Kubernetes 是一个流行的开源容器管理平台，最初由谷歌开发，它基于谷歌自己的内部博格(https://Kubernetes . io/blog/2015/04/博格-前身到 kubernetes/ )容器平台。Kubernetes 利用了谷歌在大规模运行容器方面的丰富经验，现在随着 aws 弹性 Kubernetes 服务(EKS)的发布，所有主要的云平台提供商都支持它。EKS 提供了一个托管的 Kubernetes 集群，您可以将容器应用部署到其中，而不必担心日常运营开销和集群管理的复杂性。AWS 已经完成了建立一个健壮且可扩展的平台的所有繁重工作，使其比以往任何时候都更容易与 Kubernetes 一起启动和运行。

在本章中，您将了解 Kubernetes 的世界，我们将研究如何配置 Kubernetes，以确保我们能够成功部署和操作我们通过本书使用的示例应用，然后在 AWS 中建立一个 EKS 集群，您将使用您在本地开发的配置部署应用。这将为作为应用所有者的您如何将容器工作负载部署到 Kubernetes，以及如何快速启动并运行 EKS 提供实际的见解。

我们将首先了解如何在本地使用该平台，使用 Docker for Mac 和 Docker for Windows 现在为 Kubernetes 提供的本机支持。您可以开箱即用地启动本地单节点群集，从而减少启动和运行本地环境通常需要的大量手动配置。您将学习如何创建在 Kubernetes 中运行示例应用所需的各种类型的资源，解决关键的操作挑战，例如为应用数据库提供持久存储、机密管理，以及运行一次性任务，例如数据库迁移。

一旦您建立了一个工作配置，让示例应用在 Kubernetes 本地启动并运行，我们将把注意力转向从 EKS 开始，创建一个 EKS 集群，并建立一个 EC2 自动扩展组，在该组中管理运行您的容器工作负载的工作节点。您将学习如何从本地环境设置对集群的访问，并继续部署 Kubernetes Dashboard，它提供了丰富的管理用户界面，您可以从中部署和管理应用。最后，您将设置与其他 AWS 服务的集成，包括弹性块存储(EBS)和弹性负载平衡(ELB)，并继续将示例应用部署到您的 EKS 集群。

本章将涵盖以下主题:

以下是本章的技术要求:

以下 GitHub URL 包含本章使用的代码示例:https://GitHub . com/docker-in-AWS/docker-in-AWS/tree/master/ch17。

查看以下视频，了解《行动守则》: http://bit.ly/2LyGtSY

Kubernetes 是由 Google 在 2014 年开源的开源容器管理平台，2015 年以其 1.0 版本实现量产准备。在三年的时间里，它已经成为最受欢迎的容器管理平台，并且非常受希望将其应用作为容器工作负载运行的大型组织的欢迎。Kubernetes 是 github 上最受欢迎的开源项目之一(https://GitHub . com/cncf/velocity/blob/master/docs/top30 chart creation . MD)，根据 [Redmonk])，根据 Redmonk 的数据，截至 2017 年末，Kubernetes 在财富 100 强公司中的使用率为 54%。 Kubernetes 的主要功能包括:

在前一章中，我提供了我自己对 Docker Swarm 和 Kubernetes 的想法，在这里我将继续，这一次更多地关注为什么你会选择 Kubernetes 而不是 Docker Swarm。当您完成这一章时，应该很明显，Kubernetes 有一个更复杂的体系结构，这意味着有一个更高的学习曲线，我在这一章中介绍的只是 Kubernetes 可能做到的事情的表面。也就是说，一旦你了解了这些概念，至少从我的角度来看，你应该看到 Kubernetes 最终更强大，具有更大的灵活性，可以说，Kubernetes 肯定比 Docker Swarm 感觉更“企业级”，有更多的旋钮可以根据您的特定需求定制 Kubernetes。

与 Docker Swarm 和其他竞争对手相比，Kubernetes 最大的优势可能是它的社区，这一点非常重要，这意味着在更广泛的 Kubernetes 社区和生态系统中，可以很容易地找到关于您能想到的几乎任何配置场景的信息。Kubernetes 运动的背后一直有很大的动力，而随着领先的供应商和提供商(如 AWS)用自己的产品和解决方案拥抱 Kubernetes，这种动力似乎只会越来越大。

在架构上，Kubernetes 以集群的形式组织自己，其中主节点形成集群控制平面，工作节点运行您的实际容器工作负载:

Kubernetes architecture

在每个主节点中，存在许多组件:

在所有节点上，都存在以下组件:

请注意，工作节点只运行前面直接列出的组件，而主节点运行我们到目前为止讨论过的所有组件，这允许主节点也为单节点集群等场景运行容器工作负载。 Kubernetes 还提供了一个名为 kubectl 的客户端组件，它提供了通过 Kubernetes API 管理集群的能力。 kubectl 在 Windows、macOS 和 Linux 上受支持，允许您轻松管理多个集群并在它们之间切换，既可以本地运行，也可以远程运行。

现在，您已经简单地了解了 Kubernetes，让我们专注于在您的本地环境中与 Kubernetes 一起启动和运行。

在本书的前面，当您设置本地开发环境时，如果您使用的是 macOS 或 Windows，则安装了 Docker Desktop 的社区版(CE)版本(Docker for Mac 或 Docker for Windows，在本章中我可能统称为 Docker Desktop)，其中包括对 Kubernetes 的本机支持。 If you are using a variant of Docker for Mac/Windows that does not support Kubernetes, or are using Linux, you can install minikube by following the instructions at https://github.com/kubernetes/minikube. Most of the examples included in this section should work with minikube, although features such as load balancing and dynamic host path provisioning may not be directly supported and require some additional configuration.

要启用 Kubernetes，请在本地 Docker 桌面设置中选择 Kubernetes ，并选中启用 Kubernetes 选项。单击应用后，将安装 Kubernetes，并需要几分钟时间启动和运行:

Enabling Kubernetes using Docker for Mac Docker Desktop 还会自动为您安装和配置 Kubernetes 命令行实用程序kubectl，可用于验证您的安装:

如果您将 Docker for Windows 与 Linux 子系统 for Windows 结合使用，您将需要通过运行以下命令将kubectl安装到子系统中(有关更多详细信息，请参见https://kubernetes . io/docs/tasks/tools/install-kube CTL/# install-kube CTL-binary-via-native-package-management):

安装kubectl后，如果您之前将您的 Linux 子系统主文件夹更改为您的 Windows 主文件夹，您现在应该能够与本地 Kubernetes 集群交互，而无需进一步配置。

如果您的主文件夹不同于 Windows 主文件夹(默认情况下是这样)，那么您需要设置一个指向 Windows 主文件夹中kubectl配置文件的符号链接，之后您应该能够使用kubectl与本地 Kubernetes 安装进行交互:

The Linux subsytem for Windows also allows you to run Windows command-line programs, so alternatively you can run kubectl.exe to invoke the Windows kubectl component.

在 Kubernetes 中，您将您的应用部署为 pods ，它们指的是一个或多个彼此密切相关的容器和其他资源，并共同表示您的应用。一个吊舱是 Kubernetes 的核心工作单元，在概念上类似于一个 ECS 任务定义，尽管在引擎盖下它们以完全不同的方式工作。 A common shorthand code for Kubernetes is k8s, where the “ubernete” portion of the name Kubernetes is replaced with the digit 8, representing the number of characters in “ubernete”.

在我们创建第一个 pod 之前，让我们在 todo back and 存储库中建立一个名为k8s的文件夹，该文件夹将保存 todo back and 应用的所有 Kubernetes 配置，然后创建一个名为app的文件夹，该文件夹将存储与核心 todo back and 应用相关的所有资源定义:

下面的代码演示了 todobackend 应用的基本 pod 定义，我们将把它保存到k8s/app/deployment.yaml文件中:

pod 配置文件的格式很容易理解，一般来说，如果您习惯于使用 Docker Compose 定义容器，那么您看到的大多数参数都会映射到同名的参数。一个容易引起混淆的重要区别是command参数——在 Kubernetes 中，该参数相当于 Docker Compose 服务规范中的ENTRYPOINT Dockerfile 指令和entrypoint参数，而 Kubernetes 中的args参数相当于 CMD 指令(Dockerfile)和command服务参数(Docker Compose)。这意味着在前面的配置中，我们的容器中的默认入口点脚本被绕过，取而代之的是 uwsgi web 服务器将直接运行。 IfNotPresent的imagePullPolicy属性值将 Kubernetes 配置为仅在本地 Docker Engine 注册表中没有映像的情况下拉取一个映像，这意味着在尝试创建 pod 之前，您必须确保已运行现有的 todobackend Docker Compose 工作流来本地构建和标记 todo back and 映像。这是必需的，因为当您在 AWS EC2 实例上运行 Kubernetes 时，Kubernetes 仅包括对 ECR 的本机支持，而当您在 AWS 之外运行 Kubernetes 时，Kubernetes 不支持 ECR。 There are a number of third-party plugins available that allow you to manage AWS credentials and pull ECR images. A popular example can be found at https://github.com/upmc-enterprises/registry-creds

要创建我们的 pod 并验证它是否正在运行，您可以运行kubectl apply命令，其中-f标志引用您刚刚创建的部署文件，后跟kubectl get pods命令:

您可以看到 pod 的状态是Running，并且一个容器已经被部署到在您的本地 Docker Desktop 环境中运行的单节点 Kubernetes 集群中。需要注意的一点是，已经部署的 todobackend 容器没有与外部世界通信的手段，因为没有从 pod 及其关联容器发布的网络端口。 Kubernetes 的一个有趣的方面是，您可以使用 Kubernetes API 与您的豆荚进行交互。为了演示这一点，首先运行kubectl proxy命令，该命令设置一个本地 HTTP 代理，该代理通过一个普通的旧 HTTP 接口公开 API:

现在，您可以通过网址http://localhost:8001/api/v1/namespaces/default/pods/todobackend:8000/proxy/访问吊舱上的容器端口 8000:

Running the kubectl proxy

如您所见，todobackend 应用正在运行，尽管它缺少静态内容，因为我们还没有生成它。还要注意，页面底部的 todos 链接(http://localhost:8001/todos)是无效的，因为 todobackend 应用不知道通过代理访问应用所调用的 API 路径。 Kubernetes 的另一个有趣的特性是能够通过运行kubectl port-forward命令将 Kubernetes 客户端的端口公开给应用，该命令在客户端发布一个本地端口，并使用 Kubernetes API 将其连接到指定的 pod:

如果您现在尝试访问http://localhost:8000，您应该会看到 todosbackend 主页，并且页面底部的 todo 链接现在应该可以访问:

Accessing a port forwarded pod

您可以再次看到，我们的应用没有处于完全正常的状态，因为我们还没有配置任何数据库设置。

虽然我们已经能够发布我们的 todobackend 应用，但是我们用来发布的机制并不适合现实世界的生产使用，只对有限的本地开发场景真正有用。

在现实世界中运行我们的应用的一个关键要求是能够增加或减少应用容器的实例或副本的数量。为了实现这一点，Kubernetes 支持一类称为控制器的资源，它们负责协调、组织和管理给定 pod 的多个副本。一种流行的控制器类型是部署资源，顾名思义，它包括支持创建和更新新版本的 pods，以及滚动升级和支持部署失败时的回滚等功能。

以下示例演示了更新todobackend存储库中的k8s/app/deployment.yaml文件以定义部署资源:

我们将之前的 pod 资源更新为现在的部署资源，顶层spec属性(即spec.template)的template属性内联定义了应该部署的 pod。部署和 Kubernetes 的一个关键概念通常是使用基于集合的标签选择器匹配(https://Kubernetes . io/docs/concepts/overview/work-with-objects/labels/# label-selectors)来确定部署适用的资源或 pods。在前面的示例中，部署资源spec指定了两个replicas，并使用selectors.matchLabels将部署匹配到包含标签app和值todobackend的 pod。这是一个简单而强大的范例，允许您以灵活且松散耦合的方式创建自己的结构和资源之间的关系。请注意，我们还向容器定义中添加了readinessProbe和livenessProbe属性，它们分别创建了就绪探测和活动探测。就绪探测器定义了 Kubernetes 应该执行的操作，以确定容器是否就绪，而活跃度探测器用于确定容器是否仍然健康。在前面的示例中，就绪探测器使用对端口 8000 的 HTTP GET 请求来确定部署控制器何时应该允许将连接转发到容器，而活跃度探测器用于在容器不再响应活跃度探测器的情况下重新启动容器。请参考https://kubernetes . io/docs/tasks/configure-pod-container/configure-liveness-ready-probes/了解不同类型的探针及其使用方法的更多信息。

要创建新的部署资源，我们可以首先移除现有的 pod，然后使用kubectl在todobackend存储库中应用k8s/app/deployment.yaml文件:

创建部署后，您可以看到配置数量的副本以两个单元的形式部署，每个单元都有一个唯一的名称。一旦您配置的就绪探测器成功，每个吊舱的状态将转换为就绪。

此时，我们已经为应用定义了一个 pod，并使用一个部署资源部署了应用的多个副本，现在我们需要确保外部客户端可以连接到我们的应用。假设我们的应用有多个副本在运行，我们需要一个能够提供稳定的服务端点、跟踪每个副本的位置并在所有副本之间负载平衡传入连接的组件。 服务是提供此类功能的 Kubernetes 资源，其中每个服务都被分配了一个虚拟 IP 地址，该地址可用于访问给定的一组 pod，并且基于 iptables 规则，到虚拟 IP 地址的传入连接被负载平衡到每个 pod 副本，iptables 规则通过称为 kube-proxy 的标准 Kubernetes 系统资源进行管理和更新:

Services and endpoints in Kubernetes

在上图中，一个客户端 pod 正试图使用端口80 ( 10.1.1.1:80)上的虚拟 IP 地址10.1.1.1与应用 pod 通信。请注意，服务虚拟 IP 地址是在集群中的每个节点上发布的，其中 kube-proxy 组件负责更新 iptables 规则，该规则选择客户端连接应该以循环方式路由到的适当端点。因为虚拟 IP 地址发布在集群中的每个节点上，所以任何节点上的任何客户端都可以与服务通信，并且流量以均匀的方式分布在集群中。

现在，您已经对服务的工作原理有了较高的理解，让我们在位于todobackend存储库中的k8s/app/deployment.yaml文件中定义一个新的服务:

请注意，您可以在单个 YAML 文件中定义多个资源，方法是使用---分隔符分隔每个资源，并且我们可以创建一个名为 todobackend 的服务，该服务使用标签匹配将服务绑定到标签为app=todobackend的任何 pods。在spec.ports部分，我们将端口 80 配置为服务的传入或监听端口，这将对每个 pod 上的 8000 个targetPort连接进行负载平衡。

有了我们服务的定义，您现在可以使用kubectl apply命令部署服务:

您可以使用kubectl get svc命令查看当前服务，并注意到每个服务都包括一个唯一的集群 IP 地址，这是集群中其他资源可以用来与服务相关联的 pod 通信的虚拟 IP 地址。kubectl get endpoints命令显示了与每个服务相关联的实际端点，您可以看到到10.103.210.17:80的todobackend服务虚拟 IP 地址的连接将被负载平衡到10.1.0.27:8000和10.1.0.30:8000。

每个服务也以..svc.cluster.local的形式分配一个唯一的 DNS 名称。Kubernetes 中的默认命名空间被称为default，因此对于我们的 todobackend 应用，它将被分配一个名称todobackend.default.svc.cluster.local，您可以使用kubectl run命令验证该名称在集群中是否可达:

在前面的例子中，您可以简单地查询 todo backnd，因为 Kubernetes 将 DNS 搜索域发送到.svc.cluster.local(在我们的用例中为default.svc.cluster.local)，您可以看到这解析为 todo backnd 服务的集群 IP 地址。

需要注意的是，集群 IP 地址只能在 Kubernetes 集群内访问，如果没有进一步的配置，我们无法从外部访问该服务。

为了允许外部客户端和系统与 Kubernetes 服务进行通信，您必须向外界公开该服务。在真正的 Kubernetes 风格中，有多种选项可以实现这一点，这些选项由 Kubernetes ServiceTypes控制:

向外部发布服务的最常见方法是使用负载平衡器方法，如下图所示:

Load balancing in Kubernetes

外部负载平衡器发布客户端将连接到的外部服务端点，在前面的示例中是192.0.2.43:80。负载平衡器服务端点将与群集中具有与服务相关联的活动 pod 的节点相关联，每个节点都有一个通过 kube-proxy 组件设置的节点端口映射。然后，节点端口映射被映射到节点上的每个本地端点，从而允许流量在整个集群中高效且均匀地进行负载平衡。 For communications from internal clients within the cluster, communications still take place using the service cluster IP address, as described earlier in this chapter.

在本章的后面，我们将看到如何将 AWS 负载平衡器与 EKS 集成，但是目前您的本地 Docker Desktop 环境包括对其自己的负载平衡器资源的支持，该资源在您的主机上为您的服务发布一个外部端点。向服务添加外部负载平衡器非常简单，如下例所示，我们在 todobackend 存储库中修改k8s/app/deployments.yaml文件的配置:

为您的环境部署合适的负载平衡器所需要的只是将spec.type属性设置为LoadBalancer，Kubernetes 将自动创建一个外部负载平衡器。您可以通过应用更新的配置并运行kubectl get svc命令来测试这一点:

请注意，kubectl get svc输出现在显示 todobackend 服务的外部 IP 地址是 localhost (localhost 总是您的 Docker 客户端在使用 Docker Desktop 时可以到达的外部接口)，并且它是在端口 80 上向外发布的，您可以通过运行curl localhost命令来验证它是否为真。外部端口映射到单节点集群上的端口 31417，这是 kube-proxy 组件监听的端口，以便支持我们前面描述的负载平衡器体系结构。

现在，我们已经了解了如何在 Kubernetes 集群内部以及向外部发布我们的应用，我们可以通过添加对 todo back and 应用的各种部署活动和依赖关系的支持，专注于使 todo back and 应用完全正常运行。

我们将首先解决为 todo back and 应用提供静态内容的问题——正如您在前面几章中所知道的，我们需要运行一个 collectstatic 任务，以确保静态内容可用于todo back and应用，并且这应该在部署todo back and应用的任何时候运行。 collectstatic 任务需要将静态内容写入一个卷，然后由主应用容器装载，因此让我们讨论如何将卷添加到 Kubernetes pods 中。 Kubernetes 有一个强大的存储子系统，支持多种卷类型，您可以在https://kubernetes . io/docs/concepts/storage/volumes/# type-of-volumes上了解更多。对于 collectstatic 用例来说， emptyDir 卷类型是合适的，它是一个遵循每个 pod 生命周期的卷——它是随 pod 动态创建和销毁的——因此它适合作为一个临时存储类型用于缓存和提供静态内容等用例，这些静态内容可以在 pod 创建时轻松地重新生成。

以下示例演示了如何向k8s/app/deployment.yaml文件添加公共emptyDir卷:

我们在 pod 模板的spec.Volumes属性中定义一个名为public的卷，然后使用 todobackend 容器定义中的volumeMounts属性将public卷挂载到/public。我们用例的一个重要配置要求是设置spec.securityContext.fsGroup属性，该属性定义了组标识，该组标识将被配置为 pod 中任何文件系统挂载的组所有者。我们将该值设置为1000；回想一下前面几章，todobackend 映像作为app用户运行，该用户/组 ID 为 1000。该配置确保 todobackend 容器能够读写静态内容到public卷。

如果您现在部署您的配置更改，您应该能够使用kubectl exec命令检查 todobackend 容器文件系统，并验证我们可以读写/public挂载:

kubectl exec命令类似于docker exec命令，因为它允许您在当前运行的 pod 容器内执行命令。这个命令必须引用 pod 的名称，我们使用kubectl get pods命令和一个 JSON 路径查询来提取这个名称。如您所见，至容器内的app用户能够读写/public底座。

有了用于静态内容的临时卷，我们现在可以专注于调度收集静态任务来为我们的应用生成静态内容。Kubernetes 支持初始化容器，这是 pod 中的一种特殊类型的容器，在主应用容器启动之前执行。Kubernetes 将确保您的 init 容器运行到完成，并在启动应用之前成功完成，如果您指定多个 init 容器，Kubernetes 将按顺序逐一执行它们，直到所有 init 容器都完成。

下面的代码演示了向k8s/app/deployment.yaml文件添加一个初始化容器:

现在，您可以部署您的更改，并使用kubectl logs命令验证 collectstatic init 容器是否成功执行:

如果您现在在浏览器中浏览到http://localhost，您应该能够验证静态内容现在是否正确呈现:

The todobackend application with correct static content

让至应用完全运行的下一步是添加一个数据库服务，该服务将托管至应用数据库。我们将在我们的 Kubernetes 集群中运行这个服务，但是在 AWS 的实际生产用例中，我通常建议使用关系数据库服务(RDS)。

定义数据库服务需要两个主要的配置任务:

我们的数据库服务的一个关键需求是持久存储，对于我们的单节点本地 Kubernetes 开发环境来说， hostPath 卷类型代表了提供简单持久存储需求的标准选项。

虽然您可以通过直接在卷定义中指定路径来非常容易地创建一个 hostPath 卷(参见位于https://kubernetes . io/docs/concepts/storage/volumes/# hostPath的示例 pod 定义)，但是这种方法的一个问题是，它会对底层卷类型产生硬依赖，并且如果您想要删除 pod 和与卷相关联的数据，还需要手动清理。 Docker Desktop Kubernetes 支持的一个非常有用的特性是包含一个名为docker.io/hostpath的动态卷供应器，它会自动为您创建类型为 hostPath 的卷，该卷可通过默认的存储类获得，您可以通过运行kubectl get sc命令来查看:

存储类提供了对底层卷类型的抽象，这意味着您的 pods 可以从特定类请求存储。这包括一般要求，如卷大小，而不需要担心底层卷类型。在 Docker Desktop 的情况下，默认存储类是开箱即用的，它使用 hostPath 卷类型来提供存储请求。

但是，稍后当我们使用 EKS 在 AWS 中设置 Kubernetes 集群时，我们将配置一个默认存储类，该类使用 AWS 弹性块存储(EBS)作为底层卷类型。采用这种方法意味着我们不需要更改 pod 定义，因为我们将在每个环境中引用相同的存储类。 If you are using minikube, a dynamic provisioner called k8s.io/minikube-hostpath provides similar functionality to the Docker hostpath provisioner, but mounts volumes under /tmp/hostpath-provisioner.

要使用存储类，而不是直接用 pod 定义指定卷类型，您需要创建一个持久卷声明，它提供了卷大小和访问模式等存储要求的逻辑定义。让我们定义一个持久的卷声明，但是在此之前，我们需要在 todobackend 存储库中建立一个名为k8s/db的新文件夹，它将存储我们的数据库服务配置:

在这个文件夹中，我们将创建一个名为k8s/db/storage.yaml的文件，其中我们将定义一个持久卷声明:

我们在一个专用文件中创建索赔(称为todobackend-data)，因为这将允许我们独立管理索赔的生命周期。上例中没有包括的一个属性是spec.storageClassName属性——如果省略该属性，将使用默认存储类，但是请记住，您可以创建和引用自己的存储类。spec.accessModes属性指定了应该如何装载存储–对于 AWS 中的本地存储和 EBS 存储，我们一次只需要一个容器就可以读写卷，这包含在ReadWriteOnce访问模式中。 spec.resources.requests.storage属性指定持久卷的大小，在本例中，我们将其配置为 8 GB。 If you are using Docker for Windows, you will be prompted to share your C:\ with Docker the first time you attempt to use the Docker hostPath provisioner.

如果您现在使用kubectl部署持久卷声明，您可以使用kubectl get pvc命令查看您新创建的声明:

您可以看到，当您创建持久卷声明时，会动态创建一个持久卷。使用 Docker Desktop 时，这实际上是在路径~/.docker/Volumes//中创建的:

如果您使用的是 Windows Docker，而您使用的是 Linux 的 Windows 子系统，您可以创建一个指向 Windows 主机上.docker文件夹的符号链接:

请注意，如果您按照[第 1 章] 01.html

现在我们已经创建了一个持久的卷声明，我们可以定义数据库服务了。我们将在todobackend存储库中一个名为k8s/db/deployment.yaml的新文件中定义数据库服务，在这里我们创建一个服务和部署定义:

我们首先定义一个名为todobackend-db的服务，发布默认的 MySQL TCP 端口3306。请注意，我们指定了None的spec.clusterIP值，这将创建一个无头服务。无头服务对于单实例服务很有用，它允许 pod 的 IP 地址用作服务端点，而不是使用带有虚拟 IP 地址的 kube-proxy 组件，该组件只能对单个端点进行负载平衡。定义一个无头服务仍然会为该服务发布一个 DNS 记录，但是会将该记录与 pod IP 地址相关联，确保todo back 和应用可以通过名称连接到todobackend-db服务。然后，我们为todobackend-db服务创建一个部署，并定义一个名为data的卷，该卷映射到我们之前创建的持久卷声明，并装载到 MySQL 容器中的数据库数据目录(/var/lib/mysql)中。请注意，我们指定了args属性(相当于 Docker/Docker Compose 中的 CMD/command 指令)，该属性配置 MySQL 忽略lost+found目录(如果存在的话)。虽然这在使用 Docker Desktop 时不会成为问题，但在 AWS 中会成为问题，原因与前面 Docker Swarm 一章中讨论的相同。最后，我们创建一个类型为exec的活动探测器，它执行mysqlshow命令来检查到 MySQL 数据库的连接是否可以在 MySQL 容器中本地建立。因为 MySQL 机密位于一个文件中，所以我们将 MySQL 命令包装在一个 shell 进程中(/bin/sh)，这允许我们使用$(cat /tmp/secrets/MYSQL_PASSWORD)命令替换。 Kubernetes allows you resolve environment variables at execution time by using the syntax $(). For example, the $(MYSQL_USER) value included in the preceding liveness probe will be resolved to the environment variable MYSQL_USER when the probe is executed. See https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#use-environment-variables-to-define-arguments for more details.

如果您现在部署数据库服务和部署资源，您可以使用kubectl get svc和kubectl get endpoints命令来验证您的无头服务配置:

请注意，todobackend-db服务部署的集群 IP 为 none，这意味着服务的发布端点是todobackend-db pod 的 IP 地址。

您还可以通过在本地主机上的~/.docker/Volumes/todobackend-data中列出物理卷目录的内容来验证数据卷是否已正确创建:

如果您现在只删除数据库服务和部署，您应该能够验证持久卷没有被删除并保持不变，这意味着您可以重新创建数据库服务并重新连接到data卷而不会丢失数据:

前面的代码是一个很好的例子，说明了为什么我们将持久卷声明分离到自己的文件中——这样做意味着我们可以轻松管理数据库服务的生命周期，而不会丢失任何数据。如果您确实想要销毁数据库服务及其数据，您可以选择删除永久卷声明，在这种情况下，Docker Desktop hostPath 置备程序将自动删除永久卷和任何存储的数据。 Kubernetes also supports a controller called a StatefulSet, which is specifically designed for stateful applications such as databases. You can read more about StatefulSets at https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/.

Kubernetes 支持 secret 对象，该对象允许密码或令牌等敏感数据以加密格式安全存储，然后根据需要私下暴露给您的容器。Kubernetes 机密以键/值映射或字典格式存储，这与 Docker 机密不同，正如您在上一章中看到的，Docker 机密通常只存储机密值。

您可以使用文字值手动创建机密，或者将机密值包含在文件中并应用该文件。我建议使用文字值创建您的机密，以避免将您的机密存储在配置文件中，这些文件可能会被无意中提交并推送到您的源代码存储库:

在前面的示例中，您使用kubectl create secret generic命令创建了一个名为todobackend-secret的机密，该机密存储了三个机密值。请注意，每个值都存储有一个与预期环境变量同名的键，这将使这些值的配置易于使用。

现在创建了机密，您可以配置todobackend和db部署来使用机密。Kubernetes 包含一种称为 secret 的特殊卷类型，允许您将机密安装在容器中的可配置位置，然后您的应用可以安全地私下读取这些机密。

让我们首先更新在k8s/db/deployment.yaml文件中定义的数据库部署资源，以使用todobackend-secret:

您首先创建一个名为secrets的卷，其类型为secret，引用了我们之前创建的todobackend-secret。默认情况下，所有机密项目都可用，但是您可以通过可选的items属性控制哪些项目发布到卷中。因为todobackend-secret包含了特定于 todobackend 应用的SECRET_KEY机密，所以我们配置items列表以排除该项目，并且只显示MYSQL_PASSWORD和MYSQL_ROOT_PASSWORD键。请注意，指定的path是必需的，并表示为基于机密卷在每个容器中的安装位置的相对路径。

然后将secrets卷以只读方式装载到db容器中的/tmp/secrets中，并更新与密码相关的环境变量以引用机密文件，而不是直接使用环境中的值。请注意，每个机密值都将在一个文件中创建，该文件是根据装载机密卷的文件夹中的密钥命名的。

要部署我们的新配置，您首先需要删除数据库服务及其关联的持久卷，因为这包括以前的凭据，然后重新部署数据库服务。当您执行删除和应用操作时，通过引用整个k8s/db目录，您可以非常容易地做到这一点，而不是单独指定每个文件:

一旦您重新创建了db服务，您就可以使用kubectl exec命令来验证MYSQL_PASSWORD和MYSQL_ROOT_PASSWORD机密项目是否已写入/tmp/secrets:

我们现在需要通过修改k8s/app/deployment.yaml文件来更新 todobackend 服务以消耗我们的机密:

您必须定义secrets体积，并确保只有MYSQL_PASSWORD和SECRET_KEY项目暴露在至容器中。在中以只读方式装载卷以装入应用容器后，必须使用secrets装载路径配置SECRETS_ROOT环境变量。回想一下，在上一章中，我们增加了对至应用消费 Docker 机密的支持，默认情况下，Docker 机密位于/run/secrets。然而，由于/run是一个特殊的 tmpfs 文件系统，您不能在这个位置使用常规文件系统挂载来挂载您的机密，因此我们需要配置SECRETS_ROOT环境变量，它重新配置应用将查看的机密位置。我们还必须配置MYSQL_HOST和MYSQL_USER环境变量，以便随着MYSQL_PASSWORD的机密一起，到应用具有连接到数据库服务所需的信息。

如果您现在部署更改，您应该能够验证正确的机密项目是否安装在至容器中:

如果您浏览到http://localhost/todos，您应该会收到一个错误，指示数据库表不存在，这意味着应用现在已经成功连接并验证到数据库，但是缺少应用所需的模式和表。

我们的todo back and应用几乎完全正常运行，但是我们需要执行一个关键的部署任务，那就是运行数据库迁移，以确保在todo back and数据库中存在正确的模式和表。正如您在本书中所看到的，数据库迁移应该在每次部署中只执行一次，而不管我们的应用运行了多少个实例。Kubernetes 通过一个特殊类型的控制器作业来支持这种性质的任务，顾名思义，它运行一个任务或进程(以 pod 的形式)，直到作业成功完成。

要为所需的数据库迁移任务创建作业，我们将在todobackend存储库中创建一个名为k8s/app/migrations.yaml的新文件，它允许您独立于位于同一位置的deployment.yaml文件中定义的其他应用资源运行作业:

您必须指定一种Job来将此资源配置为作业，并且在大多数情况下，该配置与我们之前创建的 pod/部署模板非常相似，除了spec.backoffLimit属性和模板spec.restartPolicy属性，前者定义了如果作业失败，Kubernetes 应尝试重新运行作业的次数，后者应始终设置为Never用于作业。

如果现在运行作业，您应该验证数据库迁移是否成功运行:

此时，您已经成功地将 todo back and 应用部署到了完全正常的状态，您应该能够连接到 todo back and 应用并创建、更新和删除 todo 项。

现在，您已经对 Kubernetes 有了坚实的了解，并且已经定义了在本地部署和运行 todobackend 应用所需的核心资源，现在是时候将我们的注意力转移到弹性 Kubernetes 服务(EKS)上了。 EKS 支持的核心资源是 EKS 集群，它代表了一个完全管理的、高可用性的 Kubernetes 管理器集群，为您管理 Kubernetes 控制平面。在本节中，我们将重点关注在 AWS 中创建 EKS 集群，建立对集群的认证和访问，以及部署 Kubernetes 仪表板。

创建 EKS 集群包括以下主要任务:

要管理您的 EKS 集群，您必须安装kubectl以及用于 Kubernetes 组件的 AWS IAM 认证器，该认证器允许kubectl使用您的 IAM 凭证向您的 EKS 集群进行认证。

您已经安装了kubectl，所以要为 Kubernetes 安装 AWS IAM 认证器，您需要安装一个名为aws-iam-authenticator的二进制文件，该文件由 AWS 发布，如下所示:

在创建 EKS 群集之前，您需要确保您的 AWS 帐户满足以下先决条件:

该模板需要两个输入参数——目标 VPC 标识和目标子网标识。EksServiceRole资源创建一个 IAM 角色，该角色授予eks.awsamazon.com服务代表您管理 EKS 集群的能力，如ManagedPolicyArns属性中引用的托管策略所指定的。然后，您必须为控制平面通信定义一个空的安全组，最后定义 EKS 集群资源，引用RoleArn属性的EksServiceRole资源，并定义一个以输入ApplicationSubnets为目标并使用EksClusterSecurityGroup资源的 VPC 配置。

现在，您可以使用aws cloudformation deploy命令部署该模板，如下所示:

创建群集大约需要 10 分钟，创建后，您可以使用 AWS CLI 获得有关群集的更多信息:

本章后面的内容都需要群集端点和证书颁发机构数据，因此请注意这些值。

创建 EKS 集群后，现在需要将新集群添加到本地kubectl配置中。默认情况下，kubectl知道的所有集群都被定义在一个名为~/.kube/config的文件中，如果你使用的是 Mac 的 Docker 或 Windows 的 Docker，这个文件目前将包含一个名为docker-for-desktop-cluster的集群。

以下代码演示了如何将您的 EKS 集群和相关配置添加到~/.kube/config文件中:

您必须首先向clusters属性添加一个名为eks-cluster的新集群，指定您之前在创建 EKS 集群后捕获的证书颁发机构数据和服务器端点。然后，您必须添加名为eks的上下文，这将允许您在本地 Kubernetes 服务器和您的 EKS 集群之间进行切换，最后，向用户部分添加名为aws的新用户，该用户部分由eks上下文用来向您的 EKS 集群进行认证。aws用户配置将 kubectl 配置为执行您之前安装的aws-iam-authenticator组件，传递参数token -i eks-cluster并使用您的本地docker-in-aws配置文件来验证访问。执行此命令将自动向kubectl返回一个认证令牌，该令牌可用于向您的 EKS 集群进行认证。

有了前面的配置，您现在应该能够访问名为eks的新上下文，并验证与 EKS 群集的连接，如下所示:

请注意，如果您正在使用我们在前面章节中设置的多因素认证 ( MFA )配置，每次您对您的 EKS 集群运行kubectl命令时，都会提示您输入一个 MFA 令牌，这将很快变得令人厌烦。

要暂时禁用多功能事务机，您可以使用aws iam remove-user-from-group命令从用户组中删除您的用户帐户:

然后在~/.aws/config文件中为您的本地 AWS 配置文件注释mfa_serial行:

设置 EKS 的下一步是创建将加入您的 EKS 集群的工作节点。与完全由 AWS 管理的 Kubernetes 主节点不同，您负责创建和管理您的工作节点。AWS 提供了一个 EKS 优化的 AMI，包括加入 EKS 集群和作为 EKS 工人操作所需的所有软件。您可以浏览https://docs . AWS . Amazon . com/eks/latest/user guide/eks-optimized-AMI . html获取您所在地区的最新 AMI ID:

Amazon EKS-Optimized AMI

在撰写本书时，EKS 优化的 AMI 需要使用我们在前面章节中了解到的 cfn-init 框架进行大量配置。创建工作节点的推荐方法是使用由 AWS 发布的预定义 CloudFormation 模板，该模板已经包含了在https://docs . AWS . Amazon . com/eks/latest/user guide/launch-workers . html中指定的所需配置:

Worker CloudFormation template URL

现在，您可以通过在 AWS 控制台中选择服务 | 云信息，单击创建栈按钮，并粘贴您之前在选择模板部分中获得的工作者模板 URL，为您的工作者节点创建一个新的云信息栈:

Creating a worker node CloudFormation stack

点击下一步后，系统会提示您输入栈名称(您可以指定一个eks-cluster-workers或类似的名称)，并提供以下参数:

配置好所需的各种参数后，单击下一步按钮两次，最后确认云信息可以创建 IAM 资源，然后单击创建按钮部署您的工作节点。成功创建栈后，打开栈的输出选项卡，记下NodeInstanceRole输出，这是下一个配置步骤所需的:

Obtaining the NodeInstanceRole output

成功部署云信息栈后，您的工作节点将尝试加入您的集群，但是在他们加入之前，您需要通过将名为aws-auth的 AWS 认证器ConfigMap资源应用于您的集群来授予对工作节点的 EC2 实例角色的访问权限。 A ConfigMap is simply a key/value data structure used to store configuration data that can be used by different resources in your cluster. The aws-auth ConfigMap is used by EKS to grant AWS users the ability to interact with your cluster, which you can read more about at https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html. You can also download a sample aws-auth ConfigMap from https://amazon-eks.s3-us-west-2.amazonaws.com/1.10.3/2018-06-05/aws-auth-cm.yaml.

要创建aws-auth配置图，在todobackend-aws/eks文件夹中创建一个名为aws-auth-cm.yaml的文件:

在前面的示例中，您需要粘贴在创建 workers CloudFormation 栈时获得的NodeInstanceRole输出的值。创建此文件后，您现在可以使用kubectl apply命令将其应用到您的 EKS 集群，然后通过运行kubectl get nodes --watch等待您的工作节点加入集群:

一旦您的所有工作人员的状态为Ready，您就已经成功地将您的工作人员节点加入到您的 EKS 集群中。

设置 EKS 集群的最后一步是将 Kubernetes 仪表板部署到集群中。Kubernetes 仪表板是一个强大而全面的基于网络的管理界面，用于管理和监控您的集群和容器应用，并作为基于容器的应用部署在 Kubernetes 集群的kube-system命名空间内。仪表板由许多组件组成，我在此不再赘述，但您可以在https://github.com/kubernetes/dashboard了解更多关于仪表板的信息。

为了部署仪表板，我们将首先创建一个名为todobackend-aws/eks/dashboard的文件夹，并继续下载和应用组成仪表板的各种组件到该文件夹:

然后，您需要创建一个名为eks-admin.yaml的文件，该文件创建具有完全集群管理员权限的服务帐户和集群角色绑定:

创建此文件后，您需要将其应用于您的 EKS 集群:

有了eks-admin服务帐户，您可以通过运行以下命令来检索该帐户的认证令牌:

前面示例中的关键信息是令牌值，当您连接到仪表板时，需要复制并粘贴令牌值。要连接到仪表板，您需要启动 kubectl 代理，该代理提供对 Kubernetes API 的 HTTP 访问:

如果您现在浏览至http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/，系统将提示您登录仪表板，您需要在其中粘贴之前为eks-admin服务帐户检索到的令牌:

Signing in to the Kubernetes dashboard

登录后，如果您将命名空间更改为 kube-system 并选择工作负载 | 部署，您可能会看到一个错误，指示无法找到监控-influxdb 部署的映像:

Kubernetes dashboard deployment failure

如果是这种情况，您需要更新之前下载的todobackend-aws/eks/dashboard/influxdb.yml文件以引用k8s.gcr.io/heapster-influxdb-amd64:v1.3.3(这是一个已知问题(https://github.com/kubernetes/heapster/issues/2059))，在您阅读本章时可能存在也可能不存在):

如果您现在通过运行kubectl apply -f influxdb.yml重新应用文件，仪表板现在应该显示所有服务按预期运行。

现在，我们的 EKS 集群和工作节点已经就位，并且我们已经确认可以部署到该集群，现在是时候将 todobackend 应用部署到 EKS 了。当您在 Kubernetes 中定义在本地运行应用所需的各种资源时，您已经完成了大部分艰苦的工作，所需要做的就是调整一些外部资源，例如负载平衡器和数据库服务的持久卷，以使用 AWS 本机服务。

现在，您需要执行以下配置任务:

在本章的前面，我们讨论了持久卷声明和存储类的概念，它们允许您从应用中抽象出存储基础架构的细节。我们了解到，在使用 Docker Desktop 时，提供了一个默认存储类，该类将自动创建 hostPath 类型的持久卷，这些卷可在~/.docker/Volumes从您的本地操作系统访问，这使得在将 Docker Desktop 与 Kubernetes 一起使用时，可以轻松调配、管理和维护持久卷。

使用 EKS 时，需要了解的是，与 Docker Desktop 不同，默认情况下，不会为您创建任何存储类。如果要支持持久卷声明，这要求您至少创建一个存储类，在大多数使用情况下，您通常会定义一个默认存储类，为集群提供标准的默认存储介质和卷类型。当使用 EKS 时，这些存储类的一个很好的候选是弹性块存储(EBS)，它提供了一个标准的集成机制来支持在集群中作为工作节点运行的 EC2 实例的基于块的卷存储。Kubernetes 支持名为AWSElasticBlockStore的卷类型，允许您从工作节点访问和装载 EBS 卷，还支持名为aws-ebs的存储资源调配程序，该程序提供 EBS 卷的动态资源调配和管理。

通过开箱即用的对 AWS EBS 的本机支持，创建一个将自动调配 EBS 存储的默认存储类非常容易，我们将在名为todobackend-aws/eks/gp2-storage-class.yaml的文件中定义该存储类:

我们将创建一个名为gp2的存储类，顾名思义，它将使用kubernetes.io/aws-ebs存储资源调配器从 AWS 调配类型为gp2或固态硬盘的 EBS 存储。parameters部分控制该存储选择，根据存储类型，可能有其他可用的配置选项，您可以在https://kubernetes . io/docs/concepts/storage-class/# AWS上了解更多。reclaimPolicy的值可以是Retain或Delete，它控制每当从 Kubernetes 中删除与存储类相关联的持久卷声明时，存储资源调配者是否应该保留或删除相关联的 EBS 卷。对于生产用例，您通常会将其设置为Retain，但是对于非生产环境，您可能希望将其设置为Delete的默认回收策略，以避免您不得不手动清理不再被您的集群使用的 EBS 卷。

现在，让我们在 EKS 集群中创建这个存储类，然后我们可以将新的存储类配置为集群的默认存储类:

创建存储类后，使用kubectl patch命令向存储类添加注释，将该类配置为默认类。可以看到，当运行kubectl describe sc/gp2命令查看存储类的详细信息时，IsDefaultClass属性被设置为Yes，确认新创建的类是集群的默认存储类。

有了这一点，到多包应用的 Kubernetes 配置现在有了一个默认存储类，可以应用于todobackend-data持久卷声明，该声明将基于存储类参数提供类型为gp2的 EBS 卷。 The eksServiceRole IAM role that you created earlier in this chapter includes the AmazonEKSClusterPolicy managed policy, which grants your EKS cluster the ability to manage EBS volumes. If you choose to implement your own custom IAM policies for the EKS service role, you must ensure that you include the various EC2 IAM permissions for managing volumes, such as ec2:AttachVolume, ec2:DetachVolume, ec2:CreateVolumes, ec2:DeleteVolumes, ec2:DescribeVolumes, and ec2:ModifyVolumes (this is not an exhaustive list). See https://docs.aws.amazon.com/eks/latest/userguide/service_IAM_role.html for details on the full list of IAM permissions that are granted by AWS-defined EKS service roles and managed policies.

在本章的前面，当您为 todo back and 应用定义 Kubernetes 配置时，您为 todo back and 应用创建了一个类型为LoadBalancer的服务。我们讨论了负载平衡器的实现细节是特定于您的 Kubernetes 集群部署到的平台的，在 Docker Desktop 的情况下，Docker 提供了他们自己的负载平衡器组件，该组件允许服务暴露给您的开发机器上的本地网络接口。

使用 EKS 时，好消息是您不需要做任何事情来支持类型为LoadBalancer的服务–您的 EKS 集群将自动创建一个 AWS 弹性负载平衡器并将其与每个服务端点相关联，其中AmazonEKSClusterPolicy托管策略为此授予所需的 IAM 权限。 Kubernetes 确实允许您通过配置注释来配置LoadBalancer类型的特定于供应商的功能，这是一个元数据属性，给定的供应商在其目标平台上可以理解该属性，如果在不同的平台上部署，例如您的本地 Docker Desktop 环境，则可以忽略该属性。您可以在https://kubernetes . io/docs/concepts/services-networking/service/# publishing-services-service-type上阅读关于这些注释的更多信息，下面的示例演示了如何将特定于 AWS 弹性负载平衡器的几个注释添加到todobackend/k8s/app/deployment.yaml文件中的服务定义中:

在前面的示例中，我们添加了以下注释:

需要注意的一点是，注释期望每个值都是一个字符串值，因此请确保引用布尔值，如"true"和"false"，以及任何数值，如"60"，如前面的代码所示。

现在，您已经准备好将示例应用部署到 AWS，您可以通过首先切换到 todobackend 存储库并确保使用您在本章前面创建的eks上下文来完成:

回想一下，应用和数据库服务都依赖于我们在本地 Docker Desktop 上下文中手动创建的机密，因此您首先需要在您的 EKS 上下文中创建这些机密:

现在，您可以部署数据库服务，该服务将根据您之前创建的默认存储类的配置，创建一个由 EBS 支持的新持久卷:

您可以看到创建了一个持久卷，如果您浏览到 AWS 控制台中的服务 | EC2 ，并从左侧的弹性块存储菜单中选择卷，您应该可以看到持久值对应的 EBS 卷:

查看 EBS 卷

请注意，Kubernetes 用许多标记来标记 EBS 卷，这些标记允许容易地识别哪个持久卷和持久卷声明与它相关联的给定 EBS 卷。

在 Kubernetes 仪表板中，您可以通过选择工作负载 | 部署:来验证todobackend-db部署正在运行

查看 EBS 卷

数据库服务就绪后，您现在可以继续部署应用:

部署应用将执行以下任务:

在 Kubernetes 仪表板中，如果您选择发现和负载平衡 | 服务并选择到后台处理服务，您可以查看该服务的每个内部端点，以及外部负载平衡器端点:

Viewing the todobackend service in the Kubernetes dashboard You can also obtain the external endpoint URL by running the kubectl describe svc/todobackend command.

如果单击外部端点 URL，您应该能够验证 todobackend 应用是否完全正常工作，所有静态内容是否正确显示，以及是否能够添加、删除和更新应用数据库中的 Todo 项目:

Verifying the todobackend application

分解示例应用非常简单，如下所示:

完成此操作后，您应该能够验证与 todo back and 服务关联的弹性负载平衡器资源以及 todo back and 数据库的 EBS 卷是否已被删除，前提是您已将默认存储类的回收策略配置为“删除”。当然，您还应该删除您在本章前面创建的工作节点栈和 EKS 集群栈，以避免不必要的费用。

在本章中，您学习了如何使用 Kubernetes 和 AWS 弹性 Kubernetes 服务(EKS)部署 Docker 应用。Kubernetes 已经凭借强大的开源社区成为领先的容器管理平台之一，随着 AWS 现在用 EKS 服务支持 Kubernetes 客户，Kubernetes 肯定会变得更加受欢迎。

您首先学习了如何在 Docker Desktop 中利用对 Kubernetes 的本机支持，这使得在本地启动和运行 Kubernetes 变得非常容易。您学习了如何创建各种核心 Kubernetes 资源，包括 pods、部署、服务、机密和作业，这些资源为在 Kubernetes 中运行应用提供了基本的构建块。您还学习了如何配置对持久存储的支持，利用持久卷声明将应用的存储需求从底层存储引擎中抽象出来。

然后向您介绍了 EKS，并学习了如何创建 EKS 集群和相关的支持资源，包括运行您的工作节点的 EC2 自动扩展组。您建立了对 EKS 集群的访问，并通过部署 Kubernetes 仪表板来测试集群是否正常工作，该仪表板为您的集群提供了丰富而强大的管理用户界面。

最后，您继续将 todobackend 应用部署到 EKS，其中包括与用于外部连接的 AWS 弹性负载平衡器(ELB)服务和用于提供持久存储的弹性块存储(EBS)的集成。这里的一个重要考虑是，除了添加一些注释来控制 todobackend 服务负载平衡器的配置之外，我们不需要修改之前在本地部署到 Docker Desktop 环境时创建的 Kubernetes 配置(这些注释在使用 Docker Desktop 时被忽略，因此被认为是“安全的”特定于供应商的配置元素)。您应该始终努力实现这一目标，因为它确保您的应用在不同的 Kubernetes 环境中具有最大的可移植性，并且可以独立于底层的 Kubernetes 平台轻松部署，无论是本地开发环境、AWS EKS 还是谷歌 Kubernetes 引擎(GKE)。

好吧，所有美好的事情都必须结束，现在是我说恭喜和感谢你完成这本书的时候了！很高兴写这本书，我希望你已经学会了如何利用 Docker 和 AWS 的力量来测试、构建、部署和操作你自己的容器应用。

有关本章所涵盖主题的更多信息，您可以查看以下链接: