翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# `AWSSupport-TroubleshootEKSDNSFailure`
<a name="automation-awssupport-troubleshooteksdnsfailure"></a>

 **説明** 

`AWSSupport-TroubleshootEKSDNSFailure` ランブックは、アプリケーションまたはポッドが DNS 解決に失敗した場合の Amazon Elastic Kubernetes Service (Amazon EKS) での CoreDNS ポッドと設定に関する問題のトラブルシューティングに役立ちます。ランブックは、VPC DNS 設定の検証、CoreDNS デプロイと ConfigMap の検査、Horizontal Pod Autoscaler (HPA) 設定のチェック、CoreDNS ログの収集、ワーカーノードの DNS 解決チェックを実行します。必要に応じて、問題のワーカーノードと同じサブネットに調査対象の Amazon Elastic Compute Cloud インスタンスを作成して、ノードに直接アクセスすることなく DNS 解決チェックを実行できます。

**重要**  
Amazon EKS クラスターの認証モードは、 `API`または に設定する必要があります`API_AND_CONFIG_MAP`。このランブックは AWS Lambda 、(Lambda) 関数をプロキシとしてデプロイして認証された Kubernetes API コールを行い、実行終了時に作成されたすべてのリソースをクリーンアップします。

 [このオートメーションを実行する (コンソール)](https://console.aws.amazon.com/systems-manager/automation/execute/AWSSupport-TroubleshootEKSDNSFailure) 

**ドキュメントタイプ**

オートメーション

**[所有者]**

Amazon

**[Platforms]** (プラットフォーム)

Linux、macOS、Windows

**パラメータ**
+ AutomationAssumeRole

  タイプ: AWS::IAM::Role::Arn

  説明: (オプション) Systems Manager Automation がユーザーに代わってアクションを実行できるようにする AWS Identity and Access Management (IAM) ロールの Amazon リソースネーム (ARN)。ロールを指定しない場合、Systems Manager Automation はこのランブックを開始するユーザーのアクセス許可を使用します。
+ EksClusterName

  タイプ: 文字列

  説明: (必須) ターゲット Amazon EKS クラスターの名前。
+ DnsName

  タイプ: 文字列

  デフォルト: amazon.com

  説明: (オプション) アプリケーションまたはポッドが解決に失敗したドメイン名のスタブドメインサフィックス。
+ ProblematicNodeInstanceId

  タイプ: AWS::EC2::Instance::Id

  説明: (オプション) DNS 解決エラーが発生しているアプリケーションが実行されているワーカーノードのインスタンス ID。指定した場合、ランブックは、DNS 解決チェックを実行するために、同じサブネットにプローブ対象の Amazon EC2 インスタンスを作成します。ワーカーノードがパブリックサブネットにない場合、またはワーカーノード`bind-utils`へのインストールが許可されていない場合は、このパラメータを使用します。
+ CoreDnsNamespace

  タイプ: 文字列

  デフォルト: kube-system

  説明: (オプション) CoreDNS ポッドの Kubernetes 名前空間。
+ S3BucketName

  タイプ: AWS::S3::Bucket::Name

  説明: (オプション) CoreDNS トラブルシューティングログがアップロードされる Amazon Simple Storage Service バケットの名前。
+ LambdaRoleArn

  タイプ: AWS::IAM::Role::Arn

  説明: (オプション) Lambda プロキシ関数の IAM ロールの ARN。指定しない場合、ランブックは `AWSLambdaBasicExecutionRole`および `AWSLambdaVPCAccessExecutionRole`管理ポリシー`Automation-K8sProxy-Role-<ExecutionId>`を使用して という名前のロールを作成します。独自のロールを指定することをお勧めします。

**必要な IAM アクセス許可**

`AutomationAssumeRole` パラメータでは、ランブックを正常に使用するために、次のアクションが必要です。
+ `eks:DescribeCluster`
+ `ec2:DescribeVpcs`
+ `ec2:DescribeInstances`
+ `ec2:DescribeSubnets`
+ `ec2:DescribeSecurityGroups`
+ `cloudformation:CreateStack`
+ `cloudformation:DescribeStacks`
+ `cloudformation:DeleteStack`
+ `lambda:InvokeFunction`
+ `s3:GetBucketPublicAccessBlock`
+ `s3:GetBucketAcl`
+ `s3:PutObject`
+ `ssm:DescribeInstanceInformation`
+ `ssm:SendCommand`
+ `ssm:GetCommandInvocation`
+ `ssm:StartAutomationExecution`
+ `ssm:GetAutomationExecution`

 **ドキュメントステップ** 

1. `AssertIfTargetClusterExists` - で指定された Amazon EKS クラスター`EksClusterName`が存在し、 `ACTIVE`状態であることを確認します。クラスターが見つからないか、アクティブでない場合、ランブックは にスキップされます`GenerateReport`。

1. `UpdateEksClusterExists` - レポート生成で使用する内部`eksClusterExists`変数を `true` に設定します。

1. `GetVpcDnsSettings` - Amazon EKS クラスターに関連付けられた Amazon Virtual Private Cloud の `enableDnsSupport`および `enableDnsHostnames`設定を取得します。

1. `BranchOnVpcDnsSettings` - 両方の VPC DNS 設定が有効になっているかどうかを確認します。いずれかが無効になっている場合、ランブックは にスキップされます`GenerateReport`。それ以外の場合、 は に進みます`DeployK8sAuthApisResources`。

1. `DeployK8sAuthApisResources` - を実行して、Amazon EKS クラスター`AWSSupport-SetupK8sApiProxyForEKS`に認証された Kubernetes API コールを行うためのプロキシとして Lambda 関数をデプロイします。

1. `RetrieveCoreDNSDeployment` - ポッドの準備状況、コンテナのステータス、CoreDNS ポッドをホストするノードの準備状況など、CoreDNS デプロイに関する情報を取得します。CoreDNS クラスター IP も取得します。

1. `RetrieveAndInspectCoreDNSConfigMap` - Amazon EKS クラスターから CoreDNS ConfigMap を取得し、 で指定されたドメインのスタブドメイン設定など、設定の問題をチェックします`DnsName`。

1. `ValidateHpaConfiguration` - Horizontal Pod Autoscaler (HPA) が指定された名前空間の CoreDNS デプロイ用に設定されているかどうかを確認します。

1. `CheckS3BucketPublicStatus` - で指定された Amazon S3 バケット`S3BucketName`がパブリックまたは匿名の読み取りまたは書き込みアクセスを許可していないことを確認します。

1. `CollectLogToS3` - CoreDNS ポッドログを収集し、指定された Amazon S3 バケットにアップロードします。

1. `BranchOnProblematicNodeInstanceId` - `ProblematicNodeInstanceId`が指定され、CoreDNS ホストノードが存在するかどうかを確認します。両方の条件が満たされた場合、 は に進みます`VerifyThatProblematicNodeInstanceBelongsToCluster`。それ以外の場合、 は に分岐します`BranchOnCoreDnsDeployment`。

1. `VerifyThatProblematicNodeInstanceBelongsToCluster` - で指定されたインスタンス`ProblematicNodeInstanceId`が Amazon EKS クラスターのワーカーノードであることを確認します。

1. `UpdateProblematicNodeInstanceStanding` - 内部`problematicNodeInstanceStanding`変数を に設定します`true`。

1. `GetProblematicInstanceDetails` - 問題のワーカーノードの AMI ID、インスタンスタイプ、サブネット ID、およびセキュリティグループ IDs を取得し、調査対象の Amazon EC2 インスタンスを作成するときに使用します。

1. `CreateProbingInfrastructure` - 問題のあるワーカーノードと同じサブネット内の AWS CloudFormation スタックを介してインスタンスプロファイルを作成し、Amazon EC2 インスタンスを調べます。スタックの名前は です`AWSSupport-TroubleshootEKSDNSFailure-<ExecutionId>`。

1. `GetProbingInstanceId` - CloudFormation スタック出力から詳細な Amazon EC2 インスタンス ID を取得します。

1. `WaitForProbingInstanceSSMAgentStateToBeOnline` - 調査中の Amazon EC2 インスタンスで Amazon EC2 Systems Manager Agent が`Online`ステータスを報告するのを待ってから続行します。 Amazon EC2 

1. `RetrieveCoreDNSPodsIPFromProblematicNode` - 問題のあるワーカーノードから見た CoreDNS ポッド IP アドレスを取得します。

1. `PerformDNSResolutionOnProbing``EC2Instance` - クラスター IP と CoreDNS ポッド IP を使用して、プローブ対象の Amazon EC2 インスタンスで DNS 解決チェックを実行します。 CoreDNS 

1. `DeleteCloudFormationStack` - 詳細な Amazon EC2 インスタンスとインスタンスプロファイルを作成した CloudFormation スタックを削除します。

1. `UpdateCfnStackDeleted` - 内部`cfnStackDeleted`変数を に設定します`true`。

1. `BranchOnCoreDnsDeployment` - が指定され`ProblematicNodeInstanceId`ておらず、CoreDNS ホストノードが存在するかどうかを確認します。両方の条件が満たされた場合、 は に進みます`PerformDNSResolutionOnCoreDnsWorkerNodes`。それ以外の場合は、 に進みます`CleanupK8sAuthenticationInfrastructure`。

1. `BranchOnCoreDnsNodesExistForRunCommandSteps` - `aws:runCommand` ステップを実行する前に CoreDNS ホストノードが存在するかどうかを確認します。ノードが存在しない場合 (たとえば、CoreDNS のレプリカがゼロの場合）、 は にスキップします`CleanupK8sAuthenticationInfrastructure`。

1. `PerformDNSResolutionOnCoreDnsWorkerNodes` - クラスター IP と CoreDNS ポッド IP を使用して、CoreDNS ワーカーノードで DNS 解決チェックを直接実行します。

1. `VerifyNameserverMatchAndKubeProxyLogsAndIPTableEntries` - ネームサーバー IP がクラスター IP と一致することを確認し、API サーバーへの kube-proxy ポッドアクセスをチェックし、CoreDNS ワーカーノードで kube-dns iptables エントリを検証します。

1. `VerifyPPSThrottlingOnENIs` - CoreDNS ワーカーノードの Elastic Network Interface (ENI) あたりの DNS packets-per-second (PPS) 制限をチェックして、潜在的なスロットリングを特定します。 CoreDNS 

1. `UpdateChecksOnNodes` - ノードレベルのチェックが実行されたことを示す`true`内部`checksOnNodes`変数を に設定します。

1. `CleanupK8sAuthenticationInfrastructure` - `Cleanup`オペレーション`AWSSupport-SetupK8sApiProxyForEKS`で実行し、自動化中に作成された Lambda プロキシ関数と関連するリソースを削除します。

1. `UpdateK8sInfrastructreDeleted` - 内部`K8sInfrastructreDeleted`変数を に設定します`true`。

1. `CleanUpAllResources` - 以前のクリーンアップステップが正常に完了しなかった場合に備えて、CloudFormation スタックや Lambda プロキシ関数など、残りのリソースの包括的なクリーンアップを実行します。

1. `CollectOutputFromAllRunCommandSteps` - 自動化中に実行されたすべての`aws:runCommand`ステップから出力を収集して統合します。

1. `GenerateReport` - 前述のすべてのステップの結果を、VPC DNS 設定、CoreDNS デプロイヘルス、ConfigMap 設定、HPA 設定、ログ収集ステータス、DNS 解決チェック結果を含む包括的な評価レポートにコンパイルします。

 **[出力] ** 

`GenerateReport.EvalReport` - 検出結果や推奨される修復手順など、実行されたすべての DNS トラブルシューティングチェックの包括的なレポート。