关于 Kubernetes 规划的灵魂 n 问

做者 | 易立 阿里云资深技术专家

导读：Kubernetes 已经成为企业新一代云 IT 架构的重要基础设施，可是在企业部署和运维 Kubernetes 集群的过程当中，依然充满了复杂性和困扰。

阿里云容器服务自从 2015 年上线后，目前托管着上万的 K8s 集群来支撑全球各地的客户。咱们对客户在规划集群过程当中常常会碰见的问题，进行一些分析解答。试图缓解你们的“选择恐惧症”。

如何选择 Worker 节点实例规格？

裸金属仍是虚拟机？

在 Dimanti 2019 年的容器调查报告中，对专有云用户选择裸金属服务器来运行容器的主要缘由进行了分析。

1. 选择裸金属服务器的最主要缘由（超过 55%）是：传统虚拟化技术 I/O 损耗较大；对于 I/O 密集型应用，裸金属相比传统虚拟机有更好的性能表现；

2. 此外近 36% 的客户认为：裸金属服务器能够下降成本。大多数企业在初始阶段采用将容器运行在虚拟机的方案，可是当大规模生产部署的时候，客户但愿直接运行在裸金属服务器上来减小虚拟化技术的 license 成本（这也常被戏称为“VMWare 税”）；

3. 还有近 30% 的客户由于在物理机上部署有更少的额外资源开销（如虚拟化管理、虚拟机操做系统等）；还有近 24% 的客户选择的缘由是：能够有更高的部署密度，从而下降基础设施成本；

4. 超过 28% 的客户认为，在物理机上能够更加灵活地选择网络、存储等设备和软件应用生态。

在公共云上，咱们应该如何选择呢？2017 年 10 月，阿里云“神龙架构”横空出世。弹性裸金属服务器（ECS Bare Metal Instance）是一款同时兼具虚拟机弹性和物理机性能及特性的新型计算类产品，实现超强超稳的计算能力，无任何虚拟化开销。阿里云 2019 年 8 月重磅发布了弹性计算第六代企业级实例，基于神龙架构对虚拟化能力进行了全面升级。

• 基于阿里自研神龙芯片和全新的轻量化 Hypervisor - 极大减小虚拟化性能开销。基于阿里云智能神龙芯片和全新的轻量化 VMM，将大量传统虚拟化功能卸载到专用硬件上，大大下降了虚拟化的性能开销，同时用户几乎能够得到全部的宿主机 CPU 和内存资源，提升整机和大规格实例的各项能力，尤为是 I/O 性能有了大幅度提高；

• 使用最新第二代英特尔至强可扩展处理器 - E2E 性能提高。使用最新一代 Intel Cascade Lake CPU, 突发主频提高至 3.2GHz, 各场景 E2E 性能大幅提高，并在深度学习的多种场景有数倍的提高；

• 给企业级场景带来稳定和可预期的表现 - 全球最高水准 SLA。针对软硬件优化以及更加实施更细致的 QoS 手段，给企业级客户的负载提供更稳定可预期的性能。

通常而言建议：

• 对性能极其敏感的应用，如高性能计算，裸金属实例是较好的选择；
• 若是须要 Intel SGX，或者安全沙箱等技术，裸金属实例是不二选择；
• 六代虚拟机实例基于神龙架构，I/O 性能有了显著提高，同时有更加丰富的规格配置，能够针对自身应用需求灵活选择，下降资源成本；
• 虚拟机实例支持热迁移，能够有效下降运维成本。

阿里云 ACK K8s 集群支持多个节点伸缩组（AutoScalingGroup），不一样弹性伸缩组支持不一样的实例规格。在工做实践，咱们会为 K8s 集群划分静态资源池和弹性资源池。一般而言，固定资源池能够根据须要选择裸金属或者虚拟机实例。弹性资源池建议根据应用负载使用合适规格的虚拟机实例来优化成本、避免浪费，提高弹性供给保障。此外因为裸金属实例通常 CPU 核数很是多，大规格实例在使用中的挑战请参见下文。

较少的大规格实例仍是较多的小规格实例？

一个引伸的问题是，如何选择实例规格？咱们列表对比一下：

默认状况下，kubelet 使用 CFS 配额 来执行 pod 的 CPU 约束。当节点上运行了不少 CPU 密集的应用时，工做负载可能会迁移到不一样的 CPU 核，工做负载的会受到 CPU 缓存亲和性以及调度延迟的影响。当使用大规格实例类型时，节点的 CPU 数量较多，现有的 Java，Golang 等应用在多 CPU 共享的场景，性能会出现明显降低。全部对于大规格实例，须要对 CPU 管理策略进行配置，利用 CPU set 进行资源分配。

