k8s之深入解剖Pod（二）

2024-03-17 12:35:52

　　Pod配置管理：ConfigMap

　　容器内获取Pod信息：Downward API

　　Pod生命周期和重启策略

　　Pod健康检查

一、ConfigMap

将应用所需的配置信息与程序进行分离，可以使应用程序更好的被复用，通过不同的配置实现更灵活的功能。如果将应用打包成镜像，再用环境变量或者外挂文件的方式挂载配置，在大型容器集群中会变得异常繁琐，所以出现了统一的配置管理：ConfigMap

（1）ConfigMap：容器应用的配置管理

典型用法如下：

1、生成为容器内的环境变量

2、设置容器启动命令的启动参数（需设置为环境变量）

3、以Volume的形式挂载为容器内部的文件或目录

ConfigMap以一个或多个key：value的形式保存在k8s系统*应用使用，既可以用于表示一个变量的值，也可以表示一个完整配置文件的内容。

（2）创建方式

1、通过yaml文件进行创建

apiVersion: v1
kind: ConfigMap
metadata:
  name: cm-1
data:
  home_path: /usr/soft

需要将配置定义在data下面，上述yaml文件中在data中定义了一个key是home_path，value是/usr/soft的配置。

使用如下命令创建：

kubectl create -f cm_1.yaml

查看创建的ConfigMap:

kubectl get cm
或
kubectl get configmap

查看ConfigMap的详细内容：

kubectl describe cm/cm-1

2、通过kubectl命令行创建

直接通过kubectl create configmap，可使用参数--from-file或--from-literal指定内容，并且可以在一行命令中指定多个参数。

（1）通过--from-file参数从文件中进行创建，可以指定key的名称，也可以在一个命令行中创建包含多个key的ConfigMap

例如：在当前目录下创建一个文件名为config_1.conf，文件内容就是“value1”

使用如下命令创建configmap，名为config-1

kubectl create configmap config-1 --from-file=config_1.conf

查看：其会以文件名为key，文件内容为value创建一条数据

（2）通过--from-file参数从目录中进行创建，该目录下的每个配置文件名都被设置为key，文件的内容被设置为value

例如：在configmap目录下由三个文件

使用如下命令创建：

kubectl create configmap cm-name --from-file=file-dir

查看详细数据：其会以文件名作为key，文件内容作为value

（3）--from-literal从文本中进行创建，直接将指定的key=value创建为configmap的内容

例如：创建一个key为name，value为Liusy的configmap数据

kubectl create configmap cm-3 --from-literal=name=liusy

（3）ConfigMap使用

以上述常见的cm-1为例

apiVersion: v1
kind: ConfigMap
metadata:
  name: cm-1
data:
  home_path: /usr/soft

1、环境变量方式

本文创建一个Pod运行着nginx实例，在环境变量中使用cm-1的配置

apiVersion: v1
kind: Pod
metadata:
  name: cm-nginx
spec:
  containers:
  - name: cm-nginx
    image: nginx
    imagePullPolicy: IfNotPresent
    env:
    - name: home
      valueFrom:
        configMapKeyRef:
          name: cm-1
          key: home_path

创建好Pod后进入容器：

查看环境变量：

可以看到，home环境变量的值正是cm-1中配置的路径

2、volumeMount模式

比如定义一个Pod，其中定义一个volume，volume中引用名为cm-1的configmap，将key为home_path的value值写入homtpath.txt文件中，在容器中的configfiles目录上挂载这个volume

apiVersion: v1
kind: Pod
metadata:
  name: mount-pod
spec:
  volumes:
  - name: cm-volume
    configMap:
      name: cm-1
      items:
      - key: home_path
        path: homepath.txt
  containers:
  - name: mount-pod
    image: nginx
    imagePullPolicy: IfNotPresent
    volumeMounts:
    - name: cm-volume
      mountPath: /configfiles

创建Pod后进入容器：

可以看到，configfiles目录下确实生成了一个homepath.txt文件，来查看以下文件的内容：

（4）ConfigMap使用限制

ConfigMap必须在Pod之前创建
ConfigMap有Namespace限制，只有在同一Namespace下才可使用
静态Pod无法使用ConfigMap

二、容器内获取Pod信息：Downward API

在Pod创建之后，会被分配唯一的名字、IP地址，并处于某个Namespace中，那么这些信息在Pod中应该怎么获取呢，就是利用Downward API。

Downward API可以通过以下两种方式将Pod信息注入容器内部。

1、环境变量

用于单个变量（也就是在Pod定义中是单值的，非数组），可以将Pod信息和Container信息注入容器内部。

比如下例中将Pod的name、namespace、ip注入为环境变量

apiVersion: v1
kind: Pod
metadata:
  name: pod-name
  namespace: kube-system
spec:
  containers:
  - name: pod-name
    image: nginx
    imagePullPolicy: IfNotPresent
    env:
    - name: name
      valueFrom:
        fieldRef:
          fieldPath: metadata.name
    - name: ns
      valueFrom:
        fieldRef:
          fieldPath: metadata.namespace
    - name: ip
      valueFrom:
        fieldRef:
          fieldPath: status.podIP

创建Pod之后进入容器查看相应的环境变量：

又比如下例中将resource注入为环境变量

apiVersion: v1
kind: Pod
metadata:
  name: pod-name1
spec:
  containers:
  - name: c1
    image: nginx
    imagePullPolicy: IfNotPresent
    resources:
      requests:
        cpu: "125m"
        memory: "32Mi"
      limits:
        cpu: "250m"
        memory: "64Mi"
    env:
    - name: req_cpu
      valueFrom:
        resourceFieldRef:
          containerName: c1
          resource: requests.cpu
    - name: lim_cpu
      valueFrom:
        resourceFieldRef:
          containerName: c1
          resource: limits.cpu
    - name: lim_me
      valueFrom:
        resourceFieldRef:
          containerName: c1
          resource: limits.memory

