Вопрос или проблема
Я создал ЧАСТНЫЙ кластер EKS с помощью консоли AWS. Затем я следовал документации для настройки Fargate. После завершения я увидел свои узлы Fargate в разделе Compute моего кластера в консоли AWS, но поды CoreDNS, работающие на узлах, не могут запуститься, когда происходит загрузка изображения:
$ kubectl get pods -n kube-system
NAME READY STATUS RESTARTS AGE
coredns-58488c5db-j8l9f 0/1 Pending 0 2d2h
coredns-7c969d8cd7-7xztr 0/1 ImagePullBackOff 0 3h30m
coredns-7c969d8cd7-mh6z2 0/1 ImagePullBackOff 0 3h30m
Еще одна вещь, которую я заметил, это то, что в пространстве имен kube-system нет конечных точек:
kubectl -n kube-system get endpoints kube-dns
NAME ENDPOINTS AGE
kube-dns 2d2h
Вот описание одного из подов:
Containers:
coredns:
Container ID:
Image: 602401143452.dkr.ecr.us-east-1.amazonaws.com/eks/coredns:v1.10.1-eksbuild.2
Image ID:
Ports: 53/UDP, 53/TCP, 9153/TCP
Host Ports: 0/UDP, 0/TCP, 0/TCP
Args:
-conf
/etc/coredns/Corefile
State: Waiting
Reason: ImagePullBackOff
Ready: False
Restart Count: 0
Limits:
memory: 170Mi
Requests:
cpu: 100m
memory: 70Mi
Liveness: http-get http://:8080/health delay=60s timeout=5s period=10s #success=1 #failure=5
Readiness: http-get http://:8080/health delay=0s timeout=1s period=10s #success=1 #failure=3
Environment: <none>
Mounts:
/etc/coredns from config-volume (ro)
/tmp from tmp (rw)
/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-9mhnd (ro)
Conditions:
Type Status
Initialized True
Ready False
ContainersReady False
PodScheduled True
Volumes:
tmp:
Type: EmptyDir (временный каталог, который разделяет жизненный цикл пода)
Medium:
SizeLimit: <unset>
config-volume:
Type: ConfigMap (том, заполняемый ConfigMap)
Name: coredns
Optional: false
kube-api-access-9mhnd:
Type: Projected (том, который содержит внедренные данные из нескольких источников)
TokenExpirationSeconds: 3607
ConfigMapName: kube-root-ca.crt
ConfigMapOptional: <nil>
DownwardAPI: true
QoS Class: Burstable
Node-Selectors: <none>
Tolerations: CriticalAddonsOnly op=Exists
node-role.kubernetes.io/master:NoSchedule
node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning Failed 45m (x5 over 4h40m) kubelet Не удалось загрузить изображение "602401143452.dkr.ecr.us-east-1.amazonaws.com/eks/coredns:v1.10.1-eksbuild.2": не удалось загрузить и распаковать изображение "602401143452.dkr.ecr.us-east-1.amazonaws.com/eks/coredns:v1.10.1-eksbuild.2": не удалось разрешить ссылку "602401143452.dkr.ecr.us-east-1.amazonaws.com/eks/coredns:v1.10.1-eksbuild.2": не удалось выполнить запрос: Head "https://602401143452.dkr.ecr.us-east-1.amazonaws.com/v2/eks/coredns/manifests/v1.10.1-eksbuild.2": dial tcp 54.211.105.2:443: время ожидания ввода-вывода
Warning Failed 25m (x10 over 4h42m) kubelet Не удалось загрузить изображение "602401143452.dkr.ecr.us-east-1.amazonaws.com/eks/coredns:v1.10.1-eksbuild.2": не удалось загрузить и распаковать изображение "602401143452.dkr.ecr.us-east-1.amazonaws.com/eks/coredns:v1.10.1-eksbuild.2": не удалось разрешить ссылку "602401143452.dkr.ecr.us-east-1.amazonaws.com/eks/coredns:v1.10.1-eksbuild.2": не удалось выполнить запрос: Head "https://602401143452.dkr.ecr.us-east-1.amazonaws.com/v2/eks/coredns/manifests/v1.10.1-eksbuild.2": dial tcp 34.198.77.233:443: время ожидания ввода-вывода
Normal BackOff 10m (x915 over 4h43m) kubelet Ожидание загрузки изображения "602401143452.dkr.ecr.us-east-1.amazonaws.com/eks/coredns:v1.10.1-eksbuild.2"
Warning Failed 5m9s (x10 over 4h34m) kubelet Не удалось загрузить изображение "602401143452.dkr.ecr.us-east-1.amazonaws.com/eks/coredns:v1.10.1-eksbuild.2": не удалось загрузить и распаковать изображение "602401143452.dkr.ecr.us-east-1.amazonaws.com/eks/coredns:v1.10.1-eksbuild.2": не удалось разрешить ссылку "602401143452.dkr.ecr.us-east-1.amazonaws.com/eks/coredns:v1.10.1-eksbuild.2": не удалось выполнить запрос: Head "https://602401143452.dkr.ecr.us-east-1.amazonaws.com/v2/eks/coredns/manifests/v1.10.1-eksbuild.2": dial tcp 52.207.2.251:443: время ожидания ввода-вывода
Normal Pulling 5s (x47 over 4h45m) kubelet Загружается изображение "602401143452.dkr.ecr.us-east-1.amazonaws.com/eks/coredns:v1.10.1-eksbuild.2"
Что может происходить? Я не хочу создавать другой кластер, как это предложено в https://stackoverflow.com/questions/66996306/aws-eks-fargate-coredns-imagepullbackoff
Согласно сообщению об ошибке, поды fargate не могут достичь конечной точки ecr для загрузки изображения coredns. Проверьте
- Подсеть, связанная с профилем fargate, имеет маршрут к ecr (либо через nat gateway, tgw или конечные точки vpc).
- Группа безопасности, связанная с вашим подом coredns fargate (по умолчанию группа безопасности кластера), позволяет исходящий интернет-трафик.
- Правила входящего и исходящего трафика для ваших списков управления сетевым доступом (ACL) позволяют доступ к ecr.
Я смог восстановить свой кластер Fargate EKS, проверив и добавив правила в входящие и исходящие правила NetworkACL
Большое спасибо, приятель
Ответ или решение
Проблемы с извлечением образа CoreDNS в AWS EKS Fargate: Полное решение
Проблема, с которой вы столкнулись в своем частном кластере AWS EKS, вызвана невозможностью контейнеров CoreDNS извлечь нужный образ из Amazon ECR. Это, в свою очередь, приводит к статусу ImagePullBackOff
для ваших CoreDNS
подов, что критически влияет на работу DNS в вашем кластере.
Причины проблемы
Судя по предоставленной информации, ошибка предполагает, что ваши поды не могут связаться с ECR, чтобы загрузить нужные Docker-образы. Основные возможные причины включают:
-
Неправильная маршрутизация: Подфайлы, связанные с Fargate, должны иметь корректные маршруты к ECR. Если ваш кластер размещен в частной сети, убедитесь, что существует NAT-шлюз или VPC, которые предоставляют доступ к интернету для ваших подов.
-
Ограничения безопасности: Проверьте настройки групп безопасности, связанных с вашим Fargate-профилем. Группы безопасности должны обеспечивать исходящий трафик в интернет, обеспечивая доступ к ECR.
-
Настройки сетевых ACL: Убедитесь, что ваши сетевые ACL позволяют входящий и исходящий трафик к необходимым IP-адресам, связанным с ECR.
Решения пошагово
Для устранения проблемы выполните следующие действия:
1. Проверка маршрутов и NAT-шлюза
Убедитесь, что подсети, ассоциированные с вашим профилем Fargate, имеют маршруты для доступа к ECR:
- Если кластер находится в частной подсети, должен быть NAT-шлюз, направляющий трафик в интернет.
- Убедитесь, что маршрут для интернет-целевого объекта (0.0.0.0/0) направлен на NAT-шлюз.
2. Проверка групп безопасности
Проверьте настройки групп безопасности, связанные с вашим Fargate-профилем:
- Убедитесь, что существует правило, разрешающее исходящий трафик на порту 443, что необходимо для доступа к ECR.
- Убедитесь, что другие услуги AWS (например, EKS) разрешены, если они устанавливают связь.
3. Проверка сетевых ACL
Убедитесь, что ваши сетевые ACL не блокируют трафик:
- Для тех же IP-адресов и портов (логично использовать 443 для HTTPS-запросов).
- Добавьте необходимые разрешения для исходящего и входящего трафика.
Проверка и тестирование
После проверки и внесения изменений выполните следующую команду для обновления статуса ваших подов:
kubectl get pods -n kube-system
Ожидайте, что статус ваших подов изменится на Running
. Убедитесь, что вы видите конечные точки для kube-dns
:
kubectl -n kube-system get endpoints kube-dns
Заключение
Решение проблемы с извлечением образов в EKS Fargate требует стратегического подхода к сетевой конфигурации. Проверяя маршруты, настройки групп безопасности и сетевых ACL, вы сможете устранить большинство проблем. Если проблемы продолжают возникать, стоит провести дополнительное тестирование на уровне сети или поднять вопрос в официальном AWS поддержке.
Надеюсь, это руководство поможет вам восстановить работоспособность вашего кластера EKS и вернуть услуги DNS в состояние функциональности!