喜忧参半的 Kubernetes 生产之路

Posted 2021-04-16 K8sMeetup

 | 为  |  容  |  器  |  技  |  术  |  而  |  生  |

翻译：夏天

校对：灯神

生而知之者，上也；学而知之者，次也；困而学之，又其次也——孔子（公元前 551 - 479年）

孔子认为，得上等智慧靠天赋，不学而懂；得二等智慧靠学习，一学即懂；得三等智慧靠磨练，历经时移势易，艰难险阻之后才有领悟。今天这篇文章，展示了一群 K8S 实施人员在 Kubernetes 生产之路上习得智慧的苦辣酸甜。

我们在生产环境下运营 Kubernetes 已经有一段时间了，也与像 Global traffic，Black Friday 和 Christmas sales 这样的大公司有合作。这些公司都有严格的安全规则和多国协同工作的团队。我们 7 * 24 全天候为每一个公司管理这些集群。可以说我们就是客户专属的 SRE 团队。

这让我们有了一个独特视角，可以与大家分享我们经历过的一些尝试和挑战。有些很苦涩，但是有些因为一开始就站在巨人和其他人的肩膀上，进展得很顺利。然而无论苦涩还是开心，我们已经历过了，回首往事都是件很有意思的事。

安全性问题 

安全性是我们关注的重点，我们曾经参与编写了 Kubernetes CIS Benchmarks，现在与许多其他一些 CIS Benchmarks（AWS 和 Docker）标准保持一致。虽然 RBAC 在 Kubernetes 1.6 和 1.7 中都只是测试版，但经过测试我们最终确定使用 Kubernetes 1.7 这个版本。由于我们将所有基础架构组件托管在容器中，并且其中许多容器，例如 Calico Networking 作为 Kubernetes 管理的 pod 运行，所以“关闭特权容器”这条旧规则对我们来说是不可行的。（就像它不适用于大多数严肃的生产环境一样）

