大连网站推广排名,在线看视频网站怎么做,建筑设计资料集,wordpress加密数据库文件目录 pod
pod基本介绍
k8s集群中pod两种使用方式
pause容器使得Pod中所有容器共享两种资源#xff1a;网络和存储
kubernetes中的pause容器主要为每个容器提供以下功能
k8s设计这样的pod概念和特殊组成结构有什么用意
pod分类
pod容器的分类
基础容器#xff08;infr…目录 pod
pod基本介绍
k8s集群中pod两种使用方式
pause容器使得Pod中所有容器共享两种资源网络和存储
kubernetes中的pause容器主要为每个容器提供以下功能
k8s设计这样的pod概念和特殊组成结构有什么用意
pod分类
pod容器的分类
基础容器infrastructure container
初始化容器initcontainers
应用容器Maincontainer
镜像拉取策略image PullPolicy
重启策略restartPolicy
资源限制
Pod 和 容器 的资源请求和限制
CPU 资源单位
内存 资源单位
健康检查又称为探针Probe
探针的三种规则
Probe支持三种检查方法
pod状态
Container生命周期 pod
pod基本介绍
Pod是kubernetes中最小的资源管理组件Pod也是最小化运行容器化应用的资源对象。一个Pod代表着集群中运行的一个进程。kubernetes中其他大多数组件都是围绕着Pod来进行支撑和扩展Pod功能的例如用于管理Pod运行的StatefulSet和Deployment等控制器对象用于暴露Pod应用的Service和Ingress对象为Pod提供存储的PersistentVolume存储资源对象等
k8s集群中pod两种使用方式
一个Pod中运行一个容器
“每个Pod中一个容器”的模式是最常见的用法在这种使用方式中你可以把Pod想象成是单个容器的封装kuberentes管理的是Pod而不是直接管理容器。
在一个Pod中同时运行多个容器
一个Pod中也可以同时封装几个需要紧密耦合互相协作的容器它们之间共享资源。这些在同一个Pod中的容器可以互相协作成为一个service单位比如一个容器共享文件另一个“sidecar”容器来更新这些文件。Pod将这些容器的存储资源作为一个实体来管理 一个Pod下的容器必须运行于同一节点上。现代容器技术建议一个容器只运行一个进程该进程在容器中PID命令空间中的进程号为1可直接接收并处理信号进程终止时容器生命周期也就结束了。若想在容器内运行多个进程需要有一个类似Linux操作系统init进程的管控类进程以树状结构完成多进程的生命周期管理。运行于各自容器内的进程无法直接完成网络通信这是由于容器间的隔离机制导致k8s中的Pod资源抽象正是解决此类问题Pod对象是一组容器的集合这些容器共享Network、UTS及IPC命令空间因此具有相同的域名、主机名和网络接口并可通过IPC直接通信。
Pod资源中针对各容器提供网络命令空间等共享机制的是底层基础容器pause (也可称为父容器。pause就是为了管理Pod容器间的共享操作这个父容器需要能够准确地知道如何去创建共享运行环境的容器还能管理这些容器的生命周期。为了实现这个父容器的构想kubernetes中用pause容器来作为一个Pod中所有容器的父容器。这个pause容器有两个核心的功能一是它提供整个Pod的Linux命名空间的基础。二来启用PID命名空间它在每个Pod中都作为PID为1进程init进程并回收僵尸进程。
pause容器使得Pod中所有容器共享两种资源网络和存储
网络 每个Pod都会被分配一个唯一的IP地址。Pod中的所有容器共享网络空间包括IP地址和端口。Pod内部的容器可以使用localhost互相通信。Pod中的容器与外界通信时必须分配共享网络资源例如使用宿主机的端口映射。
存储 Pod可以指定多个共享的Volume。Pod中的所有容器都可以访问共享的Volume。Volume也可以用来持久化Pod中的存储资源以防容器重启后文件丢失。
每个pod都有一个特殊的被称为”基础容器“的pause容器pause容器对应的镜像属于k8s平台的一部分处理pause容器每个pod还包含一个或多个紧密相关的用户应用容器
kubernetes中的pause容器主要为每个容器提供以下功能
在pod中担任linux命名空间(如网络命名空间)共享的基础
启用pid命名空间开启init进程
协助他的容器生命周期
提供健康检查和生存探针
k8s设计这样的pod概念和特殊组成结构有什么用意
在一组容器作为一个单元的情况下难以对整体的容器简单地进行判断及有效地进行行动。比如一个容器死亡了 那么引入与业务无关的Pause容器作为Pod的基础容器以它的状态代表着整个容器组的状态这样就可以解决该问题
Pod里的多个应用容器共享Pause容器的IP共享Pause容器挂载的Volume这样简化了应用容器之间的通信问题也解决了容器之间的文件共享问题
pod分类
自主式pod
这种Pod本身是不能自我修复的当Pod被创建后不论是由你直接创建还是被其他Controller都会被Kuberentes调度到集群的Node上。直到Pod的进程终止、被删掉、因为缺少资源而被驱逐、或者Node故障之前这个Pod都会一直保持在那个Node上。Pod不会自愈。如果Pod运行的Node故障或者是调度器本身故障这个Pod就会被删除。同样的如果Pod所在Node缺少资源或者Pod处于维护状态Pod也会被驱逐
控制器管理的pod
Kubernetes使用更高级的称为Controller的抽象层来管理Pod实例。Controller可以创建和管理多个Pod提供副本管理、滚动升级和集群级别的自愈能力。例如如果一个Node故障Controller就能自动将该节点上的Pod调度到其他健康的Node上。虽然可以直接使用Pod但是在Kubernetes中通常是使用Controller来管理Pod的
pod容器的分类
基础容器infrastructure container
基础容器维护整个pod网络和存储空间每次创建pod的时候会创建运行的每一个pod都有一个 pause-amd64 的基础容器自动会运行对于用户是透明的
#创建一个自主式的pod在对应的node节点查看
kubectl run nginx --imagenginx kubectl get pod -owide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx 1/1 Running 0 86s 10.244.1.52 node01 none none#对应节点查看
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
abad514a5b53 nginx /docker-entrypoint.… 3 minutes ago Up 3 minutes k8s_nginx_nginx_default_4a2b568c-1e4d-481c-a236-0dc7b5e96ed1_0
79ae20dbfdba k8s.gcr.io/pause:3.2 /pause 4 minutes ago Up 4 minutes k8s_POD_nginx_default_4a2b568c-1e4d-481c-a236-0dc7b5e96ed1_0初始化容器initcontainers
Init容器必须在应用程序容器启动之前运行完成而应用程序容器是并行运行的所以Init容器能够提供了一种简单的阻塞或延迟应用容器的启动的方法
Init 容器与普通的容器非常像除了以下两点
Init 容器总是运行到成功完成为止
每个 Init 容器都必须在下一个 Init 容器启动之前成功完成启动和退出
如果 Pod 的 Init 容器失败k8s 会不断地重启该 Pod直到 Init 容器成功为止。然而如果 Pod 对应的重启策略restartPolicy为 Never它不会重新启动
Init 的容器作用
因为init容器具有与应用容器分离的单独镜像其启动相关代码具有如下优势
Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。例如没有必要仅为了在安装过程中使用类似 sed、 awk、 python 或 dig 这样的工具而去FROM 一个镜像来生成一个新的镜像
Init 容器可以安全地运行这些工具避免这些工具导致应用镜像的安全性降低
应用镜像的创建者和部署者可以各自独立工作而没有必要联合构建一个单独的应用镜像
Init 容器能以不同于Pod内应用容器的文件系统视图运行。因此Init容器可具有访问 Secrets 的权限而应用容器不能够访问
由于 Init 容器必须在应用容器启动之前运行完成因此 Init 容器提供了一种机制来阻塞或延迟应用容器的启动
直到满足了一组先决条件。一旦前置条件满足Pod内的所有的应用容器会并行启动
cd /mntvim test1.yaml
apiVersion: v1
kind: Pod
metadata:name: myapp-podlabels:app: myapp
spec:containers:- name: myapp-containerimage: busybox:1.28command: [sh, -c, echo The app is running! sleep 3600 ]initContainers:- name: init-myserviceimage: busybox:1.28command: [sh, -c, until nslookup myservice; do echo waiting for myservice; sleep 2; done;]- name: init-mydbimage: busybox:1.28command: [sh, -c, until nslookup mydb; do echo waiting for mydb; sleep 2; done;]#这个例子是定义了一个具有 2 个 Init 容器的简单 Pod。 第一个等待 myservice 启动 第二个等待 mydb 启动。 一旦这两个 Init容器都启动完成Pod 将启动 spec 中的应用容器。特别说明
●在Pod启动过程中Init容器会按顺序在网络和数据卷初始化之后启动。每个容器必须在下一个容器启动之前成功退出。
●如果由于运行时或失败退出将导致容器启动失败它会根据Pod的restartPolicy指定的策略进行重试。然而如果Pod的restartPolicy设置为AlwaysInit容器失败时会使用RestartPolicy策略。
●在所有的Init容器没有成功之前Pod将不会变成Ready状态。Init容器的端口将不会在Service中进行聚集。正在初始化中的Pod处于Pending状态但应该会将Initializing状态设置为true。
●如果Pod重启所有Init容器必须重新执行。
●对Init容器spec的修改被限制在容器image字段修改其他字段都不会生效。更改Init容器的image字段等价于重启该Pod。
●Init容器具有应用容器的所有字段。除了readinessProbe因为Init容器无法定义不同于完成completion的就绪readiness之外的其他状态。这会在验证过程中强制执行。
●在Pod中的每个app和Init容器的名称必须唯一与任何其它容器共享同一个名称会在验证时抛出错误。
#查看状态
kubectl get pod
NAME READY STATUS RESTARTS AGE
myapp-pod 0/1 Init:0/2 0 3m47s
nginx 1/1 Running 0 32m#没有启动成功查看具体信息
kubectl describe pod myapp-pod...Events:Type Reason Age From Message---- ------ ---- ---- -------Normal Scheduled 5m44s default-scheduler Successfully assigned default/myapp-pod to node02Normal Pulling 5m43s kubelet Pulling image busybox:1.28Normal Pulled 5m26s kubelet Successfully pulled image busybox:1.28 in 17.339782474sNormal Created 5m26s kubelet Created container init-myserviceNormal Started 5m26s kubelet Started container init-myservice#无法创建init-myservice查看日志获取详细信息
kubectl logs my-service -c init-myservice...waiting for myservice
nslookup: cant resolve myservice
nslookup: cant resolve myservice
Server: 10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.localwaiting for myservice
Server: 10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.localwaiting for myservice
nslookup: cant resolve myservice#找不到myservice域名无法跳出循环#编写myservice的service的yaml文件
vim myservice.yamlapiVersion: v1
kind: Service
metadata:name: myservice
spec:ports:- protocol: TCPport: 80targetPort: 9376kubectl get pod
kubectl get pod
NAME READY STATUS RESTARTS AGE
myapp-pod 0/1 Init:1/2 0 18m
nginx 1/1 Running 0 47m#已经恢复一个查看另一个的情况
kubectl describe pod myapp-db...Events:Type Reason Age From Message---- ------ ---- ---- -------Normal Scheduled 19m default-scheduler Successfully assigned default/myapp-pod to node02Normal Pulling 19m kubelet Pulling image busybox:1.28Normal Pulled 19m kubelet Successfully pulled image busybox:1.28 in 17.339782474sNormal Created 19m kubelet Created container init-myserviceNormal Started 19m kubelet Started container init-myserviceNormal Pulled 76s kubelet Container image busybox:1.28 already present on machineNormal Created 76s kubelet Created container init-mydbNormal Started 76s kubelet Started container init-mydb#查看日志
kubectl logs myapp-db -c init-mydb...waiting for mydb
nslookup: cant resolve mydb
nslookup: cant resolve mydb
Server: 10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.localwaiting for mydb
Server: 10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.localnslookup: cant resolve mydb
waiting for mydb#同样的创建mydb的service对应的yaml文件vim mydb.yamlapiVersion: v1
kind: Service
metadata:name: mydb
spec:ports:- protocol: TCPport: 80targetPort: 9377kubectl apply -f mydb.yamlkubectl get pod
NAME READY STATUS RESTARTS AGE
myapp-pod 1/1 Running 0 84m
nginx 1/1 Running 0 113m
应用容器Maincontainer
应用容器会在init容器完成并退出后并行启动
镜像拉取策略image PullPolicy
Pod 的核心是运行容器必须指定容器引擎比如 Docker启动容器时需要拉取镜像k8s 的镜像拉取策略可以由用户指定
IfNotPresent
在镜像已经存在的情况下kubelet 将不再去拉取镜像仅当本地缺失时才从仓库中拉取默认的镜像拉取策略
Always
每次创建 Pod 都会重新拉取一次镜像
Never
Pod 不会主动拉取这个镜像仅使用本地镜像
注意 对于标签为“:latest”的镜像文件其默认的镜像获取策略即为“Always”而对于其他标签的镜像其默认策略则为“IfNotPresent”
vim test2.yamlapiVersion: v1
kind: Pod
metadata:name: pod-test1
spec:containers:- name: nginximage: nginximagePullPolicy: Alwayscommand: [echo , SUCCESS]kubectl apply -f test2.yamlkubectl get pods -o wide #此时 Pod 的状态异常原因是 echo 执行完进程终止容器生命周期也就结束NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
myapp-pod 1/1 Running 0 98m 10.244.2.37 node02 none none
nginx 1/1 Running 0 126m 10.244.1.52 node01 none none
pod-test1 0/1 CrashLoopBackOff 1 41s 10.244.2.38 node02 none nonekubectl describe pod pod-test1
#可以发现 Pod 中的容器在生命周期结束后由于 Pod 的重启策略为 Always容器再次重启了并且又重新开始拉取镜像
...Events:Type Reason Age From Message---- ------ ---- ---- -------Normal Scheduled 2m3s default-scheduler Successfully assigned default/pod-test1 to node02Normal Pulled 107s kubelet Successfully pulled image nginx in 15.734730617sNormal Pulled 91s kubelet Successfully pulled image nginx in 15.675328748sNormal Pulled 62s kubelet Successfully pulled image nginx in 15.607262669sNormal Pulling 36s (x4 over 2m3s) kubelet Pulling image nginxNormal Created 21s (x4 over 107s) kubelet Created container nginxNormal Pulled 21s kubelet Successfully pulled image nginx in 15.577490682sNormal Started 20s (x4 over 107s) kubelet Started container nginxWarning BackOff 4s (x6 over 90s) kubelet Back-off restarting failed container#修改 test2.yaml文件
vim test2.yamlapiVersion: v1
kind: Pod
metadata:name: pod-test1
spec:containers:- name: nginximage: nginx:1.14 #修改 nginx 镜像版本imagePullPolicy: Always#command: [ echo, SUCCESS ] #删除#删除原有的资源
kubectl delete -f test2.yaml #更新资源
kubectl apply -f test2.yaml #查看 Pod 状态
kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
myapp-pod 1/1 Running 0 104m 10.244.2.37 node02 none none
nginx 1/1 Running 0 133m 10.244.1.52 node01 none none
pod-test1 1/1 Running 0 66s 10.244.2.39 node02 none none#在任意 node 节点上使用 curl 查看头部信息curl -I 10.244.2.39HTTP/1.1 200 OK
Server: nginx/1.14.2
Date: Mon, 27 May 2024 11:47:16 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Tue, 04 Dec 2018 14:44:49 GMT
Connection: keep-alive
ETag: 5c0692e1-264
Accept-Ranges: bytes
重启策略restartPolicy
当 Pod 中的容器退出时通过节点上的 kubelet 重启容器。适用于 Pod 中的所有容器。
Always
当容器终止退出后总是重启容器默认策略
OnFailure
当容器异常退出退出状态码非0时重启容器正常退出则不重启容器
Never
当容器终止退出从不重启容器。
注意 K8S 中不支持重启 Pod 资源只有删除重建
vim test3.yamlapiVerson: v1
kind: Pod
metadata:name: foo
spec:containers:- name: busyboximage: busyboxargs:- /bin/sh- -c- sleep 30 ; exit 3kubectl apply -f test3.yaml#查看Pod状态等容器启动后30秒后执行exit退出进程进入error状态就会重启次数加1
kubectl get pod
NAME READY STATUS RESTARTS AGE
foo 0/1 Error 0 53s
myapp-pod 1/1 Running 0 117m
nginx 1/1 Running 0 146m
pod-test1 1/1 Running 0 13m
[rootmaster01 mnt]#kubectl get pod
NAME READY STATUS RESTARTS AGE
foo 1/1 Running 1 78s
myapp-pod 1/1 Running 0 117m
nginx 1/1 Running 0 146m
pod-test1 1/1 Running 0 14mkubectl delete -f test3.yaml对test3.yaml进行修改apiVersion: v1
kind: Pod
metadata:name: foo
spec:containers:- name: busyboximage: busyboxargs:- /bin/sh- -c- sleep 30; exit 3restartPolicy: Never #添加该内容 注意跟container同一个级别kubectl apply -f test3.yaml容器进入error状态不会进行重启
kubectl get pod -w NAME READY STATUS RESTARTS AGE
foo 1/1 Running 0 2s
myapp-pod 1/1 Running 0 126m
nginx 1/1 Running 0 154m
pod-test1 1/1 Running 0 22m
foo 0/1 Error 0 33s资源限制
当定义 Pod 时可以选择性地为每个容器设定所需要的资源数量。 最常见的可设定资源是 CPU 和内存大小以及其他类型的资源
当为 Pod 中的容器指定了 request 资源时调度器就使用该信息来决定将 Pod 调度到哪个节点上。当还为容器指定了 limit 资源时kubelet 就会确保运行的容器不会使用超出所设的 limit 资源量。kubelet 还会为容器预留所设的 request 资源量 供该容器使用
如果 Pod 运行所在的节点具有足够的可用资源容器可以使用超出所设置的 request 资源量。不过容器不可以使用超出所设置的 limit 资源量
如果给容器设置了内存的 limit 值但未设置内存的 request 值Kubernetes 会自动为其设置与内存 limit 相匹配的 request 值。 类似的如果给容器设置了 CPU 的 limit 值但未设置 CPU 的 request 值则 Kubernetes 自动为其设置 CPU 的 request 值 并使之与 CPU 的 limit 值匹配
Pod 和 容器 的资源请求和限制
spec.containers[].resources.requests.cpu 定义创建容器时预分配的CPU资源 spec.containers[].resources.requests.memory 定义创建容器时预分配的内存资源 spec.containers[].resources.limits.cpu 定义 cpu 的资源上限 spec.containers[].resources.limits.memory 定义内存的资源上限
CPU 资源单位
CPU 资源的 request 和 limit 以 cpu 为单位。Kubernetes 中的一个 cpu 相当于1个 vCPU1个超线程
Kubernetes 也支持带小数 CPU 的请求。spec.containers[].resources.requests.cpu 为 0.5 的容器能够获得一个 cpu 的 、一半 CPU 资源类似于Cgroup对CPU资源的时间分片。表达式 0.1 等价于表达式 100m毫核表示每 1000 毫秒内容器可以使用的 CPU 时间总量为 0.1*1000 毫秒
Kubernetes 不允许设置精度小于 1m 的 CPU 资源
内存 资源单位
内存的 request 和 limit 以字节为单位。可以以整数表示或者以10为底数的指数的单位E、P、T、G、M、K来表示 或者以2为底数的指数的单位Ei、Pi、Ti、Gi、Mi、Ki来表示。 如1KB10^310001MB10^610000001000KB1GB10^910000000001000MB 1KiB2^1010241MiB2^2010485761024KiB
apiVersion: v1
kind: Pod
metadata:name: frontend
spec:containers:- name: appimage: images.my-company.example/app:v4env:- name: MYSQL_ROOT_PASSWORDvalue: passwordresources:requests:memory: 64Micpu: 250mlimits:memory: 128Micpu: 500m- name: log-aggregatorimage: images.my-company.example/log-aggregator:v6resources:requests:memory: 64Micpu: 250mlimits:memory: 128Micpu: 500m#此例子中的 Pod 有两个容器。每个容器的 request 值为 0.25 cpu 和 64MiB 内存每个容器的 limit 值为 0.5 cpu 和 128MiB 内存。那么可以认为该 Pod 的总的资源 request 为 0.5 cpu 和 128 MiB 内存总的资源 limit 为 1 cpu 和 256MiB 内存。vim test4.yamlapiVersion: v1
kind: Pod
metadata:name: frontend
spec:containers:- name: webimage: nginxenv:- name: WEB_ROOT_PASSWORDvalue: passwordresources:requests:memory: 64Micpu: 250mlimits:memory: 128Micpu: 500m- name: dbimage: mysqlenv:- name: MYSQL_ROOT_PASSWORDvalue: abc123resources:requests:memory: 128Micpu: 0.5limits:memory: 256Micpu: 1kubectl apply -f test5.yamlkubectl describe pod frontend
...web:Container ID: docker://8ecf144751da4110f4dd5e67f7598ec4a6d38b345e9a79c8468ecb0f1cfb564fImage: nginxImage ID: docker-pullable://nginxsha256:0d17b565c37bcbd895e9d92315a05c1c3c9a29f762b011a10c54a66cd53c9b31Port: noneHost Port: noneState: RunningStarted: Mon, 27 May 2024 21:14:59 0800Ready: TrueRestart Count: 0Limits:cpu: 500mmemory: 128MiRequests:cpu: 250mmemory: 64MiEnvironment:WEB_ROOT_PASSWORD: passwordMounts:/var/run/secrets/kubernetes.io/serviceaccount from default-token-kr2xl (ro)db:Container ID: docker://1155ff3a8bd64c460dc728a0bc9136bcf069edd5bf828ddd90d58342bf03ab57Image: mysqlImage ID: docker-pullable://mysqlsha256:e9027fe4d91c0153429607251656806cc784e914937271037f7738bd5b8e7709Port: noneHost Port: noneState: RunningStarted: Mon, 27 May 2024 21:15:16 0800Ready: TrueRestart Count: 0Limits:cpu: 1memory: 1GiRequests:cpu: 500mmemory: 512Mi...kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
frontend 2/2 Running 0 3m59s 10.244.1.57 node01 none nonekubectl get nodes node01...
Non-terminated Pods: (3 in total)Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits AGE--------- ---- ------------ ---------- --------------- ------------- ---default frontend 750m (37%) 1500m (75%) 576Mi (33%) 1152Mi (66%) 5m20skube-flannel kube-flannel-ds-vq46g 100m (5%) 0 (0%) 50Mi (2%) 0 (0%) 11dkube-system kube-proxy-qztsc 0 (0%) 0 (0%) 0 (0%) 0 (0%) 11d
Allocated resources:(Total limits may be over 100 percent, i.e., overcommitted.)Resource Requests Limits-------- -------- ------cpu 850m (42%) 1500m (75%)memory 626Mi (36%) 1152Mi (66%)ephemeral-storage 0 (0%) 0 (0%)hugepages-1Gi 0 (0%) 0 (0%)hugepages-2Mi 0 (0%) 0 (0%)
Events: none
健康检查又称为探针Probe
探针是由kubelet对容器执行的定期诊断
探针的三种规则
livenessProbe 判断容器是否正在运行。如果探测失败则kubelet会杀死容器并且容器将根据 restartPolicy 来设置 Pod 状态。 如果容器不提供存活探针则默认状态为Success。
readinessProbe 判断容器是否准备好接受请求。如果探测失败端点控制器将从与 Pod 匹配的所有 service 址endpoints 中剔除删除该Pod的IP地。 初始延迟之前的就绪状态默认为Failure。如果容器不提供就绪探针则默认状态为Success。
startupProbe这个1.17版本增加的 判断容器内的应用程序是否已启动主要针对于不能确定具体启动时间的应用。如果配置了 startupProbe 探测在则在 startupProbe 状态为 Success 之前其他所有探针都处于无效状态直到它成功后其他探针才起作用。 如果 startupProbe 失败kubelet 将杀死容器容器将根据 restartPolicy 来重启。如果容器没有配置 startupProbe 则默认状态为 Success
注意以上规则可以同时定义。在readinessProbe检测成功之前Pod的running状态是不会变成ready状态的
Probe支持三种检查方法
exec 在容器内执行指定命令。如果命令退出时返回码为0则认为诊断成功
tcpSocket 对指定端口上的容器的IP地址进行TCP检查三次握手。如果端口打开则诊断被认为是成功的
httpGet 对指定的端口和路径上的容器的IP地址执行HTTPGet请求。如果响应的状态码大于等于200且小于400则诊断被认为是成功的
每次探测都将获得以下三种结果之一成功 容器通过了诊断。失败 容器未通过诊断。未知 诊断失败因此不会采取任何行动
apiVersion: v1
kind: Pod
metadata:labels:test: livenessname: liveness-exec
spec:containers:- name: livenessimage: k8s.gcr.io/busyboxargs:- /bin/sh- -c- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 60;livenessProde:exec:command:- cat- /tmp/healthyfailureThreshold: 1initialDelaySeconds: 5periodSeconds: 5#initialDelaySeconds指定 kubelet 在执行第一次探测前应该等待5秒即第一次探测是在容器启动后的第6秒才开始执行。默认是 0 秒最小值是 0
#periodSeconds指定了 kubelet 应该每 5 秒执行一次存活探测。默认是 10 秒。最小值是 1。
#failureThreshold: 当探测失败时Kubernetes 将在放弃之前重试的次数。 存活探测情况下的放弃就意味着重新启动容器。就绪探测情况下的放弃 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。
#timeoutSeconds探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。在 Kubernetes 1.20 版本之前exec 探针会忽略 timeoutSeconds 探针会无限期地 持续运行甚至可能超过所配置的限期直到返回结果为止。可以看到 Pod 中只有一个容器。kubelet 在执行第一次探测前需要等待 5 秒kubelet 会每 5 秒执行一次存活探测。kubelet 在容器内执行命令 cat /tmp/healthy 来进行探测。如果命令执行成功并且返回值为 0kubelet 就会认为这个容器是健康存活的。 当到达第 31 秒时这个命令返回非 0 值kubelet 会杀死这个容器并重新启动它#exec方式测试vim test5.yamlapiVersion: v1
kind: Pod
metadata:name: liveness-execnamespace: default
spec:containers:- name: liveness-exec-containerimage: busyboximagePullPolicy: IfNotPresentcommand: [/bin/sh , -c , touch /tmp/live; sleep 30; rm -rf /tmp/live; sleep 60;]livenessProbe:exec:command: [test,-e,/tmp/live]initialDelaySeconds: 1periodSeconds: 3kubectl apply -f test5.yamlkubectl describe pods liveness-exec...Events:Type Reason Age From Message---- ------ ---- ---- -------Normal Scheduled 2m56s default-scheduler Successfully assigned default/liveness-exec to node02Normal Pulling 2m56s kubelet Pulling image busyboxNormal Pulled 2m38s kubelet Successfully pulled image busybox in 17.889125702sWarning Unhealthy 51s (x6 over 2m6s) kubelet Liveness probe failed:Normal Killing 51s (x2 over 2m) kubelet Container liveness-exec-container failed liveness probe, will be restartedNormal Created 21s (x3 over 2m38s) kubelet Created container liveness-exec-containerNormal Started 21s (x3 over 2m38s) kubelet Started container liveness-exec-containerNormal Pulled 21s (x2 over 90s) kubelet Container image busybox already present on machinekubectl get pods -w #当检测失败时便会重启
NAME READY STATUS RESTARTS AGE
frontend 2/2 Running 0 37m
liveness-exec 1/1 Running 0 26s
liveness-exec 1/1 Running 1 88s
liveness-exec 1/1 Running 2 2m37shttpGet方式测试apiVersion: v1
kind: Pod
metadata:labels:test: livenessname: liveness-http
spec:containers:- name: livenessimage: k8s.gcr.io/livenessargs:- /serverlivenessProde:httpGet:path: /healthzport: 8080httpHeaders:- name: Custom-Headervalue: AwsomeinitialDelaySeconds: 3periodSeconds: 3#在这个配置文件中可以看到 Pod 也只有一个容器。initialDelaySeconds 字段告诉 kubelet 在执行第一次探测前应该等待 3 秒。periodSeconds 字段指定了 kubelet 每隔 3 秒执行一次存活探测。kubelet 会向容器内运行的服务服务会监听 8080 端口发送一个 HTTP GET 请求来执行探测。如果服务器上 /healthz 路径下的处理程序返回成功代码则 kubelet 认为容器是健康存活的。如果处理程序返回失败代码则 kubelet 会杀死这个容器并且重新启动它vim test6.yaml
apiVersion: v1
kind: Pod
metadata:name: liveness-httpgetnamespace: default
spec:containers:- name: liveness-httpget-containerimage: soscscs/myapp:v1imagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 80livenessProbe:httpGet:port: httppath: /index.htmlinitialDelaySeconds: 1periodSeconds: 3timeoutSeconds: 10kubectl apply -f test6.yamlkubectl exec -it liveness-httpget -- rm -rf /usr/share/nginx/html/index.htmlkubectl get pods
NAME READY STATUS RESTARTS AGE
liveness-httpget 1/1 Running 1 2m44stcpSocket方式测试apiVersion: v1
kind: Pod
metadata:name: goproxylabels:app: goproxy
spec:containers:- name: goproxyimage: k8s.gcr.io/goproxy:0.1ports:- containerPort: 8080readinessProbe:tcpSocket:port: 8080initialDelaySeconds: 5periodSeconds: 10livenessProbe:tcpSocket:port: 8080initialDelaySeconds: 15periodSeconds: 20这个例子同时使用 readinessProbe 和 livenessProbe 探测。kubelet 会在容器启动 5 秒后发送第一个 readinessProbe 探测。这会尝试连接 goproxy 容器的 8080 端口。如果探测成功kubelet 将继续每隔 10 秒运行一次检测。除了 readinessProbe 探测这个配置包括了一个 livenessProbe 探测。kubelet 会在容器启动 15 秒后进行第一次 livenessProbe 探测。就像 readinessProbe 探测一样会尝试连接 goproxy 容器的 8080 端口。如果 livenessProbe 探测失败这个容器会被重新启动。vim test7.yaml
apiVersion: v1
kind: Pod
metadata:name: probe-tcp
spec:containers:- name: nginximage: soscscs/myapp:v1livenessProbe:initialDelaySeconds: 5timeoutSeconds: 1tcpSocket:port: 8080periodSeconds: 10failureThreshold: 2kubectl apply -f tcpsocket.yamlkubectl exec -it probe-tcp -- netstat -natp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1/nginx: master prokubectl get pods -w
NAME READY STATUS RESTARTS AGE
probe-tcp 1/1 Running 0 1s
probe-tcp 1/1 Running 1 25s #第一次是 init(5秒) period(10秒) * 2
probe-tcp 1/1 Running 2 45s #第二次是 period(10秒) period(10秒) 重试了两次
probe-tcp 1/1 Running 3 65s就绪检测vim test8.yamlapiVersion: v1
kind: Pod
metadata:name: readiness-httpgetnamespace: default
spec:containers:- name: readiness-httpget-containerimage: soscscs/myapp:v1imagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 80readinessProbe:httpGet:port: 80path: /index1.htmlinitialDelaySeconds: 1periodSeconds: 3livenessProbe:httpGet:port: httppath: /index.htmlinitialDelaySeconds: 1periodSeconds: 3timeoutSeconds: 10kubectl apply -f test8.yamlkubectl get pods #readiness探测失败无法进入READY状态
NAME READY STATUS RESTARTS AGE
readiness-httpget 0/1 Running 0 18skubectl exec -it readiness-httpget sh# cd /usr/share/nginx/html/# ls
50x.html index.html# echo 123 index1.html # exitkubectl get pods
NAME READY STATUS RESTARTS AGE
readiness-httpget 1/1 Running 0 2m31skubectl exec -it readiness-httpget -- rm -rf /usr/share/nginx/html/index.htmlkubectl get pods -w
NAME READY STATUS RESTARTS AGE
readiness-httpget 1/1 Running 0 4m10s
readiness-httpget 0/1 Running 1 4m15s就绪检测2vim test9.yamlapiVersion: v1
kind: Pod
metadata:name: myapp1labels:app: myapp
spec:containers:- name: myappimage: soscscs/myapp:v1ports:- name: httpcontainerPort: 80readinessProbe:httpGet:port: 80path: /index.htmlinitialDelaySeconds: 5periodSeconds: 5timeoutSeconds: 10
---
apiVersion: v1
kind: Pod
metadata:name: myapp2labels:app: myapp
spec:containers:- name: myappimage: soscscs/myapp:v1ports:- name: httpcontainerPort: 80readinessProbe:httpGet:port: 80path: /index.htmlinitialDelaySeconds: 5periodSeconds: 5timeoutSeconds: 10
---
apiVersion: v1
kind: Pod
metadata:name: myapp3labels:app: myapp
spec:containers:- name: myappimage: soscscs/myapp:v1ports:- name: httpcontainerPort: 80readinessProbe:httpGet:port: 80path: /index.htmlinitialDelaySeconds: 5periodSeconds: 5timeoutSeconds: 10
---
apiVersion: v1
kind: Service
metadata:name: myapp
spec:selector:app: myapptype: ClusterIPports:- name: httpport: 80targetPort: 80kubectl apply -f test9.yamlkubectl get pods,svc,endpoints -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod/myapp1 1/1 Running 0 29s 10.244.2.44 node02 none none
pod/myapp2 1/1 Running 0 29s 10.244.2.43 node02 none none
pod/myapp3 1/1 Running 0 29s 10.244.1.62 node01 none none
pod/readiness-httpget 0/1 Running 1 14m 10.244.1.61 node01 none noneNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
service/kubernetes ClusterIP 10.96.0.1 none 443/TCP 11d none
service/myapp ClusterIP 10.96.106.147 none 80/TCP 29s appmyapp
service/mydb ClusterIP 10.96.134.191 none 80/TCP 4h32m none
service/myservice ClusterIP 10.96.47.106 none 80/TCP 5h37m noneNAME ENDPOINTS AGE
endpoints/kubernetes 192.168.111.7:6443 11d
endpoints/myapp 10.244.1.62:80,10.244.2.43:80,10.244.2.44:80 28skubectl exec -it pod/myapp1 -- rm -rf /usr/share/nginx/html/index.html
readiness探测失败Pod 无法进入READY状态且端点控制器将从 endpoints 中剔除删除该 Pod 的 IP 地址kubectl get pods,svc,endpoints -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod/myapp1 1/1 Running 0 97s 10.244.2.44 node02 none none
pod/myapp2 1/1 Running 0 97s 10.244.2.43 node02 none none
pod/myapp3 1/1 Running 0 97s 10.244.1.62 node01 none none
pod/readiness-httpget 0/1 Running 1 15m 10.244.1.61 node01 none noneNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
service/kubernetes ClusterIP 10.96.0.1 none 443/TCP 11d none
service/myapp ClusterIP 10.96.106.147 none 80/TCP 97s appmyapp
service/mydb ClusterIP 10.96.134.191 none 80/TCP 4h33m none
service/myservice ClusterIP 10.96.47.106 none 80/TCP 5h38m noneNAME ENDPOINTS AGE
endpoints/kubernetes 192.168.111.7:6443 11d
endpoints/myapp 10.244.1.62:80,10.244.2.43:80,10.244.2.44:80 96s启动、退出动作
vim test10.yamlapiVersion: v1
kind: Pod
metadata:name: lifecycle-demo
spec:containers:- name: lifecycle-demo-containerimage: soscscs/myapp:v1lifecycle: #此为关键字段postStart:exec:command: [/bin/sh, -c, echo Hello from the postStart handler /var/log/nginx/message] preStop:exec:command: [/bin/sh, -c, echo Hello from the poststop handler /var/log/nginx/message]volumeMounts:- name: message-logmountPath: /var/log/nginx/readOnly: falseinitContainers:- name: init-myserviceimage: soscscs/myapp:v1command: [/bin/sh, -c, echo Hello initContainers /var/log/nginx/message]volumeMounts:- name: message-logmountPath: /var/log/nginx/readOnly: falsevolumes:- name: message-loghostPath:path: /data/volumes/nginx/log/type: DirectoryOrCreatekubectl apply -f test10.yamlkubectl get pods -owidekubectl exec -it lifecycle-demo -- cat /var/log/nginx/messageHello initContainers
Hello from the postStart handler在node02上查看
cat /data/volumes/nginx/log/message Hello initContainers
Hello from the postStart handler#由上可知init Container先执行然后当一个主容器启动后Kubernetes 将立即发送 postStart 事件。#删除 pod 后再在 node02 节点上查看
kubectl delete pod lifecycle-demo#在node02上查看cat /data/volumes/nginx/log/message
Hello initContainers
Hello from the postStart handler
Hello from the poststop handler#由上可知当在容器被终结之前 Kubernetes 将发送一个 preStop 事件。
pod状态
pending pod已经被系统认可了但是内部的container还没有创建出来。这里包含调度到node上的时间以及下载镜像的时间会持续一小段时间
Running pod已经与node绑定了调度成功而且pod中所有的container已经创建出来至少有一个容器在运行中或者容器的进程正在启动或者重启状态。--这里需要注意pod虽然已经Running了但是内部的container不一定完全可用。因此需要进一步检测container的状态
Succeeded 这个状态很少出现表明pod中的所有container已经成功的terminated了而且不会再被拉起了
Failed pod中的所有容器都被terminated至少一个container是非正常终止的。退出的时候返回了一个非0的值或者是被系统直接终止
unknown 由于某些原因pod的状态获取不到有可能是由于通信问题。 一般情况下pod最常见的就是前两种状态。而且当Running的时候需要进一步关注container的状态 Container生命周期
Waiting 启动到运行中间的一个等待状态。
Running 运行状态。
Terminated 终止状态。 如果没有任何异常的情况下container应该会从Waiting状态变为Running状态这时容器可用
但如果长时间处于Waiting状态container会有一个字段reason表明它所处的状态和原因如果这个原因很容易能标识这个容器再也无法启动起来时例如ContainerCannotRun整个服务启动就会迅速返回
