首页 > 其他分享> 文章详细

k8s之深入解剖Pod（二）

2020-12-21 22:34:15 阅读：186 来源： 互联网

标签：容器 name cm ConfigMap 创建 Pod k8s 解剖

　　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大神。

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

标签：容器,name,cm,ConfigMap,创建,Pod,k8s,解剖
来源： https://www.cnblogs.com/liusy01/p/14170491.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

ICode9