KubeSphere网关使用LoadBalancer时，为何外部无法访问服务？

Question

KubeSphere网关启用LoadBalancer类型Service后外部仍无法访问，常见原因有三：一是底层云平台（如AWS/Aliyun）未成功分配公网IP或SLB实例，导致Service的`EXTERNAL-IP`字段为``；二是集群所在节点安全组/防火墙未放行LoadBalancer监听端口（如80/443）及健康检查端口；三是KubeSphere网关组件（基于nginx-ingress-controller或istio-ingressgateway）未正确部署、处于CrashLoopBackOff状态，或其Pod未被LoadBalancer后端正确纳管（如label selector不匹配、namespace隔离）。此外，MetalLB等裸金属方案若未配置IP地址池或ARP/NDP通告异常，也会导致IP不可达。排查需依次验证`kubectl get svc -n kubesphere-controls-system ks-console`的EXTERNAL-IP状态、云厂商负载均衡控制台日志、ingress-controller Pod就绪情况及NodePort连通性。

Answer 1

```html

一、现象层：EXTERNAL-IP 为空——云平台资源未就绪

执行 kubectl get svc -n kubesphere-controls-system ks-console，若输出中 EXTERNAL-IP 列为空（<pending> 或空白），表明 Kubernetes 未能从底层云厂商获取负载均衡器实例。这并非 KubeSphere 配置错误，而是云基础设施层未响应 Service 创建请求。

常见于：AWS EKS 未启用 aws-load-balancer-controller；阿里云 ACK 未安装 alb-ingress-controller 或 SLB 权限不足；腾讯云 TKE 中 CLB 组件未授权或配额耗尽。

云平台	关键检查项	验证命令示例
AWS	是否部署 aws-load-balancer-controller？IAM Role 是否绑定 ALB/ELB 权限？	kubectl get deploy -n kube-system aws-load-balancer-controller
阿里云	SLB 实例是否在控制台生成？安全组是否关联至后端节点？	aliyun slb DescribeLoadBalancers --RegionId cn-hangzhou

二、网络层：安全组与防火墙策略阻断流量路径

即使 EXTERNAL-IP 已分配，外部仍无法访问，需排查三层网络通路：① 云平台 SLB → Node 节点（入向安全组）；② Node → ingress-controller Pod（NodePort 或 HostNetwork 模式）；③ 健康检查端口（如 /healthz 默认 10254）是否被拦截。

典型误配置：阿里云安全组仅放行 80/443，但未开放健康检查端口（如 nginx-ingress 的 10254）；AWS 安全组未允许来自 SLB CIDR 的源 IP；物理服务器防火墙（firewalld/iptables）DROP 了 NodePort 流量（如 30080/30443）。

三、控制平面层：ingress-controller 生命周期与调度异常

KubeSphere 网关依赖 nginx-ingress-controller（v3.4+ 默认）或 istio-ingressgateway，其 Pod 必须满足：Running + Ready = True，且标签匹配 LoadBalancer Service 的 selector，且处于同一 namespace（kubesphere-controls-system）。

高频故障场景：

• Pod 处于 CrashLoopBackOff：检查日志 kubectl logs -n kubesphere-controls-system deploy/nginx-ingress-controller，常见因 ConfigMap 引用错误、RBAC 权限缺失、或 hostPort 冲突；
• Label selector 不一致：Service 的 selector.app: nginx-ingress 与 Pod 的 app.kubernetes.io/name: ingress-nginx 不匹配；
• Taint/Toleration 隔离：控制器被调度至带 node-role.kubernetes.io/control-plane:NoSchedule 的 Master 节点，而该节点未开启 --allow-privileged 导致挂载失败。

四、裸金属适配层：MetalLB 配置与协议通告失效

在非云环境（如 VMware/vSphere/物理机集群）启用 LoadBalancer，必须部署 MetalLB，并完成两阶段配置：

1. 地址池定义：通过 ConfigMap 分配可用 IP 段，例如 192.168.10.100-192.168.10.110；
2. 协议层通告：Layer2 模式需确保 ARP 响应可达（交换机未启用 port-security）；BGP 模式需正确配置邻居与路由策略。

验证命令：kubectl get cm -n metallb-system config -o yaml；kubectl get pods -n metallb-system；arping -I eth0 192.168.10.105 测试 ARP 可达性。

五、端到端连通性验证流程图

flowchart TD
    A[执行 kubectl get svc -n kubesphere-controls-system ks-console] --> B{EXTERNAL-IP 是否为 <pending>？}
    B -->|是| C[检查云厂商控制台 SLB/ALB 实例状态]
    B -->|否| D[确认 EXTERNAL-IP 是否可 ping / telnet 80]
    C --> E[验证云组件部署 & IAM 权限]
    D --> F{telnet 成功？}
    F -->|否| G[检查 Node 安全组/防火墙/路由表]
    F -->|是| H[进入 Pod 层：kubectl get pods -n kubesphere-controls-system -l app=nginx-ingress]
    H --> I{Pod Ready？}
    I -->|否| J[kubectl describe pod / logs]
    I -->|是| K[验证 NodePort 连通性：curl http://NODE_IP:NODE_PORT/healthz]

六、高阶诊断技巧：跨组件依赖链快照

运行以下复合诊断脚本（建议保存为 ks-gateway-debug.sh）：

#!/bin/bash
echo "== 1. Service 状态 =="; kubectl get svc -n kubesphere-controls-system ks-console -o wide
echo -e "\n== 2. Ingress Controller Pod =="; kubectl get pods -n kubesphere-controls-system -l app=nginx-ingress -o wide
echo -e "\n== 3. Endpoints 关联 =="; kubectl get endpoints -n kubesphere-controls-system ks-console
echo -e "\n== 4. NodePort 映射 =="; kubectl get svc -n kubesphere-controls-system nginx-ingress-controller -o jsonpath='{.spec.ports[?(@.name==\"http\")].nodePort}'
echo -e "\n== 5. MetalLB 检查 =="; kubectl get pods -n metallb-system 2>/dev/null || echo "MetalLB not installed"

输出结果可直接用于 SRE 故障单提报，包含 Service→Endpoints→Pod→NodePort 全链路快照。

```