共计 4918 个字符，预计需要花费 13 分钟才能阅读完成。
前言
在后面的文章《弹性调度助力企业灵便应答业务变动，高效治理云上资源》中，咱们介绍了阿里云容器服务 ACK 弹性调度为了帮忙客户解决在应用云上弹性资源时，面对的“难以差异化管制业务资源使用量，缩容时局部业务 Pod 未开释”等挑战，提供了依照多级资源的优先程序进行调度，以及依照定义的优先程序进行缩容的能力。
本文将介绍弹性调度如何应用虚构节点来满足您的业务弹性需要。
企业在施行利用弹性过程中，弹性速度和弹性地位是重点关注的两个外围指标。
对于谋求高可用以及稳定性的企业来说，麻利的弹性可能在业务流量突增时，保证系统的连续性与稳定性。同时，通过跨多地区部署利用，能够在地域性故障产生时，无效地维持服务的继续可用性。
对于大数据处理工作的企业来说，疾速的弹性可能缩短工作执行工夫，放慢利用的迭代速度。同时，集中部署在单个地区，则能够缩小利用之间的网络通信时延，从而进一步晋升数据处理效率。
显然，这两个指标对于确保企业业务的稳固高效运行至关重要。
然而，许多企业在面对疾速到来的业务流量顶峰和日益增长的大数据算力需要时，现行的分钟级主动伸缩节点池的弹性响应曾经无奈满足需要。并且，通过正当的部署策略，实现预期的弹性地位，也颇具挑战。
为此，阿里云推出弹性容器实例（Elastic Container Instance，ECI），以十秒级的弹性速度，有效应对突发流量的弹性需要。同时，阿里云容器服务 Kubernetes 版（ACK）利用虚构节点技术实现与 ECI 弹性资源的无缝集成，使得业务可能在集群内灵便动静地调用 ECI 资源，迅速应答弹性挑战。此外，容器服务 ACK 的弹性调度性能在将业务调度到 ECI 上时，还能维持业务的亲和性配置不变，确保利用运行的稳固和高效。
应用虚构节点实现秒级弹性
为了在 ACK 中应用 ECI，须要在 ACK 集群中装置虚构节点组件。
在 ACK Pro 版集群中，能够通过组件治理页面部署 ack-virtual-node 组件，该组件默认被托管，不占用 Worker 节点资源。
在 ACK 专有版集群中，能够通过利用市场页面部署 ack-virtual-node 组件，装置胜利后会在 kube-system 命名空间下创立一个名为 ack-virtual-node-controller 的 deployment，该 deployment 会运行在您的 Worker 节点上。
装置胜利后用户能够通过 kubectl get no 命令在集群中查看到若干虚构节点，代表虚构节点装置胜利。
虚构节点装置胜利之后，能够应用弹性调度性能配置 ECI 的应用策略，以下是“优先调度 ECS，当 ECS 资源应用完后应用 ECI 资源”的示例。
apiVersion: scheduling.alibabacloud.com/v1alpha1
kind: ResourcePolicy
metadata:
name: test
spec:
strategy: prefer
units:
- resource: ecs
- resource: eci配置了以上 ResourcePolicy 之后，在 default 命名空间下的所有 Pod 都将遵循以下的调度规定：优先应用 ECS，ECS 资源用完后应用 ECI。
须要留神的是：以上配置会使得 ECS 节点上的抢占性能生效，如果须要同时放弃在 ECS 上的抢占能力，请配置 preemptPolicy=BeforeNextUnit，如果须要限定失效的业务范围，请按需配置 selector。
以下是理论应用成果：
首先，提交一个 Deployment，8 个业务 Pod 中仅有 7 个业务 Pod 可能被胜利调度。
此时，提交 ResourcePolicy，并将 Deployment 的正本数减少到 10，新的正本将全副运行在 ECI 上。
通过统计业务 Pod 的创立工夫以及 startTime，能够看到这里新 Pod 的创立工夫在 13 秒，远远低于主动伸缩节点所需的弹性工夫。
升高大数据工作通信时延
若您的集群配置了多个可用区的虚构节点，在默认状况下，ECI Pod 可能会被调度在多个可用区上。如下图，在默认状况下，nginx 被调度到了 C 和 D 两个可用区的 virtual node 上。
对于大数据型利用，配置可用区亲和往往意味着计算 Pod 之间的网络通信代价更小，进而带来更高的吞吐量。通过阿里云弹性调度，您能够通过 Pod 上的节点亲和以及 Pod 亲和限度业务调度的可用区，从而实现 ECS 上的 Pod 与 ECI 上的 Pod 调度在雷同的可用区上。
以下是两种在 ECI 上配置雷同可用区调度的示例，别离应用了指定可用区调度以及不指定可用区调度两种形式，在以下的两个例子中，已提前提交了 ResourcePolicy：
手动指定可用区
原生 Kubernetes 提供了节点亲和调度语义来管制 Pod 的调度地位，以下的例子中咱们指定 nginx 服务仅在可用区 C 上进行调度。您惟一须要进行的批改是在工作负载的 PodTemplate 或 PodSpec 中增加节点亲和束缚。
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx
name: nginx-deployment-basic
spec:
replicas: 9
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: topology.kubernetes.io/zone
operator: In
values:
- cn-hongkong-c
containers:
- image: 'nginx:1.7.9'
imagePullPolicy: IfNotPresent
name: nginx
resources:
limits:
cpu: 1500m
requests:
cpu: 1500m
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File同样将业务 Pod 扩容到 9，此时可能察看到业务 Pod 全副运行在可用区 C 上，因为集群中 ECS 节点均为可用区 D 上的机器，因而所有业务 Pod 全副运行在 ECI 上。
最优可用区感知调度
为应答大数据计算需要，通常须要部署大量的 Pod，这时候确保 ECI 提供短缺的算力资源成为要害。为确保抉择到具备短缺残余算力的可用区，能够在指定可用区亲和时应用 Pod 亲和。在 ECI 调度过程中，调度器会参考 ECI 提供的可用区倡议，抉择一个可用算力更多的可用区，从而实现主动抉择更优地位的成果。以下例子中咱们将限度 Pod 仅在 ECI 上调度，并通过 Pod 亲和限度 Pod 必须被调度到同一个可用区。
注：Pod 亲和会使得后续 Pod 与第一个被调度的 Pod 亲和在雷同可用区，当采纳 ECS+ECI 弹性调度时，因为第一个被调度的 Pod 通常为 ECS Pod，会使得后续 ECI Pod 亲和在 ECS 雷同的可用区，此时建议您应用 preferredDuringSchedulingIgnoredDuringExecution。
提交的 ResourcePolicy 为：
apiVersion: scheduling.alibabacloud.com/v1alpha1
kind: ResourcePolicy
metadata:
name: test
spec:
strategy: prefer
units:
- resource: eci提交的工作负载为：
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx
name: nginx-deployment-basic
spec:
replicas: 9
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- nginx
topologyKey: topology.kubernetes.io/zone
containers:
- image: 'nginx:1.7.9'
imagePullPolicy: IfNotPresent
name: nginx
resources:
limits:
cpu: 1500m
requests:
cpu: 1500m
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File提交后可用发现，此时 Pod 仍然均调度在雷同的可用区，此时调度到的可用区将会是 ECI 举荐的更优可用区。
保障在线业务高可用
对于在线业务而言，配置业务多可用区部署是保障业务高可用的一种无效伎俩。通过阿里云弹性调度，您能够通过 Pod 上的拓扑散布束缚来实现 ECS 上的 Pod 与 ECI 上的 Pod 遵循雷同的拓扑散布束缚，从而实现业务的高可用。
以下是一个在 ECI 上配置业务高可用的示例，指定了业务 Pod 在多个可用区上均匀分布，并且在 ECS 资源有余时应用 ECI。
apiVersion: scheduling.alibabacloud.com/v1alpha1
kind: ResourcePolicy
metadata:
name: test
spec:
strategy: prefer
units:
- resource: ecs
- resource: eci
---
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx
name: nginx-deployment-basic
spec:
replicas: 9
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
topologySpreadConstraints:
- labelSelector:
matchLabels:
app: nginx
maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: DoNotSchedule
containers:
- image: 'nginx:1.7.9'
imagePullPolicy: IfNotPresent
name: nginx
resources:
limits:
cpu: 1500m
requests:
cpu: 1500m
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File提交上述资源清单后，Pod 最终的可用区和节点散布如下，因为可用区 D 上存在三个 ECS 节点，因而最终 Pod 在可用区 D 上存在 5 个 Pod，在可用区 C 上存在 4 个 Pod。可能满足束缚中最大倾斜度为 1 的要求。
What’s Next
阿里云容器服务 Kubernetes 版（ACK）在规范 K8s 调度框架的根底上扩大了弹性调度性能，致力于进步利用性能和集群整体资源的利用率，保障企业业务的稳固高效运行。
在后期文章《弹性调度助力企业灵便应答业务变动，高效治理云上资源》中，咱们曾经探讨了如何通过阿里云容器服务 ACK 的弹性调度无效治理各类弹性资源，以帮忙企业优化资源配置，实现降本增效。
在本文中，咱们又深刻解析了 ACK 弹性调度如何与弹性容器实例（ECI）这一要害弹性资源联合，凭借 ECI 疾速弹性、秒级计费和即时开释的劣势，显著晋升企业业务的稳定性和效率。
在行将推出的调度系列文章中，咱们将具体介绍如何在 ACK 上治理和调度 AI 工作，助力企业 AI 业务在云端疾速落地。
作者：吴昆
原文链接
本文为阿里云原创内容，未经容许不得转载。
