Kubernetes十周年：送给架构师的十条实用技巧

Kubernetes 诞生10 周年之际，CNCF 生态系统负责人 Taylor Dolezal 为架构师提供了十条建议，帮助大家更好地驾驭 Kubernetes 及其生态系统。

Kubernetes 诞生10 周年之际，CNCF 生态系统负责人 Taylor Dolezal 为架构师提供了十条建议，帮助大家更好地驾驭 Kubernetes 及其生态系统。

Dolezal 的 IT 职业生涯起步于他创立的 Pixelmachinist 公司，这家公司致力于为克利夫兰地区的企业提供软件解决方案。随后，他加入了华特迪士尼工作室担任 SRE 工程师，并最终成为 HashiCorp 的高级开发者、倡导者。

在这次访谈中，Dolezal深入探讨了Kubernetes，并为架构师提供了十大实用技巧，以助他们更好地掌握这个平台和其生态系统。他还讨论了Kubernetes社区如何成功地整合了基础设施，并总结了这当中的“经验教训”给开发者和架构师们。

在深入探讨前，能否简要介绍您刚开始接触 Kubernetes 的背景？

我于2016年开始接触Kubernetes ，我在华特迪士尼工作室工作，当时我们正处于一次重大的云迁移中，为了管理不断增长的容器化工作负载，我们关注到了Kubernetes（以下简称K8s）。

当时，K8s仍处于早期阶段，采用它就像踏入未知领域。因此我们面临许多挑战：从理解核心概念，到弄清楚如何将云原生原则集成到我们现有的系统中。在这一阶段，我得到了在大型企业环境中实施 K8s 的宝贵经验，加深了技术理解，深入了解这当中所需的组织和文化转变。

随着我越来越多地参与K8s社区、为各种项目做出贡献，并参加 KubeCon 活动，我看到了云原生生态系统更大的潜力。成为CNCF 生态系统负责人后，我致力于促进最终用户、供应商和 CNCF 项目之间的合作。

我做过K8s的实际实施、社区建设多方面的工作，这种多视角对于理解企业不断变化的需求，并让生态适应这些需求是至关重要的。见证并参与 K8s从一项有前途的技术成长为容器编排标准，是一件非常有趣的事情。

K8s架构师应该关注哪些关键的安全因素，以确保安全且合规的集群环境？

K8s 安全需要采取全面、主动的方法。根据我与众多组织合作的经验，有几个关键领域需要关注：

身份和访问管理是基础。组织应实施超越基本 RBAC 的细粒度访问控制，并可能采用零信任模型，最小特权原则应指导所有访问决策。

确保应用程序生命周期的安全至关重要。这种安全性包括强化 CI/CD 管道、实施全面的镜像扫描和签名流程以及维护安全的容器注册表。目标是确保环境中每个组件的完整性，而不仅仅是检测漏洞。

网络安全需要仔细考虑。虽然 K8s 网络策略提供了基础，但许多组织采用更高级的解决方案，来精细控制服务间通信和默认加密。

数据保护对于静态和传输中都至关重要。这种保护涉及加密和谨慎管理机密和敏感配置数据。

持续的安全监控和审计至关重要。组织应实施全面的日志记录和警报系统，定期进行安全审计，并为事件响应做好准备。

K8s 安全是一个持续的过程，而不是一次性设置，它需要将基础设施视为代码，并在整个开发生命周期中融入安全实践。

社区参与在 K8s 安全中发挥着至关重要的作用。Linux基金会也强调了这一点。我们通过为项目做出贡献、分享经验和参与社区团体来共同增强整个生态系统的安全性。

成功的组织将安全性融入其流程中，并专注于构建有弹性、可自我修复的环境，以实时检测和应对威胁，而不是追求“牢不可破”的系统。

如何在大规模部署中优化资源利用率并降低成本？

K8s 的资源优化是一个持续的过程，尤其是在大规模部署中，需要采取战略性方法，在性能、成本效益和可扩展性之间找到适当的平衡。

首先可以利用 K8s 原生工具（如 Horizontal Pod Autoscaler 和 Vertical Pod Autoscaler），这些工具有助于根据实际使用模式动态调整资源，为所有容器实施适当的资源请求和限制，对于防止争用和确保公平分配至关重要。

在云环境中，利用节点自动扩展可以帮助将容量与需求相匹配，从而优化成本。考虑对非关键工作负载使用现货实例或可抢占虚拟机，以进一步降低费用，实施 pod 中断预算可确保在这些扩展事件期间实现高可用性。

可见性对于优化至关重要。可以使用 kube-state-metrics 和Prometheus等工具进行详细的资源监控，定期审核以清理未使用的资源（例如孤立卷或未使用的负载平衡器），可以随着时间的推移节省大量成本。

采用FinOps原则有助于协调财务和运营目标，为持续优化提供框架。OpenCost 等工具可提供有关 K8s 支出的宝贵见解，帮助团队就资源分配做出明智的决策。

请记住，有效的资源优化是一个迭代过程。它需要持续监控、分析和调整，以确保云原生环境在应用程序和基础设施发展过程中，保持高效且经济高效。

在 K8s 环境中实现和管理可观察性（日志记录、监控和跟踪）的最佳实践是什么？

K8s 环境中的可观察性对于维护系统健康、性能和安全性至关重要。根据我与各个组织合作的经验，我建议重点关注以下关键领域：

首先，采用结合日志记录、监控和跟踪的综合方法。每个组件都提供了独特的见解：

日志记录可捕获详细的事件数据，这对于调试和审计跟踪至关重要。在所有应用程序和基础设施组件中，使用标准格式实施集中式日志记录策略。这种方法有助于更轻松地进行搜索和分析。

监控可跟踪系统的运行状况和性能。专注于收集基础设施和特定于应用程序的指标（如 CPU 和内存使用情况）。根据这些指标设置警报，以主动解决问题。

分布式跟踪有助于了解跨微服务的请求流，此功能对于处理跨大规模环境的复杂分布式系统至关重要。

其次，接受“可观察性即代码”的概念。使用声明性清单定义可观察性配置，并与应用程序代码一起管理它们，这种做法可确保一致性并允许对可观察性设置进行版本控制。

第三，考虑 K8s 环境的独特挑战。容器编排的动态特性意味着传统的静态监控方法经常需要修改，实施能够在新服务启动时自动发现和监控它们的解决方案。

第四，关注有意义、可操作的指标。在复杂的系统中，数据很容易让人不知所措，与开发和运营团队密切合作，确定最关键的系统健康和性能指标。

最后，培养一种注重可观察性的文化。鼓励开发人员正确地检测他们的代码，并从设计阶段开始考虑可观察性。从长远来看，这种积极主动的方法将使系统更易于管理、更具弹性。

请记住，有效的可观察性不是收集更多数据，而是获得可操作的见解和经验，帮助以后快速了解和解决问题，预测潜在问题，并不断提高系统性能和可靠性。

架构师可以遵循哪些技巧，来确保 K8s 集群的高可用性（HA）和灾难恢复（DR）？

除了考虑基础设施之外，保证K8s 的高可用性和灾难恢复的还要考虑很多方面。虽然强大的集群设置很重要，但真正的弹性来自于考虑应用程序、数据和团队流程的整体方法。

故障经常以意想不到的方式发生。关键应用程序组件不可用，多么完美配置的多云设置都无济于事，从基础设施到应用程序层，查看整个堆栈至关重要。

一个经常被忽视的方面是数据。在灾难情况下，只有当数据可用或一致时，应用程序才能正常运行，这对于有状态的应用程序来说可能是一个挑战，需要想想你的数据如何移动以及它在哪里。

另一个关键因素是团队的准备程度。定期进行灾难模拟是非常有价值的，可以帮助发现技术设置和团队响应流程中的漏洞。并且，这些练习通常可以在解决一些不可预见的问题。

在 HA/DR 场景中，自动化是好帮手，但也是一把双刃剑。虽然它可以加快恢复速度，但实施不当的自动化也会使问题升级，所以平衡是关键。

最后，请记住 HA/DR 策略中的人为因素。在服务和平台恢复期间，清晰的沟通渠道和明确的角色，在响应事件时可以发挥巨大作用，混乱和缺乏清晰度可能会带来巨大的问题。

如何简化持续集成和持续部署（CI/CD）管道以提高交付效率？

简化 K8s 部署的 CI/CD 管道可实现高效、可靠的软件交付，结合以往经验我总结了几种非常有效的策略：

GitOps 原则在 K8s 环境中有显著的好处。Git 存储库是应用程序代码和基础架构配置的唯一真实来源，可实现一致、可审计和可重现的部署，这种方法符合 K8s 的声明性本质，简化了回滚和环境奇偶校验。

利用云原生概念可提高 CI/CD 效率。用于环境隔离的命名空间、用于资源管理的标签和注释以及用于零停机部署的滚动更新功能，有助于简化 K8s 原生工作流程。

基础设施测试往往被低估，但却至关重要。在部署前验证 K8s 清单和策略可尽早发现潜在问题，从而节省大量时间和资源，这种做法是对传统单元测试和集成测试的补充，可提供更全面的质量保证方法。

渐进式交付（例如金丝雀部署或功能标记）更可控。这些方法允许团队密切监控变更的影响，并在出现问题时快速回滚，从而降低生产环境中的风险。

自动化不仅限于基本的构建和部署流程。将安全扫描、依赖项更新和合规性检查集成到管道中可确保一致性，能使团队专注于更高价值的活动。

K8s 中的机密管理需要仔细考虑。实施安全、动态的解决方案来存储和轮换 API 密钥和密码等敏感信息，对于保持强大的安全态势至关重要。

在CI/CD 管道实施可观测性时获取经验。捕获管道的全面日志、监控和跟踪有助于提供关键的可见性，从而快速识别和解决管道问题。

持续改进 CI/CD 流程。这种思维方式推动部署速度、可靠性和安全性的不断改进，以跟上不断变化的业务需求和功能添加。

在跨集群扩展服务时，应该牢记哪些高级网络注意事项？

随着组织跨集群扩展服务，K8s 中的网络会变得越来越复杂。面对多集群服务发现带来了重大挑战，强大的服务网格可以跨集群提供统一的服务发现机制，实现无缝通信和负载平衡，这种方法需要精心设计，以管理增加的延迟和潜在的故障点。

跨集群边界实施网络策略需要复杂的解决方案。虽然 K8s 网络策略在集群内运行良好，但跨集群扩展这些策略通常需要额外的工具或自定义模式。解决这一挑战，对于在整个基础架构中保持一致的安全态势至关重要。

随着多集群设置的增加，边缘路由和流量管理的复杂性也随之增加。实施智能边缘路由以根据延迟、负载或数据驻留要求等因素将流量引导到最合适的集群变得至关重要，这通常涉及将 K8s 网络与更广泛的网络基础设施和 CDN 集成。

跨地理分布集群的性能优化带来了独特的挑战。拓扑感知路由和智能客户端负载平衡等技术，可以通过减少集群间流量和延迟来显著提高应用程序性能。

跨集群的 DNS 管理需要仔细考虑。实施了解多集群拓扑的全局 DNS 解决方案，可以显著简化服务发现并提高可靠性；实施网络流的分布式跟踪和集中式日志记录，有助于排除故障并优化跨集群通信。

K8s 架构师要有超越单集群网络范式的思考能力，成功的实施还需要与网络工程团队密切合作，并深入了解 K8s 网络原理和更广泛的企业网络概念。

如何有效管理 K8s 生态系统中的有状态应用程序和持久存储？

我了解的一种模式，是针对特定数据库或有状态应用程序使用自定义控制器，这些控制器可以自动执行许多过去需要手动干预的复杂操作，例如扩展、备份，甚至灾难恢复的某些方面。

持久存储解决方案也取得了长足进步。容器存储接口(CSI) 是一项关键发展，它允许以标准化方式将存储系统与 K8s 集成，这为组织开辟了一个无限可能的世界，使他们能够使用最适合其需求的存储解决方案，无论是在本地还是在云中。

然而，需要注意的是，在 K8s 中管理有状态应用程序仍然是一项复杂的任务，需要仔细规划和专业知识。我见过一些比较成功的团队，他们将这些服务作为K8s策略中的重点，投入时间深入了解每个应用程序的具体需求，并据此设计相应的基础设施。

我学到的关键一课是，对于 K8s 中的有状态应用程序，没有一刀切的解决方案。成功源于对应用程序需求和所选存储解决方案功能的深刻理解，关键在于在利用 K8s 的编排功能，和尊重有状态工作负载的独特特征之间找到适当的平衡。

应该使用什么策略，来管理跨云提供商或内部环境的多个集群？

这让我想起了在迪士尼工作时的情形，当时我们面临着在 350 多个应用程序中协调工作负载的挑战，这次经历让我学到了关于多集群管理复杂性的宝贵经验。

成功不在于将每个集群视为一个孤立的实体，而在于制定一个承认其独特特征的统一策略。在管理不同环境中的集群时，标准化变得至关重要（包括如何部署工作负载、如何处理治理、安全和运营）。

在 CNCF 的最终用户计划中，我观察到：成功的组织首先要建立明确的界限，根据数据主权、延迟要求和成本优化等因素，确定哪些工作负载属于哪里。

将多集群策略视作产品是一种特别有效的模式。通过清晰的路线路、深入理解开发运维团队需求，并根据反馈持续迭代构建一个强大的平台，让团队无论在何处都能部署和管理应用。

多集群环境中的安全性和合规性需要特别注意。每个云或本地环境都有安全考虑和合规性要求，挑战在于在尊重这些差异的同时，如何保持一致的安全政策。

最有意思的是那些将自动化应用于集群部署和整个生命周期管理的组织，他们从集群的初始配置、日常维护到退役，都实现了自动化，很大程度上保障了一致性，并减轻了管理多个集群的工作量。

