调度FAQ

如何防止虚拟交换机IP不足导致Pod启动失败？

如何将ack-descheduler迁移至Koordinator Descheduler？

ack-descheduler已停止维护，请参见【组件公告】ack-descheduler组件迁移公告。建议您迁移至当前维护的组件模块Koordinator Descheduler。迁移流程与迁移Kubernetes Descheduler至Koordinator Descheduler的流程类似，请参见迁移Kubernetes Descheduler至Koordinator Descheduler完成迁移。

容器服务 Kubernetes 版在应用市场中提供了重调度应用ack-descheduler组件。该组件是对社区Kubernetes Descheduler的封装，目前提供0.20.0和0.27.1两个版本，其功能和使用方法均与社区Kubernetes Descheduler 0.20.0以及0.27.1保持一致。

ACK Scheduler的默认调度策略是什么？

在ACK集群中，ACK Scheduler的默认调度策略与社区Kubernetes调度器保持一致。Kubernetes调度器决定如何将Pod调度到某个节点时，通常包括两个关键步骤：Filter（过滤）和Score（评分）。

• Filter：过滤哪些节点可以被调度的。如果过滤后的列表为空，则表明Pod当前无法被调度。

• Score：过滤后，调度器将对可供调度的节点进行打分和排名，从而选择一个最适合放置Pod的节点。

关于ACK Scheduler最新版本中开启的Filter和Score插件，请参见Filter及Score插件介绍。

如何在Pod调度过程中，规避利用率热点节点？

在Kubernetes原生调度策略中，调度器主要基于节点资源的分配情况（资源Request）进行调度，并不会参考节点的真实利用率情况。此外，调度器还有多种Filter（过滤）和Score（评分）插件，共同影响着调度结果。推荐您使用ACK集群提供的如下功能，避免Pod被调度到热点节点上。

• 为每个Pod配置合理的资源Request和Limit，规划资源冗余。您可以使用资源画像功能，基于对资源使用量历史数据的分析获取容器规格的推荐配置。更多信息，请参见资源画像。

• 启用负载感知调度功能。负载感知调度是ACK调度器Kube Scheduler基于Kubernetes Scheduling Framework实现的插件。与Kubernetes原生调度策略不同的是，ACK Scheduler可以感知节点实际的资源使用情况，通过参考节点负载的历史数据并对新调度Pod进行预估，将Pod优先调度到负载较低的节点，实现节点的负载均衡。更多信息，请参见使用负载感知调度。

• 启用负载热点打散重调度功能。节点的利用率会随着时间、集群环境变化、工作负载的流量或请求等动态变化，从而导致集群内节点间原本的负载均衡被打破。此外，ACK Scheduler还提供了重调度能力，防止负载出现极端不均衡的情况。更多信息，请参见使用负载热点打散重调度。

集群中新增了一个节点，但Pod为什么始终没有调度到这台节点上去？

此现象可能由多种原因导致。您可以按照如下流程进行排查。

1. 检查节点状态是否正常。若节点处于NotReady状态，表明节点仍未就绪。

2. 检查Pod是否设置了不合适的调度策略（NodeSelector、NodeAffinity、PodAffinity）或存在污点等情况，导致Pod无法被调度到新节点。

3. 评估是否为Kubernetes原生调度策略问题。在Kubernetes原生调度策略中，调度器主要基于节点资源的分配情况（资源Request）进行调度，并不会参考节点的真实利用率情况，所以可能会出现某些节点上运行的Pod很多，某些节点上运行的Pod很少或没有。

   您可以参见如何在Pod调度过程中，规避利用率热点节点？提供的解决方案解决此问题。

集群中CPU或内存使用率不高，但调度时会提示CPU或内存资源不足

在Kubernetes原生调度策略中，调度器主要基于节点资源的分配情况（资源Request）进行调度，并不会参考节点的真实资源使用率，所以即使集群CPU真实使用率不高，但仍有可能出现Pod调度时因CPU、内存资源不足（Insufficient CPU或Insufficient Memory）而调度失败的情况。

