k8s pod生命周期、初始化容器、钩子函数、容器探测、重启策略（k8s和docker区别）

pod结构

Pause容器

Pause容器是每个Pod都会有的一个根容器，它的作用有两个

可以以它为根据，评估整个pod的健康状态

可以在根容器上设置IP地址，其他容器都以此IP（Pod IP），以实现Pod内部的网络通信，

这里是Pod内部的通讯，Pod之间的通讯采用虚拟二层网络技术来实现，我们当前环境用的是Flannel

pod配置

apiVersion: v1 #必选，版本号，例如v1 king: Pod #必选，资源类型，例如Pod metadata: name: string #必选，pod名称 namespace: string #pod所属的命名空间，默认为"default" labels: - name: string spec: #必选，pod中容器的详细定义 containers: #必选，pod中容器列表 - name: string #必选，容器名称 image: string #必选，容器镜像名称 imagePullPolicy: [Always|Never|IfNotPresent] #获取镜像的策略 command: [string] #容器的启动命令列表，如不指定，使用打包时使用的启动命令 args: [string] #容器的启动命令参数列表 workingDir: string #容器的工作目录 volumeMounts: #挂载到容器内部的存储卷配置 - name: string #引用pod定义的共享数据卷的名称，需用volumes[]部分定义的卷名 mountPath: string #存储卷在容器内mount的绝对路径，应少于512字符 readOnly: boolean #是否为只读模式 ports: 3需要暴露的端口库号列表 - name: string #端口的名称 containerPort: int #容器需要监听的端口号 hostPort: int #容器所在主机需要监听的端口号，默认与Container相同 protocol: string #端口协议，支持TCP和UDP，默认TCP env: #容器运行前需要设置的环境变量列表 - name: string #环境变量名称 value: string #环境变量的值 resources: #资源限制和请求的设置 limits: #资源限制的设置......

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

pod的资源配置非常繁多，因此要一个一个记住是不现实的

所以k8s提供了能够查看每种资源的配置项的命令

kubectl explain 资源类型 #查看某种资源可以配置的一级属性 kubectl explain 资源类型.属性 #查看属性的子属性

1

2

查看pod资源的metadata的子属性

kubectl explain pod.metadata

1

在k8s中所有资源的一级属性都是一样的，主要包含5部分：

apiVersion 版本，由k8s内部定义，版本号可以用 kubectl api-versions查询到

kind 类型，由k8s内部定义，可以用 kubectl api-resources查询到

metadata 元数据，主要是资源标识和说明，常用的有name，namespace，labels等

spec 描述，这是配置中最重要的一部分，里面是对各种资源配置的详细描述

status 状态信息，里面的内容不需要定义，由k8s自动生成

在上面的属性中，spect是接下来研究的重点，继续看下它的常见子属性：

containers <[]Object> 容器列表，用于定义容器的详细信息

nodeName 根据nodename的值将pod调度到指定的Node节点上

nodeSelector 根据NodeSelector中定义的信息选择将该Pod调度到包含这些label的node上

hostNetwork 是否使用主机网络模式，默认为false，如果设置为true，表示使用宿主机网络

volumes <[]Object> 存储卷，用于定义Pod上面挂载的存储信息

restartPolicy 重启策略，表示Pod在遇到故障的时候的处理策略;

pod生命周期

pod对象从创建到终止的这段时间范围被称为生命周期，它主要包含以下几个过程：

pod创建过程

运行初始化容器（init container）过程

运行主容器（main container）

容器启动后钩子（post start）、容器终止前钩子（pre stop）

容器的存活性探测（liveness probe）、就绪性探测（readiness probe）

pod终止过程

生命周期中出现的5种状态

pod创建过程

用户通过kubectl或其他api客户端提交需要创建的pod信息给apiServer

apiServer开始生成pod对象的信息，并将信息存入etcd，然后返回确认信息至客户端

apiServer开始反映etcd中的pod对象的变化，其它组件使用watch机制来跟踪检查apiServer上的变动

scheduler发现有新的pod对象要创建，开始为Pod分配主机并将结果信息更新至apiServer

