knative serving 组件分析

简介: knative serving 组件分析。

knative 部署完成后可以在 knative-serving namespace 下看到创建出的组件:

$ kubectl get pod -n knative-serving
NAME                                READY   STATUS    RESTARTS   AGE
activator-7fff689bcb-zt9pm          2/2     Running   2          28d
autoscaler-5bcff95856-pr6nk         2/2     Running   3          28d
autoscaler-hpa-75584dd678-fpk7w     2/2     Running   1          28d
controller-bbdd78bc4-6cqm4          2/2     Running   1          28d
istio-webhook-5f5794dcc4-sgzlj      2/2     Running   1          28d
networking-istio-7d875675c7-gc55v   1/1     Running   0          28d
storage-version-migration-f46wc     1/2     Running   2          28d
webhook-68bb66b676-9xk4s            2/2     Running   11         28d

创建 knative serving

首先创建一个 knative service 进行测试,yaml 文件如下所示:

// 创建 helloworld-go 示例:
$ cat <<-EOF | kubectl apply -f -
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: example
spec:
  template:
    spec:
      containers:
      - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:160e4dc8
        env:
        - name: TARGET
          value: "Go Sample v1"
EOF


// 查看 helloworld-go serving 所关联的资源
$ kubectl get all -n example
NAME                                                  READY   STATUS    RESTARTS   AGE
pod/helloworld-go-wkrdr-deployment-57b86596d7-7qvcf   2/2     Running   0          11s

NAME                                  TYPE           CLUSTER-IP    EXTERNAL-IP                                            PORT(S)                             AGE
service/helloworld-go                 ExternalName   <none>        cluster-local-gateway.istio-system.svc.cluster.local   <none>                              8s
service/helloworld-go-wkrdr           ClusterIP      10.96.64.61   <none>                                                 80/TCP                              11s
service/helloworld-go-wkrdr-private   ClusterIP      10.96.79.32   <none>                                                 80/TCP,9090/TCP,9091/TCP,8022/TCP   11s

NAME                                             READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/helloworld-go-wkrdr-deployment   1/1     1            1           11s

NAME                                                        DESIRED   CURRENT   READY   AGE
replicaset.apps/helloworld-go-wkrdr-deployment-57b86596d7   1         1         1       11s

NAME                                               CONFIG NAME     K8S SERVICE NAME      GENERATION   READY   REASON
revision.serving.knative.dev/helloworld-go-wkrdr   helloworld-go   helloworld-go-wkrdr   1            True

NAME                                              LATESTCREATED         LATESTREADY           READY   REASON
configuration.serving.knative.dev/helloworld-go   helloworld-go-wkrdr   helloworld-go-wkrdr   True

NAME                                        URL                                        LATESTCREATED         LATESTREADY           READY   REASON
service.serving.knative.dev/helloworld-go   http://helloworld-go.example.example.com   helloworld-go-wkrdr   helloworld-go-wkrdr   True

NAME                                      URL                                        READY   REASON
route.serving.knative.dev/helloworld-go   http://helloworld-go.example.example.com   True


$ kubectl get serverlessservice -n example
NAME                  MODE    ACTIVATORS   SERVICENAME           PRIVATESERVICENAME            READY     REASON
helloworld-go-wkrdr   Proxy   2            helloworld-go-wkrdr   helloworld-go-wkrdr-private   Unknown   NoHealthyBackends

$ kubectl get svc istio-ingressgateway --namespace istio-system
NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                                                      AGE
istio-ingressgateway   LoadBalancer   10.96.189.189   <pending>     15021:30883/TCP,80:31046/TCP,443:32728/TCP,15443:30769/TCP   21d

创建完成后验证一下 knative 的 kpa 功能,创建完 helloworld-go serving 后会存在一个 pod 实例,如果该 pod 长时间没有被访问则会被销毁。首先验证下首次请求 helloworld-go 的场景,当服务的实例被完全销毁后,请求 helloworld-go 的 URL 此时会先启动一个实例,如下所示:

$ time curl -H "Host: helloworld-go.example.example.com" http://192.168.99.130:31046
Hello Go Sample v1!
curl -H "Host: helloworld-go.example.example.com" http://192.168.99.130:31046  0.00s user 0.01s system 0% cpu 2.189 total

使用 minkube 搭建的 k8s 集群由于没有 loadBalancer 此处使用 nodeport 来访问,nodeport 的 31046 端口会转发到后端实例的 8080 端口。当流量到达 helloworld-go 服务时,此时该服务还没有实例,activator 感知到请求后会对 helloworld-go 的 deployment 进行一次扩容,将 deployment 的 replicas 指定为 1,此时 helloworld-go deployment 会拉起一个 pod 实例,由于 pod 首次启动会比较慢。