您可以参见如何在Pod调度过程中，规避利用率热点节点？提供的解决方案解决此问题。

在ACK中使用重调度功能有哪些注意事项？是否会重启Pod？

ACK通过Koordinator Descheduler提供重调度功能，在使用重调度功能时，有如下注意事项。

• Koordinator Descheduler只负责驱逐正在运行的Pod，并不负责Pod驱逐后的重建以及调度。Pod被驱逐后的重建由其工作负载对应的Controller实现（例如Deployment、StatefulSet），重建后Pod的调度流程仍然由调度器负责。

• 重调度在执行过程中会先驱逐旧Pod，再创建新Pod。请确保您的应用有充足的冗余副本（replicas），避免驱逐时影响应用可用性。

更多信息，请参见重调度。

如何将应用调度到指定的节点上？

您可以为节点设置标签，然后在应用YAML中添加对应的nodeSelector，调度应用到指定节点。具体操作，请参见调度应用至指定节点。

在一个Deployment中，如何指定一定数量的Pod调度到ECS，一定数量的Pod调度到ECI？

在ECS、ECI资源混合使用场景的下，您可以通过UnitedDeployment的方式定义Subset，对工作负载进行管理。例如，您可以在UnitedDeployment的YAML中指定subset-ecs中的replicas为10，subset-eci中的replicas为10。详细信息，请参见基于UnitedDeployment实现工作负载的伸缩。

如何让一个工作负载的Pod在调度时满足高可用？

您可以通过Pod亲和性的方式，将一个工作负载的Pod打散到不同可用区或节点。例如，您可以参见下方YAML为Pod添加如下字段，声明一个preferredDuringSchedulingIgnoredDuringExecution“偏好”规则，尝试将具有 security=S2 Label的Pod分散调度到不同的可用区（zone）内，并在无法满足此条件时，再次尝试将该Pod调度到其他节点上。

spec:
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: security
              operator: In
              values:
              - S2
          topologyKey: topology.kubernetes.io/zone

详细信息，请参见Kubernetes官方文档podAffinity和podAntiAffinity、拓扑分布约束（Topology Spread Constraints）。

对于一批新创建的Pod，为什么没有全部调度到负载最低的节点？

如果调度器将一批新创建的Pod全部调度到当前负载最低的节点，那么这个节点反而可能很快就会成为负载热点，这是因为新Pod在启动后会增加节点的负载。

因此，负载感知调度插件在计算节点打分时，若节点中有利用率还未上报的新Pod，会对打分结果进行适当调整，避免过量调度而产生新的热点。

除了节点负载水位，还有哪些因素会影响调度结果？

K8s调度器由多个插件组成，在调度过程中很多插件都会参与到节点排序的打分计算，例如亲和性插件、拓扑分布插件，节点的最终排序会受这些插件共同影响，您可以根据实际情况，按需调整各插件的打分权重。

调度器升级为新版本后，是否继续支持已通过旧版本协议使用的负载感知调度功能？

如需使用旧版本的负载感知调度功能，需为Pod添加Annotation alibabacloud.com/loadAwareScheduleEnabled: "true"。

各版本协议的支持情况和组件版本具体要求如下。

开启CPU Burst配置后，为什么Pod仍有CPU Throttled现象出现？

通常会有以下几个原因，您可以参考以下说明进行调整。

• 配置格式错误，导致CPU Burst策略没有生效，请参见高级参数配置修改并验证。

• CPU利用率达到cfsQuotaBurstPercent配置的上限时，由于CPU资源不足，仍会出现CPU Throttled现象。

  建议您根据应用实际需求情况调整Reqeuest和Limit值。

• CPU Burst策略会调整Pod的两个cgroup参数：cpu.cfs_quota_us和cpu.cfs_burst_us，详情请参见高级参数配置。其中，cpu.cfs_quota_us在ack-koordinator感知到CPU Throttled后才会进行设置，存在少许延迟；而cpu.cfs_burst_us直接参考配置进行设置，效果更灵敏。

  建议您搭配Alibaba Cloud Linux操作系统使用，效果更佳。

