一:概念
Pod是一个或多个容器的组合。这些容器共享存储、网络和命名空间,以及运行规范。在Pod中,所有容器都被统一安排和调度,并运行在共享的上下文中。对于具体应用而言,Pod是它们的逻辑主机,Pod包含业务相关的多个应用容器。所以,Pod是一组具有共享命名空间、IP地址和端口的容器的集合。
备注:共享上下文是一种基于线程的内存位置
1:从使用的角度来看
在实际的使用时,单个容器是无法单独来支撑我们的应用的,往往需要很多微服务才能组成一个系统,并且还会存在A服务依赖B服务,B服务需要和C服务共用某个目录。另外,在使用裸容器时,很难实现对容器内进行健康检查以及横向扩容等操作,而Pod可以轻松解决这些问题。
2:从Kubernetes的角度来看
Docker只是容器Runtime(运行时)的一种们还有很多容器Runtime,比如Rkt、CRI-O等,而Kubernetes作为目前最流行的容器编排工具,需要支持各个Runtime并且不依赖于底层Runtime的实现技术,于是就抽象出了Pod这个概念,用于管理多个紧密相连的符合CRI标准的容器。
Pod可以简单的理解为一组、一个或多个容器,每个Pod还包含一个Pause容器,Pause容器是Pod的父容器,主要负责僵尸进程的回收管理。同时,通过Pause容器可以使同一个Pod里面的不同容器共享存储、网络、PID、IPC等,容器之间可以使用Localhost:Port的方式相互访问,可以使用volume实现数据共享。根据Docker的构造,Pod可以被创建为一组具有共享命名空卷、IP地址和端口的容器。
Pod有两个必须知道的特点:
网络:每一个Pod都会被指派一个唯一的Ip地址,在Pod中的每一个容器共享网络命名空间,包括Ip地址和网络端口。在同一个Pod中的容器可以同locahost进行互相通信。当Pod中的容器需要与Pod外的实体进行通信时,则需要通过端口等共享的网络资源。
存储:Pod能够被指定共享存储卷的集合,在Pod中所有的容器能够访问共享存储卷,允许这些容器共享数据。存储卷也允许在一个Pod持久化数据,以防止其中的容器需要被重启。
二:Pod的状态
(1)kubectl命令创建pod
kubectl run nginx --image=nginx:1.7.9 --labels="app=nginx"
(2)查看pod
kubectl get pods -n default
(3)显示Pod的更多信息
kubectl get pod nginx -o wide
(4)查看pod日志
cur110.244.58.195
kubectl logs nginx
(5)以yaml格式显示Pod详细信息
kubectl get pod nginx -o yaml
(6)显示资源的详细描述信息
kubectl describe pod nginx
备注:
- kubect.l get:常用于查看同一资源类型的一个或多个资源对象,可以使用-o参数自定义输出格式。
- kubectl describe:侧重于描述指定资源的各方面的详细信息,不仅会返回节点信息,还会返回在其上运行的Pod的摘要、节点事件等信息。
(7)在Pod的容器中执行命令
kubectl exec nginx -c nginx -date
备注:
-c:指定Pod中容器的名字
(8)登录到Pod中的容器中
kubectl exec -it nginx -c nginx -bash
备注:
kubectl exec -it nginx --bash
如果登录的时候不指定容器,就登录到Pod中的第一个容器中。
(9)在线编辑运行中的资源对象
kubectl edit pod nginx
(10)将pod的端口映射到宿主机
kubectl port-forward --address 0.0.0.0 pod/nginx 8080:80
Forwarding from 0.0.0.0:8080 -80
注意:
此命令会在前台运行,此时就可以在其他客户端用该k8s主机的IP地址和8080的端口号进行访问了,Ctrl+c停止,但停止后就没有这个映射了
(11)在宿主机和Pod的容器之间拷贝文件
kubectl cp nginx:etc/fstab /opt/aaa.txt
kubectl cp /opt/aaa.txt nginx:etc/bbb.txt
(12)Pod的状态
kubectl get pods -n default
可以看到此时的Pod的状态是Running,Pod的状态不仅仅只有Running,常见的其他状态如下表所示:
Pod状态字段Phase(阶段)的不同取值
状态 | 说明 |
pending(挂起) | Pod已经被Kubernetes系统接收,但是仍有一个或多个容器未被创建,可以通过kubectl describe查看处于Pending状态的原因。 |
Running(运行中) | Pod己经被绑定到一个节点上,并且所有的容器都已经被创建,而且至少有一个是运行的状态、正在启动或者重启,可以通过kubectl logs查看Pod的日志。 |
Succeeded | 所有容器执行成功,并终止,并且不会再次重启,可以通过kubectl logs查看Pod的日志 |
Failed(失败) | 所有容器都已终止,并且至少一个容器以失败的方式终止,也就是说这个容器要么以非零状态退出,要么被系统终止,可以通过logs和describe查看Pod的日志和状态 |
Unknown(未知) | 通常是由于通信问题造成的无法获得Pod的状态 |
ImagePullBackoff ErrImagePull | 镜像拉取失败,一般是由于镜像不存在、网络不通或者需要登录认证引起的,可以使用describe命令查看具体的原因 |
CrashLoopBackoff | 容器启动失败,可以通过logs命令查看具体的原因,一般为启动命令不正确、健康检查不通过等原因 |
OOMKilled | 容器内存溢出,一般是容器的内存Limit设置的过小,或者程序本身有内存溢出,可以通过logs查看程序的启动日志 |
Terminating | Pod正在被删除,可以通过describe查看状态 |
SysctlForbiden | Pod自定义了内核配置,但kubectl没有添加内核配置或配置的内核参数不支持,可以通过describe查看具体原因 |
Completed | 容器内部主进程退出,一般计划任务执行结束会显示该状态,此时可以通过logs查看容器日志 |
ContainerCreating | Pod正在创建,一般正在下载镜像,或者有配置不当的地方,可以通过describe查看具体原因 |
(13)删除Pod
kubectl delete pod nginx
三:Pod探针
在生产环境中,进程正常启动并不代表应用能正常处理请求,所以合理的设计应用的健康检查尤其重要。在使用裸机或裸容器部署时,一般很难对应用做很完善的健康检查,而Pod提供的探针可以很方便的用来检测容器的应用是否正常。目前探针有3种检测方式,可以根据不同的场景选择合适的健康检查方式。检查方式如下表所示。
实现方式 | 说明 |
ExecAction | 在容器内执行一个指定的命令,如果命令返回值为0,则认为容器健康 |
TCPSocketAction | 通过TCP连接检查容器指定的端口,如果端口开放,则认为容器健康 |
HTTPGetAction | 通过TCP连接检查容器指定的端口,如果端口开放,则认为容器健康 |
上述的检查方式可以被周期性的执行,每次检查容器后可能得到的容器状态如下表所示。
状态 | 说明 |
Success(成功) | 容器通过检查 |
Failure(失败) | 容器检查失败 |
Unknown(未知) | 诊断失败,因此不采取任何措施 |
Pod探针有三类,分别是:livenessProbe(存活探针)、readinessProbe(就绪探针)、startupProbe(启动探针)。
- livenessProbe(存活探针):判断容器是否正常运行,如果失败则杀掉容器(不是pod),再根据重启策略决定是否重启容器
- readinessProbe(就绪探针):判断容器是否能够进入ready状态,探针失败则进入noready状态,并从service的endpoints中剔除此容器
- startupProbe(启动探针):判断容器内的应用是否启动成功,在success状态前,其它探针都处于无效状态
四:Pod镜像拉取策略和重启策略
操作方式 | 说明 |
---|---|
Always | 总是拉取,无论镜像是否存在,总是拉取 |
Never | 无论是否存在都不拉取 |
IfNotPressent | 镜像不存在时拉取镜像,是k8s默认的策略,但是如果tag为latest,则总是拉取 |
指定拉取策略:
kubectl run nginx --image=nginx:1.7.9 --labels="app=nginx" --image-pull-policy=Never
操作方式 | 说明 |
---|---|
Always | 默认策略,容器失效时,自动重启该容器 |
OnFailure | 容器以不为0的状态码终止,自动重启该容器 |
Never | 无论何种状态,都不会重启 |
指定重启策略:
kubectl delete pod nginx
kubectl run nginx --image=nginx:1.7.9 --labels="app=nginx"--restart=OnFailure
五:Pod文件语法
(1)Pod文件的一级属性
一级属性主要包含5部分:
- apiVersion<string>版本,由kubernetes内部定义,版本号必须可以用kubectl api-versions查询到
- kind <string>类型,由kubernetes内部定义,版本号必须可以用kubectl api-resources查询到
- metadata<Object>元数据,主要是资源标识和说明,常用的有name、namespace、labels等
- spec<Object>描述,这是配置中最重要的一部分,里面是对各种资源配置的详细描述
- status<Object>状态信息,里面的内容不需要定义,由kubernetes自动生成
(2)spec(规格)属性
在一级属性中,spec是研究的重点,它的常见子属性有:
- containers<[ ]Object>容器列表,用于定义容器的详细信息
- nodeName<String>根据nodeName的值将pod调度到指定的Node节点上
- nodeSelector<map[]>根据NodeSelector中定义的信息选择将该Pod调度到包含这些label的Node上
- hostNetwork<boolean>是否使用主机网络模式,默认为false,如果设置为true,表示使用宿主机网络
- volumes<[ ]Object>存储卷,用于定义Pod上面挂在的存储信息
- restartPolicy<string>重启策略,表示Pod在遇到故障的时候的处理策略
(3)通过kubectl explain命令来查看每种资源的可配置项
- kubect1 explain pod
- kubectl explain deployment
- kubectl explain service
- kubectl explain pod.metadata
- kubectl explain pod.spec.containers
备注:
查看某种资源可以配置的一级属性
#kubectl explain资源类型
查看属性的子属性
#kubectl explain资源类型.属性
4:运行kubect!create命令创建此Pod
kubectl create -f frontend-localredis-pod.yaml
5:查看已经创建的Pod
kubectl get pods
6:查看pod详细创建信息
kubectl describe pod redis-php
7:删除pod
kubectl delete -f frontend-localredis-pod.yaml
六:Pod启动阶段(相位phase)
Pod创建完之后,一直到持久运行起来,中间有很多步骤,也就有很多出错的可能,因此会有很
多不同的状态
1:pod的启动过程包含的步骤
(1)调度到某台node上。kubernetes根据一定的优先级算法选择一台node节点将其作为Pod运行的node
(2)拉取镜像
(3)挂载存储配置等
(4)运行起来。如果有健康检查,会根据检查的结果来设置其状态
2:phase的可能状态
(1)Pending:表示APIServer创建了Pod资源对象并己经存入了etcd中,但是它并未被调度完成(比如还没有调度到某台node上),或者仍然处于从仓库下载镜像的过程中
(2)Running:Pod已经被调度到某节点之上,并且Pod中所有容器都已经被kubelet创建。至少有一个容器正在运行,或者正处于启动或者重启状态(也就是说Running状态下的Pod不一定能被正常访问)
(3)Succeeded:有些pod不是长久运行的,比如job、cronjob,一段时间后Pod中的所有容器都被成功终止,并且不会再重启。需要反馈任务执行的结果
(4)Failed:Pod中的所有容器都已终止了,并且至少有一个容器是因为失败终止。也就是说,容器以非0状态退出或者被系统终止,比如command写的有问题
(5)Unknown:表示无法读取Pod状态,通常是kube-contro1ler-manager无法与Pod通信