kube 之声明式API与kube编程范式

kube 之声明式API与kube变成范式
读书笔记

命令式命令行操作：
docker service create --name 。。。–replicas 。。。。
docker service update --name 。。。

命令式配置文件操作：
kubectl create再 kubectl replace的操作。被称为命令式配置文件操作。
也就是说它的处理方式和钱买呢docker swarm的两句命令没有本质区别；

到底什么是声明式API
kubectl apply
kubectl replace操作时使用新的yaml文件的api对象替换原有的 api对象
kubectl apply是执行了一个对原有的api对象的 patch操作；
kubectl set image。kubetl edit也是对已有api对象的修改；也应该算是声明式api操作
更进一步：
这意味着kube-apiserver在响应式请求kubectl replace的时候。一次只能处理一个写请求。否则会产生冲突
kubectl apply一次能处理多个写操作。并具备merge能力
— 这句我理解。就是apply可以在配置文件中配置多个api对象。而响应式的replace等只能声明一个api对象？

istio项目为例说明声明式api的重要意义：
istio。一个基于kubernetes项目的微服务治理框架。
贴个图：

图中呢。istio核心组件是在每个pod内运行一个envoy组件，
–这让我想起来之前一个公司的网络安全产品。对in和out的流量进行数据安全流量清洗。—是个好主意。没机会进去。真的很失望
面试通过了。回头hr跟我说。我所在的城市hc取消了。让我无语啊。。。难受香菇。。

切回正题：
isto工作原理：
istio项目以sidecar容器的方式在每个pod中运行代理服务，我们知道pod中所有容器共享network ns。所以envoy容器就能够通过配置pod的iptables规则接管整个pod的in和out流量，这样istio的控制层里的pilot就能够通过调用envoy容器的api来对这个envoy代理进行配置。从而实现微服务治理；

灰度发布过程
pilot通过调节旧pod（定义为pod1.）里的envoy容器里的配置，将90%的流量分配给pod1.10%分配给pod2。后续没问题。将流量调整80%，50%，最后0%。这样就完成了这个灰度发布过程；

在整个微服务治理的过程中无论是对envoy容器的部署，还是对envoy代理的配置。用户和应用都是无感的；得益于kubernetes一个重要的功能Dynamic Admission Control。也称之为initializer。—热插拔式的admission机制；
关于admission controller：上个大佬的解释。我的解释多余：

initializer过程：
istio目的将envoy容器无感的加入到业务pod中。期望状态就是酱envoy的conteainer的配置自动加入到业务pod的yaml配置中；
如何完成 。istio需要编写一个为pod自动注入envoy容器的initializer。
istio会将envoy本身的container的定义以configmap的方式保存在kubernetes中。
configmap（envoy-initializer）定义：data中的config正式一个pod对象的定义。container字段和volumes字段

要将这部分envoy相关字段添加到用户提交的pod的api对象里。kubernetes需要使用patch api来完成这中类似于git merge的操作。才能将两部分代码合并在一起；
将initializer作为一个pod部署在kubernetes中 。这个pod定义：

这个pod配置的envoy-initializer镜像，是一个自定义控制器，他是一个死循环。不断的获取的实际状态就是用户新创建的pod。期望状态就是pod里被添加了envoy的容器的定义；
envoy-initializer会一直获取新创建的 pod。然后获取pod信息。diff一下。检查是否以及高init初始化过。
如果初始化过。就放过这个 pod。进入下一个检查周期；
如果没有初始化。就开始initialize操作；
1.从apiserver中获取configmap
2.将configmap中的container字段和vlumes字段直接添加到一个空的pod对象里；
3.使用kubernetes中的一个api。将新旧我哥pod对象生成一个twoWayMergePatch
4.发起patch请求。initializer的代码就可以加入的新的pod中；这样用户提交的pod对象就被自动加上了envoy容器相关的字段；

额外津贴：这个太大佬操作。还是交给大佬们来做。
kubernetes允许你通过配置来指定要对什么养的资源进行initialize操作
大概的意思是配置一个kind。initializerconfiguration对象。kube会将rules配置的那些pod鞋带上initial的配置加上新的pod上去；

小总结：
以上是关于initializer基本的工作原理。使用方法。大佬处理；这个时候我们要明白。istio项目的核心就是由无数个在pod中运行的envoy容器组成的服务代理网络网格。这也是servicemesh的含义；
这个机制的实现是借助了kube能够对api对象进行在线更新的能力，也正是kube 声明式api的独特之处；

1.声明式是指只需要调一个定义好的api对象来声明我所期望的状态；
2.声明式api允许多个api写。以patch的方式对api进行修改。而无需关心本地原始的yaml文件的内容；
3.尤其是需要注意的是。在kube中不止用户会修改api对象 。kube本身和插件比如hpa也会修改api对象。这里必须能够处理冲突，在kube中这个能力已经内置到了apiserver中叫做：server side apply
4.最后。有了上述的能力，kube才可以基于对api对戏那个的curd。在完全无干预的情况下完成对实际状态和期望状态的调协；