存活探针
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。
-> [[email protected]] [~] 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秒后查看
-> [[email protected]] [~] k create -f exec-liveness.yaml
pod/liveness-exec created
-> [[email protected]] [~] 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 default-scheduler Successfully assigned default/liveness-exec to kube1.vm
Normal Pulling kubelet, kube1.vm Pulling image "busybox"
Normal Pulled kubelet, kube1.vm Successfully pulled image "busybox"
Normal Created kubelet, kube1.vm Created container liveness
Normal Started kubelet, kube1.vm Started container liveness
Warning Unhealthy (x3 over ) kubelet, kube1.vm Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory
Normal Killing 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
-> [[email protected]] [~] k create -f nginx-rc.yaml
replicationcontroller/nginx-rc created
查看pod，确实新建了3个pod。
-> [[email protected]] [~] 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的简写。
-> [[email protected]] [~] k get rc
NAME DESIRED CURRENT READY AGE
nginx-rc 3 3 3 5m58s
查看详情
-> [[email protected]] [~] k describe rc nginx-rc
Name: nginx-rc
Namespace: default
Selector: app=nginx
Labels: app=nginx
Annotations:
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:
Mounts:
Volumes:
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配置，修改在保存后会立刻做出改变。
-> [[email protected]] [~] k edit rc nginx-rc
replicationcontroller/nginx-rc edited
通过KUBE_EDITOR环境变量可以指定用什么编辑器打开。
kubectl scale
可以使用kubectl scale命令进行扩缩容。
-> [[email protected]] [~] 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打个标签
-> [[email protected]] [~] k label node kube1.vm region=beijing
node/kube1.vm labeled
-> [[email protected]] [~] k get node -L region
NAME STATUS ROLES AGE VERSION REGION
kube0.vm Ready master 40h v1.17.3
kube1.vm Ready 40h v1.17.3 beijing
kube2.vm Ready 40h v1.17.3
提交描述文件
-> [[email protected]] [~] k create -f nginx-ds.yaml
daemonset.apps/nginx-ds created
-> [[email protected]] [~] 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
给kube2.vm也打个标签
-> [[email protected]] [~] k label node kube2.vm region=beijing
node/kube2.vm labeled
-> [[email protected]] [~] 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
pod/nginx-ds-b46lb 0/1 ContainerCreating 0 3s kube2.vm
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
-> [[email protected]] [~] k create -f job.yaml
job.batch/job created
60秒内查看：
-> [[email protected]] [~] 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秒后查看：
-> [[email protected]] [~] 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
-> [[email protected]] [~] 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
-> [[email protected]] [~] k create -f cronjob.yaml
cronjob.batch/cron-job created
等了几分钟
-> [[email protected]] [~] 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
又等了几分钟
-> [[email protected]] [~] 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