摘要：他曾在 HashiCorp 担任高级开发者布道师，并在华特迪士尼工作室担任站点可靠性工程师。他实际上是通过创立自己的软件解决方案公司 Pixelmachinist 开始自己的 IT 职业生涯的，该公司专注于克利夫兰地区的企业。

本次访谈中，CNCF 生态系统负责人 Taylor Dolezal 为架构师提供了十条关于如何驾驭 Kubernetes 及其生态系统的建议。

译自 10 Tips for Kubernetes Architects on K8s' 10th Birthday，作者 Raghavan Srinivas。

我们与云原生计算基金会（CNCF）生态系统负责人Taylor Dolezal交谈，讨论了正在庆祝其十周年的 Kubernetes。

他曾在 HashiCorp 担任高级开发者布道师，并在华特迪士尼工作室担任站点可靠性工程师。他实际上是通过创立自己的软件解决方案公司 Pixelmachinist 开始自己的 IT 职业生涯的，该公司专注于克利夫兰地区的企业。

Taylor Dolezal (LinkedIn)

在犹他州盐湖城举行的北美 KubeCon + CloudNativeCon 2024 大会之前，我采访了他。此次活动将于 11 月 12 日至 14 日举行。从在旧金山举行的第一次 Kubecon 大会上的不起眼开端，到 2018 年在西雅图举行的爆满活动，此次活动仍然在平台维护者、开发人员和架构师中很受欢迎。

与会者可以从 1937 篇提交的论文中选择 218 个会议、主题演讲、闪电演讲和小组讨论，其中有 87 个由 CNCF 项目维护者主持的会议，面向各行各业和各种技能水平的技术人员。与会者还可以在周二参加 40 多个 CNCF 项目闪电演讲。

在本次采访中，Dolezal谈到了 Kubernetes，并为架构师提供了十大技巧，以帮助他们驾驭该平台和生态系统。他谈到了 Kubernetes 社区的成功，该社区成功地统一了基础设施，以及如何利用这些“经验教训”来帮助开发人员和架构师。

在深入探讨十大技巧之前，您能否先介绍一下自己，并简要介绍一下您最初接触 Kubernetes 的经历？

我与 Kubernetes 的旅程始于 2016 年，当时我在华特迪士尼工作室工作。当时我们正在进行大规模的云迁移，Kubernetes 成为管理我们不断增长的容器化工作负载的有前景的解决方案。

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

随着我更多地参与 Kubernetes 社区，为各种项目做出贡献并参与 KubeCon 活动，我看到了更广泛的云原生生态系统的巨大潜力。我对社区的关注使我担任了我在 CNCF 的当前职位，在那里我致力于促进最终用户、供应商和 CNCF 项目之间的合作。

我的背景涵盖了 Kubernetes 的实践实施方面和社区建设方面。这种双重视角对于理解企业的不断变化的需求以及生态系统如何适应这些需求至关重要。见证并促成 Kubernetes 从一项有前景的技术发展到容器编排标准的过程，令人着迷。

Kubernetes 架构师应关注哪些关键安全注意事项，以确保安全合规的集群环境？

Kubernetes 安全需要一种全面主动的方法。根据我与众多组织的经验，一些关键领域需要关注：

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

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

网络安全需要仔细考虑。虽然 Kubernetes 网络策略提供了基础，但许多组织采用更高级的解决方案来对服务间通信和默认加密进行细粒度控制。 数据保护对于静态数据和传输中数据都至关重要。此保护涉及加密以及对密钥和敏感配置数据的仔细管理。

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

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

社区参与在Kubernetes安全中发挥着至关重要的作用。Linux基金会的研究强调了社区主导的倡议如何应对安全挑战。我们通过为项目贡献力量、分享经验和参与社区小组，共同增强整个生态系统的安全性。

成功的组织将安全集成到其流程中，并专注于构建弹性、自愈的环境，这些环境能够实时检测和响应威胁，而不是追求“不可攻破”的系统。

Kubernetes架构师如何优化大型部署中的资源利用率并降低成本？

Kubernetes中的资源优化是一个持续的过程，需要一种战略性方法，尤其是在大型部署中。这关乎在性能、成本效率和可扩展性之间取得正确的平衡。

利用Kubernetes原生工具，如水平Pod自动缩放器和垂直Pod自动缩放器，是一个良好的起点。这些工具有助于根据实际使用模式动态调整资源。为所有容器实施适当的资源请求和限制对于防止争用和确保公平分配至关重要。

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

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

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

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

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

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

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

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

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

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

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

第三，考虑Kubernetes环境的独特挑战。容器编排的动态特性意味着传统静态监控方法通常需要修改。实施能够自动发现和监控新服务的解决方案，因为它们会启动。 第四，关注有意义的可执行指标。在复杂的系统中，很容易被数据淹没。与开发和运维团队紧密合作，确定最关键的系统健康和性能指标。

