k8s之深刻解剖Pod（二）

时间  2021-08-14
标签 nginx 程序员 面试 api 数组 bash 微信 markdown tcp spa 栏目 Nginx 繁體版
原文   原文链接

目录：nginx

Pod配置管理：ConfigMap程序员

容器内获取Pod信息：Downward API面试

Pod生命周期和重启策略api

Pod健康检查数组

1、ConfigMapbash

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

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

典型用法以下：tcp

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

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

三、以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
复制代码

k8s之深刻解剖Pod（二）

查看建立的ConfigMap:

kubectl get cm
或
kubectl get configmap
复制代码

k8s之深刻解剖Pod（二）

查看ConfigMap的详细内容：

kubectl describe cm/cm-1
复制代码

k8s之深刻解剖Pod（二）

经过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
复制代码

环境变量方式

本文建立一个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中配置的路径

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

2、容器内获取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以后进入容器查看相应的环境变量：

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（二）

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（二）

3、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是什么值，而且也不会进行健康检查。

4、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
复制代码

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
复制代码

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

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

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程