Kubernetes学习笔记（二）：部署托管的Pod -- 存活探针、ReplicationController、ReplicaSet、DaemonSet、Job、CronJob
存活探针
Kubernetes可以通过存活探针（liveness probe）检查容器是否存活。如果探测失败，Kubernetes将定期执行探针并重新启动容器。
官方文档请见：https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
存活探针分为三种：
- exec：在容器内执行任意命令，并检查命令的退出状态码，为0则成功，否则失败。
- httpGet：执行http get请求，http code大于等于200并且小于400表示成功，否则失败。
- tcp：尝试与指定端口建立socket连接，建立成功则探测成功，否则失败。
exec探针
从官网复制个yaml，但是要将image从k8s.gcr.io/busybox更改为busybox。
-> [root@kube0.vm] [~] cat exec-liveness.yaml
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-exec
spec:
containers:
- name: liveness
image: busybox
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
运行然后30秒后查看
-> [root@kube0.vm] [~] k create -f exec-liveness.yaml
pod/liveness-exec created
-> [root@kube0.vm] [~] k describe po liveness-exec
.......
Liveness: exec [cat /tmp/healthy] delay=5s timeout=1s period=5s #success=1 #failure=3
.......
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled <unknown> default-scheduler Successfully assigned default/liveness-exec to kube1.vm
Normal Pulling <invalid> kubelet, kube1.vm Pulling image "busybox"
Normal Pulled <invalid> kubelet, kube1.vm Successfully pulled image "busybox"
Normal Created <invalid> kubelet, kube1.vm Created container liveness
Normal Started <invalid> kubelet, kube1.vm Started container liveness
Warning Unhealthy <invalid> (x3 over <invalid>) kubelet, kube1.vm Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory
Normal Killing <invalid> kubelet, kube1.vm Container liveness failed liveness probe, will be restarted
前30秒，/tmp/healthy是存在的，探针返回成功。30秒后，因为/tmp/healthy不存在了，所以一直失败，直到失败3次后重启。
livenessProbe下的字段
这时候kubectl explain po.spec.containers.livenessProbe就派上了用场。
- exec：exec探针配置
- httpGet：httpGet探针配置
- tcpSocket：tcpSocket探针配置
- initialDelaySeconds：初始延迟时间，在此时间内不进行探测，给程序预留启动时间。
- periodSeconds：探测周期，默认10s
- timeoutSeconds：超时时间，默认1s
- failureThreshold：被认为失活的最小连续失败次数，默认3次
- successThreshold：失败后被认为存活的最小连续成功次数，默认为1次。
这些参数在上面的kubectl describe的结果中的Liveness字段有：
exec [cat /tmp/healthy] delay=5s timeout=1s period=5s #success=1 #failure=3
注意事项
- 一定要检查程序的内部，而没有外界因素影响。
例如，当服务器无法连接到数据库时，前端服务的探针不应返回失败。因为问题在数据库，重启前端服务也无法解决问题。 - 无须再探针中实现重试
- 探针要轻量
ReplicationController
ReplicationController是一种Kubernetes资源，可以确保他的pod始终处于运行状态。
ReplicationController描述文件分为三大部分：
- label selector（标签选择器）：用于确定ReplicationController管理哪些pod
- replica count（副本个数）：指定运行pod的数量
- pod template（pod模板）：用于创建pod
ReplicationController的目的就是创建和管理若干个pod副本，它会持续监控正在运行的pod列表，保证标签选择器匹配的pod数量与副本个数一致。如果少于副本数量，就要根据pod模板创建新的副本；如果多余副本数量，就要删除多余的pod。
数量少的原因可能是：
- 增加了副本个数
- pod所在的工作节点出现故障
- pod的标签更改了，导致pod与ReplicationController的标签选择器不再匹配了。此时，如果它不被任何ReplicationController的标签选择器匹配，它就称为一个孤儿了。
数量多的原因可能是：
- 减少了副本个数
- 新建的pod与该ReplicationController的标签选择器匹配
- 已存在的pod标签修改后与该ReplicationController的标签选择器匹配
nginx-rc.yaml
API服务器会检查模板中的标签是否与selector匹配，如果不匹配是无法创建的。可以不指定selector，它会根据模板中的labels自动配置。
apiVersion: v1
kind: ReplicationController
metadata:
name: nginx-rc
spec:
replicas: 3 # 副本数量
selector: # pod选择器，决定RC的操作对象
app: nginx
template: # pod模板
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
使用ReplicationController
创建ReplicationController
-> [root@kube0.vm] [~] k create -f nginx-rc.yaml
replicationcontroller/nginx-rc created
查看pod，确实新建了3个pod。
-> [root@kube0.vm] [~] k get po --show-labels
NAME READY STATUS RESTARTS AGE LABELS
nginx-rc-2c47w 0/1 ContainerCreating 0 5s app=nginx
nginx-rc-jrcl2 0/1 ContainerCreating 0 5s app=nginx
nginx-rc-qgchh 0/1 ContainerCreating 0 5s app=nginx
查看ReplicationController，rc是ReplicationController的简写。
-> [root@kube0.vm] [~] k get rc
NAME DESIRED CURRENT READY AGE
nginx-rc 3 3 3 5m58s
查看详情
-> [root@kube0.vm] [~] k describe rc nginx-rc
Name: nginx-rc
Namespace: default
Selector: app=nginx
Labels: app=nginx
Annotations: <none>
Replicas: 3 current / 3 desired # 当前数量、期望数量
Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed # 各种状态下的数量
Pod Template:
Labels: app=nginx
Containers:
nginx:
Image: nginx
Port: 80/TCP
Host Port: 0/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulCreate 7m26s replication-controller Created pod: nginx-rc-2c47w
Normal SuccessfulCreate 7m26s replication-controller Created pod: nginx-rc-jrcl2
Normal SuccessfulCreate 7m26s replication-controller Created pod: nginx-rc-qgchh
可以搞一些破坏，比如更改、删除pod的标签，或者干脆删除pod。ReplicationController会因为当前数量与期望数量不符而创建新的副本。
控制器如何创建的pod
控制器通过创建一个新的副本代替被删除的副本时，它并没有对删除本身做出反应，而是针对由此产生的状态——副本数量不足做出反应。
虽然控制器会立即受到pod被删除的通知，但这并不是它创建新副本的原因。该通知会触发控制器检查实际的副本数量并采取相应措施。
kubectl edit
kubectl edit rc nginx-rc可以在编辑器中打开nginx-rc的yaml配置，修改在保存后会立刻做出改变。
-> [root@kube0.vm] [~] k edit rc nginx-rc
replicationcontroller/nginx-rc edited
通过KUBE_EDITOR环境变量可以指定用什么编辑器打开。
kubectl scale
可以使用kubectl scale命令进行扩缩容。
-> [root@kube0.vm] [~] k scale rc nginx-rc --replicas=6
replicationcontroller/nginx-rc scaled
以上操作会修改spec.replicas字段，就像通过kubectl edit修改一样。
删除ReplicationController
使用 kubectl delete 删除ReplicationController时，pod也会被删除。但由于pod是被ReplicationController创建的而不是它的组成部分，所以可以通过指定--cascade=false而不删除pod。
注意事项
- pod永远不会被重新安置到另一个节点。
- 虽然一个pod没有绑定在ReplicationController上，但该pod在
metadata.ownerReferences引用它。
ReplicaSet
ReplicationController最终将要被弃用，代替它的是ReplicaSet。它们的行为完全相同，但是ReplicaSet的选择器更具有表达力。
nginx-rs.yaml
让我们来看一个ReplicaSet的描述文件：
apiVersion: apps/v1 # api版本与ReplicationController不同
kind: ReplicaSet
metadata:
name: nginx-rs
spec:
replicas: 3
selector: # ReplicaSet的pod选择器有matchLabels和matchExpressions，与ReplicationController的是相似的，但更强大
matchLabels:
app: nginx
template: # 模板内容是一致的
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
主要区别在于pod选择器。ReplicaSet的创建于ReplicationController一样，缩写是rs，就不再赘叙了。
matchExpressions
上面描述文件的选择器使用matchExpressions可以改为：
selector:
matchExpressions:
- key: app
operator: In
values:
- nginx
每个表达式都必须包含key、operator（运算符），有可能包含values（取决于运算符），运算符有以下四种：
- In：Label的值必须与values中的一个相等
- NotIn：Label的值不能与values中的任何一个相等
- Exists：Pod必须包含一个指定名称的标签，values无所谓
- DoesNotExists：Pod不得包含指定名称的标签，values不能指定
DaemonSet
DaemonSet与ReplicaSet的不同在于，DaemonSet可以让pod在集群的每个节点上运行，有且只有一个。
如果节点下线，DaemonSet不会在其他地方重建pod；如果集群新加入了一个节点，DaemonSet会立刻部署一个新的pod。如果有人删除了pod，DaemonSet会建立一个新的。
这些pod通常用于执行系统级别或基础结构相关的工作，如日志收集和资源监控。典型的例子就是Kubernetes自己的kube-proxy。
如果想让DaemonSet只在特定节点运行pod，需要通过pod模板中的nodeSelector属性指定。
DaemonSet中没有期望副本数的概念，它不需要。因为它的工作是确保有一个匹配它选择器的pod在节点上运行。
nginx-ds.yaml
可能这里用继续用nginx作为例子不太恰当，但目前我们关注的重点是DaemonSet，继续吧。。。
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: nginx-ds
spec: # 去掉了replicas，因为不需要
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
nodeSelector: # 添加了一个节点的标签选择器，选择只部署地区在在北京的节点上
region: "beijing"
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
创建DaemonSet
先给kube1.vm打个标签
-> [root@kube0.vm] [~] k label node kube1.vm region=beijing
node/kube1.vm labeled
-> [root@kube0.vm] [~] k get node -L region
NAME STATUS ROLES AGE VERSION REGION
kube0.vm Ready master 40h v1.17.3
kube1.vm Ready <none> 40h v1.17.3 beijing
kube2.vm Ready <none> 40h v1.17.3
提交描述文件
-> [root@kube0.vm] [~] k create -f nginx-ds.yaml
daemonset.apps/nginx-ds created
-> [root@kube0.vm] [~] k get ds,po -o wide
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE CONTAINERS IMAGES SELECTOR
daemonset.apps/nginx-ds 1 1 1 1 1 region=beijing 52s nginx nginx app=nginx
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod/nginx-ds-5z95c 1/1 Running 0 52s 10.244.1.24 kube1.vm <none> <none>
给kube2.vm也打个标签
-> [root@kube0.vm] [~] k label node kube2.vm region=beijing
node/kube2.vm labeled
-> [root@kube0.vm] [~] k get ds,po -o wide
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE CONTAINERS IMAGES SELECTOR
daemonset.apps/nginx-ds 2 2 1 2 1 region=beijing 113s nginx nginx app=nginx
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod/nginx-ds-5z95c 1/1 Running 0 113s 10.244.1.24 kube1.vm <none> <none>
pod/nginx-ds-b46lb 0/1 ContainerCreating 0 3s <none> kube2.vm <none> <none>
Job
Job可以运行一种pod，在该pod内的进程成功结束时，不再重启。一旦任务完成，pod就被认为处于完成状态。
比如可以使用在将一些数据导出到其他地方，这个工作可能会持续几个小时。
我们基于busybox镜像，sleep一段时间用于模拟这个操作。
job.yaml
apiVersion: batch/v1
kind: Job
metadata:
name: job
spec:
template: # 没有指定selector，会根据pod标签中自动创建
metadata:
labels:
app: job
spec:
restartPolicy: OnFailure # 执行遇到异常则重启，默认为Always。
containers:
- name: sleepbusybox
image: busybox
command: ["/bin/sh","-c","sleep 60;echo this is busybox"]
restartPolicy表示pod的重启策略，默认Always，其他两项为OnFailure和Never。
运行查看
创建job
-> [root@kube0.vm] [~] k create -f job.yaml
job.batch/job created
60秒内查看：
-> [root@kube0.vm] [~] k get job,pod
NAME COMPLETIONS DURATION AGE
job.batch/job 0/1 14s 14s
NAME READY STATUS RESTARTS AGE
pod/job-4sfv4 1/1 Running 0 14s
60秒后查看：
-> [root@kube0.vm] [~] k get job,pod
NAME COMPLETIONS DURATION AGE
job.batch/job 1/1 68s 71s
NAME READY STATUS RESTARTS AGE
pod/job-4sfv4 0/1 Completed 0 71s
使用jsonpath获取 pod name 查看log
-> [root@kube0.vm] [~] k logs $(k get po --selector=app=job --output=jsonpath={.items..metadata.name})
this is busybox
completions与parallelism
job描述文件下的spec有两个字段：
- completions：job要确保完成多少个pod，默认为1。
- parallelism：最多并行运行多少个pod，默认为1。
job-batch.yaml
apiVersion: batch/v1
kind: Job
metadata:
name: job-batch
spec:
completions: 5
parallelism: 2
template:
# 与job.yaml相同
activeDeadlineSeconds
job.spec.activeDeadlineSeconds属性来限制Job在集群中的存活时间，超过此值，所有的pod都被终止。Job的status变为 type: Failed,reason: DeadlineExceeded
CronJob
与Linux的crontab类似，使pod可以在特定时间运行，或者周期运行。
cronjob.yaml
这个描述文件是个套娃。。
CronJob包含job的模板，也就是jobTemplate；job里还包含pod的模板，也就是template。
schedule字段中的值是”分 小时 每月第几天 月份 星期几”，详情请参考Linux crontab。
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: cron-job
spec:
schedule: "*/3 * * * * " # 每三分钟运行一次
jobTemplate: # job的模板
spec:
template: # pod的模板
metadata:
labels:
app: job-in-cron
spec:
restartPolicy: OnFailure
containers:
- name: sleepbusybox
image: busybox
command: ["/bin/sh","-c","sleep 60;echo this is busybox"]
运行
创建cron-job
-> [root@kube0.vm] [~] k create -f cronjob.yaml
cronjob.batch/cron-job created
等了几分钟
-> [root@kube0.vm] [~] k get all
NAME READY STATUS RESTARTS AGE
pod/cron-job-1590053040-pqhhh 0/1 Completed 0 97s
NAME COMPLETIONS DURATION AGE
job.batch/cron-job-1590053040 1/1 68s 97s
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE
cronjob.batch/cron-job */3 * * * * False 0 105s 4m39s
又等了几分钟
-> [root@kube0.vm] [~] k get all
NAME READY STATUS RESTARTS AGE
pod/cron-job-1590053040-pqhhh 0/1 Completed 0 3m4s
pod/cron-job-1590053220-whflp 0/1 ContainerCreating 0 3s
NAME COMPLETIONS DURATION AGE
job.batch/cron-job-1590053040 1/1 68s 3m4s
job.batch/cron-job-1590053220 0/1 3s 3s
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE
cronjob.batch/cron-job */3 * * * * False 1 12s 6m6s
可以看到就当前的描述文件而言，cron-job每次创建一个job，job创建一个pod的运行。
startingDeadlineSeconds
cronjob.spec.startingDeadlineSeconds规定pod必须预定时间之后的startingDeadlineSeconds秒内运行，超过此时间则不运行，并将其显示未Failed。
小结
- 使用存活探针检查容器是否存活。
- ReplicationController创建并管理Pod，但并不是绑定关系。它始终保持期望数量的副本正在运行。
- ReplicationController将被弃用，ReplicaSet拥有更强的标签选择器。
- DaemonSet会在每个节点上保持运行有且只有一个Pod，可以通过nodeSelector让其只在特定节点运行。
- Job创建Pod运行完成后，Pod为为
Completed状态。completions与parallelism指定需要完成的数量与并行度。 - restartPolicy：默认Always，还有OnFailure、Never。
- CronJob创建Job，Job创建Pod。
- 命令：edit、scale