CKA备考实验 | readiness probe

热爱编程的通信人

已于 2023-09-25 15:53:06 修改

阅读量188

点赞数

文章标签： kubernetes

于 2023-07-04 18:03:16 首次发布

本文链接：https://blog.csdn.net/guolianggsta/article/details/131540332

版权

书籍来源：《CKA/CKAD应试指南：从Docker到Kubernetes完全攻略》

一边学习一边整理老师的课程内容及实验笔记，并与大家分享，侵权即删，谢谢支持！

附上汇总贴：CKA备考实验 | 汇总_热爱编程的通信人的博客-CSDN博客

关于readiness的探测和liveness的探测类似，不过readiness和liveness探测到问题之后，处理的方式是不一样的。

liveness：探测到pod有问题之后，通过重启pod来解决问题。

readiness：探测到pod有问题之后并不重启，只是svc接收到请求之后，不再转发到此pod。svc的主要作用是接收用户的请求，然后转发给后端的pod，如图10-1所示。

这里有3个pod，它们的标签是一样的，都是run=app，为具有这个标签的pod创建一个名字为readsvc的服务。当用户把请求发送给readsvc的时候，readsvc会把请求转发给后端的pod，即pod1、pod2、pod3。3台pod都配置了readiness probe，当探测到pod3有问题的时候，readsvc就不会再把请求转发给pod3了。

步骤1：创建含有readiness probe的pod，yaml文件内容如下。

##########实操验证##########
[root@vms10 probe]# cat readiness.yaml 
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: app 
  name: pod1
spec:
  containers:
  - name: c1
    image: nginx 
    imagePullPolicy: IfNotPresent 
    lifecycle: 
      postStart:
        exec:
          command: ["/bin/sh","-c","touch /tmp/healthy"]
    readinessProbe:
      exec:
        command:
        - cat 
        - /tmp/healthy 
[root@vms10 probe]#

这里通过配置pod postStart钩子，让pod在启动的时候创建文件/tmp/healthy。然后通过readiness probe探测这个文件是否存在，存在则认为pod是健康的，否则认为nod出问题了。

步骤2：创建出来3个pod。

##########实操验证##########
[root@vms10 probe]# kubectl apply -f readiness.yaml
pod/pod1 created
[root@vms10 probe]# sed 's/pod1/pod2/' readiness.yaml | kubectl apply -f -
pod/pod2 created
[root@vms10 probe]# sed 's/pod1/pod3/' readiness.yaml | kubectl apply -f -
pod/pod3 created
[root@vms10 probe]#

步骤3：查看pod的运行状态。

##########实操验证##########
[root@vms10 probe]# kubectl get pods --show-labels
NAME   READY   STATUS    RESTARTS   AGE   LABELS
pod1   1/1     Running   0          57s   run=app
pod2   1/1     Running   0          41s   run=app
pod3   1/1     Running   0          34s   run=app
[root@vms10 probe]#

可以看到3个pod均具备相同的标签run=app。

步骤4：创建名字为readsvc的svc。

##########实操验证##########
[root@vms10 probe]# kubectl expose --name=readsvc pod pod1 --port=80 --selector=run=app
service/readsvc exposed
[root@vms10 probe]#

虽然这里是为pod1创建的svc，但是因为它们的标签是一样的，所以这个readsvc会关联3个pod。

步骤5：为了看到svc把请求转发到不同的pod，这里修改3个pod的index.html的内容，分别为111、222、333。

##########实操验证##########
[root@vms10 probe]# kubectl exec -it pod1 -- bash
root@pod1:/# echo 111 > /usr/share/nginx/html/index.html 
root@pod1:/# exit
exit
[root@vms10 probe]# kubectl exec -it pod2 -- bash
root@pod2:/# echo 222 > /usr/share/nginx/html/index.html
root@pod2:/# exit
exit
[root@vms10 probe]# kubectl exec -it pod3 -- bash
root@pod3:/# echo 333 > /usr/share/nginx/html/index.html
root@pod3:/# exit
exit
[root@vms10 probe]#

步骤6：获取readsvc的IP。

##########实操验证##########
[root@vms10 probe]# kubectl get svc readsvc
NAME      TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
readsvc   ClusterIP   10.97.124.183   <none>        80/TCP    95s
[root@vms10 probe]#

从这里可以看到readsvc的IP是10.102.236.50。

步骤7：通过这个IP访问svc。

##########实操验证##########
[root@vms10 probe]# curl -s 10.97.124.183
222
[root@vms10 probe]# curl -s 10.97.124.183
333
[root@vms10 probe]# curl -s 10.97.124.183
111
[root@vms10 probe]#

可以看到，请求分别转发到了3个pod上。

步骤8：删除pod3里的/tmp/healthy，让pod3探测失败。

##########实操验证##########
[root@vms10 probe]# kubectl exec -it pod1 -- ls /tmp/healthy
/tmp/healthy
[root@vms10 probe]# 
[root@vms10 probe]# kubectl exec -it pod3 -- rm -rf /tmp/healthy
[root@vms10 probe]# kubectl exec -it pod3 -- ls /tmp/healthy
ls: cannot access '/tmp/healthy': No such file or directory
command terminated with exit code 2
[root@vms10 probe]#

步骤9：看到pod 3的状态。

##########实操验证##########
[root@vms10 probe]# kubectl describe pod pod3
Name:         pod3
Namespace:    nsprobe
Priority:     0
Node:         vms12.rhce.cc/192.168.1.112
Start Time:   Mon, 05 Jun 2023 15:29:08 +0800
Labels:       run=app
Annotations:  cni.projectcalico.org/containerID: 23902ece57adb5126f09c083608a4f6a6b6db951ffd90d696bc424cb5743cc82
              cni.projectcalico.org/podIP: 10.244.14.19/32
              cni.projectcalico.org/podIPs: 10.244.14.19/32
Status:       Running
IP:           10.244.14.19
IPs:
  IP:  10.244.14.19
Containers:
  c1:
    Container ID:   docker://d46c971d72eb59e14e96a3a10cec2f43f29379bb38b1031a6d550505f5db253a
    Image:          nginx
    Image ID:       docker-pullable://nginx@sha256:af296b188c7b7df99ba960ca614439c99cb7cf252ed7bbc23e90cfda59092305
    Port:           <none>
    Host Port:      <none>
    State:          Running
      Started:      Mon, 05 Jun 2023 15:29:09 +0800
    Ready:          False
    Restart Count:  0
    Readiness:      exec [cat /tmp/healthy] delay=0s timeout=1s period=10s #success=1 #failure=3
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-65zm9 (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             False 
  ContainersReady   False 
  PodScheduled      True 
Volumes:
  kube-api-access-65zm9:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   BestEffort
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason     Age               From               Message
  ----     ------     ----              ----               -------
  Normal   Scheduled  4m51s             default-scheduler  Successfully assigned nsprobe/pod3 to vms12.rhce.cc
  Normal   Pulled     4m50s             kubelet            Container image "nginx" already present on machine
  Normal   Created    4m50s             kubelet            Created container c1
  Normal   Started    4m50s             kubelet            Started container c1
  Warning  Unhealthy  1s (x5 over 41s)  kubelet            Readiness probe failed: cat: /tmp/healthy: No such file or directory
[root@vms10 probe]#

这里可以看到已经检测到pod3是不健康的。

步骤10：再次访问readsvc。

##########实操验证##########
[root@vms10 probe]# curl -s 10.97.124.183
222
[root@vms10 probe]# curl -s 10.97.124.183
111
[root@vms10 probe]#

可以看到read svc已经不把svc转到pod3了。

步骤11：查看pod的状态。

##########实操验证##########
[root@vms10 probe]# kubectl get pods
NAME   READY   STATUS    RESTARTS   AGE
pod1   1/1     Running   0          6m36s
pod2   1/1     Running   0          6m20s
pod3   0/1     Running   0          6m13s
[root@vms10 probe]#

这里pod3的状态虽然是显示0/1，但是pod3里的容器依然是正常运行的。

##########实操验证##########
[root@vms10 probe]# kubectl exec -it pod3 -- bash
root@pod3:/# exit
exit
[root@vms10 probe]#

步骤12：删除这3个pod和readsvc。

##########实操验证##########
[root@vms10 probe]# kubectl delete svc readsvc
service "readsvc" deleted
[root@vms10 probe]# 
[root@vms10 probe]# kubectl delete pod pod{1,2,3} --force
warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely.
pod "pod1" force deleted
pod "pod2" force deleted
pod "pod3" force deleted
[root@vms10 probe]#

热爱编程的通信人

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
CKA备考实验 | readiness probe

这里有3个pod，它们的标签是一样的，都是run=app，为具有这个标签的pod创建一个名字为readsvc的服务。关于readiness的探测和liveness的探测类似，不过readiness和liveness探测到问题之后，处理的方式是不一样的。步骤5：为了看到svc把请求转发到不同的pod，这里修改3个pod的index.html的内容，分别为111、222、333。虽然这里是为pod1创建的svc，但是因为它们的标签是一样的，所以这个readsvc会关联3个pod。
复制链接

扫一扫