此外一个重要的考虑因素就是 NUMA 支持。在 NUMA 开启的裸金属实例或者大规格实例上，若是处理不当，内存访问吞吐可能会比优化方式下降了 30%。Topology 管理器能够开启 NUMA 感知 。可是目前 K8s 对 NUMA 的支持比较简单，还没法充分发挥 NUMA 的性能。

https://kubernetes.io/docs/tasks/administer-cluster/topology-manager/

阿里云容器服务提供了 CGroup Controller 能够更加灵活地对 NUMA 架构进行调度和重调度。

如何容器运行时?

Docker 容器仍是安全沙箱？

在 Sysdig 发布的 2019 容器使用报告中，咱们能够看到 Docker 容器占据市场规模最大的容器运行时 （79%），containerd 是 Docker 贡献给 CNCF 社区的开源容器运行时，如今也占据了一席之地，而且获得了厂商的普遍支持；cri-o 是红帽公司推出的支持 OCI 规范的面向 K8s 的轻量容器运行时，目前还处在初级阶段。

不少同窗都关心 containerd 与 Docker 的关系，以及是否 containerd 能够取代 Docker？Docker Engine 底层的容器生命周期管理也是基于 containerd 实现。可是 Docker Engine 包含了更多的开发者工具链，好比镜像构建。也包含了 Docker 本身的日志、存储、网络、Swarm 编排等能力。此外，绝大多数容器生态厂商，如安全、监控、日志、开发等对 Docker Engine 的支持比较完善，对 containerd 的支持也在逐渐补齐。

因此在 Kubernetes 运行时环境，对安全和效率和定制化更加关注的用户能够选择 containerd 做为容器运行时环境。对于大多数开发者，继续使用 Docker Engine 做为容器运行时也是一个不错的选择。

此外，传统的 Docker RunC 容器与宿主机 Linux 共享内核，经过 CGroup 和 namespace 实现资源隔离。可是因为操做系统内核的***面比较大，一旦恶意容器利用内核漏洞，能够影响整个宿主机上全部的容器。

愈来愈多企业客户关注容器的安全性，为了提高安全隔离，阿里云和蚂蚁金服团队合做，引入安全沙箱容器技术。19 年 9 月份咱们发布了基于轻量虚拟化技术的 RunV 安全沙箱。相比于 RunC 容器，每一个 RunV 容器具备独立内核，即便容器所属内核被攻破，也不会影响其余容器，很是适合运行来自第三方不可信应用或者在多租户场景下进行更好的安全隔离。

阿里云安全沙箱容器有大量性能优化，能够达到 90% 的原生 RunC 性能：

• 利用 Terway CNI 网络插件，网络性能无损；
• 利用 DeviceMapper 构建了⾼速、稳定的容器 Graph Driver；
• 优化 FlexVolume 和 CSI Plugin，把 mount bind 的动做下沉到沙箱容器内，从而避开了 9pfs 带来的性能损耗。

并且，ACK 为安全沙箱容器和和 RunC 容器提供了彻底一致的用户体验，包括日志、监控、弹性等。同时，ACK 能够在一台神龙裸金属实例上同时混布 RunC 和 RunV 容器，用户能够根据本身的业务特性自主选择。

同时，咱们也要看到安全沙箱容器还有一些局限性，现有不少日志、监控、安全等工具对独立内核的安全沙箱支持很差，须要做为 sidecar 部署在安全沙箱内部。

对于用户而言，若是须要多租户隔离的场景，能够采用安全沙箱配合 network policy 来完成，固然也可让不一样租户的应用运行在不一样的虚拟机或者弹性容器实例上，利用虚拟化技术来进行隔离。

注意：安全沙箱目前只能运行在裸金属实例上，当容器应用须要资源较少时成本比较高。能够参考下文的 Serverless K8s 有关内容。

如何规划容器集群？

一个大集群仍是一组小集群？

在生产实践中，你们常常问到的一个问题是咱们公司应该选择一个仍是多个 Kubernetes 集群。

Rob Hirschfeld 在 Twitter 上作了一个调查：

• 一个大一统的平台，支持多种应用负载、环境和多租户隔离；
• 或者，一组以应用为中心的小集群，支持不一样应用和环境的生命周期管理。

https://thenewstack.io/the-optimal-kubernetes-cluster-size-lets-look-at-the-data/

大多数的用户选择是后者，典型的场景是：