在实际的环境中,当流量达到后再启动 pod 是不可接受的,一般会保留一个相同实例的 pod 或者一个配置较低的实例,避免冷启动时相应慢或者丢失流量等情况。

存在一个实例后,再次访问时可以看到整个请求流程非常快了,如下所示:

$ time curl -H "Host: helloworld-go.example.example.com" http://192.168.99.130:31046
Hello Go Sample v1!
$ curl -H "Host: helloworld-go.example.example.com" http://192.168.99.130:31046  0.01s user 0.01s system 45% cpu 0.026 total

knative serving 组件

serving 共有 6 个主要的组件,其中 5 个在 knative-serving 这个 namespace 下面,分别为 controller 、webhook 、autoscaler、autoscaler-hpa、activator 这五个组件;还有一个 queue,运行在每个应用的 pod 里,作为 pod 的 sidecar 存在。

  • 1、Controller:负载 Service 整个生命周期的管理,涉及、Configuration、Route、Revision 等的 CURD。是一个控制器,根据用户输入更新集群的状态;
  • 2、Webhook:主要负责创建和更新的参数校验;
  • 3、Activator:在应用缩容到 0 后,拦截用户的请求,通知 autoscaler 启动相应应用实例,等待启动后将请求转发。负责将服务缩容到 0 以及转发请求;
  • 4、Autoscaler:根据应用的请求并发量对应用扩缩容;
  • 5、Queue:负载拦截转发给 Pod 的请求,用于统计 Pod 的请求并发量等,autoscaler 会访问 queue 获取相应数据对应用扩缩容;
  • 6、Autoscaler-hpa:负责 autoscaler 应用的扩缩容;

Knative 把应用里的所有能力全都放到统一的 CRD 资源中管理—Service。这里的 Service 与 K8s 原生用户访问的 Service 不同,这是 Knative 的自定义资源,管理 Knative 应用的整个生命周期。

  • Service:service.serving.knative.dev 资源管理着工作负载的整个生命周期。它控制其他对象(Route、Configration、Revison)的创建,并确保每次对 Service 的更新都作用到其他对象。
  • Route: route.serving.knative.dev 资源将网络端点映射到一个或多个 Revision。可以通过配置 Route 实现多种流量管理方式,包括部分流量和命名路由。
  • Configuration:configuration.serving.knative.dev 资源保持部署所需的状态。它提供了代码和配置之间的清晰分离,并遵循十二要素应用程序方法。修改 Configuration 将创建新的 Revision。
  • Revision:revision.serving.knative.dev 资源是对工作负荷所做的每个修改的代码和配置的时间点快照。修订是不变的对象,只要有用就可以保留。Revision 可以根据进入的流量自动扩缩容。

Serving 关联的所有资源如下图所示:

  • 1、revision 会创建 imageCache、deployment、kpa 以及 sks 几个组件,deployment 是所运行的服务,kpa 会根据并发数进行伸缩对应的 deployment,ServerlessService 会为 kpa 服务在 cluster 内部和外部都创建一个可以访问的 service。image cache 主要是为了解决冷启动时拉取镜像慢的问题;
  • 2、route 会创建 svc、kingress、virtualService 几个组件,供 service 之间以及从外部访问;

自动扩缩容

1->n: 任何访问应用的请求在进入 Pod 后都会被 Queue 拦截,统计当前 Pod 的请求并发数,同时 Queue 会开放一个 metric 接口,autoscalor 通过访问该端口去获取 Pod 的请求并发量并计算是否需要扩缩容。当需要扩缩容时,autoscalor 会通过修改 Revision 下的 deployment 的实例个数达到扩缩容的效果。

0->1: 在应用长时间无请求访问时,实例会缩减到 0。这个时候,访问应用的请求会被转发到 activator,并在请求在转发到 activator 之前会被标记请求访问的 Revision 信息(由 controller 修改 VirtualService 实现)。activator 接收到请求后,会将 Revision 的并发量加 1,并将 metric 推送给 autoscalor,启动 Pod。同时,activator 监控 Revision 的启动状态,Revision 正常启动后,将请求转发给相应的 Pod。

当然,在 Revision 正常启动后,应用的请求将不会再发送到 activator,而且直接发送至应用的 Pod(由 controller 修改 VirtualService 实现)。

在 mac 下使用 hey 进行压测,当请求数增加时对应服务的实例数同样会增加:

$ hey -z 30s -c 50 -host "helloworld-go.example.example.com" http://192.168.99.130:31046

knative 网络模式

