《Kubernetes知识篇：Kubernetes之Pod管理对象》

我就是我 2023-01-13 06:14 178阅读 0赞

### 文章目录 ###

*  一、Pod管理对象
 *  二、Deployment应用场景
 *  三、DaemonSet应用场景
 *  四、StatefulSet应用场景
 *  总结：整理不易，如果对你有帮助，可否点赞关注一下？

--------------------

# 一、Pod管理对象 #

**Pod管理对象主要解决Pod编排问题，常见Pod管理对象有RC、ReplicaSet、Job、DaemonSet、Deployment、StatefulSet。其中RC、ReplicaSet、Job、DaemonSet、Deployment都是面向无状态的服务，而StatefulSet面向的是有状态的服务。**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3ODE0MTEy_size_16_color_FFFFFF_t_70]

--------------------

# 二、Deployment应用场景 #

**Deployment Kubemetes vl .2 引入的新概念，引入的目的是为了更好地解 Pod的编排问题。为此， Deployment 在内部使用了Replica Set来实现目的，无论从Deployment 的作用与目的、它的 定义，还是从它的具体命令行操作来看，我们都可以把它看作 RC 的一次升级，两者的相似度超过 90%。**

**Deployment 相对于 RC 的一个最大升级是我们可以随时知道当前 Pod “部署”的进度。实际上由于一个 Pod 的创建、调度、绑定节点及在目标 Node 上启动对应的容器这完整过程需定的时间，所以我们期待系统启动Pod副本的目标状态，实际上是个连续变化的“部署过程”导致的最终状态。**

**Deployment 的典型使用场景：**  
**1、创建 Deployment 对象来生成对应的 Replica Set 井完成 Pod 副本的创建过程**  
**2、检查 Deployment 的状态来看部署动作是否完成（ Pod 副本的数量是否达到预期的值）**  
**3、更新 Deployment 以创建新的 Pod （比如镜像升级）**  
**4、如果当前 Deployment 不稳定，则回滚到 个早先的 Deployment 版本**  
**5、暂停 Deployment 以便于一次性修改多个 PodTemplateSpec 的配置项，之后再恢复**  
**6、Deployment ，进行新的发布。**  
**7、扩展 Deployment 以应对高负载。**  
**8、查看 Deployment 的状态，以此作为发布是否成功的指标。**  
**9、清理不再需要的旧版本 ReplicaSets**

--------------------

# 三、DaemonSet应用场景 #

**DaemonSet（守护进程集）和守护进程类似，它在符合匹配条件的节点上均部署一个Pod。DaemonSet确保全部（或者某些）节点上运行一个Pod副本。当有新节点加入集群时，也会为它们新增一个Pod。当节点从集群中移除时，这些Pod也会被回收，删除DaemonSet将会删除它创建的所有Pod。**

**DaemonSet的典型使用场景：**  
**1、在每个节点运行日志收集daemon，例如Fluentd、Logstash**  
**2、在每个节点运行监控daemon，比如Prometheus Node Exporter、Collectd、Datadog代理、New Relic代理或 Ganglia gmond**  
**3、运行集群存储daemon（守护进程），例如在每个节点上运行Glusterd、Ceph等**

--------------------

# 四、StatefulSet应用场景 #

**在kubernetes系统中 Pod 的管理对象RC、Deployment、 DaemonSet、Job、ReplicaSet 都是面向无态的服务。而有些服务是有状态的，如复杂的中间件集群，Mysql集群、Mongodb集群、Zookeeper集群。这些应用集群具有以下特点：**  
**1、每个节点都有固定的身份ID，通过这ID，集群中的成员可以相互发现并且通信。**  
**2、集群的规模是比较固定的，集群规模不能随意变动。**  
**3、集群里的每个节点都是有状态的，通常会持久化数据到永久存储中。**  
**4、如果磁盘损坏，则集群里的某个节点无法正常运行，集群功能受损。**

**如果用 RC/Deployment 控制 Pod 副本数的方式来实现上述有状态的集群，则我们会发现第1点是无法满足的，因为 Pod 的名字是随机产生的， Pod IP 地址也是在运行期才确定且可能有变动的，我们事先无法为每个Pod确定唯一不变的 ID 另外，为了能够在其他节点上恢复某个失败的节点，这种集群中的Pod需要挂接某种共享存储，为了解决这个问题， Kubernetesvl.4 版本开始引入了 PetSet 这个新的资源对象，并且在 vl.5 版本时更名为 StatefulSet, Statefu!Set 从本质上来说，可以看作 Deployment/RC 个特殊变种。**

**它有如下特性：**  
**1、Statefu!Set 里的每个 Pod 都有稳定、唯 的网络标识，可以用来发现 群内的其他成员。假设 StatefulSet 名字叫 kafka, ，那么第 Pod kafka-0 ，第 个叫 kafk-1 ，以此类推。**  
**2、Statefu!Set 控制的 Pod 副本的启停顺序是受控的，操作第 Pod 时，前 n-1 Pod经是运行且准备好的状态。**  
**3、StatefulSet 里的 Pod 采用稳定的持久化存储卷，通过 PV/PVC 来实现，删除 Pod 时默认不会删除与 Statefu!Set 相关的存储卷（为了保证数据的安全）。**

**StatefulSet 除了要与 PV 卷捆绑使用以存储 Pod 的状态数据，还要与 Headless Service 配合使用，即在每个 Statefu!Set 定义中要声明它属于哪个 Headless Service Headless Service 与普Service 的关键区别在于，它没有 Cluster IP ，如果解析 Headless Service 的DNS 域名，则返回的是该 Service 对应的全部 Pod 的Endpoint 列表 Statefu!Set Headless Service 的基础上又Statefu lSet 控制的每个 Pod 实例创建了 DNS 域名，这个域名的格式为：**

**( p o d n a m e ) . (podname). (podname).(headless service name)**

**比如节点的 Kafka 的StatefulSet 集群，对应的 Headless Service 的名字为 kafka,StatefulSet 的名字为 kafka，则 StatefulSet 里面的 Pod DNS 名称分别为 kafka-0.kafka，kafka-1.kafka，kafka-3 .kafka ，这些 DNS 名称可以直接在集群的配置文件中固定下来。**

--------------------

# 总结：整理不易，如果对你有帮助，可否点赞关注一下？ #

更多详细内容请参考：[企业级K8s集群运维实战][K8s]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3ODE0MTEy_size_16_color_FFFFFF_t_70]: /images/20221022/f9015e06afa54c8fbf8ea4bf3549a829.png
[K8s]: https://blog.csdn.net/m0_37814112/category_10856504.html?spm=1001.2014.3001.5482