Deployment设计理念

Deployment对象控制Replicaset（RS）的版本，而Replicaset控制集群中Pod的数量

比如管理员想维持某个服务（service）的Pod数量在5个，希望有个东西能帮管理员去实时监控副本的数量，如果少于5个就创建，多了就删除。但实际不是Deploment在控制数量，而是他控制的Replicaset（RS）这个东西在去控制Pod数量。

Deploment的配置：

apiVersion: apps/v1
kind: Deployment   
metadata:   # Deployment元信息
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3  # 期望Pod数量
  selector:   #  Pod的选择器
    matchLabels:
      app: nginx
  template:  # 以下是Pod的模板
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx:1.7.9
      ports:
      - containerPort: 80

常见操作

更新镜像

kubectl set image deploment.v1.apps/deployment 名称 要更新的Container名=新的镜像名

回滚

kubectl rollout undo deployment deploym的名称

修改副本数

kubectl scale deploy nginx --replicas 5

查看历史版本

kubectl rollout history deploy nginx --revision=X “X”为第几个版本，没有的话可以通过–revision=N来查看所有历史记录

Deploy更新策略

• 在spec.strategy中定义更新策略，两种方式：
  Recrete ： 重建 干掉所有Pod，再重新生成，完成更新

• RollingUpdate： 滚动 滚动更新Pod 可以指定 spec.strategy.rollingUpdate.maxUnavailable用于指定更新过程中不可用状态的Pod数量的上限；spec.strategy.rollingUpdate.maxSurge用于指定更新过程中Pod总数量超过期望数量的部分的最大值

其它类别Pod控制器

job ，cronjob，DaemonSet都是直接管理Pod的

1.job

可以理解为批处理任务，一批一批的去执行，设置失败次数。restartPolicy控制失败策略，backoffLimit控制重试次数

2.cronjob

定时执行，计划任务，Schedule定义时间；startingDeadlineSeconds定义job最长运行时间；concurrencyPolicy是否并行运行；

3.DaemonSet

每个节点都运行一个相同的Pod

4.StatefulSet

比如主从数据库启动顺序是需要先主后从

• 每个节点有固定的身份ID，是按数字升序定义，不包含随机字符，成员通过ID相互发现与通信
• 集群规模规定，不能随意变更
• 每个节点都是有状态的，会持久化数据到永久存储中，每个节点重启后都是用之前用到的数据
• 节点的启动与关闭顺序通常也是有序的

HPA横向自动扩容

因为不可能人工去看每个机器的资源变化，所以会通过跟踪分析指定Deployment控制的所有目标的Pod的负载变化情况，确定是否需要针对的调整目标Pod的副本数量，自定义HPA是根据CPU的使用率或者Memory（内存）使用率来判断扩/缩容与否。比如Prometheus也会去监控机器资源的使用情况，得到了Metrics指标情况之后再根据一定的逻辑，来转化成Replicas的实时数量，不断地去监控就会不断地去调整，以此实现自动扩容或者缩容 。

VPA垂直扩缩容

相对HPA，自动配置Pod的资源请求，降低运维成本（根据Pod运行的历史数据和实施资源情况，使用推荐模型，计算Pod推荐使用资源值，再更新Pod的资源配置或者驱逐Pod）