Kubernetes生命周期和探针

目录

简介

Pod在整个生命周期中被系统定义为各种状态，熟悉Pod的各种状态对于理解如何设置Pod的调度策略，重启策略很有必要

1. Pod的状态

  • Pending
    API Server已经创建Pod 但在Pod内还有一个或多个的镜像没有创建，包括正在下载镜像的过程。

  • Running
    Pod内所有容器已经创建完成，且至少有一个容器处于运行状态

  • Successded
    Pod内所有容器均成功执行退出，并且不会再重启

  • Faild
    Pod内所有容器均已退出，但至少有一个容器为退出失败状态

2. Pod重启策略

Pod的重启策略应用于Pod内所有的容器，并且仅在Pod所处的Node上由kubelet进行判断和重启操作

重启策略

  • Always： 总是重启；当容器失效时，由kubelete自动重启该容器，默认值
  • OneFailure：当容器终止运行且退出码不为0时候，由kubelete自动重启该容器
  • Never：不论容器运行状态如何都不会重启该容器,Job或CronJob

配置在spec与containers同级中

........
     containers:
     - name: tomcat-app1-container
       image: harbor.magedu.local/tomcat-app1:v1
       command: ["/apps/tomcat/bin/run_tomcat.sh"]
       imagePullPolicy: IfNotPresent
       #imagePullPolicy: Always
       ports:
       - containerPort: 8080
         protocol: TCP
         name: http
       env:
       - name: "password"
         value: "123456"
       resources:
         limits:
           cpu: 1
           memory: "512Mi"
         requests:
           cpu: 500m
           memory: "512Mi"
     restartPolicy: Always      #重启策略

3. Pod探针

Pod健康检查和服务可用性检查

Kubernetes对Pod的健康检查可以通过两类探针检查LivenessProbe，ReadinessProbe，kubelet定期执行这两类探针来诊断容器的监控状态

  • LivenessProber探针
    用于判断容器是否存活(Running状态)，如果LivenessProbe探针探测到容器不健康，则kubelete将杀掉该容器，并根据容器的重启策略做相应的处理，如果一个容器不包含LivenessProbe探针，那么kubelet认为该容器的LivenessProbe弹指值返回永远时Seccess

  • ReadinessProbe探针
    用于判断容器服务是否可用(Ready状态)，达到Ready状态的Pod才可以接受请求，流量可以接入。对于service管理的Pod service与Pod Endpoint的关联关系也会将基于Pod是否Ready进行设置

3.1 探针的探测方式

  • ExecAction
    在容器内执行一个命令，如果该命令的返回值为0 则表明容器健康

  • TCPSocketActio
    通过容器的IP地址和端口号执行TCP检
    查，如果能够建立TCP连接，则表明容器健康

  • HTTPGetAction
    通过容器的IP地址，端口号及路径调用Http Get方法，如果状态码大于等于200且小于400，则认为容器健康
    生产建议使用此方法调用你的程序接口进行检测

3.2 配置方式

辅助探测的其它配置项目

  • initialDelaySeconds: 5 #启动容器后的多长时间进行探测

  • periodSeconds: 3 #间隔多长时间执行一次探测

  • timeoutSeconds: 5 #探测超时等待多少秒进行下一次探测

  • successThreshold: 1 #从失败转为成功的重试次数，探测器在失败后，被视为成功的最小连续成功数，默认值是1，存活探测的这个值必须是1，最小值是 1

  • failureThreshold: 3 #从成功转为失败的重试次数，当Pod启动了并且探测到失败，Kubernetes的重试次数，存活探测情况下的放弃就意味着重新启动容器，就绪探测情况下的放弃Pod 会被打上未就绪的标签，默认值是3，最小值是1

HttpGet探针
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 1
  selector:
    matchLabels: #rs or deployment
      app: ng-deploy-80
  template:
    metadata:
      labels:
        app: ng-deploy-80
    spec:
      containers:
      - name: ng-deploy-80
        image: nginx:1.17.5 
        ports:
        - containerPort: 80
      livenessProbe:
        httpGet:
          path: /index.html
          port: 80
        initialDelaySeconds: 5  #启动容器后的多长时间进行探测
        periodSeconds: 3       #间隔多长时间执行一次探测
        timeoutSeconds: 5     #探测超时等待多少秒进行下一次探测
        successThreshold: 1   #从失败转为成功的重试次数，探测器在失败后，被视为成功的最小连续成功数，默认值是1，存活探测的这个值必须是1，最小值是 1
        failureThreshold: 3   #从成功转为失败的重试次数，当Pod启动了并且探测到失败，Kubernetes的重试次数，存活探测情况下的放弃就意味着重新启动容器，就绪探测情况下的放弃Pod 会被打上未就绪的标签，默认值是3，最小值是1

kubelet定时发送HTTP请求到 localhost:80/index.html 来进行容器应用的健康检查

TcpSocket探针
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 1
  selector:
    matchLabels: #rs or deployment
      app: ng-deploy-80
  template:
    metadata:
      labels:
        app: ng-deploy-80
    spec:
      containers:
      - name: ng-deploy-80
        image: nginx:1.17.5 
        ports:
        - containerPort: 80
      livenessProbe:
        tcpSocket:
          port: 80
        initialDelaySeconds: 5
        periodSeconds: 3
        timeoutSeconds: 5
        successThreshold: 1
        failureThreshold: 3
ExecAction探针
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 1
  selector:
    matchLabels: #rs or deployment
      app: ng-deploy-80
  template:
    metadata:
      labels:
        app: ng-deploy-80
    spec:
      containers:
      - name: ng-deploy-80
        image: nginx:1.17.5 
        ports:
        - containerPort: 80
      livenessProbe:
        exec:
          command:
          - cat 
          - /root/
        initialDelaySeconds: 5
        periodSeconds: 3
        timeoutSeconds: 5
        successThreshold: 1
        failureThreshold: 3

3.2 livenessProbe和readinessProbe的对比

配置参数一样

  • livenessProbe 连续探测失败会重启、重建pod，readinessProbe不会执行重启或者重建Pod操作

  • livenessProbe 连续检测指定次数失败后会将容器置于(Crash Loop BackOff)且不可用，readinessProbe不
    会

  • readinessProbe 连续探测失败会从service的endpointd中删除该Pod，livenessProbe不具备此功能，但是会将容器挂起livenessProbe

  • livenessProbe用户控制是否重启pod，readinessProbe用于控制pod是否添加至service

建议：
两个探针都配置

4. 镜像拉取策略

  • imagePullPolicy: IfNotPresent
    node节点没有此镜像就去指定的镜像仓库拉取，node有就使用node本地镜像。

  • imagePullPolicy: Always
    每次重建pod都会重新拉取镜像

  • imagePullPolicy: Never
    从不到镜像中心拉取镜像，只使用本地镜像

posted @ 2020-12-02 01:03  刘新元  阅读(199)  评论(0)  编辑  收藏  举报