Проблема AWS EKS CoreDNS в общедоступной подсети - PullRequest
Новая
       2

Проблема AWS EKS CoreDNS в общедоступной подсети

0 голосов
/ 31 января 2019

Я выполнил AWS EKS, используя их шаги по настройке.

AWS EKS ver 1.11, coredns

С помощью VPC я создаю две открытые и две частные подсети в соответствии с их документами: https://docs.aws.amazon.com/eks/latest/userguide/create-public-private-vpc.html

Узлы, развернутые в частной подсети, помечены как частные, а узлы, развернутые в общедоступной подсети, помечены как общедоступные.

Когда я развертываю модуль busybox для каждого узла nodeSelector (публичный / частный), общедоступный контейнерне может разрешить днс, в то время как частный может.

nslookup: can't resolve 'kubernetes.default'

Если я ssh подключусь к самому узлу общедоступной подсети, я смогу успешно пропинговать имена хостов (т.е. google.com).

Есть какие-нибудь мысли? 

# kubectl exec -it busybox-private -- nslookup kubernetes.default

Server:    172.20.0.10
Address 1: 172.20.0.10 ip-172-20-0-10.ec2.internal

Name:      kubernetes.default
Address 1: 172.20.0.1 ip-172-20-0-1.ec2.internal

# kubectl exec -it busybox-public -- nslookup kubernetes.default
Server:    172.20.0.10
Address 1: 172.20.0.10

nslookup: can't resolve 'kubernetes.default'
command terminated with exit code 1

# kubectl -n=kube-system get all
NAME                           READY     STATUS    RESTARTS   AGE
pod/aws-node-46626             1/1       Running   0          3h
pod/aws-node-52rqw             1/1       Running   1          3h
pod/aws-node-j7n8l             1/1       Running   0          3h
pod/aws-node-k7kbr             1/1       Running   0          3h
pod/aws-node-tr8x7             1/1       Running   0          3h
pod/coredns-7bcbfc4774-5ssnx   1/1       Running   0          20h
pod/coredns-7bcbfc4774-vxrgs   1/1       Running   0          20h
pod/kube-proxy-2c7gj           1/1       Running   0          3h
pod/kube-proxy-5qr9h           1/1       Running   0          3h
pod/kube-proxy-6r96f           1/1       Running   0          3h
pod/kube-proxy-9tqxt           1/1       Running   0          3h
pod/kube-proxy-bhkzx           1/1       Running   0          3h

NAME               TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)         AGE
service/kube-dns   ClusterIP   172.20.0.10   <none>        53/UDP,53/TCP   20h

NAME                        DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/aws-node     5         5         5         5            5           <none>          20h
daemonset.apps/kube-proxy   5         5         5         5            5           <none>          20h

NAME                      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/coredns   2         2         2            2           20h

NAME                                 DESIRED   CURRENT   READY     AGE
replicaset.apps/coredns-7bcbfc4774   2         2         2         20h

Прохождение "Отладка разрешения DNS" https://kubernetes.io/docs/tasks/administer-cluster/dns-debugging-resolution/

Странно, что в AWS все свои модули corens все еще помечены как kube-dns 

# kubectl get pods --namespace=kube-system -l k8s-app=kubedns
No resources found.

# kubectl get pods --namespace=kube-system -l k8s-app=kube-dns
NAME                       READY     STATUS    RESTARTS   AGE
coredns-7bcbfc4774-5ssnx   1/1       Running   0          20h
coredns-7bcbfc4774-vxrgs   1/1       Running   0          20h

# for p in $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name); do kubectl logs --namespace=kube-system $p; done
2019/01/31 15:23:36 [INFO] CoreDNS-1.1.3
2019/01/31 15:23:36 [INFO] linux/amd64, go1.10.5, d47c9319
.:53
CoreDNS-1.1.3
linux/amd64, go1.10.5, d47c9319
2019/01/31 15:23:36 [INFO] CoreDNS-1.1.3
2019/01/31 15:23:36 [INFO] linux/amd64, go1.10.5, d47c9319
.:53
CoreDNS-1.1.3
linux/amd64, go1.10.5, d47c9319

1 Ответ

0 голосов
/ 06 февраля 2019

Я думаю, что нашел проблему в группах безопасности рабочего узла.

Конечные точки и модули AWS EKS kube-dns находились в частной подсети.

У меня есть два стека CloudFormation .... один для автоматического масштабирования узлов в частных подсетях и один для автоматического масштабирования узлов в общих подсетях.

У них не было общей группы безопасности, поэтомумодули, работающие в общедоступных узлах, не смогли получить доступ к модулям kube-dns, работающим на частных узлах.

Как только я обновил группы безопасности рабочих узлов, чтобы разрешить перекрестную связь, DNS начал работать.

Пожалуйста, напишите, если кто-то видит непредвиденные последствия.Thx!

...