举个栗子

　　在本地编写一个Deployment的YAML文件：

apiVersion: apps/v1

kind: Deployment

metadata:

  name: nginx-deployment

spec:

  selector:

    matchLabels:

      app: nginx

  replicas:

  template:

    metadata:

      labels:

        app: nginx

    spec:

      containers:

      - name: nginx

        image: nginx

        ports:

        - containerPort:

###然后用kubectl apply创建这个Deployment

$ kubectl apply -f nginx.yaml

### 倘若修改一下nginx里定义的镜像

...

    spec:

      containers:

      - name: nginx

        image: nginx:1.7.

###可以继续执行一条kubectl apply命令，触发滚动更新

$ kubectl apply -f nginx.yaml

　　kubectl apply执行了一个对原有API对象的PATCH（补丁）操作。而kubectl replace的执行过程，是使用新的YAML文件中的API对象，替换原来的API对象。

　　这意味着kube-apiserver在响应命令式请求（kubectl replace）的时候，一次只能处理一个写请求，否则会有产生冲突的可能。而对于声明式请求（kubectl apply），一次能处理多个写操作，并且具备Merge能力。

那声明式API在实际使用中有何重要意义呢？举起第二个栗子

　　Istio是一个基于Kubernetes项目的微服务治理框架。它最根本的组件是允许在每一个应用Pod里的Envoy容器，Envoy是一个高性能的C++网络代理，Istio把这个代理服务以sidecar容器的方式，运行在了每一个被治理的应用Pod中，因Pod里的所有容器共享同一个Network Namespace，所以Envoy容器就能够通过配置Pod里的iptables规则，把整个Pod的进出流量接管下来。这时候Istio的控制层里的Pilot组件就能够通过调用每个Envoy容器的API，对这个Envoy代理进行配置，从而实现微服务治理。

　　更重要的是，在整个微服务治理过程中，无论是对Envoy容器的部署，还是对Envoy代理的配置，用户和应用都是无感的。

　　那istio明明需要在每个Pod里安装一个Envoy容器，又怎么能做到无感呢？　　

　　实际上，istio项目使用的是，Kubernetes中一个非常重要的功能，叫做Dynamic Admission Control。

　　在Kubernetes中，当一个Pod或者任何一个API对象被提交给APIServer之后，总有一些初始化性质的工作需要在被Kubernetes项目正式处理之间进行（如自动为所有Pod加上某些标签），而这个初始化操作的实现，借助的是一个叫做Admission的功能，它其实是接祖Kubernetes项目里一组被称为Admission Controller的代码，可以选择性地被编译进APIServer中，在API对象创建之后会被立刻调用到。但这就意味着如果现在想要添加一些自己的规则到Admission Controller会比较困难，因为这要求重新编译并重启APIServer。显然这个对istio影响太大。

　　因此Kubernetes提供了一种热插拔的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 Kubernetes! && sleep 3600']

　　可以看到，这个Pod里面只有一个用户容器：myapp-container

　　istio要做的就是在这个Pod YAML被提交给Kubernetes之后，在它对应的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 Kubernetes! && sleep 3600']

  - name: envoy

    image: lyft/envoy:845747b88f102c0fd262ab234308e9e22f693a1

    command: ["/usr/local/bin/envoy"]

    ...

　　可以看到，多出了一个叫envoy的容器，那istio又是如何在用户不知情的前提下完成这个操作的呢？

　　istio做的就是编写一个用来为Pod自动注入Envoy容器的Initializer。

　　首先Istio会将这个Envoy容器本身的定义，以ConfigMap的方式保存在Kubernetes中

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:

            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容器对应的Container字段，以及一个用来声明Envoy配置文件的volumes字段。Initializer要做的就是把这部分Envoy相关的字段，自动添加到用户提交的Pod的API对象里。但是用户提交的Pod里本来就有containers和volumes字段，所以Kubernetes在处理这样的更新请求时，就必须使用类似于git merge这样的操作，才能将这两部分内容合并在一起。即Initializer更新用户的Pod对象时，必须使用PATCH API来完成。

　　接下来，Istio将编写好的Initializer作为一个Pod部署在Kubernetes中

apiVersion: v1

kind: Pod

metadata:

  labels:

    app: envoy-initializer

  name: envoy-initializer

spec:

  containers:

    - name: envoy-initializer

      image: envoy-initializer:0.0.

      imagePullPolicy: Always

　　envoy-initializer:0.0.1镜像时一个自定义控制器（Custom Controller）。Kubernetes的控制器实际上是一个死循环：它不断地获取实际状态，然后与期望状态作对比，并以此为依据决定下一步的操作。

　　对Initializer控制器，不断获取的实际状态，就是用户新创建的Pod，它期望的状态就是这个Pod里被添加了Envoy容器的定义。它的控制逻辑如下：

for {

  // 获取新创建的 Pod

  pod := client.GetLatestPod()

  // Diff 一下，检查是否已经初始化过

  if !isInitialized(pod) {

    // 没有？那就来初始化一下

   //istio要往这个Pod里合并的字段，就是ConfigMap里data字段的值

    doSomething(pod)

  }

}

func doSomething(pod) {

  //调用APIServer拿到ConfigMap

  cm := client.Get(ConfigMap, "envoy-initializer") 

  //把ConfigMap里存在的containers和volumes字段，直接添加进一个空的Pod对象

  newPod := Pod{}

  newPod.Spec.Containers = cm.Containers

  newPod.Spec.Volumes = cm.Volumes

  // Kubernetes的API库，提供一个方法使我们可以直接使用新旧两个Pod对象，生成 patch 数据

  patchBytes := strategicpatch.CreateTwoWayMergePatch(pod, newPod)

  // 发起 PATCH 请求，修改这个 pod 对象

  client.Patch(pod.Name, patchBytes)

}

　　所以Envoy机制得以实现正是借助了Kubernetes能够对API对象进行在线更新的能力，这也是Kubernetes声明式API的独特之处

- 声明式：指只需要提交一个定义好的API对象来声明期望的状态是什么样子的
- 声明式API允许有多个API写短，以PATCH的方式对API对象进行修改，无需关心本地原始YAML文件的内容
- 有了上述两个能力，Kubernetes才可以基于对API对象的增删改查，在完全无需外界干预的情况下，完成对实际状态和期望状态的调谐过程。

　　声明式API才算Kubernetes项目编排能力赖以生存的核心所在

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

巴特西

【Kubernetes】声明式API与Kubernetes编程范式

举个栗子

那声明式API在实际使用中有何重要意义呢？举起第二个栗子

最新文章

热门文章