Kubernetes pod中systemctl狀態(tài)探針失敗問(wèn)題怎么解決

本篇內(nèi)容介紹了“Kubernetes pod中systemctl狀態(tài)探針失敗問(wèn)題怎么解決”的有關(guān)知識(shí)，在實(shí)際案例的操作過(guò)程中，不少人都會(huì)遇到這樣的困境，接下來(lái)就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

在Heketi的glusterd容器服務(wù)，使用systemctl探針來(lái)檢測(cè)glusterfs服務(wù)是否可用，發(fā)現(xiàn)總是出現(xiàn)失敗問(wèn)題。

經(jīng)查，在Ubuntu 18.04 上 systemctl status glusterd.service 運(yùn)行時(shí)輸出信息不是K8s livenessProbe希望的，導(dǎo)致檢測(cè)器超時(shí)掛起了。

• 使用systemctl status glusterd.service并不能檢測(cè)到服務(wù)的真實(shí)狀態(tài)，會(huì)掛起、超時(shí)，返回錯(cuò)誤狀態(tài)碼。

使用下面的方式，可以正確檢測(cè)service的真實(shí)狀態(tài)： 

systemctl is-active --quiet glusterd.service; echo $?;

或者（類(lèi)似于）：

systemctl is-active sshd >/dev/null 2>&1 && echo 0 || echo 1

輸出：

• 正常時(shí) 0；

• 非正常時(shí)為錯(cuò)誤碼。

• 如下所示：

        livenessProbe:
          exec:
            command:
            - /bin/bash
            - -c
            - systemctl is-active --quiet glusterd.service; echo $?;
          failureThreshold: 3
          initialDelaySeconds: 60
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 3
        readinessProbe:
          exec:
            command:
            - /bin/bash
            - -c
            - systemctl is-active --quiet glusterd.service; echo $?;

修改后的k8s yaml文件如下：

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: glusterfs-daemon
  namespace: gluster
  labels:
    k8s-app: glusterfs-node
spec:
  selector:
    matchLabels:
      name: glusterfs-daemon
  template:
    metadata:
      labels:
        name: glusterfs-daemon
    spec:
      tolerations:
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      containers:
      - image: gluster/gluster-centos:latest
        imagePullPolicy: IfNotPresent
        name: glusterfs
        livenessProbe:
          exec:
            command:
            - /bin/bash
            - -c
            - systemctl is-active --quiet glusterd.service; echo $?;
          failureThreshold: 3
          initialDelaySeconds: 60
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 3
        readinessProbe:
          exec:
            command:
            - /bin/bash
            - -c
            - systemctl is-active --quiet glusterd.service; echo $?;
          failureThreshold: 3
          initialDelaySeconds: 60
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 3
        resources: {}
        securityContext:
          capabilities: {}
          privileged: true
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        volumeMounts:
        - mountPath: /var/lib/heketi
          name: glusterfs-heketi
        - mountPath: /run
          name: glusterfs-run
        - mountPath: /run/lvm
          name: glusterfs-lvm
        - mountPath: /etc/glusterfs
          name: glusterfs-etc
        - mountPath: /var/log/glusterfs
          name: glusterfs-logs
        - mountPath: /var/lib/glusterd
          name: glusterfs-config
        - mountPath: /dev
          name: glusterfs-dev
        - mountPath: /sys/fs/cgroup
          name: glusterfs-cgroup
      dnsPolicy: ClusterFirst
      hostNetwork: true
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
      volumes:
      - hostPath:
          path: /var/lib/heketi
          type: ""
        name: glusterfs-heketi
      - emptyDir: {}
        name: glusterfs-run
      - hostPath:
          path: /run/lvm
          type: ""
        name: glusterfs-lvm
      - hostPath:
          path: /etc/glusterfs
          type: ""
        name: glusterfs-etc
      - hostPath:
          path: /var/log/glusterfs
          type: ""
        name: glusterfs-logs
      - hostPath:
          path: /var/lib/glusterd
          type: ""
        name: glusterfs-config
      - hostPath:
          path: /dev
          type: ""
        name: glusterfs-dev
      - hostPath:
          path: /sys/fs/cgroup
          type: ""
        name: glusterfs-cgroup

可能在不同的Linux版本上，systemd的版本不同，參數(shù)也可能不一樣，輸入systemctl help來(lái)獲取當(dāng)前版本的幫助。

“Kubernetes pod中systemctl狀態(tài)探針失敗問(wèn)題怎么解決”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！