pod进阶

探针（核心内容）

poststart

prestop

容器钩子

pod的生命周期开始：

k8s的pod的重启策略：

Always（默认策略）

deployment的yaml文件只能是Always。Always：不论正常还是非正常退出都会重启。

pod的yaml三种模式都可以。

OnFailure：只有状态码非0才会重启。正常退出是不重启的

Never：正常退出和非正常退出都不重启。

容器退出了，pod才会重启。

pod可以有多个容器，只要有一个容器退出，整个pod都会重启，pod内的所有容器都会重启。

k8s的重启策略与docker的重启策略对比（重点）

docker的重启策略：

docker的默认策略是never。

on-failure：非正常退出，才会重启容器。

always：只要容器退出都会重启

unless-stopped：只要容器退出就会重启，docker的守护进程启动时已经停止的容器，不再重启。

单机部署：docker足够了（网络 部署）

集群化部署容器：k8s

yaml文件快速生成（模版）

kubectl create deployment nginx1 --image=nginx:1.22? --replicas=3?--dry-run=client -o yaml

>/opt/test1.yaml

--dry-run=client：只是调用api的对象不执行命令。

kubectl run nginx1 --image=nginx:1.22 --dry-run=client -o yaml > /opt/test1-pod.yaml

kubectl expose deployment nginx?--port=80 --target-port=80?--type=NodePort? --dry-run=client -o yaml > /opt/test1-service.yaml

vim test1.yaml

vim test1-pod.yaml

vim?test1-service.yaml

crashloopbackoff：pod当中的容器退出，kubelet正在重启

imagepullbackoff：正在重试拉取镜像

errimagepull：拉取镜像出错了（1、网速太慢，2、镜像名字写错了，3、镜像仓库挂了）

Evicte：Pod被驱赶了（node节点的资源不够部署pod。或者是资源不足，kubelet自动选择一个pod驱逐）

对pod内的容器使用节点资源的限制：

1、request：需要的资源

2、limit：限制--->最高能占用系统多少资源

limit需要多少，最多也只能占用这么多

两个限制：

cpu

cpu的限制格式：

1? 2? ?0.5? ? 0.2? ? 0.1

1 可以占用1个cpu

2 可以占用两个

0.5 半个

0.2 一个cpu的五分之一

0.1是最小单位。

要么是整数，要么就是小数点后面只能跟一位，最小单位0.1

m来表示cpu

cpu的时间分片原理：

cpu时间分片：通过周期性的轮流分配cpu时间给各个进程。多个进程可以在cpu上交替执行。

在k8s中就是表示占用cpu的比率：

m：millicores 单位

1

2000m

1000m 也表示一个cpu

500m

100m就是最小的单位

内存：

单位

Ki（大小写）

Mi

Gi

Ti

以test1.yaml为例

apiVersion: apps/v1
kind: Deployment
metadata:
? labels:
? ? app: centos
? name: centos
spec:
? replicas: 3
? selector:
? ? matchLabels:
? ? ? app: centos
? template:
? ? metadata:
? ? ? labels:
? ? ? ? app: centos
? ? spec:
? ? ? containers:
? ? ? - image: centos:7
? ? ? ? name: centos
? ? ? ? resources:?
? ? ? ? ? requests:
? ? ? ? ? ? memory: "256Mi"
? ? ? ? ? ? cpu: "0.5"
? ? ? ? ? limits:
? ? ? ? ? ? memory: "1Gi"
? ? ? ? ? ? cpu: "1"

查看状态

containers：

-? image: centos:7

? ?name: centos

? ?command: ["/bin/bash","-c","sleep 3600"]

9:56 需要指定后台进程，否则运行一次即退出了

? ?resources:

? ? ? requests:

? ? ? limits:

? ? ? memory: "256Mi"

? ? ? cpu："1"

在创建pod时，一定要给容器做资源限制。防止它把整个系统资源全部占满

k8s怎么设置拉取镜像的策略：

镜像默认策略：

ifNotPresent：如果本地镜像有，就不再拉取，本地没有才会去镜像仓库去拉取。（默认策略）

Always：不论镜像是否存在，创建时（包括重启时）都会重新拉取镜像。

Never：仅仅使用本地镜像，本地没有也不会主动拉取。

注：

都是本地部署，never

如果涉及到外部部署，默认策略（事前要把docker的镜像导入到目标主机）

Always：一般不用

imagePullPolicy：Never

10:13

Always策略例：

pod的容器健康检查：

探针

probe

k8s对容器执行的定期检查，诊断。

探针有三种规则：

1、存活探针：livenessProbe? 探测容器是否正常运行，如果发现探测失败，会杀容器，容器会根据重启策略来决定是否重启。不是杀掉pod。

2、流量/就绪探针：探测容器是否进入ready状态，并做好接受请求的准备。

