AWS负载均衡器无法部署

问题描述

我正在尝试按照文档https://docs.aws.amazon.com/eks/latest/userguide/alb-ingress.html

中的步骤通过EKS创建AWS ALB-Ingress

我成功地完成了创建控制器的第7步：

[ec2-user@ip-X-X-X-X eks-cluster]$ kubectl apply -f v2_0_0_full.yaml 
customresourcedefinition.apiextensions.k8s.io/targetgroupbindings.elbv2.k8s.aws created 
mutatingwebhookconfiguration.admissionregistration.k8s.io/aws-load-balancer-webhook created 
Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply 
serviceaccount/aws-load-balancer-controller configured 
role.rbac.authorization.k8s.io/aws-load-balancer-controller-leader-election-role created 
clusterrole.rbac.authorization.k8s.io/aws-load-balancer-controller-role created 
rolebinding.rbac.authorization.k8s.io/aws-load-balancer-controller-leader-election-rolebinding created 
clusterrolebinding.rbac.authorization.k8s.io/aws-load-balancer-controller-rolebinding created 
service/aws-load-balancer-webhook-service created 
deployment.apps/aws-load-balancer-controller created 
certificate.cert-manager.io/aws-load-balancer-serving-cert created 
issuer.cert-manager.io/aws-load-balancer-selfsigned-issuer created 
validatingwebhookconfiguration.admissionregistration.k8s.io/aws-load-balancer-webhook created

但是，控制器不会进入“就绪”状态：

[ec2-user@ip-X-X-X-X eks-cluster]$ kubectl get deployment -n kube-system aws-load-balancer-controller
NAME                           READY   UP-TO-DATE   AVAILABLE   AGE
aws-load-balancer-controller   0/1     1            0           29m

我还可以列出与控制器关联的窗格，该窗格还显示未就绪：

[ec2-user@ip-X-X-X-X eks-cluster]$ kubectl get pods -n kube-system
NAME                                            READY   STATUS    RESTARTS   AGE
aws-load-balancer-controller-XXXXXXXXXX-p4l7f   0/1     Pending   0          30m

我似乎也无法获取日志以尝试调试问题：

[ec2-user@ip-X-X-X-X eks-cluster]$ kubectl -n kube-system logs aws-load-balancer-controller-XXXXXXXXXX-p4l7f
[ec2-user@ip-X-X-X-X eks-cluster]$

此外，/ var / log目录也没有任何相关的日志。

请帮助我了解为什么它没有进入READY状态。另外，请让我知道如何启用日志记录功能来调试此类问题。

解决方法

我找到了答案is not subscriber-editable。要进行Faragate部署，需要使用区域和vpc-id。

25px

,

从 current LB conntroller manifest 中我发现 LB 控制器 Pod 规范没有 Readiness probe，只有 Liveness probe。这意味着 Pod 一通过 Liveness 探测就变成 Ready：

      livenessProbe:
        failureThreshold: 2
        httpGet:
          path: /healthz
          port: 61779
          scheme: HTTP
        initialDelaySeconds: 30
        timeoutSeconds: 10

但正如我们在以下输出中看到的，LB 控制器的 Pod 处于 Pending 状态：

[ec2-user@ip-X-X-X-X eks-cluster]$ kubectl get pods -n kube-system
NAME                                            READY   STATUS    RESTARTS   AGE
aws-load-balancer-controller-XXXXXXXXXX-p4l7f   0/1     Pending   0          30m

如果 Pod 保持在 Pending 状态，则意味着 kube-scheduler 无法将 Pod 绑定到集群节点，无论出于何种原因。

Kube-scheduler 是 Kubernetes 控制平原的一部分，负责将 Pod 分配给节点。

此阶段没有Pod日志，因为Pod的容器还没有启动。

检查原因最方便的方法是使用 kubectl describe 命令：

kubectl describe pod/podname -n namespacename

在输出的底部有与 Pod 生命周期相关的事件列表。以下是通用 Ubuntu Pod 的示例：

Events:
  Type    Reason     Age                From               Message
  ----    ------     ----               ----               -------
  Normal  Scheduled  37s                default-scheduler  Successfully assigned default/ubuntu to k8s-w1
  Normal  Pulling    25s (x2 over 35s)  kubelet,k8s-w1    Pulling image "ubuntu"
  Normal  Pulled     23s (x2 over 30s)  kubelet,k8s-w1    Successfully pulled image "ubuntu"
  Normal  Created    23s (x2 over 30s)  kubelet,k8s-w1    Created container ubuntu
  Normal  Started    23s (x2 over 29s)  kubelet,k8s-w1    Started container ubuntu

kubectl get events 命令也可以显示问题。例如：

LAST SEEN   TYPE     REASON      OBJECT       MESSAGE
21s         Normal   Scheduled   pod/ubuntu   Successfully assigned default/ubuntu to k8s-w1
9s          Normal   Pulling     pod/ubuntu   Pulling image "ubuntu"
7s          Normal   Pulled      pod/ubuntu   Successfully pulled image "ubuntu"
7s          Normal   Created     pod/ubuntu   Created container ubuntu
7s          Normal   Started     pod/ubuntu   Started container ubuntu

或者调度器无法将 Pod 分配给节点的原因可能是：

"No nodes are available that match all of the predicates: Insufficient cpu (2),Insufficient memory (2)". 

在某些情况下，可能会在 kube-scheduler 命名空间中的 kube-system Pod 日志中发现错误。可以使用以下命令列出日志：

kubectl logs $(kubectl get pods -l component=kube-scheduler,tier=control-plane -n kube-system -o name) -n kube-system 

未安排 Pod 的最常见原因如下：

• 节点上的 Pod 请求的 CPU 或内存不足 resources。
• Pod 不能容忍 Taints on the Nodes
• Pod 具有 Affinity/AntiAffinity 配置，阻止其调度
• 无法满足 Pod 规范中的存储或 other 特定资源（如 GPU）要求