1 关于Pod控制器
1.1 控制器与Pod对象
Pod控制器资源通过持续性的监控集群中运行着的Pod资源对象来确保受其管控的资源严格符合用户期望的状态,例如资源副本的数量要精确符合期望等,通常,一个Pod控制器资源至少应该包含三个基本的组成部分。
- 标签选择器:匹配并关联Pod资源对象,并据此完成受其管控的Pod资源计数
- 期望的副本数:期望在集群中精确运行着的Pod资源的对象数量
- Pod模板:用于新建Pod资源对象的Pod模板资源
2 ReplicaSet控制器
2.1 ReplicaSet概述
相比较于手动创建和管理Pod资源来说,ReplicaSet能够实现以下功能。
- 确保Pod资源对象的数量精确反映期望值:ReplicaSet需要确保由其控制运行的Pod副本数量精确吻合配置中定义的期望值,否则就会自动补足所缺或终止所余。
- 确保Pod健康运行:探测到由其管控的Pod对象因其所在的工作节点故障而不可用时,自动请求由调度器于其他工作节点创建缺失的Pod副本。
- 弹性伸缩:业务规模因各种原因时常存在明显波动,在波峰或波谷期间,可以通过ReplicaSet控制器动态调整相关Pod资源对象的数量。此外,在必要时还可以通过HPA(HroizontalPodAutoscaler)控制器实现Pod资源规模的自动伸缩。
2.2 创建ReplicaSet
apiVersion: apps/v1 kind: ReplicaSet metadata : name: rs-example spec: replicas: 2 selector: matchLabels: app:rs-demo template: metadata: labels: app:rs-demo spec: containers: - name: myapp image: ikubernetes/myapp:v1 ports: - name: http containerPort: 80
- replicas<integer>:期望的Pod对象副本数
- selector<Object>:当前控制器匹配Pod对象副本的标签选择器,支持matchLabels和matchExpressions两种匹配机制
- template<Object>:用于补足Pod副本数量时使用的Pod模板资源
- minReadySeconds<integer>:新建的Pod对象,在启动后的多少时间内如果其容器未发生崩溃等异常情况即被视为“就绪”;默认为0秒,表示一旦就绪性探测成功,即被视为可用。
2.3 replicaSet扩容和缩容
kubectl提供了一个专用的子命令scale用于实现应用规模的伸缩,它支持从资源清单文件中获取新的目标副本数量,也可以直接在命令行通过“--replicas”选项进行读取:
例如,将re-example控制器的Pod副本数量提升至5个:
# kubectl scale replicasets rs-example --replicas=5
另外,kubectl scale命令还支持在现有Pod副本数量符合指定的值时才执行扩展操作,这仅需要为命令使用“--current-replicas”选项即可。
例如,下面的命令表示如果rs-example目前的Pod副本数量为2,就将其扩展至4个
# kubectl scale replicasets rs-example --current-replicas=2 --replicas=4
2.4 删除ReplicaSet控制器资源
使用kubectl delete命令删除ReplicaSet对象时默认会一并删除其管控的各Pod对象,有时,考虑到这些Pod资源未必由其创建,或者即便由其创建却也并非自身的组成部分,故而剋为命令使用“--cascade=false”选项,取消级联,删除相关的Pod对象,这在Pod资源后续可能会再次用到时尤为有用。
例如:删除rs控制器rs-example:
# kubectl delete replicasets rs-example --cascade=false
删除操作完成后,此前由rs-example控制器管控的各Pod对象仍处于活动状态,但他们变成了自主式Pod资源,用户需要自行组织和维护好他们。
3 Deployment控制器
apiVersion: apps/v1 kind: Deployment metadata: name: myapp-deploy spec: replicas: 3 selector: matchLabels: app: myapp template: metadata: labels: app: myapp spec: containers: - name: myapp image: ikubernetes/myapp:v1 ports: - containerPort: 80 name: http
3.1 Deployment更新策略
Deployment控制器支持两种更新策略:滚动更新(rolling update)和重新创建(recreate),默认为滚动更新。
Deployment控制器的滚动更新操作并非在同一个ReplicaSet控制器对象下删除并创建Pod资源,而是将他们分置于两个不同的控制器之下;旧控制器的Pod对象数量不断减少的同时,新控制器的Pod对象数量不断增加,直到旧控制器不在拥有Pod对象,而新控制器的副本数量变得完全符合期望值为止。
滚动更新时,应用升级期间还要确保可用的Pod对象数量不低于某阈值以确保可以持续处理客户端的服务请求,变动的方式和Pod对象的数量范围将通过spec.strategy.rolling.Update.maxSurge和spec.strategy.rolling.Update.maxUnavailable两个属性协调进行定义,如下
- maxSusge:指定升级期间存在的总Pod对象数量最多可超出期望值的个数,其值可以时0或正整数,也可以时一个期望值的百分比;例如,如果期望值为3,当前的属性值为1,则表示Pod对象的总数不能超过4个
- maxUnavailable:升级期间不可用的Pod副本数(包括新旧版本)最多不能低于期望值的个数,其值可以是0或正整数,也可以是一个期望值的百分比,默认值为1,该值意味着如果期望值是3,则升级期间至少要有两个Pod对象处于正常提供服务的状态。
3.2 回滚Deployment控制器下的应用发布
Deployment控制器的回滚操作可使用“kubectl rollout undo”命令完成,如下面命令可将myapp-deploy回滚至此前版本
# kubectl rollout undo deployments myapp-deploy
在“kubectl rollout undo”命令上使用“--to-revision”选项指定revision号码即可回滚到历史特定版本,如下可以查看revision历史记录
# kubectl rollout history deployments myapp-deploy
若要回滚到号码为2的revision记录,则可以使用如下命令
# kubectl rollout undo deployments myapp-deploy --to-revision=2
4 DaemonSet控制器
Daemonset是一种特殊的控制器,他有特定的应用场景,通常运行那些执行系统及操作任务的应用,其应用场景具体如下。
- 运行集群存储的守护进程,如在各个节点上运行glusterd或ceph
- 在各个节点上运行日志收集守护进程,如fluentd和logstash
- 在各个节点上运行监控系统的代理守护进程,如Prometheus Node Exporter、collectd、Datadog agent、New Relic agent或Ganglia gmond等
4.1 创建DaemonSet资源对象
例如,在每个节点上运行一个filebeat进程以收集容器相关的日志数据
apiVersion: apps/v1 kind: DaemonSet metadata: name: filebeat-ds labels: app: filebeat spec: selector: matchLabels: app: filebeat template: metadata: labels : app: filebeat name: filebeat spec: containers: - name: filebeat image: ikubernetes/filebeat:5.6.5-alpine env: - name: REDIS_HOST value: db.ilinux.io:6379 - name: LOG_LEVEL value: info
注意⚠️:如果Daemonset所创建的Pod需要运行于指定的Node节点上,可以在Pod模版的spec字段中嵌套使用nodeSelector字段,并确保其值定义的标签选择器与部分定义工作节点的标签匹配即可。
4.2 更新DaemonSet对象
在spec.updateStrategy嵌套字段中支持RollingUpdate(滚动更新)和OnDelete(删除时更新)两种更新策略。
滚动更新为默认策略,工作逻辑类似于Deployment控制,不过仅支持使用maxUnavailabe属性定义最大不可用Pod资源副本数(默认值为1),而删除时更新的方式则是在删除相应节点的Pod资源后重建并更新为新版本。
标签:kubectl,控制器,副本,name,对象,第七章,Pod From: https://www.cnblogs.com/weidongliu/p/16928199.html