探测失败? ?READY 0/1 没有进入ready状态。service会把这个资源对象的端点从当中剔除，service也不会把请求转发到这个pod。

3、启动探针：

只是在容器启动后开始检测，容器内的应用是否启动成功。

注意：在启动探测成功之前，所有的其他的探针都会处于禁用状态。

但是，一旦启动探针结束，后续的操作不再受启动探针的影响。

在一个容器当中可以有多个探针。

启动探针：只在容器启动时探测

存活

就绪

probe的检查方法：

1、exec探针，在容器内部执行命令，如果命令的返回码是0，表示成功。

适用于需要在容器内自定义命令来检查容器的健康的情况。

2、httpGet：

对指定ip+端口的容器发送一个httpGet请求。响应状态码大于等于200，小于400都是成功。

x>=200 <400

适用于检查容器能否响应http的请求，web容器（nginx，tomcat）

3、tcpSocket：

? ? ? ? 端口，对指定端口上的容器的ip地址进行tcp检查（三次握手），端口打开，认为探测成功。

检查特定容器的端口监听状态。（监听容器端口是否正常打开）

80

999

telnet? 192.168.233.30? 80

诊断结果：

1、成功，容器通过了，正常运行

2、失败，存活探针就会重启

3、未知状态：诊断失败。

存活探针：livenessProbe

exec方式：

command [""]

livenessProbe：

? exec：

? ? ? command? ["/usr/bin/test", "-e", "/opt/123.txt"]

? initialDelaySeconds:? 30? ?（核心指标，必须要有）

#表示容器启动之后多少秒来进行检测，时间不要设置的太短，可能导致无效探测（推荐10-30）

? periodSeconds：2? ?（必加）

#表示探针探测的间隔时间。每隔多少秒进行一次检查。应用的延迟敏感度。这个应用非常重要，是核心组件。(探测周期，必须要有)? 10-60s

? failureThreshold：2 （必加）

#表示如果探测失败，失败几次之后，把容器标记为不健康。（2-6）

? successThreshold：1（可选加）

只要成功一次就标记为就绪，健康，ready，成功，默认就是一次

? timeoutSeconds：1（可不加）

#表示每次探测的超时时间，在多少秒内必须完成检测。（10-30）

成功次数可以不加，失败次数不加，默认是3次。

存活探针的特点：

liveness? 杀死容器，重启。所有的探针策略伴随整个pod的生命周期，除了启动探针。

httpGet的方式

例：

livenessProbe

? httpGet：

? ? ?scheme：HTTP

? ? ?port：80

initialDelaySeconds:4

periodSeconds：2

指定path路径

path：/index.html

get http:ip:8080/index.html

200 400

11:48

tcpSocket：

? port:8080

? per

删除

kubectl apply -f

会把所有资源回收

telnet 检测端口是否正常

总结：

探针：

存活探针：检测失败之后，会杀死容器，然后重启。

探针将伴随整个容器的生命周期

exec 相当于执行了一个shell命令，容器里面执行

shell命令执行成功：

返回码：为0表示成功。

成功一次就是探测成功。

httpGet：对web容器发起了一次get请求，可以添加path，指定访问的资源。返回码在大于等于200，小于400的范围之内都算成功。

tcpSocket：相当于telnet，指定的容器监听端口是否打开，是否能和指定的容器监听端口进行通信。

就绪探针：readinessProbe

就绪探针的特点：

pod的状态是runing，但是ready的状态是notready，容器不可以提供正常的业务访问，就绪探针不会重启容器。

tcpSocket只是监视容器上的业务端口是否能正常通信，8081没有，8080还在，也就是正常的端口

还是可以访问的。

如果更改了容器的启动端口

mysql? 3306? ? ? 33066

tcp? 33066

查看nginx1的状态

正常状态

测试：删除passwd，再次查看

变为failed

但是pod的状态依旧为Running，READY为not ready

pod在运行，容器状态变为not ready，不会重启

注：存活探针和就绪探针，会伴随整个pod的生命周期

整个过程中一直都存在。

httpGet的方式：

vim test1-pod.yaml

apiVersion: v1
kind: Pod
metadata:
? labels:
? ? run: nginx1
? name: nginx1
spec:
? containers:
? - image: tomcat:8.0.52
? ? name: nginx1
? ? readinessProbe:
? ? ? httpGet:
? ? ? ? scheme: HTTP
? ? ? ? port: 8080
? ? ? ? path: /index.jsp
? ? ? initialDelaySeconds: 4
? ? ? periodSeconds: 2

查看状态，正常

将 index.jsp删除

状态变为404，但是并没有重启，容器状态变为not ready

访问一下，实际上还是不可用

总结：未就绪状态是一个不可用状态，只不过它的status是running，实际上容器还是不可用

tcpSocket：

查看一下详细信息

startupProbe（启动探针）

startupPorbe的特点：

如果探测失败，pod的状态是notready。

启动探针，会重启容器。

