基于K8S部署ZooKeeper准备知识（StatefulSet）

使用k8s部署zk时，会部署一个headless service.科普一下headless service:

Headless Service（无头服务）是 Kubernetes 中的一种服务类型，它与普通的 ClusterIP 服务有所不同。普通的 ClusterIP 服务会为每个服务分配一个虚拟 IP 地址，并通过负载均衡将流量转发到后端 Pod。而 Headless Service 不分配虚拟 IP，而是直接暴露 Pod 的 IP 地址，允许直接访问后端 Pod。

Headless Service 的主要特点是它不提供负载均衡和代理功能。当你使用 Headless Service 发送请求时，Kubernetes 不会进行负载均衡和流量转发，而是直接返回与服务关联的所有后端 Pod 的 IP 地址。这样，你可以在应用中直接使用这些 IP 地址进行自定义的负载均衡或直接访问特定的 Pod。

Headless Service 在以下场景中特别有用：

1. 需要对每个后端 Pod 进行直接访问，例如数据库或分布式存储系统。

2. 需要自定义负载均衡逻辑，而不是依赖 Kubernetes 提供的默认负载均衡功能。

3. 需要通过 DNS 查找所有后端 Pod 的 IP 地址。

通过定义一个 ClusterIP 为 "None" 的 Service 类型，可以创建 Headless Service。在 Service 的配置中，将 spec.clusterIP 设置为 "None" 即可。

总结：Headless Service 是 Kubernetes 中的一种服务类型，它不分配虚拟 IP，而是直接暴露后端 Pod 的 IP 地址，允许直接访问后端 Pod。它适用于需要直接访问后端 Pod、自定义负载均衡逻辑或通过 DNS 查找所有后端 Pod IP 地址的场景。

划重点：通过定义一个 ClusterIP 为 "None" 的 Service 类型，可以创建 Headless Service。在 Service 的配置中，将 spec.clusterIP 设置为 "None" 即可。

还会部署一个Cluster Service，理解了Headless Service以后，这个就容易理解了，Cluster Service跟Headless Service恰好相反，Cluster Service是可以通过虚拟IP地址经过负载均衡来访问服务对应的POD提供的服务的。

然后还会部署一个PodDisruptionBudget,科普如下：

PodDisruptionBudget（Pod 破坏预算）是 Kubernetes 中的一种资源对象，用于控制在节点维护、故障恢复或其他情况下可以同时终止的 Pod 的数量。它提供了一种机制，确保在进行节点维护或删除节点时，系统仍然具备足够的可用性和容错能力。

PodDisruptionBudget 通过定义最小可用 Pod 数量来限制 Pod 的终止数量。它指定了一个最小可用副本数，系统会确保在终止 Pod 时，剩余的可用副本数不会低于这个指定的最小值。如果终止操作会导致可用副本数低于最小可用副本数，Kubernetes 将拒绝终止 Pod，并且不会执行维护操作或节点删除。

PodDisruptionBudget 的主要特点如下：

1. 定义最小可用 Pod 数量：通过指定一个最小可用副本数，确保在终止 Pod 时系统仍然保持足够的可用性。

2. 控制 Pod 终止数量：在节点维护或其他情况下，控制可以同时终止的 Pod 的数量，避免系统过度受影响。

3. 与 Deployment、StatefulSet 等资源对象结合使用：PodDisruptionBudget 可以与其他控制 Pod 创建和调度的资源对象进行关联，以提供更精确的控制和保护。

通过定义 PodDisruptionBudget，可以为关键的应用程序或服务设置保护机制，确保在节点维护或故障恢复期间，系统仍然能够保持足够的可用性和容错能力。

总结：PodDisruptionBudget 是 Kubernetes 中的一种资源对象，用于控制在节点维护、故障恢复或其他情况下可以同时终止的 Pod 的数量。它通过定义最小可用 Pod 数量来限制 Pod 终止数量，确保系统仍然具备足够的可用性和容错能力。

最后还要部署一个StatefulSet,同样科普一下：

StatefulSet（有状态副本集）是 Kubernetes 中的一种控制器（Controller），用于管理有状态应用的部署和运行。与 Deployment 控制器相比，StatefulSet 提供了一些额外的功能和保证，以支持有状态应用的需求。

StatefulSet 的主要特点如下：

1. 稳定的唯一标识：每个 StatefulSet 中的 Pod 都有一个稳定的唯一标识符，即 Pod 名称。这使得 Pod 在重新启动、缩放或迁移时能够保持一致的标识，方便与其他系统进行交互或保持持久化存储的连接。

2. 有序部署和伸缩：StatefulSet 可以按顺序逐个部署和伸缩 Pod。每个 Pod 都有一个固定的索引，确保 Pod 在创建、删除和更新时的有序性。

3. 网络标识和稳定的网络域名：每个 Pod 都有一个稳定的网络标识，可以使用 Pod 名称直接访问。此外，每个 Pod 还会分配一个稳定的网络域名，以便其他应用程序可以直接通过域名进行访问。

4. 持久化存储卷：StatefulSet 支持与持久化存储卷（Persistent Volume）的集成，确保 Pod 在重启、迁移或缩放时可以保持其持久化数据。