我们将 RBAC 和 Pod 安全策略（PSP）结合起来，通过限制扩展安全上下文 ( security contexts）的使用来解决这个问题。一开始，我们以为这是一个合理的解决方案，直到开始尝试，我们发现了一些小 bug（PSP 当时仍然处于 alpha 阶段）。此外，没有恰当的预设规则意味着之前几乎没有人使用过它。但这就是使用最新功能必须付出的代价。实践证明，它对我们来说非常有效，其中社区关键人物的帮助也起到了重要作用。

最终我们解决了这个问题。从那时起，每个集群都被完全加固了。甚至有客户使用 Calico 网络策略为不同团队根据 namespace 来限制容器对外流向 NFS 的流量。

其实，我们也有点讨厌安全扫描仪。所有集群 etcds 都完全加密，但在未加密的 EBS volume 上运行。理论上，这是没有问题的，因为所有的内容都是加密的。但是安全扫描仪会注意到未加密的 EBS，并且会一直提醒你在安装之前设置是不安全的。这是令人讨厌的小问题之一。如果你知道 etcd，你肯定知道它的实时迁移有多麻烦。

更新问题

我们将基础架构视为代码，这意味着我们有完整的 CI / CD 来管理基础架构组件，尤其是我们自己构建的组件。实际上，我们有一个补丁系统和一些小的和主要的更新，针对不同部署都有不同规则。但随着时间的推移，我们了解到其实大部分规则都是为了确保部署。

现在我们的合同中甚至有一部分内容是，如果你的集群已经超过三个月没有更新，我们的管理将不再适用。这是由一位客户提出的，现在他自己就可以告诉他的团队集群需要升级了，不然就麻烦了。这个内容特别有用，因为很多客户团队都不会特别重视更新工作，他们只会懵懂地说：“它还在工作呢，为什么要更新？”

通用电气 CEO Jack Welch 曾说过：“我一直相信，当一个机构内部的变化速度比外面的变化速度慢时，它的“死期”就在眼前，唯一的问题是什么时候。”

这真是一个问题。我们发现大部分生产问题都存在于比较老的集群中。我们会针对所有客户集群中的每个生产事件进行复盘，直到找到并修复根本问题，随后把经验推广到所有客户集群中。我们确定一定以及肯定我们只能有一种产品，就是用户喜欢的那一种。也许客户作为个体看到的问题会很少，但我们要让他们跟我们一起升级。

安装问题

试图预测未来，就像在暗夜开着车奔驰在没有路灯的乡间小路上，还一直往后窗看。——Peter F. Drucker（1909-2005）

我们可以在两小时内在 AWS 上完成整个 Giant Swarm 安装，在 Azure 上也差不多是这个时间，因为我们最近在 Azure 上推出了适用于生产的 Kubernetes。我们的客户可以创建任意数量的集群。我们的优势在于，我们可以在本地完成同样的任务，但可悲的是我们仍然不得不说，在本地安装设备需要一些时间。对于这件事，我总是开玩笑说：“安装大约需要六个小时到六个月之间……那是不可能的。”

内部部署的问题关键是他们的内部环境都是不同的。比如 VPN 如何工作？跳转主机怎么样？服务器是否正确联网？有 ILO access 吗？对我们的许多客户来说，内部部署具有实际价值，但客户情况不同，内部部署就会完全不同，不能复制。如果你没有集成 Load Balancer API（你可以根据规则获得自己的 F5 网络 BIG-IP space 吗？），也没有适当标准化和支持 Kubernetes 的存储解决方案，那就更一言难尽了。我们连接过 iSCSI，这对 Docker 和 NFS 来说有一些稳定性问题，并不能一直表现良好。现在，我们正在考虑 EMC Ipsilon 和 Rex-Ray 或 Rook，但它们都有各自的问题。如果有一个云服务提供商能在上游提供一个好的动态提供商，那就可以说是很完美了。

负载测试问题

讲讲我们曾与客户进行的一次负载测试吧。在测试一开始我们就吓了一大跳，因为当进入负载测试时，什么都还没有做，集群就集体死亡了。尽管如此，我们的客户团队仍然习惯于旧的工作方式，他们表示已经知道“负载测试失败”这个结果了，并说他们以后会再测一次……

一开始，我们不知道如何解决这个问题，直到我们刨根问底，揪出问题所在。首先，负载测试配置错误，并没有产生 100,000 个并发用户。相反，它每个地点产生了 100,000 个并发用户，由于使用了三个源地点，导致出现了 300,000 个并发用户。然后我们继续深“挖”，发现在这个小集群中使用的 EC2 机器有 1Gbit 网卡，几秒钟后它们就饱和并死亡，流量从未到达集群层面。

缩放集群完成后，问题就解决了，它工作得很好。

身份验证问题

从前有 ___。每天， ___。有一天 ___。因为，___。因为，___。直到最后___。——皮克斯讲故事经典套路

我们的设置默认为证书身份验证，由我们的 API 和 cert-operator 自动执行，后端基于 Vault。现在，很多公司都在用 Active Directory，它确实挺好用。我们希望让客户能通过它来进行身份验证。

我们想通过 Kubernetes 支持的 OIDC 接口进行集成。所以首先，我们需要客户升级到比较新版本的 ADFS，因为旧版本不提供任何 OIDC 端点。但是，当我们开始测试时，就遇到了自签名证书的问题，所以我们开始用 Dex 进行测试。经过一段时间后，我们克服了这个问题，但是我们仍然遇到了 OIDC 端点的扩展 claims/scopes 问题。而且其实 Dex 并不关心用户体验 （如果你没有运行 Tectonic 的话）。然后我们灵光一现，决定尝试第三条路径：Azure AD。

客户在其本地 ADFS 和 Azure AD 之间进行了同步。通过与我们在微软的朋友交谈（很高兴可以直接与他们在我们的 Slack 中交流）并检查一些上游文档，我们发现这是一个值得尝试的解决方案。借助微软的一些帮助，解决了上游文档中的一些开放问题，迅速有了思路。从那时起，我们所有客户的集群都预先设置了 Azure AD 身份验证。

共同成长

正如上面这些故事讲的那样，在 Kubernetes 生产的道路上，需要克服技术和组织方面存在的很多问题和挑战。有些来得早，有些来得晚，有些因为规模，有些因为资源压力。如果我们只与客户建立最简单的供应商与客户的关系，就不会有这些喜忧参半的过往。我们很高兴能与我们的客户建立真正的伙伴关系，让我们能够陪伴彼此，共同成长。

我们希望通过分享我们的经验，可以让你感受下我们日常工作的苦乐，让你也开始尝试与客户建立这样的战友感情。我想，等下次你见到我们时，我们会讲更多 Kubernetes 生产战线上奋斗的故事给你听吧。

原文链接：

https://thenewstack.io/the-bittersweet-road-to-kubernetes-production/

推荐阅读：

END

赶紧扫描下方二维码关注「Kubeflow 社区」。「Kubeflow 社区」陪你解锁 Kubeflow 新技能，让 Kubernetes 上的机器学习变得更简单！

点击“阅读原文” 直接看 4 月 22 日 Kubeflow Meetup 「杭州站」首秀回顾！