• CPU Burst策略在调整cpu.cfs_quota_us时会有保护机制，即整机安全水位阈值配置的sharePoolThresholdPercent。当整机利用率过高时，为了避免单个Pod产生更多干扰，cpu.cfs_quota_us会被重置为初始值。

  建议您结合自身应用的实际情况，合理设置整机安全水位阈值，避免因整机利用率过高而影响应用性能。

开启CPU Burst策略是否必须使用Alibaba Cloud Linux操作系统？

ack-koordinator的CPU Burst策略适用于所有Alibaba Cloud Linux及CentOS开源内核。推荐您使用Alibaba Cloud Linux操作系统。借助Alibaba Cloud Linux内核特性，ack-koordinator可以提供更加细粒度的CPU弹性管理机制。更多信息，请参见在cgroup v1接口开启CPU Burst功能。

应用使用了Batch资源后，内存资源用量为什么突然变得更高？

对于在Pod Limit中配置了kubernetes.io/batch-memory的应用（简称batch limit），ack-koordinator会等待容器创建后根据batch limit在节点上为其设置Cgroup限制参数。由于部分应用在启动时会根据容器Cgroup参数自动申请内存，若应用在Cgroup的memory.limit参数设置前就完成了启动，其内存的真实用量可能会超过batch limit。而操作系统不会立即缩减该进程的内存使用，从而导致容器的内存Cgroup参数无法设置成功，需等待至其真实用量降低至batch limit以下。

此时，建议您适当调整应用配置参数，控制其内存真实用量在batch limit以下，或在应用启动脚本中首先检查内存限制参数，确认完成设置后再进行启动，确保应用的内存用量存在合理限制，避免出现OOM等情况。

您可以在容器内执行以下命令，查看内存资源限制参数。

# 单位为字节。
cat /sys/fs/cgroup/memory/memory.limit_in_bytes 
# 预期输出。
1048576000

CPU核数提高后，为什么性能反而下降并且Pod出现CPU Throttling限流问题？

当前已通过ack-slo-manager的旧版本协议使用了动态资源超卖功能，升级为ack-koordinator组件后是否继续支持？

旧版本的动态资源超卖协议包括两部分：

• 在Pod的Annotation中填写的alibabacloud.com/qosClass。

• 在Pod的Request和Limit中填写的alibabacloud.com/reclaimed。

ack-koordinator兼容以上旧版本协议，并在ACK托管集群Pro版的调度器中统一计算新旧版本协议的资源申请量和可用量。您可将组件无缝升级至ack-koordinator。

ACK托管集群Pro版的调度器和ack-koordinator对各版本协议的适配如下。

当前已通过ack-slo-manager的旧版本协议使用了CPU Burst功能，升级为ack-koordinator后是否继续支持？

旧版本的Pod协议要求在Annotation中填写alibabacloud.com/cpuBurst，ack-koordinator对此旧版本协议完全兼容，您可将组件无缝升级至新版本。

ack-koordinator对各版本协议的适配如下。

当前已经通过ack-slo-manager的旧版本协议使用了CPU QoS功能，升级为ack-koordinator后是否继续支持CPU QoS功能？

旧版本（≤0.8.0）的Pod协议中，通过在Pod的Annotation中填写alibabacloud.com/qosClass启用CPU QoS。

ack-koordinator保持了对以上旧版本协议的兼容，您可以将组件无缝升级至ack-koordinator，并逐步将Pod切换为koordinator.sh协议。ack-koordinator将对以上旧版本协议兼容至2023年07月30日，我们建议您将原协议资源字段及时升级到新版本。

当前已经通过ack-slo-manager的旧版本协议使用了容器内存QoS功能，升级为ack-koordinator后是否继续支持容器内存QoS功能？

旧版本（≤0.8.0）的Pod协议包括：

• 在Pod的Annotation中填写alibabacloud.com/qosClass。

• 在Pod的Annotation中填写alibabacloud.com/memoryQOS。

ack-koordinator兼容以上旧版本协议，您可以将组件无缝升级至ack-koordinator。兼容支持至2023年7月30日。建议您将原协议资源字段及时升级到新版本。

