Kubernetes – Deployment 篇

od 是不健壮的，而且 Pod 本身是没有可再生性的，随时都会挂掉，这时：

• 如果需要 Pod 数目很多，这时就需要 ReplicaSet 控制器来管理

• Pod 是没有再生性的，如果某个 Pod 挂掉后，这就需要控制器自动管理 Pod

replicaSet 目的：

ReplicaSet 的目的是维护一组在任何时候都处于运行状态的 Pod 副本的稳定集合。 因此，它通常用来保证给定数量的、完全相同的 Pod 的可用性

replicaSet 工作原理： replicaSet 通过下面的字段来控制和管理 Pod ：

• 用来识别 Pod 集合的标签选择器

• 标明应该维护的副本个数

• 新创建 Pod 的模板

replicaSet 现在的主要作用：

• 主要被 Deployments 用作协调 Pod 创建、删除和更新的机制。

• 当使用 Deployment 时，不必担心还要管理它们创建的 ReplicaSet。

• Deployment 会拥有并管理它们的 ReplicaSet。

• Deployment 管理 ReplicaSet，并向 Pod 提供声明式的更新以及许多其他有用的功能。

• 使用 Deployment 而不是直接使用 ReplicaSet

注意： 现在推荐使用配置 ReplicaSet 的 Deployment 来建立副本管理机制。

ReplicationController作用:

ReplicationController 确保在任何时候都有特定数量的 Pod 副本处于运行状态。 换句话说，ReplicationController 确保一个 Pod 或一组同类的 Pod 总是可用的。

ReplicationController 工作原理：

• 当 Pod 数量过多时，ReplicationController 会终止多余的 Pod

• 当 Pod 数量太少时，ReplicationController 将会启动新的 Pod

Deployment 控制器以受控速率更改实际状态， 使其变为期望状态。你可以定义 Deployment 以创建新的 ReplicaSet，或删除现有 Deployment。

模板为：

说明：

• deployment.metadata : 表示 deployment 的元数据

• template : 表示 创建 pod 的模板

• replicas : 表示创建pod的副本数

• selector : 表示 Deployment 如何查找要管理的 Pods，也就是通过这个selector来选择管理pod

  • matchLabels : {key,value} 偶对的映射，表示要选择的标签

  • 注意：这里的标签一定要和 Pod 的标签一致，这样才可以匹配并且管理

上面的 yaml 文件，也可以通过命令行生成：(通过 –dry-run 重定向)

kubectl create deployment web1 --image=nginx --replicas=6 --dry-run=client -o yaml > web-deployment.yaml

1. 查看 deployment ：

• kubectl get deployments.apps

• -o wide 选项，查看详细信息

2. 查看 Deployment 上线状态

• kubectl rollout status deployment web1

3. 查看 Pod 自动生成的标签

• kubectl get pods --show-labels

两种方式修改 deployment 的副本数：

1. 通过命令行方式：

   • kubectl scale deployment web1 --replicas=8

   • kubectl edit deployments.apps web1

2. 通过修改 yaml 文件的方式，修改 replicas 字段后

   • kubectl apply -f xx.yaml

概念 可以根据 CPU 利用率自动扩缩 ReplicationController、Deployment 或者 ReplicaSet 中的 Pod 数量

过程：

• 假设 deployment 启动了 3 个 pod 副本，而每个副本的负载率比较低

• 当有大规模的 并发数 到来时，每个 pod 的负载使用率增大

• 假设 pod 的负载使用率，例如 cpu 使用率，会超过某个 阈值

• 当有 pod 超过 负载阈值后，就会新创建出 pod 来分担

• 通过检测 pod CPU 的负载，解决 deployment 里某 pod 负载太重，动态伸缩 pod 的数量来负载均衡

• HPA 就是来监控 pod 的负载使用情况，一旦超出 阈值，通知 deployment 来创建新的 pod 分担负载

HPA 的使用：

1. 创建 HPA

   • kubectl autoscale deployment web1 --min=1 --max=10

   • 说明，上面的命令创建了 hpa，最少 1 个 pod，最多只能创建 10 个 pod

   • 默认的cpu 的负载率阈值为 80%

2. 创建 HPA，并指定 cpu 的阈值

   • kubectl autoscale deployment web1 --min=1 --max=10 --cpu-percent=50

   • 说明，这里指定了 cpu 负载率 的阈值为 50%

3. 注意，如果要使用 hpa，必须安装 metric server 来监控资源使用率

   • 解决当前cpu的使用量为unknown：

     • 在 metric server 的部署yaml 中添加：- --metric-resolution=30s

• • • 并且在 deployment 的 yaml 文件中，添加 deployment.spec.template.spec.containers.resources

• • • 结果：

测试内容：

• 创建了一个deployment，并且启动了 3 个pod副本

• 其中 一个 pod 的副本在 node2 节点上，其余 pod 在 node1 节点上

• 如果 node2 突然宕机，那么在 node2上 的这个 pod，会处于 Unknown 状态，并且 deployment 会新创建一个 pod，来满足 3 个副本的要求

• 但未来某时刻，node2 恢复启动，该 pod 也不会重新启动在 node2 节点上，而是一直处于 Unknown 状态

有三种形式，可以修改 deployment 的镜像：

1. 通过命令行的方式

   • 在线修改，通过 kubectl edit deployments.apps web1， 修改 image 字段

   • 通过命令修改，kubectl set image 控制器类型 控制器名称 容器名=新的镜像名

2. 修改 yaml 文件形式

   • 修改完 deployment 的yaml 文件后，通过 kubectl apply -f xxx.yaml 修改

查看 deployment 的变更记录：

可以看到，如果没有 加 –record 选项，就不会记录在变更历史中，kubectl apply 和 kubectl set image 命令都可以 加 –record=true 选项，如果加了 –record 选项，例如：

可以看到 变更记录中已经有了升级命令。

deployment 的回滚： 回滚命令：kubectl rollout undo deployment web1 --to-revision=5

例子：

滚动升级的概念：

• 当升级 deployment 的镜像时，并不是所有的 pod 一下全部升级

• 而是 部分 pod 先升级，其余 pod 保持不变，当这部分 pod 升级完成后，其余 pod 在升级

滚动升级的配置：

• deployment.spec.strategy : 该字段用来配置滚动升级策略

• deployment.spec.strategy.type : 用新 Pods 替换旧 Pods 的策略, 可以是 RollingUpdate 或者 Recreate

  • RollingUpdate : 默认值，采取 滚动更新的方式更新 Pods。你可以指定 maxUnavailable 和 maxSurge 来控制滚动更新 过程。

    • maxSurge : 在升级过程中一次升级几个

    • maxUnavailable : 在升级过程中，只能有1个不可用一次性删除多少个pod

  • Recreate : 在创建新 Pods 之前，所有现有的 Pods 会被杀死。

例如：