K8s - 3 核心概念 - 3 Pod

---

K8s - 目录

---

---

一、kubernetes 核心技术-Pod

---

1. Pod 概述

• Pod 是k8s 系统中可以创建和管理的最小单元；
• Pod 是资源对象模型中由用户创建或部署的最小资源对象模型；
• Pod 是在k8s上运行容器化应用的资源对象，其他的资源对象都是用来支撑或者扩展 Pod 对象功能的，比如控制器对象是用来管控 Pod 对象的，Service或者 Ingress 资源对象是用来暴露 Pod 引用对象的，PersistentVolume 资源对象是用来为 Pod 提供存储等等；
• k8s 不会直接处理容器，而是 Pod；
• Pod 是由一个或多个 container 组成；

Pod 是 Kubernetes 的最重要概念，每一个 Pod 都有一个特殊的被称为”根容器“的 Pause 容器。Pause 容器对应的镜像属于 Kubernetes 平台的一部分，除了 Pause 容器，每个 Pod 还包含一个或多个紧密相关的用户业务容器。

Pod vs 应用

• 每个 Pod 都是应用的一个实例，有专用的 IP。

Pod vs 容器

• 一个 Pod 可以有多个容器，彼此间共享网络和存储资源；
• 每个 Pod 中有一个 Pause 容器保存所有的容器状态， 通过管理pause 容器，达到管理 pod 中所有容器的效果。

Pod vs 节点

• 同一个 Pod 中的容器总会被调度到相同 Node 节点；
• 不同节点间 Pod 的通信基于虚拟二层网络技术实现。

Pod vs Pod

• 普通的 Pod 和静态 Pod。

2. Pod 特性

2.1 资源共享

一个 Pod 里的多个容器可以共享存储和网络，可以看作一个逻辑的主机。共享的如 namespace,cgroups 或者其他的隔离资源。

多个容器共享同一 network namespace，由此在一个 Pod 里的多个容器共享 Pod 的 IP 和 端口 namespace，所以一个 Pod 内的多个容器之间可以通过 localhost 来进行通信,所需要 注意的是不同容器要注意不要有端口冲突即可。

不同的 Pod 有不同的 IP,不同 Pod 内的多 个容器之前通信，不可以使用 IPC（如果没有特殊指定的话） 通信，通常情况下使用 Pod 的 IP 进行通信。

一个 Pod 里的多个容器可以共享存储卷，这个存储卷会被定义为 Pod 的一部分，并且可 以挂载到该 Pod 里的所有容器的文件系统上。

2.2 生命周期短暂

Pod 属于生命周期比较短暂的组件，比如，当 Pod 所在节点发生故障，那么该节点上的 Pod 会被调度到其他节点，但需要注意的是，被重新调度的 Pod 是一个全新的 Pod,跟之前的 Pod 没有半毛钱关系。

2.3 平坦的网络

K8s 集群中的所有 Pod 都在同一个共享网络地址空间中，也就是说每个 Pod 都可以通过其 他 Pod 的 IP 地址来实现访问。

3. Pod 定义

4. Pod 的基本使用方法

在kubernetes 中对运行容器的要求为：

• 容器的主程序需要一直在前台运行，而不是后台运 行；
• 应用需要改造成前台运行的方式。如果我们创建的 Docker 镜像的启动命令是后台执行程序，则在 kubelet 创建包含这个容器的 pod 之 后运行完该命令，即认为 Pod 已经结束， 将立刻销毁该 Pod。如果为该 Pod 定义了 RC，则创建、销毁会陷入一个无限循环的过程中；
• Pod 可以由 1 个或多个容器组合而成。

4.1 一个容器组成的 Pod 的 yaml 示例

# 一个容器组成的 Pod
apiVersion: v1
kind: Pod
metadata:
  name: mytomcat
  labels:
    name: mytomcat
spec:
  containers:
    - name: mytomcat
      image: tomcat
      ports:
      - containerPort: 8000

4.2 多个容器组成的 Pod 的 yaml 示例

#两个紧密耦合的容器
apiVersion: v1
kind: Pod
metadata:
  name: myweb
  labels:
    name: tomcat-redis
spec:
  containers:
  - name: tomcat
    image: tomcat
    ports:
    - containerPort: 8080
  - name: redis
    image: redis
    ports:
    - containerPort: 6379

4.3 创建

kubectl create -f xxx.yaml

4.4 查看

kubectl get pod/po <Pod_name>
kubectl get pod/po <Pod_name> -o wide
kubectl describe pod/po <Pod_name>

4.5 删除

kubectl delete -f pod pod_name.yaml
kubectl delete pod --all/[pod_name]

5. Pod 的分类