注：启动探针没有成功之前，后续的探针都不会执行。

启动探针失败，自动重启

启动探针成功之后，在pod的生命周期内不会再检测启动探针。

重启了pod之后，相当于重新部署了一个初始版的新的容器。

三种探针综合实例

startupProbe

? tcpSocket

livenessProbe

? exec

? ? command:? []

readinessProbe:

?httpGet

apiVersion: v1
kind: Pod
metadata:
? labels:
? ? run: nginx1
? name: nginx1
spec:
? containers:
? - image: tomcat:8.0.52
? ? name: nginx1
? ? startupProbe:
? ? ? tcpSocket:
? ? ? ? port: 8081
? ? ? initialDelaySeconds: 4
? ? ? periodSeconds: 2
? ? livenessProbe:
? ? ? exec:
? ? ? ? command: ["/usr/bin/test","-e","/etc/passwd"]
? ? ? initialDelaySeconds: 4
? ? ? periodSeconds: 2
? ? readinessProbe:
? ? ? httpGet:
? ? ? ? scheme: HTTP
? ? ? ? port: 8080
? ? ? ? path: /index.jsp
? ? ? initialDelaySeconds: 4
? ? ? periodSeconds: 2

command: ["/usr/bin/test","-e","/etc/passwd"]

运行结果：

状态是runing，但是ready是notready

删除/etc/passwd,测试是否会检测到

发现后续的探针并没有探测到

说明启动探针没有成功之前，后续的探针都不会执行。

报错是连接不到8081端口，与后续的探针无关

更改一下顺序：

查看详细情况：

查看pod信息，发现可以正常使用是ready，running状态

同样删除/etc/passwd，查看访问情况，发现命中的是存活探针

状态是8080端口连接不上

删除index.jsp，触发就绪探针

由此验证了，在pod的生命周期当中，后续的条件是满足哪个探针的条件，触发哪个探针的条件。

这时候查看pod的状态，没有重启

探针运行的规律（优先级、规则）总结：（重点掌握）

1、在一个yaml当中可以有多个探针。启动? 存活? ?就绪都针对一个容器。

2、启动探针的优先级是最高的，只有启动探针"成功"，后续的探针才会执行。

3、启动探针成功之后，后续除非重启pod，否则不会再触发探针了。

4、在pod的生命周期中，一直存在，一直探测的是存活探针和就绪探针。

5、在pod的生命周期中，后续的条件是满足哪个探针的条件，触发哪个探针的条件。

6、就绪探针不影响容器运行，status:runing，这个时候不会重启，但是，容器退出的话，就绪探针也会重启。

容器启动和退出时的动作：

postStart：容器启动钩子，容器启动之后触发的条件。

preStop：容器退出钩子，容器退出之后触发的条件。

apiVersion: v1

kind:pod

metadate:

? name: nginx1

spec:

? containers:

? - name:nginx2

? command ["/bin/bash"."-c","sleep 3600"]

? volumeMount:

? -? name: test1

? ? ? mountpath: /opt

? ? ? readOnly: false

? ?lifecycle:

? ? ? postStart:

? ? ? ? ? exec:

? ? ? ? ? ? ? command [""]?

? ? ? prestop:

? ? ? ? ?exec

? ? ? ? ? ? ? command? [""]

volumes:

? ? name:? test1

? ? hostPath:

? ??

声明容器内部的挂载目录

要给这个挂载卷取名字，不同挂载卷的名字不能重复

readonly：false：可读写

volume：

? - name

声明的是node节点上和容器内的/opt的挂载目录

挂载卷的名称和要挂载的容器内挂载卷名称要一一对应

hostPAthens：指定容器和挂载目录

type：Directoryorcreate: 如果节点上的目录不存在，自动创建该目录。

# pod会经常被重启，销毁，一且容器和node节点做了挂载卷，数据不会丢失

启动和退出的作用：

1、启动可以自定义配置容器内的环境变量

2、通知机制，告诉用户容器启动完毕。

3、退出时，可以换行自定义命令，删除或者生产一些必要的程序，自定义销毁方式以及自定义资源回收的方式以及容器的退出等待时间。

在这个pod的生命周期事件当中，把启动探针，存活探针和就绪探针加入到yaml文件当中。

补充：pod的重启策略

在k8s当中都是重启pod

三种重启策略：

Always：默认策略-------->当pod内的容器退出，不论是一个还是两个容器退出，整个pod都会重启

Never：当pod内的容器退出时。退出一个还是退出N个，pod都不会重启。

onFalire：当pod内的容器退出时，状态码是0，整个pod都不会重启，只有一个或者N个容器非正常退出，状态码非0，整个pod才会重启。

k8s就是集群化管理容器。k8s管理对象的封装容器的pod。

启动探针会重启，只是重启内部的容器（实际上是重启容器），也相当于重启了pod

describe 查看状态

pod和容器到底是什么