驱逐及防护

驱逐场景说明

包括但不限于以下场景，ACS可能会发起对用户Pod的驱逐操作：

• 节点异常（NotReady）：ACS产品中节点由阿里云管理，用户不需要感知，但您的Pod仍需调度和运行在这些节点之上。当某节点因宕机或其他原因处于NotReady异常状态时，ACS将启动节点自愈流程，此时节点上的Pod将会被驱逐。

• 节点升级：升级节点内核或其他模块时，可能需要触发节点重启操作，在节点重启前，ACS会先将节点上的所有Pod进行驱逐。

• 资源调度运营：ACS为了优化资源使用效率，会不定期进行资源运维操作，此时可能会将一些Pod进行驱逐腾挪，以进行资源碎片整合等资源效率优化操作。

• 任务型实例过期释放：ACS对任务型实例的运行时长有限制。在公测期间，单个实例的最大运行时长为24小时。若任务型实例创建24小时后仍在运行，会因过期释放而被强制驱逐，在被释放前，您将收到相关的通知信息，您可以基于此通知对实例做优雅退出或保存中间结果等操作。对于任务型实例，ACS默认将提前10分钟发送驱逐决议通知。

针对上述驱逐场景类型的不同，ACS将这些驱逐场景分成两类：一类是异常场景下的被动驱逐场景，包括节点异常和资源质量保证这两类场景；另一类是正常场景下的主动驱逐场景，包括节点升级和资源调度运营。

• 在被动驱逐场景下，由于已经发生异常并且正在进行自愈，所以对于此类型的驱逐ACS不会做过多防护。

• 在主动驱逐场景下，由于Pod和节点处于正常状态，所以对此类型的驱逐ACS会提供一些防护策略。

但是，不管是哪类场景，为保证您服务的连续性，仍然需要您尽可能使用多副本部署等高可用部署策略来部署您的应用。

高可用基本配置

• 您需要使用Deployment等能够进行副本保持的Workload进行服务部署，而不是裸Pod，以确保旧Pod被驱逐后，新的Pod能够及时创建。

• 您需要在Workload层面做多副本部署，以保证在发生驱逐时，您的服务尽可能不会被中断。对于单副本Workload以及裸Pod，ACS在进行驱逐时将无法保证应用整体的可用性。

• 您需要将需要持久化的数据保存到独立的云存储上，或者上传日志到日志服务上，避免Pod驱逐后容器的数据丢失。

• 您需要正确配置容器的启动后处理，停止前处理命令或者信号处理器（Signal handler），保证驱逐的Pod、以及新创建的Pod能够优雅地上下线。

• 您需要正确配置暴露的服务（K8s Service），或者中间件、服务网格等的服务发现机制，保证驱逐的Pod、以及新创建的Pod能够被应用发现，从而保证服务的可用性和容量。

驱逐防护说明

ACS针对驱逐场景下的用户应用可用性防护，提供了丰富的策略供用户选择。除宕机等非计划内的被动驱逐场景以外，ACS默认只在您设置的集群运维窗口时间内进行驱逐动作，并在驱逐前几分钟通过Kubernetes Event向您的集群推送事件通知，您可以通过事件中心配置相应的告警规则。在一些特殊场景下，我们也将允许您设置一个容器最小运行时间来保障一些任务型应用的执行完成。

干扰预算机制（Pod Disruption Budgets，PDB）

PDB是Kubernetes提供的一种应用级别的驱逐防护策略，用来保证驱逐场景Workload层面的服务可用性，它可以对任意支持Scale子资源的Workload类型生效，包括原生的Deployment或者您自定义的CRD。

如果您配置了PDB策略，ACS在做驱逐动作时会尽可能遵循PDB的防护策略。但是，如果ACS长时间驱逐失败，则最长等待1h后，会对驱逐失败的Pod进行强制驱逐操作（Delete）。

ACS默认防护

类似PDB防护策略，ACS在驱逐时也会针对具有Scale子资源Workload生产的Pod，进行Workload维度的可用性防护。默认情况下，会保证至少50%的Pod处于Ready的情况下才允许触发ACS主动驱逐的逻辑。但对于不满足Scale子资源Workload生产的Pod或者裸Pod，默认没有此类防护策略。ACS默认防护和您配置的PDB策略不会冲突，可同时生效。