node节点上的kubelet发现有pod调度过来，尝试调用docker启动容器，并将结果回送至apiServer

apiServer将接收到的pod状态信息存入etcd中

pod终止过程

用户向apiServer发送删除pod对象的命令

apiServcer中的pod对象信息会随着时间的推移而更新，在宽限期内（默认30s），pod被视为dead（死亡）

将pod标记为terminating（正在删除中）状态

kubelet在监控到pod对象转为terminating（正在删除中）状态的同时启动pod关闭过程

端点控制器监控到pod对象的关闭行为时将其从所有匹配到此端点的service资源的端点列表中移除

如果当前pod对象定义了preStop钩子处理器，则在其标记为terminating（正在删除中）后即会以同步的方式启动执行

pod对象中的容器进程收到停止信号

宽限期结束后，若pod中还存在仍在运行的进程，那么pod对象会收到立即终止的信号

kubelet请求apiServer将此pod资源的宽限期设置为0从而完成删除操作，此时pod对于用户已不可见

初始化容器

Pod能够具有多个容器，应用运行在容器里面，但是它也可能有一个或多个先于应用容器启动的 Init容器

Init 容器与普通的容器非常像，除了如下两点：

Init 容器总是运行到成功完成为止

每个 Init 容器都必须在下一个 Init 容器启动之前成功完成

如果 Pod 的 Init 容器失败， Kubernetes 会不断地重启该 Pod ，直到 Init 容器成功为止。然而，如果 Pod 对应的 restartPolicy（重启策略） 为 Never，它不会重新启动。

init容器能够做什么呢？

Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。

Init 容器可以安全地运行这些工具，避免这些工具导致应用镜像的安全性降低。

应用镜像的创建者和部署者可以各自独立工作，而没有必要联合构建一个单独的应用镜像。

Init 容器能以不同于Pod内应用容器的文件系统视图运行。因此，Init容器 可具有访问 Secrets 的权限，而应用容器不能够访问。

由于 Init 容器必须在应用容器启动之前运行完成，因此 Init 容器提供了一种机制来阻塞或延迟应用容器的启动，直到满足了一组先决条件。一旦前 置条件满足，Pod内的所有的应用容器会并行启动。

初始化容器配置

在spec下添加initContainers子项即可

spec: containers: - image: nginx:1.17.1 name: nginx-container ports: - name: "port-name" containerPort: 8080 protocol: TCP initContainers: - name: init-mysql image: busybox:1.3.0 command: ["/bin/sh","-c","while true;do echo hello;sleep 1;done"]

1

2

3

4

5

6

7

8

9

10

11

12

钩子函数

类似spring的AOP功能，在主容器启动后和容器终止前执行一些自定义的逻辑；

postStart：容器创建之后执行，如果postStart钩子函数失败了会重启容器；

preStop：容器终止之前执行，执行完成之后容器将成功终止，在其完成之前会阻塞删除容器的操作

钩子函数支持以下三种方式定义动作

第一种：exec命令

在容器内执行一次命令，这种方式使用比较频繁，一般都是使用这种方式作为钩子函数；

spec: containers: - image: nginx:1.17.1 name: nginx-container ports: - name: "port-name" containerPort: 8080 protocol: TCP lifecycle: postStart: # 主容器启动后钩子 exec: command: ["/bin/bash","-c","echo postStart > /root/post.txt"] preStop: # 主容器终止前钩子 exec: command: ["/bin/bash","-c","echo postStart > /root/post.txt"]

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

也可以这样

spec: containers: - image: nginx:1.17.1 name: nginx-container ports: - name: "port-name" containerPort: 8080 protocol: TCP lifecycle: postStart: # 主容器启动后钩子 exec: command: - cat - post.txt preStop: # 主容器终止前钩子 exec: command: - cat - post.txt

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

第二种：tcpSocket

以下列子是在主容器启动后尝试去连接8080端口，在主容器终止前去连接8081端口

spec: containers: - image: nginx:1.17.1 name: nginx-container ports: - name: "port-name" containerPort: 8080 protocol: TCP lifecycle: postStart: # 主容器启动后钩子 tcpSocket: port: 8080 preStop: # 主容器终止前钩子 tcpSocket: port: 8081

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

