我正在尝试按照文档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状态。另外,请让我知道如何启用日志记录功能来调试此类问题。
答案 0 :(得分:0)
我找到了答案is not subscriber-editable。要进行Faragate部署,需要使用区域和vpc-id。
25px
答案 1 :(得分:0)
从 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 的最常见原因如下: