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

文章作者：Ana Cunha、Jose Yapur，

Developer Advocate, Amazon Web Services

文章译者：郑予彬

亚马逊云科技资深开发者布道师

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

在这篇文章中，我们将了解 Kubernetes ——一个容器的编译工具，帮你把漂浮在海上的集装箱改变成安全且舒服的家。这是 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：

  1. 请求/Requests：这是 Pod 所得到的担保。就像你订比萨，有 30 分钟送达的保证一样。这并不意味着比萨不能更快送到，它只是一个指标，意味着单个送餐人可以处理的订单数量。对于 Requests 来说，它们指定了集群中计算资源分配的保证。如果你只有一个 Pod，那么很有可能你会得到比保证更多的计算资源；

  2. 限制/Limits：这是任何 Pod 的硬性限制。如果我们指定了 limits，即使有可用资源，Pod 的消耗量也不会超过指定的 limits。同样用送货员的例子，就像告诉他们在任何情况下都不能同时配送 3 个以上的披萨。

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

  1. Mebibytes/兆字节 (MiB) 表示为 Mi：用作内存衡量值。要从 miB 转换为 MB，你需要 miB x 1.049；

  2. Millicores(mc) 表示为 m：用作 CPU 测量值。1 个 CPU 内核表示为 1000 millicores。例如，250m 是 ¼个 CPU core。

// ReplicaSet

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

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

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

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

  1. 服务名称必须始终以字母开头并使用 “-” 作为分隔符，例如：picturesocial-pictures；

  2. 对于私有负载均衡器：必须有服务注释。以下示例指定该服务仅在内部公开：

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

服务总能检测到后端的变化，因此，如果一个 Pod 离线或被一个新的 Pod 取代，服务将停止发送流量并重新路由到工作中的 Pod。这就是为什么我们强调，即使 API 仅由一个 Pod 组成，也必须使用 Services 进行同步通信，而不是直接调用 Pod。

// Images Namespace

Kubernetes 是一个多租户容器协调器。这意味着它为同时处理多个应用程序和环境的解决方案而设计。

这就是 namespace 的用武之地。Namespac 作为 Kubernetes 内部资源的逻辑分隔符，可以将资源（Pod、服务等）绑定到特定的 namespac 并设置特定的权限。例如，可以设置为 namespac A 中的 Pod 无法访问 namespac B 中的 Pod。

我建议将业务域的资源分组到一个 namespac 中，这样可以更轻松地找到所需的资源，也可以让团队在软件项目中独立维护特定的业务领域。

Kubernetes

适合托管哪种类型的应用程序

任何情况下都使用 Kubernetes 就像开着 F1 赛车去超市。虽然我希望这样做，但还是有点扯。当我选择何时使用 kubernetes 时，会使用以下标准 (当然也需要根据实际情况进行调整) ：

• 我的容器化架构由至少 10 种不同的服务组成，这些服务在同一基础架构上独立运行和扩展。

• 我的服务存在于本地网络环境中的依赖关系，并且需要流量策略和身份验证才能调用这些依赖关系。

• 我正在与不同的团队合作，维护和开发同一应用程序的不同组件。

• 我需要控制计算、网络、网络策略、滚动策略和 Orchestrator 版本控制。

• 我需要一个使用一致的工具集和部署策略从本地扩展到云的解决方案。

如果满足以上两个或更多选项，那么 Kubernetes 是一个不错的选择。

作为一篇科普类文章，这篇信息量略大，刚接触容器的开发者可能需要消化一段时间，但是我们希望帮助刚入门的开发者了解容器编译的工作原理并熟悉一些专用术语。在后续的 Picturesocial 系列文章中，我们将通过一个具体的案例演示来展开这些概念是如何应用的。

在后面的文章中，我们将一起学习如何使用 Terraform 实际创建 Amazon EKS 集群！

希望你开心工作，努力生活～

请持续关注「亚马逊云开发者」微信公众号，了解更多面向开发者的技术分享和云开发动态！

听说，点完下面4个按钮

就不会碰到bug了！