我们需要专职 Kubernetes 工程师吗？

2022 年 7 月 30 日 InfoQ

作者 | Jenn Gile

译者 | 王强

策划 | 褚杏娟

伴随着技术领域的每一次重大变革，我们都会看到很多拥有新头衔的新职业。如今，基础设施和应用程序部署领域的最大变革是 Kubernetes 被广泛采用。我们随之看到的最新职位是“Kubernetes Operator”，K8s 操作员（不要把它与 Kubernetes 编程操作符这个构造搞混了，后者是 Kubernetes 中用于管理资源的一个软件扩展）。由于“操作员”这个词在 Kubernetes 中有多种含义，为简单起见，我们将在后文中使用“Kubernetes 工程师”这个说法。

来自 Kubernetes Gateway API 站点的一张示意图，将 Kubernetes 工程师描述为负责管理网关功能的“集群操作员”。Gateway API 仍处于 alpha 阶段，但这个模型同样适用于使用其他入站 - 出站选项（例如 Ingress API）的 Kubernetes 实现。

提供线索的编辑用于在 Kubernetes 中部署 L4 和 L7 路由的一组现代 API，

图片来源：https://gateway-api.sigs.k8s.io/

Kubernetes 工程师通常由其他头衔的工程师担任，例如 Web 应用的站点可靠性工程师，或老派 IT 部门的系统管理员等。云原生组织和团队可能会将这个岗位作为平台运营或云架构师职位的一部分，但越来越多运行现代应用或走云原生之路的公司都需要专门的 Kubernetes 专家。

这一变化可以追溯到上次大型基础设施的变革浪潮时期。当时，虚拟化技术取代了裸机，企业争相聘请虚拟化工程师来操作 VMware 和 Citrix 虚拟化平台。

在这次变革中，Kubernetes 工程师需要经历一个非常陡峭的学习曲线。Kubernetes 一词经常令人困惑，同样的网络或应用术语在 Kubernetes 世界中可能含义不同。同时，还产生了许多较新的术语。例如，微服务与以 Kubernetes 作为主要部署模式的实现密切相关；服务网格是一种全新的基础设施，旨在帮助团队安全可靠地管理和交付微服务，它基本上总是跟 Kubernetes 关联在一起。

未来，几乎每个追求 Kubernetes 的组织都需要符合 Kubernetes 工程师职位描述的人才。如果他们还没有这样的雇员，那么他们很快就会需要一个。那么，这个职位对企业意味着什么、企业如何通过这个岗位来满足自己的需求呢？

基本职责

Kubernetes 工程师的首要任务是确保 Kubernetes 在其所在组织正常运行。该岗位的职责通常包括：

安全性。Kubernetes 并非开箱即用的。Kubernetes 工程师的工作是锁定 Kubernetes 并对其进行配置，以便开发人员在集群上部署他们的应用程序时，不必要的情况下避免暴露各种 API、允许未经授权的流量等等。
性能和可观察性。虽然 Kubernetes 因其众多弹性特点而出名，但对其进行性能调优需要知识全面。比如，即使在 CPU 或内存层资源不足的情况下，Pod 可能看起来也是在正常运行，结果却是导致了延迟、丢包或重复重启。Kubernetes 工程师的工作是通过查看服务和流量指标来寻找比“Pod 是否启动并正常通过流量？”更细微的问题，进而识别问题并对性能进行调优。
网络。Kubernetes 网络不同于传统网络，Kubernetes 网络多路复用第 4 层和第 7 层，并通过 API 运行一切。Kubernetes 网络需要工程师管理南北和东西流量，并调整维护关键服务所需的内部网络要求。许多流量管理工具是 Kubernetes 独有的——例如，Ingress 控制器是专用于 Kubernetes 的组件，它是高级 Ingress 约定（如标头重写和流量整形）所必需的。Kubernetes 工程师应该精通这种新颖且差异化的网络环境，并准备好为 Kubernetes 设置和管理网络管道。
基础设施。组织可以选择自己运行 Kubernetes，或者使用托管服务。不管是哪种情况，Kubernetes 工程师的任务都是确保一切都能以正确的方式运行、获得正确的补丁，并有足够的资源来运行应用程序。可以这么说，Kubernetes 工程师很少有服务器机柜的钥匙，但他们通常能够判断 CPU、内存和其他物理元素是否出现了故障或不足。使用托管 Kubernetes 环境时，Kubernetes 工程师可以确保服务已配置并能根据需要进行扩展，而不会过度配置。

工作范围

Kubernetes 工程师角色的工作范围取决于三个因素：

企业基础设施规模
企业在 Kubernetes 采用曲线上的位置
Kubernetes 部署的复杂性