第三种：httpGet

以下列子是在主容器启动后会去访问链接http://192.168.1.101:8080/login，在主容器终止前去访问链接http://192.168.1.101:8080/logout;

spec: containers: - image: nginx:1.17.1 name: nginx-container ports: - name: "port-name" containerPort: 8080 protocol: TCP lifecycle: postStart: # 主容器启动后钩子 httpGet: path: /login # Url地址 port: 8080 # 端口 host: 192.168.1.101 # 主机地址 schema: HTTP # 支持的协议，http或https preStop: # 主容器终止前钩子 httpGet: path: /logout # Url地址 port: 8080 # 端口 host: 192.168.1.101 # 主机地址 schema: HTTP # 支持的协议，http或https

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

容器探测

容器探测用于检测容器中的应用实例是否正常工作，是保障业务可用性的一种传统机制，如果经过探测，实例的状态不符合预期，那么kubernetes就会把该问题实例“摘除”，不承担业务流量，k8s提供了两种探针来实现容器探测

liveness probes ： 存活性探针，用于检测应用实例当前是否处于正常运行状态，如果不是，k8s会重启容器

readiness probes ： 就绪性探针，用于检测应用实例当前是否可以接收请求，如果不能，k8s不会转发流量

liveness probes决定是否重启容器，readiness probes觉得是否将请求转发给容器

存活性探针和就绪性探针都支持三种探测方式，其实就是使用了钩子函数,

第一种 exec

在容器内执行一次命令，如果命令执行的退出码为0，则认为程序正常， 否则不正常；

仔细看看，跟上面的钩子函数差不多，钩子函数用的是lifecycle，而探针用的是livenessProbe或者readinessProbe

# 存活性探针 ..... spec: containers: - image: nginx:1.17.1 name: nginx-container livenessProbe: # 存活性探针 initialDelaySeconds: 5 # 容器启动后等待多少秒执行第一次探测 timeoutSeconds: 10 # 探测超时时间，默认1秒，默认1秒 failureThreshold: 10 # 连续探测失败多少次才被认定为失败，默认是3，最小值是1 successThreshold: 1 # 连续探测成功多少次才被认定为成功，默认是1 exec: command: - cat - post.txt ...... # 就绪性探针 ..... spec: containers: - image: nginx:1.17.1 name: nginx-container readinessProbe: # 就绪性探针 initialDelaySeconds: 5 # 容器启动后等待多少秒执行第一次探测 timeoutSeconds: 10 # 探测超时时间，默认1秒，默认1秒 failureThreshold: 10 # 连续探测失败多少次才被认定为失败，默认是3，最小值是1 successThreshold: 1 # 连续探测成功多少次才被认定为成功，默认是1 exec: command: - cat - post.txt ......

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

第二种 tcpSocket

将会尝试访问容器的端口，如果能建立连接，则认为程序正常，否则不正常

仔细看看，跟上面的钩子函数差不多，钩子函数用的是lifecycle，而探针用的是livenessProbe或者readinessProbe

# 存活性探针 ...... spec: containers: - image: nginx:1.17.1 name: nginx-container livenessProbe: # 存活性探针 initialDelaySeconds: 5 # 容器启动后等待多少秒执行第一次探测 timeoutSeconds: 10 # 探测超时时间，默认1秒，默认1秒 failureThreshold: 10 # 连续探测失败多少次才被认定为失败，默认是3，最小值是1 successThreshold: 1 # 连续探测成功多少次才被认定为成功，默认是1 tcpSocket: port: 8080 ...... # 就绪性探针 ...... spec: containers: - image: nginx:1.17.1 name: nginx-container readinessProbe: # 就绪性探针 initialDelaySeconds: 5 # 容器启动后等待多少秒执行第一次探测 timeoutSeconds: 10 # 探测超时时间，默认1秒，默认1秒 failureThreshold: 10 # 连续探测失败多少次才被认定为失败，默认是3，最小值是1 successThreshold: 1 # 连续探测成功多少次才被认定为成功，默认是1 tcpSocket: port: 8080 ......

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

第三种 httpGet

调用容器内web应用的url，如果返回的状态码在200 ~ 399之间，则认为程序正常，否则不正常

仔细看看，跟上面的钩子函数差不多，钩子函数用的是lifecycle，而探针用的是livenessProbe或者readinessProbe

# 存活性探针 ...... spec: containers: - image: nginx:1.17.1 name: nginx-container # 存活性探针 livenessProbe: initialDelaySeconds: 5 # 容器启动后等待多少秒执行第一次探测 timeoutSeconds: 10 # 探测超时时间，默认1秒，默认1秒 failureThreshold: 10 # 连续探测失败多少次才被认定为失败，默认是3，最小值是1 successThreshold: 1 # 连续探测成功多少次才被认定为成功，默认是1 httpGet: path: /login # Url地址 port: 8080 # 端口 host: 192.168.1.101 # 主机地址 schema: HTTP # 支持的协议，http或https ...... # 就绪性探针 ...... spec: containers: - image: nginx:1.17.1 name: nginx-container readinessProbe: # 就绪性探针 initialDelaySeconds: 5 # 容器启动后等待多少秒执行第一次探测 timeoutSeconds: 10 # 探测超时时间，默认1秒，默认1秒 failureThreshold: 10 # 连续探测失败多少次才被认定为失败，默认是3，最小值是1 successThreshold: 1 # 连续探测成功多少次才被认定为成功，默认是1 httpGet: path: /login # Url地址 port: 8080 # 端口 host: 192.168.1.101 # 主机地址 schema: HTTP # 支持的协议，http或https ......

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

重启策略

存活性探针对容器进行探测时，如果出现了问题，k8s就会对容器所在的pod进行重启，这是由pod的重启策略决定的，pod的重启策略由三种

Always：（默认值）总是重启容器

OnFailure： 容器终止运行且退出码不为0时重启

Never ： 不论状态如何，都不重启

配置重启策略

spec: restartPolicy: Always

1

2

重启等待时间

重启策略适用pod中的所有容器，如果是第一次重启，在需要重启时将会立即重启，如果不是第一次重启，那么将会延长一段时间后重启，这是防止服务器资源都用来重启所做的一些优化，

第一次重启，立即重启

第二次重启，延长10s重启

第三次重启，延长20s重启，

第四次重启，延长40s重启

第五次重启，延长80s重启

第六次重启，延长160s重启

第七次或七次以上重启，都延长300s重启

pod调度

什么是调度

默认情况下，一个pod在哪个node节点上运行，是通过scheduler组件采用相应的算法计算出来的，这个过程是不受人工控制的；

调度规则

但是在实际使用中，我们想控制某些pod定向到达某个节点上，应该怎么做呢？其实k8s提供了四类调度规则

定向调度

指的是利用在pod上声明nodeName或nodeSelector的方式将pod调度到指定的pod节点上，因为这种定向调度是

强制性

的，所以如果node节点不存在的话，也会向上面进行调度，只不过pod会运行失败；

nodeName 是将pod强制调度到指定名称的node节点上，这种方式跳过了scheduler的调度逻辑，直接将pod调度到指定名称的节点上，配置文件内容如下

apiVersion: v1 # 版本号 kind: Pod # 资源类型 metadata: name: pod-name namespace: dev spec: containers: - image: nginx:1.17.1 name: nginx-container nodeName: node1 # 调度到node1节点上

1

2

3

4

5

6

7

8

9

10

NodeSelector是将pod调度到添加了指定label标签的node节点上，它是通过k8s的label-selector机制实现的，也就是说，在创建pod之前，会由scheduler用matchNodeSelecto调度策略进行label标签的匹配，找出目标node，然后在将pod调度到目标node；

要实验NodeSelector，首先得给node节点加上label标签

kubectl label nodes node1 nodetag=node1

1

配置文件内容如下

apiVersion: v1 # 版本号 kind: Pod # 资源类型 metadata: name: pod-name namespace: dev spec: containers: - image: nginx:1.17.1 name: nginx-container nodeSelector: nodetag: node1 # 调度到具有nodetag=node1标签的节点上

1

2

3

4

5

6

7

8

9

10

11

TCP/IP 容器

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。