集群维护窗口设置

为了更好地保障您的服务可用性，ACS允许您为您的ACS集群设置一个维护窗口，ACS所有的主动驱逐操作都只会在维护窗口期内执行，以最大程度避开您业务高峰期，降低驱逐动作对您的业务带来的影响。

您可以在集群创建时，或在您的ACS集群的集群信息/基本信息页面的集群维护栏，进行维护窗口的设置和调整。另外，ACS保证每个Pod在一次维护窗口时间内，不会被多次发起主动驱逐。

最小运行时长保障

对于一些不可中断的计算型任务，如果您期望这类Pod在一定时间内不被主动驱逐，您可以预估一个计算任务执行的最长时间，并且在Pod的Annotation上进行标注，我们将会根据您的设置来尽可能保障Pod在期望的运行时长内不会被主动驱逐。例如，您希望您的Pod至少运行3小时后才能被主动驱逐，只需要在Pod上填写Annotation alibabacloud.com/ensure-running-duration: 3h，则ACS会对Pod发起的主动驱逐进行延后处理，以Pod.Status.StartAt为时间基准，确保Pod在此3h之后的第一个维护窗口期，Pod才能被主动驱逐。您最长可以设置24小时的最小运行时长保障。

任务型实例过期释放

ACS对任务型实例的运行时长有限制。在公测期间，单个实例的最大运行时长为24小时。若任务型实例创建24小时后仍在运行，会因过期释放而被强制驱逐，在被释放前，您将收到相关的通知信息，您可以基于此通知对实例做优雅退出或保存中间结果等操作。对于任务型实例，ACS默认将提前10分钟发送驱逐决议通知。更多信息，请参见 任务型实例概述。

注意：任务型实例达到最大运行时长24小时被强制驱逐时，将不会受到 PDB、集群运维窗口 等保护，但是会提前十分钟发送驱逐决议通知。如下：

27s         Warning   ScheduledEviction         pod/pod-zg7s6r   The pod will be evicted after 10m0s at 2023-10-22 15:49:56 +0800 CST, reason: pod is expired because best-effort instance can only run maximum 24h duration

驱逐通知说明

ACS进行的主动驱逐操作时，在真正驱逐之前，会通过Kubernetes Event的方式进行通知，您可以使用事件监控来配置相应的告警策略，以便您能及时发现和处理此类问题。

驱逐通知分为以下两个阶段：

• 驱逐提名通知：当Pod被提名驱逐时，表示ACS因为某些原因期望该Pod被驱逐出Node，但是该驱逐动作可能会被驱逐防护策略所拦截。只要Pod被提名驱逐，就会向用户集群发送Reason为NominatedEviction的事件通知。

  27s         Warning   ProposedEviction          pod/pod-zg7s6r   The pod is nominated to be evicted at 2023-10-22 15:39:56 +0800 CST, reason: node upgrading

• 驱逐决议通知：当Pod被决定驱逐时，表示驱逐提名已经获得通过，已满足除用户配置的PDB以外的其他防护条件，可以被尝试驱逐。默认会在尝试驱逐前10min向用户发送Reason为DeterminedEviction的事件通知。

  27s         Warning   ScheduledEviction         pod/pod-zg7s6r   The pod will be evicted after 10m0s at 2023-10-22 15:49:56 +0800 CS, reason: node upgrading

此外，为了方便用户订阅驱逐事件，还会通过 Pod Status.Condition type=PodEviction 进行通知，如下：

apiVersion: v1
kind: Pod
status:
 conditions:
 - lastProbeTime: null
   lastTransitionTime: "2024-02-01T06:02:36Z"
   status: "True"
   type: PodEviction
   reason: ProposedEviction | ScheduledEviction
   message: "The pod will be evicted after 10m0s at 2023-10-22 15:49:56 +0800 CST, reason: pod reaches 24H maximum hour limit"

您可以利用上述通知机制，提前执行相应的应对策略来降低驱逐对您的业务带来的影响。