• 开发、测试环境使用不一样的集群
• 不一样的部门使用不一样的集群进行隔离
• 不一样的应用使用不一样的集群
• 不一样版本的 K8s 集群

在用户反馈中，采用以多个小集群的主要缘由在于爆炸半径比较小，能够有效提高系统的可用性。同时经过集群也能够比较好地进行资源隔离。管理、运维复杂性的增长是采用多个小集群的一个不足之处，可是在公共云上利用托管的 K8s 服务（好比阿里云的 ACK）建立和管理 K8s 集群生命周期很是简单，能够有效解决这个问题。

咱们能够比较一下这两种选择：

源自 Google Borg 的理念，Kubernetes 的愿景是成为 Data Center Operating System，并且 Kubernetes 也提供了 RBAC、namespace 等管理能力，支持多用户共享一个集群，并实现资源限制。可是这些更可能是 “软多租” 能力，不能实现不一样租户之间的强隔离。在多租最佳实践中，咱们能够有以下的一些建议：

• 数据平面：能够经过 PSP (PodSecurityPolicy) 或者安全沙箱容器，提高容器的隔离性；利用 Network Policy 提高应用之间网络隔离性；能够经过将 nodes 和 namespace 绑定在一块儿，来提高 namespace 之间资源的隔离；

• 控制平面：Kubernetes 的控制平面包括 master 组件 API Server, Scheduler, etcd 等，系统 addon 如 CoreDNS, Ingress Controller 等，以及用户的扩展，如 3 方的 CRD (Customer Resource Definition) controller。这些组件大多不具有良好的租户之间的安全、资源和故障隔离能力。一个错误的 CRD contoller 实现有可能打挂一个集群的 API Server。

关于 Kubernetes 多租户实践的具体信息能够参考下文。目前而言，Kubernetes 对硬隔离的支持存在不少局限性，同时社区也在积极探索一些方向，如阿里容器团队的 Virtual Cluster Proposal 能够提高隔离的支持，可是这些技术还未成熟。

https://www.infoq.cn/article/NyjadtOXDemzPWyRCtdm?spm=a2c6h.12873639.0.0.28373df9R7x2DP

https://github.com/kubernetes-sigs/multi-tenancy/tree/master/incubator/virtualcluster?spm=a2c6h.12873639.0.0.28373df9R7x2DP

另外一个须要考虑的方案是 Kubernetes 自身的可扩展性，咱们知道一个 Kubernetes 集群的规模在保障稳定性的前提下受限于多个维度，通常而言 Kubernetes 集群小于 5000 节点。固然，运行在阿里云上还受限于云产品的 quota 限制。阿里经济体在 Kubernetes 规模化上有丰富的经验，可是对于绝大多数客户而言，是没法解决超大集群的运维和定制化复杂性的。

对于公共云客户咱们通常建议，针对业务场景建议选择合适的集群规模：

• 对于跨地域（region）场景，采用多集群策略，K8s 集群不该跨地域。咱们能够利用 CEN 将不一样地域的 VPC 打通；
• 对于强隔离场景，采用多集群策略，不一样安全域的应用部署在不一样的集群上；
• 对于应用隔离场景，好比 SaaS 化应用，能够采用单集群方式支持多租，并增强安全隔离；
• 对于多个大规模应用，能够采用多集群策略，好比，在线应用、AI 训练、实时计算等能够运行在不一样的 K8s 集群之上，一方面能够控制集群规模，一方面能够针对应用负载选择合适的节点规格和调度策略。

因为有 VPC 中节点、网络资源的限制，咱们能够甚至将不一样的 K8s 集群分别部署在不一样的 VPC，利用 CEN 实现网络打通，这部分须要对网络进行前期规划。

• 若是须要对多个集群的应用进行统一管理，有以下几个考虑；
• 利用 Kubefed 构建集群联邦，ACK 对集群联邦的支持能够参考。

https://help.aliyun.com/document_detail/121653.html?spm=a2c6h.12873639.0.0.28373df9R7x2DP

利用统一的配置管理中心，好比 GitOps 方式来管理和运维应用。

https://github.com/fluxcd/flux?spm=a2c6h.12873639.0.0.28373df9R7x2DP

另外利用托管服务网格服务 ASM，能够利用 Istio 服务网格轻松实现对多个 K8s 集群的应用的统一路由管理。

如何选择 K8s 或者 Serverless K8s 集群？