knative 目前默认使用 Istio 作为网络的基础,但 knative 不强依赖 istio,除 istio 之外,还可以选择 ambassador,contour,gloo,kourier 等。网络模式分两个部分,一个为 service 之间的访问,一个为外部访问。

service 之间的访问:

  • istio 会解析 knative service 的 virtualService 下发给各个 pod 的 envoy,当应用通过域名相互访问时,envoy 会拦截请求直接转发给相应的 pod。

外部访问:

  • 如果是在集群外访问,默认的请求入口为 ingressgateway,ingressgateway 将请求根据访问域名转发到应用,如上面示例所示,在本地搭建的 k8s 集群上访问 ingressgateway 的 nodeport,ingressgateway 会将请求转发到后端的 service;
  • 如果是在集群节点上访问,每个 knative service 都对应一个 k8s service, 这个 service 的后端都为 ingressgateway,ingressgateway 会根据访问域名转发到应用;

knative 会给每一个 revision 都生成一个域名用于外部访问使用,service 默认的主域名是 example.com,所有 knative service 生成的独立域名都是这个主域名的子域名,可以通过修改 config 来指定默认域名:

$ kubectl edit cm config-domain --namespace knative-serving

参考:

https://knative.dev/docs/serving/

https://github.com/knative/docs/tree/master/docs/serving/samples/hello-world/helloworld-go

相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。 &nbsp; &nbsp; 相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
目录
相关文章
|
存储 JSON Prometheus
Kubernetes 监控 Harbor
Kubernetes 监控 Harbor
2422 1
|
10月前
|
传感器 存储 供应链
物联网技术在物流领域的应用实例有哪些?
物联网技术在物流领域的应用实例有哪些?
2029 59
|
7月前
|
域名解析 人工智能 弹性计算
基于Knative快速部署DeepSeek-R1
本文以DeepSeek-R1模型、GPU类型为A10卡为例,介绍如何在Knative中快速部署一个DeepSeek-R1推理服务。
|
机器学习/深度学习 Kubernetes 算法框架/工具
容器服务 ACK 大模型推理最佳实践系列一:TensorRT-LLM
在 ACK 中使用 KServe 部署 Triton+TensorRT-LLM
|
9月前
|
消息中间件 人工智能 Kubernetes
解密开源Serverless容器框架:事件驱动篇
Knative是一款基于Kubernetes的开源Serverless框架,提供了云原生、跨平台的Serverless编排标准。作为Serverless中必不可少的事件驱动能力,Knative Eventing提供了云原生的事件驱动能力。
|
9月前
|
存储 安全 网络安全
云计算与网络安全:技术融合下的挑战与机遇
随着云计算技术的飞速发展,网络安全问题也日益凸显。本文将探讨云计算环境下的网络安全挑战,以及如何通过技术创新来应对这些挑战。我们将分析云服务的安全特性,讨论信息安全的最佳实践,并展望未来云计算与网络安全的发展趋势。
|
人工智能 算法 NoSQL
GraphRAG 与 RAG 的比较分析
Graph RAG 技术通过引入图结构化的知识表示和处理方法,显著增强了传统 RAG 系统的能力。它不仅提高了信息检索的准确性和完整性,还为复杂查询和多步推理提供了更强大的支持。
1423 10
|
10月前
|
人工智能 Kubernetes 云计算
第五届CID大会成功举办,阿里云基础设施加速AI智能产业发展!
第五届中国云计算基础架构开发者大会(CID)于2024年10月19日在北京成功举办。大会汇聚了300多位现场参会者和超过3万名在线观众,30余位技术专家进行了精彩分享,涵盖高效部署大模型推理、Knative加速AI应用Serverless化、AMD平台PMU虚拟化技术实践、Kubernetes中全链路GPU高效管理等前沿话题。阿里云的讲师团队通过专业解读,为与会者带来了全新的视野和启发,推动了云计算技术的创新发展。
|
芯片
Pi滤波器 - 概述、工作、构造、应用和设计技巧
滤波器通常用于电源和音频电子设备以抑制不需要的频率。根据应用,电子电路设计中使用了许多不同类型的滤波器,但所有这些滤波器的基本概念都是相同的,即去除不需要的信号。所有这些滤波器都可以分为两种类型——有源滤波器和无源滤波器。
2033 0
|
API 容器 Perl
调整istio-proxy(envoy)日志级别
istio-proxy也是我们常说的sidecar,istio默认使用envoy注入的,envoy的日志级别包括trace, debug, info, warning, error, critical, offistioctl命令动态调整istio默认使用的warning级别的日志,可以通过istioctl命令来指定sidecar修改日志级别istioctl -n [namespace] prox
1349 0