看到这篇文章的时候，你很可能已经了解到了使用 kubernetes 管理多服务架构的好处。本文不会讨论为什么要使用 kubernetes，而是重点讨论你已经确定将kubernetes作为你的解决方案后，如何使用它。
网上有许多 kubernetes 的学习资源，这当然很好，但这也使得我们很难知道从哪里以及如何开始学习这项庞大的技术。本文将提供一系列学习路径和资源，涵盖在 K8s 集群上运行应用程序微服务的不同方面。
我们将介绍一些概念，并为实际的学习提供外部资源，这将是你成为全面的 K8s 工程师的一站式指南。
一、十个步骤
STEP 1：在本地安装 Minikube 并熟悉 Control Plane 组件
Minikube 将为我们模拟一个多服务集群环境，它安装快速简便，文档可在此处找到。Minikube 比较占用机器资源（它非常占用 RAM），因此请记住这一点。
了解 k8s 集群组件的作用很重要。在继续第 2 步之前，请访问此简短教程。关注驻留在Control Plane（主节点）上的组件。
Kube-apiserver：为k8s api对象（如pods）配置数据
Kubelet：向 api-server 注册一个节点
Kube-controller-manager：一个嵌入 k8s 核心控制循环的守护进程
Kube-scheduler：确定哪些节点是每个 Pod 的有效位置
Kube-proxy：将发往服务的流量定向到正确的后端 Pod
STEP 2：安装并熟悉 Kubectl
kubernetes命令行界面或 Kubectl 用于从主节点（稍后讨论）或您的本地机器向 K8s 环境中的工作节点发出调度命令。要安装命令行工具，请单击此处。您可以在此处学习基本命令，但我强烈建议您在深入了解 Kubectl 之前先完成第 3 步并了解不同类型的 k8s yaml 配置对象。
STEP 3：了解不同的 yaml k8s api 对象
我认为最省时的方法是在高层次上学习核心 K8s 配置 yaml api 对象的目的。
不要记住文件结构或语言，因为 Helm（在下一步中有详细说明）会自动创建 yaml 配置结构。此处有个简短的教程，重点了解以下各项的作用：
部署
服务
服务帐户
ingress（不要与后面讨论的 nginx-ingress-controller 混淆）
hpa（水平 pod 自动缩放器）
ConfigMap 和 Secrets
STEP 4：使用 Helm 为你的各种微服务编写 yaml 自定义文件
Helm 自动为您创建的每个“chart”创建默认的 yaml 配置文件。每个“chart”代表您架构中的一个单独的微服务。“chart”目录包含在集群上部署此微服务所需的所有配置文件。由于微服务是使用定义文件部署的，因此可以灵活轻松地更改和重新部署。最佳实践是将所有 helm 目录推送到（私有）git 存储库中，以便您稍后可以使用单个命令在不同的集群上重新安装所有服务。“动态” kubectl 命令不提供这种可重用性。
在大多数情况下，需要在每个Helm Chart中编辑的唯一文件是 values.yaml 文件。该文件为每个微服务创建了一个“单一的事实来源”。有关如何创建 Helm 图表的完整指南，我们会放在另一篇文章。
STEP 5：使用 KOPS 构建具有工作节点自动缩放功能的高可用云设置
一旦您看到您的 Helm chart服务在 Minikube 中成功相互通信，您就正式准备好设置云环境了。高可用云设置被定义为在不同区域中至少有两个工作节点，每个节点托管您的应用程序入口控制器和服务。如果一个数据中心因风暴着火，另一个节点驻留在一个完全不同的“计算机群”中，并将继续不间断地处理传入请求。您的最终客户将不受干扰。不用担心，K8s 会在几分钟内自动创建在火灾中丢失的 Node 工作线程。
第一步，从您的云提供商处购买一台便宜、低 CPU/RAM 的机器。在这台便宜的机器上安装 Kubectl、KOPS 和 Helm。这台机器将被称为主节点，它将负责连接、交互和设置集群和驻留在其中的 pod。详细介绍，我们会在另一篇文章说明。
确保将所有 KOPS 命令记录在 sh 脚本文件中，这样您的基础设施构建过程就会被记录为代码，并且可以轻松复制，以防出现可能需要重新设置集群的错误。“基础设施即代码”的概念通过使用 KOPS 和 Helm 得到了很好的体现。
STEP 6：设置您的 Nginx 入口控制器和微服务入口 yaml 以满足您的需求
Nginx 入口控制器将管理到集群的流量。它可以配置为向服务提供外部可访问的 URL、负载平衡流量、终止 SSL/TLS 并提供基于名称的虚拟主机。下一篇文章我们将带您逐步了解如何部署带有 aws LoadBalancer 的 Nginx 入口控制器。
Helm 自动创建的入口 yaml 定义文件是不同的。它提供特定于服务的入口配置。annotations 字段是您定义 https 转发规则、任何请求大小限制和超时或与传入请求处理相关的其他重要配置的地方。这些规则通常会因集群中的服务而异，这就是为什么每个微服务都有自己的入口。
STEP 7：理解pod水平自动伸缩和集群自动伸缩的关系
您的某些服务可能需要定义一个 hpa（水平 pod 自动缩放器）yaml 文件以允许自动缩放。调度程序将根据您在部署 yaml 文件中定义的 cpu/ram 阈值自动生成更多 pod。一旦 Node 用 Pod 填满了它的资源限制，它就会自动创建一个额外的 Node 并在其上恢复 Pod 的调度。类似地，如果微服务上的工作负载下降，k8s 将神奇地“释放”或终止它产生的 pod 以及它在变得不必要时自动创建的新节点。
STEP 8：使用 taints、tolerations、affinity 和 anti-affinity 将 pod 自动安排在适当的节点上
“污染”节点，包括在其上放置一个标签，部署可以“容忍”（或换句话说，允许在被污染的节点上进行调度）或不允许（禁止调度）。Tolerations 在部署 yaml 文件的 pod spec 部分中指定，而污点则使用 Node.js 上的 Kubectl 命令进行标记。官方文档可以在这里找到。
一个类似的 yaml 配置调度功能是节点选择器 pod 规范。它赋予 Pod 对特定节点污点的亲和（或喜欢），或对节点污点的反亲和（不喜欢）。当尝试在具有特殊功能（高 CPU、GPU、高内存）的节点上调度特定 pod 时，节点亲和性非常强大。它最常用于防止在主节点上调度 Pod（为控制平面 Pod 保留）。
有时希望确保两个 Pod 不会自动部署到同一台机器上。为此，我们有Pod 间关联规则。例如，假设我们有两个 Pod（属于相同的部署/副本集），每个都需要 70% 的节点 CPU。在这种情况下，我们每个节点只能运行一个 Pod，两个 Pod 会导致 CPU 过载。一个不需要资源跟踪的简单解决方案是在部署中放置一个 pod anti-affinity 到它自己。这将实现每个工作节点关系一个 pod。
STEP 9：使用 Prometheus 和 Grafana 进行监控
最基本的性能监控工具是指标服务器。这是使用水平 pod 自动缩放器的基本先决条件，您可以使用它执行“Kubectl top”命令来检索 pod 或节点的 CPU 使用率。这很重要，因为在 K8s 中，每个设置为水平自动缩放的部署都必须在 yaml 配置中定义 CPU/RAM 要求（和限制）。
请注意，您可能会发现指标服务器本身并没有提供足够的洞察力。如果您的服务是 RAM/CPU 密集型的，您将需要一个可视化工具来精确测量每个 Pod 的资源使用情况。更好的监控意味着更少的意外和更少的 Pod 由于限制过度使用或技术术语 OOM 终止而崩溃。
我们会在另一篇文章中介绍有关如何使用helm charts安装 Grafana 和 Prometheus 的详细指南。Prometheus 将测量资源使用情况，而 Grafana 提供了一个可视化界面，用于在 x 时间轴上查看不同的资源指标。
STEP 10：使用 Elastic Search 和 Kibana 聚合日志记录
可以使用以下命令查看每个 pod 的实时 STDOUT：
kubectl logs -f
这本身是不够的。
日志查看器显示 pod 写入 STDOUT 的最新打印的一部分。我们需要查看日志的一个常见原因是错误导致 pod 崩溃。在 pod 崩溃的情况下，日志将被擦除，并且无法恢复它们或调查源错误。
这个时候就得Elastic Search登场了！
它很容易与 Helm Charts 一起安装，并将集中和记录集群中所有 pod 的所有日志。Kibana 将为我们提供一个界面，我们可以从中搜索日志，或者缩小属于特定 pod 或时间段的日志。