【k8s系列九】k8s应用节点的探针2--案例分析

212 阅读4分钟

持续创作,加速成长!这是我参与「掘金日新计划 · 10 月更文挑战」的第16天,点击查看活动详情

1. 就绪探测

1) 基于http get的就绪探测.

第一步: 准备资源清单

apiVersion: v1
kind: Pod
metadata:
  name: readiness-httpget-pod
  namespace: default
  labels:
    app: myapp
spec:
  containers:
  - name: readiness-httpget-container
    image: wangyanglinux/myapp:v1
    imagePullPolicy: IfNotPresent
    readinessProbe:
      httpGet:
        port: 80
        path: /index1.html
      initialDelaySeconds: 1
      periodSeconds: 3

资源清单内容解析

  • 创建一个pod,pod名是readiness-httpget-pod. pod 有一个标签,key是app, value是myapp

  • 在spec中定义了应用容器, 名为readiness-httpget-container. 使用的镜像是wangyanglinux/myapp:v1, 镜像拉取的策略是IfNotPresent

    • 应用容器有一个readinessProbe就绪探针,

      • 探针采用的探测方式是httpget, 端口是80, 路径是/index1.html
      • initialDelaySeconds 探针开始检测的时间是容器启动后1s.
      • periodSeconds表示重试间隔, 单位也是秒. 也就是每隔3秒探测一次.

分析: 在myapp中封装了nginx, nginx启动后会自动生产index.html文件. 但是没有index1.html文件. 所以这个就绪探测会检测失败, 检测失败,会一直删除该pod的ip地址.

第二步: 创建pod资源

kubectl create -f readiness-httpget-pod.yaml

image

从途中可以看出, 容器启动成功了,但是ready状态却始终没有ready. 因为访问html1.html文件失败.

通过kubectl create创建的svc会自动与pod标签的value一样的pod.

2. livenessProbe-存活探测

1) 通过脚本探测

资源清单

apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec-pod
  namespace: default
spec:
  containers:
    - name: liveness-exec-container
      image: busybox:latest
      imagePullPolicy: IfNotPresent
      command: ["/bin/sh","-c","touch /tmp/live;sleep 60;rm -rf /tmp/live;sleep 3600"]
      livenessProbe:
        exec:
          command: ["test","-e","/tmp/live"]
        initialDelaySeconds: 1
        periodSeconds: 3

这段代码的含义是:

  • 创建一个名字叫做liveness-exec-pod的pod

  • 应用容器名叫liveness-exec-container, 镜像是busybox:latest, 镜像拉取策略是IfNotPresent没有才拉取.

    • 镜像的启动命令是: 创建一个文件/tmp/live, 然后休眠60s, 在删除/tmp/live文件.

    • 应用容器有一个存活探测

      • 存活探测采用的是脚本测探, 脚本命令是检测/tmp/live是否存在
      • 存货探测在应用容器启动后1秒开始探测, 探测每隔3s执行一次

代码分析: 容器启动后, 就会创建一个文件/tmp/live, 然后1s后探针开始检测, 每隔3s检测一次, 都是判断/tmp/live文件是否存在, 60s内一直都是存在的. 60s后文件被删除. 这时存活探针再次检测, 文件不存在. 于是存货检测失败. pod会被删除重建. 然后我们在pod的restart那里就会看到不断地重启.

第二步:创建pod

kubectl create -f liveness-exec-pod.yaml

image

刚启动pod是Running的状态,60s后,当检测到失败,会删除pod重建。下图运行了6分29s,重建了3次。

image

2) http方式探测

1) 准备资源清单

apiVersion: v1
kind: Pod
metadata:
  name: liveness-httpget-pod
  namespace: default
spec:
  containers:
  - name: liveness-httpget-container
    image: wangyanglinux/myapp:v1
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 80
    livenessProbe:
      httpGet:
        port: 80
        path: /index.html
      initialDelaySeconds: 1
      periodSeconds: 3
      timeoutSeconds: 3

这段代码的含义是:

  • 前面都不说了,直接说spec

  • 创建了一个名字为liveness-httpget-container的应用容器,使用的镜像是wangyanglinux/myapp:v1, 镜像的拉取策略是IfNotPresent

  • 这里定义了一个服务的端口号,但这个服务端口号没有太大用途. 因为在扁平化的网络中, 不需要服务转发.

  • livenessProbe定义了存货探针, 探针的方式是httpget, 探测的是80端口下的/index.html是否存在. 我们知道这个一定是存在的,因为myapp里封装了nginx

    • initialDelaySeconds表示首次探测是在容器启动后1秒.
    • periodSeconds表示每隔3秒探测一次
    • timeoutSeconds表示探测的超时时间, 对于http请求, 有请求超时时间. 如果超过指定时间还没有返回结果, 那么就探测失败

逻辑分析: 这个探测是成功的,因为能够找到80端口下的/index.html, 所以pod正常运行

第二步: 创建pod,并运行

kubectl create -f 

运行结果如下: image

如果想验证的话, 很简单,进入到容器里,吧index.html删掉或者改名, 进入到容器里

kubectl exec liveness-httpget-pod -it -- /bin/sh

image

当改名的一瞬间,我们就被强制退出了, 因为pod被删除了, 容器也删除了.

3) tcp探测

第一步: 准备资源清单

apiVersion: v1
kind: Pod
metadata:
  name: liveness-tcp-pod
spec:
  containers:
  - name: nginx
    image: wangyanglinux/myapp:v1
    livenessProbe:
      initialDelaySeconds: 5
      timeoutSeconds: 1
      tcpSocket:
        port: 80

资源文件解析:

  • 直接看spec, 这里定义了一个容器叫做nginx, 镜像是wangyanglinux/myapp:v1

  • 创建了一个存活探测

    • tcpSocket: 探测的类型是tcp探测, 探测的端口是80
    • initialDelaySeconds初始延迟时间是5s, 也就是容器启动后5s开始探测
    • timeoutSeconds: 探测的超时时间是1s, 也就是如果容器探测1s内没有详情就返回失败

也就是说: 存活探测的类型是tcp, 探测端口是80, 如果有一天80端口不能访问通了, 那么检测就失败了

\