Pod 状态管理

在容器内获取Pod信息（Downward API）

Downward API有提供了两种方式来实现从容器内部获取POD信息的方法：

  • 环境变量的方式
  • Downward API 卷文件挂载

通过这两种方式，可以将pod的标签信息，资源信息，状态信息传递到Pod内部。

环境变量方式-将Pod信息注入为环境变量

参考链接

1、使用pod参数方式

使用如下文件：

apiVersion: v1
kind: Pod
metadata:
  name: envars-pod
spec:
  containers:
    - name: test-container
      image: busybox
      command: [ "sh", "-c"]
      args:
      - while true; do
          echo -en ‘\n‘;
          printenv MY_NODE_NAME MY_POD_NAME MY_POD_NAMESPACE;
          printenv MY_POD_IP MY_POD_SERVICE_ACCOUNT;
          sleep 10;
        done;
      env:
        - name: MY_NODE_NAME
          valueFrom:
            fieldRef:
              fieldPath: spec.nodeName
        - name: MY_POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: MY_POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        - name: MY_POD_IP
          valueFrom:
            fieldRef:
              fieldPath: status.podIP
        - name: MY_POD_SERVICE_ACCOUNT
          valueFrom:
            fieldRef:
              fieldPath: spec.serviceAccountName
  restartPolicy: Never

创建pod之后，通过logs查看：

# kubectl logs envars-pod

10.0.0.3
envars-pod
default
10.2.6.23
default

登录pod,可以直接查看，发现环境变量中已经加载了这些参数：

kubectl exec -it  envars-pod -- sh

/ # env
MY_POD_SERVICE_ACCOUNT=default
KUBERNETES_SERVICE_PORT=443
KUBERNETES_PORT=tcp://10.1.0.1:443
HOSTNAME=envars-pod
SHLVL=1
HOME=/root
MY_POD_NAMESPACE=default
TERM=xterm
MY_POD_IP=10.2.6.23
KUBERNETES_PORT_443_TCP_ADDR=10.1.0.1
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
KUBERNETES_PORT_443_TCP_PORT=443
KUBERNETES_PORT_443_TCP_PROTO=tcp
MY_NODE_NAME=10.0.0.3
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_PORT_443_TCP=tcp://10.1.0.1:443
KUBERNETES_SERVICE_HOST=10.1.0.1
PWD=/
MY_POD_NAME=envars-pod

通过yaml文件中指定的valueFrom这种方式的Downward语法获取相关Pod信息。

2、 使用容器参数方式

如下文件：

apiVersion: v1
kind: Pod
metadata:
  name: envars-con
spec:
  containers:
    - name: test-container
      image: busybox:1.24
      command: [ "sh", "-c"]
      args:
      - while true; do
          echo -en ‘\n‘;
          printenv MY_CPU_REQUEST MY_CPU_LIMIT;
          printenv MY_MEM_REQUEST MY_MEM_LIMIT;
          sleep 10;
        done;
      resources:
        requests:
          memory: "32Mi"
          cpu: "125m"
        limits:
          memory: "64Mi"
          cpu: "250m"
      env:
        - name: MY_CPU_REQUEST
          valueFrom:
            resourceFieldRef:
              containerName: test-container
              resource: requests.cpu
        - name: MY_CPU_LIMIT
          valueFrom:
            resourceFieldRef:
              containerName: test-container
              resource: limits.cpu
        - name: MY_MEM_REQUEST
          valueFrom:
            resourceFieldRef:
              containerName: test-container
              resource: requests.memory
        - name: MY_MEM_LIMIT
          valueFrom:
            resourceFieldRef:
              containerName: test-container
              resource: limits.memory
  restartPolicy: Never

运行此pod，查看日志：

1
1
33554432
67108864

使用volume方式

参考链接

1、使用Pod 参数
创建如下文件：

