K8s | 声明式API与Kubernetes编程范式

• 先 kubectl create，再 replace 的操作，称为命令式配置文件操作。

• 什么才是“声明式 API”——kubectl apply

  创建和修改都用kubectl apply

  • kubectl replace 是使用新的 YAML 文件中的API 对象，替换原有的 API 对象，一次只能处理一个写请求

  • kubectl apply是执行一个对原有 API 对象的PATCH 操作，一次能处理多个写操作，并且具备 Merge 能力

• Envoy——讲解一下声明式 API 在实际使用的重要意义

  Envoy是一个高性能 C++ 网络代理，istio 的控制层（Control Plane）里的 Pilot 组件，能通过调用每个 Envoy容器的 API对Envoy 代理进行配置，实现微服务治理

  • Envoy以 sidecar 容器的方式运行在每被治理的应用Pod 中，通过配置 Pod 里的 iptables 规则，接管整个 Pod 的进出流量

  • DynamicAdmission Control ——“热插拔”式的 Admission 机制，也叫作：Initializer。

    • 背景： K8s 的1个 Pod 或者1个 API 对象被提交给 APIServer ，有一些“初始化”性质的工作需要在它们被正式处理之前进行
      eg: 自动为所有 Pod 加上某些标签（Labels）

    • Istio 项目要做的，就是在1个 Pod YAML 被提交给 K8s 之后，在里面自动加上 Envoy 容器的配置

      • Istio 会将 Envoy 容器本身的定义，以 ConfigMap 的方式保存，这个 ConfigMap 的 data 部分，正是一个 Pod 对象的一部分定义，所以会有重叠，所以更新用户的 Pod 对象的时候，必须使用 PATCH API 来完成

      • Istio 将一个编写好的 Initializer，作为一个 Pod 部署在 K8s 中，其中这个Initializer的工作过程如下：

        这个 envoy-initializer 使用的 envoy-initializer:0.0.1 镜像，是一个事先写好的“自定义控制器”（Custom Controller），在下一篇文章中讲解

        • initializer 控制器

          • 1、不断检查有无新pod创建, 实际就是死循环，逻辑伪代码

          • 2、从 APIServer 中拿ConfigMap的data

          • 3、将 ConfigMap 里存储的 containers 和 volumes 字段，直接添加进一个空的Pod 对象里

          • 4、使用k8sAPI，使用新旧两个 Pod 对象，生成一个 TwoWayMergePatch

          • 5、调用 K8s 的 Client，发起一个 PATCH 请求

          • ps、指定要对什么样的资源起作用

            • 成功创建后，新创建的 Pod 的 Metadata 上就有这个Initializer的name，但initializer 里完成了要做的操作后，一定要记得将metadata.initializers.pending 标志清除掉

          • ps、在具体的 Pod 的 Annotation 里声明要使用哪个 Initializer, eg：Annotation写initializer.kubernetes.io/envoy=true, 就会使用到我们前面所定义的envoy-initializer

• 如何理解“Kubernetes 编程范式”，如何为 Kubernetes 添加自定义 API 对象，编写自定义控制器，正是这个晋级过程中的关键点