Pod控制器
分类
ReplicaSet
场景
示例
Deployment
滚动更新(灰度发布)
自定义滚动更新方式
示例
Kubernetes实现滚动发布以及回滚流程
金丝雀发布
Pod控制器
对于Kubernetes来讲，API Server整个系统的GATEWAY，并且它还是一个Restfull系统，它把我们整个系统所管理内容通通抽象成Resources，这也是Restfull风格的特性，Pod控制器就是一个Resources，而我们创建出来的每一个具体的Pod就是一个Object，API Server为整个Kubernetes的数据管理提供了一种数据范式，所有存取于API Server的数据，都必须遵循于Resources这样的一个规范，比如我们需要创建一个Pod时候，应该在Pod上调用哪个属性，给哪个值，所有的数据都保存在etcd当中，保存进来的数据要被构建为Kubernetes上面的活动对象，而活动对象的状态究竟该成为什么样的结构，则取决于各种各样的Controller，Controller去负责创建修改各Live Object，活动对象创建时，它的基本标准是由存储于etcd存储的用户所定义出来的对象，所以etcd当中，我们称为用户期望的对象，Controller从中取出来用户所期望的标准，负责给它创建在当前集群之上，成为活动对象，并且Controller还要负责通过和解循环Reconcilation Loops，确保在每一个时刻Live Objects要与用户所定义的Objects要保持一致，换句话说Reconcilation Loops要保证，status里面的状态要和spec里面的状态保持一致，status由Controller负责维护，而spec由我们的用户负责维护；
整个Kubernetes系统，控制器有很多，控制Pod叫做Pod控制器，控制Service的叫做Service控制器，控制节点的也有节点控制器，因为Kubernetes集群中的任何一个对象，都得确保它的status中的实际状态要吻合于spec当中用户所期望的状态，所以在Kubernetes上来讲，控制器有很多类型，分别用于控制不同的资源，但是并不是每一个类型都必须有一个控制器，而是每一个类型可以有多个控制器，同时，一个控制器也可以控制多个资源，他们彼此之间没有一一对应的关系，但是基础资源类型通常都有同名控制器，目前来将Kubernetes上面的内建控制器，大概有四十多种；
然后每一个类型的控制器，还可以创建出多个控制器对象来，和Pod很像，Pod是一种资源类型，真正把Pod创建出来，我们称之为资源对象，同样的道理，Pod Controller里面也有多个类型，比如一个基本类型，ReplicaSet，通过这个类型，我们可以通过这个类型创建出多个对象来，所以说每一种Controller控制器也是一个Resources，可以实例化出多个Controller Object；
还有每一个控制器内部都有一个Control Loop叫控制循环，也称之为和解循环，如果这个循环能周期性运行的话，通常意味着其背后必须有一个守护进程，来确保每一个Controller Object的内部的和解循环可以实时运行，因此基本上来讲，每一种类型的控制器组合起来，背后一定得有一个守护进程来确保这一类进程当中的的所有控制器对象中的和解循环能正确运行，所以为了确保ReplicaSet的所有控制器对象可以正常运行起来，其背后得有一个ReplicaSet Daemon，但是这么一来就麻烦了，四十多个控制器得有四十多个后台进程，这就比较麻烦了，那为了避免每一个控制器被单独运行，所以Kubernetes采用了一种精巧的方式去阻止他，把所有的控制器的代码打包成一个，只运行为一个统一的守护进程，它被称为kube-controller-manager，Kubernetes内部的四五十种控制器的和解循环的实现，都由kube-controller-manager来实现，因此随后创建的Controller都会在它的维护下，来确保控制器的正常运行；
Pod控制器用来控制Pod，Pod不健康了由Pod控制器来进行销毁重建，Pod控制器也有内部的和解循环， Pod控制器由控制器来控制， Pod控制器不健康了由控制器管理器的守护进程来进行Pod控制器进程重建，而我们的控制器管理器是可以高可用的，如果用户不需要这个Pod控制器的话，那么也会自动将Pod控制器下面的Pod对象删除掉；
黄色的控制器是Pod控制器，其他的是其他资源的控制器，这些才是Kubernetes背后的资源管理大脑，所以整个Kubernetes的各种高级功能都是借助于Contrller完成的，对于Contrller来讲，它们才是真正的确保任务编排系统之所以成为编排系统的核心组件，因为编排任务当中的比如像自动创建、自动恢复等等高级功能，基本都是依赖于Contrller完成的，所以从某种意义上来讲，Contrller如果复杂一点的话，我们甚至可以把它称为运维器或者操作器；
那么对于kube-controller-manager来讲，它是整个Kubernetes控制平面一个非常重要的守护进程，其实Kubernetes每一个守护进程都可以通过配置选项来配置，只不过我们在此之前将其运行成为了一个Pod，如果我们期望自定义kube-controller-manager控制器里面的各种类型是否被启用，可以在启动这个进程时，通过--controllers来指定要启用的控制器，默认是*；
内部控制器有attachdetach, bootstrapsigner, certificatesigningrequests, cronjob, daemonset, deployment, disruption, endpoint, garbagecollector, horizontalpodautoscaling, job, namespace, node, persistentvolume-binder, podgc, replicaset, replicationcontroller, resourcequota, route, service, serviceaccount, serviceaccount-token, statefuleset, tokencleaner, ttl；
两个独特的控制器，不包含在默认启动当中，bootstrapsigner和tokencleaner，如果需要用就需要单独的启动；
在使用kubeadm安装kube-controller-manager的时候，默认配置文件地址：/etc/kubernetes/manifests/kube-controller-manager.yaml 修改完成之后不需要重启，会自动重建；
我们用户不应该手动去创建Pod，而应该由Pod控制器来创建，之所以如此是因为Pod控制器是建立在基础资源之上的更进一步的抽象，Kubernetes之所以能够自动编排，是完全依赖于控制器来实现的，因此我们应该创建控制器对象来管理这些基础资源类型，Pod控制器是只是一种统称，早期的Kubernetes版本只有一种控制器，ReplicationController，现在这一个控制器被划分为多种类型，第一种叫守护进程型，守护进程型，又可以分为有状态应用，和无状态应用，第二种非守护进程型，例如备份任务；
分类
守护进程型：
无状态：
非系统级：Deployment ReplicaSet
系统级：DaemonSet
有状态：
SataefulSet
非守护进程型：
Job
CronJob
ReplicaSet
主要用来控制非系统级的无状态守护进程的应用，比如Nginx、tomcat、haproxy都可以，但是MySQL不行，因为它是有状态应用，对于ReplicaSet来讲，它就是就是对那些无状态应用确保用户所期望存在的某一种无状态应用的Pod能够精确反应用户所定义的运行状态的Pod数量，任何一个Pod出现故障都可以被其他新的Pod所取代，而对于Pod控制器来将，它需要根据你创建Pod时候的模版去定义新Pod的运行方式，所以一个ReplicaSet控制器至少2个部分组成Pod模版、Pod 标签、Pod数量；
[root@node1 cce]# cat rs-example.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: cce-rs
namespace: cce
spec:
replicas: 3
selector:
matchLabels:
app: web
template:
metadata:
name: ccecontainer
labels:
app: web
spec:
containers:
- imagePullPolicy: IfNotPresent
image: ikubernetes/myapp:v1
name: cce
[root@node1 cce]# kubectl apply -f rs-example.yaml
[root@node1 cce]# kubectl get replicasets.apps -n cce -o wide
NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR
cce-rs 3 3 3 2m56s cce ikubernetes/myapp:v1 app=web
[root@node1 cce]# kubectl describe replicasets.apps -n cce cce-rs
Name: cce-rs
Namespace: cce
Selector: app=web
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"apps/v1","kind":"ReplicaSet","metadata":{"annotations":{},"name":"cce-rs","namespace":"cce"},"spec":{"replicas":3,"selector...
Replicas: 3 current / 3 desired
Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
Labels: app=web
Containers:
cce:
Image: ikubernetes/myapp:v1
Port: <none>
Host Port: <none>
Environment: <none>
Mounts: <none>
Volumes: <none>
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulCreate 4m49s replicaset-controller Created pod: cce-rs-4gv29
Normal SuccessfulCreate 4m49s replicaset-controller Created pod: cce-rs-c4q7q
Normal SuccessfulCreate 4m49s replicaset-controller Created pod: cce-rs-7jhh
场景
当我们使用ReplicaSet控制器之后，第一个版本上线了那么几天之后想上一个新版本，那么此时修改方式有两种，第一种直接修改对应的yaml模版里面的镜像，然后重新apply；
示例
直接修改yaml模版文件；
[root@node1 cce]# cat rs-example.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: cce-rs
namespace: cce
spec:
replicas: 3
selector:
matchLabels:
app: web
template:
metadata:
name: ccecontainer
labels:
app: web
spec:
containers:
- imagePullPolicy: IfNotPresent
image: ikubernetes/myapp:v2 # 修改版本号
name: cce
[root@node1 cce]# kubectl apply -f rs-example.yaml
replicaset.apps/cce-rs unchanged
[root@node1 cce]# kubectl get rs -n cce -o wide
NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR
cce-rs 3 3 3 20m cce ikubernetes/myapp:v2 app=web # 查看镜像
[root@node1 cce]# kubectl get pods -n cce -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
cce-rs-4gv29 1/1 Running 0 20m 10.244.2.5 node3.cce.com <none> <none>
cce-rs-7jhhc 1/1 Running 0 20m 10.244.1.4 node2.cce.com <none> <none>
cce-rs-c4q7q 1/1 Running 0 20m 10.244.2.4 node3.cce.com <none> <none>
[root@node1 cce]# curl 10.244.1.4
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a> # 访问测试，还是v1版本
Deployment
可以看到上述例子我们apply之后还是v1版本，因为rs自己并不确保用户每一次更新操作都能反应给实际需求，定义完成之后只是控制器变了，这从另一个角度来讲也是一种安全策略，这种情况下，老的Pod不会自动更新版本为v2，而创建的新版本则会使用v2的yaml文件，已有的它是不动的。所以在rs下要想真正更新Pod有几种办法，要么把原来的Pod手动删除，它一定会根据新模版重建的，第二个办法可以一次删一个这一个重建完成之后再删第二个重建完成之后再删除第三个，这也就是所谓的滚动更新，或者说是灰度发布，但是因为Pod的会实时收到监控，一旦数量少于预定义的数量就会创建，因此就需要使用先加后减的策略进行，先加后减是确保当前的可用节点数量，但是如果这样的话，就比较繁琐，那么我们的Kubernetes就专门提供了一个控制器来负责，完成此类功能，它被称为Deployment，也就意味着在Kubernetes之上我们不应该人为去手动使用ReplicaSet存在的目的，只是用来管理底层Pod的，但我们用户来管理的是Deployment，Deployment负责由Controller来管理RS，RS负责管理Pod，它能利用RS功能帮用户完成各种操作，比如版本升级，回滚，灰度发布，金丝雀发布等。
灰度发布其实就是滚动发布，删一个加一个，真正做到了滚动发布，金丝雀发布，使用Deployment去发布时，使用的是先加后减的方式，但是对于金丝雀发布只加不减，新老版本并存，暂停了，我们可以使用路由策略把一部分用户量不大的区域的流量放到新的Pod里面，而用户量比较大的地区还是使用老版本的Pod，而这一切在Dployment上，都可用自动进行，你只需要告诉它更新一批并且暂停下来，那就是金丝雀，如果需要实现流量调度，Kubernetes目前默认提供的组件还没这个能力，需要借助其他的网络组件实现，Deployment还有一个另外一个功能，就是回滚，回滚到指定版本的Pod，Deployment的实现方式是将历史Pod进行保留不进行删除，必要的时候能够基于历史Pod进行回滚，默认保留十个版本，而现在应该是保留所有，而且对于回滚，它还是灰度的，一次删一个删除完成之后再重建一个，依次循环，更何况假如我们6个Pod你要删一个再建立一个删一个建立是需要时间的，但是我们的Pod的副本数量是至少6个那就会控制器立即增加一个，这就不符合我们的使用需求，所以这个场景下我们得告诉我们的控制器暂停创建，由用户自行创建，所以我们发布是时候有两种形式，第一种是先删后加，然后是先加后删，但是这些我们手动无法控制，于是Kubernetes专门提供了一个控制器，来帮我们完成此类操作，它被称为Deployment，所以说ReplicaSet不应该是我们直接使用的，ReplicaSet存在的目的只是为了管理底层的Pod；
对于我们用户应该使用的是Deployment，Deployment负责由控制器来管理ReplicaSet，ReplicaSet来管理Pod，所以Deployment是一个更高级的功能，它能利用ReplicaSet的功能帮我们完成各种更新策略；
而且Deployment在管理ReplicaSet也会中间加一组名字，比如Deployment叫myapp，那它的第一版ReplicaSet可能叫myapp-5t6asd，后面这个字符串是当前所拥有的RS的模版的hash码计算得来的，因为只要ReplicaSet模版变了，那它的hash码也肯定会变，因此它使用这个hash码来引用ReplicaSet，而ReplicaSet下面会创建多个Pod，这个Pod的名字可能会是myapp-5t6asd-asd213sa名字中的5t6asd是ReplicaSet的名字，后面是Pod是Podhash值；
Deployment是ReplicaSet的一个升级版，可以进行升级或者回滚详细进度和状态查询，当升级Pod的时候如果出现问题，可以使用回滚操作回滚到之前的任一版本，每一次对Deployment的操作，都能够保存下来，这也是保证可以回滚到任一版本的基础，对于每一次升级都能够随时暂停和启动。而ReplicaSet是RS（Replication Contorller）的升级版本他的主要功能是确保Pod数量，确保Pod健康，弹性伸缩，滚动升级(灰度发布)；
滚动更新(灰度发布)
此处使用set image的方式来实现滚动更新操作，我们也可以修改yaml模版文件，使用apply重新应用；
apiVersion: apps/v1
kind: Deployment
metadata:
name: repod
namespace: cce
labels:
app: relabel
spec:
replicas: 3
selector:
matchLabels:
app: web
template:
metadata:
name: ikubernets
namespace: cce
labels:
app: web
annotations:
author: caichangen
spec:
restartPolicy: Always
containers:
- name: repodbackend
image: ikubernetes/myapp:v1
imagePullPolicy: IfNotPresent
修改完成之前
测试修改镜像版本
[root@node1 cce]# kubectl set image -f test.yml repodbackend=ikubernetes/myapp:v2
deployment.apps/repod image updated
修改完成后，可以查看到期望版本是0，当前版本也是0，自动完成滚动升级
自定义滚动更新方式
我们的Deployment可以用户自定义一次加几个，删几个依次循环；
[root@node1 cce]# kubectl explain deployment.spec.type #定义滚动类型，指定新的Pod替换旧的Pod的策略
Recreate：删除一个建立一个，在创建出新的Pod之前会先杀掉所有已存在的Pod；
RollingUpdate：Deployment使用rolling update 的方式更新Pod 。您可以指定maxUnavailable 和 maxSurge 来控制 rolling update 进程；
[root@node1 cce]# kubectl explain deployment.spec.strategy # 当类型为RollingUpdate的时候strategy才会有效，主要用于定义滚动更新的Pod数量的上下限；
maxUnavailable：期望是6个但是最多在滚动更新的过程当中能低于期望数量2个，那也就意味着我们最少有4个可用，它的值可以是一个百分数，也可以是一个整形；
maxSurge：在滚动更新当中，能够超出用户所期望的数量，比如用户期望是6个，设置maxSurge为2代表，允许在滚动更新的时候，多出2个，它表示最多多出几个，它的值可以是一个百分数，也可以是一个整形；
示例
设定滚动更新方式
[root@node1 cce]# cat test.yml
apiVersion: apps/v1
kind: Deployment
metadata:
name: repod
namespace: cce
labels:
app: relabel
spec:
replicas: 3
selector:
matchLabels:
app: web
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 0
maxSurge: 3
template:
metadata:
name: ikubernets
namespace: cce
labels:
app: web
annotations:
author: caichangen
spec:
restartPolicy: Always
containers:
- name: repodbackend
image: ikubernetes/myapp:v1
imagePullPolicy: IfNotPresent
开始应用
[root@node1 cce]# kubectl apply -f test.yml
deployment.apps/repod created
修改镜像
[root@node1 cce]# kubectl set image -f test.yml repodbackend=ikubernetes/myapp:v2
deployment.apps/repod image updated
查看滚动更新的Pod创建批次，此时是一次创建3个，符合我们的预定义
[root@node2 ~]# kubectl get pods -n cce
NAME READY STATUS RESTARTS AGE
repod-649c59bb-kjxfk 0/1 ContainerCreating 0 1s
repod-649c59bb-n89fz 0/1 ContainerCreating 0 1s
repod-649c59bb-ww7dd 0/1 ContainerCreating 0 1s
repod-7b455d5567-f4pdl 1/1 Running 0 11s
repod-7b455d5567-g6dhk 1/1 Running 0 11s
repod-7b455d5567-jgqnt 1/1 Running 0 11s
查看滚动更新的Pod销毁批次，此时是一次删除3个，符合我们的预定义
[root@node2 ~]# kubectl get pods -n cce
NAME READY STATUS RESTARTS AGE
repod-649c59bb-kjxfk 1/1 Running 0 3s
repod-649c59bb-n89fz 1/1 Running 0 3s
repod-649c59bb-ww7dd 1/1 Running 0 3s
repod-7b455d5567-f4pdl 1/1 Terminating 0 13s
repod-7b455d5567-g6dhk 1/1 Terminating 0 13s
repod-7b455d5567-jgqnt 1/1 Terminating 0 13s
Kubernetes实现滚动发布以及回滚流程
第一个版本上线
[root@node1 cce]# kubectl apply -f test.yml --record=true # 使用--record可以在查看历史的时候查看此次记录
第二个版本上线
[root@node1 cce]# kubectl set image -f test.yml repodbackend=ikubernetes/myapp:v2 --record=true # 使用--record可以在查看历史的时候查看此次记录
第三个版本上线
[root@node1 cce]# kubectl set image -f test.yml repodbackend=ikubernetes/myapp:v3 --record=true # 使用--record可以在查看历史的时候查看此次记录
查看当前版本
[root@node1 cce]# kubectl get deployments.apps -n cce -o wide
NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR
repod 3/3 3 3 3m10s repodbackend ikubernetes/myapp:v3 app=web
查看历史版本
[root@node1 cce]# kubectl rollout history -f test.yml
deployment.apps/repod
REVISION CHANGE-CAUSE
1 kubectl apply --filename=test.yml --record=true
2 kubectl set image repodbackend=ikubernetes/myapp:v2 --filename=test.yml --record=true
3 kubectl set image repodbackend=ikubernetes/myapp:v3 --filename=test.yml --record=true
回滚到第一个版本
[root@node1 cce]# kubectl rollout undo -n cce deployment repod --to-revision=1
deployment.apps/repod rolled back
监控回滚流程
[root@node2 ~]# kubectl rollout status -n cce deployment repod -w
Waiting for deployment "repod" rollout to finish: 3 old replicas are pending termination...
Waiting for deployment "repod" rollout to finish: 3 old replicas are pending termination...
Waiting for deployment "repod" rollout to finish: 3 old replicas are pending termination...
Waiting for deployment "repod" rollout to finish: 2 old replicas are pending termination...
Waiting for deployment "repod" rollout to finish: 2 old replicas are pending termination...
Waiting for deployment "repod" rollout to finish: 2 old replicas are pending termination...
Waiting for deployment "repod" rollout to finish: 1 old replicas are pending termination...
Waiting for deployment "repod" rollout to finish: 1 old replicas are pending termination...
deployment "repod" successfully rolled out
查看当前版本
[root@node2 ~]# kubectl get deployments.apps -n cce -o wide
NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR
repod 3/3 3 3 6m49s repodbackend ikubernetes/myapp:v1 app=web
注意：对于查看history版本的说明，当版本发生变更的时候，比如此时我们的有v1、v2、v3三个版本，当我们从v3回滚到v1，那么在查看history的时候v1会变更为v4，v1不会出现在history里面
金丝雀发布
如果在滚动更新的时候，第一批更新的时候，先创建，然后不删除，此时的删除会等待，也就是一个更新包括两个操作，删除老的Pod创建新的Pod或者创建新的Pod删除老的Pod，这两种流程，那么对于金丝雀发布它使用的是，创建新的Pod删除老的Pod，所以我们的Kubernetes在此功能上也提供了功能kubectl rollout pause表示暂停，实现新老版本共存；
金丝雀发布的Pod模版
[root@node1 cce]# cat test.yml
apiVersion: apps/v1
kind: Deployment
metadata:
name: repod
namespace: cce
labels:
app: relabel
spec:
replicas: 3
selector:
matchLabels:
app: web
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 2
maxSurge: 2
template:
metadata:
name: ikubernets
namespace: cce
labels:
app: web
annotations:
author: caichangen
spec:
restartPolicy: Always
containers:
- name: repodbackend
image: ikubernetes/myapp:v1
imagePullPolicy: IfNotPresent
应用到Kubernetes
[root@node1 cce]# kubectl apply -f test.yml
查看当前节点
[root@node3 ~]# kubectl get pods -n cce
NAME READY STATUS RESTARTS AGE
repod-7b455d5567-7jrm7 1/1 Running 0 13s
repod-7b455d5567-n5d56 1/1 Running 0 13s
repod-7b455d5567-vnx5p 1/1 Running 0 13s
利用金丝雀发布新版本
[root@node1 cce]# kubectl set image -f test.yml repodbackend=ikubernetes/myapp:v2 && kubectl rollout pause deployment -n cce repod # 此条命令的意思是，先更新镜像版本，然后立即暂停
查看更新流程
[root@node2 ~]# kubectl rollout status deployment -n cce repod
Waiting for deployment "repod" rollout to finish: 1 old replicas are pending termination...
Waiting for deployment "repod" rollout to finish: 1 old replicas are pending termination...
Waiting for deployment "repod" rollout to finish: 1 old replicas are pending termination...
Waiting for deployment "repod" rollout to finish: 1 old replicas are pending termination...
Waiting for deployment "repod" rollout to finish: 1 old replicas are pending termination...
查看最终Pod数量(满足5个就为正确)
[root@node3 ~]# kubectl get pods -n cce
NAME READY STATUS RESTARTS AGE
repod-649c59bb-4njbc 1/1 Running 0 32s
repod-649c59bb-4wjpx 1/1 Running 0 32s
repod-649c59bb-r5rkd 1/1 Running 0 32s
repod-649c59bb-z4sjr 1/1 Running 0 32s
repod-7b455d5567-vnx5p 1/1 Running 0 110s
查看新版本
[root@node3 ~]# curl 10.244.1.68
Hello MyApp | Version: v2 | <a href="hostname.html">Pod Name</a>
查看老版本
[root@node3 ~]# curl 10.244.2.65
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>
现在就实现了金丝雀发布，我们如果有完好的网络组件比如Istios，就可以实现部分用户访问的是新版本，部分用户访问的是老版本；
此时如果有问题，我们可以回滚
[root@node1 cce]# kubectl rollout history deployment -n cce repod
deployment.apps/repod
REVISION CHANGE-CAUSE
1 <none>
2 <none> # 回滚到第二个版本
如果没问题，我们可以继续执行，更新所有Pod
[root@node1 cce]# kubectl rollout resume deployment -n cce repod
注意：在Kubernetes实现金丝雀发布的条件的，必须在Pod的模版里面指明，maxUnavailable和maxSurge一致且小于Pod模版里面的replicas