apiVersion: v1
kind: Pod
metadata:
  name: kubernetes-downwardapi-volume-example
  labels:
    zone: us-est-coast
    cluster: test-cluster1
    rack: rack-22
  annotations:
    build: two
    builder: john-doe
spec:
  containers:
    - name: client-container
      image: busybox
      command: ["sh", "-c"]
      args:
      - while true; do
          if [[ -e /etc/podinfo/labels ]]; then
            echo -en ‘\n\n‘; cat /etc/podinfo/labels; fi;
          if [[ -e /etc/podinfo/annotations ]]; then
            echo -en ‘\n\n‘; cat /etc/podinfo/annotations; fi;
          sleep 5;
        done;
      volumeMounts:
        - name: podinfo
          mountPath: /etc/podinfo
          readOnly: false
  volumes:
    - name: podinfo
      downwardAPI:
        items:
          - path: "labels"
            fieldRef:
              fieldPath: metadata.labels
          - path: "annotations"
            fieldRef:
              fieldPath: metadata.annotations

通过downward API的volume方式，将pod的labels中的所有参数和annotations中的所有参数传递给了pod内。
在对应的路径下，有一个隐藏的文件目录，存放了这两个文件。

2、通容器参数传递资源配额
如下Pod文件：

apiVersion: v1
kind: Pod
metadata:
  name: kubernetes-downwardapi-volume-example-2
spec:
  containers:
    - name: client-container
      image: k8s.gcr.io/busybox:1.24
      command: ["sh", "-c"]
      args:
      - while true; do
          echo -en ‘\n‘;
          if [[ -e /etc/podinfo/cpu_limit ]]; then
            echo -en ‘\n‘; cat /etc/podinfo/cpu_limit; fi;
          if [[ -e /etc/podinfo/cpu_request ]]; then
            echo -en ‘\n‘; cat /etc/podinfo/cpu_request; fi;
          if [[ -e /etc/podinfo/mem_limit ]]; then
            echo -en ‘\n‘; cat /etc/podinfo/mem_limit; fi;
          if [[ -e /etc/podinfo/mem_request ]]; then
            echo -en ‘\n‘; cat /etc/podinfo/mem_request; fi;
          sleep 5;
        done;
      resources:
        requests:
          memory: "32Mi"
          cpu: "125m"
        limits:
          memory: "64Mi"
          cpu: "250m"
      volumeMounts:
        - name: podinfo
          mountPath: /etc/podinfo
          readOnly: false
  volumes:
    - name: podinfo
      downwardAPI:
        items:
          - path: "cpu_limit"
            resourceFieldRef:
              containerName: client-container
              resource: limits.cpu
          - path: "cpu_request"
            resourceFieldRef:
              containerName: client-container
              resource: requests.cpu
          - path: "mem_limit"
            resourceFieldRef:
              containerName: client-container
              resource: limits.memory
          - path: "mem_request"
            resourceFieldRef:
              containerName: client-container
              resource: requests.memory

通过如下方式，查看pod中传递的参数：

kubectl exec -it kubernetes-downwardapi-volume-example-2 -- sh
/# cat /etc/podinfo/cpu_limit

Downward API的应用主要是在某些场景中，集群中的每个节点将需要将自身的标识（ID）及进程绑定IP地址等信息事先写入配置文件中，进程启动时读取这些信息发布到服务的注册中心，实现集群节点的自动发现功能。

Pod生命周期和重启策略

Pod的常见状态

当我们执行kubectl describe pod <pod-name>时，会发现Pod都会有一个状态值，下面列举了Pod的5中状态：

  • Pending: API server 已经创建该Pod,但是Pod内还有一个或多个容器镜像没有创建，一般是在下载镜像。
  • Running: Pod内的所有容器均已经创建，且至少有一个容器处于运行状态、正在启动或重启状态。
  • Succeeded: Pod内所有容器均已经成功执行退出，且不再重启
  • Failed: Pod内所有容器均已退出，但至少有一个容器退出为失败状态。
  • Unknown: 由于某种原因无法获取Pod状态，可能由于网络通信不畅导致。

