pod实现

pod本质是共享了Network Namespace，并且可以声明共享同一个 volume的一组容器。
Pod 的实现需要使用Infra中间容器，每个pod中Infra都是第一个被创建的容器，其他用户定义的容器，通过Join Network Namespace 的方式，与Infra容器关联在一起。例如下图中的容器 A和B可以直接使用localhost通信，看到的网络设备跟 Infra 容器看到的完全一样；一个 Pod 只有一个 IP 地址，也就是这个 Pod 的 Network Namespace 对应的 IP，Pod 的生命周期只跟 Infra 容器一致，而与容器 A和B无关。
image.png
当需要在一个容器里跑多个功能并不相关的应用时，应该优先考虑它们是否更应该被描述成一个 Pod 里的多个容器

生命周期

1、初始化容器完成初始化
2、主容器启动前后做钩子
liveness及readiness probe支持3种探测行为

  1.   - 执行自定义命令
  2.   - 指定TCP套接字发送请求
  3.   - 向指定HTTP服务发送请求

一旦存活性检测失败，会依据restartpolicy进行containter重启操作

pod知识点 - 图2

pod的状态

pod.status.phase
pod知识点 - 图3
Pending
API Server创建了Pod资源对象并已经存入etcd中，但并未被调度完成，或者仍然处于从仓库下载镜像的过程中。
Running
Pod 已经被绑定到了一个节点，所有容器已被创建。pod包含的容器至少一个正在运行，或者正在启动或重新启动。
Failed
所有容器终止，至少有一个容器以失败方式终止。也就是说，这个容器要么已非 0 状态退出，要么被系统终止。
Unknown
异常状态，意味着 Pod 的状态不能持续地被 kubelet汇报给 kube-apiserver，可能是主从节点（Master 和 Kubelet）间的通信出现了问题
image.png
image.png
https://blog.csdn.net/horsefoot/article/details/52324830

Pod创建过程

pod知识点 - 图6

  1. 用户通过kubectl或其他API客户端提交Pod Spec给API Server。
  2. API Server尝试将Pod对象的相关信息存储到etcd中，等待写入操作完成，API Server返回确认信息到客户端。
  3. API Server开始反映etcd中的状态变化。
  4. 所有的Kubernetes组件通过”watch”机制跟踪检查API Server上的相关信息变动。
  5. kube-scheduler（调度器）通过”watcher”检测到API Server创建了新的Pod对象但是没有绑定到任何工作节点。
  6. kube-scheduler为Pod对象挑选一个工作节点并将结果信息更新到API Server。
  7. 调度结果新消息由API Server更新到etcd，并且API Server也开始反馈该Pod对象的调度结果。
  8. Pod被调度到目标工作节点上的kubelet尝试在当前节点上调用docker engine进行启动容器，并将容器的状态结果返回到API Server。
  9. API Server将Pod信息存储到etcd系统中。
  10. 在etcd确认写入操作完成，API Server将确认信息发送到相关的kubelet。

https://www.cnblogs.com/linuxk/p/9569618.html

pod 网络

image.png
service:通过lable将请求转发给pod，实际可以理解为dnat转换。
pod请求送至svc，svc再通过DNAT或者ipvs 的nat模型代理至目标pod

  • 同一个pod内的多个container间共享network ns
  • pod之间
    • 同节点
      • 网桥（docker0,cni0,calio0）
    • 跨节点
      • IP直接通信（overlay,routing,underlay）

每个Pod都会被分配一个唯一的IP地址。Pod中的所有容器共享网络空间，包括IP地址和端口。Pod中的容器与外界通信时，必须分配共享网络资源（例如使用宿主机的端口映射）。
https://www.kubernetes.org.cn/2059.html
pod知识点 - 图8