深入理解Pod（二）
目录：
Pod配置管理：ConfigMap
容器内获取Pod信息：Downward API
Pod生命周期和重启策略
Pod健康检查
ConfigMap
将应用所需的配置信息与程序进行分离，可以使应用程序更好的被复用，通过不同的配置实现更灵活的功能。如果将应用打包成镜像，再用环境变量或者外挂文件的方式挂载配置，在大型容器集群中会变得异常繁琐，所以出现了统一的配置管理：ConfigMap
（1）ConfigMap：容器应用的配置管理
典型用法如下：
1、生成为容器内的环境变量
2、设置容器启动命令的启动参数（需设置为环境变量）
3、以Volume的形式挂载为容器内部的文件或目录
ConfigMap以一个或多个key：value的形式保存在k8s系统中供应用使用，既可以用于表示一个变量的值，也可以表示一个完整配置文件的内容。
（2）创建方式
通过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
通过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环境变量方式
本文创建一个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中配置的路径
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信息注入容器内部。
环境变量
用于单个变量（也就是在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后进入容器查看：
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的状态包括以下几种：
状态值 | 描述 |
|---|---|
Pending | API Server已经创建该Pod，但Pod内还存在有容器的镜像没有被创建，包括正在下载 |
Running | Pod内所有容器均已创建，且至少有一个容器处于运行状态、正在启动状态或正在重启状态 |
Succeeded | 所有容器均已成功执行退出，且不会再重启 |
Failed | 所有容器均已退出，至少有一个容器处于退出失败的状态 |
Unknow | 无法获取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
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: 1ReadinessProbe
用于判断容器是否启动完成（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