多集群管理需要平台、安全和应用程序团队之间的紧密协作。当技术选择与运营能力和业务目标相一致时，团队的表现会更出色。

如何解决集群生命周期管理和版本升级相关的问题？

集群生命周期管理是 K8s 生态系统中最为棘手的挑战之一。要跟上 K8s 的更新步伐，并应对企业环境的复杂性，就需要仔细考虑升级策略。

发布周期影响堆栈的每一层（从核心基础设施到应用程序工作负载）。成功的升级策略可以解释这种连锁反应，这需要开发团队调整其应用程序，操作员了解新功能和弃用功能，安全团队评估安全模型的变化。

K8s 增强提案(KEP) 体现了这种管理变更的结构化方法。K8s 中每个重要功能的添加或修改都遵循此流程，为架构师提供了对即将发生的变化的清晰可见性。KEP 详细说明了整个生态系统的技术规范、动机、设计约束和潜在影响，这种透明度使架构师可以主动规划未来的升级，并了解特定变化背后的原因。

发布计划需要在进度和稳定性之间取得平衡。跳过太多版本会造成技术债务和安全漏洞，而升级过于频繁，则会让团队不堪重负并带来不必要的风险，了解这种动态有助于架构师设计可持续的升级策略。

沟通是成功升级的基石。技术团队需要迁移路径，管理需要风险评估和时间表，应用程序团队需要了解对其工作负载的潜在影响，清晰的沟通渠道和明确的流程有助于协调这些复杂的变化。

有效的集群生命周期管理，可将升级从重大事件转变为常规操作。这种转变通过测试环境、实用自动化，以及对特定环境要求和约束的透彻理解来实现。

维护一个文档齐全、一致且协作性强的K8s基础设施，有哪些重要建议？

在K8s中，文档工作不仅仅是记录技术规范那么简单。根据我在SIG Docs工作的经验，需要让文档策略与它们描述的基础设施一同演进。

活跃的文档应与代码紧密相连。架构决策、权衡和未来考虑为团队提供了维护和发展其基础架构的重要背景，有助于团队了解当前状态和历史背景。

团队可能会低估文档标准化的重要性。运行手册、架构决策记录和操作程序的一致结构可以加快入职速度并减少事故期间的精神压力，这种标准化在管理多个集群或跨云提供商工作时尤其有益。

基础设施文档应该讲述一个故事。充足的文档应该引导读者了解系统的演变过程，而不是孤立的 Wiki 页面或分散的 README。当遇到基础设施中不熟悉的部分时，团队应该了解它的工作原理、它存在的原因以及它解决了哪些问题。

跨团队协作以共同理解为基础。定期的架构评审、事件回顾和技术讨论会产生宝贵的见解，记录这些讨论和决策有助于团队建立集体知识并避免重复过去的错误。

功能标记、API 版本和弃用政策需要清晰的文档记录。这些元素直接影响应用程序团队，需要仔细沟通。通过维护这些更改的全面记录，架构师可以以此帮助团队顺利过渡并有效地规划未来的更新。

CNCF生态庞大，可以给大家提供未来1-2年的K8s学习路线指南吗？

云原生生态系统的优势在于有系统性的方法解决不同的技术需求。架构师不应该试图了解每个项目，而应该专注于自己的领域：

• 应用定义和开发涵盖构建云原生应用的工具和框架。其中包括数据库、流媒体平台、应用定义和持续集成/交付工具，这些构成了现代应用开发的支柱。

• 可观察性和分析工具可洞察系统行为，帮助团队了解其生产中的应用程序。此类别包括支持可靠操作的监控、日志记录、跟踪和混沌工程工具。

• 编排和管理侧重于调度、扩展和维护容器化工作负载。除了容器编排之外，还包括服务网格、API 网关和服务发现 — 管理分布式系统的关键组件。

• 配置涵盖部署和维护云原生基础设施所需的工具，包括自动化、安全性、密钥管理和映像构建。这些工具可帮助团队跨不同平台建立一致、安全的环境。

• 运行时是基础 — 容器运行时、存储和网络组件，它们使云原生基础设施成为可能。了解运行时需求有助于为所有其他类别的决策提供依据。

CNCF技术监督委员会（TOC）和最终用户技术咨询委员会（TAB）分别通过技术顾问组（TAGs）和用户组提供指导。这些社区能够直接获取专业知识和实际经验，帮助团队在各个类别中做出选择。

每个组织的云原生之路都是独一无二的。深入理解云原生生态的不同领域，有助于团队更情绪当前的挑战和需求。通过与相关社区的交流，获得宝贵的见解和学习机会，能促使找到更适合的解决方案，做出更明智的选择。

来源：dbaplus社群

原文作者：Raghavan