web-dev-qa-db-ja.com

プライベートサブネットで実行中のAWS EKSのDNS問題

VPCにEKSクラスターがセットアップされています。ワーカーノードはプライベートサブネットで起動されます。ポッドとサービスを正常にデプロイできます。

ただし、ポッド内からDNS解決を実行することはできません。 （コンテナーの外のワーカーノードでは正常に動作します。）

https://kubernetes.io/docs/tasks/administer-cluster/dns-debugging-resolution/ を使用したトラブルシューティングでは、nslookupから次のような結果になります（1分程度のタイムアウト）。

サーバー：172.20.0.10アドレス1：172.20.0.10

nslookup： 'kubernetes.default'を解決できません

すべてパブリックなVPCでクラスターを起動すると、この問題は発生しません。プライベートサブネット内からDNS解決に必要な手順がありませんか？

ダニエル、どうもありがとう

kubernetesamazon-vpcamazon-eks
10
Daniel

この質問に答えることは、私にとって10時間のデバッグの答えだったので、私はこれに適切な答えを与える必要があると感じています。 @Danielがコメントで述べたように、私が見つけた問題は、UDBポート53での発信トラフィックをACLがブロックしていることでした。これは、kubernetesがDNSレコードの解決に使用しているようです。

私のポッドの1つが実際にはkubernetes DNSリゾルバーと同じゾーンにある（たぶん？）ので、実際に機能していたため、プロセスは特に混乱しました。

10
apdm

@Danielからのコメントを詳しく説明するには、次のものが必要です。

  1. uDPポート53の上りルール
  2. エフェメラルポートのUDPの上りルール（例：1025〜65535）

追加していない（2）ので、CoreDNSがリクエストを受信して​​応答しようとしているのを見ましたが、応答がリクエスターに返されませんでした。

これらの種類の問題に対処する他の人へのいくつかのヒントは、log構成をconfigmapに追加してCoreDNSロギングをオンにします。これは、kubectl edit configmap -n kube-system corednsで実行できました。これに関するCoreDNSのドキュメントを参照してください https://github.com/coredns/coredns/blob/master/README.md#examples これは、問題がCoreDNSによるクエリの受信または応答の送信のどちらであるかを理解するのに役立ちますバック。

4
Matt Wilber

Re：AWS EKS Kube Clusterと、ポッドからのRoute53内部/プライベートRoute53クエリ

問題を解決するために何をする必要があるかについてのメモを投稿したかっただけです。 YMMVと誰もが異なる環境や解像度などを持っていることに注意してください。

免責事項：私たちは、コミュニティterraform eksモジュールを使用して、vpcsとeksクラスターをデプロイ/管理しています。セキュリティグループを変更する必要はありませんでした。複数のクラスター、リージョン、VPCを使用しています。

ref： Terraform EKSモジュール

CoreDNSの変更：プライベート内部のDNSリレーがあるため、coredns configmapを変更して、dns-relay IPアドレスを追加する必要がありました...

ec2.internal:53 {
    errors
    cache 30
    forward . 10.1.1.245
}
foo.dev.com:53 {
    errors
    cache 30
    forward . 10.1.1.245
}
foo.stage.com:53 {
    errors
    cache 30
    forward . 10.1.1.245
}

...

VPC DHCPオプションセット：上記のリレーサーバーのIPで更新します（該当する場合）。変更できないため、オプションセットの再生成が必要です。

DHCPオプションセットは次のようになります。

["AmazonProvidedDNS", "10.1.1.245", "169.254.169.253"]

ref： AWS DHCPオプションセット

Route-53 Updates：すべてのroute53ゾーンを、それに関連付ける必要があるVPC-IDに関連付けます（kubeクラスターが存在し、ポッドが作成する場所）からのクエリ）。

そのためのterraformモジュールもあります： https://www.terraform.io/docs/providers/aws/r/route53_zone_association.html

1
cmcc

一部のポッドでDNS解決がタイムアウトするという同様の問題が発生しましたが、ポッドを数回再作成すると問題が解決します。また、特定のノードのすべてのポッドが問題を示しているわけではなく、一部のポッドのみが示されています。

Amazon VPC CNIのバージョン1.5.4のバグが原因であることが判明しました。詳細はこちら https://github.com/aws/Amazon-vpc-cni-k8s/issues/ 641 。

クイックソリューションは、推奨バージョンに戻すことです1.5.3- https://docs.aws.Amazon.com/eks/latest/userguide/update-cluster.html

0
Vivek Thomas

ですから、この問題についても、私は数時間苦労していて、時間の経過を失っています。

デフォルトのVPCを使用していますが、ワーカーノードがプライベートサブネット内にあるため、機能していませんでした。

私はAmazon-vpc-cni-k8sを調べ、解決策を見つけました。

Aws-nodeデーモンセットAWS_VPC_K8S_CNI_EXTERNALSNAT=trueの環境変数をsffする必要があります。

新しいyamlを取得して適用するか、ダッシュボードで修正することができます。ただし、それが機能するためには、ワーカーノードインスタンスを再起動して、IPルートテーブルを更新する必要があります。

問題のリンクは ここ です

ありがとう

0
WickStargazer