喜忧参半的 Kubernetes 生产之路
技术
作者:Oliver Thylmann
译者:夏天
2018-04-28 02:26

生而知之者,上也;学而知之者,次也;困而学之,又其次也——孔子(公元前 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/

127 comCount 1

11234123

12341234123