Picturesocial | 只要 5 分钟，发现容器编排的秘密武器！

2024-02-01
北京
本文字数：3328 字
阅读完需：约 11 分钟

在上一篇文章《Picturesocial | 开发实践：如何在 15 分钟内将应用容器化》，我们讨论了容器以及容器化应用程序所需的步骤。在不考虑将 container 部署到哪里的情况下创建 container，就像把家放在漂浮在海中的货运集装箱里一样，听起来既浪漫又可怕。如果想过上安全而惬意的生活，肯定需要电、水、煤气、食物、垃圾回收…..最好再有些社交活动。

亚马逊云科技开发者社区为开发者们提供全球的开发技术资源。这里有技术文档、开发案例、技术专栏、培训视频、活动与竞赛等。帮助中国开发者对接世界最前沿技术，观点，和项目，并将中国优秀开发者或技术推荐给全球云社区。如果你还没有关注/收藏，看到这里请一定不要匆匆划过，点这里让它成为你的技术宝库！

在这篇文章中，我们将了解 Kubernete ——一个容器的编译工具，帮你把漂浮在海上的集装箱改变成安全且舒服的家。这是 Picturesocial 架构中非常重要的部分。

Picturesocial 会有多个 API，我们希望它们在维护、部署和开发等不同阶段保持彼此独立。因此，我们决定使用容器化架构。

这其实没有那么复杂，它只是意味着你正在使用容器和容器编译器。Container Orchestrator 负责处理编排所需的所有容器、容器副本、网络、存储和基础设施的组件。对于容器编排器，如今最受欢迎的就是 Kubernetes。这要归功于其活跃的社区、持续有效的技术支持和丰富的生态系统。

我们称 Kubernetes 为 k8s，它是一款开源的容器编排器，其生态系统发展迅速，且广泛。Kubernetes 不仅帮助开发者管理容器的扩展和故障处理，还帮助开发者：

服务发现和负载平衡：允许在容器和基础架构之间对网络流量进行负载平衡，以及发现容器的新副本或要移除的故障容器。
自动部署和回滚：可以选择要如何部署容器、如何处理更新以及如何防止因更新、基础设施故障或容器错误而造成的停机。
自动打包：Kubernetes 将根据设置的限制来使用、优化和调整可用的计算能力。
自我修复：如果容器出现故障，Kubernetes 将重启容器直到其正常运行，或者将其删除并创建一个新容器。

从头开始部署和运维自己的 Kubernetes 集群并非易事，需要深入了解 Kubernetes、Linux、虚拟化、网络、安全等技术。于是，亚马逊云科技为开发者提供了 Amazon Elastic Kubernetes（Amazon EKS）服务。这是一款全托管式的 Kubernetes 解决方案，降低了开发者面向基础设施和 Kubernetes 配置、管理的复杂性，同时还确保运行环境安全的安全性。安全补丁会自动应用到运行的集群中。

Manifest (aka. YAML)

开发者可以通过两种方式实现与 Kubernetes 集群进行本地通信：Kubectl（Kube Control）或调用 REST API。两种方法都使用通用的 YAML 结构向集群发送 payload。

我们称之为 manifest，它包含了详细的指令用于：

我们正在在部署什么
我们如何部署它
要暴露什么
我们如何暴露它

以下是一个示例 YAML 模板，我们可以将其用于许多容器应用程序。下面介绍 manifest 的基本概念：

Label/标签

Kubernetes 内部的所有内容都需要一个标签，这是我们识别集群内所有资源的方式，也是我们使用 Kubectl 命令或 API 请求告诉 Kubernetes 要寻找什么的方法。

Pods

Pods 是 Kubernetes 中最小的对象，也是容器存在的地方。

一个 Pod 可以有多个容器，但建议采用 1 对 1 的关系来避免高度耦合的故障点。Pod 的一些重要注意特性如：

Pod 是短暂的，这意味着如果里面的容器出现故障，最可能的结果是 Kubernetes 会删除该 Pod 并创建一个新的。当我们部署容器的新版本时，通常会创建新的 Pod，Kubernetes 将负责更新平衡服务的后端。
容器镜像必须被指定。它被定义为 repository name 和 image name，例如：[aws account id].dkr.ecr.[aws region].amazonaws.com/imageName
设置资源限制是一种最佳实践。我们有两种 boundaries：

请求/Requests：这是 Pod 所得到的担保。就像你订比萨，有 30 分钟送达的保证一样。这并不意味着比萨不能更快送到，它只是一个指标，意味着单个送餐人可以处理的订单数量。对于 Requests 来说，它们指定了集群中计算资源分配的保证。如果你只有一个 Pod，那么很有可能你会得到比保证更多的计算资源；
限制/Limits：这是任何 Pod 的硬性限制。如果我们指定了 limits，即使有可用资源，Pod 的消耗量也不会超过指定的 limits。同样用送货员的例子，就像告诉他们在任何情况下都不能同时配送 3 个以上的披萨。

我们在 Kubernetes 中常用的单位是：

Mebibytes/兆字节 (MiB) 表示为 Mi：用作内存衡量值。要从 miB 转换为 MB，你需要 miB x 1.049；
Millicores(mc) 表示为 m：用作 CPU 测量值。1 个 CPU 内核表示为 1000 millicores。例如，250m 是 ¼个 CPU core。

ReplicaSet

Pod 本应根据不同的指标（例如 CPU 或内存消耗）被复制。在我们只设置 1 个副本时，也可以设置一个如下例所示的静态值。我们称这种副本设置和自动扩展规则集称为 ReplicaSet。

Services

我们不建议开发者直接调用 Pod。如我们之前所讨论的，它们是短暂的，这意味着 Pod 名称和 IP 是动态的。

这就是 Service 的用武之地。它提供了从同一 ReplicaSet 调用一个或多个 Pod 的单一接入点。我们将重点关注两种类型的 Service:

LoadBalancer/负载均衡器：当我们需要将 ReplicaSet 暴露到 Kubernetes 集群外部时，会使用这种类型的 Service。可以是私有网络，也可以公开到互联网。就 Amazon EKS 而言，需要注意两点：

服务名称必须始终以字母开头并使用 “-” 作为分隔符，例如：picturesocial-pictures；
对于私有负载均衡器：必须有服务注释。以下示例指定该服务仅在内部公开：

clusterIP：当我们需要在 Kubernetes 集群内为使用者提供 ReplicaSet 时，会使用这种服务。这也是最常见的方法，因为如果将 Pod 保留在集群边界内，则会更安全。通过这种方式，可以为使用 Pods 添加更多的安全层，比如入口控制器、双向认证、API 网关等。我们将在以后的文章中解释更多这样的概念。