k8s1.6伸缩性升级，支持处理5000 Node 和 15 万个 Pod-低调大师

k8s1.6伸缩性升级，支持处理5000 Node 和 15 万个 Pod

2018-12-14 581

上个夏天，我们分享了 Kubernetes 的伸缩性更新，经过一番努力，我们自豪的宣布 Kubernetes 1.6 能够处理 5000 个节点的集群和 15 万个 Pod 了；另外即使在这种负载规模下，端到端的 Pod 启动速度依然优于 2000 节点规模的 1.3 版本的 Kubernetes 集群，API 调用的延迟依然满足 1 秒的 SLO。

本文中我们会讨论到

性能测试的指标和结果
提高性能的改进
未来在伸缩性方面的发展计划

XX 节点的集群意味着什么？

现在 Kubernetes 1.6 已经发布，那么当我们说到支持多少个节点的集群的时候，我们到底在说什么？前文说过，我们有两个性能相关的服务水平目标（SLO）：

API 响应性：99% 的 API 调用应该在一秒之内返回。
Pod 启动时间：99% 的 Pod 及其容器（已拉取镜像）在五秒之内完成启动。

跟以前一样，集群规模是可以超过 5000 节点的，但是会引起性能下降，可能无法满足 SLO 要求。

我们知道 SLO 的限制。还有很多我们没有覆盖到的系统因素。例如，新 Pod 启动之后，需要多久才能通过服务 IP 进行访问？这个数据我们就没有测量。如果你在使用大规模 Kubernetes 集群过程中，还有没有被我们的 SLO 覆盖的性能需要，请联系 Kubernetes 的伸缩性小组，让我们可以帮助你进一步理解 Kubernetes 是否能够满足你的负载需求。

接下来， Kubernetes 的伸缩性相关的最高优先级任务就是清晰一下对于支持 XX 节点规模的集群的定义：

强化现有的 SLO。
加入更多的 SLO（覆盖 Kubernetes 相关的更多方面，包括网络）

Kuernetes 1.6 的性能指标

那么在 Kubernetes 1.6 中，大规模集群到底怎样呢？下图显示了 2000 和 5000 节点的集群规模下的端到端的 Pod 启动时间。另外我们还加入了之前性能测试中发布过的 Kubernetes 1.3 下 2000 节点规模集群的相应指标来作对比。如图所见，两种规模的 Kubernetes 1.6 集群的 Pod 启动延迟都优于 2000 节点规模的 Kubernetes 1.3 集群。

接下来的这种图展示了 5000 节点规模的 Kubernetes 1.6 集群的 API 响应时间。所有的百分位数都少于 500 毫秒，而且 90 百分位数下低于 100 毫秒。

如何达成现有的性能目标？

过去的九个月中（从上次的伸缩性博客开始），Kubernetes 有很多性能和伸缩性的改进。本文中会谈谈两个最大的变化，并会列出一些其他的改动。

etcd v3

在 Kubernetes 1.6 中，缺省的存储后端从 etcd v2 升级到了 v3。这一工作从 1.3 的发布周期就开始了。为什么花了这么长的时间呢？

第一个稳定的支持 v3 API 的 etcd 发布于 2016 年 6 月 30 日。
新 API 是和 Kubernetes 团队合作设计的，以满足 Kubenretes 的功能和伸缩性需求。
几乎在 etcd v3 发布的同时，就完成了 Kubernetes 的集成——事实上，CoreOS 就是使用 Kubernetes 作为 etcd v3 API 的概念验证来使用的。

我们有很多做出这一变化的理由，下面列举一些最重要的：

从 v2 到 v3 的不向后兼容的升级，是一个巨大的变化，这是一个艰难的决定。我们在九月份发现，如果我们继续使用 etcd v2 的话，是无法负载 5000 节点的集群规模的。etcd v2 中的 watch 实现是一个主要障碍。在 5000 节点规模的集群中，我们每秒需要向同一个 watcher 发送至少 500 个 watch 事件，这在 v2 中是不可能的。

kubernetes/32361: https://github.com/kubernetes/kubernetes/issues/32361 里面包含了一些这方面的讨论。

在有了升级到 etcd v3 的动机之后，我们开始进行测试，过程中发现了一些问题。除了 Kubernetes 中出了一些小 Bug 之外，我们还向 etcd v3 的 watch 实现提出了更高的性能要求（etcd v2 中我们遇到的主要性能瓶颈）。这导致了 etcd 3.0.10 的补丁发布。
做出这一变化之后，我们确信新的 Kubernetes 集群能够使用 etcd v3。但是还有迁移现有集群的问题。为了自动实现迁移过程，对 CoreOS 的 etcd 升级工具进行了详尽的测试，并且做出了回滚方案。

