pod简介
pod是k8s中最小的单元,早期是一个pod中运行一个容器。kube-apiserver跟kubelet通讯,来发送管理命令,创建一个pod,在由kubelet创建容器运行时,kubelet可以兼容docker、containerd、cri-o、rkt、pouch等多种容器运行时。后期延伸为一个pod中可以运行多个容器。如下图:
- pod管理container
- 一个pod中可以运行多个container,在90%的场景中,一个pod只会运行一个container
- 一个pod中的多个container是真正的命运共同体,只要任意一个容器挂掉了,则整个pod就会挂掉
pod管理
k8s真正强大的地方不是像docker那样的命令行 ,而是像docker-compuse的方式通过yaml文件去管理pod。对pod的管理就是对pod的增删改查,有两种方式,命令行直接修改和通过编辑yaml文件。
下面是k8syaml的语法:
#yaml文件主要包含三部分:
#gvk
#元数据
#描述信息 这种重点,包含了容器的相关配置信息
#gvk
#gv = group/version
apiVersion: v1 #version gv: ""/v1
#k
kind: Pod
# 元数据
metadata:
name: nginx #pod的名字
namespace: default
labels: #标签信息,可以认为定义,需要时键值对的形式
name: nginx
maintainer: dkp
func: webserver
annotations: #描述信息
describe: "this is a pod for test"
#描述信息
spec:
containers:
- name: nginx
image: nginx:1.21
进入pod:
kubectl exec -it <pod_name> -- /bin/bash
kubectl explain pods --recursive | more 查看yaml语法详细文档
kubectl explain pods --recursive | grep -A 10 显示搜索到的行及后面10行
pod里所有容器的全局配置:
restartPolicy:
- Always: 此为默认值,在pod资源对象中,只能使用always;在pod退出时总是自动重启。
- Never: 当pod退出时,不要重启
- OnFailure: 只有当pod异常退出时才重启
dnsPolicy:
- Default: 使用宿主机的dns,当pod的网络指定为hostNetwork: true时,则此为默认值
- ClusterFirst: 此为默认值,使用k8s内置的dns做解析
- ClusterFirstWithHostNet: 当pod的网络指定为hostNetwork: true时,如果想让pod使用k8s集群的内部coredns做解析,则配置此项
指定网络:
- hostNetwork: true (or false)
初始化容器
用于应用容器的初始化;
B容器依赖于A容器:B在启动之前,检查A是否启动,如果A没有启动,则B等待,直至A启动完成
nginx启动之前先要将代码放到目录里面
1.初始化容器一定会先于应用容器启动,
2.初始化容器跟我们的应用容器一样,可以有多个,每个只完成一件事
3多个初始化容器是串行启动的
4.每个初始化容器执行的任务都是短时任务,任务执行完成,并且正常退出之后,下一个初始化容器才会正常启动
5.当所有的初始化容器都正常启动并退出之后,应用容器才会开始启动
存储-声明存储:(声明将宿主机的某一个文件或者目录映射到容器中)
hostPath类型
volumes:
- name: host-name
hostPath:
path: /etc/localtime
emptydir类型
volumes:
- name: webdir
emptyDir:
要将数据存储在内存中的写法
volumes:
- name: cachedir
emptyDir:
- medium: Memory
sizeLimit: 128Mi
使用存储要和容器独有配置配合使用,容器调用已经声明的存储配置,容器独有配置部分内容写法见下文
pod里每个容器独有的配置:
指定名称:
name: nginx指定镜像:
image: nginx:1.21镜像拉取策略:
imagePullPolicy:
Always :不检查本地是否存在镜像,总是拉取
IfNotPresent : 默认值
当pod被调度到一个节点上时,这个节点的kubelet在启动容器时优先检查这个容器所需的镜像在本地是否存在,如果存在。则直接使用本地存在的镜像,如果不存在,则从镜像仓库拉取镜像
Never : 总是不拉取,使用该参数时要确保本地存在镜像指定启动命令: (覆盖默认启动指令)
写法一:
command: ["/bin/sh","-c", "sleep 3600"]
写法二:
command:
- /bin/sh
- -c
- "sleep 3600"指定启动参数: (一般和comman配合使用)
args:
写法示例:
command:
- /bin/sh
- -c
args:
- "sleep 3600"传递环境变量:
env:
- name:
value:
- name:
value:映射端口:
ports:
- name: mysql
containerPort: 3306
hostPort: 3306
protocol: tcp或者udp,默认tcp
- name: http
containerPort: 80
hostPort: 80多容器:
配置文件中,指定多个容器。注意监听端口不能一样静态容器:
将正常创建pod的yaml文件放到任意一个worker节点的/etc/kubernetes/manifests下,则该节点会自动读取yaml文件并在本机创造出pod,此种pod即称为静态pod
静态pod并不是被调度器调度创建的,而是由管理员向kubelet直接下达创建pod的指令,kubelet自行创建的
静态pod无法被kubernetes的master所管理。要删除只需删除对应路径的yaml文件即可存储: 使用存储
hostPath类型:
volumeMounts:
- name: host-name(全局配置声明过的存储文件或目录)
mountPath: /etc/localtime (挂载在容器的路径)
readonly: true
emptyDir类型:
emptyDir是一个临时存储,数据可以存储在磁盘上或者内存中,并且与pod的生命周期强绑定,当pod退出时,emptyDir中的数据全丢失。
containers:
···
volumeMounts:
- name: webdir(全局配置声明过的存储文件或目录)
mountPath: /usr/share/nginx/html (挂载在容器的路径)
数据存储在内存中的写法:
containers:
···
volumeMounts:
- name: cachedir(全局配置声明过的存储文件或目录)
mountPath: /usr/share/cache (挂载在容器的路径)
生命周期钩子(lifecycle)
postStart:(启动之后)
preStop:(生命结束之前)资源限制:
resources:
requests:
cpu: 200m
memory: 512Mi
limits:
cpu: "1"
memory: 1Gi
limits限定当前容器能够使用的最多cpu和memory
1.当cpu超出超出限制时,会触发cpu节流
2.当内存超出限制时,会触发oom,杀掉容器
资源限制与pod服务等级
1.BestEffort:尽可能的服务,既没有设置requests,也没有设置limits;资源没有使用限制,其所运行的宿主机有多少资源空闲,他们在需要的时候都可以使用,这种qos的优先级是最低的
2.burstable:当只设置了requests,或者虽然同是设置了requests和limits,但是requests和limits并不相等的情况下,其优先级要高于BestEffort
3.Guaranteed:如果一个pod里面有多个容器,则这多个容器都必须设置requests和limits,而且每个容器的requests和limits必须相等,其拥有最高的服务等级
当一个节点上的资源不够这些pod分配时,pod就会发生资源争抢,此时服务等级越高的pod,将优先获得资源
requests和limits可以都不配,也可以支配其一
都不配:BestEffort
只配置requests:至少预留requests资源,limits不限制
只配置limits:则requests=limits
- 健康检查:
1.一个容器中,如果有多个进程,后台运行的进程是无法被感知到的
2.进程可能假死
3.进程虽然启动,但程序尚未就绪
启动阶段探测:startupProbe
1、在pod启动时探针开始执行
2、其期望目标是探测失败,一旦成功,则该探针生命周期结束,退出
3、如果始终失败,在超过最大探测次数时,退出;此时,pod被标记为启动失败
运行阶段探测:
livenessProbe:
1、在pod完成正常启动之后,开始执行
2、其探活周期贯穿整个pod生命周期
3、其期望目标是成功;一旦出现连续失败,则pod被标记为不健康,此时,pod会被强行杀死
每10秒检测一次,连续失败3次,将其杀死
readinessProbe:
1、在pod完成正常启动之后,开始执行
2、其探活周期贯穿整个pod生命周期
3、其期望目标是成功;一旦出现连续失败,则pod被标记为不健康,此时,pod会被设置为未就绪
每1秒检测一次,连续失败3次,将其标记为未就绪
pod状态:
- ContainerCreating
- Running
- PostStartHookError
- PodInitializing