23-0-声明式API

这些API对象，有的描述应用，有的为应用提供服务。但为使用这些API对象提供的能力，都要编写对应YAML文件交给k8s。

这YAML正是k8s声明式API必备要素。

1 用YAML代替命令行操作，就是声明式API？

Swarm编排操作都是命令行操作：

# 创建两个容器
$ docker service create --name nginx --replicas 2  nginx
# 把它们“滚动更新”为一个新镜像
$ docker service update --image nginx:1.7.9 nginx

k8s咋做？本地编写一个Deployment YAML：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

kubectl create在k8s创建这Deployment对象：

$ kubectl create -f nginx.yaml

更新这两个Pod使用的Nginx镜像，可用kubectl set image、kubectl edit直接修改k8s里的API对象。

Q：能否通过修改本地YAML完成操作？这样我的改动就会体现在本地YAML。

A：可！可修改这YAML里的Pod模板部分，把Nginx容器的镜像改成1.7.9：

...
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9

执行kubectl replace完成这Deployment的更新：

$ kubectl replace -f nginx.yaml

Q：这种基于YAML的操作方式，是“声明式API”吗？

A：不是。

这种先kubectl create，再replace的操作称为命令式配置文件操作。和前面Docker Swarm那两句命令，无本质区别。只是把Docker命令行的参数写在配置文件。

啥才是“声明式API”

kubectl apply命令。

kubectl apply创建Deployment：

$ kubectl apply -f nginx.yaml

Nginx的Deployment就被创建，看起来跟kubectl create效果一样。

再修改nginx.yaml里定义的镜像：

...
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9

修改完这YAML后，不用kubectl replace更新，而是继续执行kubectl apply：

$ kubectl apply -f nginx.yaml

k8s会立即触发这Deployment的“滚动更新”。

kubectl apply V.S kubectl replace

• kubectl replace执行过程，是用新YAML中的API对象， 替换原有API对象
• kubectl apply，执行一个 对原有API对象的PATCH操作

类似地，kubectl set image和kubectl edit也是对已有API对象的修改。

即kube-apiserver在响应:

• 命令式请求（如kubectl replace）时，一次只能处理一个写请求，否则会有冲突可能
• 而对声明式请求（比如，kubectl apply）， 一次能处理多个写操作，并具备Merge能力

正因要照顾到这样的API设计，做同样一件事，k8s需要步骤比其他项目多。

声明式API的重要意义

2017年5月，Google、IBM和Lyft公司共同宣布Istio诞生，掀起“微服务”热潮，把Service Mesh新编排的概念推到风口浪尖。

Istio就是基于k8s的微服务治理框架：

Istio最根本组件，是运行在每个应用Pod里的Envoy容器：Lyft推出的高性能C++网络代理，也是L对Istio项目唯一贡献。

而Istio则把这代理服务以sidecar容器方式，运行在每个被治理的应用Pod。Pod里的所有容器共享同一Network Namespace。所以，Envoy就能通过配置Pod里的iptables规则，把整个Pod的进出流量接管。

这时，Istio的控制层（Control Plane）里的Pilot组件，就能够通过调用每个Envoy容器的API，对这Envoy代理进行配置，从而实现微服务治理。

灰度发布

假设这Istio架构图左边Pod是已运行应用，右边Pod是刚上线的应用新版本。这时，Pilot通过调节这两Pod里的Envoy容器的配置，将90%流量分配给旧版本应用，10%分给新版本应用，且后续还能随时调整。如Istio可调节这流量从90%-10%，改到80%-20%，再到50%-50%，最后到0%-100%，完成灰度发布。

整个微服务治理过程，无论对Envoy容器的部署，还是像上面对Envoy代理的配置，用户和应用完全“无感”。

Istio项目需要在每个Pod安装一个Envoy容器，又咋做到“无感”？Istio利用k8s重要功能 - Dynamic Admission Control。

k8s中，当某Pod或任一API对象被提交给APIServer后，总有一些“初始化”性质的工作需要在它们被k8s正式处理前进行。如自动为所有Pod加标签（Labels）。

而这“初始化”操作的实现，借助Admission，是k8s里一组Admission Controller代码，可选择性编译进APIServer，在API对象创建后会被立刻调用。

但这意味着，若你想添加一些自定义规则到Admission Controller，得重新编译并重启APIServer，对Istio影响太大。

所以，k8s额外提供“热插拔”式Admission机制 - Dynamic Admission Control，也叫Initializer。

