我们想要轻松入门Kubernetes平台，并掌握它，我们就要考虑到Kubernetes的复杂性、基础设施的弹性、可扩展性和安全性，从这几个方面入手我们就可以大体掌握这个平台的核心内容，接下为大家带来2024最新Kubernetes平台入门指引。

2024最新Kubernetes平台入门指引

Kubernetes四个主要内容

可观察性和监控通常作为同义词使用，但它们的方法和范围有所不同。监控侧重于跟踪预定义的指标并在违反阈值时触发警报，而可观察性则通过组合指标、日志、事件和跟踪来提供系统状态的整体视图。 Kubernetes 环境中的可观察性包含各种组件，这些组件协同工作以提供对应用程序和基础设施的运行状况和性能的可见性。可观察性使您能够获得更深入的见解并更有效地诊断问题。传统上，可观察性依赖于三个支柱：指标、日志和跟踪。然而，在 Kubernetes 部署环境中，事件在故障排除和深入了解集群运行状况方面发挥着重要作用。因此，我们将探讨 Kubernetes 可观察性的这四个内容，如下所示。

• 指标：指标是在一段时间内测量的数据的数字表示。在 Kubernetes 环境中，指标可以包括 CPU 和内存利用率、网络流量、磁盘 I/O 和自定义应用程序级指标。指标对于监控资源使用情况、识别性能瓶颈和设置警报至关重要。 Prometheus 中的典型度量示例如下：

container_cpu_usage_seconds_total{container_name=”oauth-server”, namespace=”production”}[5m]

This metric measures the total CPU time consumed by the oauth-server container in the production
 namespace over the last 5 minutes.

• 日志：日志是事件记录流，用于捕获有关应用程序和基础设施的状态和活动的信息。 Kubernetes 组件（例如控制平面和工作节点）会生成日志，容器化应用程序也是如此。日志对于调试、审核和故障排除非常宝贵。 Kubernetes 中的典型日志条目如下：

2024-03-14T10:00:00Z ERROR [oauth-server] Failed to connect to database: timeout exceeded.

This metric measures the total CPU time consumed by the oauth-server container
 in the production namespace over the last 5 minutes.

• 事件： Kubernetes 生成事件来记录集群内的状态变化和重大事件。事件可以提供有关资源创建、删除、扩展和错误条件的见解。监控事件可以帮助您了解 Kubernetes 集群的整体运行状况并及时响应紧急情况。 Kubernetes 中的一个典型事件如下：

2024-03-14T10:05:00Z INFO [kubelet] Successfully pulled image “myapp:latest” for pod “myapp-pod” in namespace “production”.

This log shows kubelet's success in pulling the latest image for "myapp-pod" 
in the "production" namespace.

• 跟踪：在分布式微服务环境中，跟踪提供了各个请求在不同服务中传播时的端到端可见性。跟踪有助于识别跨服务边界的性能瓶颈、延迟问题和错误情况，这使得它们对于排除故障和优化复杂应用程序至关重要。这是一个典型的跟踪示例：

Trace ID: 12345. Operation: GET /api/v1/users. Duration: 250ms. Status: Success.

This trace captures a successful GET request to the /api/v1/users endpoint,
 taking 250 milliseconds to complete.

• 警报：有效的可观察性在很大程度上依赖于警报机制。通过根据预定义的阈值或条件设置警报，您可以在出现问题时立即通知相关团队或个人，从而实现更快的响应时间并最大限度地减少对应用程序和客户的影响。这是一个警报示例：

Alert: CPU utilization for pod “api-server” in namespace “production” exceeds 80% for more than 5 minutes.

This alert notifies that the CPU utilization of the "api-server" pod has been above 80% 
for over 5 minutes, potentially indicating an issue.

可观察性跨越多个层：

• 底层平台（Kubernetes 控制平面、工作节点、网络和存储）
• 您的应用程序（微服务、容器和工作负载）
• 业务数据（应用程序日志、用户交互和特定于域的指标）。

通过捕获并关联来自上述各层的数据，您可以全面了解系统的行为并更有效地检测问题。

另一个需要考虑的重要方面是您是运行单个集群还是多个集群。在多集群环境中，可观察性变得更加重要，因为您需要跨不同集群（可能跨越多个区域或云提供商）聚合和关联数据。

对于 ISV 或初创公司来说，在收集的可观察性数据和所需的见解之间取得平衡至关重要。开发人员可能需要更精细的数据来调试和优化特定组件，而操作员和站点可靠性工程师 (SRE) 可能会关注更高级别的指标和事件，以提供整个系统运行状况的全面视图。

