目录
pod的生命周期当中的状态
1. running 表示运行中:就是pod已经分配到节点上且pod内的容器正常运行。正常状态不仅需要running还需要ready 1/1
2. complete 表示容器正常运行结束:就是完成之后退出,指容器内的返回码是0
3. pending 叫做挂起状态:就是pod已经创建好了,但是没有被分配到节点上。
出现pending的原因有哪些?(重点)
1)节点上的资源不足 解决方法:释放节点的资源 / 换一个有资源的节点部署
2)节点上设置了污点标签,导致节点不可部署
3)节点上没有适合的pv挂载点(手动的情况)、磁盘空间不足、创建pv失败(即可能自动,也可能手动)
4)网络原因和防火墙策略,导致节点不可用
5)swap交换分区没有关闭
6) hostport端口被占用或者nodeport节点上的端口被占用
4. failed 表示失败:容器内的返回码是非0的状态退出,就是进入失败状态
这里可以用logs -f 查看pod的日志、用describe pod 查看pod的详细情况也可以查询到错误原因
5. terminating 表示终止中:表示pod正在删除中
6. unknown 表示未知:一般是集群出现了问题、apiserver出现了问题、或者是apiserver和调度器之间通信有问题(比如证书过期)
7. ImagePullBackOff 表示拉取镜像失败
8. CrashLoopBackOff 表示容器已经启动了,但还是异常退出了。可以查看日志或者详细情况来分析
9. error 表示pod启动过程中报错 可以通过日志查看
10. PodInitializing 表示初始化中,就是pod内部有初始化init容器
11. Evicte 表示pod被驱逐
pod状态一览:
CrashLoopBackOff: 容器退出,kubelet正在将它重启
InvalidImageName: 无法解析镜像名称
ImageInspectError: 无法校验镜像
ErrImageNeverPull: 策略禁止拉取镜像
ImagePullBackOff: 正在重试拉取
RegistryUnavailable: 连接不到镜像中心
ErrImagePull: 通用的拉取镜像出错
CreateContainerConfigError: 不能创建kubelet使用的容器配置
CreateContainerError: 创建容器失败
m.internalLifecycle.PreStartContainer 执行hook报错
RunContainerError: 启动容器失败
PostStartHookError: 执行hook报错
ContainersNotInitialized: 容器没有初始化完毕
ContainersNotReady: 容器没有准备完毕
ContainerCreating: 容器创建中
PodInitializing:pod 初始化中
DockerDaemonNotReady: docker还没有完全启动
NetworkPluginNotReady: 网络插件还没有完全启动
Evicte: pod被驱赶
资源限制
k8s里的cpu最小单位是100m或者0.1 表示占一个cpu的10%。其中1000m或者1表示占满一个cpu;500m或者0.5表示占一个cpu的50%
内存的单位是 Ki、Mi、Gi、Ti
语法:
apiVersion: v1
kind: Pod
metadata:
name: nginx1
labels:
app: nginx1
spec:
#声明容器的参数
containers:
- name: nginx
image: nginx:1.22
resources:
requests:
cpu: "0.5"
memory: "512Mi"
#表示软限制,就是最低的要求(在工作中最低限制可以不写)
limits:
cpu: "1"
memory: "1Gi"
#表示硬策略,就是最多只能使用这么多
探针probe
探针又叫probe,它是对容器执行定期的检查
有三种探针
1.启动探针startupProbe
语法:startupProbe
在容器启动的时候,根据条件判断容器是否启动成功。如果有启动探针和其他探针并列,只有启动探针执行成功之后,那么后续的探针才会执行;启动探针执行失败,整个容器判定为失败,pod也会进入失败状态。
在整个容器的生命周期当中,只有启动探针会在启动时执行,执行成功之后后续不再执行。
2.存活探针livenessProbe
语法:livenessProbe
用来探测容器是否正常运行,如果探测失败,会根据pod的重启策略来决定是否重启。
存活探针会伴随整个pod的生命周期
3.就绪探针readinessProbe
语法:readinessProbe
用来检测pod的状态是否进去ready。如果进入ready状态失败,那么service将会把这个pod的ip从转发中移除,也就是service不会把请求转发到这个pod。如果就绪探针没有检测成功或者失败,pod可能是running,但是ready一定是0/1.
存活探针一般用于容器内的配置文件或者关键组件是否正常
就绪探针一般用于指定端口的服务,就是需要对外提供访问的业务
存活和就绪探针都会伴随整个pod的生命周期
probe探针的检查方法
1. exec方法
就是进入容器内执行命令,命令的返回码是0表示成功,非0表示失败
使用场景:在容器内使用自定义命令来检测容器内的健康状况,比如判断关键配置文件是否存在、依赖环境是否完整等等
2.tcpSocket方法
就是对容器内的ip地址进行tcp检查(三次握手),并和指定的端口进行连接,如果三次握手和端口通信建立连接正常,则表示成功。
使用场景:主要是用来判断容器的端口是否正常启动。即端口是否处于监听状态
3.httpGet方法
就是对容器内的ip+端口进行http请求,请求的方式是get。响应码 ≥200且<400 都表示成功
使用场景:主要应用于web容器
结果:
1.成功
2.失败 如果定义了容器的重启策略,容器会进行重启
3.未知 也属于探针失败,但是不会采取任何行动(这个行动主要是重启)
举例
exec方法
apiVersion: apps/v1
kind: Deployment
metadata:
name: centos
labels:
app: centos7
spec:
replicas: 1
#定义副本数
selector:
#定义匹配的标签
matchLabels:
app: centos7
template:
#定义模版
metadata:
labels:
app: centos7
spec:
#定义pod的容器参数:
containers:
- name: centos7
image: centos:7
command: ["/bin/bash","-c","touch /opt/123.txt && sleep 3600"]
livenessProbe:
exec:
command: ["/usr/bin/test","-e","/opt/123.txt"]
initialDelaySeconds: 1
#表示容器启动之后多少秒开始第一次探测,这个时间可以长一点,就是要等应用程序准备好之后再探测,以避免结果有误
periodSeconds: 3
#表示在pod的生命周期内,探针的检测间隔时间是3秒,根据业务容器的情况来看,如果有比较敏感的检测,可以缩短间隔时间
failureThreshold: 2
#表示探针检测容器失败几次就把容器标记为不健康
timeoutSeconds: 1
#表示探针在多少秒之内完成探测,timeoutSeconds的时间必须小于periodSeconds
successThreshold: 1
#只要探针成功一次,就把容器标记为健康,这个值只能是1,默认也是1,所以可以不写
然后 kubectl describe pod 查看详情
注:下面五个参数可以不写,系统有默认值
tcpSocket方法
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
labels:
app: nginx1
spec:
replicas: 1
#定义副本数
selector:
#定义匹配的标签
matchLabels:
app: nginx1
template:
#定义模版
metadata:
labels:
app: nginx1
spec:
#定义pod的容器参数:
containers:
- name: nginx
image: nginx:1.22
livenessProbe:
tcpSocket:
port: 80
httpGet方法
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
labels:
app: nginx1
spec:
#声明容器的参数
replicas: 1
#定义副本数1
selector:
matchLabels:
app: nginx1
template:
metadata:
labels:
app: nginx1
spec:
#定义pod的容器参数:
containers:
- name: nginx
image: nginx1.22
livenessProbe:
httpGet:
port: 80
scheme: HTTP
path: /index1.html
#scheme:调用的协议(https)
#path:/index.html curl 192.168.233.10
组合形式
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
labels:
app: nginx1
spec:
replicas: 1
#定义副本数
selector:
#定义匹配的标签
matchLabels:
app: nginx1
template:
#定义模版
metadata:
labels:
app: nginx1
spec:
#定义pod的容器参数:
containers:
- name: nginx
image: nginx:1.22
startupProbe:
httpGet:
port: 80
scheme: HTTP
path: /index.html
readinessProbe:
exec:
command: ["/usr/bin/test","-e","/etc/passwd"]
#scheme:表示调用的协议,默认是https
#path: /index/html 就是声明访问192.168.233.31:80/index.html
这样就表示正常
注:假设启动探针失败,启动探针只要不重启,就不影响老的pod,如果重启了,就会生成新的pod,就会报错启动探针挂了
把多个yaml文件写在一个里面
---
#表示分段符,上一个yaml结束,下跟一个新的yaml
apiVersion: v1
kind: Service
metadata:
name: nginx-1
labels:
app: nginx1
#定义service的标签
spec:
selector:
app: nginx1
#注意:这里的标签要和上面的标签一致
type: NodePort
ports:
- port: 80
#这个是service的端口
targetPort: 80
#这个是容器的端口
nodePort: 30000
#暴露的端口
lifecycle 字段
容器钩子
portStart:表示容器启动时立即执行的命令 一般用于执行容器内需要执行的初始化命令、等待依 赖环境等待
preStop:表示容器停止之前执行的任务 一般用于清理任务、同步文件等待(导出容器内的数据)
1.如果启动钩子失败,pod能否进入正常状态
不能
2. 停止任务失败,pod能否退出
报错
3. 如果启动钩子和探针一起,那么启动钩子失败影响探针吗
影响,容器的启动钩子优先级大于启动探针
总结:容器的启动钩子优先级>启动探针>存活和就绪探针
4.容器的钩子,不论是启动还是停止之前的命令,只能使用exec
启动钩子和退出钩子
apiVersion: v1
kind: Pod
metadata:
name: centos1
labels:
app : centos1
spec:
containers:
- name: centos
image: centos:7
command: ["/bin/bash","-c","sleep 30"]
lifecycle:
postStart:
exec:
command: ["/bin/bash","-c","echo start > /opt/123.txt && sleep 10"]
preStop:
exec:
command: ["/bin/bash","-c","echo stop > /opt/456.txt && sleep 10"]
做挂载卷
apiVersion: v1
kind: Pod
metadata:
name: centos1
labels:
app : centos1
spec:
containers:
- name: centos
image: centos:7
command: ["/bin/bash","-c","sleep 30"]
volumeMounts:
- name: data-v
#表示挂载卷的名称
mountPath: /opt/test1
#表示容器内的目录
lifecycle:
postStart:
exec:
command: ["/bin/bash","-c","echo start > /opt/123.txt && sleep 10"]
preStop:
exec:
command: ["/bin/bash","-c","echo stop > /opt/456.txt && sleep 10"]
volumes:
- name: data-v
hostPath:
path: /opt/test
#表示节点(宿主机)的目录
type: DirectoryOrCreate
#表示节点的目录如果不存在就创建一个
展示结果:
注:这里如果需要显示stop就需要执行 kubectl delete -f test2.yaml
总结练习题
yaml文件
启动钩子和退出钩子
和节点挂载: /usr/shar/nginx/html/ 节点的: /opt/node
exec 执行 要能再目录中看到开始和打印的结果
包含探针:
1、启动探针:
方法: exec 检测 /usr/shar/nginx/html/ index.html分件是否存在
2、存活探针
方法: httpGet
访问验证返回码是否正确
3、就绪探针:
tcpSocket:
监听容器的80端口是否正常