新增pod其它控制
This commit is contained in:
@@ -4,7 +4,7 @@ Deployment 控制器是 Kubernetes 中用于管理应用程序部署和更新的
|
|||||||
它提供了一种声明式的方法来定义和管理应用程序的生命周期, 包括创建、更新和回滚等操作。
|
它提供了一种声明式的方法来定义和管理应用程序的生命周期, 包括创建、更新和回滚等操作。
|
||||||
Deployment 控制器(通过管理 ReplicaSet 来确保应用程序的期望状态与实际状态保持一致),从而实现高可用性和弹性伸缩。
|
Deployment 控制器(通过管理 ReplicaSet 来确保应用程序的期望状态与实际状态保持一致),从而实现高可用性和弹性伸缩。
|
||||||
|
|
||||||
|
#-----------------------------------------------------------------------------------------------
|
||||||
|
|
||||||
二、声明式与命令式
|
二、声明式与命令式
|
||||||
|
|
||||||
@@ -20,6 +20,7 @@ Deployment 控制器(通过管理 ReplicaSet 来确保应用程序的期望状
|
|||||||
# kubectl diff -f deployment.yaml
|
# kubectl diff -f deployment.yaml
|
||||||
比较当前集群实际运行的资源清单对象与当前资源清单文件对象的差异
|
比较当前集群实际运行的资源清单对象与当前资源清单文件对象的差异
|
||||||
|
|
||||||
|
#-----------------------------------------------------------------------------------------------
|
||||||
|
|
||||||
三、Deployment 控制器资源清单
|
三、Deployment 控制器资源清单
|
||||||
|
|
||||||
@@ -48,6 +49,7 @@ spec:
|
|||||||
|
|
||||||
# 上边的Deployment控制器清单没在spec中设置replicas,默认为 1
|
# 上边的Deployment控制器清单没在spec中设置replicas,默认为 1
|
||||||
|
|
||||||
|
#-----------------------------------------------------------------------------------------------
|
||||||
|
|
||||||
三、Deployment常用命令
|
三、Deployment常用命令
|
||||||
|
|
||||||
@@ -75,3 +77,35 @@ spec:
|
|||||||
# kubectl set image deployment/myapp-deployment myapp-container=nginx/nginx:1.9.1
|
# kubectl set image deployment/myapp-deployment myapp-container=nginx/nginx:1.9.1
|
||||||
更新Deployment控制器的镜像
|
更新Deployment控制器的镜像
|
||||||
|
|
||||||
|
#-----------------------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
四、金丝雀部署思想
|
||||||
|
利用Deployment控制器的滚动更新特性, 可以实现金丝雀部署。
|
||||||
|
先设置Deployment控制器允许多n个pod, 允许少0个pod, 然后逐步更新pod的镜像版本, 观察新版本的稳定性, 如果新版本稳定, 则继续更新剩余的pod, 如果新版本不稳定, 则回滚到旧版本。
|
||||||
|
|
||||||
|
Deployment 控制器回滚的原理是etcd内存了这个Deploymen控制器控制的对应的RS的历史版本
|
||||||
|
|
||||||
|
1、通过补丁方式 设置Deployment控制器的滚动更新策略, 允许多1个pod, 允许少0个pod
|
||||||
|
# kubectl patch deployment myapp-deployment -p '{"spec":{"straegy":{"rollingUpdate":{"maxSurge":"1", "maxUnavailable":"0"}}}}'
|
||||||
|
|
||||||
|
2、更新Deployment控制器的镜像版本 (由于 1 的设置, 会多创建一个新pod, 然后停止删除旧pod)
|
||||||
|
# kubectl patch deployment myapp-deployment --patch '{"spec":{"template":{"spec":{"containers":[{"name":"myapp-container","image":"nginx:1.9.1"}]}}}}' && kubectl rollout rollout pause deploy myapp-deployment
|
||||||
|
|
||||||
|
3、恢复滚动更新 (恢复新建一个新pod, 删除一个旧pod, 创建一个新pod)
|
||||||
|
# kubectl rollout resume deploy myapp-deployment
|
||||||
|
|
||||||
|
暂停滚动更新
|
||||||
|
# kubectl rollout pause deploy myapp-deployment
|
||||||
|
|
||||||
|
4、回滚到上一个版本【注】回滚只能回滚到上一个版本, 不能回滚到更早的版本
|
||||||
|
# kubectl rollout undo deploy myapp-deployment && kubectl rollout status deployments myapp-deployment
|
||||||
|
|
||||||
|
5、查看回滚的历史记录
|
||||||
|
# kubectl rollout history deployment myapp-deployment
|
||||||
|
|
||||||
|
[注意] 更新命令在尾部加上 --record 参数, 可以记录变更历史, 方便后续查看和回滚
|
||||||
|
|
||||||
|
6、回滚到制定版本(这里的版本号数字是命令5查询出来的历史记录中的版本号)
|
||||||
|
# kubectl rollout undo deploy myapp-deployment --to-revision=2 && kubectl rollout status deployments myapp-deployment
|
||||||
|
|
||||||
|
|
||||||
|
|||||||
37
k8s知识笔记/二、k8s pod 控制器/4、daemonSet控制器.conf
Normal file
37
k8s知识笔记/二、k8s pod 控制器/4、daemonSet控制器.conf
Normal file
@@ -0,0 +1,37 @@
|
|||||||
|
一、DeamonSet 简介
|
||||||
|
DaemonSet 是 Kubernetes 中的一种控制器, 用于确保在集群中的每个节点上运行有且只有一个 Pod 的副本。
|
||||||
|
它通常用于部署需要在每个节点上运行的后台服务, 例如日志收集、监控代理等。
|
||||||
|
当有Node加入集群时,也会为他们新增一个Pod。当有Node从集群移除时,这些Pod也会被回收。
|
||||||
|
删除DaemonSet将会删除它创建的所有Pod
|
||||||
|
|
||||||
|
使用场景:
|
||||||
|
1. 集群日志收集: 在每个节点上运行日志收集代理, 如Fluentd, Logstash等
|
||||||
|
2. 监控代理: 在每个节点上运行监控代理, 如Prometheus Node Exporter, Datadog Agent等
|
||||||
|
3. 网络插件: 在每个节点上运行网络插件, 如Calico, Weave等
|
||||||
|
4. 存储插件: 在每个节点上运行存储插件, 如Ceph, GlusterFS等
|
||||||
|
5. 安全代理: 在每个节点上运行安全代理, 如Falco, Sysdig等
|
||||||
|
|
||||||
|
#-----------------------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
二、DaemonSet 控制器清单示例
|
||||||
|
|
||||||
|
apiVersion: apps/v1
|
||||||
|
kind: DaemonSet
|
||||||
|
metadata:
|
||||||
|
name: my-daemonset
|
||||||
|
labels:
|
||||||
|
app: my-daemonset
|
||||||
|
spec:
|
||||||
|
selector:
|
||||||
|
matchLabels:
|
||||||
|
app: my-daemonset
|
||||||
|
template:
|
||||||
|
metadata:
|
||||||
|
labels:
|
||||||
|
app: my-daemonset
|
||||||
|
spec:
|
||||||
|
containers:
|
||||||
|
- name: my-container
|
||||||
|
image: nginx:1.7.9
|
||||||
|
ports:
|
||||||
|
- containerPort: 80
|
||||||
35
k8s知识笔记/二、k8s pod 控制器/5、job控制器.conf
Normal file
35
k8s知识笔记/二、k8s pod 控制器/5、job控制器.conf
Normal file
@@ -0,0 +1,35 @@
|
|||||||
|
一、Job 控制器简介
|
||||||
|
Job负责批处理任务,即仅执行一次的任务,它保证批处理任务的一个或多个Pod成功结束。
|
||||||
|
Job 控制器用于管理批处理任务, 确保指定数量的 Pod 成功完成其任务。
|
||||||
|
它适用于需要一次性执行的任务, 如数据处理、备份等。Job 控制器会创建一个或多个 Pod 来执行任务, 并监控其状态, 直到所有 Pod 成功完成任务为止。
|
||||||
|
如果某个 Pod 失败, Job 控制器会根据配置重新创建 Pod 以确保任务完成。
|
||||||
|
|
||||||
|
特殊说明:
|
||||||
|
* spec.template 格式同 Pod
|
||||||
|
* RestartPolicy 仅支持 Never 或 OnFailure
|
||||||
|
* 单个 Pod 时, 默认 Pod 成功运行后 Job 即结束
|
||||||
|
* .spec.completions 标志 Job 结束需要成功运行的 Pod 个数, 默认为 1
|
||||||
|
* .spec.parallelism 标志并行运行的 Pod 的个数, 默认为 1
|
||||||
|
* spec.activeDeadlineSeconds 标志失败 Pod 的重试最大时间, 超过这个时间不会继续重试
|
||||||
|
|
||||||
|
|
||||||
|
#-----------------------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
二、job 控制器资源清单
|
||||||
|
|
||||||
|
apiVersion: batch/v1
|
||||||
|
kind: Job
|
||||||
|
metadata:
|
||||||
|
name: my-job
|
||||||
|
spec:
|
||||||
|
completions: 3 # 需要成功运行的 Pod 个数, 默认为 1
|
||||||
|
parallelism: 2 # 并行运行的 Pod 的个数, 默认为 1
|
||||||
|
backoffLimit: 4 # 失败 Pod 的重试次数, 默认为 6
|
||||||
|
activeDeadlineSeconds: 100 # 失败 Pod 的重试最大时间, 超过这个时间不会继续重试, 单位秒
|
||||||
|
template:
|
||||||
|
spec:
|
||||||
|
containers:
|
||||||
|
- name: my-job
|
||||||
|
image: my-job-image
|
||||||
|
restartPolicy: Never
|
||||||
|
|
||||||
84
k8s知识笔记/二、k8s pod 控制器/6、cronjob控制器.conf
Normal file
84
k8s知识笔记/二、k8s pod 控制器/6、cronjob控制器.conf
Normal file
@@ -0,0 +1,84 @@
|
|||||||
|
一、cronjob控制器简介
|
||||||
|
|
||||||
|
CronJob管理基于时间的Job,即:
|
||||||
|
* 在给定时间点只运行一次
|
||||||
|
* 周期性地在给定时间点运行
|
||||||
|
|
||||||
|
使用条件:当前使用的Kubernetes集群,版本>=1.8(对CronJob)
|
||||||
|
|
||||||
|
典型的用法如下所示:
|
||||||
|
* 在给定的时间点调度Job运行
|
||||||
|
* 创建周期性运行的Job,例如:数据库备份、发送邮件
|
||||||
|
* 创建周期性运行的任务,例如:定期清理临时文件
|
||||||
|
|
||||||
|
#-----------------------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
CronJob 控制器用于在 Kubernetes 集群中定期运行任务。它类似于传统的 cron 作业, 但具有更强大的功能和灵活性。CronJob 控制器允许用户定义定时任务的调度时间、任务执行的命令或脚本, 以及任务的并发策略等。
|
||||||
|
|
||||||
|
CronJob 控制器通过创建和管理 Job 资源来实现定期任务的执行。每当达到预定的时间点时, CronJob 控制器会创建一个新的 Job 资源, Job 资源负责实际执行任务。用户可以通过配置 CronJob 的 spec 字段来定义任务的调度规则和执行细节。
|
||||||
|
|
||||||
|
CronJob 控制器支持多种调度方式, 包括基于时间间隔的调度和基于特定时间点的调度。用户可以使用类似于 cron 表达式的语法来定义调度规则, 例如 "0 0 * * *" 表示每天午夜执行一次任务。
|
||||||
|
|
||||||
|
除了基本的调度功能外, CronJob 控制器还提供了一些高级功能, 例如并发策略、失败重试机制和历史记录保留等。用户可以根据需要配置这些选项, 以满足不同的任务执行需求。
|
||||||
|
|
||||||
|
总之, CronJob 控制器是 Kubernetes 中用于管理定期任务的重要组件, 它简化了任务调度和执行的过程, 提高了系统的自动化水平和可靠性。
|
||||||
|
|
||||||
|
#-----------------------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
二、CronJob 常用命令
|
||||||
|
|
||||||
|
# 创建 CronJob
|
||||||
|
kubectl apply -f cronjob.yaml
|
||||||
|
|
||||||
|
# 查看 CronJob 列表
|
||||||
|
kubectl get cronjob
|
||||||
|
|
||||||
|
# 查看特定 CronJob 的详细信息
|
||||||
|
kubectl describe cronjob <cronjob-name>
|
||||||
|
|
||||||
|
# 删除 CronJob
|
||||||
|
kubectl delete cronjob <cronjob-name>
|
||||||
|
|
||||||
|
# 查看由 CronJob 创建的 Job 列表
|
||||||
|
kubectl get jobs
|
||||||
|
|
||||||
|
# 查看由 Job 创建的 Pod 列表
|
||||||
|
kubectl get pods --selector=job-name=<job-name>
|
||||||
|
|
||||||
|
# 查看特定 Pod 的日志
|
||||||
|
kubectl logs <pod-name>
|
||||||
|
|
||||||
|
# 手动触发 CronJob 创建一个 Job
|
||||||
|
kubectl create job --from=cronjob/<cronjob-name> <new-job-name>
|
||||||
|
|
||||||
|
#-----------------------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
三、CronJob 控制器资源清单
|
||||||
|
|
||||||
|
资源清单字段:
|
||||||
|
|
||||||
|
.spec.schedule: 调度, 必需字段, 指定任务运行周期, 格式同Cron
|
||||||
|
|
||||||
|
.spec.jobTemplate: Job模板, 必需字段, 指定需要运行的任务, 格式同Job
|
||||||
|
|
||||||
|
.spec.startingDeadlineSeconds: 启动Job的期限(秒级别),
|
||||||
|
该字段是可选的
|
||||||
|
如果因为任何原因而错过了被调度的时间,那么错过执行时间的Job将被认为是失败的
|
||||||
|
如果没有指定,则没有期限
|
||||||
|
|
||||||
|
.spec.concurrencyPolicy: 并发策略
|
||||||
|
该字段也是可选的。它指定了如何处理被CronJob创建的
|
||||||
|
Job的并发执行, 只允许指定下面策略中的一种:
|
||||||
|
Allow(默认): 允许并发运行Job
|
||||||
|
Forbid: 禁止并发运行, 如果前一个还没有完成, 则直接跳过下一一个
|
||||||
|
Replace: 取消当前正在运行的Job, 用一个新的来替换
|
||||||
|
注意, 当前策略只能应用于同一个CronJob创建的Job, 如果果存在多个CronJob, 它们创建的Job之间总是允许并发运行。
|
||||||
|
|
||||||
|
.spec.suspend: 挂起, 该字段也是可选的。
|
||||||
|
如果设置为'true',后续所有执行都会被挂起。它对已经开始执行的Job不起作用。默认值为'false'
|
||||||
|
|
||||||
|
.spec.successfulJobsHistoryLimit 和 .spec.failedJobsHistoryLimit: 历史限制, 是可选的字段。
|
||||||
|
它们指定了可以保留多少完成和失败的Job。默认情况下,它们分别设置为'3'和'1'。设置限制的值为'0',相关类型的Job完成后将不会被保留
|
||||||
Reference in New Issue
Block a user