构建Kubernetes 3年，我们得到的经验教训
极客时间编辑部
讲述：丁婵大小：8.14M时长：05:56
你好，欢迎收听极客视点。
最近，LinkedIn 工程师科马尔·文卡特什·甘尼山（Komal Venkatesh Ganesan）介绍了他们在 2017 年开始构建 Kubernetes 的经验。他表示 Kubernetes 最终使他们变得更轻松，但是这个过程很艰难，不仅让他们的技能和工具有了彻底的转变，还让他们的设计和思维也得到了彻底的转变。
极客视点摘录了其中关于 Java 应用、Kubernetes 生命周期管理、构建和部署这三方面的经验，分享给你，希望对你有所帮助。
1. Java 应用程序的奇怪案例
在微服务和容器化方面，工程师倾向于避免使用 Java，这主要是由于 Java 臭名昭著的内存管理。但是，现在情况发生了改变，过去几年来 Java 的容器兼容性得到了改善。毕竟，大量的系统（例如 Apache Kafka 和 Elasticsearch）在 Java 上运行。
回顾 2017-2018 年，我们有一些应用程序在 Java 8 上运行。这些应用程序通常很难理解像 Docker 这样的容器环境，并因堆内存问题和异常的垃圾回收趋势而崩溃。我们了解到，这是由于 JVM 无法使用 Linuxcgroup 和 namespace 造成的，而它们是容器化技术的核心。
但是，从那时起，Oracle 一直在不断提高 Java 在容器领域的兼容性。甚至 Java 8 的后续补丁都引入了实验性的 JVM 标志来解决这些问题，但是，尽管做了所有的这些改进，不可否认的是，Java 在内存占用方面仍然声誉不佳，与 Python 或 Go 等同行相比启动速度慢。这主要是由 JVM 的内存管理和类加载器引起的。
现在，如果我们必须选择 Java，请确保版本为 11 或更高。并且 Kubernetes 的内存限制要在 JVM 最大堆内存（-Xmx）的基础上增加 1GB，以留有余量。也就是说，如果 JVM 使用 8GB 的堆内存，则我们对该应用程序的 Kubernetes 资源限制为 9GB。
2. Kubernetes 生命周期管理：升级
Kubernetes 生命周期管理（例如升级或增强）非常繁琐，尤其是如果已经在裸金属或虚拟机上构建了自己的集群。对于升级，我们已经意识到，最简单的方法是使用最新版本构建新集群，并将工作负载从旧版本过渡到新版本。节点原地升级所做的努力和计划是不值得的。
Kubernetes 具有多个活动组件，需要升级保持一致。从 Docker 到 Calico 或 Flannel 之类的 CNI 插件，你需要仔细地将它们组合在一起才能正常工作。虽然像 Kubespray、Kubeone、Kops 和 Kubeaws 这样的项目使它变得更容易，但它们都有缺点。
我们在 RHEL 虚拟机上使用 Kubespray 构建了自己的集群。 Kubespray 非常棒，它具有用于构建、添加和删除新节点、升级版本的 playbook，以及我们在生产环境中操作 Kubernetes 所需的几乎所有内容。但是，用于升级的 playbook 附带了免责声明，以避免我们跳过子版本。因此，必须经过所有中间版本才能到达目标版本。
关键是，如果你打算使用 Kubernetes 或已经在使用 Kubernetes，请考虑生命周期活动以及解决这一问题的方案。构建和运行集群相对容易一些，但是生命周期维护是一个全新的体验，具有多个活动组件。
3. 构建和部署
在准备重新设计整个构建和部署流水线之前，我们的构建过程和部署必须经历 Kubernetes 世界的完整转型。不仅在 Jenkins 流水线中进行了大量的重构，而且还使用了诸如 Helm 之类的新工具，策划了新的 git 流和构建、标签化 Docker 镜像，以及版本化 Helm 的部署 chart。
你需要一种策略来维护代码，以及 Kubernetes 部署文件、Docker 文件、Docker 镜像、Helm chart，并设计一种方法将它们组合在一起。
经过几次迭代，我们决定采用以下设计。
应用程序代码及其 helm chart 放在各自的 git 存储库中。这使我们可以分别对它们进行版本控制（语义版本控制）。
然后，我们将 chart 版本与应用程序版本关联起来，并使用它来跟踪发布。
对于我们未构建或修改代码的系统应用程序，例如 Apache Kafka 或 Redis ，工作方式有所不同。也就是说，我们没有两个 git 存储库，因为 Docker 标签只是 Helm chart 版本控制的一部分。如果我们更改了 Docker 标签以进行升级，则会升级 chart 标签的主要版本。
你是否一定需要 Kubernetes？
三年过去了，我们每天仍然在继续发现和学习新知识。它是一个复杂的平台，具有自己的一系列挑战，尤其是在构建和维护环境方面的开销。它将改变你的设计、思维、架构，并需要提高技能和扩大团队规模以适应转型。
但是，如果你在云上并且能够将 Kubernetes 作为一种“服务”使用，它可以减轻平台维护带来的大部分开销。
今天，我们意识到，你需要问自己的第一个问题是“你是否一定需要 Kubernetes？”这可以帮助你评估所遇到的问题以及 Kubernetes 解决该问题的重要性。Kubernetes 转型并不便宜，为此支付的价格必须确实证明“你的”用例的必要性及其如何利用该平台。如果可以，那么 Kubernetes 可以极大地提高你的生产力。
以上就是今天的内容，希望对你有所帮助。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(1)
- 最新
- 精选
piboye云原生的技术，自己运维太复杂，云厂商会有意让你使用他们的产品😅2
收起评论