ALB Ingress FAQ

本文汇总了使用ALB Ingress时遇到的常见问题。

索引

为什么ALB Ingress规则不生效?

ALB实例是按照串行的方式维护路由规则。也就是说,如果多个ALB Ingress使用的是同一个ALB实例,那么一个ALB Ingress配置有问题,其他的ALB Ingress变更都不会生效。

如果您创建的ALB Ingress没有生效,那么有可能是之前创建的ALB Ingress发生了错误。您需要将错误的ALB Ingress修正为正确后,新创建的ALB Ingress才能生效。

ALB Ingress和Nginx Ingress有什么区别?

推荐您使用ALB Ingress,相较于Nginx Ingress需要您自己运维,ALB Ingress基于阿里云应用型负载均衡ALB(Application Load Balancer),属于全托管免运维的云服务,提供了更为强大的Ingress流量管理方式和高性能的网关服务。关于Nginx Ingress与ALB Ingress的对比详情,请参见Nginx Ingress、ALB Ingress和MSE Ingress对比

ALB后端默认监听转发到kube-system-fake-svc-80服务器组,该服务器组的作用是什么?

创建监听必须有一个默认转发规则,并且转发规则目前只支持转发到某个服务器组。所以,当前需要通过创建kube-system-fake-svc-80服务器组实现监听功能。该服务器组不参与业务处理,但不能被删除。

ALB Ingress是否支持同时使用公网和私网?

支持。如果您想同时使用公网和私网访问ALB Ingress,您需要创建公网ALB实例,该实例会在每个可用区创建一个公网EIP,ALB实例可以通过EIP与公网通信。同时,该实例还会提供一个私网VIP,您可以通过私网VIP访问ALB实例,实现从私网访问的效果。如果您只想私网访问ALB Ingress,建议您创建一个私网ALB实例。

为什么在集群中看不到ALB Ingress Controller Pod?

仅ACK专有版才能在kube-system命名空间下看到ALB Ingress Controller Pod。ACK标准版、ACK Pro版和ACK Serverless托管了ALB Ingress Controller组件,因此无法在集群中看到ALB Ingress Controller Pod。关于ACK专有版升级到ACK Pro版的具体操作,请参见热迁移ACK专有集群至ACK集群Pro版

如何保证ALB Ingress使用固定的ALB域名?

通过ALBConfig创建ALB实例之后,ALB Ingress会通过IngressClass引用ALBConfig,从而使用对应的ALB实例域名。如果ALB Ingress关联的IngressClass以及ALBConfig不做变更,则域名保持不变。

创建ACK托管版集群时选择使用ALB Ingress,是否会自动创建ALB实例?

不会。创建ACK托管版集群时选择ALB Ingress,将会安装ALB Ingress Controller,并不会自动创建ALB实例。

为什么在ALB控制台手动变更的配置会丢失,并且添加的规则会被删除,访问日志会被关闭?

ALB Ingress需要通过修改集群内资源来实现配置变更,相应的配置会以ALB Ingress或ALBConfig的形式保存在集群的APIServer中。在ALB控制台手动修改配置的行为并没有修改APIServer中的资源,所以修改的配置并不会生效。如果触发集群内调和操作,就会使用Ingress或ALBConfig中的配置对控制台配置进行变更,导致出现手动修改的配置被覆盖的现象。建议您通过修改ALB Ingress或AlbConfig来修改对应配置。

ALB Ingress转发规则创建后被立即删除,出现503状态码怎么办?

检查转发规则对应Ingress是否都配置了canary:true注解项。由于Canary灰度强制需要主干版本才能引流,所以对于主干版本的Ingress,不需要添加canary:true注解。关于如何使用ALB Ingress实现服务的灰度发布,请参见通过ALB Ingress实现灰度发布

Canary灰度方式仅支持两个Ingress且条件有限,推荐您使用自定义转发规则,使用更丰富的引流方案 。具体操作,请参见自定义ALB Ingress的转发规则

ALB Ingress无异常事件,但是变更不生效怎么办?

当出现未执行AlbConfig相关的调和事件,或者变更事件没有成功处理时,原因可能是IngressClass和AlbConfig的绑定关系错误。请按照使用文档检查IngressClass中指定的parameters参数是否正确。具体信息,请参见使用IngressClass关联AlbConfig与Ingress

在控制台上配置完创建的ALB实例后,使用kubectl apply命令更新AlbConfig的ACL(访问控制列表)配置,为什么会导致部分监听被删除?

说明

优先推荐使用kubectl edit命令直接更新资源的配置。如果必须使用kubectl apply命令来更新资源,请在执行kubectl apply命令之前先执行kubectl diff命令预览变更点,确保变更符合预期,然后再使用kubectl apply命令将变更应用到Kubernetes集群。

kubectl apply命令的语义会对ALBConfig进行覆盖式更新。因此,在使用kubectl apply命令更新ALBConfig的ACL配置时,请确保YAML文件中包含了完整的监听配置,以免未包含的监听被删除。

若执行kubectl apply命令后发现有监听被删除,推荐您按照以下方式进行恢复。

  1. 查看YAML文件中是否指定了完整的监听列表。

    若监听列表中缺少被删除的监听,请执行下一步操作。否则,无需执行。

  2. 执行以下命令,编辑对应的AlbConfig,将被删除的监听配置添加回来。

    kubectl -n <namespace> edit AlbConfig <albconfig-name> # 将<namespace>和<albconfig-name>分别替换为AlbConfig资源所在的命名空间和AlbConfig资源的名称。

如何优化Service中Pod变配场景下的Server调谐时间?

在Kubernetes环境下,Service进行Pod扩缩容时,Server调谐时间的长短可能受到关联的Ingress数量影响。为保证Server调谐效率,您可以采取以下措施:

  • 限制Ingress数量:同一个Service挂载的Ingress数不超过30条。

  • 合并Ingress规则:当Ingress数量过多时,您可以将多个Service挂载在同一个Ingress下,然后通过在同一个Ingress资源下定义多条转发规则来提升Server调谐性能。

在使用Flannel网络插件且Service配置为Local模式时,如何自动分配Node权重

说明

从v2.13.1-aliyun.1版本开始,ALB Ingress Controller支持自动设置节点权重。请确保您升级到最新版本以使用此功能。更多信息,请参见升级ALB Ingress Controller组件

本文以一个示例说明,在安装了Flannel插件的集群中,当Service设置为Local模式时,Node权重的计算方式。如下图所示,示例中业务Pod(app=nginx)部署在三台ECS上,通过Service A对外提供服务。

image

Service后端Pod的总数量

描述

Pod数量 <= 100个

ALB Ingress Controller会将每个节点上的Pod数量作为该节点的权重。

例如:如上图所示,三台ECS的Pod数量为1、2、3,则相应的ECS权重被设定为1、2、3。因此,流量将以1:2:3的比例分配至这三台ECS上,从而实现更均衡的Pod负载分配。

Pod数量 > 100个

ALB Ingress Controller将根据Node上部署的Pod数量占Pod总数的百分比计算Node权重。

例如:若上图中三台ECS上的Pod数量分别为100、200、300,则相应的ECS权重被设定为16、33、50。因此,流量将依照16:33:50的比例分配到这三台ECS上,以达到更平衡的Pod负载分布。