1. ReplicaSet
1.1 ReplicaSet资源清单
apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
name: rs-test
spec:
replicas: 3 #有3个副本
selector: #标签选择器
matchLabels:
tier: frontend
template: # pod模板
metadata:
1abels:
tier: frontend
spec:
containers:
- name: toc
image: lzw5399/tocgenerator
env:
- name: GET_HOSTS_FROM
value:dns
ports:
- containerPort: 80
1.2 selector
rs通过selector标签来认定哪些pod是属于它当前的，所以跟下面template的labels必须对应起来
验证步骤
- 显示当前pod的labels
kubectl get po --show-labels
可以看到下面被replicaSet托管的pod有label
2. 强行修改运行的pod的label
kubectl label pod tocgenerator-6b57695c6f-9nfqc app=eee --override
再次查看pod，发现重新控制器重新创建了一个新的pod
2. Deployment
2.1 Deployment资源清单
apiVersion: apps/v1
kind: Deployment
metadata:
name: toc-deploy
spec:
replicas: 3
selector: #标签选择器
matchLabels: # 跟下面的labels必须对应起来
app: toc
template:
metadata:
labels: # 跟上面的matchLabels必须对应起来
app: toc
spec:
containers:
- name: toc
image: lzw5399/tocgenerator
ports:
- containerPort: 80
2.2 其他相关操作
2.2.1 应用yaml创建
# --record参数可以记录命令，我们可以很方便的查看每次 revision 的变化
# 更新的时候可以记录状态，每一步是使用什么命令进行更新的
kubectl apply -f temp.yaml --record
2.2.2 扩容
kubectl scale deployment toc-deploy --replicas 10
2.2.3 自动扩容
- 如果集群支持horizontal pod autoscaling的话，还可以为Deployment设置自动扩展
kubectl autoscale deployment toc-deploy --min=10 --max=15 --cpu-percent=80
2.2.4 更新容器中的镜像
kubectl set image deployment/toc-deploy tocgenerator=lzw5399/tocgenerator:xxx
2.2.5 回滚
- 回滚到上一次
kubectl rollout undo deployment/toc-deploy
- 回滚到指定版本
# 这个revision可以通过kubectl rollout history deployment/toc-deploy查找
kubectl rollout undo deployment/toc-deploy --to-revision=2
- 查看回滚的状态
kubectl rollout status deployments toc-deploy
- 查看可回滚的历史版本
kubectl rollout history deployment toc-deploy
2.2.6 使用edit命令编辑Deployment
kubectl edit deployment/toc-deploy
2.3 deploy保存的rs历史版本数量
默认保存所有的历史rs，可以通过spec.revisonHistoryLimit来配置
如果将该项设置为0，Deployment 就不允许回退了
3. DaemonSet
3.1 DaemonSet资源清单
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: deamonset-test
labels:
app: daemonset
spec:
selector:
matchLabels:
name: dd
template:
metadata:
labels:
name: dd
spec:
containers:
- name: daemonset-example
image: lzw5399/tocgenerator
3.2 其他相关操作
3.2.1 查看daemonset
kubectl get ds
-
由于daemonset会避开有
污点的节点，所以daemonset默认不会往主节点调度pod -
下面的截图是去除了master的污点的情况下，daemonset往主节点调度的情形
4. Job
4.1 Job资源清单
apiVersion: batch/v1
kind: Job
metadata:
name: pi
spec:
template:
metadata:
name: pi
spec:
containers:
- name: pi
image: lzw5399/tocgenerator
command: ["echo","doneee!!!!"]
restartPolicy: Never # job的policy建议用Never，不会丢失日志。如果是OnFailure，一旦达到backoffLimit，运行job的容器将被终止。这会使调试job更加困难
backoffLimit: 4 # 如果job失败，最多的重试次数，默认为6
activeDeadlineSeconds: 100 # job运行的时间限制，包括失败后启动其他pod继续运行的时间，优先级大于backoffLimit
4.2 其他操作
4.2.1 查看job
kubectl get job
可以看到需要完成次数是1，已完成是0
4.2.2 job出现错误的情况
- 可以看到，由于我们的job有错误无法完成执行，所以k8s会重复地执行该job，知道执行完成或者达到重试次数
默认重试次数是6
4.2.3 job成功运行的情况
- job完成后，不会再创建其他Pod，但是Pod也不会被删除，而是状态变为
completed
5. CronJob
5.1 CronJob资源清单
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: he11o
spec:
schedule: "*/1 * * * *" # 1分钟执行一次
jobTemplate:
spec:
template:
spec:
containers:
- name: hello
image: lzw5399/tocgenerator
command: # 输出当前时间和hello
- /bin/sh
- -c
- date;echo Hello from the Kubernetes cluster
restartPolicy: OnFailure
5.2 CronJob Spec
-
spec.template格式同Pod -
RestartPolicy仅支持Never或OnFailure - 单个Pod时，默认Pod成功运行后Job即结束·
-
spec.completions标志Job结束需要成功运行的Pod个数，默认为1· -
spec.parallelism标志并行运行的Pod的个数，默认为1 -
spec.activeDeadlineSeconds标志失败Pod的重试最大时间，超过这个时间不会继续重试 -
spec.schedule：调度，必需字段，指定任务运行周期，格式同 Cron· -
spec.jobTemplate:Job模板，必需字段，指定需要运行的任务，格式同Job -
spec.startingDeadlineSeconds:启动Job的期限（秒级别），该字段是可选的。如果因为任何原因而错过了被调度的时间，那么错过执行时间的Job将被认为是失败的。如果没有指定，则没有期限 -
spec.concurrencyPolicy:并发策略，该字段也是可选的。它指定了如何处理被 Cron Job创建的Job的并发执行。只允许指定下面策略中的一种：- Allow（默认）：允许并发运行Job
- Forbid：禁止并发运行，如果前一个还没有完成，则直接跳过下一个
- Replace：取消当前正在运行的Job，用一个新的来替换
注意，当前策略只能应用于同一个CronJob创建的Job。如果存在多个Cron Job，它们创建的Job之间总是允许并发运行。
-
spec.suspend：挂起，该字段也是可选的。如果设置为true，后续所有执行都会被挂起。它对已经开始执行的Job不起作用。默认值为false。 -
spec.successfulJobsHistoryLimit和spec.failed]obsHistoryLimit:历史限制，是可选的字段。它们指定了可以保留多少完成和失败的Job。默认情况下，它们分别设置为3和1。设置限制的值为1，相关类型的Job完成后将不会被保留。
5.3 CronJob的限制
- 创建Job操作应该是幂等的
- CronJob并不太好去判断任务是否成功，CronJob通过创建Job去完成任务，Job成功与否可以判断，但CronJob无法链接到Job去获取成功与否，Cron只会定期的去创建Job，仅此而已。