在全部的调查中，K8s 的复杂性和缺少相应的技能是阻碍 K8s 企业所采用的主要问题，在 IDC 中运维一个 Kubernetes 生产集群仍是很是具备挑战的任务。阿里云的 Kubernetes 服务 ACK 简化了 K8s 集群的生命周期管理，托管了集群的 master 节点被，可是用户依然要维护 worker 节点，好比进行升级安全补丁等，并根据本身的使用状况进行容量规划。

针对 K8s 的运维复杂性挑战，阿里云推出了 Serverless Kubernetes 容器服务 ASK。

彻底兼容现有 K8s 容器应用，可是全部容器基础设施被阿里云托管，用户能够专一于本身的应用。它具有几个特色：

1. 首先它按照容器应用实际消耗的资源付费，而不是按照预留的节点资源付费；
2. 对用户而言没有节点的概念，零维护；
3. 全部资源按需建立，无需任何容量规划。

在 ASK 中，应用运行在弹性容器实例 - ECI （Elastic Container Instance）中，ECI 基于轻量虚拟机提供的沙箱环境实现应用安全隔离，而且彻底兼容 Kubernetes Pod 语义。在 ASK 中咱们经过对 Kubernetes 作减法，将复杂性下沉到基础设施，极大下降了运维管理负担，提高用户体验，让 Kubernetes 更简单，让开发者更加专一于应用自身。除了无需管理节点和 Master 外，咱们将 DNS, Ingress 等能力经过阿里云产品的原生能力来实现，提供了极简但功能完备的 Kubernetes 应用运行环境。

Serverless Kubernetes 极大下降了管理复杂性，并且其自身设计很是适合突发类应用负载，如 CI/CD，批量计算等等。好比一个典型的在线教育客户，根据教学须要按需部署教学应用，课程结束自动释放资源，总体计算成本只有使用包月节点的 1/3。

在编排调度层，咱们借助了 CNCF 社区的 Virtual-Kubelet，并对其进行了深度扩展。Virtual-Kubelet 提供了一个抽象的控制器模型来模拟一个虚拟 Kubernetes 节点。当一个 Pod 被调度到虚拟节点上，控制器会利用 ECI 服务来建立一个 ECI 实例来运行 Pod。

咱们还能够将虚拟节点加入 ACK K8s 集群，容许用户灵活控制应用部署在普通节点上，仍是虚拟节点上。

值得注意的是 ASK/ECI 是 nodeless 形态的 pod，在 K8s 中有不少能力和 node 相关，好比 NodePort 等概念不支持，此外相似日志、监控组件常常以 DaemonSet 的方式在 K8s 节点上部署，在 ASK/ECI 中须要将其转化为 Sidecar。

用户该如何选择 ACK 和 ASK 呢？ACK 主要面向的是基础设施运维团队，具有和 K8s 高度的兼容性和灵活性控制性。而 ASK 则是面向业务技术团队或者开发者，用户彻底不需具有 K8s 的管理运维能力，便可管理和部署 K8s 应用。而 ACK on ECI，则同时支持用户负载运行在 ECS 实例或者 ECI 实例上，能够容许用户进行灵活控制。

ACK on ECI/ASK 则能够将弹性的负载经过 ECI 的方式运行，有几个很是典型的场景：

• 应对突发流量：ECI 基于面向容器的轻量安全沙箱，能够实现 30s 500Pod 的弹性伸缩能力，能够轻松应对突发的业务流量，在面对不肯定的业务流量时，能够简化弹性配置；
• 批量数据处理：咱们能够实现 Serverless Spark/Presto 这样的计算任务, 按需为计算任务分配计算资源；
• 安全隔离：有些业务应用须要运行 3 方不可信应用，好比一个 AI 算法模型，ECI 自己利用安全沙箱进行隔离，咱们能够利用 ECI 隔离运行相关应用。

ACK on ECI 还能够和 Knative 这样的 Serverless 应用框架配合，开发领域相关的 Serverless 应用。

总结

合理规划 K8s 集群能够有效规避后续运维实践中的稳定性问题，下降使用成本。期待与你们一块儿交流阿里云上使用 Kubernetes 的实践经验。

关于做者

易立，阿里云资深技术专家，阿里云容器服务的研发负责人。以前曾在 IBM 中国开发中心工做，担任资深技术专员；做为架构师和主要开发人员负责或参与了一系列在云计算、区块链、Web 2.0，SOA 领域的产品研发和创新。阿里云容器平台团队求贤若渴！社招技术专家 / 高级技术专家，base 杭州 / 北京 / 深圳。欢迎发简历到 jiaxu.ljx@alibaba-inc.com

“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，作最懂云原生开发者的技术圈。”