如果你是一家初创公司，只在小型基础架构上运行数量有限的应用程序，“Kubernetes 工程师”角色可能就只是某人工作的一部分内容而已，甚至可能仅限于在托管 Kubernetes 服务（例如 Google Kubernetes Engine）上部署容器和应用。此类服务抽象出了物理硬件和网络层，并能很好地处理扩展、基本安全性和基本网络管理需求，只需要非常少的手动工作。

但是，企业在决定一个兼职的 Kubernetes 工程师是否够用之前，需要考虑一点：基础设施越大，移动部件的数量越多，工作就越复杂和耗时。

下图是一个非常简单的视图。从广义上讲，在裸机上管理和操作 Kubernetes 比使用托管服务复杂得多，但是使用托管服务意味着对物理层的可见性为零，并且会增加一些延迟。非常多的问题、冲突和性能问题都可以追溯到多租户基础架构上。如果企业认为云端有很多“嘈杂的邻居”不是什么好事情，那就想象下它们在托管 Kubernetes 服务中的样子吧！这一逻辑同样适用于驻留在大型容器和更高容量 Kubernetes 集群上的大型应用程序。

除了基础设施问题之外，企业还需要考虑将运行多少个集群，以及每个集群中有多少个 pod 和节点。

多集群 Kubernetes 要复杂得多，因为它需要对安全性、网络、API 和流量管理进行额外的定制，还需要管理和链接多个 Ingress 控制器（稍后会详细介绍），并确定是否需要运行多个集群以进行热故障转移（很昂贵），企业也可以选择容忍备份集群从头开始启动带来的一些停机时间。

对于单个集群和数量有限的 pod 和服务，可观察性和故障排除远没有那么复杂。一旦企业必须对运行在十几个 Pod 上的多个服务进行故障排除并观察它们的性能，那么工作就会变得非常繁重。

那么，Kubernetes 工程师是负责部署应用还是只管理基础设施？这需要具体情况具体分析。

在大型组织中，Kubernetes 工程师的职责主要是保障 Kubernetes 环境的安全和正常运行，而不是编写 YAML 清单或监督应用程序部署工作，他们通常与平台运维团队（或作为该团队的成员）密切合作，更多的是设置受信任的服务和 API 目录，或设置经过审查以处理 Kubernetes 设置的容器注册表。

较小的组织或团队需要对 Kubernetes 投入更多精力，这里的 Kubernetes 工程师角色可能与 DevOps 团队重叠，并要负责与应用程序开发人员合作监督部署流程。

什么时候需要
Kubernetes 工程师

一旦确定 Kubernetes 将在应用程序基础架构中发挥重要作用，企业就要开始考虑聘请一名 Kubernetes 工程师，或者至少是一名具有 Kubernetes 专业知识、并有实践经验的应用开发人员。

企业如果在开始部署应用之前，遵循“构建坚如磐石的、以 Kubernetes 集群为基础的现代应用程序设计模式”（在 F5 NGINX，这种模式被称为“集群输出”），那么你就需要尽快招募一名 Kubernetes 工程师。

在 Kubernetes 中出现的问题有很多，相关的风险很高，而架构、服务设计和其他缺陷可能不会在“上线”后自己暴露出来。出于这个原因，在采用的早期就发展自己的 Kubernetes 工程技术是明智之举。

Kubernetes 认证是否必要？

虽然成为一名认证的 Kubernetes 管理员（CKA）绝对是一个加分项，但有很多人是以更老派的方式——通过来之不易的经验和教训来学习如何运维 Kubernetes 集群。事实上，我们认为执行特定任务的经验比 CKA 证书更有用，原因有二：

Kubernetes 比任何认证课程都复杂得多。
一旦构建了所有服务、配置了网络并设置了安全性，任何 Kubernetes 部署都会变得非常复杂。

当然，经验和认证都有是两全其美的。在花时间亲身体验 Kubernetes 之后再去考 CKA 是一个很好的策略。

另外一个问题是：Kubernetes 工程师需要高级 Kubernetes 网络专业知识吗？答案是不必要。

Kubernetes 工程师需要对 Kubernetes 网络概念有深入了解，并具备配置 Ingress 控制器、多集群网络以及管理东西和南北流量的经验，但不一定需要更高级的容器网络接口（CNI）应用经验。这些应用旨在提供的东西更像是 Kubernetes 中的网络管理和网络安全层。对于现在大多数 Kubernetes 用例来说，CNI 是多余的。所以，Kubernetes 工程师有这方面的技能当然更好，没有也无所谓。

原文链接：

https://www.cncf.io/blog/2022/03/03/an-emerging-job-kubernetes-engineer/

点击底部阅读原文访问 InfoQ 官网，获取更多精彩内容！

在中国 ToB 市场选一个对的供应商太难了

搞不定移动端性能，全球爆火的 Notion 从 Hybrid 转向了 Native

离开谷歌的副作用：外面很难找到这么好用的开发工具