第二章 九析带你轻松完爆 Knative Serving 组件

第二章 九析带你轻松完爆 Knative Serving 组件

系列文章:总目录索引：九析带你轻松完爆 Knative 系列教程

目录

1 前言

2 邀约

3 Knative 简介

4 Knative Serving 架构

4.1 Configuration 对象

4.2 Route 对象

4.3 Service 对象

4.4 Revision 对象

4.5 Knative serving 各组件之间关系

1 前言

如果你对博客有任何疑问，请告诉我。

2 邀约

你可以从 b 站搜索 “九析”，获取免费的、更生动的视频资料：

3 Knative 简介

上小节中介绍 Knative 0.17.0 版本中主要组件有 Serving 和 Event。这节简要介绍一下 Serving 组件。

Serving 组件是让应用运行起来并提供服务，其中包括：

自动启动和销毁容器自动生成网络访问的 service、ingress 对象（这些原来需要运维编写相关 Yaml 文件）监控应用的请求，根据请求自动进行扩缩容（这些原来需要运维指定 K8S HPA）

使用 k8s 管理应用是一件比较辛苦的事情，尽管 k8s 针对容器编排已经非常方便，但是仍然会有很多手工、重复性工作。比如，需要根据源码创建镜像（无论是手动编写 Dockerfile 还是通过工具创建流水线）、创建 deployment 对象、创建 service 对象、创建 ingress 对象。经过上述操作才可以最终将服务暴露给外部用户使用，而且有时还需要手动创建 HPA 对象来响应容器的扩缩容策略。

Knative 提供了更简单的操作接口，使得只通过一个 Knative service 对象就可以轻松完爆上述整个流程。

下图展示了一个 Knative service 用例：

执行如下命令创建 Knative service 对象。如果要让整个 Knative 起作用，前提是已经安装好 Knative，安装过程可以参考本人上节内容。

kubectl apply -f knative-svc.yaml

执行结果如下所示，注意是 ksvc，而不是 svc，前者是 Knative 对象，后者是 K8s 对象：

部署好 Knative service 对象之后，就可以直接通过 curl 进行访问了，而不像以前 k8s 管理一样，需要手动创建 deployment、service、ingress 对象后才可以访问。访问结果如下所示：

是不是更方便了？惊不惊喜？开不开心？意不意外？

Knative Serving 组件是如何做到这一步的？这里需要介绍一下 Knative Serving 架构。

4 Knative Serving 架构

下图是 Knative Serving 架构图：

执行 kubectl apply -f knative-svc.yaml 后，会同时生成 Knative Service、Configuration、Route 和 Revision 对象。下面分别介绍这些对象。

4.1 Configuration 对象

Configuration：应用的配置对象，也就是应用目前期望的状态，你可以对标 k8s 的 deployment 对象。每次应用升级都会更新 configuration，而 Knative 同时也会保留历史版本记录（revision），结合流量管理，Knative 可以让多个不同版本共同提供服务，方便蓝绿发布和滚动升级

你可以执行如下语句来查看 Knative configuration 对象：

kubectl get configurations.serving.knative.dev -n helloworld

命令执行结果如下图所示：

4.2 Route 对象

应用的路由规则，也就是进来的流量如何访问应用，对应了 Istio 的流量管理（Virtual Service）

你可以执行如下语句来查看 Knative Route 对象：

kubectl get routes.serving.knative.dev  -n helloworld

命令执行结果如下图所示：

4.3 Service 对象

注意，这里的 Service 对象不是 k8s 提供服务发现的那个 Service，而是 Knative 自定义的的 CRD，它的全称目前是 serving.knative.dev/v1。单独控制 route 和 configuration 就能实现 serving 的所有功能，但 Knative 更推荐使用 Service 来管理，因为它会自动帮你管理 route 和 configuration

Knative Serving 和 k8s 的 pod 定义非常类似，但是它会帮你管理 deployment、ingress、service discovery、auto scaling... 等资源，从这个角度来看，Knative Serving 自动帮你封装了 k8s 和网络层（Istio、Kourier等）的实现细节。

执行如下结果查看 Knative service 对象：

kubectl get ksvc -n helloworld

命令执行结果如下图所示：

4.4 Revision 对象

可以通过执行如下指令查看 Revision 对象：

kubectl get revisions.serving.knative.dev -n helloworld

命令执行结果如下：

4.5 Knative serving 各组件之间关系

由上图可知：

每个 Revision 对应一组 deployment 管理的 podpod 自动汇报 metrics 给 Autoscaler 组件，Autoscaler 会根据请求量和资源使用情况修改 deployment 的 replicas 数量，从而实现自动扩缩容。serverless 一个重要的特性是它可以缩容到 0，也就是当没有流量访问时，它会自动销毁所有的 podActivator 组件作用是当 revision 的 pod 缩容到 0 时，route 流量就会指向 Activator，Activator 接收到请求之后会自动拉起 pod，然后把流量转发过去route 对象决定访问应用的流量如何路由

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。