包装材料东莞网站建设,重庆微网站制作,手机银行下载app,网上怎么找人去推广广告Kubernetes#xff08;快速#xff09;入门 Kubernetes 是一种容器编排技术#xff0c;这只是一种奇特的说法#xff0c;它可以帮助您管理和运行打包的应用程序。它基本上看起来像这样#xff1a;
库伯内特斯架构 Kubernetes 基本架构 您的应用程序#xff08;例如博客软…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 安全性的地方。
