k8s的对象管理I(命令式和声明式API)

官方文档：https://kubernetes.io/docs/concepts/overview/working-with-objects/object-management/

　　　　　https://kubernetes.io/docs/tasks/manage-kubernetes-objects

k8s在管理对象(增删改查资源)时可以有如下三种方式

1.几个关键的概念

object configuration file / configuration file: A file that defines the configuration for a Kubernetes object. 使用的时候会pass configuration files tokubectl apply. Configuration files are typically stored in source control, such as Git. 点评: 重点在于他就是一个文件，一各定义object的用户写的文件。
live object configuration / live configuration: The live configuration values of an object, as observed by the Kubernetes cluster. These are kept in the Kubernetes cluster storage, typically etcd.点评:重点在于他是object的'属性'值，且这些'属性'值是k8s集群生成，存储在集群中的。
declarative configuration writer / declarative writer: A person or software component that makes updates to a live object. The live writers will make changes to object configuration files and runkubectl applyto write the changes. 点评: 重点在于他是应用于声明式场景中，表示将被应用到object，从而去改变某些'属性'.

2`方式一：命令式命令(Imperative commands)

顾名思义，首先，他是以下发命令的形式(Imperative)直接操作object，即我命令(run/create/replace)xxx做什么什么....

然后，命令的对象是Live object，通过命令的方式(commands)直接指定，即直接在命令行中指定是deployment还是什么，也包括一些参数则用flag

最后，被操作的的对象具体变成什么样子则交给系统了

特点：1)仅需一步就对集群做了修改

例子：创建一个deployment类型的object

kubectl run nginx --image nginx

或 kubectl create deployment nginx --image nginx

# kubectl run nginx --image nginx
kubectl run --generator=deployment/apps.v1beta1 is DEPRECATED and will be removed in a future version. Use kubectl create instead.
deployment.apps/nginx created
# kubectl get deployment |grep nginx
nginx 1 1 1 0 32s

# kubectl get pods|grep nginx
nginx-dbddb74b8-qt7zv 0/1 ImagePullBackOff 0 86s

命令：

1)创建object，例如run(表示要run一个pod,缺省会创建deployment)， create：创建指定类型的object，比如deployment

2)更新object，例如edit(直接编辑一个live object的raw configuration)， patch: 直接改live object。。。。。

3)删除object, 例如delete

4)查看pbject，例如get，describe，logs等

方式二：对象配置式命令(Imperative object configuration)

顾名思义，首先，同样是下发命令(Imperative)，即我命令(create/replace...)xxx做什么什么....

但是，命令的对象是Individual files(一个文件)，文件中的内容是a full definition of the object in YAML or JSON format；整个命令可以指定多个文件，但是每个文件都是独立的，相当于两条独立的操作放在一条命令中，并不会将多个文件合并再操作。

最后，被操作的的对象会被系统按照配置文件进行具体操作了

特点：1)只能指定文件名称，不可以是目录

2)可以将想要做的事情以文件的形式存放，方便管理(比如执行前检查，比如放到git上等)

3)在使用replace命令的时候需要特别注意： replace命令会将当前obeject的spec完全替换成新的，所谓完全替换意味着会dropping all changes to the object missing from the configuration file(wxy: 意思应该是说如果object已经存在某些spec，但是新配置文件中没有这方面的信息，那么就直接将这些参数去掉，也就是'全方位的替换')。另外，这种方式不要用在那些spec的更新不依赖配置文件的资源类型中，比如LoadBalancer类型的Services，他的externalIPs字段是由对应的LoadBalancer所更新(wxy:不知道如果就用了会怎样？)

???? 4) 使用create, replace和delete命令时，如果定义的object' configuration已经被记录到object的configuration里面了，则啥也不会发生；但一旦一个live object被update但还没来及merge到configuration file中，则如果此时有replace操作，那么上一次update操作丢失，即

1)根据用户定义的configuration文件创建新资源

2)一个update操作来了

3)又一个带着新configuration的replace请求来了，那么2)中的update将会lost

例子：

#将在这两个文件中定义的object删除 kubectl delete -f nginx.yaml -f redis.yaml

命令：

除了run?其余和命令式命令相同？

方式三：声明式对象配置(Declarative object configuration)

https://kubernetes.io/docs/tasks/manage-kubernetes-objects/declarative-config/

顾名思义，首先，只是声明(Imperative)一下，即我想要我的object什么什么样子都定义在配置文件中了；

并且，操作的对象是Directories of files(多个文件)，所谓的动作就是apply;

最后，kubectl会根据情况自动检测出针对某个object具体是执行什么动作(create,update,delete)。

例子：

1.当没有这个资源的时候，apply操作会创建对应的资源， # kubectl apply -f ./ 2.查看该资源的live configuration，发现如下： 1)生成annotations: kubectl.kubernetes.io/last-applied-configuration，将configuration file的内容完整记录下来了中记录了完整的 2)configuration file中没有指定replicas的信息，于是生成后为缺省值1 # kubectl get deployment nginx-deployment -oyaml # kubectl get -f ./simple_deployment.yaml -oyaml apiVersion: apps/v1 kind: Deployment metadata: annotations: deployment.kubernetes.io/revision: '1' kubectl.kubernetes.io/last-applied-configuration: | {'apiVersion':'apps/v1','kind':'Deployment','metadata':{'annotations':{},'name':'nginx-deployment','namespace':'default'},'spec':{'minReadySeconds':5,'selector':{'matchLabels':{'app':'nginx'}},'template':{'metadata':{'labels':{'app':'nginx'}},'spec':{'containers':[{'image':'nginx:1.14.2','name':'nginx','ports':[{'containerPort':80}]}]}}}} creationTimestamp: 2020-05-03T08:46:37Z spec: minReadySeconds: 5 progressDeadlineSeconds: 600 replicas: 1 3.使用命令式命令的方式扩容为2 # kubectl scale deployment/nginx-deployment --replicas=2 4.此时并不会更改kubectl.kubernetes.io/last-applied-configuration的内容，因为他就是记录的apply的configuration file的内容 # kubectl get deployment nginx-deployment -oyaml ... annotations: deployment.kubernetes.io/revision: '1' kubectl.kubernetes.io/last-applied-configuration: | {'apiVersion':'apps/v1','kind':'Deployment','metadata':{'annotations':{},'name':'nginx-deployment','namespace':'default'},'spec':{'minReadySeconds':5,'selector':{'matchLabels':{'app':'nginx'}},'template':{'metadata':{'labels':{'app':'nginx'}},'spec':{'containers':[{'image':'nginx:1.14.2','name':'nginx','ports':[{'containerPort':80}]}]}}}} creationTimestamp: 2020-05-03T08:46:37Z ... replicas: 2 5.更改configuration file的内容，删除一项，修改一项 # vi ./simple_deployment.yaml minReadySeconds: 5 ---删除 image: nginx:1.16.2 ---修改 6.重新执行声明式命令，然后查看live configuration，发现如下的改变 1)kubectl.kubernetes.io/last-applied-configuration随着配置文件变更而变更 2)live configuration被以patch的方式进行修改，即：以configuration file为基准修改，他没提到的保持不变 # kubectl apply -f ./ # kubectl get deployment nginx-deployment -oyaml ... annotations: deployment.kubernetes.io/revision: '2' kubectl.kubernetes.io/last-applied-configuration: | ---被刷新 {'apiVersion':'apps/v1','kind':'Deployment','metadata':{'annotations':{},'name':'nginx-deployment','namespace':'default'},'spec':{'selector':{'matchLabels':{'app':'nginx'}},'template':{'metadata':{'labels':{'app':'nginx'}},'spec':{'containers':[{'image':'nginx:1.16.2','name':'nginx','ports':[{'containerPort':80}]}]}}}} creationTimestamp: 2020-05-03T08:46:37Z ... replicas: 2 ----保持不变 ... - image: nginx:1.16.2 ----被修改

实现原理：

核心思想是apply命令使用的是patch API，该API可以认为是一种update操作，操作的范围是object的指定字段而不是整个object，具体的工作步骤如下

1.kubectl apply命令(即kubectl)计算patch请求， 计算步骤如下：

1)计算哪些字段需要被删除：last-applied-configuration中有的，但是新配置文件(configuration file)中没有的

2)计算哪些字段需要添加或者设置的：新配置文件(configuration file)中有，但是与live configuration中的值不匹配(比如没有，或者值不同)

3)设置一个新的last-applied-configurationannotation，使其值与配置文件(configuration file)匹配

4)将上述 1) 2） 3)得到的结果进行融合，最终得到一个信息的patch请求，并发往API server

2.向patch API发送请求。

请求中存放的是'差别'信息，然后API Server会将这些“差别信息”与该object 的live configuration进行合并，合并的过程中，会因为字段的类型不同，而有不同的处理方式：

1)原生类型：比如string, integer, or boolean，则直接替换处理；

2)map(也称为object)类型：则将其元素或子字段进行合并处理；

3)list类型：list中的条目可以是原生类型或map类型，则根据1) 和2)分别处理。

另: 更详细的处理细节参考官网

特点：

1)使用kubectl apply命令被称为'managed bykubectl apply'，原因为这是一个管理的命令，包含了create/update/delete操作

2)声明式对象配置会retains changes made by other writers, even if the changes are not merged back to the object configuration file. 这是因为这种方式使用的是patchAPI，这种操作只会写入observed differences, 而不似replaceAPI 那般，直接替换整个object的配置文件。

3) 不支持与命令式配置文件方式混合使用，这是因为后者的create和replace操作没有kubectl.kubernetes.io/last-applied-configuration，而这却恰恰是apply赖以生存的部分。

经试验发现，使用create创建，使用apply修改也是可以的，后者的操作会为object的live configuration增加该annotation，只不过会爆出警告，如下：

//1.命令式创建object, 此时是没有annotation的 # kubectl create -f ./simple_deployment.yaml 或 # kubectl create deployment nginx-deployment --image nginx //2.经过apply，尽管会报错，但仍会添加annotation，且参数也会依照object configuration file而变更 # kubectl apply -f ./ Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply deployment.apps/nginx-deployment configured

4）关于删除那些'managed bykubectl apply'的object：推荐直接使用命令式命令的方式删除，

也可以使用声明式本身的删除方式：kubectl apply -f <directory/> --prune -l your=label

=================================