5. 有序的删除：当删除 StatefulSet 时，它会按照逆序删除其中的 Pod，确保在删除过程中不会中断应用的可用性。

StatefulSet 适用于有状态应用程序，如数据库、消息队列、缓存等，这些应用程序通常需要固定的标识和稳定的网络连接，以及持久化的存储。

总结：StatefulSet 是 Kubernetes 中的一种控制器，用于管理有状态应用的部署和运行。它提供了稳定的唯一标识、有序部署和伸缩、网络标识和稳定的网络域名、持久化存储卷以及有序的删除等功能，以满足有状态应用的需求。

再细看一下StatefulSet的定义清单，同样会看一些不熟悉的名词。

affinity：

Affinity（亲和性）是 Kubernetes 中的一个概念，用于指定 Pod 与其他资源（节点、Pod）之间的关联性和互动规则。通过使用亲和性，可以对 Pod 的调度和部署进行更精确的控制，以满足特定的需求和策略。

在 Kubernetes 中，有两种类型的亲和性可供使用：

1. Node Affinity（节点亲和性）：通过指定条件和规则，将 Pod 调度到特定的节点。可以基于节点的标签（labels）或其他属性来定义亲和性规则，以确保 Pod 被调度到符合条件的节点上。

2. Pod Affinity/Pod Anti-Affinity（Pod 亲和性/反亲和性）：通过指定条件和规则，将 Pod 调度到与其他 Pod 相关的节点上或避免与其他 Pod 调度在同一节点上。可以根据其他 Pod 的标签、Pod 的命名空间（namespace）或其他属性来定义亲和性规则。

通过使用亲和性规则，可以实现一些常见的场景和策略，例如：

• 将相关的服务 Pod 调度到同一节点上，以提高网络延迟和性能。

• 将相互依赖的应用程序 Pod 调度到同一节点上，以减少跨节点通信的开销。

• 将敏感数据处理的 Pod 与其他非敏感数据处理的 Pod 隔离在不同的节点上。

亲和性规则通过使用标签选择器（label selectors）和拓扑约束（topology constraints）来定义，以满足特定的条件和策略。亲和性可以在 Pod 的配置文件中通过 affinity 字段进行定义。

总结：亲和性是 Kubernetes 中用于指定 Pod 与其他资源之间关联性和互动规则的概念。通过使用节点亲和性和 Pod 亲和性/反亲和性，可以对 Pod 的调度和部署进行更精确的控制，以满足特定的需求和策略。

topologyKey：

在 Kubernetes 中，topologyKey 是用于定义亲和性规则的一个关键字段。它用于指定 Pod 亲和性或反亲和性的拓扑约束条件。

topologyKey 的作用是与节点的拓扑信息相关联，以决定 Pod 应该被调度到哪个节点。它可以是节点的标签（label）或节点的拓扑域（例如：kubernetes.io/hostname、failure-domain.beta.kubernetes.io/zone 等）。

通过设置 topologyKey，可以根据节点的拓扑信息来约束 Pod 的调度，从而实现一些特定的策略和需求，例如：

• 将 Pod 调度到具有特定标签的节点上，以满足特定的硬件或软件要求。

• 将 Pod 调度到特定的区域（zone）或机架（rack）上，以提高容灾性和可用性。

topologyKey 可以在 Pod 的亲和性规则或反亲和性规则中进行设置。通过结合标签选择器和拓扑约束，可以更精确地定义 Pod 的调度策略。

总结：topologyKey 是用于定义亲和性规则中的一个关键字段，在 Kubernetes 中与节点的拓扑信息相关联。通过设置 topologyKey，可以根据节点的标签或拓扑域来约束 Pod 的调度，以满足特定的策略和需求。

kubernetes.io/hostname 这个topologyKey怎么理解 ？

这个topologyKey理解起来有点困难，单独列一篇出来，讲得详细一点，参考这篇《Kubernetes之Pod亲和性与反亲和性的TopologyKey》。

image: "k8s.gcr.io/kubernetes-zookeeper:1.0-3.4.10" 这个镜像与官方的zk有区别吗

k8s.gcr.io这个容器镜像仓库下载会超时，去dockerhub（https://hub.docker.com/）上搜索kubernetes-zookeeper，能找到很多，选择“docker pull tonybian/kubernetes-zookeeper”这个下载。tag成私服的镜像，并上传私服harbor，然后删除原镜像：

docker tag tonybian/kubernetes-zookeeper ${HARBOR_DOMAIN}/google_containers/kubernetes-zookeeper:1.0-3.4.10
​
docker rmi tonybian/kubernetes-zookeeper:latest
​
docker push ${HARBOR_DOMAIN}/google_containers/kubernetes-zookeeper:1.0-3.4.10

可以使用这个启动：sh -c start-zookeeper servers=3 ？这是什么命令？

sh -c zookeeper-ready

zk持久化数据使用了StatefulSet的持久化卷声明模板（volumnClaimTemplate）属性

介绍篇幅较长，单独起一篇说明，跳转《StatefulSet的volumeClaimTemplates》查看