Kubernetes（快速）入门
Kubernetes 是一种容器编排技术，这只是一种奇特的说法，它可以帮助您管理和运行打包的应用程序。它基本上看起来像这样：

库伯内特斯架构
Kubernetes 基本架构
您的应用程序（例如博客软件）是在Container中构建和打包的。
容器化应用程序部署到 Kubernetes，并在Pod中运行。
部署是 Kubernetes 的一个概念，用于管理 Pod 及其属性，例如要运行的 Pod 的副本数量。
服务用于向世界公开容器端口（如果是 LoadBalancer 类型），或者至少向其邻居部署公开。换句话说，服务为在后台运行的容器创建一个 IP 地址。
Kubernetes 服务使得其他部署中的 Pod 可以访问我们的 Pod，例如，我们的博客软件可以通过各自的服务与数据库和电子邮件服务器进行通信，当然假设它们在 Kubernetes 上运行。
Kubernetes节点正在运行 Pod。默认情况下，节点上 pod 的顺序是任意的。
您可以使用亲和性和反亲和性规则来告诉 Kuberentes 如何将正在运行的 Pod 分布在节点上（例如，所有绿色 Pod 不应在同一节点上运行，以防失败）。
Kubernetes 部署不会为其 pod 维护任何状态，因为假设在下面运行的应用程序是完全无状态的。如果您确实希望应用程序在重新启动之间维护状态及其存储卷，就像我们在本例中运行数据库或 Elasticsearch 时所做的那样，您应该使用 StatefulSet，它是可以维护状态的部署：

PersistentVolume (PV) 是 Kubernetes对底层硬件提供的某个卷上的存储空间的抽象。这可以是 AWS EBS 驱动器、Google 云磁盘等。
PersistentVolumeClaim (PVC) 是 Deployment 或 StatefulSet 请求某些存储空间的一种方式。已分配的存储将在 Pod 和 Node 重新启动后继续存在。
StatefulSet只是另一种类型的 Deployment，但它能够维护 Pod 身份和 Pod 卷。
Headless Service用于 StatefulSet Pod 的发现。
现在我们已经基本解释了 Kubernetes，让我们解决最重要的问题。

Kubernetes 是 Elasticsearch 的好选择吗？
Kubernetes 最初是为运行临时工作负载而设计和构建的，这意味着无状态应用程序和各种作业。一般来说，数据库从来就不是要在 Kubernetes 和容器上运行的。请参阅此处和此处，了解有关该主题的一些值得注意的讨论。

使有状态部署发挥作用的 StatefulSet 是后来添加的，尽管它们确实有效并且工作得很好。

对我来说，我通常仍然会避免在 Kubernetes 上运行任何数据库或数据存储：

额外的抽象层会带来性能损失。
在普通虚拟机上运行数据库和数据存储可让您选择合适的大小，而不会浪费任何资源。对于 Kuberenetes，运行节点的虚拟机中总会有某些部分未被使用。
在虚拟机上运行时，调整机器和磁盘的大小要容易得多。
由于增加了抽象层，运行大型集群将更加难以管理（例如，在保持反亲和性的同时更难以停用/重新启动多个节点）。
如前所述，Kubernetes 最初并不是为有状态应用程序设计的。
基于 VM 的 Elasticsearch 集群的编排、自动化、滚动更新等可以使用 Terraform、Pulumi、Ansible 和一些其他类似工具轻松解决。
在某些情况下，在 Kubernetes 上运行 Elasticsearch 确实非常有用，我们甚至可能建议：

您正在使用 Kubernetes 来做所有事情，并且不熟悉任何其他部署方法。在这种情况下，重用现有基础设施是一个重要因素。
此外，您只需要一个非常小的集群，这可能无法证明管理其他工具或部署方法是合理的。不过，对于大型集群来说，学习和使用其他工具或方法将值得避免在 Kubernetes 上管理它的麻烦。
如果您的系统需要作为 SaaS 部署在某些公共云上，但同时需要使用相同的部署和配置为您的客户部署在本地。
对于您确实想在 Kubernetes 上运行 Elasticsearch 的情况，让我们看看如何完成。

Elasticsearch集群拓扑
使用 Elastic Stack 时，需要特别注意的部分是 Elasticsearch 本身 - 位于堆栈中间的层，用于存储数据并执行所有魔力。典型的 Elasticsearch 集群如下所示：

典型的Elasticsearch集群

典型的Elasticsearch集群
至少有2个Data节点 来保存所有数据；他们接收查询和索引请求，并完成所有繁重的工作。
正好有 3 个符合 Master 资格的节点，它们将管理集群元数据。与许多人想象的不同，主节点从不处理数据操作，只处理集群元数据操作。他们甚至从未接近过数据。
可选地，有2个或更多客户端节点，也称为协调节点。这些节点向集群数据的使用者公开并充当 HTTP 代理。如果未部署它们，数据节点也将充当协调节点，这是我们通常希望在适当大小的集群上避免的事情。
集群访问点是任何协调节点，或者可以放在它们前面的负载平衡器。

在 Kubernetes 上运行的 Elasticsearch 集群拓扑将非常相似：

在 Kubernetes 上运行的 Elasticsearch 集群拓扑

在 Kubernetes 上运行的 Elasticsearch 集群拓扑
节点布局相同；单独的客户端节点仍然是可选的。
数据节点部署为具有 PV 和 PVC 的 StatefulSet。因此，它们通过重新启动和崩溃也保留其身份和存储，这是期望的行为。
主节点可以部署为 Deployment 或 StatefulSet。部署为 StatefulSet 只会使集群恢复更快。
为每个 StatefulSet 创建一个无头服务并用于集群间发现。
客户端节点完全无状态，可以作为简单的 Kubernetes 部署进行部署。
创建 LoadBalancer Kubernetes 服务以将 HTTP 请求转发到协调节点。
您的应用程序以及 Kibana、Logstash、Beats 等工具都应配置为与 LoadBalancer 服务通信。这也是您应该通过 Kubernetes Ingress 等设置 HTTPS 安全性的地方。