最终我们确信这一方案是可靠的。

数据格式切换为 protobuf

在 Kubernetes 1.3 中，我们在 Kubernetes 中启用了 protobufs 作为组件通讯的数据格式（作为 JSON 的补充）。这给我们带来巨大的性能提升。

虽说技术上我们已经做好了准备，但我们还在 etcd 存储中使用了 JSON，这一变更的延迟，直接原因就是 etcd v3 的迁移。因为在 etcd v2 中我们无法使用二进制格式存储（只能用 base 64 编码来勉强实现），而在 etcd v3 中就可以了。所以迁移到 etcd v3 能够避免一些不必要的数据转换，最终我们决定等待 etcd v3 的迁移完成后，才切换到 protobufs。

其他优化

我们在 Kubernetes 的最近三次发布中做出了几十项优化，包括：

调度器优化（ 5-10 倍的调度吞吐）
优化控制器设计，降低了 controller-manager 的资源消耗

参见：https://github.com/kubernetes/community/blob/master/contributors/devel/controllers.md

对 API Server 的部分操作进行优化（转换、深度复制、patch）
降低 API Server 的内存占用（显著的降低了 API 调用的延迟时间）

需要强调的是，近期的几个发布中的优化工作，以及这个项目的整个历史，都是 Kubernetes 社区很多公司和个人通力协作的结果。

下一步

经常有人问，我们到底要把 Kubernetes 的伸缩性提高到何种程度。目前我们还没有在未来版本中把集群规模提高到 5000 节点以上。如果超过 5000 节点，我们建议采用 federation 来结合多个 Kubernetes 集群。

当然并不是说我们要停止对伸缩性和性能的追求。正如开篇所言，我们的最高优先级工作是保证目前的 SLO 并扩展 SLO 到其他系统，例如网络。这些工作都已经在伸缩性 SIG 中启动，我们在 SLO 的定义上已经取得了长足的进步，这些工作将在未来的几个月中逐步完成。

本文转自中文社区-k8s1.6伸缩性升级，支持处理5000 Node 和 15 万个 Pod

微信关注我们

原文链接：https://yq.aliyun.com/articles/679605

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

容器编排之Kubernetes1.6.1安装与配置

在经历了几年混乱的职业生涯之后，初步把未来延伸领域定位在容器云方向。区块链系列我还会继续写下去，且可能只会关注Hyperledger。云计算是最近几年来火热的技术领域，不同于其他，他没有固定的行业领域限制，他只是基础设施。任何基建于计算机上的服务，在达到一定规模后，都可应用云计算解决方案使硬件资源高效利用，统一开发运维，提高服务可靠性，降低企业支出等等。近两年火热的大数据、人工智能等都离不开背后计算集群的支持。拥抱云计算，拥抱未来。且说到云计算，外行人都会觉得很高大上，其实我觉得更多的是拿来主义，就是将一系列开源软件按照公司的业务架构搭配起来，大部分的工作其实是熟悉开源软件，解决他们的坑，顺便反馈开源社区，促进其发展。云计算也是有领域划分的，从物理机–>虚拟机–>容器技术的发展，孵化出了openstack、docker，kubernetes等这样的开源项目，openstack使得物理机到虚拟机的转变变的简单，而docker的出现，更是将这种简单极致化，将云计算推向容器云阶段。而如何将docker的容器在集群的规模上高效的管理，则是kubernetes出现的源动力。废...

2018-12-15

499

很多用户都有自己的域名区域，并且希望能够集成到 Kubernetes DNS 的命名空间去。例如混合云用户可能希望能在集群内解析他们内部的 “.corp” 。其他用户用户可能有一个受非 Kubernetes 管理的服务发现系统（例如 Consul）。我们在 Kubernetes 1.6 中推出了新功能，可配置私有 DNS 区域（通常称为存根域）以及外部的上级域名服务，本文将会讲解如何使用这一功能。 Kubernetes 目前在 Pod 定义中支持两个 DNS 策略：Default和ClusterFirst，dnsPolicy缺省为ClusterFirst：如果dnsPolicy设置为Default，那么域名解析配置会从 Pod 所在节点继承而来。注意，本文所述功能在dnsPolicy设置为Default时无效。如果dnsPolicy设置为ClusterFirst，DNS 查询会被发送到 kube-dns 服务。kube-dns 服务负责相应以集群域名为后缀（例如.cluster.local）的查询。其他的域名查询（例如 www.kubernetes.io ）会被转发给来自节点定义...

2018-12-15

686

资源下载

更多资源

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。