一个pod里面最少两个容器:
一个是pause容器，
另一个是指定运行的容器.
k8s为每一个pod都分配唯一的IP地址，称之为pod ip，一个pod中的多个容器共享pod ip地址,。
k8s要求底层网络支持集群内任意两个pod之间网络通信，采用虚拟二层技术实现，比如flanne、 calico、 ovs。 k8s中，一个pod的容器与另外主机上的pod容器能够直接通信。
init容器(初始化容器)
参考: https://www.jianshu.com/p/42afb9d9bfff
initContainer(初始化容器)会比普通container先启动；会按照定义的顺序启动，而普通的container是并发启动的；执行成功后结束退出，普通容器会一直执行
- InitContainer先于普通容器启动执行
- 多个InitContainer的执行是按定义次序串行执行，而多个普通容器是并行执行
- InitContainer执行成功后就结束退出，而普通容器可以一直执行
- Pod重启时，InitContainer会再次执行
pause容器(Infra容器)
kubernetes中的pause容器主要为每个业务容器 提供以下功能:
PID命名空间:Pod中的不同应用程序可以看到其他应用程序的进程ID。
网络命名空间:Pod中的多个容器能够访问同 一个IP和端口范围。
IPC命名空间:Pod中的多个容器能够使用 SystemV IPC或POSIX消息队列进行通信。
UTS命名空间:Pod中的多个容器共享一个主 机名;Volumes(共享存储卷):
Pod中的各个容器可以访问在Pod级别定义的 Volumes.
每个Pod都有一个特殊的称之为“根容器”的Pause容器。 Pause容器对应的镜像属于k8s平台的一部分，除了Pause容器外，每个Pod还包含一个或多个紧密相关的用户业务容器。他为每个业务容器提供如下功能：
①在pod中担任Linux命名空间共享的基础。
②启用pid命名空间，开启init进程。
引入这种方式的原因：
- 一组容器运行的pod中，很难对整体进行判断，引入pasue作为根容器，以它的状态代表整个容器组的状态。
- pod中多个容器共享pasue容器的IP，共享pause容器挂载的volume。
这样简化了密切相连的容器之间的通信，也解决了他们之间文件共享的问题。
修改默认infro容器
普通pod：
一旦被创建，会被放到etcd中存储，随后被k8s master调度到某个具体的node上并进行绑定，随后该pod被对应的node上的kubelet进程实例化成一组相关的docker容器并启动起来。默认情况下，当pod中的某个容器停止时，
K8s会自动检测到这个问题并重新启动这个pod（重启pod里面的所有容器），如果pod所在的node宕机，则会将这个
node上的所有pod重新调度到其他节点上。
pod资源限制:
每个pod可以设置限额，目前可以设置CPU和内存， cpu的单位为core的数量，
是一个绝对值而不是相对值。 k8s中是以千分之一为最小单位，一般一个pod
设置为100m到300m，也是就是0.1-0.3个cpu。内存是以MB为单位
k8s设置2个参数：
:该资源的最小申请量，系统必须满足的要求
：该资源的最大允许使用的量，不能被突破，当容器试图使用超过这个
量的资源时，有可能会被k8s kill并重启。
pod生命周期介绍
Pod 对象在 Kubernetes 中的生命周期。 Pod 生命周期的变化，主要体现在 Pod API 对象的Status 部分。
其中pod.status.phase，就是 Pod 的当前状态，它有如下几种可能的情况：
Pending状态
当Pod处在Pending的时候，可能是由于如下哪个问题造成的。
- 资源不足，造成无法调度
- Pod尚未进入调度阶段
- Pod正在拉取镜像
Running状态
Succeeded状态
Failed状态
Unknown状态
error状态
一个容器出错pod状态就会显示error，会根据重启策略执行重启
CrashLoopBackOff状态
https://cloud.tencent.com/document/product/457/43130
pod 处于 状态，说明该 Pod 在正常启动过后异常退出过，此状态下 Pod 的 如果不是 就可能会被重启拉起，且 Pod 的 RestartCounts 通常大于0。可首先参考 通过 定位 , 查看对应容器进程的退出状态码，缩小异常问题范围。
容器进程主动退出时，通常在之间，导致异常的原因可能是业务程序 Bug，也可能是其他原因。请参考 容器进程主动退出 进一步定位异常问题。
可能原因:
- 容器进程主动退出
- 系统 OOM
- cgroup OOM
- 节点内存碎片化
- 健康检查失败
Completed状态
的 状态表示 Pod 中的所有容器都。这通常意味着容器已经完成了它们的工作，例如批处理作业或定时任务。
init状态
Pod一直处于init状态如何排查：https://www.cnblogs.com/huangjiabobk/p/
其他字段
更进一步地， Pod 对象的 Status 字段，还可以再细分出一组 Conditions。这些细分状态的值包括： PodScheduled、
Ready、 Initialized，以及 Unschedulable。它们主要用于描述造成当前Status 的具体原因是什么。
比如， Pod 当前的 Status 是 Pending，对应的 Condition 是 Unschedulable，这就意味着它的调度出现了问题。
Pod 的这些状态信息，是我们判断应用运行情况的重要标准，尤其是 Pod 进入了非“Running”状态后，你一定要能迅速
做出反应，根据它所代表的异常情况开始跟踪和定位，而不是去手忙脚乱地查阅文档。
官方文档
静态 Pod（Static Pod） 直接由特定节点上的 ， 不需要API 服务器看到它们。
无法与我们常用的控制器Deployments或者DaemonSeti进行关联，它由kubeleti进程自己来监控，当pod崩溃时重启该pod,kubelete也无法对他们进行健康检查。静态pod始终绑定在某一个kubelet，并且始终运行在同一个节点上。
Kubelets会自动为每一个静态pod在Kubernetes的apiserver.上创建一个，因此我们可以在apiserveri中查询到该pod，但是不能通过apiserver进行控制（例如不能删除）。
静态pod中，而是存放在某个具体的node上的一个具体文件中，并只在此node上启动运行。
静态Pod名称标识当前节点名称.
在kubelet配置文件中启用静态pod的参数
创建静态pod
创建静态Pod有两种方式：配置文件和HTTP两种方式
将静态pod的yaml文件放在路径下即可.
静态pod的yaml示例
查看静态pod
删除静态pod
从静态pod目录中删除静态podyml即可。
多容器pod重启策略
一个容器出错pod状态就会显示error，会根据重启策略执行重启
参考官方文档: https://kubernetes.io/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes
存活探针-livenessProbe
定义探针存活命令
参考: 定义探针存活命令
检查机制
exec存活检查示例
httpGet存活检查示例
就绪探针-readinessProbe
指示容器是否准备好为请求提供服务。如果就绪态探测失败， 端点控制器将从与 Pod 匹配的所有服务的端点列表中删除该 Pod 的 IP 地址。 初始延迟之前的就绪态的状态值默认为 Failure。 如果容器不提供就绪态探针，则默认状态为 Success。
在检测失败后会自动从上。
tcpSocket就绪探针和存活探针示例
的原理有点像,检查端口是否开放.
启动探针-startupProbe
指示容器中的应用是否已经启动。如果提供了启动探针，则所有其他探针都会被 禁用，直到此探针成功为止。如果启动探测失败，kubelet 将杀死容器，而容器依其 重启策略进行重启。 如果容器没有提供启动探测，则默认状态为 Success。
参考:
QoS（Quality of Service），大部分译为“服务质量等级”，又译作“服务质量保证”，是作用在 Pod 上的一个配置，当 Kubernetes 创建一个 Pod 时，它就会给这个 Pod 分配一个 QoS 等级，可以是以下等级之一：
：Pod 里的每个容器都必须有内存/CPU 限制和请求，而且值必须相等。
：Pod 里至少有一个容器有内存或者 CPU 请求且不满足 等级的要求，即内存/CPU 的值设置的不同。
：容器必须没有任何内存或者 CPU 的限制或请求。
最高优先级(Guaranteed)pod
https://www.toutiao.com/a/?log_from=f50e1823b745_14
limits和requests两个都配置了且配置的值要一样,就是最高优先级的pod.
将pod中的容器资源限制的，该pod优先级即为最高。如果资源不够时会驱逐其他pod。
启动一个pod
创建一个测试pod
使用yaml创建pod
进入ping这个测试pod
一般用来做网络测试
pod yaml 范例
镜像拉取策略
Kubernetes 中的镜像拉取策略（）有以下几种：
- : 每次都尝试拉取镜像，如果本地已经存在该镜像，则会进行覆盖。这是默认的拉取策略。
- : 仅当本地不存在该镜像时才尝试拉取。
- : 仅使用本地已经存在的镜像，如果本地不存在该镜像，则会报错。
- : 仅在上一次启动容器失败后才会尝试拉取镜像。
需要注意的是，镜像拉取策略只会影响首次容器启动时的行为，如果容器已经被创建并运行，那么更新镜像需要手动执行“-”操作。
进入pod执行命令
查看pod的ip地址
查看pod详情
查看pod资源的labels(标签)
查看运行中pod的镜像
查看pod的日志
pod扩容
HPA自动水平伸缩pod
参考: https://www.toutiao.com/a/?log_from=f50e1823b745_14
需要，
需要pod
滚动更新pod
强制删除pod
从 v1.5 开始，Kubernetes 不会因为 Node 失联而删除其上正在运行的 Pod，而是将其标记为 或 状态
用yaml强制更新pod
强制更新 pod（运行时只能修改部分内容）
华为云-pod亲和
官方doc-pod亲和示例
，例如将应用的前端和后端部署在一起，从而。
参考:
官方doc-避免同一个node上放置多个带有同标签的副本
华为云-pod反亲和
pod间亲和性和反亲和性
且
雪花啤酒的面试官问了个问题: 当时一时想不起来可以实现.
- 问题场景：
某pod业务访问k8s外部业务网络不通，怎么抓pod网络的包 - 解决办法：
容器中一般是没有命令的,可以通过上的命令进入的进行抓包.
查询pod的容器pid
进入指定pid的网络命名空间(network namespace)
Linux系统的6种类型的命名空间
例如：- 命名空间内的进程只能看到同一命名空间中的。
- 命名空间，可以将进程附加到自己的文件系统（如）。
- 在本文中，只关注网络命名空间 。
https://developer.aliyun.com/article/
在node上通过tcpdump对该容器抓包
退出网络命名空间(network namespace)
抓包完成后退出当前终端会话，就回到node的OS默认网络命名空间。
版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/cjjbc/46960.html