pod进阶

m0_70766460

已于 2024-01-05 17:14:05 修改

阅读量958

点赞数 22

文章标签： kubernetes 容器云原生

于 2024-01-04 17:34:36 首次发布

本文链接：https://blog.csdn.net/m0_70766460/article/details/135377621

版权

探针（核心内容）

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 单位

2000m

1000m 也表示一个cpu

500m

100m就是最小的单位

内存：

单位

Ki（大小写）

以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

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检查（三次握手），端口打开，认为探测成功。

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

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