为了使用这些API对象提供的能力,需要编写一个对应的YAML文件交给Kubernetes。这个YAML文件是kubernetes声明式API所必须具备的一个要素。
容器的编排操作都是基于命令行。
比如,要修改容器的镜像:
kubectl set image
和kubectl edit
命令直接修改kubernetes里面的API对象。kubectl replace
命令完成镜像的更新操作。第二种方法,基于YAML文件的操作就是“声明式API”吗?显然不是。第二种方式称为命令式配置文件操作。处理方式与第一种没有区别,只不过把命令行参数写在配置文件中。
kubectl apply命令,就是声明式API。
执行的操作 | 声明式API | 命令式操作 | 异同 |
---|---|---|---|
创建容器 | kubectl apply | kubectl create | 效果一样 |
修改容器配置 | kubectl apply | kubectl replace | apply都可以,create需要更换命令才行 |
这两者的本质区别是什么?
create
到replace
是使用新的YAML文件中的API对象替换原有的API对象apply
是执行一个对原有API对象的PATCH
操作声明式API才是kubernetes项目编排能力“赖以生存”的核心所在。
kubernetes编程范式:如何使用控制器模式,同kubernetes里API对象的“增删改查”进行协作,进而完成用户业务逻辑的编写过程。
Istio项目,实际上是一个基于kubernetes项目的微服务治理框架。架构如下所示:
Istio最根本的组件,是运行在每一个应用Pod里的Envoy容器(网络代理)。把每个代理服务以sidecar容器的方式,运行在了每一个被治理的应用Pod中。
Envoy容器是Lyft公司推出的一个高性能C++网络代理。Pod中的所有容器都共享同一个Network Namespace。所以Enovy容器就能够通过配置Pod的iptables规则,把整个Pod的进出流量都接管下来。
Istio的控制层(Control Plane)里的Pilot组件,就能够通过调用每个Envoy容器的API,对整个Envoy代理进行配置,从而实现微服务治理。
更重要的是,整个微服务治理的过程中,无论是对Envoy容器的部署,还是对Envoy代理的配置,用户和应用都是“无感”的。
Istio项目使用,kubernetes中的Dynamic Admission Control功能,实现上述的“无感”操作。在kubernetes项目中,当一个Pod或者任何API对象被提交给APIServer之后,总有一些“初始化“性质的工作(如,自动为所有Pod加上某些标签)需要在它们被kubernetes项目正式处理之前进行。
初始化操作的实现借助的是Admission
功能,它是kubernetes项目里一组被成为Admission Controller
的代码,可以选择性地被编译进APIServer中,在API对象创建之后被立刻调用到。
当需要使用Admission Controller的时候,需要重新编译并启动APIServer,通过这种方式很麻烦,因此提供了一种”热插拔“的Admission机制,就是
Dynamic Admission Controller
,也叫作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中有一个容器,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"] ...
被Istio处理后,Pod中除了有一个自定义的容器还会有一个叫envoy的容器,它就是Istio要使用的Envoy代理。
如何在用户和应用无感的情况下,完成上述操作?
Istio编写一个用来给Pod”自动注入“Envoy容器的Initializer。
Istio将这个容器本身的定义,以ConfigMap
(名字叫envoy-initializer)的方式保存在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: 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包括两部分,containers字段和volumes字段。
Initializer要完成的工作是把这部分Envoy相关的字段,自动添加到用户提交的Pod的API对象里。用户提交的Pod中本来就有containers和volumes字段,所有kubernetes在处理这样的更新请求的时,类似于git merge
的操作,将两部分内容合并在一起。
在Initializer更新用户的Pod对象时,必须用到PATCH API,这正式声明式API最主要的能力。
Istio将一个编写好的Initializer,作为一个Pod部署在kubernetes中,这个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
这是一个事先编写好的“自定义控制器(custom controller)”。这个Initializer控制器,不断获取到“实际状态”(就是用户创建的Pod),它的“期望状态”就是在这个Pod中添加Envoy容器的定义。
在Kubernetes中,一个控制器,就是一个死循环,不断地获取“实际状态”,然后与“期望状态”作对比,并以此为依据决定下一步操作。如下所示。
for { // 获取新创建的 Pod pod := client.GetLatestPod() // Diff 一下,检查是否已经初始化过 if !isInitialized(pod) { // 没有?那就来初始化一下 doSomething(pod) } }
kubernetes的API库中,有一个方法,使得我们可以直接使用新旧两个Pod对象,生成一个
TwoWayMergePatch
。
TwoWayMergePatch
的patch数据,调用kubernetes的client,发起一个PATCH请求// 步骤一 func doSomething(pod) { cm := client.Get(ConfigMap, "envoy-initializer") } // 步骤二 func doSomething(pod) { cm := client.Get(ConfigMap, "envoy-initializer") newPod := Pod{} newPod.Spec.Containers = cm.Containers newPod.Spec.Volumes = cm.Volumes } // 步骤三 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) }
通过配置,来指定对什么样的资源进行Initializer操作,如下例子:
apiVersion: admissionregistration.k8s.io/v1alpha1 kind: InitializerConfiguration metadata: name: envoy-config initializers: // 这个名字必须至少包括两个 "." - name: envoy.initializer.kubernetes.io rules: - apiGroups: - "" // "" 就是 core API Group 的意思 apiVersions: - v1 resources: - pods
这个配置意味着kubernetes对所有pod进行Initializer操作,并且指定了负责这个操作的Initializer叫envoy-initializer。
这个InitializerConfiguration创建后,kubernetes就会自动把这个Initializer的名字,加到每个新创建的Pod的metadata中,如下所示:
apiVersion: v1 kind: Pod metadata: initializers: pending: - name: envoy.initializer.kubernetes.io name: myapp-pod labels: app: myapp ...
每个新创建的Pod都会自动携带metadata.initializers.pending的metadata信息。
这个metadata信息,就是Initializer控制器判断这个Pod有没有执行过自己所负责的初始化操作的重要依据。
当在Initializer中完成了要做的操作后,一定要将这个metadata.initializers.pending标志清除。
除了创建配置文件,也可在具体的Pod的annotation里添加一个字段,如下所示:
apiVersion: v1 kind: Pod metadata annotations: "initializer.kubernetes.io/envoy": "true" ...
添加后,就会使用到前面定义的envoy-Initializer。
Istio项目的核心就是由无数个运行在应用Pod中的Envoy容器组成的服务代理网格。这也就是server mesh的含义。这个机制实现的原理是借助于kubernetes能够对API对象进行在线更新的能力,这就是kubernetes“声明式API”的独特之处。
Istio项目对sidecar容器的巧妙设计,对Initializer操作的合理利用,都依托于kubernetes的声明式API和它所提供的各种编排能力。Istio项目是kubernetes的集大成者。
Istio项目部署完成,会在kubernetes里创建大约43个API对象。