考虑到这一点，让我们回顾一下如何使用可观测性数据来解决问题、查找根本原因并采取行动的示例。

如何确定问题原因及解决方案？

想象一下，您正在 Kubernetes 上运行一个流行的电子商务应用程序，在销售高峰期，您开始收到客户的投诉，称在将商品添加到购物车时响应时间慢和间歇性错误。您如何确定此问题的根本原因并解决它？

让我们看一下这个假设场景：

1. 指标显示性能下降：您的监控仪表板显示购物车微服务的第 95 个百分位响应时间出现峰值，表明存在潜在的性能问题。此外，您还注意到运行此服务的节点上的 CPU 和内存利用率有所增加。
2. 日志提供上下文：通过分析应用程序日志，您发现购物车服务正在记录与数据库连接超时相关的频繁错误。这可能可以解释客户遇到的性能下降和间歇性错误。
3. 跟踪突出显示延迟：您转向分布式跟踪，并注意到对购物车服务的请求比平时花费的时间明显更长，其中大部分延迟发生在数据库交互阶段。
4. 事件指向资源争用：查看Kubernetes事件，发现集群中多个节点内存压力较大，导致频繁发生内核OOM（Out-of-Memory）事件和Pod驱逐。
5. 关联和根本原因识别：通过关联指标、日志、跟踪和事件中的信息，您可以拼凑出根本原因；销售高峰期流量的增加导致托管购物车服务及其数据库的节点出现资源争用。这种资源争用导致数据库连接超时，从而导致客户的响应时间缓慢和间歇性错误。

有了这种洞察力，您可以立即采取措施解决问题，例如扩展购物车服务及其数据库。此外，您可以设置适当的警报和通知，以便将来主动检测类似问题。

此示例展示了可观察性在快速识别和诊断复杂分布式系统中的问题方面的强大功能。通过利用指标、日志、跟踪和事件，并将这些来源的数据关联起来，您可以深入了解应用程序的行为，并查明性能问题或故障的根本原因，最终实现更快的解决方案和更好的用户体验。

Kubernetes常见的问题和注意事项

在 Kubernetes 环境中实现有效的可观察性可能会带来一些挑战，特别是对于资源有限的初创公司和 ISV 而言。以下是一些常见的挑战和注意事项：

• 数据量和信噪比： Kubernetes 环境可以生成大量可观测数据，包括指标、日志、跟踪和事件。筛选大量数据来识别相关信号和可操作的见解可能会让人不知所措，而且不利于时间的利用。
• 存储成本：除非出于安全或合规性原因，否则长期存储和保留可观测性数据可能没有道理。在数据保留策略和存储成本之间找到适当的平衡对于确保最佳成本效率、同时维护分析和合规性所需的历史数据至关重要。
• 数据关联和上下文：来自不同来源（指标、日志、跟踪、事件）的可观察性数据可能是孤立的，这使得关联和得出有意义的见解变得具有挑战性。正确的仪表板和警报是获得良好见解的关键。
• 警报和通知管理：定义适当的警报规则并有效管理通知可能是一个挑战。
• 扩展和多集群可观察性：随着业务的增长及其 Kubernetes 足迹扩展到多个集群或区域，可观察性变得越来越复杂。对于资源有限的 ISV 来说，聚合和关联来自多个来源的可观测性数据，同时保持可见性和控制力可能是一项重大挑战。
• 安全性和合规性：可观测性数据可能包含敏感信息，例如应用程序日志或用户相关数据。 ISV 必须确保适当的访问控制、数据加密以及遵守行业法规和标准，这可能会增加其可观察性实施的复杂性和开销。

为了有效应对这些挑战，ISV 应考虑采用适合其特定需求和限制的可观测性最佳实践，如下节所述。

Kubernetes 相关建议

在 Kubernetes 环境中实现有效的可观察性需要采用结构化方法并遵守最佳实践。以下是关键建议清单。

1.将可观察性不断完善和优化

可观察性是一个持续的过程；它不是一次性的实施成本。随着 Kubernetes 环境的发展，您的可观察性需求也会发生变化。采用迭代方法，不断完善和优化您的可观察性实践，以适应新的要求、新兴技术和不断变化的工作负载。

在开始之前，请定义明确的目的和目标。这些目标可以简单而集中，例如：

