咨询：Kubernetes LoadBalancer External-IP一直Pending的排查方法

问题背景 #

在Ubuntu虚拟机搭建的Kubernetes 1.26集群（使用containerd作为容器运行时）中，包含1个控制平面节点和2个Ubuntu工作节点。创建Deployment与LoadBalancer类型的Service后，执行kubectl get services发现该Service的External-IP始终显示为Pending。执行kubectl describe service stable-service未发现明显错误，此前同类型Service部署正常，删除后才部署当前资源。

对应的配置文件：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: stable-deployment
spec:
  replicas: 4
  selector:
    matchLabels:
      app: aspnetcore
      track: stable
  template:
    metadata:
      labels:
        app: aspnetcore
        track: stable
    spec:
      containers:
      - name: stable-app
        image: stable-app
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
        readinessProbe:
          httpGet:
            path: /
            port: 80
        resources: {}


kind: Service
apiVersion: v1
metadata:
  name: stable-service
  labels:
    app: aspnetcore
spec:
  type: LoadBalancer
  selector:
    app: aspnetcore
  ports:
    - port: 80
      targetPort: 80

排查与解决步骤 #

• 集群需配置LoadBalancer控制器才能分配External-IP，裸金属集群默认无此组件。之前正常运行大概率是部署过MetalLB，若删除旧Service时误删了MetalLB资源，执行kubectl get pods -n metallb-system确认组件状态，缺失则重新部署。
• 确认Service与Pod标签匹配：执行kubectl get pods --show-labels，确保所有运行的Pod都带有app: aspnetcore标签，当前配置中标签匹配逻辑正常，但需避免部分Pod标签缺失。
• 若使用MetalLB，检查节点网络是否开启ARP广播，且LoadBalancer IP池在局域网内可达、未被占用，执行ip a查看节点网卡IP，核对MetalLB的IP池配置。
• 清理旧Service残留资源：执行kubectl delete endpoints stable-service后重新创建Service，或用kubectl apply -f <配置文件路径>强制更新资源。
• 检查kube-proxy状态：执行kubectl get pods -n kube-system | grep kube-proxy，确保所有节点的kube-proxy Pod处于Running状态，异常则删除重启对应Pod。
• 查看控制器日志：若部署了MetalLB，执行kubectl logs -n metallb-system <controller-pod-name>排查异常；或查看kube-controller-manager日志：kubectl logs -n kube-system kube-controller-manager-<控制平面节点名>。

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