案例

有如下Pod：

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busybox
    command: ['sh', '-c', 'echo Hello k8s! && sleep 3600']

这Pod里只有一个用户容器：myapp-container。

Istio就是在这Pod YAML被提交给k8s后，在它对应API对象里自动加上Envoy容器配置，使这对象变成：

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busybox
    command: ['sh', '-c', 'echo Hello k8s! && sleep 3600']
  - name: envoy
    image: lyft/envoy:845747b88f102c0fd262ab234308e9e22f693a1
    command: ["/usr/local/bin/envoy"]
    ...

被Istio处理后的Pod，除用户自定义的myapp-container容器，多个envoy容器，即Istio要使用的Envoy代理。

Istio咋在用户不知情完成这操作？

Istio要编写个为Pod“自动注入”Envoy容器的Initializer。

Istio会将这Envoy容器本身的定义，以ConfigMap保存在k8s。这ConfigMap（名叫：envoy-initializer）的定义：

apiVersion: v1
kind: ConfigMap
metadata:
  name: envoy-initializer
data:
  config: |
    containers:
      - name: envoy
        image: lyft/envoy:845747db88f102c0fd262ab234308e9e22f693a1
        command: ["/usr/local/bin/envoy"]
        args:
          - "--concurrency 4"
          - "--config-path /etc/envoy/envoy.json"
          - "--mode serve"
        ports:
          - containerPort: 80
            protocol: TCP
        resources:
          limits:
            cpu: "1000m"
            memory: "512Mi"
          requests:
            cpu: "100m"
            memory: "64Mi"
        volumeMounts:
          - name: envoy-conf
            mountPath: /etc/envoy
    volumes:
      - name: envoy-conf
        configMap:
          name: envoy

这ConfigMap的data正是Pod对象的一部分定义。Envoy容器对应的containers字段及一个用来声明Envoy配置文件的volumes字段。

Initializer

就是把这部分Envoy相关字段，自动添加到用户提交的Pod的API对象。可用户提交的Pod里本就有containers字段和volumes字段，所以k8s在处理这样的更新请求时，须使用类似git merge的操作，才能将这两部分内容合并。

所以，Initializer更新用户的Pod对象时，须用PATCH API完成，这正是声明式API最主要能力。

接下来，Istio将编写好的Initializer，作为一个Pod部署在k8s。Pod定义：

apiVersion: v1
kind: Pod
metadata:
  labels:
    app: envoy-initializer
  name: envoy-initializer
spec:
  containers:
    - name: envoy-initializer
      image: envoy-initializer:0.0.1
      imagePullPolicy: Always

这envoy-initializer使用envoy-initializer:0.0.1镜像，即事先编写好的“自定义控制器”（Custom Controller）。

控制器的主要功能

一个k8s的控制器，就是个“死循环”：不断获取“实际状态”，然后与“期望状态”对比，并以此为依据决定下一步。

而Initializer的控制器，不断获取到的“实际状态”，就是用户新创建的Pod。而它的“期望状态”，则是：这个Pod里被添加了Envoy容器的定义。

Go伪代码描述控制逻辑：

for {
  // 获取新建的Pod
  pod := client.GetLatestPod()
  // Diff一下，检查是否已初始化
  if !isInitialized(pod) {
    // 没有？那就初始化
    doSomething(pod)
  }
}

• 若这Pod里已添加过Envoy容器，就“放过”这Pod，进入下个检查周期
• 若还没添加过Envoy容器，就要进行Initialize操作，修改该Pod的API对象（doSomething函数）

Istio要往这Pod里合并的字段，正是之前保存在envoy-initializer这个ConfigMap里的数据（data字段值）。

所以，Initializer控制器的工作逻辑里，先从APIServer中拿到这ConfigMap：

func doSomething(pod) {
  cm := client.Get(ConfigMap, "envoy-initializer")
}

然后，把这ConfigMap里存储的containers和volumes字段，直接加进一个空Pod对象：

func doSomething(pod) {
  cm := client.Get(ConfigMap, "envoy-initializer")
  
  newPod := Pod{}
  newPod.Spec.Containers = cm.Containers
  newPod.Spec.Volumes = cm.Volumes
}

k8s的API可直接使用新旧两个Pod对象，生成一个TwoWayMergePatch：

