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

posted @ 2020-05-21 18:26 虾敏四把刀阅读(827) 评论(0) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部

虾敏四把刀

Kubernetes学习笔记（三）：部署托管的Pod -- 存活探针、ReplicationController、ReplicaSet、DaemonSet、Job、CronJob

存活探针

exec探针

livenessProbe下的字段

注意事项

ReplicationController

nginx-rc.yaml

使用ReplicationController

控制器如何创建的pod

kubectl edit

kubectl scale

删除ReplicationController

注意事项

ReplicaSet

nginx-rs.yaml

matchExpressions

DaemonSet

nginx-ds.yaml

创建DaemonSet

Job

job.yaml

运行查看

completions与parallelism

activeDeadlineSeconds

CronJob

cronjob.yaml

运行

startingDeadlineSeconds

小结

公告