Pod重启策略（RestartPolicy）

Pod的重启策略应用于Pod中的所有容器，并且仅在Pod所处的Node上由Kubelet进行判断和重启操作。
RestartPolicy包含三个设定：

  • Always: 当容器失效时，由kubelet自动重启该容器。
  • OnFailure: 当容器终止运行且退出码不为0时，由Kubelet自动重启该容器。
  • Never: 不论容器的运行状态如何，Kubelet都不会重启该容器。
    当管理Pod的控制包括ReplicationController、Job、DaemonSet以及直接通过Kubelet管理（静态Pod），对应的控制器对Pod的重启策略要求如下：
  • RC和DaemonSet，ReplicaSet，Deployment： 必须设置为Always，需要保证容器的持续运行
  • Job: OnFailure 或Never,确保容器不再执行
  • kubelet: 在Pod失效时自动重启它，不论将RestartPolicy设置为什么值，也不会对Pod进行健康检查。

Pod健康检查

对Pod的健康状态检查可以通过两类探针来检查：LivenessProbe和ReadinessProbe。

  • livenessProbe: 判断容器是否存活（running）,如果检测到容器不健康，则kubelet将杀掉该容器，并根据容器的重启策略做相应的处理。如果容器不包含LivenessProbe探针，则返回永远是Success。
  • readinessProbe: 用于判断容器是否启动完成（ready），可以接受请求。如果ReadinessProbe探针检测到失败，则Pod的状态将被修改。Endpoint Controller将从Service的EndPoint中删除包含该容器所在的Pod的EndPoint。

容器的探针对容器有3中实现方式：

  • ExecAction： 在容器内执行一条命令，如果命令的返回码为0，则表示容器健康。
  • TCPSocketAction: 通过容器的端口号和IP地址执行TCP检测，如果能够建立TCP连接表示容器健康。
  • HTTPGetAction: 通过容器的IP地址、端口号及路径调用HTTP Get方法，如果相应的状态码大于等于200且小于400，则认为容器状态健康。

下面是对应的三个示例，阐述了这3中实现方式：

1、使用ExecAction方式:

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                  # 每隔5s 检查一次
      timeoutSeconds: 1                 # 健康检查发送请求后的等待响应时间，默认为1S，超时无响应，则会认为无法提供服务，kubelet会重启该容器。

通过如下命令，可以查看到pod的健康状态和重启次数：

kubectl get pod -o wide
kubectl describe pod liveness-exec

2、使用TCPSockAction
如下文件示例：

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80
    readinessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 10
    livenessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 15
      periodSeconds: 20

3、使用HTTPGetAction

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: mirrorgooglecontainers/liveness
    args:
    - /server
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: X-Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

readinessProbe 和livenessProbe 用法十分相似，只需要把 readinessProbe替换为livenessProbe即可。它们可以同时使用在同一个容器上，来确保流量不会流入未准备好的容器，并且让容器在失败的时候重新启动。

原文地址：http://blog.51cto.com/tryingstuff/2130287

时间： 2024-11-01 21:35:46

Pod 状态管理的相关文章

k8s的Pod状态和生命周期管理

Pod状态和生命周期管理 一.什么是Pod? 二.Pod中如何管理多个容器? 三.使用Pod 四.Pod的持久性和终止 五.Pause容器 六.init容器 七.Pod的生命周期 (1)Pod phase(Pod的相位) (2)Pod的创建过程 (3)Pod的状态 (4)Pod存活性探测 (5)livenessProbe和readinessProbe使用场景 (6)Pod的重启策略 (7)Pod的生命 (8)livenessProbe解析 一.什么是Pod? Pod是kubernetes中你可以

# IT明星不是梦 #图解kubernetes容器探活机制核心实现状态管理