Pod 有两种类型

• 普通 Pod
  • 普通 Pod 一旦被创建，就会被放入到 etcd 中存储，随后会被 Kubernetes Master 调度到某 个具体的 Node 上并进行绑定，随后该 Pod 对应的 Node 上的 kubelet 进程实例化成一组相关的 Docker 容器并启动起来。在默认情况下，当 Pod 里某个容器停止时，Kubernetes 会自动检测到这个问题并且重新启动这个 Pod 里某所有容器， 如果 Pod 所在的 Node 宕机，则会将这个 Node 上的所有 Pod 重新调度到其它节点上。
• 静态 Pod
  静态 Pod 是由 kubelet 进行管理的仅存在于特定 Node 上的 Pod,它们不能通过 API Server 进行管理，无法与 ReplicationController、Deployment 或 DaemonSet 进行关联，并且 kubelet 也无法对它们进行健康检查。

6. Pod 生命周期和重启策略

6.1 Pod 的创建过程

Pod 从创建到最后的创建成功会分别处于不同的阶段，下面是Pod的生命周期示意图，从图中可以看到Pod状态的变化：

1. 用户通过kubectl客户端提交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。

6.2 Pod 的状态

状态值	说明
Pending	API Server 已经创建了该 Pod，但 Pod 中的一个或多个容器的镜像还没有创建，包括镜像下载过程。
Running	Pod 内所有容器已创建，且至少一个容器处于运行状态、正在启动状态或正在重启状态。
Completed	Pod 内所有容器均成功执行退出，且不会再重启。
Failed	Pod 内所有容器均已退出，但至少一个容器退出失败。
Unknown	由于某种原因无法获取 Pod 状态，例如网络通信不通。
CrashLoopBackOff	容器退出，kubelet正在将它重启
InvalidImageName	无法解析镜像名称
ImageInspectError	无法校验镜像
ErrImageNeverPull	策略禁止拉取镜像
ImagePullBackOff	正在重试拉取
RegistryUnavailable	连接不到镜像中心
ErrImagePull	通用的拉取镜像出错
CreateContainerConfigError	不能创建kubelet使用的容器配置
CreateContainerError	创建容器失败
m.internalLifecycle.PreStartContainer	执行hook报错
RunContainerError	启动容器失败
PostStartHookError	执行hook报错
ContainersNotInitialized	容器没有初始化完毕
ContainersNotReady	容器没有准备完毕
ContainerCreating	容器创建中
PodInitializing：pod	pod 初始化中
DockerDaemonNotReady	docker还没有完全启动
NetworkPluginNotReady	网络插件还没有完全启动

6.3 Pod 重启策略

Pod 的重启策略包括 Always、OnFailure 和 Never，默认值是 Always。

重启策略	说明
Always	当容器失效时，有kubelet 自动重启该容器。
OnFailure	当容器终止运行且退出代码不为0时，由 kubelet 自动重启该容器。
Never	不论容器运行状态如何，kubelet 都不会重启该容器。

6.4 常见状态转换

Pod 包含的容器数	Pod 当前的状态	发生事件	Pod 的结果状态
			RestartPolicy=Always	RestartPolicy=OnFailure	RestartPolicy=Never
包含一个容器	Running	容器成功退出	Running	Succeeded	Succeeded
包含一个容器	Running	容器退出失败	Running	Running	Failed
包含两个容器	Running	1个容器成功退出	Running	Running	Running
包含两个容器	Running	容器被 OOM 杀掉	Running	Running	Failed

7. Pod 资源配置

每个 Pod 都可以对其能使用的服务器上的计算资源设置限额，Kubernetes 中可以设置限额 的计算资源有 CPU 与 Memory 两种，其中 CPU 的资源单位为 CPU 数量,是一个绝对值而非相对值。Memory 配额也是一个绝对值，它的单位是内存字节数。
Kubernetes 里，一个计算资源进行配额限定需要设定以下两个参数： Requests 该资源最小申请数量，系统必须满足要求 Limits 该资源最大允许使用的量，不能突破，当容器试图使用超过这个量的资源时，可能会被 Kubernetes Kill 并重启。

7.1 举例

apiVersion: v1
kind: Pod
metadata:
  name: myweb
  labels:
    name: db-mysql
spec:
  containers:
    - name: db
      image: mysql
      resources:
        requests:
          memory: "64Mi"
          cpu: "250m"
        limits:
          memory: "128Mi"
          cpu: "500m"

上述代码表明 MySQL 容器申请最少 0.25 个 CPU 以及 64MiB 内存，在运行过程中容器所能使 用的资源配额为 0.5 个 CPU 以及 128MiB 内存。