这篇文章是关于 Kubernetes 监控的系列文章的 第一部分 。 第 2 部分 介绍了您应该监控的 Kubernetes 指标和事件，第 3 部分 介绍了收集数据的不同方法，第 4 部分 详细介绍了如何使用 Datadog 监控 Kubernetes 的性能。
什么是 Kubernetes？
Docker 和其他容器技术目前正在基础设施领域掀起一场风暴。对于快速扩展或频繁发布的微服务架构和环境来说，Docker 是理想的选择，在过去的两年里，它的使用量迅速增加。但是，就编排而言，容器带来了前所未有的重大复杂性。这就是 Kubernetes 出现的地方。
舵手
Kubernetes 是 Google 发布的一个开源系统，它可以自动化运行面向服务的应用程序的容器的部署、管理和扩展。许多知名的合作伙伴，如 Red Hat、 CoreOS、 VMWare 和 Meteor 都在支持 Kubernetes 的开发，它现在是 CNCF 基金会 的一部分。
就像指挥家指挥管弦乐队，告诉音乐家什么时候开始演奏，什么时候停止，什么时候演奏得更快、更慢、更安静或更大声一样，Kubernetes 管理你的容器 —— 启动、停止、创建和自动销毁它们，以便以最佳性能运行你的应用程序。将容器化的应用程序分发到各个节点集群，并通过以下方式自动化它们的编排：
- 容器调度
- 健康检查及康复
- 多副本以确保正常运行
- 用于服务命名、发现和负载均衡的内部网络管理
- 资源分配和管理
无论您的容器运行在何处，Kubernetes 都可以部署它们，无论是在 AWS、 Google 云平台、 Azure，还是在本地或混合基础设施中。
传统上使用 Kubernetes 来管理 Docker 容器，但是对 rkt 容器运行时的支持是在 Kubernetes 版本 1.3 中添加的。这个版本也极大地提高了 Kubernetes 的自动缩放功能。
ℹ️ 译者注：
Kubernetes 1.20 版本及以后，已经正式弃用 Docker。另外 rkt 对 OCI（开放容器项目）的兼容性也不够好，在被 Red Hat 收购后已经逐渐被 CRI-O 取代。
目前推荐的容器运行时为：containerd 和 CRI-O
Kubernetes 已经被 eBay，Lithium，Samsung，Jive 和 SoundCloud 等大公司采用。
Kubernetes 是如何在幕后工作的
Pods
由于 pods，Kubernetes 为容器化的组件增加了更高层次的抽象，它促进了资源共享、通信、应用程序部署和管理以及发现。Pods 是最小的可部署单位，可以用 Kubernetes 创建、调度和管理。
每个 pod 包含一个或多个运行应用程序的容器。同一个 pod 中的容器总是被安排在一起，但是每个容器可以运行不同的应用程序。给定 pod 中的容器在同一台主机上运行；共享相同的 IP 地址、端口空间、上下文和命名空间（namespace）（见下文） ; 还可以共享存储等资源。
节点、集群和命名空间
Pods 运行在 节点（node）（以前称为 minions) 上，这些节点是虚拟或物理机器，在 ** 集群（cluster）** 中分组。一个节点集群至少有一个主节点。实际上，建议在生产环境中使用不止一个主控程序，以 确保高可用性。
每个节点上都有一个 kubelet，它确保 PodSpec 中描述的所有容器都正常运行。
在 Kubernetes 中，您可以拥有由同一物理集群支持的多个虚拟集群（称为 命名空间）。这样，您就可以只启动一个集群，并将其资源用于多个环境（例如 staging 和 dev-test)。这有助于节省时间、资源和成本。
kubernetes cluster pods and nodes
副本集和部署
Pods 由 副本集 (replica sets) 动态创建和销毁，这是新一代的 复制控制器（replication controller）。副本集通过确保定义的 pod（副本）数量在任何时候都在运行来保持服务的连续性。如果某些 pod 发生故障或被终止，副本集将自动替换它们。
最近，Kubernetes 引入了声明式 部署（deployment） 来管理副本集。您只需描述“部署对象”中所需的状态，部署将为您处理副本集，以便编排 pod。
当然，您也可以不使用副本集或部署，手动管理 pod，这对于一次性工作非常有用。但是如果一个 pod 碰巧失灵了，就没有任何东西可以检测到它并启动另一个 pod。
Services（服务）
由于 pod 不断地被创建和摧毁，它们各自的 IP 地址不稳定且不可靠，不能用于 pod 之间的通信。因此，Kubernetes 依赖于 服务（service），这些服务是简单的 REST 对象，它们在应用程序的不同组件之间提供稳定的抽象级别。服务（又称微服务）作为一组 pod 的端点，向外部世界公开稳定的 IP 地址，这隐藏了跨集群的动态 pod 调度的复杂性。由于这个额外的抽象，即使构成服务的 pod 来来去去，服务也可以不断地相互通信。它还使 服务发现 和 负载均衡 成为可能。
服务通过利用 标签（label） (Kubernetes 对象上定义的任意字符串）动态标识传入请求的发送位置来实现这一点（参见下面关于标签的部分）。
ℹ️ 总结：
Kubernetes 的一切都是关于抽象
kubernetes abstraction
Auto-scaling（自动缩放）
由于 Horizontal Pod Autoscaler，Kubernetes 可以自动缩放在复制控制器、部署或副本集中运行的 pod 数。这个过程定期检查 pod 的 CPU 利用率，然后优化部署、副本集或复制控制器中的 pod 数量，如果平均 CPU 利用率与您定义的目标不匹配。对其他指标的支持存在于 alpha 中。请注意，autoscaler 需要部署 Heapster （参见 第 3 部分 TODO: 加 URL） ，以便使用这些度量进行自动伸缩。
ℹ️ 译者注：
现在的新版本是需要 kube-metrics
Kubernetes 对你的监控意味着什么？
在任何规模上，监控 Kubernetes 本身以及部署的应用程序和运行它们的容器的健康状况对于确保良好的性能都是必不可少的。
有效地监控 Kubernetes 需要您重新思考和调整监控策略，特别是在您习惯于监控传统主机（如 vm 或物理机器）的情况下。正如容器 完全改变 了我们对在虚拟机上运行服务的看法，Kubernetes 也改变了我们与容器交互的方式。
好消息是，有了适当的监控，即使容器不断移动，但是 Kubernetes 固有的抽象级别为您提供了基础架构的全面视图。监控 Kubernetes 与传统的监控在几个方面有所不同：
- Tag 和 label 变得必不可少
- 您需要监控更多的组件
- 您的监控需要跟踪不断移动的应用程序
- 应用程序可以分布在多个云提供商之间
ag 和 label 很重要，现在它们是必不可少的
使用 Kubernetes，您无法知道应用程序在给定时刻实际运行在哪里。幸运的是，Label 在这里“标记”你的 pod，并对外提供一个稳定的视图。
在容器出现之前的世界中，label 和 tag 在监控基础架构时非常重要。它们允许您对主机进行分组，并在任何抽象级别上聚合它们的度量。这对跟踪动态基础设施的性能和有效调查问题极为有用。
现在有了容器，尤其是像 Kubernetes 这样的编排框架，Kubernetes—label 变得绝对重要，因为它们是识别你的 pod 和它们的容器的唯一方法。
为了使你的指标尽可能有用，你应该给你的 pod 贴上 label，这样你就可以看到你的容器化基础设施的任何方面，比如：
- 前端 / 后端（Frontend/Backend）
- 应用程序（站点，应用程序，数据库，缓存。…)（site,app,db,cache…）
- 环境 (prod，staging，dev…)
- 团队（team）
- 版本（version）
这些用户生成的 Kubernetes label 对于监控是必不可少的，因为它们是在基础设施的不同层次上对度量标准和事件进行切片和分块的唯一方法。
kubernetes labels
🔺自定义 label 连接到 pod
默认情况下，Kubernetes 还公开关于 pods (pod_id, pod_name, pod_namespace)、 container (container_base_image, container_name) 和节点 (host_id, hostname) 的基本信息，以及 命名空间 、 服务名 和复制控制器名称。一些监控工具可以摄取这些属性并将其转换为 tag，这样您就可以像使用其他自定义 Kubernetes label 一样使用它们。
多亏了这些容器级别的 Kubernetes label，你不仅可以得到容器化基础设施的物理视图，还可以得到一个逻辑视图。因此，您可以检查堆栈（命名空间、复制控制器、 pod 或容器）中的每一层，以聚合指标并向下钻取进行调查。
作为用 Kubernetes 生成你的 pod 和应用程序的可访问视图的唯一方法，label 和 tag 现在是所有监控和警报策略的基础。您跟踪的性能指标不会像以前那样附加到主机上，而是聚合在您将用于分组或过滤您感兴趣的 pod 的 label 周围。因此，一定要为 label 定义一个逻辑的、易于理解的模式，并在命名空间中创建清晰的 label。
需要监控的更多组件
在传统的以主机为中心的基础设施中，您只有两层需要监控：您的应用程序（缓存、数据库、负载均衡器。…) 和运行它们的主机。
然后容器添加了一个 新层来监控 主机和应用程序之间的情况。
现在，还需要对用于编排容器的 Kubernetes 进行监控，以便在较高级别上跟踪基础架构。因此，现在需要监控 4 个不同的组成部分，每个组成部分都有其特点和挑战：
- 您的主机，即使您不知道它们实际上运行的是哪些容器和应用程序
- 你的容器
- 您的容器化应用
- Kubernetes 本身
kubernetes monitoring
🔺从传统的监控组件到编排的容器化基础设施的演变
此外，Kubernetes 在监控运行在容器上的应用程序时引入了一个新的问题。…
您的应用程序正在移动
来自容器和 pod 的指标是监控策略的重要组成部分。但是您还需要监控实际运行在这些容器中的应用程序（镜像）。使用 Kubernetes，它可以自动调度你的容器，你对它们在哪里运行的控制非常有限。（授权这样的控制是 Kubernetes 的观点！)
视频链接：使用 Kubernetes，您的监控必须跟踪移动的应用程序
当然，您可以在每次启动或重新启动容器时手动配置从这些应用程序收集度量的检查，但是希望您能够跟上这种变化的速度。
那么你还能做什么呢？
使用提供 服务发现 的监控工具。它将检测 pod 和容器配置的任何变化，并自动调整度量集合，以便您可以不间断地监控您的容器化基础设施，即使它在主机之间扩展、收缩或移位。
ℹ️ 观点：
使用像 Kubernetes 这样的编排工具，服务发现 机制成为监控必备的工具。
适应分布式集群
自从 Kubernetes 1.3，Kubernetes 集群联邦（Cluster Federation），也被称为 Ubernetes，使得 Kubernetes 用户能够在几个数据中心和潜在的多个云提供商之间分发他们的容器化应用程序。这使您可以将应用程序部署到为用户提供最佳性能和可用性的地方，而不必在单个提供程序上具有唯一的故障点。但是，在监控方面，这可能会使事情复杂化，除非您能够轻松地跨多个云和 / 或本地基础设施聚合度量。
ℹ️ 译者注：
第一代 Federation 已弃用，第二代 Federation（又称：KubeFed）发展并不好。
目前 Kubernetes 多集群管理方案百花齐放百家争鸣。
那么我该从哪里开始呢？
当涉及到监控时，Kubernetes 要求您重新考虑您的方法。但是如果您知道要观察什么，如何跟踪它，以及如何解释数据，那么您将能够保持您的容器化基础设施的健康、高效和良好的协调。
本系列的 第 2 部分 分解了在使用 Kubernetes 时应该收集和监控的数据。