最后，培养一种重视可观测性的文化。鼓励开发人员正确地为其代码添加监控工具，并在设计阶段考虑可观测性。这种主动的方法从长远来看会带来更易于管理和更具弹性的系统。

记住，有效的可观测性不是收集更多数据，而是获得可执行的见解。目标是快速理解和解决问题，预测潜在问题，并持续改进系统性能和可靠性。

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

关于 Kubernetes 的高可用性和灾难恢复，超越基础设施本身的思考至关重要。虽然强大的集群设置很重要，但真正的弹性来自于一个整体的方法，它考虑了您的应用程序、数据和团队流程。

故障通常以意想不到的方式出现。我见过这种情况，一个配置完美的混合云设置由于关键应用程序组件不可用而无法提供帮助。从基础设施到应用程序层，查看您的整个堆栈至关重要。

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

另一个关键因素是您团队的准备情况。我发现定期进行灾难模拟非常宝贵。它们可以帮助您发现技术设置和团队响应流程中的差距。令人惊讶的是，这些练习经常会发现您团队只需几个冲刺就能解决的意想不到的问题。

在 HA/DR 场景中，自动化是您的朋友，但它是一把双刃剑。虽然它可以加快恢复速度，但实施不当的自动化也可能加剧问题。平衡是关键。

最后，请记住 HA/DR 策略中的人为因素。清晰的沟通渠道和明确定义的角色在响应事件时可以产生巨大的影响。混乱和缺乏清晰度会给您的响应团队带来巨大的问题，因为他们试图使服务或平台恢复到稳定状态。

Kubernetes 架构师如何简化持续集成和持续交付 (CI/CD) 管道以提高交付效率？

简化 Kubernetes 部署的 CI/CD 管道可以实现高效、可靠的软件交付。我与各个组织的经验揭示了几种非常有效的策略。

GitOps 原则在 Kubernetes 环境中产生了显著的好处。Git 仓库是应用程序代码和基础设施配置的单一事实来源，从而实现一致、可审计和可重复的部署。这种方法与 Kubernetes 的声明式特性相符，简化了回滚和环境一致性。

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

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

金丝雀部署或特性标志等渐进式交付技术支持受控的推出。这些方法允许团队密切监控更改的影响，并在出现问题时快速回滚，从而降低生产环境中的风险。

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

Kubernetes 中的密钥管理需要仔细考虑。实施安全、动态的解决方案来存储和轮换敏感信息（如 API 密钥和密码）对于维护强大的安全态势至关重要。

当为其 CI/CD 管道实施可观测性时，团队会受益。捕获管道的全面日志、监控和跟踪有助于提供关键的可见性，从而能够快速识别和解决管道问题。 高性能组织将其 CI/CD 管道视为值得持续改进和投资的对象。这种思维方式推动了部署速度、可靠性和安全性方面的持续改进，从而跟上不断变化的业务需求和功能添加。

Kubernetes 架构师在跨集群扩展服务时应牢记哪些高级网络注意事项？

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

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

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

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

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

这些考虑强调了 Kubernetes 架构师需要超越单集群网络范例进行思考的必要性。成功的实施通常需要与网络工程团队密切合作，并深入了解 Kubernetes 网络原理和更广泛的企业网络概念。

Kubernetes 架构师如何有效地管理 Kubernetes 生态系统中的有状态应用程序和持久性存储？

我看到出现的一种模式是使用自定义控制器来处理特定的数据库或有状态应用程序。这些控制器可以自动化许多以前需要手动干预的复杂操作，例如扩展、备份，甚至某些灾难恢复方面。

持久性存储解决方案也取得了长足的进步。容器存储接口 (CSI) 是一项至关重要的发展，它提供了一种标准化的方法来将存储系统与 Kubernetes 集成。这为组织使用最适合其需求的存储解决方案（无论是在本地还是在云中）开辟了无限可能。

但是，需要注意的是，在 Kubernetes 中管理有状态应用程序仍然是一项复杂的任务。它需要仔细的规划，并且通常需要专门的知识。我看到团队通过将其有状态服务视为 Kubernetes 战略中的一等公民而取得成功，他们投入时间了解每个应用程序的具体要求，并相应地设计其基础设施。

我学到的关键教训是，Kubernetes 中的有状态应用程序没有一刀切的解决方案。成功来自于对应用程序需求和所选存储解决方案功能的深入了解。这是在利用 Kubernetes 的编排能力和尊重有状态工作负载的独特特性之间取得正确平衡的问题。

Kubernetes 架构师应该使用哪些策略来管理跨不同云提供商或本地环境的多个集群？