1. 增强系统和应用程序的可见性
2. 缩短问题的平均检测时间 (MTTD)
3. 减少事件的平均解决时间 (MTTR)

对于任何可观察性策略来说，指标都是绝对必要的。从指标开始您的可观察性之旅；它们为理解系统行为和性能提供了基础。

随着您的可观察性之旅逐渐成熟，逐渐将日志和事件合并到您的可观察性堆栈中。日志提供有关应用程序行为的详细信息，有助于进行故障排除和根本原因分析。事件可让您深入了解 Kubernetes 集群中的状态变化和重大事件。

通常不建议中小企业规模的 ISV 从分布式跟踪开始，除非您清楚地了解其复杂性和优势。

2.使用 SaaS 平台实现可观察性

对于资源有限的 ISV 和初创公司来说，利用 SaaS 可观察性平台是最佳实践，因为它使他们能够专注于核心业务目标，同时受益于企业级可观察性功能。通过将可观测性基础设施外包给托管服务提供商，团队可以减少运营开销，最大限度地减少对专业知识的需求，并确保其可观测性堆栈的可扩展性和可靠性。

SaaS 可观察性平台提供广泛的功能和优势，包括：

• 指标、日志和事件的集中数据收集。
• 通过处理大量可观测数据而无需管理底层基础设施，从而实现可扩展性和可靠性。
• 与流行的 Kubernetes 发行版、监控工具和日志框架的预构建集成。
• 通过预构建的仪表板进行强大的查询和可视化。
• 警报和通知。
• 通过共享仪表板、警报和见解，在团队成员之间进行协作和共享。

大多数ISV和初创公司资源有限，需要专注于核心业务。利用软件即服务 (SaaS) 可观测性解决方案是一个不错的选择。 Logtail、Papertrail、Datadog、New Relic、Elastic Cloud 或 Grafana Cloud 等托管服务可以以最小的运营开销提供全面的可观察性平台，使您能够专注于核心业务目标，同时受益于可扩展的企业级可观察性。在评估 SaaS 可观察性平台时，请考虑定价、易用性、与现有工具和平台的集成以及客户支持等因素。

3.考虑使用 kube-prometheus-stack 进行自托管

使用 kube-prometheus-stack 是自托管可观察性的最佳实践，因为它提供了专门为 Kubernetes 环境量身定制的经过实战测试的集成解决方案。通过利用该堆栈，团队可以快速建立强大的监控和警报系统，而无需进行大量的配置和集成工作。该堆栈遵循最佳实践，并为 Kubernetes 可观察性提供坚实的基础。

kube -prometheus-stack是 Kubernetes 清单、Grafana 仪表板和 Prometheus 规则的集合，提供全面且易于部署的监控和警报堆栈。该堆栈包括流行的开源工具，例如 Prometheus、Grafana 和 Alertmanager，具有最佳实践警报，并经过预先配置以与 Kubernetes 无缝协作。该堆栈可以扩展以监视和分析 Kubernetes 事件和日志，从而提供有关集群状态和资源变化的宝贵见解。我们推荐使用 K ubernetes 入门套件（第 4 章 – 可观察性）教程来自定义安装，包括数据管理。

我们推荐Loki使用 Grafana 来记录日志。 Loki 是 Grafana Labs 开发的一个可扩展且高度可用的多租户日志聚合系统，专注于简单性和效率。它旨在为存储和查询大量日志数据（在 S3/Spaces 存储中）提供经济高效的解决方案。与对日志内容进行索引的传统日志聚合系统不同，Loki 允许用户使用标签来搜索日志，而不需要全文搜索。这种设计选择显着降低了存储和计算要求。 Loki 与 Grafana 无缝集成，支持丰富的查询和可视化功能。

为了进一步增强 kube-prometheus-stack 的警报功能，请考虑集成Robusta等工具。 Robusta 可以丰富来自 Alertmanager 和 Kubernetes 事件的警报，提供额外的上下文并简化警报管理。它有助于主动识别和响应问题。

使用 Grafana 仪表板时，建议对其进行定制以满足不同的用户角色。开发人员可能需要更精细的信息来进行调试和优化，而运营商和 SRE 可能会从更高级别的系统运行状况和性能视图中受益。根据用户角色自定义仪表板可以提高工作效率并提供可行的见解。

4.控制成本

控制可观测性成本涉及实施管理和优化可观测性数据的存储和保留的策略。随着 Kubernetes 环境的发展并生成越来越多的指标、日志和事件，这些数据的存储需求可能会迅速升级，如果管理不当，会导致巨大的成本。

