VPC設定の確認
アプリケーションポッド、kube-dnsサービス、CoreDNSポッド間のDNSトラフィックは、多くの場合、複数のノードやVPCサブネットを通過します。VPCレベルでDNSトラフィックが自由に流れることができることを確認する必要があります。
ネットワークトラフィックをフィルタリングする2つの主なVPCコンポーネント：
- Security Groups
- Network ACL
ワーカーノードのSecurity GroupsとサブネットのNetwork ACLの両方が、DNSトラフィック（ポート53 UDP/TCP）を双方向で許可していることを確認する必要があります。
ステップ1 - ワーカーノードのSecurity Groupsを特定する
まず、クラスターワーカーノードに関連付けられているSecurity Groupsを特定しましょう。
クラスター作成時、EKSはクラスターエンドポイントと全てのManaged Nodesの両方に関連付けられるクラスターSecurity Groupを作成します。追加のSecurity Groupsが構成されていない場合、これがワーカーノードのトラフィックを制御する唯一のSecurity Groupです。
sg-xxxxbbda9848bxxxx
次に、ワーカーノードに設定されている追加のSecurity Groupsがあるか確認します：
--------------------------
| DescribeInstances |
+------------------------+
| i-xxxx2e04aa2baxxxx |
| sg-xxxxbbda9848bxxxx |
| i-xxxx45e34d609xxxx |
| sg-xxxxbbda9848bxxxx |
| i-xxxxdc536ec33xxxx |
| sg-xxxxbbda9848bxxxx |
+------------------------+
ワーカーノードはsg-xxxxbbda9848bxxxxというクラスターSecurity Groupのみを使用していることがわかります。
ステップ2 - ワーカーノードのSecurity Groupルールを確認する
ワーカーノードのSecurity Groupルールを調べてみましょう：
--------------------------------------------------------------------------------------------
| DescribeSecurityGroupRules |
+--------------+-----------+---------------+-----------+------------------------+----------+
| CidrIpv4 | FromPort | IsEgressRule | Protocol | SourceSG | ToPort |
+--------------+-----------+---------------+-----------+------------------------+----------+
| None | -1 | False | -1 | sg-085fea48222262c24 | -1 |
| 10.52.0.0/16| 443 | False | tcp | None | 443 |
| 10.53.0.0/16| 443 | False | tcp | None | 443 |
| 0.0.0.0/0 | -1 | True | -1 | None | -1 |
| None | -1 | False | -1 | sg-094406793b2c02fb3 | -1 |
| None | -1 | True | -1 | sg-085fea48222262c24 | -1 |
+--------------+-----------+---------------+-----------+------------------------+----------+
4つのIngressルールと2つのEgressルールが存在し、以下の詳細 があります：
- すべてのIPアドレス（0.0.0.0/0）へのすべてのプロトコルとポートのEgress - IsEgressRuleの列の値がTrueであることに注目してください。
- Security Group（sg-085fea48222262c24）へのすべてのプロトコルとポートのEgress
- Security Group（sg-085fea48222262c24）からのすべてのプロトコルとポートのIngress
- CIDRブロック10.52.0.0/16からのTCPポート443へのIngress
- CIDRブロック10.53.0.0/16からのTCPポート443へのIngress
- Security Group（sg-094406793b2c02fb3）からのすべてのプロトコルとポートのIngress
注目すべき点として、DNSトラフィック（UDP/TCPポート53）を許可するルールが存在せず、これがDNS解決の失敗の原因です。
根本原因
クラスターのセキュリティを強化する際、ユーザーがクラスターSecurity Groupのルールを過度に制限してしまうことがあります。クラスターの適切な操作のために、DNSトラフィックはクラスターSecurity Groupを通じて、またはワーカーノードに接続された別のSecurity Groupを通じて許可される必要があります。
この場合、クラスターSecurity Groupはポート443と10250のみを許可し、DNSトラフィックをブロックしているため、名前解決のタイムアウトが発生しています。
解決策
EKSセキュリティグループの要件に従って、クラスターSecurity Group内のすべてのトラフィックを許可します：
アプリケーションポッドを再作成します：
すべてのポッドがReady状態に達していることを確認します：
NAMESPACE NAME READY STATUS RESTARTS AGE
carts carts-5475469b7c-bwjsf 1/1 Running 0 50s
carts carts-dynamodb-69fc586887-pmkw7 1/1 Running 0 19h
catalog catalog-5578f9649b-pkdfz 1/1 Running 0 50s
catalog catalog-mysql-0 1/1 Running 0 19h
checkout checkout-84c6769ddd-d46n2 1/1 Running 0 50s
checkout checkout-redis-76bc7cb6f9-4g5qz 1/1 Running 0 23d
orders orders-6d74499d87-mh2r2 1/1 Running 0 50s
orders orders-postgresql-6fbd688d4b-m7gpt 1/1 Running 0 19h
ui ui-5f4d85f85f-xnh8q 1/1 Running 0 50s
詳細については、Amazon EKSセキュリティグループの要件を参照してください。
このラボではSecurity Groupsに焦点を当てていますが、Network ACLもEKSクラスターのトラフィックフローに影響を与える可能性があります。Network ACLの詳細については、ネットワークアクセスコントロールリストでサブネットトラフィックを制御するを参照してください。
結論
このラボの複数のセクションを通じて、EKSクラスターのDNS解決に影響するさまざまな問題の根本原因を調査・特定し、それらを修正するために必要な手順を実行しました。
このラボでは、以下のことを行いました：
- EKSクラスターのDNS解決に影響する複数の問題を特定
- 各問題を診断するために体系的なトラブルシューティングアプローチに従う
- DNS機能を復元するために必要な修正を適用
- すべてのアプリケーションポッドが適切に動作していることを確認
これですべてのアプリケーションポッドがReady状態になり、DNS解決が正しく機能するようになりました。