精华内容
下载资源
问答
  • Pod生命周期

    2021-03-23 22:38:40
    Pod生命周期 Pod 遵循一个预定义的生命周期,起始于 `Pending` 阶段,如果至少其中有一个主要容器正常启动,则进入 `Running`,之后取决于 Pod 中是否有容器以失败状态结束而进入 `Succeeded` 或者 `Failed` 阶段。...

    Pod 遵循一个预定义的生命周期,起始于 Pending 阶段,如果至少其中有一个主要容器正常启动,则进入 Running,之后取决于 Pod 中是否有容器以失败状态结束而进入 Succeeded 或者 Failed 阶段。Pod生命周期过程图如下
    在这里插入图片描述

    Init容器

    1. init理解:

    Pod能够具有多个容器,应用运行在容器里面,但是也可能有一个或者多个先应用容器启动的Init容器。

    Init容器与应用容器很相似,除了一下两点:

    • Init容器总是运行到成功完成为止
    • 每个Init容器都必须在下一个Init容器启动之前成功完成

    如果 Pod 的 Init 容器失败,kubelet 会不断地重启该 Init 容器直到该容器成功为止。 然而,如果 Pod 对应的参数restartPolicy 值为 “Never”,Kubernetes 不会重新启动 Pod。

    2. Init容器示例:

    apiVersion: v1
    kind: Pod
    metadata:
      name: init-demo
      labels:
        app: init-demo
    spec:
      containers:
      - name: myapp-container
        image: busybox
        command: ['sh', '-c', 'echo The app is running! && sleep 3600']
      initContainers:
      - name: init-myservice
        image: busybox
        command: ['sh', '-c', "until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
      - name: init-mydb
        image: busybox
        command: ['sh', '-c', "until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for mydb; sleep 2; done"]
        
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: myservice
    spec:
      ports:
      - protocol: TCP
        port: 80
        targetPort: 9376
        
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: mydb
    spec:
      ports:
      - protocol: TCP
        port: 80
        targetPort: 9377
    

    3. 具体行为:

    在 Pod 启动过程中,每个 Init 容器会在网络和数据卷初始化之后按顺序启动。 kubelet 运行依据 Init 容器在 Pod 规约中的出现顺序依次运行之。

    每个 Init 容器成功退出后才会启动下一个 Init 容器。 如果某容器因为容器运行时的原因无法启动,或以错误状态退出,kubelet 会根据 Pod 的 restartPolicy 策略进行重试。 然而,如果 Pod 的 restartPolicy 设置为 “Always”,Init 容器失败时会使用 restartPolicy 的 “OnFailure” 策略。

    在所有的 Init 容器没有成功之前,Pod 将不会变成 Ready 状态。 Init 容器的端口将不会在 Service 中进行聚集。正在初始化中的 Pod 处于 Pending 状态, 但会将状况 Initializing 设置为 false。

    如果 Pod 重启,所有 Init 容器必须重新执行。

    对 Init 容器规约的修改仅限于容器的 image 字段。 更改 Init 容器的 image 字段,等同于重启该 Pod。

    因为 Init 容器可能会被重启、重试或者重新执行,所以 Init 容器的代码应该是幂等的。 特别地,基于 emptyDirs 写文件的代码,应该对输出文件可能已经存在做好准备。

    Init 容器具有应用容器的所有字段。然而 Kubernetes 禁止使用 readinessProbe, 因为 Init 容器不能定义不同于完成态(Completion)的就绪态(Readiness)。 Kubernetes 会在校验时强制执行此检查。

    在 Pod 上使用 activeDeadlineSeconds 和在容器上使用 livenessProbe 可以避免 Init 容器一直重复失败。activeDeadlineSeconds 时间包含了 Init 容器启动的时间。

    在 Pod 中的每个应用容器和 Init 容器的名称必须唯一; 与任何其它容器共享同一个名称,会在校验时抛出错误。

    4. Init容器的作用:

    因为init容器具有与应用程序分离的单独镜像,所以它们的启动相关代码具有以下优势:

    • init容器可以包含运行实用工具,但是处于安全考虑,是不建议在应用程序容器镜像里包含这些工具的, 避免这些工具导致应用镜像的安全性降低 。

    • Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。 例如,没有必要仅为了在安装过程中使用类似 sedawkpythondig 这样的工具而去 FROM 一个镜像来生成一个新的镜像。

    • 应用程序镜像可以分离出创建和部署的角色,而没有必要联合它们构建一个单独的镜像

    • Init 容器能以不同于 Pod 内应用容器的文件系统视图运行。因此,Init 容器可以访问 应用容器不能访问的 Secret 的权限 。

    • 由于 Init 容器必须在应用容器启动之前运行完成,因此 Init 容器 提供了一种机制来阻塞或延迟应用容器的启动,直到满足了一组先决条件。 一旦前置条件满足,Pod 内的所有的应用容器会并行启动。

    容器探针

    容器是由 kubelet对容器执行的定期诊断 。 要执行诊断,kubelet 调用由容器实现的 Handler (处理程序)。有三种类型的处理程序:

    • ExecAction: 在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
    • TCPSocketAction: 对容器的 IP 地址上的指定端口执行 TCP 检查。如果端口打开,则诊断被认为是成功的。
    • HTTPGetAction: 对容器的 IP 地址上指定端口和路径执行 HTTP Get 请求。如果响应的状态码大于等于 200 且小于 400,则诊断被认为是成功的。

    每次探测都将获得以下三种结果之一:

    • Success(成功):容器通过了诊断。
    • Failure(失败):容器未通过诊断。
    • Unknown(未知):诊断失败,因此不会采取任何行动。

    针对运行中的容器,kubelet 可以选择是否执行以下三种探针,以及如何针对探测结果作出反应:

    • livenessProbe:指示容器是否正在运行。如果存活态探测失败,则 kubelet 会杀死容器, 并且容器将根据其重启策略restartPolicy 决定未来。如果容器不提供存活探针, 则默认状态为 Success
    • readinessProbe:指示容器是否准备好为请求提供服务。如果就绪态探测失败, 端点控制器将从与 Pod 匹配的所有服务的端点列表中删除该 Pod 的 IP 地址。 初始延迟之前的就绪态的状态值默认为 Failure。 如果容器不提供就绪态探针,则默认状态为 Success
    • startupProbe: 指示容器中的应用是否已经启动。如果提供了启动探针,则所有其他探针都会被 禁用,直到此探针成功为止。如果启动探测失败,kubelet 将杀死容器,而容器依其 重启策略restartPolicy 进行重启。 如果容器没有提供启动探测,则默认状态为 Success

    Probe有很多配置字段,可以使用这些字段精确的控制存活和就绪检测的行为:

    • initialDelaySeconds:容器启动后要等待多少秒后存活和就绪探测器才被初始化,默认是 0 秒,最小值是 0。
    • periodSeconds:执行探测的时间间隔(单位是秒)。默认是 10 秒。最小值是 1。
    • timeoutSeconds:探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。
    • successThreshold:探测器在失败后,被视为成功的最小连续成功数。默认值是 1。 存活和启动探测的这个值必须是 1。最小值是 1。
    • failureThreshold:当探测失败时,Kubernetes 的重试次数。 存活探测情况下的放弃就意味着重新启动容器。 就绪探测情况下的放弃 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。

    下面分别列举ExecActionTCPSocketActionHTTPGetAction示例简单应用容器探测功能。

    ExecAction探测示例

    #  Exec 方式探针
    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
    

    在这个配置文件中,可以看到 Pod 中只有一个容器。 periodSeconds 字段指定了 kubelet 应该每 5 秒执行一次存活探测。 initialDelaySeconds 字段告诉 kubelet 在执行第一次探测前应该等待 5 秒。 kubelet 在容器内执行命令 cat /tmp/healthy 来进行探测。 如果命令执行成功并且返回值为 0,kubelet 就会认为这个容器是健康存活的。 如果这个命令返回非 0 值,kubelet 会杀死这个容器并重新启动它。

    HTTPGetAction探测示例:

    #  HttpGet方式探针
    apiVersion: v1
    kind: Pod
    metadata:
      labels:
        test: liveness
      name: liveness-http
    spec:
      containers:
      - name: liveness
        image: lsrong0414/liveness
        args:
        - /server
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
            httpHeaders:
            - name: Custom-Header
              value: Awesome
          initialDelaySeconds: 3
          periodSeconds: 3
    

    在这个配置文件中,可以看到 Pod 也只有一个容器。 periodSeconds 字段指定了 kubelet 每隔 3 秒执行一次存活探测。 initialDelaySeconds 字段告诉 kubelet 在执行第一次探测前应该等待 3 秒。 kubelet 会向容器内运行的服务(服务会监听 8080 端口)发送一个 HTTP GET 请求来执行探测。 如果服务器上 /healthz 路径下的处理程序返回成功代码,则 kubelet 认为容器是健康存活的。 如果处理程序返回失败代码,则 kubelet 会杀死这个容器并且重新启动它。

    任何大于或等于 200 并且小于 400 的返回代码标示成功,其它返回代码都标示失败。

    liveness的容器server服务逻辑是最开始 10 秒中,/healthz 处理程序返回一个 200 的状态码。之后处理程序返回 500 的状态码。所以kubelet 在容器启动之后 3 秒开始执行健康检测。所以前几次健康检查都是成功的。 但是 10 秒之后,健康检查会失败,并且 kubelet 会杀死容器再重新启动容器。

    TCPSocketAction探测示例

    apiVersion: v1
    kind: Pod
    metadata:
      name: goproxy
      labels:
        app: goproxy
    spec:
      containers:
      - name: goproxy
        image: lsrong0414/goproxy:0.1
        ports:
        - containerPort: 8080
        readinessProbe:
          tcpSocket:
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10
        livenessProbe:
          tcpSocket:
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 20
    

    TCP 检测的配置和 HTTP 检测很相似,上面示例中同时使用就绪和存活探测。kubelet 会在容器启动 5 秒后发送第一个就绪探测。 这会尝试连接 goproxy 容器的 8080 端口。 如果探测成功,这个 Pod 会被标记为就绪状态,kubelet 将继续每隔 10 秒运行一次检测。除了就绪探测,这个配置包括了一个存活探测。 kubelet 会在容器启动 15 秒后进行第一次存活探测。 就像就绪探测一样,会尝试连接 goproxy 容器的 8080 端口。 如果存活探测失败,这个容器会被重新启动。

    Pod Phase阶段

    Pod 的 status 字段是一个 PodStatus 对象,其中包含一个 phase 字段。

    Pod 的阶段(Phase)是 Pod 在其生命周期中所处位置的简单宏观概述。 该阶段并不是对容器或 Pod 状态的综合汇总,也不是为了成为完整的状态。

    Phase 可能的值:

    取值描述
    PendingPod 已被 Kubernetes 系统接受,但有一个或者多个容器尚未创建亦未运行。此阶段包括等待 Pod 被调度的时间和通过网络下载镜像的时间,
    RunningPod 已经绑定到了某个节点,Pod 中所有的容器都已被创建。至少有一个容器仍在运行,或者正处于启动或重启状态。
    SucceededPod 中的所有容器都已成功终止,并且不会再重启。
    FailedPod 中的所有容器都已终止,并且至少有一个容器是因为失败终止。也就是说,容器以非 0 状态退出或者被系统终止。
    Unknown因为某些原因无法取得 Pod 的状态。这种情况通常是因为与 Pod 所在主机通信失败。

    如果某节点死掉或者与集群中其他节点失联,Kubernetes 会实施一种策略,将失去的节点上运行的所有 Pod 的 phase 设置为 Failed

    容器回调

    kubelet 管理生命周期中的事件触发,运行指定代码,使容器能够了解其管理生命周期中的事件,并在执行相应的生命周期回调时运行在处理程序中实现的代码。

    kubernetes有两个回调暴露给容器

    PostStart:这个回调在容器被创建之后立即被执行。 但是,不能保证回调会在容器入口点(ENTRYPOINT)之前执行。 没有参数传递给处理程序。

    PreStop:在容器因 API 请求或者管理事件(诸如存活态探针失败、资源抢占、资源竞争等)而被终止之前, 此回调会被调用。 如果容器已经处于终止或者完成状态,则对 preStop 回调的调用将失败。 此调用是阻塞的,也是同步调用,因此必须在发出删除容器的信号之前完成。 没有参数传递给处理程序。

    针对容器,有两种类型的回调处理程序可供实现:

    • Exec - 在容器的 cgroups 和名称空间中执行特定的命令(例如 pre-stop.sh)。 命令所消耗的资源计入容器的资源消耗。
    • HTTP - 对容器上的特定端点执行 HTTP 请求。

    示例:

    apiVersion: v1
    kind: Pod
    metadata:
      name: lifecycle-demo
    spec:
      containers:
      - name: lifecycle-demo-container
        image: nginx
        lifecycle:
          postStart:
            exec:
              command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
          preStop:
            exec:
              command: ["/bin/sh","-c","nginx -s quit; while killall -0 nginx; do sleep 1; done"]
    

    上述配置文件中,你可以看到 postStart 命令在容器的 /usr/share 目录下写入文件 message。 命令 preStop 负责优雅地终止 nginx 服务。当因为失效而导致容器终止时,这一处理方式很有用。

    Kubernetes 在容器创建后立即发送 postStart 事件。 然而,postStart 处理函数的调用不保证早于容器的入口点(entrypoint) 的执行。postStart 处理函数与容器的代码是异步执行的,但 Kubernetes 的容器管理逻辑会一直阻塞等待 postStart 处理函数执行完毕。 只有 postStart 处理函数执行完毕,容器的状态才会变成 RUNNING。

    Kubernetes 在容器结束前立即发送 preStop 事件。除非 Pod 宽限期限超时,Kubernetes 的容器管理逻辑 会一直阻塞等待 preStop 处理函数执行完毕。

    当你的所拥有的知识撑不起你的野心的时候,你只能静下心去努力学习! When your knowledge does not support your ambition, you can only calm down and study hard!

    展开全文
  • POD 生命周期

    2020-11-25 16:41:58
    POD生命周期 Pod对象自从其创建开始至其终止退出的时间范围称为其生命周期,在这段时间中Pod会处于多种不同的状态,并执行一些操作 其中,创建主容器 main container 为必需的操作,其他可选的操作还包括运行初始化...

    POD 生命周期

    Pod对象自从其创建开始至其终止退出的时间范围称为其生命周期,在这段时间中Pod会处于多种不同的状态,并执行一些操作
    其中,创建主容器 main container 为必需的操作,其他可选的操作还包括运行初始化容器 init container、容器启动后钩子 post start hook 、容器的存活性探测 liveness probe 就绪性探测 readiness probe 以及容器终止前钩子 pre stop hook 等,这些操作是否执行则取决于Pod的定义

    Pod相位

    无论是类似前面几节中的由用户手动创建,还是通过 Deployment 等控制器创建,Pod对象总是应该处于其生命进程中以下几个相位 phase之一

    • Pending:API Server创建了Pod资源对象并已存入etcd中,但它尚未被调度完成,或者仍处于从仓库下载镜像的过程中
    • Running:Pod已经被调度至某节点,并且所有容器都已经被kubelet创建完成
    • Succeeded:Pod中的所有容器都已经成功终止并且不会被重启,通常这个状态会很短
    • Failed:所有容器都已经终止,但至少有一个容器终止失败,即容器返回了非0值的退出状态或已经被系统终止
    • Unknown:API Server无法正常获取到Pod对象的状态信息,通常是由于其无法与所在工作节点的kubelet通信所致

    Pod的相位是在其生命周期中的宏观概述,而非对容器或Pod对象的综合汇总,而且相位的数量和含义被严格界定,它仅包含上面列举的相位值

    Pod 创建过程

    1. 用户通过 kubectl 或其他 API 客户端提交 Pod SpecAPI Server
    2. API Server 尝试着将 Pod 对象的相关信息存入 etcd 中,待写入操作执行完成,APServer 即会返回确认信息至客户端。
    3. API Server 开始反映 etcd中的状态变化
    4. 所有的 Kubernetes 组件均使用 watch 机制来跟踪检查 API Server 上的相关的变动
    5. kube-scheduler(调度器)通过其 watcher 觉察到 API Server 创建了新的 Pod 对象但尚未绑定至任何工作节点
    6. kube-schedulerPod 对象挑选一个工作节点并将结果信息更新至 API Server
    7. 调度结果信息由 API Server 更新至 etcd 存储系统,而且 API Server 也开始反映此 Pod 对象的调度结果
    8. Pod 被调度到的目标工作节点上的 kubelet 尝试在当前节点上调用 Docker 启动容器,并将容器的结果状态回送至 API Server
    9. API ServerPod 状态信息存入 etcd 系统中
    10. etcd 确认写入操作成功完成后,API Server 将确认信息发送至相关的 kubelet,事件将通过它被接受

    在这里插入图片描述

    pod重启策略

    pod中的容器一旦挂了的重启策略,字段为 restartPolicy,其有三个状态

    • Always:一旦pod中容器挂了则总是重启,其为默认值,现反复重启的情况其策略为,复数的重启间隔时长是前一次重启时长的倍数,重启间隔时长极限为300秒,如第一次重启后间隔10秒第二次重启,第三次重启与第二次重启之间间隔30秒,以此类推直到300秒
    • OnFailure:一旦pod中容器挂了且状态是错误则重启
    • Never:一直不重启

    一旦pod调度成功后,除非节点挂了否则k8s不会将其重启到其他节点,而重启pod规则则取决于 restartPolicy

    [root@master-0 ~]# kubectl explain pods.spec.restartPolicy
    KIND:     Pod
    VERSION:  v1
    
    FIELD:    restartPolicy <string>
    
    DESCRIPTION:
         Restart policy for all containers within the pod. One of Always, OnFailure,
         Never. Default to Always. More info:
         https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy
    

    pod结束策略

    当pod结束需要平滑终止,提交删除或停止pod时会向pod内的每一个容器下发终止信号15,宽限期通常为30秒,也可自行指定,而宽限期过了之后会下发 kill 信号,强行进行终止

    pod探测

    liveness probe 和 readiness probe 都可以下以下三种探针类型:

    • ExecAction
    • TCPSocketAction
    • HTTPGetAction
    1. ExecAction 探测语法

      [root@master-0 ~]# kubectl explain pods.spec.containers
      lifecycle <Object>               # 启动后结束前钩子
          Actions that the management system should take in response to container
          lifecycle events. Cannot be updated.
      livenessProbe <Object>
          Periodic probe of container liveness. Container will be restarted if the
          probe fails. Cannot be updated. More info:
          https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes
      
      name <string> -required-
          Name of the container specified as a DNS_LABEL. Each container in a pod
          must have a unique name (DNS_LABEL). Cannot be updated.
      
      ports <[]Object>
          List of ports to expose from the container. Exposing a port here gives the
          system additional information about the network connections a container
          uses, but is primarily informational. Not specifying a port here DOES NOT
          prevent that port from being exposed. Any port which is listening on the
          default "0.0.0.0" address inside a container will be accessible from the
          network. Cannot be updated.
      
      readinessProbe <Object>
          Periodic probe of container service readiness. Container will be removed
          from service endpoints if the probe fails. Cannot be updated. More info:
          https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes
      [root@master-0 ~]# kubectl explain pods.spec.containers.livenessProbe       #readiness probe同理
      KIND:     Pod
      VERSION:  v1
      
      RESOURCE: livenessProbe <Object>
      
      DESCRIPTION:
          Periodic probe of container liveness. Container will be restarted if the
          probe fails. Cannot be updated. More info:
          https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes
      
          Probe describes a health check to be performed against a container to
          determine whether it is alive or ready to receive traffic.
      
      FIELDS:
      exec <Object>
          One and only one of the following should be specified. Exec specifies the
          action to take.
      
      failureThreshold <integer>          #探测重试次数
          Minimum consecutive failures for the probe to be considered failed after
          having succeeded. Defaults to 3. Minimum value is 1.
      
      httpGet <Object>
          HTTPGet specifies the http request to perform.
      
      initialDelaySeconds <integer>       #容器启动后的延迟探测时间
          Number of seconds after the container has started before liveness probes
          are initiated. More info:
          https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes
      
      periodSeconds <integer>             #周期间隔时长
          How often (in seconds) to perform the probe. Default to 10 seconds. Minimum
          value is 1.
      
      successThreshold <integer>
          Minimum consecutive successes for the probe to be considered successful
          after having failed. Defaults to 1. Must be 1 for liveness and startup.
          Minimum value is 1.
      
      tcpSocket <Object>
          TCPSocket specifies an action involving a TCP port. TCP hooks not yet
          supported
      
      timeoutSeconds <integer>            #超时时间
          Number of seconds after which the probe times out. Defaults to 1 second.
          Minimum value is 1. More info:
          https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes
      [root@master-0 ~]# vim liveness-exec.yaml
      apiVersion: v1
      kind: Pod
      metadata:
        name: liveness-exec-pod
        namespace: default
      spec:
        containers:
        - name: liveness-exec-pod-container
          image: busbox:latest
          imagePullPolicy: IfNotPresent
          command: ["/bin/sh","-c","touch /tmp/healthy; sleep30; rm -f /tmp/healthy; sleep 36000"]
          livenessProbe:
            exec:
              command: ["test","-e","/tmp/healthy"]
            initialDelaySeconds: 1
            periodSeconds: 3
      [root@master-0 ~]# kubectl create -f liveness-exec.yaml
      pod/liveness-exec-pod created
      [root@master-0 ~]# kubectl describe pods liveness-exec-pod
      Name:         liveness-exec-pod
      Namespace:    default
      Priority:     0
      Node:         slave-1.shared/10.211.55.37
      Start Time:   Tue, 07 Apr 2020 02:41:40 -0400
      Labels:       <none>
      Annotations:  <none>
      Status:       Running
      IP:           10.244.1.6
      IPs:
      IP:  10.244.1.6
      Containers:
      liveness-exec-pod-container:
          Container ID:  docker://58fecd244cf28a7753c6b9f72ddeabc895cead4ed568aeb1115034fbbd8cd666
          Image:         busybox:latest
          Image ID:      docker-pullable://busybox@sha256:b26cd013274a657b86e706210ddd5cc1f82f50155791199d29b9e86e935ce135
          Port:          <none>
          Host Port:     <none>
          Command:
          /bin/sh
          -c
          touch /tmp/healthy; sleep30; rm -f /tmp/healthy; sleep 36000
          State:          Running
          Started:      Tue, 07 Apr 2020 02:42:56 -0400
          Last State:     Terminated
          Reason:       Error
          Exit Code:    137
          Started:      Tue, 07 Apr 2020 02:42:17 -0400
          Finished:     Tue, 07 Apr 2020 02:42:56 -0400
          Ready:          True
          Restart Count:  2
          Liveness:       exec [test -e /tmp/healthy] delay=1s timeout=1s period=3s #success=1 #failure=3
          Environment:    <none>
          Mounts:
          /var/run/secrets/kubernetes.io/serviceaccount from default-token-lbf5s (ro)
      Conditions:
      Type              Status
      Initialized       True
      Ready             True
      ContainersReady   True
      PodScheduled      True
      Volumes:
      default-token-lbf5s:
          Type:        Secret (a volume populated by a Secret)
          SecretName:  default-token-lbf5s
          Optional:    false
      QoS Class:       BestEffort
      Node-Selectors:  <none>
      Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                      node.kubernetes.io/unreachable:NoExecute for 300s
      Events:
      Type     Reason     Age                From                     Message
      ----     ------     ----               ----                     -------
      Normal   Scheduled  <unknown>          default-scheduler        Successfully assigned default/liveness-exec-pod to slave-1.shared
      Normal   Pulled     13s (x3 over 89s)  kubelet, slave-1.shared  Container image "busybox:latest" already present on machine
      Normal   Created    13s (x3 over 89s)  kubelet, slave-1.shared  Created container liveness-exec-pod-container
      Normal   Started    13s (x3 over 89s)  kubelet, slave-1.shared  Started container liveness-exec-pod-container
      Warning  Unhealthy  4s (x9 over 88s)   kubelet, slave-1.shared  Liveness probe failed:
      Normal   Killing    4s (x3 over 82s)   kubelet, slave-1.shared  Container liveness-exec-pod-container failed liveness probe, will be restarted
      [root@master-0 ~]# kubectl get pods -w
      NAME                READY   STATUS    RESTARTS   AGE
      liveness-exec-pod   1/1     Running   3          2m12s
      pod-demo            2/2     Running   7          5d23h
      
    2. TCPSocketAction 探测语法

      [root@master-0 ~]# kubectl explain pods.spec.containers.livenessProbe.tcpSocket
      KIND:     Pod
      VERSION:  v1
      
      RESOURCE: tcpSocket <Object>
      
      DESCRIPTION:
          TCPSocket specifies an action involving a TCP port. TCP hooks not yet
          supported
      
          TCPSocketAction describes an action based on opening a socket
      
      FIELDS:
      host <string>
          Optional: Host name to connect to, defaults to the pod IP.
      
      port <string> -required-
          Number or name of the port to access on the container. Number must be in
          the range 1 to 65535. Name must be an IANA_SVC_NAME.
      
    3. HTTPGetAction 探测语法

      [root@master-0 ~]# kubectl explain pods.spec.containers.livenessProbe.httpGet
      KIND:     Pod
      VERSION:  v1
      
      RESOURCE: httpGet <Object>
      
      DESCRIPTION:
          HTTPGet specifies the http request to perform.
      
          HTTPGetAction describes an action based on HTTP Get requests.
      
      FIELDS:
      host <string>           #主机
          Host name to connect to, defaults to the pod IP. You probably want to set
          "Host" in httpHeaders instead.
      
      httpHeaders <[]Object>  #自定义在请求报文中发什么请求守护
          Custom headers to set in the request. HTTP allows repeated headers.
      
      path <string>           #URL
          Path to access on the HTTP server.
      
      port <string> -required-    #端口
          Name or number of the port to access on the container. Number must be in
          the range 1 to 65535. Name must be an IANA_SVC_NAME.
      
      scheme <string>
          Scheme to use for connecting to the host. Defaults to HTTP.
      [root@master-0 ~]# vim liveness-httpget.yaml
      apiVersion: v1
      kind: Pod
      metadata:
        name: liveness-httpget-container
        namespace: default
      spec:
        containers:
        - name: liveness-httpget-container
          image: nginx:latest
          imagePullPolicy: IfNotPresent
          ports:
          - name: http
            containerPort: 80
          livenessProbe:
            httpGet:
              port: http
              path: /index.html
            initialDelaySeconds: 1
            periodSeconds: 3
      [root@master-0 ~]# kubectl create -f liveness-httpget.yaml
      pod/liveness-httpget-container created
      [root@master-0 ~]# kubectl describe pods liveness-httpget-container
      Name:         liveness-httpget-container
      Namespace:    default
      Priority:     0
      Node:         slave-1.shared/10.211.55.37
      Start Time:   Tue, 07 Apr 2020 05:07:44 -0400
      Labels:       <none>
      Annotations:  <none>
      Status:       Running
      IP:           10.244.1.7
      IPs:
      IP:  10.244.1.7
      Containers:
      liveness-httpget-container:
          Container ID:   docker://398df0adc6b016d2013a78410a0a0a2bb333ea1216f8f1672048fc55cce9cf59
          Image:          nginx:latest
          Image ID:       docker-pullable://nginx@sha256:282530fcb7cd19f3848c7b611043f82ae4be3781cb00105a1d593d7e6286b596
          Port:           80/TCP
          Host Port:      0/TCP
          State:          Running
          Started:      Tue, 07 Apr 2020 05:07:44 -0400
          Ready:          True
          Restart Count:  0
          Liveness:       http-get http://:http/index.html delay=1s timeout=1s period=3s #success=1 #failure=3
          Environment:    <none>
          Mounts:
          /var/run/secrets/kubernetes.io/serviceaccount from default-token-lbf5s (ro)
      Conditions:
      Type              Status
      Initialized       True
      Ready             True
      ContainersReady   True
      PodScheduled      True
      Volumes:
      default-token-lbf5s:
          Type:        Secret (a volume populated by a Secret)
          SecretName:  default-token-lbf5s
          Optional:    false
      QoS Class:       BestEffort
      Node-Selectors:  <none>
      Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                      node.kubernetes.io/unreachable:NoExecute for 300s
      Events:
      Type    Reason     Age        From                     Message
      ----    ------     ----       ----                     -------
      Normal  Scheduled  <unknown>  default-scheduler        Successfully assigned default/liveness-httpget-container to slave-1.shared
      Normal  Pulled     66s        kubelet, slave-1.shared  Container image "nginx:latest" already present on machine
      Normal  Created    66s        kubelet, slave-1.shared  Created container liveness-httpget-container
      Normal  Started    66s        kubelet, slave-1.shared  Started container liveness-httpget-container
      

    livenessprobe探测失败时会重启pod,而readinessprbe探测失败会让pod处于非就绪情况从而不加入service的调度中

    [root@master-0 ~]# cat readiness-httpget.yaml
    apiVersion: v1
    kind: Pod
    metadata:
      name: liveness-httpget-container
      namespace: default
    spec:
      containers:
      - name: liveness-httpget-container
        image: nginx:latest
        imagePullPolicy: IfNotPresent
        ports:
        - name: http
          containerPort: 80
        readinessProbe:
          httpGet:
            port: http
            path: /index.html
          initialDelaySeconds: 1
          periodSeconds: 3
    

    lifecycle钩子

    一般配合 gitlab 使用

    [root@master-0 ~]# kubectl explain pods.spec.containers.lifecycle
    KIND:     Pod
    VERSION:  v1
    
    RESOURCE: lifecycle <Object>
    
    DESCRIPTION:
         Actions that the management system should take in response to container
         lifecycle events. Cannot be updated.
    
         Lifecycle describes actions that the management system should take in
         response to container lifecycle events. For the PostStart and PreStop
         lifecycle handlers, management of the container blocks until the action is
         complete, unless the container process fails, in which case the handler is
         aborted.
    
    FIELDS:
       postStart <Object>       #启动前
         PostStart is called immediately after a container is created. If the
         handler fails, the container is terminated and restarted according to its
         restart policy. Other management of the container blocks until the hook
         completes. More info:
         https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks
    
       preStop <Object>         #结束后
         PreStop is called immediately before a container is terminated due to an
         API request or management event such as liveness/startup probe failure,
         preemption, resource contention, etc. The handler is not called if the
         container crashes or exits. The reason for termination is passed to the
         handler. The Pod's termination grace period countdown begins before the
         PreStop hooked is executed. Regardless of the outcome of the handler, the
         container will eventually terminate within the Pod's termination grace
         period. Other management of the container blocks until the hook completes
         or until the termination grace period is reached. More info:
         https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks
    [root@master-0 ~]# cat poststart-pod.yaml
    apiVersion: v1
    kind: Pod
    metadata:
      name: poststart-pod
      namespace: default
    spec:
      containers:
      - name: busbox-httpd
        image: busbox:latest
        imagePullPolicy: IfNotPresent
        lifecycle:
          postStart:
            exec:
              command: ['mkdir','-p','/data/web/html']
        command: ['/bin/sh','-c','sleep 36000']
        #command: ["/bin/httpd"]            # 这样写会有一个问题,当运行时由于lifecycle是启动后运行的,所以此时的command运行时还没有/data/web/html,所以会报错,他们不能进行强依赖
        #args: ["-f","-h /data/web/html"]
    
    展开全文
  • pod生命周期

    2020-12-13 14:41:07
    pod生命周期 运行主容器(main container)过程 容器启动后钩子(post start) 、容器终止前钩子(pre stop) 容器的存活性探测(liveness probe) 、就绪性探测(readiness probe) 在整个生命周期中,Pod会出现5种状态...

    pod生命周期

    运行主容器(main container)过程

    • 容器启动后钩子(post start) 、容器终止前钩子(pre stop)
    • 容器的存活性探测(liveness probe) 、就绪性探测(readiness probe)

    在这里插入图片描述

    在整个生命周期中,Pod会出现5种状态(相位),分别如下:

    • 挂起(Pending) : apiserver已经创建了pod资源对象,但它尚未被调度完成或者仍处于下载镜像的过程中
    • 运行中(Running) : pod已经被调度至某节点,并且所有容器都已经被kubelet创建完成
    • 成功(Succeeded) : pod中的所有容器都已经成功终止并且不会被重启
    • 失败(Failed):所有容器都已经终止,但至少有一个容器终止失败,即容器返回了非0值的退出状态。
    • 未知(Unknown) : apiserver无法正常获取到pod对象的状态信息,通常由网络通信失败所导致

    创建和终止

    pod的创建过程
    用户通过kubectl或其他api客户端提交需要创建的pod信息给apiServer
    apiServer开始生成pod对象的信息,并将信息存入etcd,然后返回确认信息至客户端
    apiServer开始反映etcd中的pod对象的变化,其它组件使用watch机制来跟踪检查apiServer上的变动
    scheduler发现有新的pod对象要创建,开始为Pod分配主机并将结果信息更新至apiServer
    node节点上的kubelet发现有pod调度过来,尝试调用docker启动容器,并将结果回送至
    apiServer6. apiServer将接收到的pod状态信息存入etcd中

    pod的终止过程

    1. 用户向apiServer发送删除pod对象的命令
    2. apiServcer中的pod对象信息会随着时间的推移而更新,在宽限期内(默认30s), pod被视为dead
    3. 将pod标记为terminating状态
    4. kubelet在监控到pod对象转为terminating状态的同时启动pod关闭过程
    5. 端点控制器监控到pod对象的关闭行为时将其从所有匹配到此端点的service资源的端点列表中移除
    6. 如果当前pod对象定义了preStop钩子处理器,则在其标记为terminating后即会以同步的方式启动执行
    7. pod对象中的容器进程收到停止信号
    8. 宽限期结束后,若pod中还存在仍在运行的进程,那么pod对象会收到立即终止的信号
    9. kubelet请求apiServer将此pod资源的宽限期设置为0从而完成删除操作,此时pod对于用户已不可见

    初始化容器

    初始化容器是在pod的主容器启动之前要运行的容器,主要是做一些主容器的前置工作,它具有两大特征:

    1. 初始化容器必须运行完成直至结束,若某初始化容器运行失败,那么kubernetes需要重启它直到成功完成
    2. 初始化容器必须按照定义的顺序执行,当且仅当前一个成功之后,后面的一个才能运行

    初始化容器有很多的应用场景,下面列出的是最常见的几个:

    • 提供主容器镜像中不具备的工具程序或自定义代码
    • 初始化容器要先于应用容器串行启动并运行完成,因此可用于延后应用容器的启动直至其依赖的条件得到满足接下来做—个案例,模拟下面这个需求:

    假设要以主容器来运行nginx,但是要求在运行nginx之前先要能够连接上mysql和redis所在 服务器
    为了简化测试,事先规定好mysq和redis 服务器的地址

    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    展开全文
  • Pod 生命周期

    2020-04-10 10:36:55
    文章目录Pod 阶段Pod 状态(conditions)容器探针pod和容器 status容器 statespod就绪gate重启策略pod 生命周期 Pod 阶段 Pending 下载镜像 Running 全部pod已经绑定节点,全部镜像已经创建。至少一个容器正在运行...

    翻译官方文档

    Pod 阶段

    • Pending 下载镜像
    • Running 全部pod已经绑定节点,全部镜像已经创建。至少一个容器正在运行或者正在启动/重启
    • Succedded 全部容器成功终止,不会重启
    • Failed 所有容器都终止了,至少一个容器因故障终止,也就是非零退出或者被系统终止
    • Unknown 获取不到pod的状态,典型原因是与节点通信错误

    Pod 状态(conditions)

    • PodScheduled
    • Ready
    • Inintialized
    • ContarinersReady

    容器探针

    kubelet调用容器实现的handler执行诊断

    • ExecAction 执行命令,返回为0
    • TCPSocketAction tcp端口打开
    • HTTPGetAction Get请求返回的http状态码在200-400之间

    探针状态

    • Success
    • Failure
    • Unknown

    三种探针:

    • livenessProbe 探测容器是否running,如果失败,kubelet kill容器,容器根据restart policy策略执行相应动作,不提供这个探针,容器状态就是Success
    • redinessProbe 如果失败,endpoint controller 将pod的ip从service的endpoints中移除,在initial delay之前是Failure状态,不提供这个探针,容器状态就是Success
    • startupProbe 如果提供了这个探针,在它成功之前,其他探针都disabled。如果失败,kubelet kill容器,容器根据restart policy策略执行相应动作,不提供这个探针,容器状态就是Success

    何时使用存活探针?

    • 容器里的进程在遇到问题或变得不正常时能自行崩溃,就不需要。
    • 如果容器启动时需要加载大量数据、配置文件或者迁移,就设置就绪探针,使它不在启动以后立即接收流量。删除pod时,它自动进入unready状态
    • 如果容器启动时间通常超过initialDelaySeconds + failureThreshold * periodSeconds,应该指定一个和存活探针检查相同endpoint的启动探针

    pod和容器 status

    上报的pod status依赖于当前的容器 status

    容器 states

    pod被调度器指定节点后,kebelet开始用容器运行时创建容器。

    • Waiting 拉取镜像或者应用secrets等,Reason有说明信息
    • Running postStart钩子在容器进入running状态之前执行
    • Terminated 正常或者异常终止,preStop钩子执行后进入这个状态

    pod就绪gate

    v1.14 Pod Ready++

    重启策略

    针对pod设置,对pod的所有容器生效。重启延迟倍数增长(10s,20s,40s…),5分钟封顶,成功执行10分钟后重置。

    • Always
    • OnFailure

    pod 生命周期

    控制平面会清理终止的pod(succeded或者failed的),当pod数超过kube-controller-manager设置的terminated-pod-gc-threshold以后。

    三类控制器可用:

    • 期望终止:job的pod的重启策略必须是Onfailure或者Never
    • 不期望终止:ReplicationController, ReplicaSet, or Deployment
    • DaemonSet

    如果容器success退出,OnFailure重启策略就不重启容器了

    状态实例:

    • pod running 只有一个容器,容器成功退出
      • Log completion event
      • Always:重启容器,pod running
      • OnFailure: pod succedded
      • Never: pod succedded
    • pod running 只有一个容器,容器失败退出
      • Log failure event.
      • Always:重启容器,pod running
      • OnFailure: 重启容器,pod running
      • Never: pod Failed
    • pod running 有两个容器,容器1失败退出
      • Log failure event.
      • Always:重启容器,pod running
      • OnFailure: 重启容器,pod running
      • Never: 不重启容器,pod running
    • pod running 有两个容器,容器1 不是running,容器2失败退出
      • Log failure event.
      • Always:重启容器,pod running
      • OnFailure: 重启容器,pod running
      • Never: pod Failed
    • pod running 有一个容器,容器内存不足
      • 容器终止failure
      • Log OOM event.
      • Always:重启容器,pod running
      • OnFailure: 重启容器,pod running
      • Never: pod Failed
    • pod running 磁盘掉了
      • 杀死所有容器
      • Log appropriate event.
      • pod 阶段变为Failed
      • 如果由控制器控制,在其他地方重启pod
    • pod running 节点失联
      • 节点控制器等待超时
      • 节点控制器置pod阶段为Failed
      • 如果由控制器控制,在其他地方重启pod
    展开全文
  • POD生命周期

    2020-07-23 12:32:41
    Pod 的运行阶段(phase)是 Pod 在其生命周期中的简单宏观概述。该阶段并不是对容器或 Pod 的综合汇总,也不是为了做为综合状态机 下面是 phase 可能的值: 挂起(Pending):Pod 已被 Kubernetes 系统接受,但有...
  • Kubernetes Pod 生命周期

    2020-11-06 18:11:48
    Kubernetes Pod 生命周期 文章目录Kubernetes Pod 生命周期Pod phasePod 状态容器探针该什么时候使用存活(liveness)和就绪(readiness)探针?Pod 和容器状态重启策略Pod 的生命示例高级 liveness 探针示例状态示例...
  • Kubernetes Pod生命周期

    2021-08-19 20:30:18
    一、Pod生命周期概述 我们一般将pod对象从创建到终止的这段时间范围称为pod的生命周期,它主要包含下面的过程: pod创建过程 1.运行初始化容器(init container)过程 2.运行主容器(main container)过程 - ...
  • pod 生命周期 pod phase

    2021-05-06 11:44:22
    Pod生命周期图 阶段说明 init 1. 在该阶段可以为容器预处理一些事情,比如容器启动后需要的一些历史数据的处理等等,但是该操作一定要保证幂等性; 2. init的执行时是串行的,只有前一个执行完毕,下一个才可以执行 ...
  • pod生命周期pod生命周期 pod生命周期 一般pod对象从创建至终止的这段时间范围称为pod的生命周期,他主要包含下面过程 pod的创建过程 运行初始化容器(init container)过程 运行主容器(main container)过程 * ...
  • K8S之pod生命周期

    2021-03-27 09:24:50
    K8S之pod生命周期 Pod的基本概念 最小的部署单元 一组容器的集合 一个Pod中的容器共享网络命名空间和存储卷 Pod是短暂的 Pod存在的意义 Pod为亲密性应用而存在 亲密性应用场景: 两个应用之间发生文件...
  • 4月15日-5 Pod生命周期管理.pdf
  • Kubernetes的Pod生命周期

    2020-07-29 17:32:33
    一、Pod生命周期 Pod对象自从创建开始至终止退出的时间范围称为生命周期,在这段时间中,Pod会处于多种不同的状态,并执行一些操作。其中,创建主容器为必须的操作,其他可选的操作包括运行初始化容器(init ...
  • Pod生命周期一、Pod的phase二、Pod的状态三、init容器init容器介绍Init 容器能做什么?init容器举例:四、容器探针理解探针重启策略Pod 的生命livenessProbe存活探测示例readinessProbe就绪检测示例:livenessProbe ...
  • k8sd之pod生命周期

    2019-09-30 18:57:16
    pod生命周期: 状态:pending挂起 没有节点满足条件 running运行 Failed sucess unkonwn pod生命周期中的重要行为: 初始化容器 容器探测:liveness probe 探测容器是否活着 探测容器 存活性探针 ...
  • kubernetes一、pod生命周期二、探针2.1 认识探针2.2 使用探针2.3 做存活检测(liveness)2.4 准备就绪检测(readinessProbe) 一、pod生命周期 查看pod上的namespace [kubeadm@server2 ~]$ kubectl get pod -n ...
  • Kubernetes1.3:POD生命周期管理

    万次阅读 2016-08-26 08:10:07
    Pod是kubernetes中的核心概念,kubernetes对于Pod的管理也就是对Pod生命周期的管理,对Pod生命周期的管理也就是对Pod状态的管理,我们通过下面Pod相关的各个实体信息关系图可以分析出来kubernetes是如何管理Pod状态...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 12,935
精华内容 5,174
关键字:

pod生命周期