深入剖析Kubernetes之Pods的概念
在上一篇文章中了解到kubernetes的部署在逻辑上是按照Pod的概念进行的,下面来详细的了解一下pod的知识
基础概念
Pods是您可以在 Kubernetes 中创建和管理的最小的可部署计算单元。Pods是一组由一个或一个以上的容器组成的共享存储和网络资源，以及如何运行容器的规范。Pod 的内容始终位于同一地点并共同调度，并在共享上下文中运行。Pod 为特定于应用程序的“逻辑主机”建模：它包含一个或多个相对紧密耦合的应用程序容器。在非云环境中，在同一物理或虚拟机上执行的应用程序类似于在同一逻辑主机上执行的云应用程序。
Pods的官网定义,这个定义传达出三个规范:
- Pods是Kubernetes管理执行的最小单元
- Pods是容器组成,并且容器内部可以共享网络和存储
- Pods是一个逻辑概念,替kubernetes完成底层操作的还是容器三剑客’Namespace’、‘Cgroup’、‘rootFs’
Pods组成
Pods的组成可以参考这张图:
Pods除了本身的容器’ContainerA/ContainerB’以外还有一个Infra container容器，这个容器的镜像很小解压后也只有100kb~200kb大小。
-
Init容器
init容器是在用户容器启动之前-网络和数据卷初始化完成后启动
用于代理用户容器的网络和IO,其实就是Sidecar模式 -
用户容器
用户容器是’Web Server’也就是在YML中定义的容器
Pods功能
-
volume
volume数据卷其中有一种特殊的volume->‘Projected Volume’(投射数据卷)主要是用来向容器内部提供预先定义好的数据，可以划分为
- Secret
- ConfigMao
- DownwardApi
- ServiceAccountToken
这几种类型，其中Secret指的是将配置添加到kubernetes中镜像管理的数据，在通过Pods的YMAL文件的定义可以将这部分配置信息直接写入容器中，并且可以随着Kubernetes中内容的变化而变化，类似与配置中心的使用
-
异常恢复策略
Pods的异常恢复策略可以分为:
- 只要容器没有运行就进行自动重启
- 只有在容器异常时才进行chongq
- 永不自动重启容器
检查容器是否运行的方法有:
- 响应外部请求，例如http请求
- 外部检查预设的启动后的钩子方法，例如检查文件卷宗预设的文件是否存在等
实现对容器进行定期诊断的功能叫’容器探针’，由容器内部进行实现。分为三种类型
- ExecAction
- TCPSocketAction
- HTTPGetAction
容器探针又分为：
- 存活探针
存活探针指的是要确认一个容器是否真正的死亡的场景，例如重启时检测之前的失败容器是否已经死亡 - 就绪探针
就绪探针指的是区分应用是否准备就绪的场景 - 启动探针
启动探针指的是对于大型容器的启动比较慢的场景需要区分容器是否还在启动
Pods生命周期
Pod的阶段分为
| 取值 | 描述 |
|---|---|
| Pending（悬决） | Pod 已被 Kubernetes 系统接受，但有一个或者多个容器尚未创建亦未运行。此阶段包括等待 Pod 被调度的时间和通过网络下载镜像的时间， |
| Running（运行中） | Pod 已经绑定到了某个节点，Pod 中所有的容器都已被创建。至少有一个容器仍在运行，或者正处于启动或重启状态。 |
| Succeeded（成功） | Pod 中的所有容器都已成功终止，并且不会再重启。 |
| Failed（失败） | Pod 中的所有容器都已终止，并且至少有一个容器是因为失败终止。也就是说，容器以非 0 状态退出或者被系统终止。 |
| Unknown（未知） | 因为某些原因无法取得 Pod 的状态。这种情况通常是因为与 Pod 所在主机通信失败。 |
Pod的上层抽象:Service
这里先简单的介绍以下Service，kubernetes中Service是将一组Pod暴露给外界的一种方式。对外提供两种访问方式
-
VIP
通过对外提供Service的虚拟IP,然后在将请求转发到具体的Pod上。 -
DNS
- Normal Service
与VIP方式类似
- Headles Service
对于请求直接返回具体Pod的IP。类似于DNS直接解析出真实Pod的IP