k8s为实现容器探活worker的管理构建了一个Manager组件,该组件负责底层探活worker的管理,并且缓存当前的容器的状态,并对外同步容器的当前状态,今天我们就来分析下其部分核心组件 1. 核心原理实现 Manager缓存的状态主要是会被kubelet.状态组件消费,并且在Pod同步状态的时候,会通过当前Manager里面的探测状态来更新Pod的容器的就绪与启动状态的更新,让我们一起看看Manager自身的一些关键实现吧 2. 探活结果管理 即prober/results/results

状态管理cookie和session

是由php提供的,session开关要放在代码最前面,session是保存在服务器的一般保存20分钟,cookie是保存在客户端的随便给值. 状态管理cookie和session,布布扣,bubuko.com

结合项目学习vue2(路由vue-router，状态管理vuex)

前期: index.html <div id="app"> <h1>{{intro}}</h1> <router-view></router-view> </div> app.js var App = new Vue({ router,//router:router的缩写 //传一个路由属性给 Vue 实例,路由现在被定义为一个在 router 实例里的一个routes 选项数组 data: { intro: &q

[原创]java WEB学习笔记28： 会话与状态管理Cookie 机制

1.会话与状态管理 1)背景 ① HTTP协议是一种无状态的协议,WEB服务器本身不能识别出哪些请求是同一个浏览器发出的 ,浏览器的每一次请求都是完全孤立的: ② 作为 web 服务器,必须能够采用一种机制来唯一地标识一个用户,同时记录该用户的状态: ③ 问题:怎么才能实现网上商店中的购物车呢:某个用户从网站的登录页面登入后,再进入购物页面购物时,负责处理购物请求的服务器程序必须知道处理上一次请求的程序所得到的用户信息. 2)会话和会话状态 ① WEB应用中的会话:指一个客户端浏览器与WEB服务

web应用程序的状态管理

一.Web应用程序状态形式1.表单隐藏字段2.cookie——把用户状态信息通过服务器发送到客户端浏览器中保存3.Session会话跟踪,服务器为客户端创建并维护的用于存放客户状态数据的session对象4.URL地址重写.(一)cookie 1:Cookie原理: 服务器在响应请求时将一些数据以“键-值”对的形式通过响应信息保存在客户端,当浏览器再次访问相同的应用时,会将原先的Cookie通过请求信息带到服务器端. Cookie cookie = new Cookie("cool",

HttpClient第三章 HTTP状态管理

原始的HTTP被设置成无状态的面向请求响应的协议,它并没有为基于跨几个逻辑相关的请求/响应交换的有状态会话提供所需的功能.但是随着HTTP协议越来越流行并且被应用,越来越多的系统开始用它作为原本并不是它的作用的功能,例如,电子商务传输应用,这样一来,对于状态管理的支持成为一个必要的功能. 那时网景公司作为一个web客户端和服务器端软件的领导开发者在他们的一个基于特殊的说明的产品里实现了对HTTP状态管理的支持,后来,网景通过发布一个知指导说明书试图标准化这一机制.这些努力促成了通过RFC标准的正

ASP.NET状态管理详解，让你明明白白

开发WinFrom的程序员可能不会在意维护应用程序的状态,因为WinFrom本身就在客户端运行,可以直接在内存中维护其应用程序状态.但ASP.NET应用程序在服务器端运行,客户端使用无状态的http协议对ASP.NET应用程序发出请求,ASP.NET应用程序响应用户请求,向客户端发送请求的HTML代码,服务器并不会维护任何客户端状态.考虑一个有成千上万并发用户的服务器,如果为每一个用户都维护状态的话会耗费非常多的资源. 由于使用无状态的http协议作为web应用程序的通信协议,当客户端每次请求页

状态管理（用户登录）

1.session:在服务器上保存. 打开session:session_start();要放在代码的最前面.    浏览器默认保存20分钟, 清除session:unset($...);session_destroy();. 2.cookie:在客户端上保存,不安全. setcookie("","","");里面3个变量分别表示1设置名字2值3保存多长时间(time()+数字(多少秒)), 需要再次刷新页面才能显示. 状态管理(用户登录),布布