分布式引用程序的需求
- 生命周期
- 网络
- 状态
-
多运行时微服务
生命周期管理： kubernetes
- 网络： serviceMesh
- 绑定： Knative（并非FAAS）
- 专注于ServerLess，同时兼顾了服务编排和事件驱动的绑定需求
- 状态： Dapr
- 建立在kubernetes，knative和服务网格的思想之上，并深入应用程序运行时已解决状态化工作负载，绑定和集成的需求，充当现代分布式中间件
Serverless
- 众所周知的云计算模型
场景模拟
- 如今，大多数公司在开发应用程序并将其部署、运行在服务器上的时候（无论是选择公有云还是私有的数据中心），都需要提前完成如下步骤
- 容量规划：提前了解究竟需要多少台服务器、多大容量的存储和数据库的功能等
- 部署运行应用程序和依赖的软件
概括来说，需要构建一个新的软件项目时，在编写代码之前，在IaaS或CaaS云环境下，需要完成
Serverless的基础概念
- 云原生开发模型的一种，可使开发人员专注于构建和运行应用，而无需管理服务器
- Serverless方案中仍然需要服务器，但它们已从应用开发人员的关注中抽离了出来
- 云提供商负责置备、维护和扩展服务器基础架构等例行工作
- 开发人员可以简单地将代码打包到容器中进行部署
- 部署之后，无服务器应用即可响应需求，并根据需要自动扩容
- 用户为实际占用的资源付费，而不再是固定的带宽或者服务器数量
- Serverless与其它云计算模型的核心区别
- 由云服务商负责管理基础架构和应用扩展
- 应用部署于容器中，这些容器在被调用时将会自动按需启动
- 出现能够触发应用代码运行的事件时，云架构才会为这一代码分配资源
- 代码执行结束后，占用的大部分资源便即释放
- 帮助公司避免服务器等资源的过渡采购，提高资源效益
- 操作系统、文件系统、安全补丁、负载均衡、容量管理、扩展、日志和监控等例行任务都由底层的云服务完成，从而将开发人员从应用扩展和服务器置备相关的琐碎日常任务中解放出来
现代应用架构通常是Serverless、Microservices和传统分布式应用的混合模式
Serverless产品通常可分为两类
- BaaS（Backend as a Service）
- FaaS（Function as a Service） BaaS
- 云服务端将后端需要的各种服务，例如认证服务、数据库、消息队列、文件存储、代码构建等各种后端功能封装为API提供给用户
- 用户只需要根据BaaS的API编写并提交代码即可自动完成应用构建、部署、运行、扩缩容等功能
FaaS
较之PaaS，BaaS能够为用户实现更多的价值
- IaaS=数据中心+服务器+存储+网络
- PaaS=IaaS+部署+管理+扩展
- BaaS=PaaS+自动化构建
- 缺点
- 供应商锁定
- BAAS与FAAS的区别与联系
- BaaS处理整个后端功能，而FaaS仅处理应用程序中支持响应的事件
serverless的优缺点
- 优点
- 较低的运维成本
- 较低的开发成本
- 自动化弹性扩展
- 较高的计算资源利用率
缺点
云厂商的FaaS产品
- AWS Lambda
- Google Cloud Functions
- Microsoft Azure Functions (open source)
- Aliyun Function Compute
- Huawei Cloud FunctionGraph（函数工作流）
- ……
开源解决方案
Knative项目简介
- 读音为“kay-nay-tiv”，由Google于2018年7月正式发布
- Kubernetes平台的原生扩展组件，让其能够轻松地部署、运行和管理Serverless类型的云原生应用
- 由RedHat、Google和IBM等公司，以及各种初创公司组成的开源社区共同维护
- 目标在于Serverless技术标准化
- Knative的组件
- Serving
- 部署、管理及扩展无状态应用
- 支持由请求驱动计算
- 支持缩容至0
- Eventing
- 以声明的方式创建对事件源的订阅，并将事件路由到目标端点
- 事件订阅、传递和处理
- 基于pub/sub模型连接Knative的工作负载
- Build
- 从源代码构建出应用镜像
- 已经由独立的Tekton项目取代
- Serving
knative架构体系
- 遵照Kubernetes的范式，以扩展的方式，通过自定义API资源类型支持
- 自动化完成服务的部署和扩缩容（Serving）
- 标准化事件驱动基础设施（Eventing）
- Serving
- Serving Controller
- Resources API
- Service
- Configuration
- Revision
- Route
Eventing
主要包括四个CRD
事件是一个不可变的小段数据，记录了系统在特定时间内的特定行为，或状态的转变
- 通过读取系统的事件流（序列），可以重建系统的运行历史
- 事件的格式
- 事件的格式完全可由开发者自行决定
- CNCF的CloudEvents规范至力于事件格式的标准化
- 目前，众多云服务商都开始支持该规范
- 关于“事件驱动”
- 不存在一个规范、严格的定义，任何使用事件通知范式（pub/sub）的系统都是事件驱动的系统
- 事件驱动的系统大体分为两类
- 响应式（reactive）：本质上是非同步性质的函数调用（或HTTP RESTful/RPC调用）
- 流处理（stream processing）：密集式、面向数据式使用事件，订阅者通常是流处理器，它从事件流中提取状态，并将状态传递给相关方
关于“事件源（Event Sourcing）”
负责为事件的生产和消费提供基础设施，可将事件从生产者路由到目标消费者，从而让开发人员能够使用事件驱动架构
- 各资源者是松散耦合关系，可分别独立开发和部署
- 遵循CloudEvents规范
需要说明的几个问题
Knative是FaaS解决方案吗？
- Knative并未提供FaaS
- 用户可在Knative和Kubernetes之上，借助于第三方项目自行构建FaaS系统，例如Kyma Project
Knative为Kubernetes扩展出的功能
- Serving
- 替代Deployment控制器，负责编排运行基于HTTP协议的无状态应用
- 额外提供的功能特性
- Knative的Service对象，相当于Kubernetes上的 Service+Deployment 的功能
- 基于单个请求进行负载均衡
- 基于请求的快速、自动化扩缩容，并支持收缩至0实例
- 通过在Pod扩展时缓冲请求来削峰填谷
- 流量切分
- ……
Eventing
Knative仅适合运行特定类型的应用：无状态、容器化的服务器应用
部署环境
- Kubernetes：v1.23
- Knative：v1.2
- networking layer：
- 可用部署方式
- 基于YAML配置文档直接部署
- Serving和Eventing需要分别进行部署
- 借助Knative Operator进行部署
- 首先部署Knative Operator
- 通过Operator的KnativeServing部署Serving
- 通过Operator的KnativeEventing资源部署Eventing
- 基于YAML配置文档直接部署
需要部署的Knative组件
For prototyping purposes
- 单节点的Kubernetes集群，有2个可用的CPU核心，以及4g内存；
For production purposes
- 部署Serving核心组件
- 部署网络层（networking layer）组件
- Istio、Contour和Kourier三选一
- （可选）配置DNS
（可选）部署Serving扩展
- HPA：用于支持Kubernetes的HPA
- Cert Manager：用于为工作负载自动签发TLS证书
- Encrypt HTTP01：用于为工作负载自动签发TLS证书
部署Serving
| 主机ip | hostname | 备注与属性 | | —- | —- | —- | | 10.168.56.110 | k8s-ha | external IP，与宿主机和k8s节点能通信 | | 10.168.56.200 | k8s-deploy | kubeasz3.2.0 ，用于部署k8s集群 | | 10.168.56.201 | k8s-master1 | k8s v1.23.1 master,etcd 2c4g | | 10.168.56.202 | k8s-master2 | k8s v1.23.1 master,etcd 2c4g | | 10.168.56.203 | k8s-master3 | k8s v1.23.1 master,etcd 2c4g | | 10.168.56.204 | k8s-node1 | k8s v1.23.1 node 4c8g | | 10.168.56.205 | k8s-node2 | k8s v1.23.1 node 4c8g | | 10.168.56.206 | k8s-node3 | k8s v1.23.1 node 4c8g |
参考代码： https://github.com/iKubernetes/knative-in-practise/tree/main/knative-deploy-v1.2/serving
- 参考文档： https://knative.dev/docs/install/yaml-install/serving/install-serving-with-yaml/
- k8s执行如下操作
serving-core.yamlserving-crds.yaml
kubectl apply -f serving-crds.yamlkubectl api-versions | grep servingkubectl api-resources --api-group=serving.knative.devkubectl apply -f serving-core.yamlkubectl get ns
- 部署network layer
kubectl apply -l knative.dev/crd-install=true -f istio.yamlkubectl apply -f istio.yamlkubectl apply -f net-istio.yaml
- 调整外网service（external IP: ）
```
root@k8s-deploy:~# kubectl get svc -n istio-system
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
istio-ingressgateway LoadBalancer 10.68.134.87
15021:61145/TCP,80:37658/TCP,443:51054/TCP 32m istiod ClusterIP 10.68.12.199 15010/TCP,15012/TCP,443/TCP,15014/TCP 32m knative-local-gateway ClusterIP 10.68.77.117 80/TCP 32m
root@k8s-deploy:~# kubectl edit svc istio-ingressgateway -n istio-system clusterIPs:
- 10.68.134.87 externalIPs:
- 10.168.56.110 externalTrafficPolicy: Cluster
root@k8s-deploy:~# kubectl get svc -n istio-system
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
istio-ingressgateway LoadBalancer 10.68.134.87 10.168.56.110 15021:61145/TCP,80:37658/TCP,443:51054/TCP 34m
istiod ClusterIP 10.68.12.199
- 安装可选拓展- HPA: [https://github.com/knative/serving/releases/download/knative-v1.2.0/serving-hpa.yaml](https://github.com/knative/serving/releases/download/knative-v1.2.0/serving-hpa.yaml)- certmanager: [https://github.com/knative/net-certmanager/releases/download/knative-v1.2.0/release.yaml](https://github.com/knative/net-certmanager/releases/download/knative-v1.2.0/release.yaml)[release.yaml](https://www.yuque.com/attachments/yuque/0/2022/yaml/2391625/1647104343901-9f2b1fb9-ade1-43e4-ba5d-876f8ed496f6.yaml?_lake_card=%7B%22src%22%3A%22https%3A%2F%2Fwww.yuque.com%2Fattachments%2Fyuque%2F0%2F2022%2Fyaml%2F2391625%2F1647104343901-9f2b1fb9-ade1-43e4-ba5d-876f8ed496f6.yaml%22%2C%22name%22%3A%22release.yaml%22%2C%22size%22%3A13126%2C%22type%22%3A%22%22%2C%22ext%22%3A%22yaml%22%2C%22status%22%3A%22done%22%2C%22taskId%22%3A%22uddcb3463-2522-443e-b605-c974d007946%22%2C%22taskType%22%3A%22upload%22%2C%22id%22%3A%22u7d309c38%22%2C%22card%22%3A%22file%22%7D)[serving-hpa.yaml](https://www.yuque.com/attachments/yuque/0/2022/yaml/2391625/1647104343902-cdd21f87-c576-42ca-81d7-2ddc98219548.yaml?_lake_card=%7B%22src%22%3A%22https%3A%2F%2Fwww.yuque.com%2Fattachments%2Fyuque%2F0%2F2022%2Fyaml%2F2391625%2F1647104343902-cdd21f87-c576-42ca-81d7-2ddc98219548.yaml%22%2C%22name%22%3A%22serving-hpa.yaml%22%2C%22size%22%3A3601%2C%22type%22%3A%22%22%2C%22ext%22%3A%22yaml%22%2C%22status%22%3A%22done%22%2C%22taskId%22%3A%22uc7cb7a5f-cfb6-481b-9629-46260905f79%22%2C%22taskType%22%3A%22upload%22%2C%22id%22%3A%22u9d92d17a%22%2C%22card%22%3A%22file%22%7D)
kubectl apply -f serving-hpa.yaml kubectl apply -f cert-manager.yaml
- kn 客户端的安装- 官方文档： [https://knative.dev/docs/install/client/install-kn/](https://knative.dev/docs/install/client/install-kn/)
root@k8s-master1:~# wget https://github.com/knative/client/releases/download/knative-v1.2.0/kn-linux-amd64 root@k8s-master1:~# mv kn-linux-amd64 kn root@k8s-master1:~# chmod +x kn root@k8s-master1:~# mv kn /usr/bin/ root@k8s-master1:~# kn version Version: v1.2.0 Build Date: 2022-01-26 03:13:06 Git Revision: 5030b5df Supported APIs:
- Serving
- serving.knative.dev/v1 (knative-serving v0.29.0)
- Eventing
- sources.knative.dev/v1 (knative-eventing v0.29.0)
- eventing.knative.dev/v1 (knative-eventing v0.29.0)
```
Knative CLI
- kn不支持读取YAML配置文件，其所有参数均要通过命令行选项提供
- 支持Serving和Eventing中的核心资源管理
- 支持插件化扩展，目前可用的主流插件
Serving依赖于几个关键的组件协同其管理能力
- Activator：Revision中的Pod数量收缩至0时，activator负责接收并缓存相关的请求，同时报告指标数据给Autoscaler，并在Autoscaler在Revision上扩展出必要的Pod后，再将请求路由至相应的Revision；
- Autoscaler：Knative通过注入一个称为queue-proxy容器的sidecar代理来了解它部署的Pod上的请求，而Autoscaler会为每个服务使用“每秒请求数”来自动缩放其Revision上的Pod；
- Controller：负责监视Serving CRD（KService、Configuration、Route和Revision）相关的API对象并管理它们的生命周期，是Serving声明式API的关键保障；
- Webhook：为Kubernetes提供的外置Admission Controller，兼具Validation和Mutation的功能，主要作用于Serving专有的几个API资源类型之上，以及相关的ConfigMap资源上；
- Domain-mapping：将指定的域名映射至Service、KService，甚至是Knative Route之上，从而使用自定义域名访问特定的服务；
- Domainmapping-Webhook：Domain-mapping专用的Admission Controller
- net-certmanager-controller：与Cert Manager协同时使用的专用的控制器；
- net-istio-controller：与Istio协同时使用的专用控制器
Serving有如下几个专用的CRD
serving.knative.dev群组
- Service
- Configuration
- Revision
- Route
- DomainMapping
- autoscaling.internal.knative.dev群组
- Metric
- PodAutoscaler
networking.internal.knative.dev群组
一个Configuration对象，它会创建一个Revision，并由该Revision自动创建如下两个对象
- 一个Deployment对象
- 一个PodAutoscaler对象
- 一个Route对象，它会创建
- 一个Kubernetes Service对象
- 一组Istio VirtualService对象
- {kservice-name}-ingress
- {kservice-name}-mesh
- Knative Service资源（简称kservice或ksvc）的资源规范主要有两个字段
- template：用于创建或更新Configuration，任何更新，都将创建新的Revision对象
- traffic：用于创建或更新Route对象
若有收获，就点个赞吧
0 人点赞
