营销型企业网站策划方案,seo好找工作吗,网站 图标 gif,东营做网站公司作者 | Draveness来源 | 真没什么逻辑头图 | 下载于视觉中国2014 年发布的 Kubernetes 在今天俨然已成为容器编排领域的事实标准#xff0c;相信谈到 Kubernetes 的开发者都会一再复述上述现象。如下图所示#xff0c;今天的大多数个人或者团队都会选择 Kubernetes 管理容器相信谈到 Kubernetes 的开发者都会一再复述上述现象。如下图所示今天的大多数个人或者团队都会选择 Kubernetes 管理容器而也有 75% 的人会在生产环境中使用 Kubernetes。图 1 - Kubernetes 容器编排[^1]在这种全民学习和使用 Kubernetes 的大背景下我们也应该非常清晰地知道 Kubernetes 有哪些局限性。虽然 Kubernetes 能够解决容器编排领域的大多数问题但是仍然有一些场景是它很难处理、甚至无法处理的只有对这些潜在的风险有清晰的认识才能更好地驾驭这项技术这篇文章将从集群管理和应用场景两个部分谈谈 Kubernetes 社区目前的发展和一些局限性。集群管理集群是一组能够在一起协同工作的计算机我们可以将集群中的所有计算机看成一个整体所有资源调度系统都是以集群为维度进行管理的集群中的所有机器构成了资源池这个巨大的资源池会为待运行的容器提供资源执行计算任务这里简单谈一谈 Kubernetes 集群管理面对的几个复杂问题。水平扩展性集群大小是我们在评估资源管理系统时需要关注的重要指标之一然而 Kubernetes 能够管理的集群规模远远小于业界的其他资源管理系统。集群大小为什么重要呢我们先来看另一个同样重要的指标 — 资源利用率很多工程师可能没有在公有云平台上申请过资源这些资源都相当昂贵在 AWS 上申请一个与主机差不多配置的虚拟机实例8 CPU、16 GB每个月大概需要 150 美金约为 1000 人民币[^2]。图 2 - AWS EC2 价格大多数的集群都会使用 48 CPU 或者 64 CPU 的物理机或者虚拟机作为集群中的节点如果我们的集群中需要包含 5,000 个节点那么这些节点每个月大概要 8,000,000 美元约为 50,000,000 人民币在这样的集群中提升 1% 的资源利用率就相当于每个月节省了 500,000 的成本。多数在线任务的资源利用率都很低更大的集群意味着能够运行更多的工作负载而多种高峰和低谷期不同的负载部署在一起可以实现超售这样能够显著地提高集群的资源利用率如果单个集群的节点数足够多我们在部署不同类型的任务时会有更合理的组合可以完美错开不同服务的高峰期。Kubernetes 社区对外宣传的是单个集群最多支持 5,000 节点Pod 总数不超过 150,000容器总数不超过 300,000 以及单节点 Pod 数量不超过 100 个[^3]与几万节点的 Apache Mesos 集群、50,000 节点的微软 YARN 集群[^4]相比Kubernetes 的集群规模整整差了一个数量级。虽然阿里云的工程师也通过优化 Kubernetes 的各个组件实现了 5 位数的集群规模但是与其他的资源管理方式相比却有比较大的差距[^5]。图 3 - Apache Mesos 与 Hadoop YARN需要注意的是 Kubernetes 社区虽然对外宣称单集群可以支持 5,000 节点同时社区也有各种各样的集成测试保证每个改动都不会影响它的伸缩性[^6]但是 Kubernetes 真的非常复杂我们没有办法保证你使用的每个功能在扩容的过程中都不出问题。而在生产环境中我们甚至可能在集群扩容到 1000 ~ 1500 节点时遇到瓶颈。每个稍具规模的大公司都想要实现更大规模的 Kubernetes 集群但是这不是一个改几行代码就能解决的简单问题它可能需要我们限制 Kubernetes 中一些功能的使用在扩容的过程中etcd、API 服务器、调度器以及控制器都有可能出现问题。社区中已经有一些开发者注意到了其中的一些问题例如在节点上增加缓存降低 API 服务器的负载[^7]但是要推动类似的改变还是很困难的有志之士可以尝试在社区推动类似的项目。多集群管理单个集群的容量再大也无法解决企业面对的问题哪怕有一天 Kubernetes 集群可以达到 50,000 节点的规模我们仍然需要管理多个集群多集群管理也是 Kubernetes 社区目前正在探索的方向社区中的多集群兴趣小组SIG Multi-Cluster目前就在完成相关的工作[^8]。在作者看来Kubernetes 的多集群会带来资源不平衡、跨集群访问困难以及提高运维和管理成本三大问题我们在这里谈一谈目前在开源社区和业界几种可供参考和选择的解决方案。kubefed首先要介绍的是 kubefed该项目是 Kubernetes 社区给出的解决方案它同时提供了跨集群的资源和网络管理的功能社区的多集群兴趣小组SIG Multi-Cluster负责了该项目的开发工作图 4 - Kubernetes 联邦kubefed 通过一个中心化的联邦控制面板管理多集群中的元数据上层的控制面板会为管理器群中的资源创建对应的联邦对象例如FederatedDeploymentkind: FederatedDeployment
...
spec:...overrides:# Apply overrides to cluster1- clusterName: cluster1clusterOverrides:# Set the replicas field to 5- path: /spec/replicasvalue: 5# Set the image of the first container- path: /spec/template/spec/containers/0/imagevalue: nginx:1.17.0-alpine# Ensure the annotation foo: bar exists- path: /metadata/annotationsop: addvalue:foo: bar# Ensure an annotation with key foo does not exist- path: /metadata/annotations/fooop: remove# Adds an argument -q at index 0 of the args list# this will obviously shift the existing arguments, if any- path: /spec/template/spec/containers/0/args/0op: addvalue: -q上层的控制面板会根据联邦对象 FederatedDeployment 的规格文件生成对应的 Deployment 并推送到下层的集群下层集群可以正常根据 Deployment 中的定义创建特定数量的副本。图 5 - 从联邦对象到普通对象FederatedDeployment 只是一种最简单的分发策略在生产环境中我们希望通过联邦的集群实现容灾等复杂功能这时可以利用 ReplicaSchedulingPreference 在不同集群中实现更加智能的分发策略apiVersion: scheduling.kubefed.io/v1alpha1
kind: ReplicaSchedulingPreference
metadata:name: test-deploymentnamespace: test-ns
spec:targetKind: FederatedDeploymenttotalReplicas: 9clusters:A:minReplicas: 4maxReplicas: 6weight: 1B:minReplicas: 4maxReplicas: 8weight: 2上述调度的策略可以实现工作负载在不同集群之间的权重在集群资源不足甚至出现问题时将实例迁移到其他集群这样既能够提高服务部署的灵活性和可用性基础架构工程师也可以更好地平衡多个集群的负载。我们可以认为 kubefed 的主要作用是将多个松散的集群组成强耦合的联邦集群并提供更加高级的网络和部署功能这样我们可以更容易地解决集群之间资源不平衡和连通性的一些问题然而该项目的关注点不包含集群生命周期的管理。集群接口Cluster API 也是 Kubernetes 社区中与多集群管理相关的项目该项目由集群生命周期小组SIG Cluster-Lifecycle负责开发其主要目标是通过声明式的 API 简化多集群的准备、更新和运维工作你在该项目的 设计提案 中能够找到它的职责范围[^9]。图 6 - Cluster API 概念在该项目中最重要的资源就是 Machine它表示一个 Kubernetes 集群中的节点。当该资源被创建时特定提供商的控制器会根据机器的定义初始化并将新的节点注册到集群中在该资源被更新或者删除时也会执行操作达到用户的状态。这种策略与阿里的多集群管理的方式有一些相似它们都使用声明式的 API 定义机器和集群的状态然后使用 Kubernetes 原生的 Operator 模型在更高一层的集群中管理下层集群这能够极大降低集群的运维成本并提高集群的运行效率[^10]不过类似的项目都没有考虑跨集群的资源管理和网络管理。应用场景我们在这一节将谈谈 Kubernetes 中一些有趣的应用场景其中包括应用分发方式的现状、批处理调度任务以及硬多租户在集群中的支持这些是社区中比较关注的问题也是 Kubernetes 目前的盲点。应用分发Kubernetes 主项目提供了几种部署应用的最基本方式分别是 Deployment、StatefulSet 和 DaemonSet这些资源分别适用于无状态服务、有状态服务和节点上的守护进程这些资源能够提供最基本的策略但是它们无法处理更加复杂的应用。图 7 - Kubernetes 应用管理随着 CRD 的引入目前社区的应用管理小组SIG Apps基本不会向 Kubernetes 主仓库引入较大的改动大多数的改动都是在现有资源上进行的修补很多常见的场景例如只运行一次的 DaemonSet[^11] 以及金丝雀和蓝绿部署等功能现在的资源也存在很多问题例如 StatefulSet 在初始化容器中卡住无法回滚和更新[^12]。我们可以理解社区不想在 Kubernetes 中维护更多的基本资源通过几个基本的资源可以覆盖 90% 的场景剩下的各种复杂场景可以让其他社区通过 CRD 的方式实现。不过作者认为如果社区能够在上游实现更多高质量的组件这对于整个生态都是很有价值并且很重要的工作需要注意的是假如各位读者想要在 Kubernetes 项目中成为贡献者SIG Apps 可能不是一个很好的选择。批处理调度机器学习、批处理任务和流式任务等工作负载的运行从 Kubernetes 诞生第一天起到今天都不是它的强项大多数的公司都会使用 Kubernetes 运行在线服务处理用户请求用 Yarn 管理的集群运行批处理的负载。hadoop-yarn图 8 - Hadoop Yarn在线任务和离线任务往往是两种截然不同的作业大多数的在线任务都是无状态的服务它们可以在不同机器上进行迁移彼此很难有极强的依赖关系但是很多离线任务的拓扑结构都很复杂有些任务需要多个作业一同执行而有些任务需要按照依赖关系先后执行这种复杂的调度场景在 Kubernetes 中比较难以处理。在 Kubernetes 调度器引入调度框架之前所有的 Pod 在调度器看来是没有任何关联的不过有了调度框架我们可以在调度系统中实现更加复杂的调度策略例如保证一组 Pod 同时调度的 PodGroup[^13]这对于 Spark 和 TensorFlow 任务非常有用。# PodGroup CRD spec
apiVersion: scheduling.sigs.k8s.io/v1alpha1
kind: PodGroup
metadata:name: nginx
spec:scheduleTimeoutSeconds: 10minMember: 3
---
# Add a label pod-group.scheduling.sigs.k8s.io to mark the pod belongs to a group
labels:pod-group.scheduling.sigs.k8s.io: nginxVolcano 也是在 Kubernetes 上构建的批处理任务管理系统[^14]它能够处理机器学习、深度学习以及其他大数据应用可以支持包括 TensorFlow、Spark、PyTorch 和 MPI 在内的多个框架。图 9 - Volcano虽然 Kubernetes 能够运行一些批处理任务但是距离在这个领域上取代 Yarn 等老牌资源管理系统上还有非常大的差距相信在较长的一段时间内大多数公司都会同时维护 Kubernetes 和 Yarn 两种技术栈分别管理和运行不同类型的工作负载。硬多租户多租户是指同一个软件实例可以为不同的用户组提供服务Kubernetes 的多租户是指多个用户或者用户组使用同一个 Kubernetes 集群今天的 Kubernetes 还很难做到硬多租户支持也就是同一个集群的多个租户不会相互影响也感知不到彼此的存在。硬多租户在 Kubernetes 中是一个很重要、也很困难的课题合租公寓就是一个典型的多租户场景多个租客共享房屋内的基础设施硬多租户要求多个访客之间不会相互影响你可以想象这有多么困难Kubernetes 社区甚至有一个工作小组专门讨论和研究相关的问题[^15]然而虽然感兴趣的工程师很多但是成果却非常有限。图 10 - 多租户尽管 Kubernetes 使用命名空间来划分虚拟机群然而这也很难实现真正的多租户。多租户的支持到底有哪些作用呢这里简单列几个多租户带来的好处Kubernetes 带来的额外部署成本对于小集群来说非常高昂稳定的 Kubernetes 集群一般都需要至少三个运行 etcd 的主节点如果大多数的集群都是小集群这些额外的机器会带来很高的额外开销Kubernetes 中运行的容器可能需要共享物理机和虚拟机一些开发者可能在公司内部遇到过自己的服务被其他业务影响因为主机上容器可能隔离了 CPU 和内存资源但是没有隔离 I/O、网络 和 CPU 缓存等资源这些资源的隔离是相对困难的如果 Kubernetes 能够实现硬多租户这不仅对云服务商和小集群的使用者来说都是个福音它还能够隔离不同容器之间的影响并防止潜在安全问题的发生不过这在现阶段还是比较难实现的。总结每个技术都有自己的生命周期越底层的技术生命周期会越长而越上层的技术生命周期也就越短虽然 Kubernetes 是当今容器界的扛把子但是未来的事情没有人可以说的准。我们要时刻清楚手中工具的优点和缺点花一些时间学习 Kubernetes 中设计的精髓不过如果在未来的某一天 Kubernetes 也成为了过去我们也应该感到喜悦因为会有更好的工具取代它。[^1]: Kubernetes and Container Security and Adoption Trends https://www.stackrox.com/kubernetes-adoption-security-and-market-share-for-containers/[^2]: AWS Pricing Calculator https://calculator.aws/#/createCalculator/EC2[^3]: Considerations for large clusters https://kubernetes.io/docs/setup/best-practices/cluster-large/[^4]: How Microsoft drives exabyte analytics on the world’s largest YARN cluster https://azure.microsoft.com/en-us/blog/how-microsoft-drives-exabyte-analytics-on-the-world-s-largest-yarn-cluster/[^5]: 备战双 11蚂蚁金服万级规模 K8s 集群管理系统如何设计https://www.sofastack.tech/blog/ant-financial-managing-large-scale-kubernetes-clusters/[^6]: sig-scalability-kubemark dashboard https://testgrid.k8s.io/sig-scalability-kubemark#kubemark-5000[^7]: Node-local API cache #84248 https://github.com/kubernetes/kubernetes/issues/84248[^8]: Multicluster Special Interest Group https://github.com/kubernetes/community/tree/master/sig-multicluster[^9]: Cluster API Scope and Objectives https://github.com/kubernetes-sigs/cluster-api/blob/master/docs/scope-and-objectives.md[^10]: Demystifying Kubernetes as a service – How Alibaba cloud manages 10,000s of Kubernetes clusters https://www.cncf.io/blog/2019/12/12/demystifying-kubernetes-as-a-service-how-does-alibaba-cloud-manage-10000s-of-kubernetes-clusters/[^11]: Run job on each node once to help with setup #64623 https://github.com/kubernetes/kubernetes/issues/64623[^12]: StatefulSet does not upgrade to a newer version of manifests #78007 https://github.com/kubernetes/kubernetes/issues/78007[^13]: Coscheduling based on PodGroup CRD https://github.com/kubernetes-sigs/scheduler-plugins/tree/master/kep/42-podgroup-coscheduling[^14]: Volcano · A Kubernetes Native Batch System https://github.com/volcano-sh/volcano[^15]: Kubernetes Working Group for Multi-Tenancy https://github.com/kubernetes-sigs/multi-tenancy何为“边缘计算”编程祖师爷尼古拉斯•威茨算法数据结构程序“一学就会”的微服务架构模式除了 k8s留给 k 和 s 中间的数字不多了到底是谁发明了物联网再见 Nacos我要玩 Service Mesh 了点分享点收藏点点赞点在看