管理跨不同环境的多个 Kubernetes 集群让我想起了我在迪士尼工作室工作的那段时间，当时我们面临着在 350 多个应用程序之间协调工作负载的挑战。这段经历让我学习到了关于多集群管理复杂性的宝贵经验。

关键的见解在于，成功不在于将每个集群视为一个孤立的实体，而在于制定一个统一的策略，承认它们的独特特性。在管理跨不同环境的集群时，标准化变得至关重要——不仅是在您部署工作负载的方式上，而且是在您处理治理、安全性和操作的方式上。

通过我与CNCF最终用户项目的合作，我观察到组织如何应对这一挑战。最成功的组织首先建立明确的界限。他们根据数据主权、延迟要求和成本优化等因素确定哪些工作负载属于哪个位置。

一种特别有效的模式是将您的多集群策略视为一种产品。清晰的路线图、对开发和运维团队需求的深入了解以及基于反馈的持续迭代，共同创建了一个平台，使团队能够部署和管理应用程序，无论其位置如何。

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

我看到的最有趣的进展来自那些拥抱自动化部署及其整个集群生命周期的组织。他们自动化从初始集群配置到持续维护和最终退役的所有工作。这种方法有助于保持一致性并减少管理多个集群的运营负担。

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

Kubernetes架构师应该如何解决与集群生命周期管理和版本升级相关的问题？

集群生命周期管理代表了Kubernetes生态系统中更细致的挑战之一。跟上Kubernetes版本的发布以及企业环境的复杂性，需要仔细考虑升级策略。

发布周期影响堆栈的每一层——从核心基础设施到应用程序工作负载。成功的升级策略考虑到了这种连锁反应。开发团队调整他们的应用程序，运营人员学习新的功能和弃用功能，安全团队评估对安全模型的更改。

Kubernetes增强提案 (KEPs) 体现了这种管理变更的结构化方法。Kubernetes中的每个重要功能添加或修改都遵循此过程，为架构师提供对即将发生的更改的清晰可见性。KEPs详细说明了技术规范、动机、设计约束以及对整个生态系统的潜在影响。这种透明度允许架构师主动规划未来的升级并了解特定更改背后的原因。 发布规划需要在进度和稳定性之间取得平衡。跳过太多版本会导致技术债务和安全漏洞，而过于频繁地升级可能会使团队不堪重负并带来不必要的风险。了解这种动态有助于架构师设计可持续的升级策略。

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

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

维护完善的文档、一致且协作的Kubernetes基础设施的最佳技巧是什么？

Kubernetes中的文档不仅仅是捕获技术规范。根据我与SIG Docs合作的经验，我经历了与他们描述的基础设施一起发展的成功的文档策略。

有效的文档靠近代码。架构决策、权衡和未来的考虑为团队提供了维护和发展其基础设施的关键上下文。这种实践帮助团队了解当前状态和历史背景。

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

基础设施文档应该讲述一个故事。与其说是孤立的wiki页面或分散的README，不如说是充分的文档指导读者了解系统的演变。当遇到基础设施中不熟悉的部分时，团队应该了解其工作原理、存在原因以及解决的问题。 跨团队协作依赖于共享理解。定期的架构评审、事故回顾和技术讨论会产生宝贵的见解。记录这些讨论和决策有助于团队建立集体知识，避免重蹈覆辙。

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

Kubernetes路线图。CNCF的格局极其复杂。面向架构师和开发人员的未来1-2年的速查表？

云原生生态系统的优势在于其解决不同技术需求的有组织方法。架构师不必试图理解每一个项目，而应关注与其特定挑战相关的类别：

应用定义和开发包含用于构建云原生应用程序的工具和框架。这包括数据库、流平台、应用程序定义以及构成现代应用程序开发主干的持续集成/交付工具。

可观测性和分析工具提供对系统行为的洞察，帮助团队了解其生产环境中的应用程序。此类别包括监控、日志记录、跟踪和混沌工程工具，这些工具支持可靠的运营。

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

资源供应涵盖部署和维护云原生基础设施所需的工具，包括自动化、安全、密钥管理和镜像构建。这些工具帮助团队在不同的平台上建立一致、安全的环境。

运行时代表基础——容器运行时、存储和网络组件，这些组件使云原生基础设施成为可能。了解您的运行时需求有助于为所有其他类别中的决策提供信息。

CNCF技术监督委员会 (TOC) 和最终用户技术咨询委员会 (TAB) 分别通过技术咨询小组 (TAG) 和用户组提供指导。这些社区提供直接获取专业知识和实际经验的机会，帮助团队在每个类别中浏览选项。

每个组织的云原生旅程都不同。了解这些类别有助于团队更多地讨论他们的需求和挑战。参与相关的社区小组可以提供宝贵的见解和学习机会，让您探索适合您环境的解决方案。

来源：小雨科技频道