三年的Kubernetes生产经验，我们学会了什么
发布时间：2021-12-07 16:46:00 所属栏目：云计算 来源：互联网
导读：我们在2017年开始创建我们的第一个Kubernetes集群，当时版本为1.9.4。我们有两个集群，一个是运行在裸金属RHEL虚机上，一个是跑在AWS EC2上。 如今，我们的Kubernetes基础设施由400多台分布在多个数据中心的虚机组成。该平台承载了很多高可用的关键任务的应用
|
我们在2017年开始创建我们的第一个Kubernetes集群，当时版本为1.9.4。我们有两个集群，一个是运行在裸金属RHEL虚机上，一个是跑在AWS EC2上。 如今，我们的Kubernetes基础设施由400多台分布在多个数据中心的虚机组成。该平台承载了很多高可用的关键任务的应用和系统，以管理一个拥有近4000万台活跃设备的大规模实时网络。 Kubernetes最终使我们的生活变得更简单，但这是一个艰难的过程。不仅仅是我们的技能和工具集，我们的设计和思维都发生了彻底的转变。我们必须采用多种新技术，并大量投入，以提升团队和基础设施的能力。 回顾过去三年Kubernetes在生产环境的经历，我们总结了一些重要的经验教训。 Java应用上奇怪的问题 谈到微服务和容器化，工程师们倾向于避免使用Java栈，主要是因为它臭名昭著的内存管理。不过现在情况发生了变化，多年来Java的容器兼容性得到了改善。毕竟，像Apache Kafka和Elasticsearch这类无处不在的系统都在Java上运行。 在2017-18年，我们有一些应用运行在Java 8版本上。它们通常难以理解像Docker这样的容器环境，且常因堆内存问题和非寻常的垃圾回收机制而崩溃。我们了解到，这些都是由JVM的问题以及Linux的cgroups和namespaces引起，而这些都是容器化技术的核心点。 不过从那时起，Oracle就开始持续改善Java在容器领域的兼容性问题，甚至Java 8的后续补丁也引入了实验性的JVM标志XX:+UnlockExperimentalVMOptions和 XX:+UseCGroupMemoryLimitForHeap来解决这些问题。 但是尽管有了这些改进，不可否认的是，与Python或Go等同行相比，Java仍然在内存占用和启动时间慢等方面存在坏名声。这主要是由JVM的内存管理和类加载器造成的。 现在，如果我们不得不选择Java，那么我们要确保其是在Java 11版本或以上。我们的Kubernetes内存限制是在JVM的最大堆内存(-Xmx)的基础上配置多1GB用于预留。例如，如果JVM使用8GB用于堆内存，那么我们为该应用在Kubernetes上的资源限制将为9GB。有了这个后，应用稳定了很多。 Kubernetes生命周期升级 Kubernetes生命周期管理例如升级或特性增强过程是很麻烦的，尤其是当你的集群构建在裸金属设备或VM上。对于升级，我们意识到最简单的方法就是使用最新的版本搭建一个新的集群并将工作负载从就集群迁移到新集群。为原地节点升级所做的努力和规划是不值得的。 Kubernetes有多个活动组件需要配合升级。从Docker到CNI插件，例如Calico或Flannel，你必须小心翼翼将其拼凑在一起以使其正常工作。虽然有像Kubespray，Kubeone，Kops，Kubeaws这类工具使它更容易，但它们都有各自的短板。 （编辑：随州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