为了理解成本控制的重要性，让我们考虑一个 10 节点 Kubernetes 集群的示例。假设每个节点平均每天生成 100 MB 的日志数据，每分钟生成 100 个指标。在这种情况下，每日存储需求为：

日志数据：10个节点×100MB/天=1GB/天

指标数据：10 个节点 × 100 个指标/分钟 × 1440 分钟/天 × 8 字节/指标 = 115 MB/天

每月大约有 30 GB 的日志和 3.45 GB 的指标。这些费用会迅速增加，从而增加您的成本。

为了控制成本，请考虑以下策略：

• 数据收集优化：选择对您的可观察性需求至关重要的指标、日志和事件。利用过滤和聚合技术减少存储前的数据量。
• 数据保留策略：根据您的可观察性要求和合规性需求定义明确的数据保留策略。实施分层保留策略，在较短的时间内存储高分辨率数据，并在较长的时间内存储聚合数据。

5.集中多集群环境的可观察性

许多 ISV 运营多个 Kubernetes 集群。虽然您仍然可以通过 kube-prometheus-stack 的独立部署和良好的警报（例如 slack 集成）进行管理，但集中可观察性成为这些情况下的最佳实践。

集中可观察性具有以下好处。

• 统一可见性：通过聚合来自多个集群的可观测性数据，您可以获得整个 Kubernetes 环境的单一管理平台视图。
• 简化故障排除：集中的可观察性使您能够快速识别和调查跨多个集群的问题。
• 一致的监控和警报：借助集中式可观测性解决方案，您可以在所有集群中定义和实施一致的监控和警报策略。
• 高效的资源利用：集中可观察性通过提供对跨集群的应用程序的性能和可扩展性的洞察来帮助您优化资源利用。

上图描述了这样的架构。要在多集群环境中集中可观察性，您可以利用 Grafana Mimir 或 Thanos 等工具。这些工具旨在聚合和联合来自多个 Prometheus 实例的可观测性数据，这些数据通常用于监控 Kubernetes 集群。

Grafana Mimir 是一个高度可扩展的分布式时间序列数据库，可以从多个 Prometheus 服务器获取和存储指标。您只需将 Mimir 作为数据源连接到 Grafana 即可。它节省了大量配置，而且您不必在每个集群上公开每个 prometheus 服务。现在，您可以拥有跨所有连接集群的全局查询视图，从而能够执行跨集群分析和可视化。 Mimir 还提供水平可扩展性、高可用性和长期存储功能等功能。

在集中可观测性时，请考虑以下几个方面：

• 数据聚合：确定需要从每个集群聚合的指标和日志，并相应地配置可观察性工具。
• 查询性能：确保您的集中式可观测性解决方案能够处理查询负载并提供快速响应时间，即使在处理来自多个集群的大量数据时也是如此。
• 数据保留：为集中式可观测系统定义数据保留策略，同时考虑存储要求和历史数据分析的需要。
• 访问控制：实施适当的访问控制机制，以确保用户只能访问和查看与其角色和职责相关的可观察性数据。

可观察性是一个持续的旅程；持续改进和适应是成功的关键。定期审查和完善您的可观察性实践，以适应不断变化的业务需求和技术进步。

最后

随着我们继续探索 ISV 采用 Kubernetes 的旅程，我们正在进行的博客系列将更深入地探讨部署的弹性、效率和安全性。

• 开发人员生产力（第 1 部分）：通过简化 Kubernetes 环境中的开发和部署流程，最大限度地提高开发人员生产力。
• 可观察性（本文）：深入了解应用程序和基础设施的工具和策略，确保您可以有效地监控性能和解决问题。
• 可靠性和规模（第 3 部分）：探索如何管理零停机部署、就绪/活跃探测、应用程序扩展、DNS 和 CNI，以在不同负载下保持最佳性能。
• 灾难准备（第 4 部分）：讨论制定可靠的灾难恢复计划的重要性，包括备份策略、实践和定期演习，以确保业务连续性。
• 安全性（第 5 部分）：深入研究保护 Kubernetes 环境的安全，涵盖网络策略、访问控制和保护应用程序工作负载的最佳实践。

其中每个内容对于解决 Kubernetes 的复杂性、增强基础设施的弹性、可扩展性和安全性都至关重要，希望上面的2024最新Kubernetes入门指引可以让你轻松掌握平台的使用技巧。