AGIC在Pod启动失败时删除可用ArgoCD后端的排查与隔离方案咨询

背景回顾 #

我们在AKS集群中使用Azure Gateway Ingress Controller（AGIC），它会自动为Ingress资源在应用网关上创建监听器和后端池。ArgoCD部署在集群内，负责从专属Git仓库拉取Helm Chart来创建应用；这些应用包含关联Azure存储文件的Persistent Volume Claim（PVC）用于存储用户数据，带特定标签的Ingress会触发AGIC在应用网关上生成对应配置。正常情况下，我们可以通过AGIC维护的应用网关，通过对应主机名访问ArgoCD及各应用。

遇到的问题场景：当某一Pod因PVC存储密钥错误启动失败时，AGIC会更新应用网关并删除仍正常运行的ArgoCD后端；而删除该故障Pod后，AGIC又会重新在应用网关上部署ArgoCD的HTTP后端。

1. 如何排查AGIC删除ArgoCD后端的原因？ #

你可以按以下步骤逐步定位问题：

• 查看AGIC核心日志：AGIC Pod通常运行在kube-system命名空间，执行命令提取近期日志：

  kubectl logs -n kube-system <agic-pod-name> --tail=1000
  

  重点搜索和ArgoCD、backend pool、delete、update相关的条目，AGIC会记录它对应用网关配置的每一次变更决策。
• 检查ArgoCD的Ingress资源状态：查看Ingress的事件和状态，确认是否有异常触发了AGIC的变更：

  kubectl describe ingress <argocd-ingress-name> -n <argocd-namespace>
  

  关注Events字段，看是否有与Endpoint变更、AGIC同步相关的提示。
• 验证ArgoCD的Endpoint状态：AGIC是基于K8s Endpoint资源维护应用网关后端的，检查ArgoCD服务对应的Endpoint是否正常：

  kubectl get endpoints <argocd-service-name> -n <argocd-namespace>
  

  同时也要检查故障Pod所在命名空间的Ingress和Endpoint，确认是否是这些资源的异常干扰了AGIC的全局同步逻辑。
• 查看应用网关的配置变更历史：在Azure门户中进入对应的应用网关，查看「活动日志」，筛选「更新应用网关」的操作，查看操作详情中的变更内容，确认ArgoCD后端被删除的时间点和关联触发因素。

2. 是否可启用详细日志来了解AGIC的部署决策逻辑？ #

当然可以，你可以通过以下方式开启AGIC的调试级日志：

• 通过Helm升级调整日志级别：如果AGIC是通过Helm安装的，执行以下命令将日志级别设为debug：

  helm upgrade ingress-azure ingress-azure/ingress-azure \
    --namespace kube-system \
    --set controller.logging.level=debug
  

• 直接修改AGIC Deployment：如果不是Helm安装，编辑AGIC的Deployment，添加或修改环境变量LOG_LEVEL为debug：

  kubectl edit deployment ingress-azure -n kube-system
  

  在spec.template.spec.containers[0].env中添加：

  - name: LOG_LEVEL
    value: debug
  

  保存后AGIC Pod会重启，此时日志会包含更详细的决策过程——比如它如何遍历Ingress资源、评估Endpoint状态、生成应用网关配置的每一步细节。

3. 不同命名空间下，如何隔离ArgoCD与其他Pod，避免Pod故障影响ArgoCD后端？ #

你可以通过以下两种核心方式实现隔离：

• 使用IngressClass创建独立AGIC实例：

  1. 为ArgoCD创建专属的IngressClass资源：

     apiVersion: networking.k8s.io/v1
     kind: IngressClass
     metadata:
       name: argocd-agic
     spec:
       controller: azure.io/ingress-azure
     

  2. 部署一个新的AGIC实例，指定它只处理这个IngressClass，并且关联到独立的应用网关（或同一网关的独立路由规则）：

     helm install argocd-agic ingress-azure/ingress-azure \
       --namespace kube-system \
       --set controller.ingressClass=argocd-agic \
       --set appgw.name=<your-argocd-appgw-name> \
       --set appgw.resourceGroup=<your-resource-group>
     

  3. 修改ArgoCD的Ingress资源，指定使用这个专属IngressClass：

     apiVersion: networking.k8s.io/v1
     kind: Ingress
     metadata:
       name: argocd-ingress
       namespace: argocd
     spec:
       ingressClassName: argocd-agic
       # 其他Ingress配置...
     

  这样ArgoCD的应用网关配置由独立的AGIC实例管理，其他命名空间的Pod故障不会影响它的后端配置。

• 限制AGIC的命名空间监听范围：
  如果不想部署多个AGIC，可以修改现有AGIC的配置，让它只监听ArgoCD所在命名空间和你信任的应用命名空间，排除可能出故障的命名空间：

  helm upgrade ingress-azure ingress-azure/ingress-azure \
    --namespace kube-system \
    --set controller.watchNamespace=argocd,trusted-app-namespace
  

  或者通过环境变量WATCH_NAMESPACE指定：

  kubectl set env deployment/ingress-azure -n kube-system WATCH_NAMESPACE=argocd,trusted-app-namespace
  

  这样AGIC只会处理指定命名空间内的Ingress资源，其他命名空间的Pod故障不会触发AGIC的全局配置变更。

内容的提问来源于stack exchange，提问作者Joon