Pod控制器

1. plicaSet控制器

ReplicaSet（RS）是控制器类型中的一种，主要用来确保受管控pod对象的副本数量在任何时刻都满足期待值。

与手动创建和管理Pod对象相比，ReplicaSet可以实现以下功能：

• 可以确保Pod的副本数量精确吻合配置中定义的期望值。
• 当探测到Pod对象所在的Node节点不可用时，可以自动请求在其他Node节点上重新创建新的Pod，以确保服务可以正常运行。
• 当业务规模出现波动时，可以实现Pod的弹性伸缩。

Kubernetes官方建议避免直接使用RS，推荐通过Deployment来创建RS和Pod。

2. deployment控制器

2.1 通过deployment部署nginx

1）创建并编辑Deployment描述文件

vim dp-nginx.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-deployment
 labels:
  app: nginx
spec:
 replicas: 3
 selector:
  matchLabels:
   app: nginx
 template:
  metadata:
   labels:
    app: nginx
  spec:
   containers:
   - name: nginx
     image: nginx:1.7.9
     ports:
     - containerPort: 80

上述文件中，设置了replicas的值（副本数量）为3；

• metadata.name字段表示此Deployment的名字为nginx-deployment
• spec.replicas字段表示将创建3个配置相同的Pod
• spec.selector字段定义了通过matchLabels方式选择这些Pod

2）创建部署nginx-deployment

kubectl create -f dp-nginx.yaml

3）查看Deployment状态

kubectl get deployment

通过READY的值可以看到Deployment已创建好了3个最新的副本。

4）查看相关RS和Pod信息

kubectl get rs

kubectl get pods

上面所床架的Pod由系统自动完成调度，它们各自运行在哪个节点上，由Master的Scheduler组件通过一系列的算法计算得出，用户无法干预调度过程和结果。

2.2 Pod升级

当集群中某个服务需要升级时，一般情况下需要先停止与此服务相关的Pod，然后下载新版的镜像和创建Pod，这种先停止再升级的方式在大规模集群中会导致服务较长时间不可用，而Keburnets提供滚动升级功能，以解决此问题。

滚动升级（Rolling update）：每次更新部分Pod，而不是在同一时刻将该Service下面的所有Pod shutdown，然后去更新，逐个更新可以避免将业务中断。

用户在运行时修改Deployment的Pod定义（spec.template）或镜像名称，并将其应用到Deployment上，系统即可完成自动更新。

下面将演示将nginx pods的镜像从nginx:1.7.9更新为nginx:1.9.1版本：

1）更改镜像名称或Pod定义

1. kubectl --record deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1

2. kubectl set image deployment/nginx-deployment nginx=nginx:1.91 --record

3. kubectl edit deployment.v1.apps/nginx-deployment

   

   

以上三条命令都可以就镜像的版本从nginx:1.7.9更改为nginx:1.9.1。

特别的：使用命令3. 是编辑Pod定义文件从而修改镜像版本，如上图。

当镜像名称或Pod定义发生改变时，系统会发出相关指令对Deployment创建的Pod进行滚动更新。

2）查看Deployment的更新过程

kubectl rollout status deployment.v1.apps/nginx-deployment

3）查看Pod的状态

kubectl get pods

4）查看Pod使用的镜像

kubectl describe pod dp-nginx-784b7cc96d-74db2

根据镜像的版本和时间的提示可以看出Pod的镜像已经更新为nginx:1.9.1

可以通过kubectl describe deployment/nginx-deployment命令查看更加详细的事件信息。

2.3 Deployment回滚

如果在更新过程中出现了错误，还可以回滚到先前的Pod版本。

为了演示Deployment更新出错的场景，这里在更新Deployment时将nginx镜像设置为nginx1.91（这是一个不存在的版本），并通过rollout命令进行升级操作，如下：

1）更改nginx镜像的版本

kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true

2）查看Deployment更新的过程

kubectl rollout status deployment.v1.apps/nginx-deployment

因为使用的是不存在的镜像，系统无法进行正确的镜像升级，会一直处于Waiting状态。

3）查看系统是否创建了新的RS

先使用Ctrl+C组合键终止此操作，然后执行kubectl get rs

可以看到系统新键了一个名为nginx-deployment-6dd86d77d的RS

4）查看相关Pod信息

因为更新的镜像为不存在的镜像，所以新创建的Pod的状态为ImagePullBackOff

5）检查Deployment描述

在描述信息中可以看到

Replicas：1unavailable，即一个副本不可用

Conditions：NewReplicaSet: nginx-deployment-6f6986d7b6 (1/1 replicas created)，副本集中只创建了一个，因为出现了错误，所以只创建了一个副本，且这个副本不可用。

6）查看Deployment更新历史记录

kubectl rollout history deployment.v1.apps/nginx-deployment

7）回滚版本

使用undo命令撤销本次发布并将Deployment回滚到上一个部署的版本。

kubectl rollout undo deployment.v1.apps/nginx-deployment

8）查看描述信息

kubectl describe deployment nginx-deployment

可以看到最后一个事件是“Normal ScalingReplicaSet 2m36s (x2 over 108m) deployment-controller Scaled down replica set nginx-deployment-6f6986d7b6 to 0”，表示Deployment已经执行了回滚操作。

3. StatefulSet控制器

集群中Zookeeper、Elasticsearch、MongoDB、Kafka等有状态的节点都有明确不变的唯一ID号（主机名或IP地址），这些节点的启动和停止也需要遵循严格的顺序。这些节点重启时，都需要挂载原来的数据卷。为此，可以使用StatefulSet来管理这些有状态的应用。

StatefulSet的主要特点如下：

• 具有稳定且唯一的网络标识。例如，创建一个名为MySQL的StatefulSet，第一个Pod的名字为MySQL-0，第二个为MySQL-1，以此类推。
• 可以实现稳定且持久的存储。删除Pod不会删除对应的存储卷。
• 可以有序地进行部署和更新操作，且启动顺序是受控的，当操作第n个Pod时，前n-1个Pod已经运行且处于准备状态。

4. DaemonSet控制器

当需要再Node节点上收集日志或进行主机性能采集时，可以使用DaemonSet控制器在每个Node节点上创建一个Pod副本进行资源的收集，如下图所示：