ack-koordinator各版本对内存QoS功能的适配如下。

节点利用率阈值已经达到阈值，但是节点上Pod没有被驱逐怎么办？

出现这种情况时，一般可能是有以下几种原因，请参考对应的解决方法进行调整。

重调度器频繁重启是什么原因？

重调度器的配置ConfigMap格式错误或不存在，请参见高级配置参数检查ConfigMap文件内容和格式并进行修改，修改后重启重调度器。重启重调度器，请参见步骤二：开启负载热点打散重调度插件。

负载感知调度和热点打散重调度如何搭配使用？

开启热点打散重调度后，负载热点上的Pod将会被驱逐。对于上层控制器（例如Deployment）新建的Pod，调度器会根据其配置选择合适的节点进行调度。为了获得更好的负载均衡效果，建议您同时为调度器开启负载感知调度能力，请参见使用负载感知调度。

配置时，建议您将负载感知调度中的节点筛选功能参数loadAwareThreshold配置为与热点打散重调度器的highThresholds参数相同的值，具体请参见策略说明。当节点的负载超过highThresholds时，重调度器将驱逐该节点上的Pod，而调度器则通过loadAwareThreshold拒绝新的Pod被调度到该热点节点上。否则，经驱逐的Pod可能重新被调度到原来的节点，尤其是在Pod指定了节点调度范围，但对应的节点数量较少且利用率较为接近时。

重调度参考的利用率算法是什么？

重调度器会持续对利用率监控一段时间，并对监控数据做平滑均值处理，因此只有节点持续超过阈值才会触发重调度，默认为10分钟左右。此外对于内存资源维度，重调度器参考的内存用量排除了page cache，因为这部分资源是可以被操作系统回收的，而通过kubectl top node返回的利用率是包含page cache的，您可以通过使用阿里云Prometheus监控查看真实的内存用量信息。

在使用wrk压测中，测试结果提示“Socket errors: connect 54,”怎么办？

问题描述

在使用wrk压测中，测试结果提示Socket errors: connect 54,。测试中的wrk Client和Nginx Server建立连接失败，测试结果失效。

问题原因

该错误通常是因为客户端的连接数受限，导致客户端建立连接失败。

解决办法

为了避免该错误，请在压测机上检查系统的TCP连接配置，并尝试启用TCP连接重用。

1. 登录压测机，执行如下命令，查看是否开通TCP连接重用。

   sudo sysctl -n net.ipv4.tcp_tw_reuse

   命令输出为0或2，说明系统未完全开启TCP连接重用。

2. 执行如下命令，启用TCP连接重用。

   sudo sysctl -w net.ipv4.tcp_tw_reuse=1

3. 使用wrk工具再次发起压测请求。

   检查测试结果不再包含Socket errors: connect 54, ...的报错提示，说明测试结果有效。

为什么k8s-reclaimed-resource页签中，集群混部收益情况区域没有数据？

1. 查看是否已安装ack-koordinator组件。

   1. 登录容器服务管理控制台，在左侧导航栏单击集群列表。

   2. 在集群列表页面，单击目标集群名称，然后在左侧导航栏，选择应用 > Helm。

   3. 在Helm页面查看是否存在ack-koordinator组件。

      • 不存在：参见安装和管理组件安装ack-koordinator组件，然后执行下方步骤。

      • 已存在：直接执行下方步骤。

2. 查看在离线混部监控大盘是否显示相关数据。

   若不显示，请执行以下步骤：

   1. 登录ARMS控制台。

   2. 在左侧导航栏选择Prometheus监控 > 实例列表，进入可观测监控 Prometheus 版的实例列表页面。

   3. 在页面左上角选择目标地域，单击Prometheus实例名称，然后在左侧导航栏单击指标管理。

   4. 单击蓝色指标（Metrics）按钮，按照页面提示搜索并选择kube_node_labels，查看指标的数据详情。

是否可以使用Arm架构类型的竞价（Spot）实例？

目前已经提供Arm架构的竞价实例。关于使用方式，请参见使用抢占式实例。

在ACK集群中使用Arm架构节点有哪些限制？