k8s之深入解剖Pod(二)

目录:

  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

  

 

k8s之深入解剖Pod(二)

 

查看创建的ConfigMap:

kubectl get cm
或
kubectl get configmap

  

 

k8s之深入解剖Pod(二)

 

查看ConfigMap的详细内容:

kubectl describe cm/cm-1

  

 

k8s之深入解剖Pod(二)

 

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创建一条数据

 

k8s之深入解剖Pod(二)

 

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

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

 

k8s之深入解剖Pod(二)

 

使用如下命令创建:

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

  

 

k8s之深入解剖Pod(二)

 

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

 

k8s之深入解剖Pod(二)

 

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

例如:创建一个key为name,value为Liusy的configmap数据

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

  

 

k8s之深入解剖Pod(二)

 

(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后进入容器:

 

k8s之深入解剖Pod(二)

 

查看环境变量:

 

k8s之深入解剖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后进入容器:

 

k8s之深入解剖Pod(二)

 

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

 

k8s之深入解剖Pod(二)

 

(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之后进入容器查看相应的环境变量:

 

k8s之深入解剖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后进入容器查看:

 

k8s之深入解剖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目录下:

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

 

k8s之深入解剖Pod(二)

 

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

Pod的状态包括以下几种:

 

k8s之深入解剖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

  

 

k8s之深入解剖Pod(二)

 

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

(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后创建此目录,看容器健康检测情况

 

k8s之深入解剖Pod(二)

 

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

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

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

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

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

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

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

发表评论

评论已关闭。

相关文章