func doSomething(pod) {
  cm := client.Get(ConfigMap, "envoy-initializer")

  newPod := Pod{}
  newPod.Spec.Containers = cm.Containers
  newPod.Spec.Volumes = cm.Volumes

  // 生成patch数据
  patchBytes := strategicpatch.CreateTwoWayMergePatch(pod, newPod)

  // 发起PATCH请求，修改这个pod对象
  client.Patch(pod.Name, patchBytes)
}

有这TwoWayMergePatch后，Initializer代码就可使用这patch的数据，调用k8s的Client，发起一个PATCH请求。

这样，一个用户提交的Pod对象里，就会被自动加上Envoy容器相关字段。

k8s还允许你通过配置指定要对什么样的资源进行这Initialize操作：

apiVersion: admissionregistration.k8s.io/v1alpha1
kind: InitializerConfiguration
metadata:
  name: envoy-config
initializers:
  // 这名字须至少包括两个 "."
  - name: envoy.initializer.k8s.io
    rules:
      - apiGroups:
          - "" // ""就是core API Group
        apiVersions:
          - v1
        resources:
          - pods

这配置意味着k8s要对所有Pod进行这Initialize操作，且指定负责这操作的Initializer：envoy-initializer。

一旦这InitializerConfiguration被创建，k8s就会把这Initializer的名字，加在所有新创建的Pod的Metadata：

apiVersion: v1
kind: Pod
metadata:
  initializers:
    pending:
      - name: envoy.initializer.k8s.io
  name: myapp-pod
  labels:
    app: myapp
...

每个新创建的Pod，都会自动携带metadata.initializers.pending的Metadata信息。

这Metadata就是Initializer的控制器判断这Pod有无执行过自己所负责的初始化操作的重要依据（isInitialized()方法）。

即当你在Initializer里完成要做的操作后，记得将这metadata.initializers.pending标志清除。编写Initializer代码时要注意。

还可在具体Pod的Annotation里添加如下字段，声明要使用某Initializer：

apiVersion: v1
kind: Pod
metadata
  annotations:
    "initializer.k8s.io/envoy": "true"
    ...

这就会使用前面定义的envoy-initializer。

小结

Istio核心就是由无数个运行在应用Pod中的Envoy容器组成的服务代理网格。正是Service Mesh含义。

GitHub链接。

这机制得以实现的原理，正是借助k8s能对API对象进行在线更新，这也是k8s“声明式API”独特之处：

• 首先，所谓“声明式”，指的就是我只需要提交一个定义好的API对象来“声明”，我所期望的状态是什么样子。
• 其次，“声明式API”允许有多个API写端，以PATCH的方式对API对象进行修改，而无需关心本地原始YAML文件的内容。
• 最后，也是最重要的，有了上述两个能力，k8s项目才可以基于对API对象的增、删、改、查，在完全无需外界干预的情况下，完成对“实际状态”和“期望状态”的调谐（Reconcile）过程。

所以说，声明式API，才是k8s项目编排能力“赖以生存”的核心所在，希望你能够认真理解。

无论是对sidecar容器的巧妙设计，还是对Initializer的合理利用，Istio设计与实现都依托于k8s的声明式API和它所提供的各种编排能力。Istio是在k8s项目使用上的一位“集大成者”。

一个Istio项目部署完成后，会在k8s里创建约43个API对象。

Istio多火热，就说明k8s这套“声明式API”多成功。这既是Google Cloud喜闻乐见的事情，也是Istio一出就被Google公司和整个技术圈儿热捧原因。

而在使用Initializer的流程中，最核心的步骤，莫过于Initializer“自定义控制器”的编写过程。它遵循的，正是标准的“k8s编程范式”，即：

如何使用控制器模式，同k8s里API对象的“增、删、改、查”进行协作，进而完成用户业务逻辑的编写过程。

这，也正是我要在后面文章中为你详细讲解的内容。

总结

讲解了k8s声明式API的含义。并且，通过对Istio项目的剖析，说明了它使用k8s的Initializer特性，完成Envoy容器“自动注入”的原理。

从“使用k8s部署代码”，到“使用k8s编写代码”的蜕变过程，正是你从一个k8s用户，到k8s玩家晋级之路。

尽管Istio项目一直宣称它可以运行在非k8s环境中，但我并不建议你花太多时间去做这个尝试。无论是从技术实现还是在社区运作上，Istio与k8s项目之间都唇齿相依。如脱离k8s，这条原本就不算平坦的“微服务”之路更困难。

获取更多干货内容，记得关注我哦。