创建Pod后进入容器查看：

2、volume挂载

将数组类信息生成为文件并挂载到容器内部。例如labels、annotations等

例如下例中将label信息通过volume挂载到容器的label目录

apiVersion: v1
kind: Pod
metadata:
  name: pod-volume
  labels:
    name: pod-volume
    age: zero
spec:
  containers:
  - name: c1
    image: nginx
    imagePullPolicy: IfNotPresent
    volumeMounts:
    - name: v-l
      mountPath: /labels
      readOnly: false
  volumes:
  - name: v-l
    downwardAPI:
      items:
      - path: "labels"
        fieldRef:
          fieldPath: metadata.labels

上述yaml中创建了一个volume，通过items设置，会生成path值的文件，文件的内容就是相应的信息，在容器中将volume挂载到/labels目录下：

创建之后进入容器查看文件：

三、Pod生命周期和重启策略

Pod的状态包括以下几种：

Pod的重启策略应用于Pod内的所有容器，并且仅在Pod所处的Node上有kubelet进行判断和重启操作，当某个容器异常退出或者健康检查失败时，kubelet将根据RestartPolicy设置进行相应的操作。在spec.restartPolicy中配置相应的重启策略

重启策略有如下三个：

spec:
  restartPolicy: [Always|Never|OnFailure]

Always：Pod一旦终止运行，kubelet都会进行重启，这也是默认值
Never：不会进行重启
OnFailure：容器非正常退出（即是退出码不为0），kubelet会重启容器，反之不会重启。

kubelet重启失效容器的时间间隔以sync-frequency乘以2n来计算，例如1,2,4,8等，最长延时5分钟，且在重启10分钟之后重置该时间。

Pod的重启策略与控制方式息息相关，当前可用于管理Pod的控制器包括RC，Job，DaemonSet及直接通过kubelet管理的静态Pod，每种控制器对Pod的重启策略如下：

RC、DaemonSet：必须设置为Always，保证容器持续运行
Job：OnFailure或Never，执行完就退出
kubelet：在Pod失效时自动重启它，不论RestartPolicy是什么值，并且也不会进行健康检查。

四、Pod健康检查

k8s提供了Pod健康检查机制，对于检测到故障服务会被及时自动下线，以及通过重启服务的方式使服务自动恢复。可通过两类探针来检查：LivenessProbe和ReadinessProbe

1、LivenessProbe

用于判断容器是否存活（running状态），如果探测到容器不健康，则kubelet杀掉此容器，并根据重启策略做相应的处理。

kubelet定期执行LivenessProbe来判断容器的健康状态，有三种实现方式：

（1）ExecAction

在容器内部执行一个命令，如果返回0，则表明容器健康。

apiVersion: v1
kind: Pod
metadata:
  name: live-exec
spec:
  containers:
  - name: live-exec
    image: nginx
    args:
    - /bin/sh
    - -c
    - echo ok > /tmp/health;sleep 10;rm -rf /tmp/health;sleep 1000
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/health
      initialDelaySeconds: 5
      timeoutSeconds: 1

上述yaml是在容器启动时将ok输出到/tem/health文件中，10s过后删除此文件。看效果：

kubectl describe  pods/live-exec

当文件被删除之后，探针探测到容器不健康，所以会进行重启

（2）TCPSocketAction

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

apiVersion: v1
kind: Pod
metadata:
  name: live-tcp
spec:
  containers:
  - name: live-tcp
    image: nginx
    imagePullPolicy: IfNotPresent
    livenessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 15
      timeoutSeconds: 1

（3）HttpGetAction

通过容器的IP、端口及路径调用HTTP Get方法，响应码大于200，小于400，容器健康

apiVersion: v1
kind: Pod
metadata:
  name: live-httpget
spec:
  containers:
  - name: live-httpget
    image: nginx
    imagePullPolicy: IfNotPresent
    livenessProbe:
      httpGet:
        path: /_status/healthz
        port: 80
        host: host
        scheme: HTTP
        httpHeaders:
        - name: string
          value: string
      initialDelaySeconds: 15
      timeoutSeconds: 1

2、ReadinessProbe

用于判断容器是否启动完成（ready状态），可接受请求。如果检测到失败，则Pod的状态将被修改。Endpoint Controller将从service的Endpoint中删除包含该容器所在Pod的Endpoint，此Pod不再接收请求。

此探针使用方式和上述livenessProbe相同。
例如：ExecAction方式

apiVersion: v1
kind: Pod
metadata:
  name: read-exec
spec:
  containers:
  - name: read-exec
    image: nginx
    command: ["/bin/bash","-c","mkdir /health;sleep 10;rm -rf /health;sleep 10;mkdir /health;sleep 600"]
    readinessProbe:
      exec:
        command: ["ls","/health"]
      initialDelaySeconds: 5
      timeoutSeconds: 1

上述yaml在容器启动创建一个目录，10s后删除，再10s后创建此目录，看容器健康检测情况

其在检测出容器启动失败后会定时去检测，不会重启容器，直至检测到容器健康。

对于每种探测方式，都需要配置以下两个参数：

initialDelaySeconds：启动后多久进行健康检查，单位是秒
timeoutSeconds：健康检查发送请求后的等待响应的超时时间，单位是s，超时未响应，则会重启该pod

===============================

我是Liusy，一个喜欢健身的程序员。

欢迎关注微信公众号【Liusy01】，一起交流Java技术及健身，获取更多干货，领取Java进阶干货，领取最新大厂面试资料，一起成为Java大神。

来都来了，关注一波再溜呗。

码农公寓