aws documentation - amazon eks - ユーザーガイド...aws fargate..... 112 fargate...

Amazon EKSユーザーガイド

Amazon EKS ユーザーガイド


Amazon EKS: ユーザーガイドCopyright © 2020 Amazon Web Services, Inc. and/or its affiliates. All rights reserved.

Amazon's trademarks and trade dress may not be used in connection with any product or service that is not Amazon's,in any manner that is likely to cause confusion among customers, or in any manner that disparages or discreditsAmazon. All other trademarks not owned by Amazon are the property of their respective owners, who may or may notbe affiliated with, connected to, or sponsored by Amazon.


Table of ContentsAmazon EKS とは .............................................................................................................................. 1

Amazon EKS のコントロールプレーンアーキテクチャ ..................................................................... 1Amazon EKS の仕組み ................................................................................................................ 2

Amazon EKS の開始方法 ..................................................................................................................... 3eksctl の開始方法 .................................................................................................................... 3

前提条件 ............................................................................................................................ 3Amazon EKS クラスターとワーカーノードを作成する ............................................................. 6次のステップ .................................................................................................................... 10

コンソールの開始方法 ............................................................................................................... 10Amazon EKS の前提条件 ................................................................................................... 10ステップ 1: Amazon EKS クラスターを作成する ................................................................... 14ステップ 2: kubeconfig ファイルを作成する ...................................................................... 16ステップ 3: マネージド型ノードグループの起動 .................................................................... 17次のステップ .................................................................................................................... 21

クラスター ....................................................................................................................................... 22クラスターの作成 ...................................................................................................................... 22Kubernetes バージョンの更新 ..................................................................................................... 29

既存のクラスターの更新 .................................................................................................... 30Kubernetes 1.16 にアップグレードにするための前提条件 ....................................................... 36

クラスターエンドポイントのアクセス .......................................................................................... 37クラスターエンドポイントのアクセスの変更 ......................................................................... 37プライベート専用 API サーバーへのアクセス ........................................................................ 41

コントロールプレーンのログ記録 ................................................................................................ 42コントロールプレーンログの有効化と無効化 ......................................................................... 43クラスターのコントロールプレーンログの表示 ...................................................................... 44

クラスターの削除 ...................................................................................................................... 45Kubernetes バージョン .............................................................................................................. 47

利用可能な Amazon EKS Kubernetes バージョン .................................................................. 47Kubernetes 1.16 ............................................................................................................... 48Kubernetes 1.15 ............................................................................................................... 49Kubernetes 1.14 ............................................................................................................... 50Kubernetes 1.13 ............................................................................................................... 50Amazon EKS バージョンの廃止 .......................................................................................... 51

プラットフォームのバージョン ................................................................................................... 52Kubernetes バージョン 1.16 ............................................................................................... 52Kubernetes バージョン 1.15 ............................................................................................... 53Kubernetes バージョン 1.14 ............................................................................................... 53Kubernetes バージョン 1.13 ............................................................................................... 55Kubernetes バージョン 1.12 ............................................................................................... 56

Windows サポート .................................................................................................................... 58考慮事項 .......................................................................................................................... 58Windows サポートの有効化 ................................................................................................ 59Windows サンプルアプリケーションをデプロイする .............................................................. 63

Arm サポート ........................................................................................................................... 64考慮事項 .......................................................................................................................... 64前提条件 .......................................................................................................................... 64クラスターの作成 .............................................................................................................. 65Arm サポートを有効にする ................................................................................................. 65ワーカーノードの起動 ....................................................................................................... 66ワーカーノードをクラスターに結合する ............................................................................... 67(オプション) アプリケーションのデプロイ ............................................................................ 68

API サーバーのフラグの表示 ...................................................................................................... 68ワーカーノード ................................................................................................................................. 70

Amazon EKS 最適化 Linux AMI .................................................................................................. 71

iv


Amazon EKS 最適化 AMI のビルドスクリプト ...................................................................... 76Amazon EKS 最適化 AMI (GPU 対応) .................................................................................. 77Amazon EKS 最適化 Linux AMI のバージョン ....................................................................... 79Amazon EKS 最適化 AMI ID の取得 .................................................................................... 82

Amazon EKS 最適化 Windows AMI ............................................................................................. 83Amazon EKS 最適化 Windows AMI ID の取得 ....................................................................... 87

マネージド型ノードグループ ...................................................................................................... 87マネージド型ノードグループの概念 ..................................................................................... 88マネージド型ノードグループの作成 ..................................................................................... 89マネージド型ノードグループの更新 ..................................................................................... 92マネージド型ノードグループの削除 ..................................................................................... 94

Amazon EKS Linux ワーカーノードの起動 ................................................................................... 95Amazon EKS Windows ワーカーノードの起動 ............................................................................. 101セルフマネージド型ワーカーノードの更新 .................................................................................. 105

新しいワーカーノードグループへの移行 ............................................................................. 106既存のワーカーノードグループの更新 ................................................................................ 111

Ubuntu AMI ............................................................................................................................ 113AWS Fargate .................................................................................................................................. 114

Fargate に関する考慮事項 ........................................................................................................ 115Fargate の開始方法 ................................................................................................................. 115

(オプション) クラスターを作成する ................................................................................... 116既存のノードが Fargate ポッドと通信できるようにする ....................................................... 116Fargate ポッド実行ロールを作成する ................................................................................. 117クラスターの Fargate プロファイルを作成する .................................................................... 117(オプション) CoreDNS を更新する .................................................................................... 119次のステップ .................................................................................................................. 119

Fargate プロファイル .............................................................................................................. 120Fargate プロファイルのコンポーネント .............................................................................. 120Fargate プロファイルの作成 ............................................................................................. 121Fargate プロファイルの削除 ............................................................................................. 123

Fargate ポッドの設定 .............................................................................................................. 123ポッド CPU とメモリ ...................................................................................................... 123Fargate ストレージ ......................................................................................................... 124

ストレージ ..................................................................................................................................... 125ストレージクラス .................................................................................................................... 125Amazon EBS CSI ドライバー ................................................................................................... 126Amazon EFS CSI ドライバー ................................................................................................... 130Amazon FSx for Lustre CSI ドライバー ...................................................................................... 134

Auto Scaling ................................................................................................................................... 140Cluster Autoscaler ................................................................................................................... 140

Amazon EKS クラスターを作成します。 ............................................................................ 140Cluster Autoscaler ノードグループの考慮事項 ..................................................................... 141Cluster Auto Scaling をデプロイする .................................................................................. 142Cluster Autoscaler ログを表示する .................................................................................... 143

Horizontal Pod Autoscaler ........................................................................................................ 144メトリクスサーバーのインストール ................................................................................... 144Horizontal Pod Autoscaler テストアプリケーションを実行する ............................................... 145

Vertical Pod Autoscaler ............................................................................................................ 146メトリクスサーバーのインストール ................................................................................... 146Vertical Pod Autoscaler をデプロイする ............................................................................. 147Vertical Pod Autoscaler のインストールをテストする ........................................................... 148

ロードバランシングと Ingress ........................................................................................................... 152ロードバランシング ................................................................................................................. 152

ロードバランサー用のサブネットのタグ付け ....................................................................... 152Amazon EKS の ALB Ingress Controller ..................................................................................... 153

ネットワーク .................................................................................................................................. 158Amazon EKS で使用する VPC の作成 ........................................................................................ 158

v


Amazon EKS で使用する VPC の作成 ................................................................................ 159次のステップ .................................................................................................................. 161

クラスター VPC に関する考慮事項 ............................................................................................ 161VPC IP アドレス指定 ...................................................................................................... 162VPC のタグ付け要件 ....................................................................................................... 163サブネットのタグ付け要件 ................................................................................................ 163

Amazon EKS セキュリティグループの考慮事項 ........................................................................... 164クラスターセキュリティグループ (Kubernetes 1.14 および eks.3 プラットフォームバージョンを実行している Amazon EKS クラスターから利用可能) ........................................................ 164コントロールプレーンおよびワーカーノードのセキュリティグループ (Kubernetes バージョン1.14 およびプラットフォームバージョン eks.3 以前の Amazon EKS クラスター対応) ............. 165

ポッドネットワーキング (CNI) .................................................................................................. 167CNI 設定変数 .................................................................................................................. 168外部 SNAT ..................................................................................................................... 174CNI カスタムネットワーク ............................................................................................... 176CNI Metrics Helper .......................................................................................................... 179CNI のアップグレード ..................................................................................................... 182

CoreDNS のインストールまたはアップグレード .......................................................................... 182CoreDNS のアップグレード .............................................................................................. 184

Amazon EKS に Calico をインストールする ............................................................................... 185Stars Policy デモ ............................................................................................................. 185

クラスター認証の管理 ...................................................................................................................... 190kubectl のインストール ......................................................................................................... 190aws-iam-authenticator のインストール ............................................................................... 196kubeconfig を Amazon EKS 用に作成します。 ......................................................................... 199クラスターのユーザーまたは IAM ロールの管理 ........................................................................... 202

eksctl ......................................................................................................................................... 206eksctl のインストールまたはアップグレード ............................................................................ 206

ゲストブック .................................................................................................................................. 208メトリクスサーバー ......................................................................................................................... 211Prometheus メトリクス ................................................................................................................... 212

未加工メトリクスの表示 ........................................................................................................... 212Prometheus のデプロイ ........................................................................................................... 213

Helm の使用 ................................................................................................................................... 216チュートリアル: Kubernetes ダッシュボードのデプロイ ....................................................................... 217

前提条件 ................................................................................................................................ 217ステップ 1: Kubernetes メトリクスサーバーをデプロイする .......................................................... 217ステップ 2: ダッシュボードのデプロイ ....................................................................................... 218ステップ 3: eks-admin サービスアカウントおよびクラスターロールバインディングの作成 .............. 218ステップ 4: ダッシュボードに接続する ....................................................................................... 219ステップ 5: 次のステップ ......................................................................................................... 221

AWS App Mesh .............................................................................................................................. 222シナリオ ................................................................................................................................ 222前提条件 ................................................................................................................................ 222ステップ 1: メッシュと仮想サービスを作成する .......................................................................... 222ステップ 2: 仮想ノードの作成 ................................................................................................... 223ステップ 3: 仮想ルーターとルートを作成する ............................................................................. 224ステップ 4: 確認と作成 ............................................................................................................ 225ステップ 5: 追加のリソースを作成する ....................................................................................... 226ステップ 6: サービスを更新する ................................................................................................ 230

Tutorial: Configure App Mesh integration with Kubernetes ..................................................................... 231Prerequisites .......................................................................................................................... 231Step 1: Install the integration components ................................................................................... 231Step 2: Deploy App Mesh resources .......................................................................................... 233Step 3: Create or update services ............................................................................................. 239Step 4: Clean up .................................................................................................................... 242

深層学習コンテナ ............................................................................................................................ 243

vi


セキュリティ .................................................................................................................................. 244Identity and access management ............................................................................................... 244

対象者 ........................................................................................................................... 245アイデンティティを使用した認証 ...................................................................................... 245ポリシーを使用したアクセスの管理 ................................................................................... 247Amazon EKS と IAM の連携 ............................................................................................. 248アイデンティティベースのポリシーの例 ............................................................................ 251サービスにリンクされたロールの使用 ................................................................................ 254クラスターの IAM ロール ................................................................................................. 258ワーカーノード IAM ロール .............................................................................................. 260ポッド実行ロール ............................................................................................................ 262サービスアカウントの IAM ロール ..................................................................................... 264トラブルシューティング ................................................................................................... 277

ログ記録とモニタリング ........................................................................................................... 277コンプライアンス検証 .............................................................................................................. 278耐障害性 ................................................................................................................................ 278インフラストラクチャセキュリティ ........................................................................................... 279設定と脆弱性の分析 ................................................................................................................. 280ポッドのセキュリティポリシー ................................................................................................. 280

Amazon EKS のデフォルトのポッドセキュリティポリシー .................................................... 280リソースのタグ付け ......................................................................................................................... 285

タグの基本 ............................................................................................................................. 285リソースのタグ付け ................................................................................................................. 285タグの制限 ............................................................................................................................. 286コンソールでのタグの処理 ........................................................................................................ 286

作成時に個々のリソースにタグを追加する .......................................................................... 287個々のリソースでのタグの追加と削除 ................................................................................ 287

CLI または API でのタグの操作 ................................................................................................. 287CloudTrail ...................................................................................................................................... 289

CloudTrail 内の Amazon EKS 情報 ............................................................................................ 289Amazon EKS ログファイルエントリの概要 ................................................................................. 290

Amazon EKS サービスにリンクされたロールのログエントリ ................................................. 291AWS Outposts での Amazon EKS ..................................................................................................... 292

前提条件 ................................................................................................................................ 292制約事項 ................................................................................................................................ 292ネットワーク接続に関する考慮事項 ........................................................................................... 292Outpost に Amazon EKS ノードを作成する ................................................................................ 293

関連プロジェクト ............................................................................................................................ 295管理ツール ............................................................................................................................. 295

eksctl ............................................................................................................................. 295AWS Service Operator ..................................................................................................... 295

ネットワーク .......................................................................................................................... 295Amazon VPC CNI Plugin for Kubernetes ............................................................................ 295AWS Application Load Balancer (ALB) Ingress Controller for Kubernetes ................................. 295ExternalDNS ................................................................................................................... 296

セキュリティ .......................................................................................................................... 296AWS IAM Authenticator .................................................................................................... 296

機械学習 ................................................................................................................................ 296Kubeflow ........................................................................................................................ 296

Auto Scaling ........................................................................................................................... 296Cluster Autoscaler ........................................................................................................... 297Escalator ........................................................................................................................ 297

モニタリング .......................................................................................................................... 297Prometheus .................................................................................................................... 297

継続的インテグレーション/継続的デプロイメント ........................................................................ 297Jenkins X ....................................................................................................................... 297

トラブルシューティング ................................................................................................................... 298

vii


容量不足 ................................................................................................................................ 298aws-iam-authenticator Not Found ...................................................................................... 298ワーカーノードをクラスターに結合できません ............................................................................ 298許可されていないか、アクセスが拒否されました (kubectl) ......................................................... 299hostname doesn't match ................................................................................................... 299getsockopt: no route to host ....................................................................................... 300マネージド型ノードグループのエラー ........................................................................................ 300CNI ログ収集ツール ................................................................................................................ 301Container runtime network not ready (コンテナランタイムネットワークの準備ができていません) ........ 301TLS ハンドシェイクタイムアウト .............................................................................................. 302Error: ErrImagePull .................................................................................................................. 302IAM ....................................................................................................................................... 303

AccessDeniedException ................................................................................................... 303iam:PassRole を実行する権限がない .................................................................................. 303アクセスキーを表示する場合 ............................................................................................. 303管理者として Amazon EKS へのアクセスを他のユーザーに許可する ...................................... 304自分の AWS アカウント以外のユーザーに Amazon EKS リソースへのアクセスを許可する場合 ... 304

サービスクォータ ............................................................................................................................ 305ドキュメント履歴 ............................................................................................................................ 306

viii

Amazon EKS ユーザーガイドAmazon EKS のコントロールプレーンアーキテクチャ

Amazon EKS とはAmazon Elastic Kubernetes Service (Amazon EKS) は、独自の Kubernetes コントロールプレーンを立ち上げたり維持したりすることなく、AWS で Kubernetes を簡単に実行できるようにするマネージド型サービスです。Kubernetes は、コンテナ化されたアプリケーションのデプロイ、スケーリング、および管理を自動化するためのオープンソースシステムです。

Amazon EKS は、高可用性を確保するために、複数のアベイラビリティーゾーンで Kubernetes コントロールプレーンインスタンスを実行します。Amazon EKS は、異常なコントロールプレーンインスタンスを自動的に検出して置換するために、コントロールプレーンインスタンスのバージョンのアップグレードやパッチ適用を自動的に行います。

Amazon EKS は、多くの AWS サービスと統合されていて、次のようなアプリケーションのスケーラビリティとセキュリティを提供します。

• コンテナイメージの Amazon ECR• 負荷を分散させる Elastic Load Balancing• 認証のための IAM• 分離のための Amazon VPC

Amazon EKS は、オープンソース Kubernetes ソフトウェアの最新バージョンを実行するため、Kubernetes コミュニティの既存のすべてのプラグインとツールを使用できます。Amazon EKS で実行されているアプリケーションは、標準の Kubernetes 環境で実行されているアプリケーションと完全に互換性があります。オンプレミスのデータセンターで実行されているか、パブリッククラウドで実行されているかは関係ありません。つまり、標準的な Kubernetes アプリケーションであれば、コードを変更することなく、簡単に Amazon EKS に移行できます。

Amazon EKS のコントロールプレーンアーキテクチャ

Amazon EKS はクラスターごとに単一のテナント Kubernetes コントロールプレーンを実行し、コントロールプレーンインフラストラクチャはクラスター間または AWS アカウント間で共有されません。

このコントロールプレーンは、リージョン内の 3 つのアベイラビリティーゾーンにまたがって動作する 2つ以上の API サーバーノードと 3 つの etcd ノードで構成されています。Amazon EKS は、異常なコントロールプレーンインスタンスを自動的に検出して置き換え、必要に応じてリージョン内のアベイラビリティーゾーン全体でそれらを再起動します。Amazon EKS は、高可用性を維持するために AWS リージョンのアーキテクチャを利用します。そのため、Amazon EKS は API サーバーエンドポイントの可用性のSLA を提供できます。

Amazon EKS は、Amazon VPC ネットワークポリシーを使用して、コントロールプレーンコンポーネント間のトラフィックを単一のクラスター内に制限します。Kubernetes RBAC ポリシーで許可されている場合を除き、クラスターのコントロールプレーンコンポーネントは、他のクラスターまたは他の AWS アカウントからの通信を表示したり受信したりすることはできません。

この安全で可用性の高い構成により、Amazon EKS は信頼性が高くなり、本番ワークロードに推奨されます。

1

http://aws.amazon.com/eks/sla


Amazon EKS ユーザーガイドAmazon EKS の仕組み

Amazon EKS の仕組み

Amazon EKS の簡単な開始方法。

1. まず、 AWS マネジメントコンソールで、AWS CLI または AWS SDK. の 1 つを使って Amazon EKSクラスターを作成します。

2. 次に、Amazon EKS クラスターに登録するワーカーノードを起動します。当社では、ノードを自動的に設定する AWS CloudFormation テンプレートを提供しています。

3. クラスターの準備ができたら、お気に入りの Kubernetes ツール (kubectl など) をクラスターと通信できるように設定できます。

4. 他の Kubernetes 環境と同じ方法で、Amazon EKS クラスターでアプリケーションをデプロイし、管理します。

必要なリソースと、初めての Amazon EKS クラスターを作成する方法の詳細については、Amazon EKSの開始方法 (p. 3) を参照してください。

2

Amazon EKS ユーザーガイドeksctl の開始方法

Amazon EKS の開始方法Amazon EKS で新しい Kubernetes クラスターとワーカーノードを作成するための入門ガイドは 2 つあります。

• eksctl の開始方法 (p. 3): この入門ガイドは、eksctl (Amazon EKS での Kubernetes クラスターの作成および管理用のシンプルなコマンドラインユーティリティ) を使用して、Amazon EKS の開始に必要なすべてのリソースをインストールするのに役立ちます。このチュートリアルの終わりには、ワーカーノードが関連付けられた Amazon EKS クラスターが実行中になり、kubectl コマンドラインユーティリティは新しいクラスターを使用するように設定されます。これは、Amazon EKS の使用を開始するための最も高速かつシンプルな方法です。

• AWS マネジメントコンソールの使用開始 (p. 10): この入門ガイドは、Amazon EKS での AWS マネジメントコンソールの開始に必要なすべてのリソースを作成するのに役立ちます。このガイドでは、Amazon EKS または AWS CloudFormation コンソールで各リソースを手動で作成します。ここで説明するワークフローを使用すると、どのように各リソースが作成されて相互に通信するかを視覚的に把握できます。

eksctl の開始方法この入門ガイドは、eksctl (Amazon EKS での Kubernetes クラスターの作成および管理用のシンプルなコマンドラインユーティリティ) を使用して、Amazon EKS の開始に必要なすべてのリソースをインストールするのに役立ちます。このチュートリアルの終わりには、マネージド型ノードグループが関連付けられた Amazon EKS クラスターが実行中になり、kubectl コマンドラインユーティリティは新しいクラスターを使用するように設定されます。

前提条件このセクションは、Amazon EKS クラスターの作成と管理に必要なバイナリをインストールして設定するのに役立ちます。

最新の AWS CLI をインストールするAmazon EKS クラスターで kubectl を使用するには、クラスター API サーバー通信に必要なクライアントセキュリティトークンを作成できるバイナリをインストールする必要があります。AWS CLI のバージョン 1.18.49 以降で使用可能な aws eks get-token コマンドは、クライアントセキュリティトークンの作成をサポートしています。AWS CLI をインストールまたはアップグレードするには、『AWS Command LineInterface ユーザーガイド』の「AWS コマンドラインインターフェイスのインストール」を参照してください。

pip およびサポートされるバージョンの Python をすでにインストールしている場合は、以下のコマンドを使用して AWS CLI をインストールできます。

pip install awscli --upgrade --user

Note

システムの Python のバージョンは 2.7.9 以降であることが必要です。そうでない場合は、AWSCLI で Amazon EKS を呼び出すと hostname doesn't match エラーが発生します。詳細については、Python Requests FAQ の「What are "hostname doesn't match" errors?｣を参照してください。

3

https://docs.aws.amazon.com/cli/latest/userguide/installing.html

https://2.python-requests.org/projects/3/community/faq/#what-are-hostname-doesn-t-match-errors

Amazon EKS ユーザーガイド前提条件

プラットフォーム用に AWS CLI をインストールまたはアップグレードする他の方法の詳細については、AWS Command Line Interface ユーザーガイドの以下のトピックを参照してください。

• macOS で AWS Command Line Interface をインストールする• Linux で AWS Command Line Interface をインストールする• Microsoft Windows で AWS Command Line Interface をインストールする

システムにバージョン 1.18.49 以降の AWS CLI をインストールできない場合は、AWS IAM Authenticatorfor Kubernetes がシステムにインストールされていることを確認する必要があります。詳細については、「aws-iam-authenticator のインストール (p. 196)」を参照してください。

AWS CLI 認証情報を設定するeksctl と AWS CLI の両方には、使用している環境で AWS 認証情報が設定されている必要があります。一般的な使用の場合、aws configure コマンドが、AWS CLI をインストールして設定するための最も簡単な方法です。

$ aws configureAWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLEAWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEYDefault region name [None]: region-codeDefault output format [None]: json

このコマンドを入力すると、AWS CLI によって、アクセスキー、シークレットアクセスキー、AWS リージョン、出力形式の 4 つの情報の入力が求められます。これらの情報は、default という名前のプロファイル (設定の集合) に保存されます。別のプロファイルを指定しない限り、このプロファイルが使用されます。

詳細については、AWS Command Line Interface ユーザーガイドの「AWS CLI の設定」を参照してください。

eksctl をインストールするこのセクションは、eksctl コマンドラインユーティリティをインストールするのに役立ちます。詳細については、https://eksctl.io/ を参照してください。

以下からクライアントの設定を最もよく表しているタブを選択します。

macOS

Homebrew を使用して macOS で eksctl をインストールまたはアップグレードするには

Amazon EKS と macOS の使用を開始する最も簡単な方法は、Homebrew を使用して eksctl をインストールすることです。eksctl Homebrew レシピは、eksctl と Amazon EKS に必要なその他の依存関係 (kubectl、aws-iam-authenticator など) をインストールします。

1. Mac OS で Homebrew をまだインストールしていない場合は、以下のコマンドでインストールします。

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"

2. Weaveworks Homebrew tap をインストールします。

brew tap weaveworks/tap

3. eksctl をインストールまたはアップグレードします。

4

https://docs.aws.amazon.com/cli/latest/userguide/install-macos.html

https://docs.aws.amazon.com/cli/latest/userguide/install-linux.html

https://docs.aws.amazon.com/cli/latest/userguide/install-windows.html

https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html

https://github.com/weaveworks/eksctl

https://brew.sh/


• 以下のコマンドを使用して、eksctl をインストールします。

brew install weaveworks/tap/eksctl

• eksctl がすでにインストールされている場合は、以下のコマンドでアップグレードします。

brew upgrade eksctl && brew link --overwrite eksctl

4. 以下のコマンドを使用して、インストールが成功したことをテストします。

eksctl version

Note

GitTag のバージョンは 0.19.0 以上であることが必要です。そうでない場合は、端末の出力にインストールエラーやアップグレードエラーがないか確認するか、以下からリリースのアーカイブを手動でダウンロードします https://github.com/weaveworks/eksctl/releases/download/0.19.0/eksctl_Darwin_amd64.tar.gz、eksctl を展開し、実行します。

Linux

curl を使用して Linux で eksctl をインストールまたはアップグレードするには

1. 以下のコマンドを使用して、eksctl の最新リリースをダウンロードして解凍します。

curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp

2. 抽出したバイナリを /usr/local/bin に移動します。

sudo mv /tmp/eksctl /usr/local/bin


eksctl version

Note

GitTag のバージョンは 0.19.0 以上であることが必要です。成功しない場合、端末の出力でインストールまたはアップグレードエラーがないか確認するか、ステップ 1 のアドレスを https://github.com/weaveworks/eksctl/releases/download/0.19.0/eksctl_$(uname -s)_amd64.tar.gz に置き換えて、ステップ1 ～ 3 をもう一度実行します。

Windows

Chocolatey を使用して Windows で eksctl をインストールまたはアップグレードするには

1. Windows システムに Chocolatey がまだインストールされていない場合は、「Chocolatey のインストール」を参照してください。

2. eksctl および aws-iam-authenticator をインストールまたはアップグレードします。

• 次のコマンドでバイナリをインストールします。

5

https://github.com/weaveworks/eksctl/releases/download/0.19.0/eksctl_Darwin_amd64.tar.gz


https://chocolatey.org/install


Amazon EKS ユーザーガイドAmazon EKS クラスターとワーカーノードを作成する

chocolatey install -y eksctl aws-iam-authenticator

• すでにインストールされている場合は、以下のコマンドでアップグレードします。

chocolatey upgrade -y eksctl aws-iam-authenticator


eksctl version

Note

GitTag のバージョンは 0.19.0 以上であることが必要です。そうでない場合は、端末の出力にインストールエラーやアップグレードエラーがないか確認するか、以下からリリースのアーカイブを手動でダウンロードします https://github.com/weaveworks/eksctl/releases/download/0.19.0/eksctl_Windows_amd64.zip、eksctl を展開し、実行します。

Amazon EKS の kubectl をインストールして設定するKubernetes では、クラスター API サーバーとの通信に kubectl というコマンドラインユーティリティを使用します。

Note

前述の Homebrew の手順に従って macOS で eksctl をインストールした場合、kubectl とaws-iam-authenticator はすでにシステムにインストールされています。「Amazon EKS クラスターとワーカーノードを作成する (p. 6)」に進めます。

Amazon EKS用にkubectlをインストールする

• オペレーティングシステムに kubectl をダウンロードしてインストールするには、複数のオプションがあります。• kubectl バイナリは、多数のオペレーティングシステムのパッケージで利用できます。この

オプションは多くの場合、手動のダウンロードおよびインストールプロセスよりはるかに簡単です。Kubernetes のドキュメントにある個別のオペレーティングシステムやパッケージマネージャー用の手順に従えばインストールできます。

• Amazon EKS では、同じバージョンのアップストリーム kubectl バイナリと同一の使用できるkubectl バイナリが発行されています。Amazon EKS が発行したお使いのオペレーティングシステム用のバイナリをインストールするには、「kubectl のインストール (p. 190)」を参照してください。

Amazon EKS クラスターとワーカーノードを作成するこの時点で、eksctl コマンドラインユーティリティを使用して Amazon EKS クラスターとワーカーノードグループを作成できます。

eksctl を使用してクラスターを作成するには

1. ワークロードの要件に一致する以下のタブを選択します。AWS Fargate 上でのみポッドを実行するクラスターを作成する場合は、[AWS Fargate-only cluster ] を選択します。クラスターで Linux ワークロードのみを実行する場合は、[Cluster with Linux-only workloads (Linux のみのワークロードがあるクラスター)] を選択します。クラスターで Linux および Windows ワークロードを実行する場合

6

https://github.com/weaveworks/eksctl/releases/download/0.19.0/eksctl_Windows_amd64.zip


https://kubernetes.io/docs/tasks/tools/install-kubectl/


は、[Cluster with Linux and Windows workloads (Linux および Windows のワークロードがあるクラスター)] を選択します。

AWS Fargate-only cluster

この手順では、eksctl をインストール済みで、お使いの eksctl バージョンが 0.19.0 以上であることを前提としています。お使いのバージョンは、以下のコマンドを使用して確認できます。

eksctl version

eksctl のインストールまたはアップグレードの詳細については、eksctl のインストールまたはアップグレード (p. 206) を参照してください。

以下のコマンドを使用して、Fargate をサポートする、Amazon EKS クラスターを作成します。example の値は独自の値に置き換えます。--region に、サポートされるリージョン (p. 114)を指定します。

eksctl create cluster \--name prod \--region region-code \--fargate

ワーカーノードグループなしで、新しい Amazon EKS クラスターが作成されます。ただし、eksctl は、ポッド実行ロール、default および kube-system の名前空間の Fargate プロファイルを作成し、Fargate で実行できるように、coredns デプロイにパッチを適用します。詳細については、AWS Fargate (p. 114) を参照してください。

Cluster with Linux-only workloads


eksctl version


以下のコマンドを使用して、Amazon EKS クラスターと Linux ワーカーノードを作成します。example の値は独自の値に置き換えます。

eksctl create cluster \--name prod \--region region-code \--nodegroup-name standard-workers \--node-type t3.medium \--nodes 3 \--nodes-min 1 \--nodes-max 4 \--ssh-access \--ssh-public-key my-public-key.pub \--managed

Note

• Amazon EKS マネージド型ノードグループ (p. 87) の --managed オプションは、現在 Kubernetes 1.14 以降のクラスターでのみサポートされています。最新機能を利

7


用するには、Amazon EKS で利用できる最新バージョンの Kubernetes を使用することをお勧めします。以前のバージョンの Kubernetes を使用する場合は、--managedオプションを削除する必要があります。

eksctl create cluster の使用可能なオプションの詳細については、GitHub の READMEプロジェクトを参照するか、以下のコマンドでヘルプページを参照してください。

eksctl create cluster --help

• --ssh-public-key はオプションですが、クラスターを使用してノードグループを作成するときに、これを指定することを強くお勧めします。このオプションを指定すると、マネージド型ノードグループ内のノードへの SSH アクセスが有効になります。SSH アクセスを有効にすることにより、インスタンスに接続し、問題がある場合に診断情報を収集できます。ノードグループの作成後にリモートアクセスを有効にすることはできません。キーの詳細については、『Linux インスタンス用 Amazon EC2ユーザーガイド』の「Amazon EC2 Key Pairs」を参照してください。

出力:

クラスターノードとワーカーノードが作成されると、数行の出力が表示されます。出力の最後の行は、次のサンプル行のようになります。

[✓] EKS cluster "prod" in "region-code" region is ready

Cluster with Linux and Windows workloads


eksctl version


Windows サポートの「考慮事項 (p. 58)」を把握しておいてください。以下の例のテキストには instanceType のサポートされる値が含まれています。example の値は独自の値に置き換えます。以下のテキストを cluster-spec.yaml という名前のファイルに保存します。設定ファイルは、クラスターと Linux および Windows ワーカーノードグループを作成するために使用します。クラスターで Windows ワークロードのみを実行する場合でも、すべての Amazon EKSクラスターには 1 つ以上の Linux ワーカーノードが含まれている必要があります。可用性を確保するために、各ノードグループには 2 つ以上のワーカーノードを作成することをお勧めします。Windows ワークロードに最低限必要な Kubernetes バージョンは 1.14 です。

---apiVersion: eksctl.io/v1alpha5kind: ClusterConfig

metadata: name: windows-prod region: region-codemanagedNodeGroups: - name: linux-ng instanceType: t2.large minSize: 2

nodeGroups:

8

https://github.com/weaveworks/eksctl/blob/master/README.md

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html


- name: windows-ng instanceType: m5.large minSize: 2 volumeSize: 100 amiFamily: WindowsServer2019FullContainer

以下のコマンドを使用して、Amazon EKS クラスターと Windows および Linux ワーカーノードを作成します。

eksctl create cluster -f cluster-spec.yaml --install-vpc-controllers

Note

Amazon EKS マネージド型ノードグループ (p. 87) の managedNodeGroups オプションは、現在 Kubernetes 1.14 以降のクラスターでのみサポートされています。最新機能を利用するには、Amazon EKS で利用できる最新バージョンの Kubernetes を使用することをお勧めします。以前のバージョンの Kubernetes を使用する場合は、--managed オプションを削除する必要があります。eksctl create cluster の使用可能なオプションの詳細については、GitHub の README プロジェクトを参照するか、以下のコマンドでヘルプページを参照してください。

eksctl create cluster --help

出力:

クラスターノードとワーカーノードが作成されると、数行の出力が表示されます。出力の最後の行は、次のサンプル行のようになります。

[✓] EKS cluster "windows-prod" in "region-code" region is ready

2. クラスターのプロビジョニングには通常、10 ~ 15 分かかります。クラスターの準備ができたら、kubectl 設定が正しいことをテストします。

kubectl get svc

Note

"aws-iam-authenticator": executable file not found in $PATH エラーが発生した場合、kubectl は、Amazon EKS に設定されていません。詳細については、「aws-iam-authenticator のインストール (p. 196)」を参照してください。その他の認可またはリソースタイプのエラーが発生した場合は、トラブルシューティングセクションの許可されていないか、アクセスが拒否されました (kubectl) (p. 299) を参照してください。

出力:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEsvc/kubernetes ClusterIP 10.100.0.1 <none> 443/TCP 1m

3. (Linux GPU ワーカーのみ) GPU インスタンスタイプと Amazon EKS 最適化 AMI (GPU 対応) を選択した場合は、以下のコマンドを使用して、NVIDIA device plugin for Kubernetes を、クラスターに設定されたデーモンセットとして適用する必要があります。

kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/1.0.0-beta/nvidia-device-plugin.yml

9


https://github.com/NVIDIA/k8s-device-plugin

Amazon EKS ユーザーガイド次のステップ

次のステップワーカーノードが関連付けられた Amazon EKS クラスターが実行中になったところで、Kubernetes アドオンのインストールとクラスターへのアプリケーションのデプロイを開始できます。以下のトピックは、クラスターの機能を拡張するのに役立ちます。

• Cluster Autoscaler (p. 140) — ノードグループ内のノード数を自動的に調整するように KubernetesCluster Autoscaler を設定します。

• ゲストブックアプリケーションを起動する (p. 208) — サンプルゲストブックアプリケーションを作成して、クラスターと Linux ワーカーノードをテストします。

• Windows サンプルアプリケーションをデプロイする (p. 63) — サンプルアプリケーションをデプロイして、クラスターと Windows ワーカーノードをテストします。

• チュートリアル: Kubernetes ダッシュボード (ウェブ UI) のデプロイ (p. 217) — このチュートリアルでは、Kubernetes ダッシュボードをクラスターにデプロイする方法について説明します。

• Amazon EKS での Helm の使用 (p. 216) — Kubernetes 用 helm パッケージマネージャーは、クラスターでアプリケーションをインストールおよび管理するのに役立ちます。

• Kubernetes メトリクスサーバーのインストール (p. 211) — Kubernetes メトリクスサーバーは、クラスター内のリソース使用状況データを集約します。

• Prometheus を使用したプレーンメトリクスのコントロール (p. 212) — このトピックは、helm を使用して Prometheus をクラスターにデプロイするのに役立ちます。

AWS マネジメントコンソールの使用開始この入門ガイドは、AWS マネジメントコンソールでの Amazon EKS の開始に必要なすべてのリソースを作成するのに役立ちます。このガイドでは、Amazon EKS または AWS CloudFormation コンソールで各リソースを手動で作成します。ここで説明するワークフローを使用すると、どのように各リソースが作成されて相互に通信するかを視覚的に把握できます。

eksctl CLI を使用してクラスターノードとワーカーノードを作成することもできます。詳細については、「eksctl の開始方法 (p. 3)」を参照してください。

Amazon EKS の前提条件Amazon EKS クラスターを作成する前に、Kubernetes が AWS リソースを作成するための IAM ロールを作成する必要があります。たとえば、ロードバランサーが作成されると、Kubernetes は、アカウントでElastic Load Balancing ロードバランサーを作成するための Kubernetes ロールを引き受けます。この操作は 1 回のみ行う必要があり、複数の EKS クラスターに使用できます。

また、使用するクラスター用の VPC とセキュリティグループを作成する必要があります。VPC グループとセキュリティグループは複数の EKS クラスターで使用できますが、各 EKS クラスターに別々の VPCを使用して、ネットワークを分離することをお勧めします。

このセクションでは、kubectl バイナリをインストールし、Amazon EKS を使用するために設定する方法についても説明します。

Amazon EKS クラスターの IAM ロールの作成AWS マネジメントコンソールまたは AWS CloudFormation を使用してロールを作成できます。ロールの作成に使用するツールの名前が付いているタブを選択します。

AWS マネジメントコンソール

IAM コンソールで Amazon EKS クラスターロールを作成するには

1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。

10

https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler

https://github.com/kubernetes/dashboard

https://console.aws.amazon.com/iam/

Amazon EKS ユーザーガイドAmazon EKS の前提条件

2. [ロール] を選択してから [ロールの作成] を選びます。3. サービスのリストから [EKS] を選択し、ユースケースに合った [EKS - Cluster (EKS - クラス

ター)] を選択して、[Next: Permissions (次へ: アクセス許可)] を選択します。4. [次へ: タグ] を選択します。5. (オプション) タグをキーと値のペアとしてアタッチして、メタデータをロールに追加しま

す。IAM でのタグの使用の詳細については、『IAM ユーザーガイド』の IAM エンティティのタグ付けを参照してください。

6. [Next: Review] を選択します。7. [ロール名] に、ロールの一意の名前 (eksClusterRole など) を入力し、[ロールの作成] を選択し

ます。

AWS CloudFormation

AWS CloudFormation で Amazon EKS クラスターロールを作成するには

1. 以下の AWS CloudFormation テンプレートをローカルシステムのテキストファイルに保存します。

---AWSTemplateFormatVersion: '2010-09-09'Description: 'Amazon EKS Cluster Role'

Resources:

eksClusterRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Principal: Service: - eks.amazonaws.com Action: - sts:AssumeRole ManagedPolicyArns: - arn:aws:iam::aws:policy/AmazonEKSClusterPolicy

Outputs:

RoleArn: Description: The role that Amazon EKS will use to create AWS resources for Kubernetes clusters Value: !GetAtt eksClusterRole.Arn Export: Name: !Sub "${AWS::StackName}-RoleArn"

Note

2020 年 4 月 16 日までは、ManagedPolicyArns にarn:aws:iam::aws:policy/AmazonEKSServicePolicy のエントリがありました。AWSServiceRoleForAmazonEKS サービスにリンクされたロールでは、このポリシーは必須でなくなりました。

2. AWS CloudFormation コンソール (https://console.aws.amazon.com/cloudformation) を開きます。3. [スタックの作成] を選択します。

11

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html


https://console.aws.amazon.com/cloudformation/


4. [テンプレートの指定] で、[テンプレートファイルのアップロード] を選択し、[ファイルの選択] を選択します。

5. 作成したファイルを選択し、[Next (次へ)] を選択します。6. [スタックの名前] に eksClusterRole などのロール名を入力し、[次へ] を選択します。7. [スタックオプションの設定] ページで、[Next (次へ)] を選択します。8. [Review (レビュー)] ページで、情報を確認して、スタックで IAM リソースが作成されることを認

識し、[スタックの作成] を選択します。

Amazon EKS クラスター VPC を作成するこのセクションでは、2 つのパブリックサブネットと 2 つのプライベートサブネットを持つ VPC、または3 つのパブリックサブネットを持つ VPC を作成する手順について説明します。

Amazon EKS のクラスターの作成時には、使用するクラスターの VPC サブネットを指定します。AmazonEKS には、2 つ以上のアベイラビリティーゾーンにサブネットが必要です。パブリックサブネットとプライベートサブネットを持つ VPC をお勧めします。これにより、Kubernetes がパブリックサブネットにパブリックロードバランサーを作成し、プライベートサブネットにあるワーカーノードで実行されているポッドへのトラフィックを負荷分散します。

両方の VPC タイプの詳細については、「??? (p. 158)」を参照してください。

目的の VPC 設定を表すタブを下で選択します。

Public and private subnets

パブリックサブネットとプライベートサブネットを持つクラスター VPC を作成するには

1. AWS CloudFormation コンソール (https://console.aws.amazon.com/cloudformation) を開きます。2. ナビゲーションバーで、Amazon EKS をサポートするリージョンを選択します。3. [スタックの作成] を選択します。4. [Choose a template (テンプレートの選択)] で、[Specify an Amazon S3 template URL (Amazon

S3 テンプレート URL の指定)] を選択します。5. 以下の URL をテキストエリアに貼り付けて、[次へ] を選択します。

https://amazon-eks.s3.us-west-2.amazonaws.com/cloudformation/2020-04-21/amazon-eks-vpc-private-subnets.yaml

6. [詳細の指定] ページで、必要に応じてパラメータを指定し、[次へ] を選択します。

• Stack name: AWS CloudFormation スタックのスタック名を選択します。たとえば、[eks-vpc]に呼び出します。

• VpcBlock: VPC の CIDR 範囲を選択します。デフォルト値をそのまま使用できます。• PublicSubnet01Block: パブリックサブネット 1 の CIDR 範囲を指定します。ロードバランサー

で数多くの IP アドレスを使用できるよう、デフォルト値のままにしておくことをお勧めします。

• PublicSubnet02Block: パブリックサブネット 2 の CIDR 範囲を指定します。ロードバランサーで数多くの IP アドレスを使用できるよう、デフォルト値のままにしておくことをお勧めします。

• PrivateSubnet01Block: プライベートサブネット 1 の CIDR 範囲を指定します。ポッドとロードバランサーで数多くの IP アドレスを使用できるよう、デフォルト値のままにしておくことをお勧めします。


12



7. (オプション) [オプション] ページで、スタックリソースをタグ付けします。[次へ] を選択します。8. [Review] ページで、[Create ] を選択します。9. スタックが作成されたら、コンソールで選択し、[出力] を選択します。10. 作成されたセキュリティグループの [SecurityGroups] 値を記録します。ワーカーノードをクラス

ターに追加するときは、セキュリティグループの ID を指定する必要があります。セキュリティグループは、Amazon EKS コントロールプレーンがワーカーノードと通信できるようにサブネット内に作成されたクロスアカウントの Elastic Network Interfaces に適用されます。

11. 作成された VPC の [VpcId] を記録します。これは、ワーカーノードグループテンプレートを起動する際に必要になります。

12. 作成されたサブネットの SubnetIds と、それらをパブリックサブネットとプライベートサブネットのどちらとして作成したかを記録します。ワーカーノードをクラスターに追加するときは、ワーカーノードを起動するサブネットの ID を指定する必要があります。

Only public subnets

パブリックサブネットのみを持つクラスター VPC を作成するには



https://amazon-eks.s3.us-west-2.amazonaws.com/cloudformation/2020-04-21/amazon-eks-vpc-sample.yaml



• VpcBlock: VPC の CIDR 範囲を選択します。デフォルト値をそのまま使用できます。• Subnet01Block: サブネット 1 の CIDR 範囲を指定します。ポッドとロードバランサーで数多く

の IP アドレスを使用できるよう、デフォルト値のままにしておくことをお勧めします。• Subnet02Block: サブネット 2 の CIDR 範囲を指定します。ポッドとロードバランサーで数多く


の IP アドレスを使用できるよう、デフォルト値のままにしておくことをお勧めします。7. (オプション) [オプション] ページで、スタックリソースをタグ付けします。[次へ] を選択します。8. [Review] ページで、[Create ] を選択します。9. スタックが作成されたら、コンソールで選択し、[出力] を選択します。10. 作成されたセキュリティグループの [SecurityGroups] 値を記録します。ワーカーノードをクラス



12. 作成されたサブネットの [SubnetIds] を記録します。ワーカーノードをクラスターに追加するときは、ワーカーノードを起動するサブネットの ID を指定する必要があります。

13


Amazon EKS ユーザーガイドステップ 1: Amazon EKS クラスターを作成する

Amazon EKS の kubectl をインストールして設定するKubernetes では、クラスター API サーバーとの通信に kubectl というコマンドラインユーティリティを使用します。

Amazon EKS用にkubectlをインストールする

• オペレーティングシステムに kubectl をダウンロードしてインストールするには、複数のオプションがあります。• kubectl バイナリは、多数のオペレーティングシステムのパッケージで利用できます。この

オプションは多くの場合、手動のダウンロードおよびインストールプロセスよりはるかに簡単です。Kubernetes のドキュメントにある個別のオペレーティングシステムやパッケージマネージャー用の手順に従えばインストールできます。

• Amazon EKS では、同じバージョンのアップストリーム kubectl バイナリと同一の使用できるkubectl バイナリが発行されています。Amazon EKS が発行したお使いのオペレーティングシステム用のバイナリをインストールするには、「kubectl のインストール (p. 190)」を参照してください。

最新の AWS CLI をインストールするAmazon EKS クラスターで kubectl を使用するには、クラスター API サーバー通信に必要なクライアントセキュリティトークンを作成できるバイナリをインストールする必要があります。AWS CLI のバージョン 1.18.49 以降で使用可能な aws eks get-token コマンドは、クライアントセキュリティトークンの作成をサポートしています。AWS CLI をインストールまたはアップグレードするには、『AWS Command LineInterface ユーザーガイド』の「AWS コマンドラインインターフェイスのインストール」を参照してください。

Important

yum、apt-get、または macOS の Homebrew は、AWS CLI より数バージョン遅れることがあります。最新バージョンを確実に入手するには、AWS Command Line Interface ユーザーガイドの「AWS コマンドラインインターフェイスのインストール」を参照してください。

AWS CLI のバージョンは、以下のコマンドを使用して確認できます。

aws --version

Note

システムの Python のバージョンは 2.7.9 以降であることが必要です。そうでない場合は、AWSCLI で Amazon EKS を呼び出すと hostname doesn't match エラーが発生します。

システムにバージョン 1.18.49 以降の AWS CLI をインストールできない場合は、AWS IAM Authenticatorfor Kubernetes がシステムにインストールされていることを確認する必要があります。詳細については、「aws-iam-authenticator のインストール (p. 196)」を参照してください。

ステップ 1: Amazon EKS クラスターを作成するAmazon EKS クラスターを作成できるようになりました。このセクションでは、最新機能をすべて利用するために Amazon EKS で利用可能な Kubernetes の最新バージョンでクラスターを作成する方法について説明します。一部の機能は、Kubernetes の古いバージョンでは利用できません。

Important

Amazon EKS クラスターが作成されたら、クラスターを作成する IAM エンティティ (ユーザーまたはロール) は、管理者 (system:master アクセス許可が付与されている) として KubernetesRBAC 認証テーブルに追加されます。最初は、その IAM ユーザーだけが kubectl を使用してKubernetes API サーバーを呼び出すことができます。詳細については、「クラスターのユーザー

14




Amazon EKS ユーザーガイドステップ 1: Amazon EKS クラスターを作成する

または IAM ロールの管理 (p. 202)」を参照してください。コンソールを使用してクラスターを作成する場合は、クラスター上で kubectl コマンドを実行する際、同じ IAM ユーザー認証情報がAWS SDK 認証情報チェーンにあることを確認する必要があります。AWS CLI をインストールして設定する場合は、ユーザーの IAM 認証情報を設定できます。AWSCLI がユーザーに対して適切に設定されている場合は、eksctl および AWS IAM Authenticatorfor Kubernetes でこれらの認証情報も検索できます。詳細については、AWS Command LineInterface ユーザーガイドの「AWS CLI の設定」を参照してください。

コンソールを使用してクラスターを作成するには

1. Open the Amazon EKS console at https://console.aws.amazon.com/eks/home#/clusters.2. [Create cluster] を選択します。

Note

IAM ユーザーに管理者権限がない場合は、Amazon EKS API オペレーションを呼び出すために、そのユーザーのアクセス許可を明示的に追加する必要があります。詳細については、「Amazon EKS アイデンティティベースのポリシーの例 (p. 251)」を参照してください。

3. [Configure cluster (クラスターの設定)] ページで、次のフィールドに入力します。

• 名前 – クラスターの一意の名前。• Kubernetes version (Kubernetes バージョン) – クラスターで使用する Kubernetes のバージョン。

Important

このガイドでは、利用可能な最新バージョンを選択する必要があります。• Cluster service role (クラスターサービスのロール) – 「Amazon EKS クラスターの IAM ロールの作

成 (p. 10)」で作成した IAM ロールを選択します。• シークレットの暗号化 – (オプション) AWS Key Management Service (AWS KMS) を使用して

Kubernetes シークレットのエンベロープ暗号化を有効にするよう選択します。エンベロープ暗号化を有効にすると、選択したカスタマーマスターキー (CMK) を使用して Kubernetes シークレットが暗号化されます。CMK は対称で、クラスターと同じリージョンで作成する必要があります。CMKが別のアカウントで作成されている場合は、ユーザーが CMK にアクセスできる必要があります。詳細については、『AWS Key Management Service 開発者ガイド』の「他のアカウントのユーザーに CMK の使用を許可する」を参照してください。AWS KMS CMK を使用した Kubernetes シークレット暗号化には、Kubernetes バージョン 1.13 以降が必要です。キーが一覧表示されていない場合は、最初にキーを作成する必要があります。詳細については、「キーの作成」を参照してください。

• [タグ] –（オプション）クラスターにタグを追加します。詳細については、「Amazon EKS リソースのタグ付け (p. 285)」を参照してください。

4. [Next (次へ)] を選択します。5. [Specify networking (ネットワーキングの指定)] ページで、次のフィールドの値を選択します。

• VPC – 「the section called “Amazon EKS クラスター VPC を作成する” (p. 12)」で前に作成したVPC。ドロップダウンリストで VPC の名前を検索できます。

• サブネット – デフォルトでは、前のフィールドで指定した VPC 内の利用可能なサブネットがあらかじめ選択されています。ワーカーノードやロードバランサーなど、クラスターリソースをホストしないサブネットを選択します。

• セキュリティグループ – 「Amazon EKS クラスター VPC を作成する (p. 12)」で生成した AWSCloudFormation 出力の [SecurityGroups] 値。このセキュリティグループのドロップダウン名は[ControlPlaneSecurityGroup] です。

Important

ここで指定するセキュリティグループは、ワーカーノード AWS CloudFormation テンプレートによって変更されるため、Amazon EKS では、クラスターコントロールプレーンごとに専用のセキュリティグループを使用することを強くお勧めします (クラスターごとに 1

15

https://github.com/kubernetes-sigs/aws-iam-authenticator



https://console.aws.amazon.com/eks/home#/clusters

https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html


https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html

Amazon EKS ユーザーガイドステップ 2: kubeconfig ファイルを作成する

つ)。セキュリティグループが他のリソースと共有されている場合は、これらのリソースへの接続をブロックまたは妨害する可能性があります。

• [Cluster endpoint access (クラスターエンドポイントのアクセス)] の場合 – 次のいずれかのオプションを選択します。• パブリック – クラスターの Kubernetes API サーバーエンドポイントへのパブリックアクセスのみ

を有効にします。クラスターの VPC の外部から送信される Kubernetes API リクエストは、パブリックエンドポイントを使用します。デフォルトでは、任意の送信元 IP アドレスからのアクセスが許可されます。たとえば、必要に応じて、[詳細設定] を選択し、次に [Add source (ソースの追加)] を選択して、192.168.0.0/16 などの 1 つ以上の CIDR 範囲へのアクセスを制限できます。

• プライベート – クラスターの Kubernetes API サーバーエンドポイントへのプライベートアクセスのみを有効にします。クラスターの VPC 内から送信される Kubernetes API リクエストは、プライベート VPC エンドポイントを使用します。

• Public and private (パブリックおよびプライベート) – パブリックおよびプライベートアクセスを有効にします。

前のオプションの詳細については、「??? (p. 37)」を参照してください。6. [Next (次へ)] を選択します。7. [ログ記録の構成] ページで、有効にするログタイプをオプションで選択できます。各ログタイプは、

デフォルトで [無効] になっています。詳細については、「Amazon EKS コントロールプレーンのログ記録 (p. 42)」を参照してください。

8. [Next (次へ)] を選択します。9. [確認と作成] ページで、前のページで入力または選択した情報を確認します。選択内容を変更する必

要がある場合は、[編集] を選択します。設定が適切であることを確認したら、[作成] を選択します。クラスターのプロビジョニングプロセスが完了するまで、[状況] フィールドには [作成中] と表示されます。

Note

リクエスト内のアベイラビリティーゾーンのいずれかに、Amazon EKS クラスターを作成するのに十分なキャパシティーがないというエラーが表示される場合があります。この場合、エラー出力には、新しいクラスターをサポートできるアベイラビリティーゾーンが含まれます。アカウント向けにサポートされているアベイラビリティーゾーンにある 2 つ以上のサブネットを使用して、クラスターを作成します。詳細については、「容量不足 (p. 298)」を参照してください。

クラスターのプロビジョニングが完了したら (通常 10 ～ 15 分)、[API サーバーエンドポイント] および [認証機関] 値を書き留めます。これらは、kubectl 設定で使用されます。

ステップ 2: kubeconfig ファイルを作成するこのセクションでは、クラスターの kubeconfig ファイルを AWS CLI update-kubeconfig コマンドを使って作成します。AWS CLI をインストールしない場合、または kubeconfig を手作業で作成または更新する場合は、「kubeconfig を Amazon EKS 用に作成します。 (p. 199)」を参照してください。

kubeconfig ファイルを AWS CLI で作成するには

1. AWS CLI のバージョン 1.18.49 以降がインストールされていることを確認します。AWS CLI をインストールまたはアップグレードするには、AWS Command Line Interface ユーザーガイドの「AWS コマンドラインインターフェイスのインストール」を参照してください。

Note

システムの Python のバージョンは 2.7.9 以降であることが必要です。そうでない場合は、AWS CLI で Amazon EKS を呼び出すと hostname doesn't match エラーが発生します。

16



Amazon EKS ユーザーガイドステップ 3: マネージド型ノードグループの起動


aws --version

Important


2. クラスターの kubeconfig を作成または更新するには、AWS CLI update-kubeconfig コマンドを使用します。

• デフォルトでは、最終的な設定ファイルは、ホームディレクトリのデフォルト kubeconfig パス(.kube/config) に作成されるか、その場所で既存 kubeconfig とマージされます。別のパスは --kubeconfig オプションを使用して指定できます。

• kubectl コマンドを実行するときに、認証に使用する --role-arn オプションを指定して IAMロール ARN を指定できます。それ以外の場合は、デフォルトの AWS CLI または SDK の認証情報チェーンの中の IAM エンティティが使用されます。デフォルトの AWS CLI または SDK の ID を表示するには、 aws sts get-caller-identity コマンドを実行します。

• 詳細については、aws eks update-kubeconfig help コマンドを使用するか、AWS CLI CommandReference の「update-kubeconfig」を参照してください。

Note

以下のコマンドを実行するには、指定したクラスター名に対する eks:DescribeClusterIAM アクセス許可がアカウントに割り当てられている必要があります。

aws eks --region region-code update-kubeconfig --name cluster_name

3. 設定をテストします。

kubectl get svc

Note


出力:


ステップ 3: マネージド型ノードグループの起動これで、VPC および Kubernetes コントロールプレーンが作成され、マネージド型ノードグループを起動し、設定できるようになりました。

17


https://docs.aws.amazon.com/cli/latest/reference/eks/update-kubeconfig.html


Important

Amazon EKS ワーカーノードは標準の Amazon EC2 インスタンスであり、通常の Amazon EC2インスタンス価格に基づいて請求されます。詳細については、「Amazon EC2 料金表」を参照してください。

Amazon EKS ワーカーノード kubelet デーモンは、ユーザーに代わって AWS API への呼び出しを実行します。ワーカーノードは、IAM インスタンスプロファイルおよび関連ポリシーを通じて、これらの APIコールのアクセス許可を受け取ります。ワーカーノードを起動してクラスターに登録する前に、起動するときに使用するワーカーノード用の IAM ロールを作成する必要があります。詳細については、「AmazonEKS ワーカーノード IAM ロール (p. 260)」を参照してください。AWS マネジメントコンソールまたはAWS CloudFormation を使用してロールを作成できます。ロールの作成に使用するツールの名前が付いているタブを選択します。

Note

クラスターごとに新しいワーカーノード IAM ロールを作成することをお勧めします。そうしない場合、あるクラスターのノードが、属していない別のクラスターで認証される可能性があります。


IAM コンソールで Amazon EKS ワーカーノードロールを作成するには

1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。2. [ロール] を選択してから [ロールの作成] を選びます。3. サービスのリストから [EC2] を選択し、[Next: Permissions (次へ: アクセス許可)] を選択します。4. [Filter policies (フィルタポリシー)] ボックスに「AmazonEKSWorkerNodePolicy」と入力しま

す。[AmazonEKSWorkerNodePolicy] の左側にあるチェックボックスをオンにします。5. [Filter policies (フィルタポリシー)] ボックスに「AmazonEKS_CNI_Policy」と入力します。

[AmazonEKS_CNI_Policy] の左側にあるチェックボックスをオンにします。6. [Filter policies (フィルタポリシー)] ボックスに「AmazonEC2ContainerRegistryReadOnly」

と入力します。[AmazonEC2ContainerRegistryReadOnly] の左側にあるチェックボックスをオンにします。

7. [次へ: タグ] を選択します。8. (オプション) タグをキーと値のペアとしてアタッチして、メタデータをロールに追加しま


9. [Next: Review] を選択します。10. [ロール名] にロールの一意の名前 (NodeInstanceRole など) を入力します。[ロールの説明]

で、現在のテキストを「Amazon EKS - Node Group Role」などの説明テキストに置き換え、[ロールの作成] を選択します。

AWS CloudFormation

AWS CloudFormation を使用して Amazon EKS ワーカーノードロールを作成するには

1. AWS CloudFormation コンソール (https://console.aws.amazon.com/cloudformation) を開きます。2. [スタックの作成] を選択し、[With new resources (standard) 新しいリソースを使用 (標準)] を選択

します。3. [Specify template (テンプレートを指定)] で、[Amazon S3 URL] を選択します。4. 以下の URL を [Amazon S3 URL] テキストエリアに貼り付け、[Next (次へ)] を選択します。

18

https://aws.amazon.com/ec2/pricing/






https://amazon-eks.s3.us-west-2.amazonaws.com/cloudformation/2020-04-21/amazon-eks-nodegroup-role.yaml

5. [Specify stack details (スタックの詳細の指定)] ページで、[スタックの名前] に「eks-node-group-instance-role」などの名前を入力し、[Next (次へ)] を選択します。

6. (オプション) [Configure stack options (スタックオプションの設定)] ページで、スタックリソースをタグ付けできます。[次へ] を選択します。

7. [確認] ページで、[機能] セクションのチェックボックスをオンにして、[スタックの作成] を選択します。

8. スタックが作成されたら、コンソールで選択し、[出力] を選択します。9. 作成された IAM ロールの [NodeInstanceRole] 値を記録します。これは、ノードグループを作成

するときに必要です。

マネージド型ノードグループを起動するには

1. クラスターステータスが ACTIVE と表示されるまで待ちます。まだ ACTIVE ではないクラスターにはマネージド型ノードグループを作成できません。

2. Open the Amazon EKS console at https://console.aws.amazon.com/eks/home#/clusters.3. マネージド型ノードグループを作成するクラスターの名前を選択します。4. [クラスター] ページで、[Add node group (ノードグループの追加)] を選択します。5. [Configure node group (ノードグループの設定)] ページで、必要に応じてパラメータを指定し、[次へ]

を選択します。

• [名前] — マネージド型ノードグループの一意の名前を入力します。• [ノード IAM ロール名] — ノードグループで使用するノードインスタンスロールを選択します。詳細

については、「Amazon EKS ワーカーノード IAM ロール (p. 260)」を参照してください。

Important

セルフマネージドノードグループによって現在使用されていないロールを使用するか、新しいセルフマネージドノードグループで使用する予定のロールを使用することをお勧めします。詳細については、「??? (p. 94)」を参照してください。

• [サブネット] — マネージド型ノードを起動するサブネットを選択します。

Important

Amazon EBS ボリュームによってバックアップされ、Kubernetes ClusterAutoscaler (p. 140) を使用する複数のアベイラビリティーゾーンにわたってステートフルアプリケーションを実行している場合、それぞれが単一のアベイラビリティーゾーンにスコープされる複数のノードグループを設定する必要があります。また、--balance-similar-node-groups 機能を有効にする必要があります。

Important

パブリックサブネットを選択した場合、インスタンスがクラスターに正常に参加するには、そのサブネットの MapPublicIpOnLaunch を true に設定する必要があります。サブネットが 03/26/2020 以降に eksctl または Amazon EKS から発行された AWSCloudFormation テンプレート (p. 158)を使用して作成されている場合、この設定はすでに true に設定されています。サブネットが 03/26/2020 より前に eksctl または AWSCloudFormation テンプレートを使用して作成されている場合は、設定を手動で変更する必要があります。詳細については、「サブネットの IPv4 アドレス指定属性の変更」を参照してください。

• [リモートアクセス] —（オプション）マネージド型ノードグループ内のノードへの SSH アクセスを有効にすることができます。SSH を有効にすることにより、インスタンスに接続し、問題がある場合に診断情報を収集できます。リモートアクセスを有効にするには、以下の手順に従います。

19


https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-ip-addressing.html#subnet-public-ip


Note

ノードグループを作成するときは、リモートアクセスを有効にすることを強くお勧めします。ノードグループの作成後にリモートアクセスを有効にすることはできません。

1. [Allow remote access to nodes (ノードへのリモートアクセスを許可する)] チェックボックスをオンにします。

2. [SSH キーペア] の場合は、使用する Amazon EC2 SSH キーを選択します。詳細については、『Linux インスタンス用 Amazon EC2 ユーザーガイド』の「Amazon EC2 のキーペア」を参照してください。

3. [Allow remote access from (許可するリモートアクセス元)] で、[すべて] を選択してインターネット上の任意の場所 (0.0.0.0/0) から SSH アクセスを許可するか、セキュリティグループを選択して、そのセキュリティグループに属するインスタンスからの SSH アクセスを許可します。

• [タグ] —（オプション）Amazon EKS マネージド型ノードグループにタグを付けるように選択できます。これらのタグは、Auto Scaling グループやインスタンスなど、ノードグループ内の他のリソースには伝達されません。詳細については、「Amazon EKS リソースのタグ付け (p. 285)」を参照してください。

• [Kubernetes labels (Kubernetes ラベル)] —（オプション）マネージド型ノードグループ内のノードに Kubernetes ラベルを適用するように選択できます。

6. [Set compute configuration (コンピューティング構成の設定)] ページで、必要に応じてパラメータを指定し、[次へ] を選択します。

• [AMI タイプ] — GPU 以外のインスタンスの場合は [Amazon Linux 2 (AL2_x86_64)] を選択し、GPUインスタンスの場合は [Amazon Linux 2 GPU Enabled (AL2_x86_64_GPU) (Amazon Linux 2 GPU有効 (AL2_x86_64_GPU))] を選択します。

• [インスタンスタイプ] — マネージド型ノードグループで使用するインスタンスタイプを選択します。大きいインスタンスタイプほど、多くのポッドに対応できます。

• [ディスクサイズ] — ワーカーノードのルートボリュームに使用するディスクサイズ（GiB 単位）を入力します。

7. [Setup scaling policies (スケーリングポリシーの設定)] ページで、必要に応じてパラメータを入力し、[次へ] を選択します。

Note

Amazon EKS は、ノードグループを自動的にスケールインまたはスケールアウトしません。ただし、これを行うように Kubernetes Cluster Autoscaler (p. 140) を設定することはできます。

• [最小サイズ] — マネージド型ノードグループがスケールインできるワーカーノードの最小数を指定します。

• [最大サイズ] — マネージド型ノードグループがスケールアウトできるワーカーノードの最大数を指定します。

• [必要なサイズ] — マネージド型ノードグループが起動時に保持する必要があるワーカーノードの現在の数を指定します。

8. [確認と作成] ページで、マネージド型ノードグループの設定を確認し、[作成] を選択します。9. ノードのステータスを監視し、Ready ステータスになるまで待機します。

kubectl get nodes --watch

10. （GPU ワーカーのみ） GPU インスタンスタイプと Amazon EKS 最適化 AMI GPU 対応を選択した場合は、NVIDIA device plugin for Kubernetes を、次のコマンドを使ってクラスターに設定されたデーモンセットとして適用しなければなりません。

20





(オプション) Windows ワーカーノードを起動するには

クラスターに Windows サポートを追加し、Windows ワーカーノードを起動します。詳細については、「Windows サポート (p. 58)」を参照してください。クラスターで Windows ワークロードのみを実行する場合でも、すべての Amazon EKS クラスターには 1 つ以上の Linux ワーカーノードが含まれている必要があります。

次のステップワーカーノードが関連付けられた Amazon EKS クラスターが実行中になったところで、Kubernetes アドオンのインストールとクラスターへのアプリケーションのデプロイを開始できます。以下のトピックは、クラスターの機能を拡張するのに役立ちます。








21



Amazon EKS ユーザーガイドクラスターの作成

Amazon EKS クラスターAmazon EKS クラスターは 2 つの主なコンポーネントで構成されています。

• Amazon EKS コントロールプレーン• コントロールプレーンに登録されている Amazon EKS ワーカーノード

Amazon EKS コントロールプレーンは、etcd、Kubernetes API サーバーなど、Kubernetes ソフトウェアを実行するコントロールプレーンノードで構成されています。コントロールプレーンは AWS によって管理されるアカウントで実行され、Kubernetes API はクラスターに関連付けられている Amazon EKS エンドポイントを使用して公開されます。各 Amazon EKS クラスターコントロールプレーンはシングルテナントで一意であり、独自の Amazon EC2 インスタンスセット上で実行されます。

etcd ノードおよび関連する Amazon EBS ボリュームによって保存されるすべてのデータは暗号化されます。Amazon EKS はマスター暗号化キーを使用して、Amazon EKS サービスによって管理されるボリューム暗号化キーを生成します。

クラスターコントロールプレーンは、複数のアベイラビリティーゾーンで Elastic Load Balancing NetworkLoad Balancer を前面に置いてプロビジョニングされます。Amazon EKS はまた、コントロールプレーンインスタンスからワーカーノードへの接続を提供するために、VPC サブネットの Elastic NetworkInterface をプロビジョニングします (たとえば、kubectl exec、logs、および proxy データフローをサポートします)。

Amazon EKS ワーカーノードは AWS アカウントで実行され、クラスター API サーバーエンドポイントおよびクラスターに作成された証明書ファイルを使用してクラスターのコントロールプレーンに接続します。

Amazon EKS クラスターの作成このトピックでは、Amazon EKS クラスターを作成する手順を説明します。

Amazon EKS クラスターを初めて作成する場合は、代わりに Amazon EKS の開始方法 (p. 3) ガイドのいずれかに従うことをお勧めします。これらのガイドは、Amazon EKS クラスターとワーカーノードを作成するための完全なエンドツーエンドのチュートリアルを提供します。

Important

Amazon EKS クラスターが作成されたら、クラスターを作成する IAM エンティティ (ユーザーまたはロール) は、管理者 (system:master アクセス許可が付与されている) として KubernetesRBAC 認証テーブルに追加されます。最初は、その IAM ユーザーだけが kubectl を使用してKubernetes API サーバーを呼び出すことができます。詳細については、「クラスターのユーザーまたは IAM ロールの管理 (p. 202)」を参照してください。コンソールを使用してクラスターを作成する場合は、クラスター上で kubectl コマンドを実行する際、同じ IAM ユーザー認証情報がAWS SDK 認証情報チェーンにあることを確認する必要があります。AWS CLI をインストールして設定する場合は、ユーザーの IAM 認証情報を設定できます。AWSCLI がユーザーに対して適切に設定されている場合は、eksctl および AWS IAM Authenticatorfor Kubernetes でこれらの認証情報も検索できます。詳細については、AWS Command LineInterface ユーザーガイドの「AWS CLI の設定」を参照してください。

以下から必要なクラスター作成方法に対応するタブを選択します。

eksctl


22





eksctl version


eksctl を使用してクラスターを作成するには

1. デフォルトのリージョンに、Amazon EKS のデフォルトバージョンを使用してクラスターを作成します。my-cluster を独自の値に置き換えます。

eksctl create cluster \ --name my-cluster \ --without-nodegroup

クラスターのプロビジョニングには数分かかります。クラスターの作成中に、数行の出力が表示されます。出力の最後の行は、次のサンプル行のようになります。

[✓] EKS cluster "my-cluster" in "region-code" region is ready

2. クラスターの準備ができたら、kubectl 設定が正しいことをテストします。

kubectl get svc

Note

"aws-iam-authenticator": executable file not found in $PATH エラーが発生した場合、kubectl は、Amazon EKS に設定されていません。詳細については、「aws-iam-authenticator のインストール (p. 196)」を参照してください。その他の認可またはリソースタイプのエラーが発生した場合は、トラブルシューティングセクションの許可されていないか、アクセスが拒否されました (kubectl) (p. 299)を参照してください。

出力:


3. (オプション) ポッドをクラスター内の AWS Fargate で実行する場合は、「??? (p. 117)」と「??? (p. 117)」を参照してください。

4. ワークロードをサポートするために「Amazon EKS Linux ワーカーノードの起動 (p. 95)」の手順に従ってクラスターに Linux ワーカーノードを追加します。

5. (オプション) Linux ワーカーノードをクラスターに追加したら、「Windows サポート (p. 58)」の手順に従って Windows サポートをクラスターに追加し、Windows ワーカーノードを追加します。クラスターで Windows ワークロードのみを実行する場合でも、すべての Amazon EKS クラスターには 1 つ以上の Linux ワーカーノードが含まれている必要があります。


この手順には、以下の前提条件があります。

• Amazon EKS クラスターの要件を満たす VPC および専用セキュリティグループを作成済みです。詳細については、「クラスター VPC に関する考慮事項 (p. 161)」および「Amazon EKS セキュリティグループの考慮事項 (p. 164)」を参照してください。AWS マネジメントコンソールの使用開始 (p. 10) ガイドでは、要件を満たす VPC を作成します。または、「Amazon EKS クラスター用のVPC の作成 (p. 158)」に従って作成することもできます。

23


• クラスターに適用する Amazon EKS クラスターの IAM ロールは作成済みです。Amazon EKSの開始方法 (p. 3) ガイドでは、サービスロールを作成します。または、Amazon EKS IAM ロール (p. 250) に従って、手動で作成することもできます。

コンソールを使用してクラスターを作成するには

1. Open the Amazon EKS console at https://console.aws.amazon.com/eks/home#/clusters.2. [Create cluster] を選択します。

Note


3. [Configure cluster (クラスターの設定)] ページで、次のフィールドに入力します。

• 名前 – クラスターの一意の名前。• Kubernetes version (Kubernetes バージョン) – クラスターで使用する Kubernetes のバージョ

ン。

Unless you require a specific Kubernetes version for your application, we recommend that youuse the latest version available in Amazon EKS.

Important

Kubernetes バージョン 1.13 は Amazon EKS で廃止されました。2020 年 6 月 30日に、Kubernetes バージョン 1.13 は Amazon EKS でサポートされなくなりました。この日付以降、新しい 1.13 クラスターを作成することはできなくなりました。Kubernetes バージョン 1.13 を実行しているすべての既存の Amazon EKS クラスターは最終的に、バージョン 1.14 に自動的に更新されます。サービスの中断を防ぐため、1.13 クラスターはバージョン 1.14 以降に更新することをお勧めします。詳細については、「Amazon EKS バージョンの廃止 (p. 51)」を参照してください。Kubernetes バージョン 1.12 は Amazon EKS で廃止されました。2020 年 5 月 11日に、Kubernetes バージョン 1.12 は Amazon EKS でサポートされなくなりました。この日付以降、新しい 1.12 クラスターを作成することはできなくなりました。Kubernetes バージョン 1.12 を実行しているすべての既存の Amazon EKS クラスターは最終的に、バージョン 1.13 に自動的に更新されます。サービスの中断を防ぐため、1.12 クラスターはバージョン 1.13 以降に更新することをお勧めします。詳細については、「Amazon EKS バージョンの廃止 (p. 51)」を参照してください。Amazon EKS で利用可能な Kubernetes API のバージョンは、そのバージョンを使用してクラスターを作成する機能が削除されるまで、AWS によって公式にサポートされます。これは、Amazon EKS で利用可能なバージョンがアップストリーム Kubernetesによってサポートされなくなった場合でも当てはまります。Amazon EKS でサポートされている Kubernetes のバージョンに適用可能なセキュリティ修正はバックポートされています。既存のクラスターはサポートされている状態に常に保たれます。サポート終了日までに手動で更新していない場合、サポートされているバージョンにAmazon EKS によって自動的に更新されます。

• Cluster service role – Choose the Amazon EKS cluster role to allow the Kubernetes controlplane to manage AWS resources on your behalf. For more information, see Amazon EKS クラスターの IAM ロール (p. 258).

• シークレットの暗号化 – (オプション) AWS Key Management Service (AWS KMS) を使用してKubernetes シークレットのエンベロープ暗号化を有効にするよう選択します。エンベロープ暗号化を有効にすると、選択したカスタマーマスターキー (CMK) を使用して Kubernetes シークレットが暗号化されます。CMK は対称で、クラスターと同じリージョンで作成する必要があります。CMK が別のアカウントで作成されている場合は、ユーザーが CMK にアクセスできる必要があります。詳細については、『AWS Key Management Service 開発者ガイド』の「他のア

24




カウントのユーザーに CMK の使用を許可する」を参照してください。AWS KMS CMK を使用した Kubernetes シークレット暗号化には、Kubernetes バージョン 1.13 以降が必要です。キーが一覧表示されていない場合は、最初にキーを作成する必要があります。詳細については、「キーの作成」を参照してください。

• [タグ] –（オプション）クラスターにタグを追加します。詳細については、「Amazon EKS リソースのタグ付け (p. 285)」を参照してください。

4. [Next (次へ)] を選択します。5. [Specify networking (ネットワーキングの指定)] ページで、次のフィールドの値を選択します。

• VPC – Select an existing VPC to use for your cluster. If none are listed, then you need to createone first. For more information, see ??? (p. 158).

• Subnets – By default, the available subnets in the VPC specified in the previous field arepreselected. Select any subnet that you don't want to host cluster resources, such as workernodes or load balancers. The subnets must meet the requirements for an Amazon EKS cluster.For more information, see クラスター VPC に関する考慮事項 (p. 161).

Important

If you select subnets that were created before 03/26/2020 using one of the AmazonEKS AWS CloudFormation VPC templates, be aware of a default setting change thatwas introduced on 03/26/2020. For more information, see ??? (p. 158).

• セキュリティグループ – 「Amazon EKS クラスター VPC を作成する (p. 12)」で生成した AWSCloudFormation 出力の [SecurityGroups] 値。このセキュリティグループのドロップダウン名は[ControlPlaneSecurityGroup] です。

Important

ここで指定するセキュリティグループは、ワーカーノード AWS CloudFormation テンプレートによって変更されるため、Amazon EKS では、クラスターコントロールプレーンごとに専用のセキュリティグループを使用することを強くお勧めします (クラスターごとに 1 つ)。セキュリティグループが他のリソースと共有されている場合は、これらのリソースへの接続をブロックまたは妨害する可能性があります。

• [Cluster endpoint access (クラスターエンドポイントのアクセス)] の場合 – 次のいずれかのオプションを選択します。• パブリック – クラスターの Kubernetes API サーバーエンドポイントへのパブリックアクセ

スのみを有効にします。クラスターの VPC の外部から送信される Kubernetes API リクエストは、パブリックエンドポイントを使用します。デフォルトでは、任意の送信元 IP アドレスからのアクセスが許可されます。たとえば、必要に応じて、[詳細設定] を選択し、次に [Addsource (ソースの追加)] を選択して、192.168.0.0/16 などの 1 つ以上の CIDR 範囲へのアクセスを制限できます。

• プライベート – クラスターの Kubernetes API サーバーエンドポイントへのプライベートアクセスのみを有効にします。クラスターの VPC 内から送信される Kubernetes API リクエストは、プライベート VPC エンドポイントを使用します。

• Public and private (パブリックおよびプライベート) – パブリックおよびプライベートアクセスを有効にします。

前のオプションの詳細については、「??? (p. 37)」を参照してください。6. [Next (次へ)] を選択します。7. [ログ記録の構成] ページで、有効にするログタイプをオプションで選択できます。各ログタイプ

は、デフォルトで [無効] になっています。詳細については、「Amazon EKS コントロールプレーンのログ記録 (p. 42)」を参照してください。

8. [Next (次へ)] を選択します。9. [確認と作成] ページで、前のページで入力または選択した情報を確認します。選択内容を変更す

る必要がある場合は、[編集] を選択します。設定が適切であることを確認したら、[作成] を選択25


https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html


します。クラスターのプロビジョニングプロセスが完了するまで、[状況] フィールドには [作成中] と表示されます。

Note


Cluster provisioning usually takes between 10 and 15 minutes.10. Now that you have created your cluster, follow the procedures in aws-iam-authenticator の

インストール (p. 196) and kubeconfig を Amazon EKS 用に作成します。 (p. 199) to enablecommunication with your new cluster.

11. (Optional) If you want to run pods on AWS Fargate in your cluster, see Amazon EKS での AWSFargate の開始方法 (p. 115).

12. After you enable communication, follow the procedures in Amazon EKS Linux ワーカーノードの起動 (p. 95) to add Linux worker nodes to your cluster to support your workloads.

13. (Optional) After you add Linux worker nodes to your cluster, follow the procedures in Windows サポート (p. 58) to add Windows support to your cluster and to add Windows worker nodes. AllAmazon EKS clusters must contain at least one Linux worker node, even if you only want to runWindows workloads in your cluster.

AWS CLI

AWS CLI を使用してクラスターを作成するには

この手順には、以下の前提条件があります。

• Amazon EKS クラスターの要件を満たす VPC および専用セキュリティグループを作成済みです。詳細については、「クラスター VPC に関する考慮事項 (p. 161)」および「Amazon EKS セキュリティグループの考慮事項 (p. 164)」を参照してください。AWS マネジメントコンソールの使用開始 (p. 10) ガイドでは、要件を満たす VPC を作成します。または、「Amazon EKS クラスター用のVPC の作成 (p. 158)」に従って作成することもできます。

• クラスターに適用する Amazon EKS クラスターの IAM ロールは作成済みです。Amazon EKSの開始方法 (p. 3) ガイドでは、サービスロールを作成します。または、Amazon EKS IAM ロール (p. 250) に従って、手動で作成することもできます。

1. 以下のコマンドを使用して、クラスターを作成します。「Amazon EKS クラスターの IAM ロールの作成 (p. 10)」で作成した Amazon EKS クラスターの IAM ロールの Amazon リソースネーム (ARN) をクラスター名として代わりに使用し、「Amazon EKS クラスター VPC を作成する (p. 12)」で作成した VPC のサブネットとセキュリティグループ ID を代わりに使用します。

Important

Kubernetes バージョン 1.13 は Amazon EKS で廃止されました。2020 年 6 月 30日に、Kubernetes バージョン 1.13 は Amazon EKS でサポートされなくなりました。この日付以降、新しい 1.13 クラスターを作成することはできなくなりました。Kubernetesバージョン 1.13 を実行しているすべての既存の Amazon EKS クラスターは最終的に、バージョン 1.14 に自動的に更新されます。サービスの中断を防ぐため、1.13 クラスターはバージョン 1.14 以降に更新することをお勧めします。詳細については、「AmazonEKS バージョンの廃止 (p. 51)」を参照してください。Kubernetes バージョン 1.12 は Amazon EKS で廃止されました。2020 年 5 月 11日に、Kubernetes バージョン 1.12 は Amazon EKS でサポートされなくなりました。こ

26


の日付以降、新しい 1.12 クラスターを作成することはできなくなりました。Kubernetesバージョン 1.12 を実行しているすべての既存の Amazon EKS クラスターは最終的に、バージョン 1.13 に自動的に更新されます。サービスの中断を防ぐため、1.12 クラスターはバージョン 1.13 以降に更新することをお勧めします。詳細については、「AmazonEKS バージョンの廃止 (p. 51)」を参照してください。Amazon EKS で利用可能な Kubernetes API のバージョンは、そのバージョンを使用してクラスターを作成する機能が削除されるまで、AWS によって公式にサポートされます。これは、Amazon EKS で利用可能なバージョンがアップストリーム Kubernetes によってサポートされなくなった場合でも当てはまります。Amazon EKS でサポートされている Kubernetes のバージョンに適用可能なセキュリティ修正はバックポートされています。既存のクラスターはサポートされている状態に常に保たれます。サポート終了日までに手動で更新していない場合、サポートされているバージョンに Amazon EKS によって自動的に更新されます。

aws eks --region region-code create-cluster \ --name devel --kubernetes-version 1.16 \ --role-arn \ arn:aws:iam::111122223333:role/eks-service-role-AWSServiceRoleForAmazonEKS-EXAMPLEBKZRQR \ --resources-vpc-config \ subnetIds=subnet-a9189fe2,subnet-50432629,securityGroupIds=sg-f5c54184

Important

次のような構文エラーが表示された場合は、プレビューバージョンの Amazon EKS 用AWS CLI を使用している可能性があります。コマンドの多くの構文は、パブリックサービスの公開後に変更されています。AWS CLI を利用可能な最新のバージョンに更新し、~/.aws/models/eks のカスタムサービスモデルディレクトリを削除してください。

aws: error: argument --cluster-name is required

Note


出力:

{ "cluster": { "name": "devel", "arn": "arn:aws:eks:region-code:111122223333:cluster/devel", "createdAt": 1527785885.159, "version": "1.16", "roleArn": "arn:aws:iam::111122223333:role/eks-service-role-AWSServiceRoleForAmazonEKS-AFNL4H8HB71F", "resourcesVpcConfig": { "subnetIds": [ "subnet-a9189fe2", "subnet-50432629" ], "securityGroupIds": [ "sg-f5c54184" ], "vpcId": "vpc-a54041dc", "endpointPublicAccess": true,

27


"endpointPrivateAccess": false }, "status": "CREATING", "certificateAuthority": {} }}

Note


AWS Key Management Service (AWS KMS) からのカスタマーマスターキー (CMK) を使用してKubernetes シークレットを暗号化するには、最初に create-key オペレーションを使用して CMKを作成します。

MY_KEY_ARN=$(aws kms create-key --query KeyMetadata.Arn —output text)

--encryption-config パラメータを aws eks create-cluster コマンドに追加します。Kubernetes シークレットの暗号化は、クラスターの作成時にのみ有効にできます。

--encryption-config '[{"resources":["secrets"],"provider":{"keyArn":"$MY_KEY_ARN"}}]'

keyArn メンバーには、CMK のエイリアスまたは ARN のいずれかを含めることができます。CMK は対称で、クラスターと同じリージョンで作成する必要があります。CMK が別のアカウントで作成されている場合は、ユーザーが CMK にアクセスできる必要があります。詳細については、『AWS Key Management Service 開発者ガイド』の「他のアカウントのユーザーにCMK の使用を許可する」を参照してください。AWS KMS CMK を使用した Kubernetes シークレット暗号化には、Kubernetes バージョン 1.13 以降が必要です。

2. クラスターのプロビジョニングには通常、10 ~ 15 分かかります。クラスターのステータスのクエリを実行するには、次のコマンドを使用します。クラスターステータスが ACTIVE の場合は、続行できます。

aws eks --region region-code describe-cluster --name devel --query "cluster.status"

3. クラスターのプロビジョニングが完了したら、次のコマンドを使用して endpoint およびcertificateAuthority.data を取得します。これらの値を kubectl 設定に追加する必要があります。これにより、クラスターと通信できるようになります。

a. endpoint を取得します。

aws eks --region region-code describe-cluster --name devel --query "cluster.endpoint" --output text

b. certificateAuthority.data を取得します。

aws eks --region region-code describe-cluster --name devel --query "cluster.certificateAuthority.data" --output text

4. クラスターを作成したら、aws-iam-authenticator のインストール (p. 196) およびkubeconfig を Amazon EKS 用に作成します。 (p. 199) の手順に従って、新しいクラスターとの通信を有効にします。

28

https://docs.aws.amazon.com/goto/aws-cli/kms-2014-11-01/CreateKey



Amazon EKS ユーザーガイドKubernetes バージョンの更新

5. (オプション) ポッドをクラスター内の AWS Fargate で実行する場合は、「Amazon EKS でのAWS Fargate の開始方法 (p. 115)」を参照してください。

6. 通信を有効にしたら、ワークロードをサポートするために「Amazon EKS Linux ワーカーノードの起動 (p. 95)」の手順に従ってクラスターにワーカーノードを追加します。

7. (オプション) Linux ワーカーノードをクラスターに追加したら、「Windows サポート (p. 58)」の手順に従って Windows サポートをクラスターに追加し、Windows ワーカーノードを追加します。クラスターで Windows ワークロードのみを実行する場合でも、すべての Amazon EKS クラスターには 1 つ以上の Linux ワーカーノードが含まれている必要があります。

Amazon EKS クラスターの Kubernetes バージョンの更新

新しい Kubernetes バージョンが Amazon EKS で利用できるようになると、クラスターを最新バージョンに更新することができます。

Important

新しい Kubernetes バージョンに更新する前に、「??? (p. 47)」とこのトピックの更新ステップの情報を確認することをお勧めします。

新しいバージョンの Kubernetes では大幅な変更が加えられているため、本稼働用クラスターで更新を実行する前に、新しいバージョンの Kubernetes に対してアプリケーションの動作をテストすることをお勧めします。そのためには、継続的な統合ワークフローを作成し、新しい Kubernetes バージョンに移行する前にアプリケーションの動作をエンドツーエンドでテストします。

更新プロセスは、更新された Kubernetes バージョンで新しい API サーバーを起動して既存のバージョンを置き換える Amazon EKS で構成されます。Amazon EKS は、これらの新しいノードでネットワークトラフィックの標準インフラストラクチャと準備状況のヘルスチェックを実行し、予期どおりに動作していることを確認します。これらのヘルスチェックが失敗すると、Amazon EKS はインフラストラクチャのデプロイを元に戻します。クラスターは前の Kubernetes バージョンのままになります。実行中のアプリケーションは影響を受けません。また、クラスターが非決定的または回復不可能な状態のままになることはありません。Amazon EKS は定期的にすべてのマネージド型クラスターをバックアップします。また、必要に応じてクラスターを復元するメカニズムが存在します。Kubernetes インフラストラクチャの管理プロセスは、継続的に評価、改善されています。

クラスターをアップグレードするためには、クラスターの作成時に指定したサブネットから、2～3 の空きIP アドレスが Amazon EKS に必要です。これらのサブネットに使用可能な IP アドレスがない場合、アップグレードが失敗することがあります。さらに、クラスターの作成時に指定されたいずれかのサブネットやセキュリティグループが削除された場合、クラスターのアップグレードが失敗することがあります。

Note

Amazon EKS は可用性の高いコントロールプレーンが実行されますが、更新時にサービスが短時間中断することがあります。たとえば、終了直前または終了直後に新しいバージョンのKubernetes を実行している新しい API サーバーに接続しようとすると、API コールエラーや接続の問題が発生する可能性があります。この場合は、成功するまで API オペレーションを繰り返し実行します。

Amazon EKS は、クラスターの更新時に Kubernetes アドオンを変更しません。クラスターの更新後、更新後の新しいバージョンの Kubernetes 用に、アドオンを次の表に記載のバージョンに更新することをお勧めします。これを実行するためのステップは、更新手順に含まれています。

29

Amazon EKS ユーザーガイド既存のクラスターの更新

Kubernetesバージョン

1.16 1.15 1.14 1.13 1.12

Amazon VPCCNI プラグイン

1.6.1 1.6.1 1.6.1 1.6.1 1.6.1

DNS(CoreDNS)

1.6.6 1.6.6 1.6.6 1.6.6 1.6.6

KubeProxy 1.16.8 1.15.11 1.14.9 1.13.12 1.12.10

上記の表に記載されていない追加のアドオンをクラスターに使用する場合は、クラスターの更新後にそれらを最新の互換バージョンに更新します。

既存のクラスターの更新クラスターと Kubnernete アドオンを更新します。

既存のクラスターを更新するには

1. Kubernetes バージョンのクラスターコントロールプレーンと Kubernetes バージョンのワーカーノードを比較します。

• 次のコマンドで、Kubernetes バージョンのクラスターコントロールプレーンを取得します。

kubectl version --short

• 次のコマンドで、Kubernetes バージョンのワーカーノードを取得します。

kubectl get nodes

ワーカーノードがコントロールプレーンよりも古い複数の Kubernetes マイナーバージョンの場合は、クラスターの Kubernetes バージョンを更新する前に、ワーカーノードを新しい Kubernetes マイナーバージョンにアップグレードする必要があります。詳細については、Kubernetes ドキュメントの「Kubernetes のバージョンおよびバージョンスキューのサポートポリシー」を参照してください。

クラスターを更新する前に、ワーカーノードをクラスターの現在の更新前の Kubernetes マイナーバージョンに更新することをお勧めします。コントロールプレーンより新しい Kubernetes バージョンをワーカーノードで実行しないでください。たとえば、コントロールプレーンでバージョン 1.15 を実行し、ワーカーでバージョン 1.13 を実行している場合は、クラスターの Kubernetes バージョンを1.16 に更新する前に、ワーカーノードをバージョン 1.14 または 1.15 (推奨) に更新します。詳細については、「セルフマネージド型ワーカーノードの更新 (p. 105)」を参照してください。

2. ポッドセキュリティポリシーのアドミッションコントローラーは、Kubernetes バージョン 1.13 以降を実行している Amazon EKS クラスターに対して有効になります。クラスターを Kubernetes バージョン 1.13 以降にアップグレードする場合は、問題を回避するために、適切なポッドセキュリティポリシーが設定されていることを確認してから、その更新を行います。以下のコマンドを使用して、デフォルトのポリシーを表示できます。

kubectl get psp eks.privileged

以下のエラーが表示された場合は、先に進む前に「デフォルトのポッドセキュリティポリシーをインストールまたは復元するには (p. 283)」を参照してください。

30

https://kubernetes.io/docs/setup/release/version-skew-policy/


Error from server (NotFound): podsecuritypolicies.extensions "eks.privileged" not found

3. クラスターを更新します。手順については、クラスターの更新に使用するツールの名前が付いているタブを選択します。

eksctl


eksctl version


Note

この手順は、eksctl で作成されたクラスターに対してのみ機能します。

以下のコマンドを使用して、Amazon EKS クラスターの Kubernetes バージョンを最新バージョンに更新します。dev は実際のクラスター名に置き換えてください。

Important

1.16 に更新するには、事前にデプロイ済みのリソースの一部を更新する必要があります。詳細については、「the section called “Kubernetes 1.16 にアップグレードにするための前提条件” (p. 36)」を参照してください。

eksctl update cluster --name dev --approve

このプロセスが完了するまでに数分かかります。AWS マネジメントコンソール

1. Open the Amazon EKS console at https://console.aws.amazon.com/eks/home#/clusters.2. 更新するクラスターの名前を選択し、[Update cluster version (クラスターバージョンの更新)]

を選択します。3. [Kubernetes version] で、バージョンを選択してクラスターを更新し、[更新] を選択します。

Important


Important

Kubernetes バージョン 1.13 は Amazon EKS で廃止されました。2020 年 6 月 30日に、Kubernetes バージョン 1.13 は Amazon EKS でサポートされなくなりました。この日付以降、新しい 1.13 クラスターを作成することはできなくなりました。Kubernetes バージョン 1.13 を実行しているすべての既存の Amazon EKS クラスターは最終的に、バージョン 1.14 に自動的に更新されます。サービスの中断を防ぐため、1.13 クラスターはバージョン 1.14 以降に更新することをお勧めします。詳細については、「Amazon EKS バージョンの廃止 (p. 51)」を参照してください。Kubernetes バージョン 1.12 は Amazon EKS で廃止されました。2020 年 5 月 11日に、Kubernetes バージョン 1.12 は Amazon EKS でサポートされなくなりました。この日付以降、新しい 1.12 クラスターを作成することはできなくなりまし31



た。Kubernetes バージョン 1.12 を実行しているすべての既存の Amazon EKS クラスターは最終的に、バージョン 1.13 に自動的に更新されます。サービスの中断を防ぐため、1.12 クラスターはバージョン 1.13 以降に更新することをお勧めします。詳細については、「Amazon EKS バージョンの廃止 (p. 51)」を参照してください。Amazon EKS で利用可能な Kubernetes API のバージョンは、そのバージョンを使用してクラスターを作成する機能が削除されるまで、AWS によって公式にサポートされます。これは、Amazon EKS で利用可能なバージョンがアップストリームKubernetes によってサポートされなくなった場合でも当てはまります。Amazon EKSでサポートされている Kubernetes のバージョンに適用可能なセキュリティ修正はバックポートされています。既存のクラスターはサポートされている状態に常に保たれます。サポート終了日までに手動で更新していない場合、サポートされているバージョンに Amazon EKS によって自動的に更新されます。

Important

Amazon EKS は可用性の高いコントロールプレーンを実行しているため、一度に更新できるマイナーバージョンは 1 つのみです。この背後にある論理的根拠については、「Kubernetes Version and Version Skew Support Policy (Kubernetes のバージョンおよびバージョンスキューのサポートポリシー)」を参照してください。したがって、現在のバージョンが 1.14 で、1.16 にアップグレードする場合は、最初にクラスターを1.15 にアップグレードし、その後 1.15 から 1.16 にアップグレードする必要があります。1.14 から 1.16 に直接アップデートしようとすると、バージョン更新コマンドからエラーがスローされます。

4. [クラスター名] にクラスターの名前を入力し、[確認] を選択します。

Note

クラスターの更新は、数分で終了します。

AWS CLI

1. 次の AWS CLI コマンドを使用して、クラスターを作成します。クラスター名と目的のKubernetes マイナーバージョンを置き換えます。

Important


Important

Kubernetes バージョン 1.13 は Amazon EKS で廃止されました。2020 年 6 月 30日に、Kubernetes バージョン 1.13 は Amazon EKS でサポートされなくなりました。この日付以降、新しい 1.13 クラスターを作成することはできなくなりました。Kubernetes バージョン 1.13 を実行しているすべての既存の Amazon EKS クラスターは最終的に、バージョン 1.14 に自動的に更新されます。サービスの中断を防ぐため、1.13 クラスターはバージョン 1.14 以降に更新することをお勧めします。詳細については、「Amazon EKS バージョンの廃止 (p. 51)」を参照してください。Kubernetes バージョン 1.12 は Amazon EKS で廃止されました。2020 年 5 月 11日に、Kubernetes バージョン 1.12 は Amazon EKS でサポートされなくなりました。この日付以降、新しい 1.12 クラスターを作成することはできなくなりました。Kubernetes バージョン 1.12 を実行しているすべての既存の Amazon EKS クラスターは最終的に、バージョン 1.13 に自動的に更新されます。サービスの中断を防ぐため、1.12 クラスターはバージョン 1.13 以降に更新することをお勧めします。詳細については、「Amazon EKS バージョンの廃止 (p. 51)」を参照してください。Amazon EKS で利用可能な Kubernetes API のバージョンは、そのバージョンを使用してクラスターを作成する機能が削除されるまで、AWS によって公式にサポートされます。これは、Amazon EKS で利用可能なバージョンがアップストリーム

32

https://kubernetes.io/docs/setup/version-skew-policy/#kube-apiserver



Kubernetes によってサポートされなくなった場合でも当てはまります。Amazon EKSでサポートされている Kubernetes のバージョンに適用可能なセキュリティ修正はバックポートされています。既存のクラスターはサポートされている状態に常に保たれます。サポート終了日までに手動で更新していない場合、サポートされているバージョンに Amazon EKS によって自動的に更新されます。

Important

Amazon EKS は可用性の高いコントロールプレーンを実行しているため、一度に更新できるマイナーバージョンは 1 つのみです。この背後にある論理的根拠については、「Kubernetes Version and Version Skew Support Policy (Kubernetes のバージョンおよびバージョンスキューのサポートポリシー)」を参照してください。したがって、現在のバージョンが 1.14 で、1.16 にアップグレードする場合は、最初にクラスターを1.15 にアップグレードし、その後 1.15 から 1.16 にアップグレードする必要があります。1.14 から 1.16 に直接アップデートしようとすると、バージョン更新コマンドからエラーがスローされます。

aws eks --region region-code update-cluster-version --name prod --kubernetes-version 1.16

出力:

{ "update": { "id": "b5f0ba18-9a87-4450-b5a0-825e6e84496f", "status": "InProgress", "type": "VersionUpdate", "params": [ { "type": "Version", "value": "1.16" }, { "type": "PlatformVersion", "value": "eks.1" } ], "createdAt": 1577485455.5, "errors": [] }}

2. 次のコマンドでクラスター更新のステータスをモニタリングします。その際、以前のコマンドで返されたクラスター名と更新 ID を使用します。ステータスが Successful となったら、更新は完了です。

Note

クラスターの更新は、数分で終了します。

aws eks --region region-code describe-update --name prod --update-id b5f0ba18-9a87-4450-b5a0-825e6e84496f

出力:

{ "update": { "id": "b5f0ba18-9a87-4450-b5a0-825e6e84496f", "status": "Successful", "type": "VersionUpdate",

33




"params": [ { "type": "Version", "value": "1.16" }, { "type": "PlatformVersion", "value": "eks.1" } ], "createdAt": 1577485455.5, "errors": [] }}

4. クラスターのリージョンと現在の Kubernetes バージョン (この例では 1.16.8) に対応するイメージを使用するには、kube-proxy デーモンセットにパッチを適用します。


1.16 1.15 1.14 1.13 1.12

KubeProxy 1.16.8 1.15.11 1.14.9 1.13.12 1.12.10

kubectl set image daemonset.apps/kube-proxy \ -n kube-system \ kube-proxy=602401143452.dkr.ecr.us-west-2.amazonaws.com/eks/kube-proxy:v1.16.8

5. クラスターの DNS プロバイダーを確認します。Kubernetes バージョン 1.10 で作成されたクラスターは、デフォルトの DNS およびサービス検出プロバイダーとして kube-dns に付属していました。1.10 クラスターをそれ以降のバージョンに更新し、DNS とサービス検出に CoreDNS を使用する場合は、CoreDNS をインストールして、kube-dns を削除する必要があります。

クラスターですでに CoreDNS が実行されているかどうかを確認するには、次のコマンドを使用します。

kubectl get pod -n kube-system -l k8s-app=kube-dns

出力のポッド名に coredns と示されている場合、CoreDNS はすでにクラスターで実行されています。そうでない場合は、「CoreDNS のインストールまたはアップグレード (p. 182)」を参照してクラスターに CoreDNS をインストールし、推奨バージョンに更新します。次に、ここに戻ってステップ 6～8 をスキップします。

6. クラスターの coredns デプロイの現在のバージョンを確認します。

kubectl describe deployment coredns --namespace kube-system | grep Image | cut -d "/" -f 3

出力:

coredns:v1.1.3

対応する Kubernetes バージョンに対して推奨される coredns のバージョンは以下のとおりです。

34



1.16 1.15 1.14 1.13 1.12

CoreDNS 1.6.6 1.6.6 1.6.6 1.6.6 1.6.6

7. coredns の現在のバージョンが 1.5.0 以降かつ推奨バージョンより前の場合、このステップをスキップしてください。現在のバージョンが 1.5.0 より前の場合、proxy プラグインではなく forward プラグインを使用するように coredns の設定マップを変更する必要があります。

a. 次のコマンドを使用して設定マップを開きます。

kubectl edit configmap coredns -n kube-system

b. 次の行の proxy を forward に置き換えます。ファイルを保存し、エディタを終了します。

proxy . /etc/resolv.conf

8. coredns を推奨バージョンに更新して、region-code をお客様のリージョンに、1.6.6 をお客様のクラスターの coredns の推奨バージョンに置き換えます。

kubectl set image --namespace kube-system deployment.apps/coredns \ coredns=602401143452.dkr.ecr.us-west-2.amazonaws.com/eks/coredns:v1.6.6

9. クラスターの Amazon VPC CNI Plugin for Kubernetes のバージョンを確認します。次のコマンドを使用して、クラスターの CNI バージョンを出力します。

kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2

出力:

amazon-k8s-cni:1.5.7

CNI バージョンが 1.6.1 より前のバージョンである場合は、以下のコマンドを使用して、CNI バージョンを最新の推奨バージョンに更新します。

kubectl apply -f https://raw.githubusercontent.com/aws/amazon-vpc-cni-k8s/release-1.6/config/v1.6/aws-k8s-cni.yaml

10. (オプション) クラスターをアップグレードする前にクラスターに Kubernetes Cluster Autoscaler をデプロイ済みである場合は、アップグレードした Kubernetes メジャーバージョンとマイナーバージョンに一致する最新バージョンに Cluster Autoscaler を更新します。

a. ウェブブラウザで Cluster Autoscaler リリースページを開き、クラスターの Kubernetes メジャーバージョンとマイナーバージョンに一致する最新の Cluster Autoscaler バージョンを見つけます。たとえば、クラスターの Kubernetes バージョンが 1.16 である場合、1.16 で始まる最新のCluster Autoscaler リリースを見つけます。次のステップで使用するために、そのリリースのセマンティックバージョン番号 (1.16.n) を書き留めます。

b. 次のコマンドを使用して、Cluster Autoscaler イメージタグを、前のステップで書き留めたバージョンに設定します。1.16.n は、独自の値に置き換えます。us は、asia または eu に置き換えることができます。

kubectl -n kube-system set image deployment.apps/cluster-autoscaler cluster-autoscaler=us.gcr.io/k8s-artifacts-prod/autoscaling/cluster-autoscaler:v1.16.n

35

https://github.com/kubernetes/autoscaler/releases

Amazon EKS ユーザーガイドKubernetes 1.16 にアップグレードにするための前提条件

Note

必要とするバージョンによっては、以前のアドレスを gcr.io/google-containers/cluster-autoscaler:v1.n.n に変更する必要があります。イメージアドレスは、リリースページに一覧表示されています。

11. (GPU ワーカーを含むクラスターのみ) クラスターに GPU 対応のワーカーノードグループ(p3.2xlarge など) がある場合は、以下のコマンドを使用してクラスターの NVIDIA device plugin forKubernetes デーモンセットを更新する必要があります。


12. クラスターの更新が完了したら、同じ Kubernetes バージョンの更新したクラスターにワーカーノードを更新する必要があります。詳細については、「セルフマネージド型ワーカーノードの更新 (p. 105)」を参照してください。Fargate で起動される新しいポッドには、クラスターのバージョンと一致する kubelet バージョンがあります。既存の Fargate ポッドは変更されません。

Kubernetes 1.16 にアップグレードにするための前提条件「Kubernetes 1.15 の変更ログ」と「Deprecated APIs Removed In 1.16: Here’s What You Need ToKnow」に記述されているように、既存のクラスターがある場合、クラスターを 1.16 にアップグレードする前に、以下のデプロイ済みリソースで API を変更する必要があります。

Warning

1.16 にアップグレードする前にこれらの API を変更しないと、アップグレードの完了後にワークロードが失敗します。

• v1.16 では、NetworkPolicy リソースが extensions/v1beta1 から提供されなくなります。v1.8以降で利用可能な networking.k8s.io/v1 API に移行してください。既存の永続化データは、networking.k8s.io/v1 API を介して取得できます。

• v1.16 では、PodSecurityPolicy リソースが extensions/v1beta1 から提供されなくなります。v1.10以降で利用可能な policy/v1beta1 API に移行してください。既存の永続化データは、policy/v1beta1 API を介して取得できます。

• v1.16 では、DaemonSet、Deployment、StatefulSet、および ReplicaSet の各リソースが extensions/v1beta1、apps/v1beta1、または apps/v1beta2 から提供されなくなります。v1.9 以降で利用可能な apps/v1 APIに移行してください。既存の永続化データは、apps/v1 API を介して取得できます。たとえば、apps/v1beta1 を現在使用している Deployment を変換するには、次のコマンドを入力します。

kubectl convert -f ./my-deployment.yaml --output-version apps/v1

Note

上のコマンドで使用しているデフォルト値は、現在のマニフェストファイルに設定されているデフォルト値とは異なる場合があります。特定のリソースの詳細については、Kubernetes APIリファレンスを参照してください。

1.16 にアップグレードする前に行う必要があること

• 新しい API を参照するように YAML ファイルを変更します。• 新しい API を呼び出すようにカスタムインテグレーションとコントローラーを更新します。

36





https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.15.md#deprecations-and-removals

https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/

https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/

https://kubernetes.io/docs/reference/#api-reference

https://kubernetes.io/docs/reference/#api-reference

Amazon EKS ユーザーガイドクラスターエンドポイントのアクセス

• 新しい API を呼び出すためのサードパーティー製ツール (イングレスコントローラー、継続的配信システムなど) の最新バージョンを使用していることを確認します。

クラスターで非推奨の API が使用されているかどうかを簡単に確認するには、audit コントロールプレーンログ (p. 42)が有効になっていることを確認し、イベントのフィルターとして v1beta を指定します。すべての代替 API は、Kubernetes バージョン 1.10 より後のバージョンにあります。すべてのサポートされているバージョンの Amazon EKS に搭載されているアプリケーションで、更新済み API を使用できます。

Amazon EKS クラスターエンドポイントのアクセスコントロール

このトピックは、Amazon EKS クラスターの Kubernetes API サーバーエンドポイントおよび制限のプライベートアクセスを有効にしたり、インターネットからのパブリックアクセスを完全に無効にしたりする際に役立ちます。

新しいクラスターを作成すると、Amazon EKS によってマネージド型の Kubernetes API サーバーのエンドポイントが作成されます。これは、クラスターとの通信に使用します (kubectl などの Kubernetes 管理ツールを使用)。デフォルトでは、この API サーバーエンドポイントはインターネットに公開され、APIサーバーへのアクセスは AWS Identity and Access Management (IAM) とネイティブの Kubernetes ロールベースアクセスコントロール (RBAC) の組み合わせを使用して保護されます。

Kubernetes API サーバーへのプライベートアクセスを有効にすると、ワーカーノードと API サーバー間のすべての通信が VPC 内に留まります。インターネットから API サーバーにアクセスできる IP アドレスを制限するか、API サーバーへのインターネットアクセスを完全に無効にできます。

Note

このエンドポイントは Kubernetes API サーバー用であり、AWS API と通信するための従来のAWS PrivateLink エンドポイントではないため、Amazon VPC コンソールではエンドポイントとして表示されません。

クラスターのエンドポイントのプライベートアクセスを有効にすると、Amazon EKS によって自動的にRoute 53 プライベートホストゾーンが作成され、それがクラスターの VPC に関連付けられます。このプライベートホストゾーンは Amazon EKS によって管理され、アカウントの Route 53 リソースには表示されません。プライベートホストゾーンが API サーバーに正しくトラフィックをルーティングするためには、VPC で enableDnsHostnames と enableDnsSupport が true に設定され、VPC 用に設定されたDHCP オプションで、ドメイン名サーバーリストに AmazonProvidedDNS が含まれている必要があります。詳細については、『Amazon VPC ユーザーガイド』の「VPC の DNS サポートを更新する」を参照してください。

Note

標準の Amazon EKS アクセス許可に加えて、IAM ユーザーまたはロールには、クラスターのエンドポイントのプライベートアクセスを有効にするためのroute53:AssociateVPCWithHostedZone アクセス許可が必要です。

API サーバーエンドポイントのアクセス要件は、新しいクラスターを作成するときに定義できます。また、クラスターの API サーバーエンドポイントのアクセスは、随時更新できます。

クラスターエンドポイントのアクセスの変更既存クラスターのエンドポイントのアクセスを変更するには、このセクションの手順に従ってください。次の表は、サポートされている API サーバーエンドポイントのアクセスの組み合わせとそれらに関連付けられている動作を示しています。

37

https://kubernetes.io/docs/admin/authorization/rbac/


https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-dns.html#vpc-dns-updating

Amazon EKS ユーザーガイドクラスターエンドポイントのアクセスの変更

API サーバーエンドポイントのアクセスオプション

エンドポイントのパブリックアクセス

エンドポイントのプライベートアクセス

動作

有効無効 • これは、新しい Amazon EKSクラスターのデフォルトの動作です。

• クラスターの VPC 内 (コントロールプレーン通信のワーカーノードなど) から送信される Kubernetes API リクエストは、VPC からは離れますが、Amazon のネットワークからは離れません。

• クラスター API サーバーにはインターネットからアクセスできます。必要に応じて、パブリックエンドポイントにアクセスできる CIDR ブロックを制限できます。特定の CIDRブロックへのアクセスを制限する場合は、プライベートエンドポイントも有効にするか、指定した CIDR ブロックに、ワーカーノードと Fargateポッド（使用する場合）がパブリックエンドポイントにアクセスするアドレスを含めることをお勧めします。

有効有効 • クラスターの VPC 内のKubernetes API リクエスト (プレーン通信をコントロールするワーカーノードなど) は、プライベート VPC エンドポイントを使用します。

• クラスター API サーバーにはインターネットからアクセスできます。必要に応じて、パブリックエンドポイントにアクセスできる CIDR ブロックを制限できます。

無効有効 • クラスター API サーバーへのすべてのトラフィックは、クラスターの VPC または接続されたネットワーク内から送信する必要があります。

• インターネットから API サーバーへのパブリックアクセスは存在しません。kubectlコマンドはすべて、VPC または接続されたネットワーク内から実行する必要があります。接続オプションについては、プライベート専

38

https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html



エンドポイントのパブリックアクセス

エンドポイントのプライベートアクセス

動作

用 API サーバーへのアクセス (p. 41)を参照してください。

• クラスターの API サーバーエンドポイントは、パブリックDNS サーバーによって VPCのプライベート IP アドレスに解決されます。これまでは、エンドポイントは VPC 内からしか解決できませんでした。

エンドポイントが既存のクラスターの VPC 内のプライベート IP アドレスに解決されない場合は、次の操作を実行できます。• パブリックアクセスを有効

にし、再度無効にします。この操作は、クラスターに対して 1 回行うだけで済みます。それ以降、エンドポイントはプライベート IP アドレスに解決されます。

• クラスターを更新 (p. 29)します。

AWS マネジメントコンソールまたは AWS CLI を使用して、クラスター API サーバーのエンドポイントアクセスを変更できます。手順については、使用するツールのタブを選択して参照してください。


1. Open the Amazon EKS console at https://console.aws.amazon.com/eks/home#/clusters.2. クラスターの名前を選択すると、そのクラスターの情報を表示されます。3. [ネットワーキング] の [更新] を選択します。4. [プライベートアクセス] の場合は、クラスターの Kubernetes API サーバーエンドポイントに対す

るプライベートアクセスを有効にするか無効にするかを選択します。プライベートアクセスを有効にした場合、クラスターの VPC 内から送信される Kubernetes API リクエストは、プライベート VPC エンドポイントを使用します。パブリックアクセスを無効にするには、プライベートアクセスを有効にする必要があります。

5. [パブリックアクセス] の場合は、クラスターの Kubernetes API サーバーエンドポイントに対するパブリックアクセスを有効にするか無効にするかを選択します。パブリックアクセスを無効にすると、クラスターの Kubernetes API サーバーはクラスター VPC 内からのみリクエストを受信できます。

6. (オプション) パブリックアクセスを有効にすると、インターネットからパブリックエンドポイントと通信できるアドレスを指定できます。[詳細設定] を選択します。「203.0.113.5/32」などの CIDR ブロックを入力します。ブロックに予約済みアドレスを含めることはできません。[ソースの追加] を選択すると、追加のブロックを入力できます。指定できる CIDR ブロックには最大数があります。詳細については、「Amazon EKS のサービスクォータ (p. 305)」を参照してください。ブロックを指定しない場合、パブリック API サーバーエンドポイントはすべての(0.0.0.0/0) IP アドレスからリクエストを受信します。CIDR ブロックを使用してパブリックエンドポイントへのアクセスを制限する場合は、ワーカーノードと Fargate ポッド (使用する場合) がクラスターと通信できるように、プライベートエンドポイントアクセスも有効にすることをお勧

39


https://en.wikipedia.org/wiki/Reserved_IP_addresses


めします。プライベートエンドポイントが有効になっていない場合は、パブリックアクセスエンドポイントの CIDR ソースに、VPC からの出力ソースを含める必要があります。たとえば、プライベートサブネットに NAT ゲートウェイを介してインターネットと通信するワーカーノードがある場合、パブリックエンドポイントのホワイトリストに登録された CIDR ブロックの一部として、NAT ゲートウェイのアウトバウンド IP アドレスを追加する必要があります。

7. [更新] を選択して終了します。

AWS CLI

AWS CLI バージョン 1.18.49 以降を使用して、次のステップを実行します。現在のバージョンは、aws --version で確認できます。AWS CLI をインストールまたはアップグレードするには、「AWS CLI のインストール」を参照してください。

1. 次の AWS CLI コマンドを使用してクラスター API サーバーエンドポイントのアクセスを更新します。クラスター名と必要なエンドポイントアクセス値を置き換えます。endpointPublicAccess=true を設定した場合は、(オプションで) 1 つの CIDR ブロック、または publicAccessCidrs の CIDR ブロックのカンマ区切りリストを入力できます。ブロックに予約済みアドレスを含めることはできません。CIDR ブロックを指定すると、パブリック API サーバーエンドポイントはリストされたブロックからのリクエストのみを受信します。指定できる CIDR ブロックには最大数があります。詳細については、「Amazon EKS のサービスクォータ (p. 305)」を参照してください。CIDR ブロックを使用してパブリックエンドポイントへのアクセスを制限する場合は、ワーカーノードと Fargate ポッド (使用する場合) がクラスターと通信できるように、プライベートエンドポイントアクセスも有効にすることをお勧めします。プライベートエンドポイントが有効になっていない場合は、パブリックアクセスエンドポイントの CIDR ソースに、VPC からの出力ソースを含める必要があります。たとえば、プライベートサブネットに NAT ゲートウェイを介してインターネットと通信するワーカーノードがある場合、パブリックエンドポイントのホワイトリストに登録された CIDR ブロックの一部として、NAT ゲートウェイのアウトバウンド IP アドレスを追加する必要があります。CIDR ブロックを指定しない場合、パブリック API サーバーエンドポイントはすべての (0.0.0.0/0) IP アドレスからリクエストを受信します。

Note

次のコマンドは、API サーバーエンドポイントの 1 つの IP アドレスからのプライベートアクセスとパブリックアクセスを有効にします。203.0.113.5/32 は、単一の CIDR ブロック、またはネットワークアクセスを制限する CIDR ブロックのカンマ区切りリストに置き換えます。

aws eks update-cluster-config \ --region region-code \ --name dev \ --resources-vpc-config endpointPublicAccess=true,publicAccessCidrs="203.0.113.5/32",endpointPrivateAccess=true

出力:

{ "update": { "id": "e6f0905f-a5d4-4a2a-8c49-EXAMPLE00000", "status": "InProgress", "type": "EndpointAccessUpdate", "params": [ { "type": "EndpointPublicAccess", "value": "true" }, { "type": "EndpointPrivateAccess",

40

https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html

https://en.wikipedia.org/wiki/Reserved_IP_addresses

Amazon EKS ユーザーガイドプライベート専用 API サーバーへのアクセス

"value": "true" }, { "type": "publicAccessCidrs", "value": "[\203.0.113.5/32\"]" } ], "createdAt": 1576874258.137, "errors": [] }}

2. 次のコマンドでエンドポイントアクセス更新のステータスをモニタリングします。この際、以前のコマンドで返ったクラスター名と更新 ID を使用します。ステータスが Successful となったら、更新は完了です。

aws eks describe-update \ --region region-code \ --name dev \ --update-id e6f0905f-a5d4-4a2a-8c49-EXAMPLE00000

出力:

{ "update": { "id": "e6f0905f-a5d4-4a2a-8c49-EXAMPLE00000", "status": "Successful", "type": "EndpointAccessUpdate", "params": [ { "type": "EndpointPublicAccess", "value": "true" }, { "type": "EndpointPrivateAccess", "value": "true" }, { "type": "publicAccessCidrs", "value": "[\203.0.113.5/32\"]" } ], "createdAt": 1576874258.137, "errors": [] }}

プライベート専用 API サーバーへのアクセスクラスターの Kubernetes API サーバーエンドポイントに対するパブリックアクセスを無効にした場合は、VPC または接続されたネットワーク内からのみ API サーバーにアクセスできます。Kubernetes APIサーバーエンドポイントにアクセスする方法はいくつかあります。

• 接続されたネットワーク – AWS トランジットゲートウェイまたはその他の接続オプションを使用してネットワークを VPC に接続し、接続されたネットワークのコンピュータを使用します。Amazon EKSコントロールプレーンセキュリティグループに、踏み台ホストからポート 443 のイングレストラフィックを許可するためのルールが含まれていることを確認する必要があります。

• Amazon EC2 踏み台ホスト – Amazon EC2 インスタンスをクラスターの VPC のパブリックサブネットで起動し、SSH 経由でそのインスタンスにログインして kubectl コマンドを実行できます。詳細に

41


https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html

https://docs.aws.amazon.com/aws-technical-content/latest/aws-vpc-connectivity-options/introduction.html

Amazon EKS ユーザーガイドコントロールプレーンのログ記録

ついては、AWS での Linux 踏み台ホストを参照してください。Amazon EKS コントロールプレーンセキュリティグループに、踏み台ホストからポート 443 のイングレストラフィックを許可するためのルールが含まれていることを確認する必要があります。詳細については、「Amazon EKS セキュリティグループの考慮事項 (p. 164)」を参照してください。

踏み台ホスト用に kubectl を設定するときには、クラスターの RBAC 設定にすでにマップされている AWS 認証情報を使用するか、踏み台ホストが使用する IAM ユーザーまたはロールを RBAC 設定に追加してから、エンドポイントのパブリックアクセスを削除します。詳細については、「クラスターのユーザーまたは IAM ロールの管理 (p. 202)」および「許可されていないか、アクセスが拒否されました (kubectl) (p. 299)」を参照してください。

• AWS Cloud9 IDE – AWS Cloud9 は、ブラウザだけでコードを記述、実行、およびデバッグできるクラウドベースの統合開発環境 (IDE) です。クラスターの VPC に AWS Cloud9 IDE を作成し、その IDE を使用してクラスターと通信できます。詳細については、AWS Cloud9 で環境を作成するを参照してください。Amazon EKS コントロールプレーンセキュリティグループに、IDE セキュリティグループからポート 443 のイングレストラフィックを許可するためのルールが含まれていることを確認する必要があります。詳細については、「Amazon EKS セキュリティグループの考慮事項 (p. 164)」を参照してください。

AWS Cloud9 IDE 用に kubectl を設定するときには、クラスターの RBAC 設定にすでにマップされている AWS 認証情報を使用するか、IDE が使用する IAM ユーザーまたはロールを RBAC 設定に追加してから、エンドポイントのパブリックアクセスを削除します。詳細については、「クラスターのユーザーまたは IAM ロールの管理 (p. 202)」および「許可されていないか、アクセスが拒否されました(kubectl) (p. 299)」を参照してください。

Amazon EKS コントロールプレーンのログ記録Amazon EKS コントロールプレーンのログ記録は、Amazon EKS コントロールプレーンからアカウントのCloudWatch Logs に直接監査および診断ログを提供します。これらのログを使用すると、クラスターの保護と実行が容易になります。CloudWatch の Amazon EKS クラスターごとに、必要なログタイプを選択することができ、ログがログストリームとしてグループに送信されます。

Amazon EKS コントロールプレーンのログ記録の使用を開始するには、新規または既存の Amazon EKSクラスターごとに有効にするログタイプを選択します。クラスターごとに各ログタイプを有効または無効にするには、AWS マネジメントコンソール、AWS CLI (バージョン 1.16.139 以降)、または Amazon EKSAPI を使用します。有効にすると、ログは Amazon EKS クラスターから同じアカウントの CloudWatchLogs に自動的に送信されます。

Amazon EKS コントロールプレーンのログ記録を使用すると、実行するクラスターごとに AmazonEKS の標準料金が発生します。クラスターから CloudWatch Logs に送信されるすべてのログに対して、CloudWatch Logs データの取り込みおよび保存の標準費用が発生します。また、Amazon EC2 インスタンスや Amazon EBS ボリュームなど、クラスターの一部としてプロビジョニングする AWS リソースに対しても料金が発生します。

以下のクラスターコントロールプレーンのログタイプが使用可能です。各ログタイプは、Kubernetesコントロールプレーンのコンポーネントに対応しています。これらのコンポーネントの詳細については、Kubernetes ドキュメントの Kubernetes Components (Kubernetes コンポーネント) を参照してください。

• Kubernetes API サーバーコンポーネントログ (api) – クラスターの API サーバーは、Kubernetes APIを公開するコントロールプレーンコンポーネントです。詳細については、Kubernetes ドキュメントのkube-apiserver を参照してください。

• 監査 (audit) – Kubernetes 監査ログは、クラスターに影響を与えた個々のユーザー、管理者、またはシステムコンポーネントの記録を提供します。詳細については、Kubernetes ドキュメントの Auditing (監査) を参照してください。

• 認証 (authenticator) – 認証ログは Amazon EKS に対して固有です。これらのログは、Amazon EKSが IAM 認証情報を使用して Kubernetes ロールベースアクセスコントロール (RBAC) 認証に使用するコ

42

https://aws.amazon.com/quickstart/architecture/linux-bastion/

https://docs.aws.amazon.com/cloud9/latest/user-guide/create-environment.html

https://kubernetes.io/docs/concepts/overview/components/

https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/

https://kubernetes.io/docs/tasks/debug-application-cluster/audit/

https://kubernetes.io/docs/tasks/debug-application-cluster/audit/


Amazon EKS ユーザーガイドコントロールプレーンログの有効化と無効化

ントロールプレーンコンポーネントを表します。詳細については、「クラスター認証の管理 (p. 190)」を参照してください。

• コントローラーマネージャー (controllerManager) – コントローラーマネージャーが、Kubernetes に同梱されているコアコントロールループを管理します。詳細については、Kubernetes ドキュメントのkube-controller-manager を参照してください。

• スケジューラ (scheduler) – スケジューラコンポーネントは、クラスターでポッドを実行するタイミングと場所を管理します。詳細については、Kubernetes ドキュメントの kube-scheduler を参照してください。

コントロールプレーンログの有効化と無効化デフォルトでは、クラスターのコントロールプレーンログは CloudWatch Logs に送信されません。クラスターのログを送信するには、各ログタイプを個別に有効にする必要があります。CloudWatch Logs の取り込み、アーカイブストレージ、およびデータスキャンレートが、有効なコントロールプレーンログに適用されます。詳細については、「CloudWatch の料金」を参照してください。

ログタイプを有効にすると、ログの詳細レベル 2 でログが送信されます。

コンソールを使用してコントロールプレーンログを有効または無効にするには

1. Open the Amazon EKS console at https://console.aws.amazon.com/eks/home#/clusters.2. クラスターの名前を選択すると、そのクラスターの情報を表示されます。3. [ログ記録] の [更新] を選択します。4. ログタイプごとに、そのログタイプを [有効] にするか [無効] にするかを選択します。各ログタイプ

は、デフォルトで [無効] になっています。5. [更新] を選択して終了します。

AWS CLI を使用してコントロールプレーンログを有効または無効にするには

1. 以下のコマンドを使用して、AWS CLI のバージョンを確認します。

aws --version

AWS CLI のバージョンが 1.16.139 以前である場合は、まず最新バージョンに更新する必要があります。AWS CLI をインストールまたはアップグレードするには、『AWS Command Line Interface ユーザーガイド』の「AWS コマンドラインインターフェイスのインストール」を参照してください。

2. 次の AWS CLI コマンドを使用して、クラスターのコントロールプレーンログのエクスポート設定を更新します。クラスター名と必要なエンドポイントアクセス値を置き換えます。

Note

次のコマンドは、使用可能なすべてのログタイプを CloudWatch Logs に送信します。

aws eks --region region-code update-cluster-config --name prod \--logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}'

出力:

{ "update": { "id": "883405c8-65c6-4758-8cee-2a7c1340a6d9",

43

https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/

https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/

http://aws.amazon.com/cloudwatch/pricing/



Amazon EKS ユーザーガイドクラスターのコントロールプレーンログの表示

"status": "InProgress", "type": "LoggingUpdate", "params": [ { "type": "ClusterLogging", "value": "{\"clusterLogging\":[{\"types\":[\"api\",\"audit\",\"authenticator\",\"controllerManager\",\"scheduler\"],\"enabled\":true}]}" } ], "createdAt": 1553271814.684, "errors": [] }}

3. 次のコマンドでログ設定更新のステータスをモニタリングします。その際、以前のコマンドで返されたクラスター名と更新 ID を使用します。ステータスが Successful となったら、更新は完了です。

aws eks --region region-code describe-update --name prod --update-id 883405c8-65c6-4758-8cee-2a7c1340a6d9

出力:

{ "update": { "id": "883405c8-65c6-4758-8cee-2a7c1340a6d9", "status": "Successful", "type": "LoggingUpdate", "params": [ { "type": "ClusterLogging", "value": "{\"clusterLogging\":[{\"types\":[\"api\",\"audit\",\"authenticator\",\"controllerManager\",\"scheduler\"],\"enabled\":true}]}" } ], "createdAt": 1553271814.684, "errors": [] }}

クラスターのコントロールプレーンログの表示Amazon EKS クラスターのいずれかのコントロールプレーンログタイプを有効にしたら、それらをCloudWatch コンソールで表示できます。

CloudWatch でログを表示、分析、および管理する方法の詳細については、Amazon CloudWatch LogsUser Guideを参照してください。

CloudWatch コンソールでクラスターのコントロールプレーンログを表示するには

1. CloudWatch コンソール (https://console.aws.amazon.com/cloudwatch/home#logs:prefix=/aws/eks) を開きます。この URL では、現在使用可能なロググループが表示され、プレフィックス /aws/eks でフィルタリングされます。

2. ログを表示するクラスターを選択します。ロググループの名前の形式は /aws/eks/cluster-name/cluster です。

3. 表示するログストリームを選択します。次のリストで、各ログタイプのログストリーム名の形式について説明します。

44

https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/

https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/

https://console.aws.amazon.com/cloudwatch/home#logs:prefix=/aws/eks

Amazon EKS ユーザーガイドクラスターの削除

Note

ログストリームデータが大きくなるにつれて、ログストリーム名のローテーションが行われます。特定のログタイプのログストリームが複数存在する場合、最新のログストリームを表示するには、[最終のイベント時刻] が最新のログストリーム名を見つけ出します。

• Kubernetes API サーバーコンポーネントログ (api) – kube-apiserver-nnn...• 監査 (audit) – kube-apiserver-audit-nnn...• 認証システム (authenticator) – authenticator-nnn...• コントローラーマネージャー (controllerManager) – kube-controller-manager-nnn...• スケジューラー (scheduler) – kube-scheduler-nnn...

クラスターの削除Amazon EKS クラスターの使用が終了したら、関連付けられたリソースを削除して、不要なコストが発生しないようにする必要があります。

Important

クラスター内にロードバランサーに関連付けられているアクティブなサービスがある場合は、クラスターを削除する前にこれらのサービスを削除して、ロードバランサーが正しく削除されるようにする必要があります。この操作を行わないと、VPC 内のリソースが孤立し、VPC を削除できなくなる可能性があります。

以下から優先するクラスター削除方法に対応するタブを選択します。

eksctl

eksctl を使用してワーカーノードが関連付けられた Amazon EKS クラスターを削除するには


eksctl version


Note


1. クラスターで実行されているすべてのサービスを一覧表示します。

kubectl get svc --all-namespaces

2. 関連付けられた EXTERNAL-IP 値のあるサービスすべてを削除します。これらのサービスの前面には、Elastic Load Balancing ロードバランサーがあるため、Kubernetes でそれらを削除して、ロードバランサーおよび関連するリソースが適切に解放されるようにする必要があります。

kubectl delete svc service-name

3. 以下のコマンドを使用して、クラスターとその関連するワーカーノードを削除します。prod は実際のクラスター名に置き換えてください。

45

Amazon EKS ユーザーガイドクラスターの削除

eksctl delete cluster --name prod

出力:

[✓] using region region-code[✓] deleting EKS cluster "prod"[✓] will delete stack "eksctl-prod-nodegroup-standard-workers"[✓] waiting for stack "eksctl-prod-nodegroup-standard-workers" to get deleted[✓] will delete stack "eksctl-prod-cluster"[✓] the following EKS cluster resource(s) for "prod" will be deleted: cluster. If in doubt, check CloudFormation console


AWS マネジメントコンソールを使用して Amazon EKS クラスターを削除するには





3. ワーカーノード AWS CloudFormation スタックを削除します。

a. AWS CloudFormation コンソール (https://console.aws.amazon.com/cloudformation) を開きます。

b. 削除するワーカーノードスタックを選択して、[アクション]、[スタックの削除] を選択します。

c. [Delete Stack (スタックの削除)] 確認画面で、[Yes, Delete (はい、削除します)] を選択します。

4. クラスターを削除します。

a. Open the Amazon EKS console at https://console.aws.amazon.com/eks/home#/clusters.b. 削除するクラスターを選択し、[Delete (削除)] を選択します。c. クラスターの削除確認画面で、[Delete (削除)] を選択します。

5. (オプション) VPC AWS CloudFormation スタックを削除します。

a. 削除する VPC スタックを選択し、[アクション]、[スタックの削除] を順に選択します。b. [Delete Stack (スタックの削除)] 確認画面で、[Yes, Delete (はい、削除します)] を選択しま

す。

AWS CLI

AWS CLI を使用して Amazon EKS クラスターを削除するには



46



Amazon EKS ユーザーガイドKubernetes バージョン



3. ワーカーノード AWS CloudFormation スタックを削除します。

a. 以下のコマンドで、使用可能な AWS CloudFormation スタックを一覧表示します。結果の出力でワーカーノードテンプレート名を見つけます。

aws cloudformation list-stacks --query "StackSummaries[].StackName"

b. 以下のコマンドを使用して、ワーカーノードスタックを削除します。worker-node-stackは実際のワーカーノードスタック名に置き換えてください。

aws cloudformation delete-stack --stack-name worker-node-stack

4. 以下のコマンドを使用して、クラスターを削除します。my-cluster は実際のクラスター名に置き換えてください。

aws eks delete-cluster --name my-cluster

5. (オプション) VPC AWS CloudFormation スタックを削除します。

a. 以下のコマンドで、使用可能な AWS CloudFormation スタックを一覧表示します。結果の出力で VPC テンプレート名を見つけます。

aws cloudformation list-stacks --query "StackSummaries[].StackName"

b. 以下のコマンドを使用して、VPC スタックを削除します。my-vpc-stack は実際の VPC スタック名に置き換えてください。

aws cloudformation delete-stack --stack-name my-vpc-stack

Amazon EKS Kubernetes バージョンKubernetes プロジェクトは、新機能、設計の更新、およびバグ修正とともに急速に進化しています。コミュニティでは、Kubernetes の新しいマイナーバージョン (例: 1. 16) をリリースしています。これは、およそ 3 か月ごとにリリースされており、各マイナーバージョンは、最初にリリースされてから約 9 か月間サポートされます。

利用可能な Amazon EKS Kubernetes バージョン現在、次の Kubernetes バージョンは、Amazon EKS の新しいクラスターで利用することができます。

• 1.16.8• 1.15.11• 1.14.9• 1.13.12• 1.12.10

47

Amazon EKS ユーザーガイドKubernetes 1.16

Important

Kubernetes バージョン 1.13 は Amazon EKS で廃止されました。2020 年 6 月 30日に、Kubernetes バージョン 1.13 は Amazon EKS でサポートされなくなりました。この日付以降、新しい 1.13 クラスターを作成することはできなくなりました。Kubernetes バージョン 1.13を実行しているすべての既存の Amazon EKS クラスターは最終的に、バージョン 1.14 に自動的に更新されます。サービスの中断を防ぐため、1.13 クラスターはバージョン 1.14 以降に更新することをお勧めします。詳細については、「Amazon EKS バージョンの廃止 (p. 51)」を参照してください。Kubernetes バージョン 1.12 は Amazon EKS で廃止されました。2020 年 5 月 11日に、Kubernetes バージョン 1.12 は Amazon EKS でサポートされなくなりました。この日付以降、新しい 1.12 クラスターを作成することはできなくなりました。Kubernetes バージョン 1.12を実行しているすべての既存の Amazon EKS クラスターは最終的に、バージョン 1.13 に自動的に更新されます。サービスの中断を防ぐため、1.12 クラスターはバージョン 1.13 以降に更新することをお勧めします。詳細については、「Amazon EKS バージョンの廃止 (p. 51)」を参照してください。Amazon EKS で利用可能な Kubernetes API のバージョンは、そのバージョンを使用してクラスターを作成する機能が削除されるまで、AWS によって公式にサポートされます。これは、Amazon EKS で利用可能なバージョンがアップストリーム Kubernetes によってサポートされなくなった場合でも当てはまります。Amazon EKS でサポートされている Kubernetes のバージョンに適用可能なセキュリティ修正はバックポートされています。既存のクラスターはサポートされている状態に常に保たれます。サポート終了日までに手動で更新していない場合、サポートされているバージョンに Amazon EKS によって自動的に更新されます。

特定のバージョンの Kubernetes がアプリケーションで必要である場合を除き、クラスター用に AmazonEKS によってサポートされる利用可能な最新の Kubernetes バージョンを選択することをお勧めします。新しい Kubernetes バージョンが Amazon EKS で利用可能になったら、利用可能な最新のバージョンが使用できるように、クラスターをタイムリーに更新することをお勧めします。詳細については、AmazonEKS クラスターの Kubernetes バージョンの更新 (p. 29) を参照してください。

Kubernetes 1.16Kubernetes 1.16 が Amazon EKS で利用可能になりました。Kubernetes 1.16 の詳細については、公式リリースのお知らせを参照してください。

Important

• Kubernetes 1.16 は、多くの非推奨の API を削除します。クラスターを 1.16 にアップグレードする前に、アプリケーションへの変更が必要になる場合があります。アップグレードする前に、1.16 へのアップグレードの前提条件 (p. 36)によく従ってください。

• 1.16 以降、Amazon EKS 認証局は SAN X.509 拡張による証明書署名リクエストに従います。そのため、EKS CA は GitHub からの SAN x509 拡張リクエストの要求を従う必要があります。

Kubernetes の以下の機能が Kubernetes 1.16 Amazon EKS クラスターでサポートされるようになりました。

• CSI 仕様のボリューム拡張がベータ版に移行されました。これにより、CSI 仕様のボリュームプラグインのサイズ変更が可能になりました。詳細については、Kubernetes CSI ドキュメントの「VolumeExpansion」を参照してください。最新バージョンの EBS CSI ドライバーは、Amazon EKS 1.16 クラスターで実行中のボリューム拡張をサポートします。

• Windows GMSA のサポートはアルファ版からベータ版へと段階的に移行し、Amazon EKS によってサポートされるようになりました。詳細については、Kubernetes ドキュメントの「Configure GMSA forWindows Pods and containers」を参照してください。

• 新しい注釈: service.beta.kubernetes.io/aws-load-balancer-eip-allocationsは、Elastic IP アドレスを Network Load Balancer に割り当てるためにサービスタイプ LoadBalancer

48

https://kubernetes.io/blog/2019/09/18/kubernetes-1-16-release-announcement/


https://github.com/aws/containers-roadmap/issues/750

https://kubernetes-csi.github.io/docs/volume-expansion.html

https://kubernetes-csi.github.io/docs/volume-expansion.html

https://github.com/kubernetes-sigs/aws-ebs-csi-driver/tree/master/examples/kubernetes/resizing

https://kubernetes.io/docs/tasks/configure-pod-container/configure-gmsa/



で利用可能です。詳細については、GitHub の問題「Support EIP Allocations with AWS NLB」を参照してください。

• サービスロードバランサーのファイナライザー保護がベータ版になり、デフォルトで有効になりました。サービスロードバランサーのファイナライザー保護により、AWS Network Load Balancer など、Kubernetes Service オブジェクトに割り当てられたロードバランサーリソースは、サービスの削除時に破棄または解放されます。詳細については、Kubernetes ドキュメントの「Garbage Collecting LoadBalancers」を参照してください。

• Kubernetes カスタムリソース定義とアドミッション Webhook 拡張メカニズムは、両方とも一般公開されています。詳細については、Kubernetes ドキュメントの「Custom Resources」と「DynamicAdmission Control」を参照してください。

• サーバー側の適用機能がベータステータスになり、デフォルトで有効になっています。詳細については、Kubernetes ドキュメントの「Server Side Apply」を参照してください。

• CustomResourceDefaulting 機能はベータ版に昇格され、デフォルトで有効になります。デフォルトは、apiextensions.k8s.io/v1 API を介して構造スキーマで指定することができます。詳細については、Kubernetes ドキュメントの「Specifying a structural schema」を参照してください。

完全な Kubernetes 1.16 変更ログについては、https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.16.md を参照してください。


Important

1.15 以降では、Amazon EKS により、クラスターが含まれている VPC にタグ付けされなくなりました。

• クラスターの VPC 内のサブネットは、引き続きタグ付けされます。• VPC タグは、既存のクラスターを 1.15 にアップグレードしても変更されません。

• VPC タグ付けの詳細については、「??? (p. 163)」を参照してください。

Important

Amazon EKS が Pod Identity Webhook の再呼び出しポリシーを IfNeeded に設定しました。これにより、App Mesh サイドカーインジェクターのような他の変更アドミッション Webhookによってオブジェクトが変更された場合、Webhook を再呼び出しできるようになります。AppMesh サイドカーインジェクターの詳細については、「サイドカーインジェクターのインストール」を参照してください。

以下の機能が Kubernetes 1.15 Amazon EKS クラスターでサポートされるようになりました。

• EKS では、Network Load Balancer の Transport Layer Security (TLS) 終了、アクセスログ、およびソース範囲の設定がサポートされるようになりました。詳細については、GitHub の「AWS での NetworkLoad Balancer のサポート」を参照してください。

• オンザフライでバージョンを変換する機能など、カスタムリソース定義 (CRD) の柔軟性が向上しました。詳細については、GitHub の「CustomResourceDefinitions を使用した Kubernetes API の拡張」を参照してください。

• NodeLocal DNSCache は、Kubernetes バージョン 1.15 クラスターのベータ版です。この機能は、DaemonSet としてクラスターノード上で DNS キャッシュエージェントを実行することにより、クラスター DNS のパフォーマンスを向上させることができます。詳細については、GitHub の「UsingNodeLocal DNSCache in Kubernetes clusters」を参照してください。

49

https://github.com/kubernetes/kubernetes/issues/63959

https://docs.aws.amazon.com/eks/latest/userguide/load-balancing.html

https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/#garbage-collecting-load-balancers

https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/#garbage-collecting-load-balancers

https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/

https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/

https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/

https://kubernetes.io/docs/reference/using-api/api-concepts/#server-side-apply

https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/#specifying-a-structural-schema

https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.16.md




https://docs.aws.amazon.com/eks/latest/userguide/mesh-k8s-integration.html#install-injector

https://docs.aws.amazon.com/eks/latest/userguide/mesh-k8s-integration.html#install-injector

https://kubernetes.io/docs/concepts/services-networking/service/#aws-nlb-support


https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions

https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/

https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/




Important

--allow-privileged フラグは、Amazon EKS 1.14 ワーカーノードの kubelet から削除されました。クラスターの Amazon EKS のデフォルトのポッドセキュリティポリシー (p. 280) を変更または制限した場合、アプリケーションに必要なアクセス許可が 1.14 ワーカーノードにあることを確認する必要があります。

以下の機能が Kubernetes 1.14 Amazon EKS クラスターでサポートされるようになりました。

• コンテナストレージインターフェイスのトポロジは、Kubernetes バージョン 1.14 クラスターのベータ版です。詳細については、Kubernetes CSI 開発者ドキュメントの「CSI トポロジ機能」を参照してください。以下の CSI ドライバーは、Amazon EBS ボリューム、Amazon EFS ファイルシステム、およびLustre ファイルシステムの Amazon FSx ライフサイクルを管理する Kubernetes などのコンテナオーケストレーター用の CSI インターフェイスを提供します。• Amazon Elastic Block Store(EBS) CSI ドライバー• Amazon EFS CSI ドライバー• Amazon FSx for Lustre CSI ドライバー

• プロセス ID(PID) 制限は、Kubernetes バージョン 1.14 クラスターのベータ版です。この機能により、ポッドが作成できるプロセスの数のクォータを設定できます。これにより、クラスター上の他のアプリケーションのリソース不足を防ぐことができます。詳細については、「Kubernetes 1.14 の安定性向上のためのプロセス ID の制限」を参照してください。

• 永続的ローカルボリュームは GA になり、ローカルにアタッチされたストレージを永続的ボリュームソースとして使用できるようになりました。詳細については、「Kubernetes 1.14: ローカル永続ボリューム GA」を参照してください。

• Pod Priority と Preemption が GA になり、ポッドにスケジューリング優先度レベルを割り当てることができるようになりました。詳細については、Kubernetes ドキュメントの「Pod Priority と Preemption」を参照してください。

• Kubernetes 1.14 では、Windows ワーカーノードのサポートは GA です。


Kubernetes 1.13以下の機能が Kubernetes 1.13 Amazon EKS クラスターでサポートされるようになりました。

• PodSecurityPolicy アドミッションコントローラーが有効になりました。このアドミッションコントローラーにより、ポッドの作成と更新をきめ細かく制御できます。詳細については、「ポッドのセキュリティポリシー (p. 280)」を参照してください。1.13 にアップグレードするときにクラスターで任意のポッドセキュリティポリシーが定義されていない場合は、Amazon EKS によってデフォルトのポリシーが作成されます。

Important

クラスターで任意のポッドセキュリティポリシーが定義されている場合は、Kubernetes 1.13 にアップグレードしても、デフォルトのポリシーは作成されません。クラスターにデフォルトのAmazon EKS ポッドセキュリティポリシーがない場合、既存のポッドセキュリティポリシーの

50





https://kubernetes-csi.github.io/docs/topology.html#csi-topology-feature

https://github.com/kubernetes-sigs/aws-ebs-csi-driver

https://github.com/kubernetes-sigs/aws-efs-csi-driver

https://github.com/kubernetes-sigs/aws-fsx-csi-driver

https://kubernetes.io/blog/2019/04/15/process-id-limiting-for-stability-improvements-in-kubernetes-1.14/

https://kubernetes.io/blog/2019/04/15/process-id-limiting-for-stability-improvements-in-kubernetes-1.14/

https://kubernetes.io/blog/2019/04/04/kubernetes-1.14-local-persistent-volumes-ga/

https://kubernetes.io/blog/2019/04/04/kubernetes-1.14-local-persistent-volumes-ga/

https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/



Amazon EKS ユーザーガイドAmazon EKS バージョンの廃止

制限が厳しすぎると、ポッドを起動できないことがあります。以下のコマンドを使用して、既存のポッドセキュリティポリシーがあるかどうかを確認できます。

kubectl get psp

クラスターで任意のポッドセキュリティポリシーが定義されている場合は、デフォルトのAmazon EKS ポッドセキュリティポリシー (eks.privileged) が定義されていることも確認する必要があります。定義されていない場合は、「デフォルトのポッドセキュリティポリシーをインストールまたは復元するには (p. 283)」の手順に従って適用できます。

• Amazon ECR インターフェイス VPC エンドポイント (AWS PrivateLink) がサポートされました。VPCでこれらのエンドポイントを有効にすると、VPC と Amazon ECR の間のすべてのネットワークが、Amazon ネットワークに制限されます。詳細については、『Amazon Elastic Container Registryユーザーガイド』の「Amazon ECR インターフェイス VPC エンドポイント (AWS PrivateLink)」を参照してください。

• DryRun 機能は、Kubernetes 1.13 でベータ版となっていて、Amazon EKS クラスターに対してデフォルトで有効になります。詳細については、Kubernetes ドキュメントの「Dry run」を参照してください。

• TaintBasedEvictions 機能は、Kubernetes 1.13 でベータ版となっていて、Amazon EKS クラスターに対してデフォルトで有効になります。詳細については、Kubernetes ドキュメントの「Taint basedEvictions」を参照してください。

• Raw ブロックボリュームのサポートは、Kubernetes 1.13 でベータ版となっていて、Amazon EKS クラスターに対してデフォルトで有効になります。これはポッド仕様の volumeDevices コンテナフィールド、および永続的なボリュームと、永続的ボリュームのクレーム定義の volumeMode フィールドからアクセス可能です。詳細については、Kubernetes ドキュメントの「Raw Block Volume Support」を参照してください。

• ノードリースの更新は、その NodeStatus の更新に加えて、ノードからのハートビート信号として扱われます。これにより、大規模なクラスターのコントロールプレーンの負荷が軽減されます。詳細については、https://github.com/kubernetes/kubernetes/pull/69241 を参照してください。


Amazon EKS バージョンの廃止Kubernetes コミュニティが Kubernetes バージョンをサポートしていることを踏まえて、Amazon EKS では常に、本番環境に対応する 3 つ以上のバージョンの Kubernetes を実行することをお約束します。4 番目のバージョンは推奨されません。

Kubernetes の特定のマイナーバージョンについては、サポート終了日の最低 60 日前に廃止を発表します。Kubernetes の新しいバージョンの Amazon EKS の認定およびリリースプロセスにより、AmazonEKS の Kubernetes バージョンは、Kubernetes プロジェクトがバージョンアップストリームのサポートを停止した日以降に廃止されます。

サポート終了日時点で、廃止予定のバージョンを実行している Amazon EKS クラスターは、Amazon EKSでサポートされている次のバージョンの Kubernetes に自動更新されます。たとえば、廃止予定のバージョンが 1.13 の場合、クラスターは結果として自動的に、バージョン 1.14 にアップデートされます。クラスターが Amazon EKS によって自動更新されている場合は、その更新が完了した後に、ワーカーノードのバージョンをアップデートする必要があります。詳細については、「セルフマネージド型ワーカーノードの更新 (p. 105)」を参照してください。

Kubernetes では、少なくとも 2 つのマイナーバージョンにおいて、マスターとワーカーの間の互換性をサポートしています。そのため、1.13 ワーカーは、1.14 コントロールプレーンで連携されている場合でも動作し続けます。詳細については、Kubernetes ドキュメントの「Kubernetes のバージョンおよびバージョンスキューのサポートポリシー」を参照してください。

51

https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html

https://kubernetes.io/docs/reference/using-api/api-concepts/#dry-run

https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/#taint-based-evictions

https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/#taint-based-evictions

https://kubernetes.io/docs/concepts/storage/persistent-volumes/#raw-block-volume-support

https://github.com/kubernetes/kubernetes/pull/69241



https://kubernetes.io/docs/setup/version-skew-policy/

https://kubernetes.io/docs/setup/version-skew-policy/

Amazon EKS ユーザーガイドプラットフォームのバージョン

プラットフォームのバージョンAmazon EKS プラットフォームのバージョンは、現在の Kubernetes パッチバージョンと、どのKubernetes API サーバーのフラグが有効かなどのクラスターコントロールプレーンの機能を表します。各Kubernetes マイナーバージョンには、Amazon EKS プラットフォームバージョンが 1 つ以上関連付けられています。別の Kubernetes マイナーバージョンのプラットフォームバージョンは独立しています。

新しい Kubernetes マイナーバージョンが Amazon EKS で使用可能になると (eks.1 など)、そのKubernetes マイナーバージョンの最初の 1.16 プラットフォームバージョンは Amazon EKS から始まります。ただし、Amazon EKS は、新しいプラットフォームバージョンを定期的にリリースして、新しいKubernetes コントロールプレーン設定を有効化し、セキュリティ修正プログラムを提供します。

新しい Amazon EKS プラットフォームのバージョンがマイナーバージョンで使用可能になった場合:

• Amazon EKS プラットフォームのバージョン番号がインクリメントされます (eks.n+1)。• Amazon EKS は、既存のすべてのクラスターを、対応する Kubernetes マイナーバージョン用の最新の

Amazon EKS プラットフォームバージョンに自動的にアップグレードします。• Amazon EKS は、対応するパッチバージョンを含む新しいワーカー AMI を発行する可能性があります。

ただし、すべてのパッチバージョンは、特定の Kubernetes マイナーバージョンの EKS コントロールプレーンとワーカー AMI との間に互換性があります。

新しい Amazon EKS プラットフォームバージョンでは、重大な変更が発生したり、サービスが中断されたりすることはありません。

Note

既存の Amazon EKS プラットフォームバージョンの自動アップグレードは段階的にロールアウトされます。ロールアウトプロセスには時間がかかる場合があります。最新の Amazon EKS プラットフォームバージョンの機能がすぐに必要な場合は、新しい Amazon EKS クラスターを作成する必要があります。

クラスターは常に、指定された Kubernetes バージョン用に入手可能な最新の Amazon EKS プラットフォームバージョン (eks.n) で作成されます。クラスターを新しい Kubernetes マイナーバージョンに更新した場合、クラスターは、更新した Kubernetes マイナーバージョンの現在の Amazon EKS プラットフォームバージョンを受け取ります。

現在および最新の Amazon EKS プラットフォームバージョンを以下の表に示します。

Kubernetes バージョン 1.16

Kubernetes バージョン Amazon EKS プラットフォームのバージョン

有効なアドミッションコントローラー

リリースノート

1.16.8 eks.1 NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,ResourceQuota,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook、PodSecurityPolicy、TaintNodesByCondition、Priority、StorageObjectInUseProtection、PersistentVolumeClaimResize

Amazon EKS のKubernetes 1.16 の初回リリース。詳細については、「Kubernetes1.16 (p. 48)」を参照してください。

52

Amazon EKS ユーザーガイドKubernetes バージョン 1.15

Kubernetes バージョン 1.15Kubernetes バージョン Amazon EKS プラット

フォームのバージョン有効なアドミッションコントローラー



サーバー側 AWS IAMAuthenticator の更新を含むな、バグ修正と機能強化を備えた新しいプラットフォームバージョン。IAM ロールの追跡可能性が強化されています。



Kubernetes バージョン 1.14Kubernetes バージョン Amazon EKS プラット

フォームのバージョン有効なアドミッションコントローラー


1.14.9 eks.9 NamespaceLifecycle、LimitRanger、ServiceAccount、DefaultStorageClass、ResourceQuota、DefaultTolerationSeconds、NodeRestriction、MutatingAdmissionWebhook、ValidatingAdmissionWebhook、PodSecurityPolicy拡張機能と追加機能のサポートを含む新しいプラットフォームバージョン。

1.14.9 eks.8 NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,ResourceQuota,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook、PodSecurityPolicy

セキュリティとバグが修正された新しいプラットフォームバージョン。


セキュリティ修正を含む新しいプラットフォームバージョン。

53








Amazon EKSKubernetes 1.14 クラスターを 1.14.9 に更新する、さまざまなバグ修正とパフォーマンス向上のための新しいプラットフォームバージョン。


AWS Fargate (p. 114)のサポートを追加する新しいプラットフォームバージョン。


さまざまなバグ修正とパフォーマンス向上のための新しいプラットフォームバージョン。


マネージド型ノードグループ (p. 87) のサポートを追加する新しいプラットフォームバージョン。


CVE-2019-11253 に対応するために AmazonEKS Kubernetes 1.14 クラスターを 1.14.8 に更新する新しいプラットフォームバージョン。

54

https://groups.google.com/forum/#!msg/kubernetes-security-announce/jk8polzSUxs/dfq6a-MnCQAJ











1.13.12 eks.8 NamespaceLifecycle、LimitRanger、ServiceAccount、DefaultStorageClass、ResourceQuota、DefaultTolerationSeconds、NodeRestriction、MutatingAdmissionWebhook、ValidatingAdmissionWebhook、PodSecurityPolicy拡張機能と追加機能のサポートを含む新しいプラットフォームバージョン。




CVE-2019-11253 に対応するために AmazonEKS Kubernetes 1.13 クラスターをパッチレベル 1.13.12 に更新する新しいプラットフォームバージョン。



1.13.10 eks.4 NamespaceLifecycle,LimitRanger,

サービスアカウントの IAM ロールをサ

55






ServiceAccount,DefaultStorageClass,ResourceQuota,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook、PodSecurityPolicy

ポートする新しいプラットフォームバージョン。詳細については、「サービスアカウントの IAM ロール (p. 264)」を参照してください。


CVE-2019-9512 および CVE-2019-9514 に対応するために AmazonEKS Kubernetes 1.13クラスターをパッチ適用されたバージョン1.13.10 に更新する新しいプラットフォームバージョン。









1.12.10 eks.8 NamespaceLifecycle、LimitRanger、ServiceAccount、DefaultStorageClass、ResourceQuota、DefaultTolerationSeconds、NodeRestriction、MutatingAdmissionWebhook、ValidatingAdmissionWebhook拡張機能と追加機能のサポートを含む新しいプラットフォームバージョン。

1.12.10 eks.7 NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,ResourceQuota,


56

https://groups.google.com/forum/#!topic/kubernetes-security-announce/wlHLHit1BqA


https://groups.google.com/forum/#!topic/kubernetes-security-announce/vUtEcSEY6SM






DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook

1.12.10 eks.6 NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,ResourceQuota,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook

CVE-2019-11253 に対応するために AmazonEKS Kubernetes 1.12クラスターをパッチ適用されたバージョン1.12.10 に更新する新しいプラットフォームバージョン。







57






Amazon EKS ユーザーガイドWindows サポート





新しいプラットフォームバージョン。Kubelet証明書のカスタム DNS名をサポートし、etcdパフォーマンスは向上しています。このバージョンでは、ワーカーノードの Kubelet デーモンによって、数秒ごとに新しい証明書が要求されるというバグが修正されています。


Amazon EKS のKubernetes 1.12 の初回リリース。

Windows サポートこのトピックでは、Windows サポートを Amazon EKS クラスターに追加する方法について説明します。

考慮事項Windows ワーカーノードをデプロイする前に、以下の考慮事項に注意してください。

• Windows ワークロードは、Kubernetes バージョン 1.14 以降を実行する Amazon EKS クラスターでサポートされています。

• Amazon EC2 インスタンスタイプ C3、C4、D2、I2、M4 (m4.16xlarge を除く)、R3 のインスタンスは、Windows ワークロードではサポートされていません。

• ホストネットワーキングモードは、Windows ワークロードではサポートされていません。• Linux でのみコアシステムポッドを実行するには、Amazon EKS クラスターに 1 つ以上の Linux ワー

カーノード (coredns や VPC リソースコントローラーなど) が含まれている必要があります。• kubelet および kube-proxy イベントログは EKS Windows Event Log にリダイレクトされ、200 MB

の制限に設定されます。• Windows ワーカーノードは、ノードごとに 1 つの Elastic Network Interface をサポートしま

す。Windows ワーカーノードごとに実行できるポッドの数は、ノードのインスタンスタイプの ElasticNetwork Interface ごとに使用できる IP アドレスの数から 1 を引いた数に等しくなります。詳細については、『Linux インスタンス用 Amazon EC2 ユーザーガイド』の「各インスタンスタイプのネットワークインターフェイスごとの IP アドレス」を参照してください。

• Calico ネットワークポリシーの適用は、Amazon EKS Windows ノードではテストされていません。• Windows ポッドおよびコンテナのグループ管理サービスアカウント (GMSA) は、Kubernetes 1.14 のア

ルファ機能であり、Amazon EKS ではサポートされていません。Kubernetes ドキュメントの手順に従って、クラスターでこのアルファ機能を有効にしてテストできます。

58

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI



Amazon EKS ユーザーガイドWindows サポートの有効化

Windows サポートの有効化以下の手順は、Amazon EKS クラスターに対して Windows サポートを有効にするのに役立ちます。クライアントオペレーティングシステムで標準ツールを使用するには、以下のタブを選択します。

eksctl

eksctl を使用してクラスターに対して Windows サポートを有効にするには

この手順は、eksctl で作成されたクラスターに対してのみ機能し、eksctl バージョンが 0.19.0以降であることを前提としています。お使いのバージョンは、以下のコマンドを使用して確認できます。

eksctl version


1. 以下の eksctl コマンドを使用して、Amazon EKS クラスターに対して Windows サポートを有効にします。このコマンドは、Windows ワークロードを実行するために Amazon EKS クラスターで必要な、VPC リソースコントローラーと VPC アドミッションコントローラーウェブフックをデプロイします。

eksctl utils install-vpc-controllers --cluster cluster_name --approve

2. Windows サポートを有効にした後、Windows ノードグループをクラスターに起動できます。詳細については、「Amazon EKS Windows ワーカーノードの起動 (p. 101)」を参照してください。

クラスターに Windows サポートを追加した後、アプリケーションのノードセレクタを指定して、ポッドが適切なオペレーティングシステムのノードに到達するようにしてください。Linux ポッドの場合は、マニフェストで以下のノードセレクタテキストを使用します。

nodeSelector: kubernetes.io/os: linux kubernetes.io/arch: amd64

Windows ポッドの場合は、マニフェストで以下のノードセレクタテキストを使用します。

nodeSelector: kubernetes.io/os: windows kubernetes.io/arch: amd64

Windows

Windows クライアントでクラスターに対して Windows サポートを有効にするには

以下の手順で、region-code をクラスターが存在するリージョンに置き換えます。

1. VPC リソースコントローラーをクラスターにデプロイします。

kubectl apply -f https://amazon-eks.s3.us-west-2.amazonaws.com/manifests/region-code/vpc-resource-controller/latest/vpc-resource-controller.yaml

59


2. VPC アドミッションコントローラーウェブフックをクラスターにデプロイします。

a. 必要なスクリプトとデプロイファイルをダウンロードします。

curl -o vpc-admission-webhook-deployment.yaml https://amazon-eks.s3.us-west-2.amazonaws.com/manifests/region-code/vpc-admission-webhook/latest/vpc-admission-webhook-deployment.yaml;curl -o Setup-VPCAdmissionWebhook.ps1 https://amazon-eks.s3.us-west-2.amazonaws.com/manifests/region-code/vpc-admission-webhook/latest/Setup-VPCAdmissionWebhook.ps1;curl -o webhook-create-signed-cert.ps1 https://amazon-eks.s3.us-west-2.amazonaws.com/manifests/region-code/vpc-admission-webhook/latest/webhook-create-signed-cert.ps1;curl -o webhook-patch-ca-bundle.ps1 https://amazon-eks.s3.us-west-2.amazonaws.com/manifests/region-code/vpc-admission-webhook/latest/webhook-patch-ca-bundle.ps1;

b. OpenSSL と jq をインストールします。c. VPC アドミッションウェブフックを設定してデプロイします。

./Setup-VPCAdmissionWebhook.ps1 -DeploymentTemplate ".\vpc-admission-webhook-deployment.yaml"

3. クラスターに必要なクラスターロールバインドがあるかどうかを確認します。

kubectl get clusterrolebinding eks:kube-proxy-windows

以下の出力例のような出力が返された場合、クラスターには必要なロールバインドがあります。

NAME AGEeks:kube-proxy-windows 10d

出力に Error from server (NotFound) が含まれている場合、クラスターには必要なクラスターロールバインドがありません。eks-kube-proxy-windows-crb.yaml という名前のファイルを以下の内容で作成して、バインドを追加します。

kind: ClusterRoleBindingapiVersion: rbac.authorization.k8s.io/v1beta1metadata: name: eks:kube-proxy-windows labels: k8s-app: kube-proxy eks.amazonaws.com/component: kube-proxysubjects: - kind: Group name: "eks:kube-proxy-windows"roleRef: kind: ClusterRole name: system:node-proxier apiGroup: rbac.authorization.k8s.io

設定をクラスターに適用します。

kubectl apply -f eks-kube-proxy-windows-crb.yaml


60

https://wiki.openssl.org/index.php/Binaries

https://stedolan.github.io/jq/download/





nodeSelector: kubernetes.io/os: windows kubernetes.io/arch: amd64

macOS and Linux

macOS または Linux クライアントでクラスターに対して Windows サポートを有効にするには

この手順では、クライアントシステムに openssl ライブラリと jq JSON プロセッサがインストールされている必要があります。

以下の手順で、region-code をクラスターが存在するリージョンに置き換えます。

1. VPC リソースコントローラーをクラスターにデプロイします。

kubectl apply -f https://amazon-eks.s3.us-west-2.amazonaws.com/manifests/region-code/vpc-resource-controller/latest/vpc-resource-controller.yaml

2. クラスターの VPC アドミッションコントローラーウェブフックのマニフェストを作成します。

a. 必要なスクリプトとデプロイファイルをダウンロードします。

curl -o webhook-create-signed-cert.sh https://amazon-eks.s3.us-west-2.amazonaws.com/manifests/region-code/vpc-admission-webhook/latest/webhook-create-signed-cert.shcurl -o webhook-patch-ca-bundle.sh https://amazon-eks.s3.us-west-2.amazonaws.com/manifests/region-code/vpc-admission-webhook/latest/webhook-patch-ca-bundle.shcurl -o vpc-admission-webhook-deployment.yaml https://amazon-eks.s3.us-west-2.amazonaws.com/manifests/region-code/vpc-admission-webhook/latest/vpc-admission-webhook-deployment.yaml

b. シェルスクリプトにそれらを実行するためのアクセス許可を追加します。

chmod +x webhook-create-signed-cert.sh webhook-patch-ca-bundle.sh

c. セキュアな通信のためのシークレットを作成します。

./webhook-create-signed-cert.sh

d. シークレットを確認します。

kubectl get secret -n kube-system vpc-admission-webhook-certs

e. ウェブフックを設定し、デプロイファイルを作成します。

61


cat ./vpc-admission-webhook-deployment.yaml | ./webhook-patch-ca-bundle.sh > vpc-admission-webhook.yaml

3. VPC アドミッションウェブフックをデプロイします。

kubectl apply -f vpc-admission-webhook.yaml

4. クラスターに必要なクラスターロールバインドがあるかどうかを確認します。

kubectl get clusterrolebinding eks:kube-proxy-windows

以下の出力例のような出力が返された場合、クラスターには必要なロールバインドがあります。

NAME AGEeks:kube-proxy-windows 10d

出力に Error from server (NotFound) が含まれている場合、クラスターには必要なクラスターロールバインドがありません。eks-kube-proxy-windows-crb.yaml という名前のファイルを以下の内容で作成して、バインドを追加します。

kind: ClusterRoleBindingapiVersion: rbac.authorization.k8s.io/v1beta1metadata: name: eks:kube-proxy-windows labels: k8s-app: kube-proxy eks.amazonaws.com/component: kube-proxysubjects: - kind: Group name: "eks:kube-proxy-windows"roleRef: kind: ClusterRole name: system:node-proxier apiGroup: rbac.authorization.k8s.io

設定をクラスターに適用します。

kubectl apply -f eks-kube-proxy-windows-crb.yaml





nodeSelector: kubernetes.io/os: windows

62

Amazon EKS ユーザーガイドWindows サンプルアプリケーションをデプロイする

kubernetes.io/arch: amd64

Windows サンプルアプリケーションをデプロイするWindows サンプルアプリケーションをデプロイするには

1. 次の内容で、windows-server-iis.yaml というファイルを作成します。

apiVersion: apps/v1kind: Deploymentmetadata: name: windows-server-iisspec: selector: matchLabels: app: windows-server-iis tier: backend track: stable replicas: 1 template: metadata: labels: app: windows-server-iis tier: backend track: stable spec: containers: - name: windows-server-iis image: mcr.microsoft.com/windows/servercore:1809 ports: - name: http containerPort: 80 imagePullPolicy: IfNotPresent command: - powershell.exe - -command - "Add-WindowsFeature Web-Server; Invoke-WebRequest -UseBasicParsing -Uri 'https://dotnetbinaries.blob.core.windows.net/servicemonitor/2.0.1.6/ServiceMonitor.exe' -OutFile 'C:\\ServiceMonitor.exe'; echo '<html><body><br/><br/><marquee><H1>Hello EKS!!!<H1><marquee></body><html>' > C:\\inetpub\\wwwroot\\default.html; C:\\ServiceMonitor.exe 'w3svc'; " nodeSelector: kubernetes.io/os: windows---apiVersion: v1kind: Servicemetadata: name: windows-server-iis-service namespace: defaultspec: ports: - port: 80 protocol: TCP targetPort: 80 selector: app: windows-server-iis tier: backend track: stable sessionAffinity: None type: LoadBalancer

2. アプリケーションをクラスターにデプロイします。

63

Amazon EKS ユーザーガイドArm サポート

kubectl apply -f windows-server-iis.yaml

3. ポッドのステータスを取得します。

kubectl get pods -o wide --watch

ポッドが Running 状態になるまで待ちます。4. クラスターのサービスをクエリし、windows-server-iis-service サービスの [外部 IP] 列が自動

入力されるまで待機します。Note

IP アドレスが使用可能になるまでに数分かかる場合があります。

kubectl get services -o wide

5. 外部 IP アドレスが使用可能になったら、ウェブブラウザでそのアドレスを指定して、IIS ホームページを表示します。

Note

DNS が伝播され、サンプルアプリケーションがウェブブラウザにロードされるまでに数分かかる場合があります。

Arm サポートこのトピックでは、Amazon EKS クラスターを作成し、Amazon EC2 A1 インスタンスで実行されているワーカーノードを Amazon EKS クラスターに追加する方法について説明します。Amazon EC2 A1 インスタンスは、ウェブサーバー、コンテナ化されたマイクロサービス、キャッシュサーバー群、分散データストアといった、スケールアウト型の Arm ベースアプリケーションのコストを大幅に削減します。

Note

これらの指示とそれらが参照するアセットは、AWS によって管理されるベータ機能として提供されます。これらの指示およびアセットの使用は、AWS のサービス条件のベータ版として管理されます。ベータ版では、Amazon EKS は本稼働の Kubernetes ワークロードでの Amazon EC2 A1インスタンスの使用をサポートしていません。GitHub issue でコメントや質問を送信する。

考慮事項• ワーカーノードは任意の A1 インスタンスタイプにできますが、すべてのワーカーノードは A1 インスタ

ンスタイプである必要があります。• ワーカーノードは、Kubernetes バージョン 1.13 または 1.14 でデプロイする必要があります。• A1 インスタンスワーカーノードを使用するには、新しい Amazon EKS クラスターをセットアップする

必要があります。既存のワーカーノードがあるクラスターにワーカーノードを追加することはできません。

前提条件• コンピュータに eksctl がインストールされている。インストールされていない場合は、eksctl をイ

ンストールする (p. 4) を参照してください。• kubectl と AWS IAM Authenticator がコンピュータにインストールされている。インストールされてい

ない場合は、kubectl のインストール (p. 190) のインストール手順を参照してください。

64

https://aws.amazon.com/service-terms/


https://aws.amazon.com/ec2/instance-types/a1/


クラスターの作成1. 次のコマンドを実行して、ワーカーノードのない Amazon EKS クラスターを作成します。Kubernetes

バージョン 1.13 を実行するクラスターを作成する場合は、コマンドの 1.14 を 1.13 に置き換えます。region-code は、Amazon EKS が使用可能な任意のリージョンに置き換えることができます。

eksctl create cluster \--name a1-preview \--version 1.14 \--region region-code \--without-nodegroup

eksctl を使用して Amazon EKS クラスターを起動すると、AWS CloudFormation スタックが作成されます。このスタックの起動プロセスには、通常 10～15 分かかります。Amazon EKS コンソールで進捗状況をモニターすることができます。

2. クラスターの作成が完了したら、AWS CloudFormation コンソールを開きます。eksctl-a1-preview-cluster という名前のスタックが表示されます。このスタックを選択します。[Resources(リソース)] タブを選択します。ControlPlaneSecurityGroup および VPC リソースの ID の値を記録します。

3. kubectl get svc コマンドを使用して、クラスターが実行されていることを確認します。コマンドは次の出力例のような出力を返します。

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEkubernetes ClusterIP 10.100.0.1 <none> 443/TCP 20m

Arm サポートを有効にするAmazon EKS クラスター内の A1 ノードのみをサポートするには、Kubernetes コンポーネントの一部を更新する必要があります。以下のステップを実行して、CoreDNS および kube-proxy を更新し、AmazonVPC ARM64 CNI Plugin for Kubernetes をインストールします。

1. 前の手順でインストールしたクラスターのバージョンに対応するコマンドを使用して、CoreDNS イメージ ID を更新します。

Kubernetes 1.14

kubectl apply -f https://raw.githubusercontent.com/aws/containers-roadmap/master/preview-programs/eks-arm-preview/dns-arm-1.14.yaml

Kubernetes 1.13

kubectl apply -f https://raw.githubusercontent.com/aws/containers-roadmap/master/preview-programs/eks-arm-preview/dns-arm-1.13.yaml

2. 前の手順でインストールしたクラスターのバージョンに対応するコマンドを使用して、kube-proxyイメージ ID を更新します。

Kubernetes 1.14

kubectl apply -f https://raw.githubusercontent.com/aws/containers-roadmap/master/preview-programs/eks-arm-preview/kube-proxy-arm-1.14.yaml

Kubernetes 1.13

65

https://docs.aws.amazon.com/general/latest/gr/eks.html

https://us-west-2.console.aws.amazon.com/cloudformation/home

Amazon EKS ユーザーガイドワーカーノードの起動

kubectl apply -f https://raw.githubusercontent.com/aws/containers-roadmap/master/preview-programs/eks-arm-preview/kube-proxy-arm-1.13.yaml

3. Amazon VPC ARM64 CNI Plugin for Kubernetes をデプロイします。

kubectl apply -f https://raw.githubusercontent.com/aws/containers-roadmap/master/preview-programs/eks-arm-preview/aws-k8s-cni-arm64.yaml

ワーカーノードの起動1. AWS CloudFormation コンソールを開きます。Amazon EKS クラスターを作成した AWS リージョン

を使用していることを確認します。2. [スタックの作成] を選択し、[With new resources (standard) 新しいリソースを使用 (標準)] を選択しま

す。3. [Specify template (テンプレートの指定)] で [Amazon S3 URL] を選択し、[Amazon S3 URL] ボックス

に次の URL を入力して、[次へ] を 2 回選択します。

https://amazon-eks.s3.us-west-2.amazonaws.com/cloudformation/2020-04-21/amazon-eks-arm-nodegroup.yaml

4. [Specify stack details (スタックの詳細の指定)] ページで、必要に応じて以下のパラメータを指定します。

• Stack name – AWS CloudFormation スタックのスタック名を選択します。たとえば、a1-preview-worker-nodes という名前を付けることができます。

• KubernetesVersion – Amazon EKS クラスターの起動時に選択した Kubernetes のバージョンを選択します。

• ClusterName – Amazon EKS クラスターの作成時に使用した名前を入力します。

Important

この名前は、「ステップ 1: Amazon EKS クラスターを作成する (p. 14)」で使用した名前と完全一致する必要があります。それ以外の場合、ワーカーノードにクラスターを結合できません。

• ClusterControlPlaneSecurityGroup – the section called “クラスターの作成” (p. 65) で生成した、AWS CloudFormation 出力の ControlPlaneSecurityGroup ID 値を選択します。

• NodeGroupName – ノードグループの名前を入力します。この名前は、ワーカーノードに対して作成される Auto Scaling ノードグループを識別するために後で使用できます。

• NodeAutoScalingGroupMinSize – ワーカーノードの Auto Scaling グループがスケールインする最小ノード数を入力します。

• NodeAutoScalingGroupDesiredCapacity – スタック作成時にスケーリングする必要のあるノード数を入力します。

• NodeAutoScalingGroupMaxSize – ワーカーノードの Auto Scaling グループがスケールアウトする最大ノード数を入力します。

• NodeInstanceType – a1.large など、ワーカーノードの A1 インスタンスタイプを選択します。• NodeVolumeSize – ワーカーノードのルートボリュームサイズを GiB 単位で指定します。• KeyName – 起動後に、SSH を使用してワーカーノードに接続するときに使用できる Amazon EC2

SSH キーペアの名前を入力します。Amazon EC2 キーペアをまだ持っていない場合は、AWS マネジメントコンソールで作成できます。詳細については、『Linux インスタンス用 Amazon EC2 ユーザーガイド』の「Amazon EC2 キーペア」を参照してください。

66

https://console.aws.amazon.com/cloudformation


Amazon EKS ユーザーガイドワーカーノードをクラスターに結合する

Note

ここでキーペアを指定しないと、AWS CloudFormation スタックの作成は失敗します。• BootstrapArguments – ブートストラップスクリプトに渡す引数。詳細については、https://

github.com/awslabs/amazon-eks-ami/blob/master/files/bootstrap.sh を参照してください。• VpcId – the section called “クラスターの作成” (p. 65) で作成した VPC の ID を入力します。• Subnets – the section called “クラスターの作成” (p. 65) で作成したサブネットを選択します。

Important

いずれかのサブネットがパブリックサブネットである場合は、パブリック IP アドレスの自動割り当て設定を有効にする必要があります。この設定がパブリックサブネットに対して有効になっていない場合、そのパブリックサブネットにデプロイするワーカーノードにはパブリック IP アドレスが割り当てられず、クラスターやその他の AWS のサービスと通信できなくなります。Amazon EKS AWS CloudFormationVPC テンプレート (p. 158)のいずれかを使用して 03/26/2020 以前に、または eksctl を使用してサブネットがデプロイされた場合、パブリックサブネットではパブリック IP アドレスの自動割り当てが無効になります。サブネットのパブリック IP アドレス割り当てを有効にする方法については、「サブネットのパブリック IPv4 アドレス属性の変更」を参照してください。ワーカーノードがプライベートサブネットにデプロイされている場合、NAT ゲートウェイを介してクラスターや他の AWS のサービスと通信できます。

• NodeImageAMI113 – 1.13 AMI イメージ ID の Amazon EC2 Systems Manager パラメータ。KubernetesVersion で 1.14 を選択した場合、この値は無視されます。

• NodeImageAMI114 – 1.14 AMI イメージ ID の Amazon EC2 Systems Manager パラメータ。KubernetesVersion で 1.13 を選択した場合、この値は無視されます。

5. [次へ] を選択し、もう一度 [次へ] を選択します。6. スタックが IAM リソースを作成する可能性があることを確認し、[スタックの作成] を選択します。7. スタックの作成が完了したら、コンソールで選択し、[出力] を選択します。8. 作成されたノードグループの [NodeInstanceRole] を記録します。これは、Amazon EKS ワーカーノー

ドを設定する際、必要になります。

ワーカーノードをクラスターに結合する1. AWS IAM オーセンティケーター設定マップをダウンロード、編集、適用します。

a. 次のコマンドを使用して設定マップをダウンロードします。

wget https://amazon-eks.s3.us-west-2.amazonaws.com/cloudformation/2019-11-15/aws-auth-cm.yaml

b. 任意のテキストエディタでファイルを開きます。インスタンスロールの <イイイイイイイイイイイ ARN(イイイイイイイイイイイイイイイイ)> スニペットを、前の手順で記録した [NodeInstanceRole] の値に置き換え、ファイルを保存します。

Important

このファイルの他の行は変更しないでください。

apiVersion: v1kind: ConfigMapmetadata: name: aws-auth namespace: kube-systemdata: mapRoles: |

67

https://github.com/awslabs/amazon-eks-ami/blob/master/files/bootstrap.sh




Amazon EKS ユーザーガイド(オプション) アプリケーションのデプロイ

- rolearn: <ARN of instance role (not instance profile)> username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes

c. 設定を適用します。このコマンドが完了するまで数分かかることがあります。

kubectl apply -f aws-auth-cm.yaml

Note


2. ノードのステータスを監視し、Ready ステータスになるまで待機します。


(オプション) アプリケーションのデプロイワーカーノードにアプリケーションをデプロイして実行できることを確認するには、次の手順を実行します。

1. 次のコマンドを使用して CNI メトリクスヘルパーをデプロイします。

kubectl apply -f https://raw.githubusercontent.com/aws/containers-roadmap/master/preview-programs/eks-arm-preview/cni-metrics-helper-arm64.yaml

次の出力例のような出力が返されます。

clusterrole.rbac.authorization.k8s.io/cni-metrics-helper createdserviceaccount/cni-metrics-helper createdclusterrolebinding.rbac.authorization.k8s.io/cni-metrics-helper createddeployment.extensions/cni-metrics-helper created

2. 次のコマンドを使用して、CNI メトリクスヘルパーが実行されていることを確認します。

kubectl -n kube-system get pods -o wide

cni-metrics-helper ポッドが出力に返された場合、ポッドは実行中です。

API サーバーのフラグの表示Amazon EKS クラスターのコントロールプレーンのログ記録機能を使用して、クラスターの作成時に有効になっていた API サーバーのフラグを表示できます。詳細については、「Amazon EKS コントロールプレーンのログ記録 (p. 42)」を参照してください。このトピックでは、Amazon CloudWatch コンソールで Amazon EKS クラスターの API サーバーのフラグを表示する方法を説明します。

68

Amazon EKS ユーザーガイドAPI サーバーのフラグの表示

クラスターを最初に作成すると、初期 API サーバーのログには、API サーバーの起動に使用されたフラグが含まれます。クラスターを起動するとき、またはその直後に API サーバーのログを有効にすると、これらのログが CloudWatch Logs に送信され、そこで表示できます。

クラスターの API サーバーのフラグを表示するには

1. Amazon EKS クラスターの API サーバーのログを有効にします (まだの場合)。

a. Open the Amazon EKS console at https://console.aws.amazon.com/eks/home#/clusters.b. クラスターの名前を選択すると、そのクラスターの情報を表示されます。c. [ログ記録] の [更新] を選択します。d. [API server (API サーバー)] の場合は、ログの種類が [Enabled (有効)] であることを確認します。e. [更新] を選択して終了します。

2. Amazon EKS コンソールで、クラスターの詳細ページの [Logging (ログ記録)] セクションまで下にスクロールします。[CloudWatch] の下のリンクを選択して、クラスターのログの CloudWatch コンソールページを開きます。

3. ログストリームのリストで、kube-apiserver-example-ID-288ec988b77a59d70ec77 ログストリームの最も古いバージョンを見つけます。[Last Event Time (最終のイベント時刻)] 列を使用して、ログストリームの経過時間を判別します。

4. 最早イベント (ログストリームの先頭) までスクロールします。クラスターの初期 API サーバーフラグが表示されます。

Note

ログストリームの先頭に API サーバーログが表示されない場合は、サーバーで API サーバーログ記録を有効にする前に API サーバーのログファイルがローテーションされた可能性があります。API サーバーのログ記録が有効になる前にローテーションされたログファイルは、CloudWatch にエクスポートできません。ただし、同じ Kubernetes バージョンで新しいクラスターを作成し、クラスターの作成時にAPI サーバーのログ記録を有効にすることはできます。同じプラットフォームバージョンを持つクラスターでは、同じフラグが有効になるため、フラグは新しいクラスターのフラグと一致する必要があります。CloudWatch で新しいクラスターのフラグの表示を完了したら、新しいクラスターを削除できます。

69



ワーカーノードKubernetes のワーカーマシンはノードと呼ばれます。Amazon EKS ワーカーノードは AWS アカウントで実行され、クラスター API サーバーエンドポイントを介してクラスターのコントロールプレーンに接続します。ノードグループに 1 つ以上のワーカーノードをデプロイします。ノードグループは、Amazon EC2Auto Scaling グループにデプロイされる 1 つ以上の Amazon EC2 インスタンスです。ノードグループ内のすべてのインスタンスは、次の条件を満たす必要があります。

• 同じインスタンスタイプであること• 同じ Amazon マシンイメージ (AMI) を実行していること• 同じ Amazon EKS ワーカーノード IAM ロール (p. 260) を使用すること

クラスターには複数のノードグループを含めることができ、各ノードグループには複数のワーカーノードを含めることができます。マネージド型ノードグループ (p. 87)をデプロイする場合、ノードグループに含めることができるノードの最大数と、クラスターに含めることができるノードグループの最大数があります。詳細については、「サービスクォータ (p. 305)」を参照してください。この情報を使用して、要件を満たすためにクラスターで必要なノードグループの数を決定できます。

Amazon EKS ワーカーノードはスタンダードな Amazon EC2 インスタンスであり、通常の EC2 価格に基づいて請求されます。詳細については、「Amazon EC2 料金表」を参照してください。

Amazon EKS は、Amazon EKS 最適化 AMI と呼ばれる Amazon マシンイメージ (AMI) を提供します。この AMI は Amazon Linux 2 上に構築され、Amazon EKS ワーカーノードのベースイメージとして機能するように設定されています。AMI は、設定しなくても Amazon EKS と動作するように設定されており、Docker、kubelet、および AWS IAM オーセンティケーターが含まれています。また、AMI にはクラスターのコントロールプレーンを自動的に検出して接続を許可する、特別なブートストラップスクリプトも含まれます。

Note

Amazon Linux 2 のセキュリティまたはプライバシーイベントは、Amazon Linux セキュリティセンターで追跡するか、関連付けられた RSS フィードでサブスクライブできます。セキュリティおよびプライバシーイベントには、問題の概要、影響を受けるパッケージ、および問題を修正するためにインスタンスを更新する方法などがあります。

Kubernetes バージョン 1.14 とプラットフォームバージョン (p. 52) eks.3 以降、Amazon EKS クラスターは、ノードのプロビジョニングとライフサイクル管理を自動化する、マネージド型ノードグループ (p. 87) をサポートします。以前のバージョンの Amazon EKS クラスターでは、Amazon EKS 提供のAWS CloudFormation テンプレートを使用してワーカーノードを起動できます。

CIDR ブロックを使用してクラスターのパブリックエンドポイントへのアクセスを制限する場合は、ワーカーノードがクラスターと通信できるように、プライベートエンドポイントアクセスも有効にすることをお勧めします。プライベートエンドポイントが有効になっていない場合、パブリックアクセスに指定するCIDR ブロックに、VPC からの出力ソースを含める必要があります。詳細については、「Amazon EKS クラスターエンドポイントのアクセスコントロール (p. 37)」を参照してください。

Amazon EKS クラスターにワーカーノードを追加するには、「Amazon EKS Linux ワーカーノードの起動 (p. 95)」を参照してください。このガイドのステップに従うと、必要なタグがワーカーノードに追加されます。ワーカーを手動で起動する場合は、各ワーカーノードに次のタグを追加する必要があります。詳細については、「個々のリソースでのタグの追加と削除」を参照してください。

キー値

kubernetes.io/cluster/<cluster-name> owned

70

https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroup.html

https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroup.html



https://alas.aws.amazon.com/alas2.html


https://alas.aws.amazon.com/AL2/alas.rss

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags

Amazon EKS ユーザーガイドAmazon EKS 最適化 Linux AMI

一般的な Kubernetes の観点からのワーカーノードの詳細については、Kubernetes のドキュメントでノードについて参照してください。

トピック• Amazon EKS 最適化 Linux AMI (p. 71)• Amazon EKS 最適化 Windows AMI (p. 83)• マネージド型ノードグループ (p. 87)• Amazon EKS Linux ワーカーノードの起動 (p. 95)• Amazon EKS Windows ワーカーノードの起動 (p. 101)• セルフマネージド型ワーカーノードの更新 (p. 105)• Ubuntu Amazon EKS最適化 AMI (p. 113)

Amazon EKS 最適化 Linux AMIAmazon EKS 最適化 Linux AMI は Amazon Linux 2 上に構築され、Amazon EKS ワーカーノードのベースイメージとして機能するように設定されています。AMI は、設定しなくても Amazon EKS と動作するように設定されており、Docker、kubelet、および AWS IAM オーセンティケーターが含まれています。

Note

Amazon Linux 2 のセキュリティまたはプライバシーイベントは、Amazon Linux セキュリティセンターで追跡するか、関連付けられた RSS フィードでサブスクライブできます。セキュリティおよびプライバシーイベントには、問題の概要、影響を受けるパッケージ、および問題を修正するためにインスタンスを更新する方法などがあります。

最新の Amazon EKS 最適化 AMI (GPU 対応 (p. 77)あり/なし) の AMI ID を次の表に示します。さまざまなツールを使用して、AWS Systems Manager パラメータで ID を取得することもできます。詳細については、「Amazon EKS 最適化 AMI ID の取得 (p. 82)」を参照してください。

Note

Amazon EKS 最適化 AMI (GPU 対応) では、GPU インスタンスタイプのみサポートしています。これらのインスタンスタイプは必ず、ワーカーノードの AWS CloudFormation テンプレートで指定してください。GPU 対応の Amazon EKS 最適化 AMI を使用することで、NVIDIA のエンドユーザーライセンス契約 (EULA) に同意したものとみなされます。

Kubernetes version 1.16.8

リージョン Amazon EKS 最適化 AMI (GPU 対応)

米国東部 (オハイオ) (us-east-2)

AMI ID を表示 AMI ID を表示

米国東部（バージニア北部）(us-east-1)


米国西部 (オレゴン) (us-west-2)


アジアパシフィック (香港)(ap-east-1)


アジアパシフィック (ムンバイ)(ap-south-1)


71

https://kubernetes.io/docs/concepts/architecture/nodes/

https://kubernetes.io/docs/concepts/architecture/nodes/




https://www.nvidia.com/en-us/about-nvidia/eula-agreement/


https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Feks%252Foptimized-ami%252F1.16%252Famazon-linux-2%252Frecommended%252Fimage_id/description?region=us-east-2

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Feks%252Foptimized-ami%252F1.16%252Famazon-linux-2-gpu%252Frecommended%252Fimage_id/description?region=us-east-2



https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Feks%252Foptimized-ami%252F1.16%252Famazon-linux-2%252Frecommended%252Fimage_id/description?region=us-west-2

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Feks%252Foptimized-ami%252F1.16%252Famazon-linux-2-gpu%252Frecommended%252Fimage_id/description?region=us-west-2

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Feks%252Foptimized-ami%252F1.16%252Famazon-linux-2%252Frecommended%252Fimage_id/description?region=ap-east-1

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Feks%252Foptimized-ami%252F1.16%252Famazon-linux-2-gpu%252Frecommended%252Fimage_id/description?region=ap-east-1

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Feks%252Foptimized-ami%252F1.16%252Famazon-linux-2%252Frecommended%252Fimage_id/description?region=ap-south-1

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Feks%252Foptimized-ami%252F1.16%252Famazon-linux-2-gpu%252Frecommended%252Fimage_id/description?region=ap-south-1



アジアパシフィック (東京)(ap-northeast-1)


アジアパシフィック (ソウル)(ap-northeast-2)


アジアパシフィック (シンガポール) (ap-southeast-1)


アジアパシフィック (シドニー)(ap-southeast-2)


カナダ (中部) (ca-central-1) AMI ID を表示 AMI ID を表示

欧州 (フランクフルト) (eu-central-1)


欧州 (アイルランド) (eu-west-1)


欧州 (ロンドン) (eu-west-2) AMI ID を表示 AMI ID を表示

欧州 (パリ) (eu-west-3) AMI ID を表示 AMI ID を表示

欧州 (ストックホルム) (eu-north-1)


中東 (バーレーン) (me-south-1)


南米 (サンパウロ) (sa-east-1) AMI ID を表示 AMI ID を表示

中国 (北京) (cn-north-1) AMI ID を表示 AMI ID を表示

中国 (寧夏) (cn-northwest-1) AMI ID を表示 AMI ID を表示















72

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Feks%252Foptimized-ami%252F1.16%252Famazon-linux-2%252Frecommended%252Fimage_id/description?region=ap-northeast-1

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Feks%252Foptimized-ami%252F1.16%252Famazon-linux-2-gpu%252Frecommended%252Fimage_id/description?region=ap-northeast-1



https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Feks%252Foptimized-ami%252F1.16%252Famazon-linux-2%252Frecommended%252Fimage_id/description?region=ap-southeast-1

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Feks%252Foptimized-ami%252F1.16%252Famazon-linux-2-gpu%252Frecommended%252Fimage_id/description?region=ap-southeast-1



https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Feks%252Foptimized-ami%252F1.16%252Famazon-linux-2%252Frecommended%252Fimage_id/description?region=ca-central-1

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Feks%252Foptimized-ami%252F1.16%252Famazon-linux-2-gpu%252Frecommended%252Fimage_id/description?region=ca-central-1

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Feks%252Foptimized-ami%252F1.16%252Famazon-linux-2%252Frecommended%252Fimage_id/description?region=eu-central-1

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Feks%252Foptimized-ami%252F1.16%252Famazon-linux-2-gpu%252Frecommended%252Fimage_id/description?region=eu-central-1

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Feks%252Foptimized-ami%252F1.16%252Famazon-linux-2%252Frecommended%252Fimage_id/description?region=eu-west-1

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Feks%252Foptimized-ami%252F1.16%252Famazon-linux-2-gpu%252Frecommended%252Fimage_id/description?region=eu-west-1





https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Feks%252Foptimized-ami%252F1.16%252Famazon-linux-2%252Frecommended%252Fimage_id/description?region=eu-north-1

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Feks%252Foptimized-ami%252F1.16%252Famazon-linux-2-gpu%252Frecommended%252Fimage_id/description?region=eu-north-1

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Feks%252Foptimized-ami%252F1.16%252Famazon-linux-2%252Frecommended%252Fimage_id/description?region=me-south-1

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Feks%252Foptimized-ami%252F1.16%252Famazon-linux-2-gpu%252Frecommended%252Fimage_id/description?region=me-south-1

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Feks%252Foptimized-ami%252F1.16%252Famazon-linux-2%252Frecommended%252Fimage_id/description?region=sa-east-1

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Feks%252Foptimized-ami%252F1.16%252Famazon-linux-2-gpu%252Frecommended%252Fimage_id/description?region=sa-east-1

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Feks%252Foptimized-ami%252F1.16%252Famazon-linux-2%252Frecommended%252Fimage_id/description?region=cn-north-1

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Feks%252Foptimized-ami%252F1.16%252Famazon-linux-2-gpu%252Frecommended%252Fimage_id/description?region=cn-north-1

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Feks%252Foptimized-ami%252F1.16%252Famazon-linux-2%252Frecommended%252Fimage_id/description?region=cn-northwest-1

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Feks%252Foptimized-ami%252F1.16%252Famazon-linux-2-gpu%252Frecommended%252Fimage_id/description?region=cn-northwest-1



















































73















































































74



https://ap-southeast-2.console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Feks%252Foptimized-ami%252F1.14%252Famazon-linux-2%252Frecommended%252Fimage_id/description?region=ap-southeast-2

https://ap-southeast-2.console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Feks%252Foptimized-ami%252F1.14%252Famazon-linux-2-gpu%252Frecommended%252Fimage_id/description?region=ap-southeast-2











































































75









https://eu-west-2.console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Feks%252Foptimized-ami%252F1.13%252Famazon-linux-2%252Frecommended%252Fimage_id/description?region=eu-west-2

https://eu-west-2.console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Feks%252Foptimized-ami%252F1.13%252Famazon-linux-2-gpu%252Frecommended%252Fimage_id/description?region=eu-west-2































Amazon EKS ユーザーガイドAmazon EKS 最適化 AMI のビルドスクリプト
















Important

これらの AMI には、ワーカーノードの最新 AWS CloudFormation テンプレートが必要です。これらの AMI は、以前のバージョンのワーカーノードテンプレートで使用することはできません。つまり、クラスターに加えることはできません。これらの AMI を使用するには、必ず、既存のAWS CloudFormation ワーカースタックを最新のテンプレート (以下の URL) でアップグレードしてください。

https://amazon-eks.s3.us-west-2.amazonaws.com/cloudformation/2020-04-21/amazon-eks-nodegroup.yaml

AWS CloudFormation ワーカーノードテンプレートは、特殊なブートストラップスクリプトをトリガーする Amazon EC2 ユーザーデータを使用して、ワーカーノードを起動します。このスクリプトにより、ワーカーノードはクラスターのコントロールプレーンを自動的に検出して接続できるようになります。詳細については、「Amazon EKS Linux ワーカーノードの起動 (p. 95)」を参照してください。

Amazon EKS 最適化 AMI のビルドスクリプトAmazon Elastic Kubernetes Service (Amazon EKS) には、Amazon EKS 最適化 AMI の構築に使用されるオープンソースのビルドスクリプトがあります。これらのビルドスクリプトは、現在 GitHub で入手できます。

Amazon EKS 最適化 AMI は Amazon Linux 2 の上に構築されていて、特に Amazon EKS クラスターのワーカーノードとして使用できます。このリポジトリを使用して、Amazon EKS チームがkubelet、Docker、Kubernetes 用の AWS IAM オーセンティケーターなどの設定方法の詳細を表示できます。

ビルドスクリプトレポジトリには、HashiCorp Packer テンプレートと、AMI を生成するビルドスクリプトが含まれています。これらのスクリプトは、Amazon EKS 最適化 AMI ビルドの真のソースであるため、GitHub リポジトリに従って AMI の変化をモニタリングできます。たとえば、独自の AMI で、EKSチームが正式な AMI に使用するのと同じバージョンの Docker を使用できます。

76






















https://github.com/awslabs/amazon-eks-ami

https://www.packer.io/

Amazon EKS ユーザーガイドAmazon EKS 最適化 AMI (GPU 対応)

さらに、GitHub リポジトリには、起動時にインスタンスの証明書データ、コントロールプレーンエンドポイント、クラスター名などの設定のため実行される特別なブートストラップスクリプトも含まれます。

さらに、GitHub リポジトリには、当社の Amazon EKS ワーカーノード AWS CloudFormation テンプレートが含まれています。これらのテンプレートにより、Amazon EKS 最適化 AMI を実行するインスタンスの準備と、クラスターへの登録を簡単に行うことができます。

詳細については、GitHub でリポジトリ (https://github.com/awslabs/amazon-eks-ami) について参照してください。

Amazon EKS 最適化 AMI (GPU 対応)Amazon EKSGPU 対応最適化 AMI はスタンダードな Amazon EKS 最適化 AMI 上に構築されており、GPU ワークロードをサポートするための Amazon EKS ワーカーノードのオプションイメージとして機能するよう構成されています。

スタンダードな Amazon EKS 最適化 AMI に加えて、GPU 対応の AMI には、以下が含まれています。

• NVIDIA ドライバー• nvidia-docker2 パッケージ• nvidia-container-runtime (デフォルトのランタイム)

最新の Amazon EKS 最適化 AMI (GPU 対応あり) の AMI ID を次の表に示します。さまざまなツールを使用して、AWS Systems Manager パラメータで ID を取得することもできます。詳細については、「Amazon EKS 最適化 AMI ID の取得 (p. 82)」を参照してください。

Note

Amazon EKS 最適化 AMI (GPU 対応) では、GPU インスタンスタイプのみサポートしています。これらのインスタンスタイプは必ず、ワーカーノードの AWS CloudFormation テンプレートで指定してください。GPU 対応の Amazon EKS 最適化 AMI を使用することで、NVIDIA のエンドユーザーライセンス契約 (EULA) に同意したものとみなされます。



米国東部 (バージニア北部) (us-east-1)



Important

これらの AMI には、ワーカーノードの最新 AWS CloudFormation テンプレートが必要です。これらの AMI は、以前のバージョンのワーカーノードテンプレートで使用することはできません。つまり、クラスターに加えることはできません。これらの AMI を使用するには、必ず、既存のAWS CloudFormation ワーカースタックを最新のテンプレート (以下の URL) でアップグレードしてください。


AWS CloudFormation ワーカーノードテンプレートは、特殊なブートストラップスクリプトをトリガーする Amazon EC2 ユーザーデータを使用して、ワーカーノードを起動します。このスクリプトにより、ワー

77


https://github.com/awslabs/amazon-eks-ami




Amazon EKS ユーザーガイドAmazon EKS 最適化 AMI (GPU 対応)

カーノードはクラスターのコントロールプレーンを自動的に検出して接続できるようになります。詳細については、「Amazon EKS Linux ワーカーノードの起動 (p. 95)」を参照してください。

GPU ワーカーノードがクラスターに参加した後で、NVIDIA device plugin for Kubernetes を次のコマンドを使用してクラスターのデーモンセットとして適用しなければなりません。


ノードに GPU が割り当てられたことは、次のコマンドを使って確認できます。

kubectl get nodes "-o=custom-columns=NAME:.metadata.name,GPU:.status.allocatable.nvidia\.com/gpu"

GPU マニフェストの例このセクションでは、ポッドマニフェスト例を示し、GPU のワーカーが適切に設定されていることをテストします。

Example nvidia-smi 出力の取得

このポッドマニフェスト例では、ワーカーノードで nvidia-smi を実行する Cuda コンテナを起動します。nvidia-smi.yaml という名前のファイルを作成し、そこに以下のマニフェストファイルをコピー・ペーストしてファイルを保存します。

apiVersion: v1kind: Podmetadata: name: nvidia-smispec: restartPolicy: OnFailure containers: - name: nvidia-smi image: nvidia/cuda:9.2-devel args: - "nvidia-smi" resources: limits: nvidia.com/gpu: 1

上記の変更を次のコマンドを使って適用します。

kubectl apply -f nvidia-smi.yaml

ポッドの実行が終了後、次のコマンドを使用してログを表示します。

kubectl logs nvidia-smi

出力:

Mon Aug 6 20:23:31 2018+-----------------------------------------------------------------------------+| NVIDIA-SMI 396.26 Driver Version: 396.26 ||-------------------------------+----------------------+----------------------+| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC || Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |

78


Amazon EKS ユーザーガイドAmazon EKS 最適化 Linux AMI のバージョン

|===============================+======================+======================|| 0 Tesla V100-SXM2... On | 00000000:00:1C.0 Off | 0 || N/A 46C P0 47W / 300W | 0MiB / 16160MiB | 0% Default |+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+| Processes: GPU Memory || GPU PID Type Process name Usage ||=============================================================================|| No running processes found |+-----------------------------------------------------------------------------+

Amazon EKS 最適化 Linux AMI のバージョンこのトピックでは、Amazon EKS 最適化 Linux AMI のバージョンと、それに対応するkubelet、Docker、Linux カーネル、および Packer ビルドスクリプト (p. 76) 設定のバージョンを示します。

Amazon EKS に最適化された AMI メタデータ（例: AMI ID）は、各バリアントをプログラムで取得することができます。詳細については、「Amazon EKS 最適化 AMI ID の取得 (p. 82)」を参照してください。

AMI は、Kubernetes のバージョンと AMI のリリース日によって次の形式でバージョン管理されます。

k8s_major_version.k8s_minor_version.k8s_patch_version-release_date

Amazon EKS 最適化 AMI以下の表は、Amazon EBS 最適化 AMI の現在のバージョンと以前のバージョンを示しています。

Kubernetes version 1.16

AMI のバージョン kubelet バージョン

Docker バージョン

カーネルバージョン

Packer バージョン

1.16.8-20200423 1.16.8 18.09.9-ce 4.14.173 v20200423






1.15.11-20200423 1.15.11 18.09.9-ce 4.14.173 v20200423

1.15.10-20200406 1.15.10 18.09.9-ce 4.14.173 v20200406

1.15.10-20200228 1.15.10 18.09.9-ce 4.14.165 v20200228






1.14.9-20200423 1.14.9 18.09.9-ce 4.14.173 v20200423

79






1.14.9-20200406 1.14.9 18.09.9-ce 4.14.173 v20200406

1.14.9-20200228 1.14.9 18.09.9-ce 4.14.165 v20200228

1.14.9-20200122 1.14.9 18.09.9-ce 4.14.158 v20200122

1.14.8-20191213 1.14.8 18.09.9-ce 4.14.154 v20191213

1.14.7-20191119 1.14.7 18.09.9-ce 4.14.152 v20191119

1.14.7-20190927 1.14.7 18.06.1-ce 4.14.146 v20190927






1.13.12-20200423 1.13.12 18.09.9-ce 4.14.173 v20200423

1.13.12-20200406 1.13.12 18.09.9-ce 4.14.173 v20200406

1.13.12-20200228 1.13.12 18.09.9-ce 4.14.165 v20200228

1.13.12-20200122 1.13.12 18.09.9-ce 4.14.158 v20200122

1.13.12-20191213 1.13.12 18.09.9-ce 4.14.154 v20191213

1.13.11-20191119 1.13.11 18.09.9-ce 4.14.152 v20191119

1.13.11-20190927 1.13.11 18.06.1-ce 4.14.146 v20190927






1.12.10-20200423 1.12.10 18.09.9-ce 4.14.173 v20200423

1.12.10-20200406 1.12.10 18.09.9-ce 4.14.173 v20200406

1.12.10-20200228 1.12.10 18.09.9-ce 4.14.165 v20200228

1.12.10-20200122 1.12.10 18.09.9-ce 4.14.158 v20200122

1.12.10-20191213 1.12.10 18.09.9-ce 4.14.154 v20191213

1.12.10-20191119 1.12.10 18.09.9-ce 4.14.152 v20191119

1.12.10-20190927 1.12.10 18.06.1-ce 4.14.146 v20190927

Amazon EKS 最適化 AMI (GPU 対応)以下の表は、Amazon EBS 最適化 AMI（GPU 対応）の現在のバージョンと以前のバージョンを示しています。

80



AMI のバージョン

kubelet バージョン




Nvidia ドライバーバージョン

1.16.8-202004231.16.8 18.09.9-ce 4.14.173 20200423 418.87.00








1.15.11-202004231.15.11 18.09.9-ce 4.14.173 v20200423 418.87.00

1.15.10-202004061.15.10 18.09.9-ce 4.14.173 v20200406 418.87.00

1.15.10-202002281.15.10 18.09.9-ce 4.14.165 v20200228 418.87.00








1.14.9-202004231.14.9 18.09.9-ce 4.14.173 v20200423 418.87.00

1.14.9-202004061.14.9 18.09.9-ce 4.14.173 v20200406 418.87.00

1.14.9-202002281.14.9 18.09.9-ce 4.14.165 v20200228 418.87.00

1.14.9-202001221.14.9 18.09.9-ce 4.14.158 v20200122 418.87.00

1.14.8-201912131.14.8 18.09.9-ce 4.14.154 v20191213 418.87.00

1.14.7-201911191.14.7 18.09.9-ce 4.14.152 v20191119 418.87.00

1.14.7-201909271.14.7 18.06.1-ce 4.14.146 v20190927 418.87.00








1.13.12-202004231.13.12 18.09.9-ce 4.14.173 v20200423 418.87.00

1.13.12-202004061.13.12 18.09.9-ce 4.14.173 v20200406 418.87.00

1.13.12-202002281.13.12 18.09.9-ce 4.14.165 v20200228 418.87.00

1.13.12-202001221.13.12 18.09.9-ce 4.14.158 v20200122 418.87.00

81

Amazon EKS ユーザーガイドAmazon EKS 最適化 AMI ID の取得







1.13.12-201912131.13.12 18.09.9-ce 4.14.154 v20191213 418.87.00

1.13.11-201911191.13.11 18.09.9-ce 4.14.152 v20191119 418.87.00

1.13.11-201909271.13.11 18.06.1-ce 4.14.146 v20190927 418.87.00








1.12.10-202004231.12.10 18.09.9-ce 4.14.173 v20200423 418.87.00

1.12.10-202004061.12.10 18.09.9-ce 4.14.173 v20200406 418.87.00

1.12.10-202002281.12.10 18.09.9-ce 4.14.165 v20200228 418.87.00

1.12.10-202001221.12.10 18.09.9-ce 4.14.158 v20191119 418.87.00

1.12.10-201912131.12.10 18.09.9-ce 4.14.154 v20191213 418.87.00

1.12.10-201911191.12.10 18.09.9-ce 4.14.152 v20191119 418.87.00

1.12.10-201909271.12.10 18.06.1-ce 4.14.146 v20190927 418.87.00

Amazon EKS 最適化 AMI ID の取得AWS Systems Manager パラメータストア API をクエリすることで、Amazon EKS 最適化 AMI の Amazonマシンイメージ (AMI、Amazon Machine Image) ID をプログラムで取得できます。このパラメータにより、Amazon EKS 最適化 AMI ID を手動で検索する必要がなくなります。Systems Manager パラメータストア API の詳細については、「GetParameter」を参照してください。ユーザーアカウントには、AmazonEKS 最適化 AMI メタデータを取得する ssm:GetParameter IAM アクセス許可が必要です。

AMI ID を取得するツールの名前を選択します。

AWS CLI

サブパラメータ image_id を使用して、次のコマンドで推奨される最新の Amazon EKS 最適化Amazon Linux AMI のイメージ ID を取得できます。1.16 はサポートされているバージョン (p. 52)に置き換え、region-code は AMI ID を必要とする Amazon EKS がサポートされているリージョンに置き換えます。amazon-linux-2 を amazon-linux-2-gpu に置き換えて、GPU ID を持つ AMI を表示します。

aws ssm get-parameter --name /aws/service/eks/optimized-ami/1.16/amazon-linux-2/recommended/image_id --region region-code --query "Parameter.Value" --output text

出力例:

ami-abcd1234efgh5678i

82

https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html


Amazon EKS ユーザーガイドAmazon EKS 最適化 Windows AMI


URL を使用して、Amazon EKS 最適化 AMI ID をクエリできます。URL は、パラメータの ID の値を使用して Amazon EC2 Systems Manager コンソールを開きます。次の URL で、1.16 はサポートされているバージョン (p. 52)に置き換え、us-west-2 は AMI ID を必要とする Amazon EKS がサポートされているリージョンに置き換えます。amazon-linux-2 を amazon-linux-2-gpu に置き換えて、GPU ID を持つ AMI を表示します。

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Feks%252Foptimized-ami%252F1.16%252Famazon-linux-2%252Frecommended%252Fimage_id/description?region=region-code

Amazon EKS 最適化 Windows AMIAmazon EKS 最適化 AMI は Windows Server 2019 上に構築され、Amazon EKS ワーカーノードのベースイメージとして機能するように設定されています。AMI は、設定しなくても Amazon EKS と動作するように設定されており、Docker、kubelet、および AWS IAM オーセンティケーターが含まれています。

Note

Microsoft Security Update Guide を使用して、Windows Server のセキュリティイベントやプライバシーイベントを追跡できます。

最新の Amazon EKS 最適化 AMI の AMI ID を次の表に示します。さまざまなツールを使用して、AWSSystems Manager パラメータで ID を取得することもできます。詳細については、「Amazon EKS 最適化Windows AMI ID の取得 (p. 87)」を参照してください。


リージョン Amazon EKS 用に最適化された WindowsServer 2019 Full

Amazon EKS 用に最適化された WindowsServer 2019 Core


米国東部 (オハイオ)(us-east-2)

AMI ID を表示 AMI ID を表示 AMI ID を表示

米国東部（バージニア北部） (us-east-1)


米国西部 (オレゴン)(us-west-2)


アジアパシフィック(香港) (ap-east-1)


アジアパシフィック (ムンバイ) (ap-south-1)


アジアパシフィック (東京) (ap-northeast-1)


アジアパシフィック (ソウル) (ap-northeast-2)


83



https://portal.msrc.microsoft.com/en-us/security-guidance

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Fami-windows-latest%252FWindows_Server-2019-English-Full-EKS_Optimized-1.16%252Fimage_id/description?region=us-east-2

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Fami-windows-latest%252FWindows_Server-2019-English-Core-EKS_Optimized-1.16%252Fimage_id/description?region=us-east-2





https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Fami-windows-latest%252FWindows_Server-2019-English-Full-EKS_Optimized-1.16%252Fimage_id/description?region=us-west-2

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Fami-windows-latest%252FWindows_Server-2019-English-Core-EKS_Optimized-1.16%252Fimage_id/description?region=us-west-2


https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Fami-windows-latest%252FWindows_Server-2019-English-Full-EKS_Optimized-1.16%252Fimage_id/description?region=ap-east-1

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Fami-windows-latest%252FWindows_Server-2019-English-Core-EKS_Optimized-1.16%252Fimage_id/description?region=ap-east-1


https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Fami-windows-latest%252FWindows_Server-2019-English-Full-EKS_Optimized-1.16%252Fimage_id/description?region=ap-south-1

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Fami-windows-latest%252FWindows_Server-2019-English-Core-EKS_Optimized-1.16%252Fimage_id/description?region=ap-south-1


https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Fami-windows-latest%252FWindows_Server-2019-English-Full-EKS_Optimized-1.16%252Fimage_id/description?region=ap-northeast-1

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Fami-windows-latest%252FWindows_Server-2019-English-Core-EKS_Optimized-1.16%252Fimage_id/description?region=ap-northeast-1









アジアパシフィック(シンガポール) (ap-southeast-1)


アジアパシフィック (シドニー) (ap-southeast-2)


カナダ (中部) (ca-central-1)


欧州 (フランクフルト)(eu-central-1)


欧州 (アイルランド)(eu-west-1)


欧州 (ロンドン) (eu-west-2)


欧州 (パリ) (eu-west-3)


欧州 (ストックホルム)(eu-north-1)




南米 (サンパウロ) (sa-east-1)


中国 (北京) (cn-north-1)


中国 (寧夏) (cn-northwest-1)












84

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Fami-windows-latest%252FWindows_Server-2019-English-Full-EKS_Optimized-1.16%252Fimage_id/description?region=ap-southeast-1

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Fami-windows-latest%252FWindows_Server-2019-English-Core-EKS_Optimized-1.16%252Fimage_id/description?region=ap-southeast-1





https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Fami-windows-latest%252FWindows_Server-2019-English-Full-EKS_Optimized-1.16%252Fimage_id/description?region=ca-central-1

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Fami-windows-latest%252FWindows_Server-2019-English-Core-EKS_Optimized-1.16%252Fimage_id/description?region=ca-central-1


https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Fami-windows-latest%252FWindows_Server-2019-English-Full-EKS_Optimized-1.16%252Fimage_id/description?region=eu-central-1

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Fami-windows-latest%252FWindows_Server-2019-English-Core-EKS_Optimized-1.16%252Fimage_id/description?region=eu-central-1


https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Fami-windows-latest%252FWindows_Server-2019-English-Full-EKS_Optimized-1.16%252Fimage_id/description?region=eu-west-1

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Fami-windows-latest%252FWindows_Server-2019-English-Core-EKS_Optimized-1.16%252Fimage_id/description?region=eu-west-1








https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Fami-windows-latest%252FWindows_Server-2019-English-Full-EKS_Optimized-1.16%252Fimage_id/description?region=eu-north-1

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Fami-windows-latest%252FWindows_Server-2019-English-Core-EKS_Optimized-1.16%252Fimage_id/description?region=eu-north-1


https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Fami-windows-latest%252FWindows_Server-2019-English-Full-EKS_Optimized-1.16%252Fimage_id/description?region=me-south-1

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Fami-windows-latest%252FWindows_Server-2019-English-Core-EKS_Optimized-1.16%252Fimage_id/description?region=me-south-1


https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Fami-windows-latest%252FWindows_Server-2019-English-Full-EKS_Optimized-1.16%252Fimage_id/description?region=sa-east-1

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Fami-windows-latest%252FWindows_Server-2019-English-Core-EKS_Optimized-1.16%252Fimage_id/description?region=sa-east-1


https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Fami-windows-latest%252FWindows_Server-2019-English-Full-EKS_Optimized-1.16%252Fimage_id/description?region=cn-north-1

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Fami-windows-latest%252FWindows_Server-2019-English-Core-EKS_Optimized-1.16%252Fimage_id/description?region=cn-north-1


https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Fami-windows-latest%252FWindows_Server-2019-English-Full-EKS_Optimized-1.16%252Fimage_id/description?region=cn-northwest-1

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Fami-windows-latest%252FWindows_Server-2019-English-Core-EKS_Optimized-1.16%252Fimage_id/description?region=cn-northwest-1















































85






















































































86















































https://console.aws.amazon.com/ystems-manager/parameters/%252Faws%252Fservice%252Fami-windows-latest%252FWindows_Server-2019-English-Core-EKS_Optimized-1.14%252Fimage_id/description?region=me-south-1


Amazon EKS ユーザーガイドAmazon EKS 最適化 Windows AMI ID の取得










Amazon EKS 最適化 Windows AMI ID の取得AWS Systems Manager パラメータストア API をクエリすることで、Amazon EKS 最適化 AMI の Amazonマシンイメージ (AMI、Amazon Machine Image) ID をプログラムで取得できます。このパラメータにより、Amazon EKS 最適化 AMI ID を手動で検索する必要がなくなります。Systems Manager パラメータストア API の詳細については、「GetParameter」を参照してください。ユーザーアカウントには、AmazonEKS 最適化 AMI メタデータを取得する ssm:GetParameter IAM アクセス許可が必要です。

AMI ID を取得するツールの名前を選択します。

AWS CLI

以下のコマンドでサブパラメータ image_id を使用して、推奨される最新の Amazon EKS 最適化Windows AMI のイメージ ID を取得できます。 1.15 は 1.14 に置き換え、region-code は AMI IDを必要とする Amazon EKS がサポートされているリージョンに置き換えることができます。Core をFull に置き換えて、Windows Server の完全な AMI ID を確認します。Core バージョンのみ 2019 を1909 に置き換えることもできます。

aws ssm get-parameter --name /aws/service/ami-windows-latest/Windows_Server-2019-English-Core-EKS_Optimized-1.15/image_id --region region-code --query "Parameter.Value" --output text

出力例:

ami-ami-00a053f1635fffea0


URL を使用して、Amazon EKS 最適化 AMI ID をクエリできます。URL は、パラメータの ID の値を使用して Amazon EC2 Systems Manager コンソールを開きます。次の URL で、1.15 を 1.14に、region-code を AMI ID が必要なAmazon EKS がサポートされているリージョンに置き換えます。Core を Full に置き換えて、Windows Server の完全な AMI ID を確認します。Core バージョンのみ 2019 を 1909 に置き換えることもできます。

https://console.aws.amazon.com/systems-manager/parameters/%252Faws%252Fservice%252Fami-windows-latest%252FWindows_Server-2019-English-Core-EKS_Optimized-1.15%252Fimage_id/description?region=region-code

マネージド型ノードグループAmazon EKS マネージド型ノードグループは、Amazon EKS Kubernetes クラスターのノード（AmazonEC2 インスタンス）のプロビジョニングとライフサイクル管理を自動化します。

87










https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html



Amazon EKS ユーザーガイドマネージド型ノードグループの概念

Note

マネージド型ノードグループ (p. 87) は、Kubernetes バージョン 1.14 およびプラットフォームバージョン (p. 52)で始まる Amazon EKS クラスターでサポートされていますeks.3。既存のクラスターは、この機能を利用するために、バージョン 1.14 以降に更新できます。詳細については、「Amazon EKS クラスターの Kubernetes バージョンの更新 (p. 29)」を参照してください。

Amazon EKS マネージド型ノードグループでは、Kubernetes アプリケーションを実行するためのコンピューティング能力を提供する Amazon EC2 インスタンスを個別にプロビジョニングまたは登録する必要はありません。1 回の操作で、クラスターのノードを作成、更新、または終了できます。ノードは AWSアカウント内で Amazon EKS最適化された AMI を使用して実行され、ノードの更新と終了は、アプリケーションが常に利用できるようにノードを正常にドレーンします。

すべてのマネージド型ノードは、Amazon EKS によって管理される Amazon EC2 Auto Scaling グループの一部としてプロビジョニングされます。インスタンスや Auto Scaling グループを含むすべてのリソースは、AWS アカウント内で実行されます。各ノードグループは、Amazon EKS 最適化された Amazon Linux2 AMI を使用し、定義された複数のアベイラビリティーゾーンで実行できます。

Amazon EKS コンソール、eksctl、AWS CLI、AWS API、または AWS CloudFormation を含むコードツールとしてインフラストラクチャを使用し、新規または既存のクラスターにマネージド型ノードグループを追加できます。マネージド型ノードグループの一部として起動されたノードは、自動的にKubernetes Cluster Autoscaler によって自動検出用にタグ付けされ、ノードグループを使用して、いつでも Kubernetes ラベルのノードへの適用と更新ができます。

Amazon EKS マネージド型ノードグループの使用に追加料金はかかりません。お支払いいただくのはプロビジョニングした AWS リソースの分だけです。これには、Amazon EC2 インスタンス、Amazon EBS ボリューム、Amazon EKS クラスター時間、その他の AWS インフラストラクチャが含まれます。最低料金や前払いの義務は発生しません。

新しい Amazon EKS クラスターおよびマネージド型ノードグループの使用を開始するには、「AWS マネジメントコンソールの使用開始 (p. 10)」を参照してください。

既存のクラスターにマネージド型ノードグループを追加するには、「マネージド型ノードグループの作成 (p. 89)」を参照してください。

マネージド型ノードグループの概念• Amazon EKS マネージド型ノードグループは、Amazon EC2 インスタンスの作成と管理を行います。• すべてのマネージド型ノードは、Amazon EKS によって管理される Amazon EC2 Auto Scaling グループ

の一部としてプロビジョニングされ、Amazon EC2 インスタンスや Auto Scaling グループを含むすべてのリソースは AWS アカウント内で実行されます。

• マネージド型ノードグループの Auto Scaling グループは、グループの作成時に指定するすべてのサブネットにまたがります。

• Amazon EKS は、Kubernetes Cluster Autoscaler (p. 140) を使用するように設定されるようにマネージド型ノードグループリソースをタグ付けします。

Important

Amazon EBS ボリュームによってバックアップされ、Kubernetes Cluster Autoscaler (p. 140)を使用する複数のアベイラビリティーゾーンにわたってステートフルアプリケーションを実行している場合、それぞれが単一のアベイラビリティーゾーンにスコープされる複数のノードグループを設定する必要があります。また、--balance-similar-node-groups 機能を有効にする必要があります。

• マネージド型ノードグループのインスタンスは、クラスターの Kubernetes バージョンに Amazon EKS最適化 Amazon Linux 2 AMI の最新バージョンを使用します。Amazon EKS 最適化 Amazon Linux 2 AMIの標準バリアントおよび GPU バリアントを選択できます。

• Amazon EKS は、マネージド型ノードグループで CVE およびセキュリティパッチの責任共有モデルに従います。マネージド型ノードは Amazon EKS最適化 AMI を実行するため、バグや問題が報告され、

88

Amazon EKS ユーザーガイドマネージド型ノードグループの作成

修正プログラムを公開できる場合、Amazon EKS はこれらの AMI のパッチ適用バージョンの構築を担当します。ただし、これらのパッチが適用された AMI バージョンのマネージド型ノードグループへのデプロイはユーザーが担当します。更新が利用可能になったら、「マネージド型ノードグループの更新 (p. 92)」を参照してください。

• Amazon EKS マネージド型ノードグループは、パブリックサブネットとプライベートサブネットの両方で起動できます。04/22/2020 以降にパブリックサブネットでマネージド型ノードグループを起動した場合、インスタンスがクラスターに正常に参加するには、サブネットで MapPublicIpOnLaunch を trueに設定する必要があります。パブリックサブネットが 03/26/2020 以降に eksctl または Amazon EKSから発行された AWS CloudFormation テンプレート (p. 158)を使用して作成されている場合、この設定はすでに true に設定されています。パブリックサブネットが 03/26/2020 より前に作成されている場合は、設定を手動で変更する必要があります。詳細については、「サブネットの IPv4 アドレス指定属性の変更」を参照してください。

• プライベートサブネットで VPC エンドポイントを使用する場合は、com.amazonaws.region.ecr.api と com.amazonaws.region.ecr.dkr のエンドポイントおよび Amazon S3 のゲートウェイエンドポイントを作成する必要があります。詳細については、「Amazon ECR インターフェイス VPC エンドポイント (AWS PrivateLink)」を参照してください。

• 1 つのクラスター内に複数のマネージド型ノードグループを作成できます。たとえば、一部のワークロード用に標準 Amazon EKS最適化 Amazon Linux 2 AMI を使用するノードグループを作成し、GPUサポートを必要とするワークロード用に GPU バリアントを使用する別のノードグループを作成できます。

• マネージド型ノードグループで正常性の問題が発生した場合は、Amazon EKS から問題の診断に役立つエラーメッセージが返されます。詳細については、「マネージド型ノードグループのエラー (p. 300)」を参照してください。

• Amazon EKS は、マネージド型ノードグループインスタンスに Kubernetes ラベルを追加します。これらの Amazon EKS 提供のラベルには、プレフィックス eks.amazon.com が付きます。

• Amazon EKS は、終了または更新時に Kubernetes API を使用してノードを自動的にドレーンします。更新は、ポッドに設定したポッド中断予算を優先します。

• Amazon EKS マネージド型ノードグループの使用に追加料金はかかりません。お支払いいただくのはプロビジョニングした AWS リソースの分だけです。

マネージド型ノードグループの作成このトピックは、Amazon EKS クラスターに登録されている Linux ワーカーノードの Amazon EKS マネージド型ノードグループの起動に役立ちます。ノードがクラスターに参加したら、それらのノードにKubernetes アプリケーションをデプロイ可能になります。


Amazon EKS マネージド型ノードグループを初めて起動する場合は、代わりに Amazon EKS の開始方法 (p. 3) ガイドに従うことをお勧めします。これらのガイドは、Amazon EKS クラスターとワーカーノードを作成するための完全なエンドツーエンドのチュートリアルを提供します。

Important

Amazon EKS ワーカーノードはスタンダードな Amazon EC2 インスタンスであり、通常のAmazon EC2 価格に基づいて請求されます。詳細については、「Amazon EC2 料金表」を参照してください。



89



https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html#ecr-setting-up-vpc-create



2. Open the Amazon EKS console at https://console.aws.amazon.com/eks/home#/clusters.3. マネージド型ノードグループを作成するクラスターの名前を選択します。4. [クラスター] ページで、[Add node group (ノードグループの追加)] を選択します。5. [Configure node group (ノードグループの設定)] ページで、必要に応じてパラメータを指定し、[次へ]

を選択します。

• [名前] — マネージド型ノードグループの一意の名前を入力します。• [ノード IAM ロール名] — ノードグループで使用するノードインスタンスロールを選択します。詳細

については、「Amazon EKS ワーカーノード IAM ロール (p. 260)」を参照してください。

Important



Important


Important

パブリックサブネットを選択した場合、インスタンスがクラスターに正常に参加するには、そのサブネットの MapPublicIpOnLaunch を true に設定する必要があります。サブネットが 03/26/2020 以降に eksctl または Amazon EKS から発行された AWSCloudFormation テンプレート (p. 158)を使用して作成されている場合、この設定はすでに true に設定されています。サブネットが 03/26/2020 より前に eksctl または AWSCloudFormation テンプレートを使用して作成されている場合は、設定を手動で変更する必要があります。詳細については、「サブネットの IPv4 アドレス指定属性の変更」を参照してください。


Note







90






• [AMI タイプ] — GPU 以外のインスタンスの場合は [Amazon Linux 2 (AL2_x86_64)] を選択し、GPUインスタンスの場合は [Amazon Linux 2 GPU Enabled (AL2_x86_64_GPU) (Amazon Linux 2 GPU有効 (AL2_x86_64_GPU))] を選択します。




Note









ワーカーノードが関連付けられた Amazon EKS クラスターが実行中になったところで、Kubernetes アドオンのインストールとクラスターへのアプリケーションのデプロイを開始できます。以下のトピックは、クラスターの機能を拡張するのに役立ちます。







91




Amazon EKS ユーザーガイドマネージド型ノードグループの更新


マネージド型ノードグループの更新Amazon EKS マネージド型ノードグループのバージョンまたは設定を更新するためのいくつかのユースケースがあります。

• Amazon EKS クラスターの Kubernetes バージョンを更新し、同じ Kubernetes バージョンを使用するようにワーカーノードを更新する場合。

• マネージド型ノードグループでは、新しい AMI リリースバージョンを使用できます。詳細については、「Amazon EKS 最適化 Linux AMI のバージョン (p. 79)」を参照してください。

• マネージド型ノードグループ内のインスタンスの最小数、最大数、または必要な数を調整する場合。• マネージド型ノードグループのインスタンスで Kubernetes ラベルを追加または削除する場合。• マネージド型ノードグループに AWS タグを追加または削除する場合。

マネージド型ノードグループの Kubernetes バージョンに対して、ノードグループが実行しているバージョンよりも新しい AMI リリースバージョンがある場合は、更新して新しい AMI バージョンを使用できます。クラスターがノードグループより新しい Kubernetes バージョンを実行している場合、クラスターの Kubernetes バージョンに一致する最新の AMI リリースバージョンを使用するようにノードグループを更新できます。

Note

ノードグループを以前の Kubernetes バージョンまたは AMI バージョンにロールバックすることはできません。

スケーリングアクションまたは更新によってマネージド型ノードグループ内のノードが終了すると、そのノードのポッドが最初にドレーンされます。詳細については、「マネージド型ノードの更新動作 (p. 94)」を参照してください。

ノードグループバージョンの更新バージョンをアップグレードするツールの名前が付いたタブを選択します。


ノードグループバージョンを更新するには

1. https://console.aws.amazon.com/eks/home#/clusters にある Amazon EKS コンソールを開きます。

2. 更新するノードグループを含むクラスターを選択します。3. 少なくとも 1 つのノードグループで更新が利用可能な場合は、クラスター名の下に通知が表示さ

れ、更新が利用可能なノードグループの数を知らせます。[Node Groups (ノードグループ)] テーブルで、更新可能な各ノードグループの [AMI リリースバージョン] 列の値の右側に [Update now(今すぐ更新)] と表示されます。更新するノードグループに対して、[Update now (今すぐ更新)] を選択します。

テーブルからノードグループを選択し、そのノードに対する更新が利用可能である場合、[NodeGroup configuration (ノードグループの設定) ページに通知が表示されます。その場合は、[NodeGroup configuration (ノードグループの設定)] ページで [Update now (今すぐ更新)] ボタンを選択できます。

92


Amazon EKS ユーザーガイドマネージド型ノードグループの更新

Note

[Update now (今すぐ更新)] は、利用可能な更新がある場合にのみ表示されます。このテキストが表示されない場合は、ノードグループは使用可能な最新バージョンを実行しています。

4. [AMI リリースバージョンの更新] ページで、更新先の [利用可能な AMI リリースバージョン] を選択し、[Update strategy (更新戦略)] で次のいずれかのオプションを選択して、[Update (更新)] を選択します。

• [ローリング更新] — このオプションは、クラスターのポッド中断予算を優先し、Amazon EKSがポッド中断予算の問題によりこのノードグループで実行されているポッドを正常にドレーンできない場合、更新は失敗します。

• [強制更新] — このオプションは、ポッド中断予算を優先せず、強制的にノードを再起動します。

eksctl

次のコマンドを使用して、マネージド型ノードグループを、ワーカーノードに現在デプロイされているのと同じ Kubernetes バージョンの最新 AMI リリースにアップグレードします。

eksctl upgrade nodegroup --name=node-group-name --cluster=cluster-name

ノードグループは、ノードグループの現在の Kubernetes バージョンよりメジャーリリースが 1 つ後のバージョン以降 (クラスターの Kubernetes バージョンまで) にアップグレードできます。たとえば、Kubernetes 1.16 を実行しているクラスターがある場合、次のコマンドを使用して、現在Kubernetes 1.15 を実行しているワーカーをバージョン 1.16 にアップグレードできます。

eksctl upgrade nodegroup --name=node-group-name --cluster=cluster-name --kubernetes-version=1.16

ノードグループ設定の編集マネージド型ノードグループの設定の一部を変更できます。

ノードグループ設定を編集するには

1. https://console.aws.amazon.com/eks/home#/clusters にある Amazon EKS コンソールを開きます。2. 編集するノードグループを含むクラスターを選択します。3. 編集するノードグループを選択し、[編集] を選択します。4. 必要に応じて、[Edit node group (ノードグループの編集)] ページで [グループ設定] を編集します。

• [タグ] — ノードグループリソースにタグを追加または削除します。これらのタグは Amazon EKSノードグループにのみ適用され、ノードグループ内のサブネットや Amazon EC2 インスタンスなどの他のリソースには伝達されません。

• [Kubernetes labels (Kubernetes ラベル)] — ノードグループ内のノードに Kubernetes ラベルを追加または削除します。ここに示すラベルは、Amazon EKS で適用したラベルのみです。ここには表示されていない他のラベルがノードに存在する可能性があります。

5. [Edit node group (ノードグループの編集)] ページで、必要に応じて [Group size (グループサイズ)] を編集します。

• [最小サイズ] — マネージド型ノードグループが保持する必要があるワーカーノードの現在の数を指定します。

93


Amazon EKS ユーザーガイドマネージド型ノードグループの削除

• [最大サイズ] — マネージド型ノードグループがスケールアウトできるワーカーノードの最大数を指定します。マネージド型ノードグループは、デフォルトで最大 100 個のノードをサポートできます。

• [必要なサイズ] — マネージド型ノードグループが保持する必要があるワーカーノードの現在の数を指定します。

6. 編集が終了したら、[Save changes (変更の保存)] を選択します。

マネージド型ノードの更新動作マネージド型ノードグループのバージョンをノードグループの Kubernetes バージョンの最新の AMIリリースバージョンに更新するか、クラスターに合わせて新しい Kubernetes バージョンに更新すると、Amazon EKS により次のロジックがトリガーされます。

1. Amazon EKS は、ノードグループに関連付けられた Auto Scaling グループの新しい Amazon EC2 起動テンプレートバージョンを作成します。新しいテンプレートでは、更新にターゲット AMI が使用されます。

2. Auto Scaling グループが更新され、新しい AMI で最新の起動テンプレートが使用されます。3. Auto Scaling グループの最大サイズと必要なサイズは、ノードグループの各アベイラビリティーゾーン

で少なくとも 1 つの新しいインスタンスが起動するように、Auto Scaling グループの別個のアベイラビリティーゾーンの数の 2 倍ずつ増加します。

4. Auto Scaling グループは、ノードグループの増加した必要なサイズを満たすために、新しい AMI を使用して新しいインスタンスを起動します。

5. Amazon EKS はノードグループ内のノードで eks.amazonaws.com/nodegroup-image ラベルをチェックし、最新の AMI ID でラベル付けされていないノードグループ内のすべてのノードを遮断します。これにより、以前に失敗した更新から既に更新されているノードが遮断されるのを回避します。

6. Amazon EKS はノードグループ内のノードをランダムに選択し、Auto Scaling グループに終了シグナルを送信します。その後で、Amazon EKS はノードからポッドをドレーンするためのシグナルを送信します。* ノードがドレーンされると、ノードは終了します。このステップは、すべてのノードが新しいAMI バージョンを使用するまで繰り返されます。

7. Auto Scaling グループの最大サイズと必要なサイズが 1 ずつ減少し、更新前の値に戻ります。

* ポッドがノードから 15 分間ドレーンされない場合（たとえば、ポッド中断予算が過度に制限的である場合）、次の 2 つのうちいずれかが発生します。

• 更新が強制されていない場合、更新は失敗し、エラーが報告されます。• 更新が強制されている場合、ドレーンできなかったポッドは削除されます。

マネージド型ノードグループの削除このトピックでは、Amazon EKS マネージド型ノードグループを削除する方法について説明します。

マネージド型ノードグループを削除すると、Amazon EKS はノードグループ内のノードをランダムに選択し、Auto Scaling グループに終了シグナルを送信します。次に、Amazon EKS がノードからポッドをドレーンするシグナルを送信します。ポッドがノードから 15 分間ドレーンされない場合（たとえば、ポッドの中断予算が過度に制限的である場合）、ポッドは削除されます。ノードがドレーンされた後、ノードは終了します。このステップは、Auto Scaling グループ内のすべてのノードが終了し、Auto Scaling グループが削除されるまで繰り返されます。

Important

クラスター内の他のマネージドノードグループで使用されていないワーカーノード IAMロールを使用するマネージドノードグループを削除すると、そのロールは aws-auth

94

Amazon EKS ユーザーガイドAmazon EKS Linux ワーカーノードの起動

ConfigMap (p. 202) から削除されます。クラスター内のいずれかのセルフマネージドノードグループが同じワーカーノード IAM ロールを使用している場合、セルフマネージドノードはNotReady ステータスに移行し、クラスター操作は中断されます。このマッピングを ConfigMapに追加して、中断を最小限に抑えることができます。

マネージド型ノードグループを削除するには

1. https://console.aws.amazon.com/eks/home#/clusters にある Amazon EKS コンソールを開きます。2. 削除するノードグループを含むクラスターを選択します。3. 削除するノードグループを選択し、[削除] を選択します。4. [ ノノノノノノノの削除] ページで、テキストフィールドにクラスターの名前を入力し、[確認] を選択しま

す。

Amazon EKS Linux ワーカーノードの起動このトピックは、Amazon EKS クラスターに登録されている Linux ワーカーノードの Auto Scaling グループの起動に役立ちます。ノードがクラスターに参加したら、それらのノードに Kubernetes アプリケーションをデプロイ可能になります。

Amazon EKS Linux ワーカーノードを初めて起動する場合は、代わりに Amazon EKS の開始方法 (p. 3) ガイドに従うことをお勧めします。これらのガイドは、Amazon EKS クラスターとワーカーノードを作成するための完全なエンドツーエンドのチュートリアルを提供します。

Important


以下から必要なワーカーノード作成方法に対応するタブを選択します。

Amazon EKS managed node groups




2. Open the Amazon EKS console at https://console.aws.amazon.com/eks/home#/clusters.3. マネージド型ノードグループを作成するクラスターの名前を選択します。4. [クラスター] ページで、[Add node group (ノードグループの追加)] を選択します。5. [Configure node group (ノードグループの設定)] ページで、必要に応じてパラメータを指定し、

[次へ] を選択します。

• [名前] — マネージド型ノードグループの一意の名前を入力します。• [ノード IAM ロール名] — ノードグループで使用するノードインスタンスロールを選択します。

詳細については、「Amazon EKS ワーカーノード IAM ロール (p. 260)」を参照してください。

95





Important



Important


Important

パブリックサブネットを選択した場合、インスタンスがクラスターに正常に参加するには、そのサブネットの MapPublicIpOnLaunch を true に設定する必要があります。サブネットが 03/26/2020 以降に eksctl または Amazon EKS から発行されたAWS CloudFormation テンプレート (p. 158)を使用して作成されている場合、この設定はすでに true に設定されています。サブネットが 03/26/2020 より前に eksctl または AWS CloudFormation テンプレートを使用して作成されている場合は、設定を手動で変更する必要があります。詳細については、「サブネットの IPv4 アドレス指定属性の変更」を参照してください。


Note








• [AMI タイプ] — GPU 以外のインスタンスの場合は [Amazon Linux 2 (AL2_x86_64)] を選択し、GPU インスタンスの場合は [Amazon Linux 2 GPU Enabled (AL2_x86_64_GPU) (AmazonLinux 2 GPU 有効 (AL2_x86_64_GPU))] を選択します。

96








Note









eksctl

eksctl を使用してワーカーノードを起動するには


eksctl version


Note


1. 以下のコマンドを使用して、ワーカーノードグループを作成します。example の値は独自の値に置き換えます。

eksctl create nodegroup \--cluster default \--version auto \--name standard-workers \

97



--node-type t3.medium \--node-ami auto \--nodes 3 \--nodes-min 1 \--nodes-max 4

Note

eksctl create nodegroup の使用可能なオプションの詳細については、GitHub のREADME プロジェクトを参照するか、以下のコマンドでヘルプページを参照してください。

eksctl create nodegroup --help

出力:

ワーカーノードが作成されると、複数の行の出力が表示されます。出力の最後の行は、次のサンプル行のようになります。

[✓] all nodegroups have up-to-date configuration

2. (オプション) ゲストブックアプリケーションを起動する (p. 208) — サンプルアプリケーションをデプロイして、クラスターと Linux ワーカーノードをテストします。

Self-managed nodes

これらの手順には、以下の前提条件があります。

• Amazon EKS クラスターの要件を満たす VPC およびセキュリティグループを作成済みです。詳細については、「クラスター VPC に関する考慮事項 (p. 161)」および「Amazon EKS セキュリティグループの考慮事項 (p. 164)」を参照してください。Amazon EKS の開始方法 (p. 3) ガイドでは、要件を満たす VPC を作成します。または、「Amazon EKS クラスター用の VPC の作成 (p. 158)」に従って、手動で作成することもできます。

• Amazon EKS クラスターを作成し、Amazon EKS クラスターの要件を満たす VPC とセキュリティグループを使用するように指定しました。詳細については、「Amazon EKS クラスターの作成 (p. 22)」を参照してください。

AWS マネジメントコンソールを使用してセルフマネージド型ワーカーノードを起動するには

1. クラスターステータスが ACTIVE と表示されるまで待ちます。クラスターがアクティブである前にワーカーノードを起動した場合、ワーカーノードはクラスターへの登録に失敗し、再起動する必要があります。

2. https://console.aws.amazon.com/cloudformation で AWS CloudFormation コンソールを開きます3. [スタックの作成] を選択します。4. [Specify template (テンプレートの指定)] で、 [Amazon S3 URL] を選択し、次の URL をコピーし

て、[Amazon S3 URL] に貼り付けて、[Next (次へ) ] を 2 回選択します。


5. Quick create stack ページで、必要に応じて以下のパラメータを入力します。

• Stack name: AWS CloudFormation スタックのスタック名を選択します。たとえば、<cluster-name>- ワーカーノードと呼ぶことができます。

• ClusterName: Amazon EKS クラスター用に作成した際に使用した名前を入力します。

98





Important


• ClusterControlPlaneSecurityGroup: 「Amazon EKS クラスター VPC を作成する (p. 12)」で生成した AWS CloudFormation 出力の [SecurityGroups] 値を選択します。

• NodeGroupName: ノードグループの名前を入力します。この名前は、ワーカーノードに対して作成される Auto Scaling ノードグループを識別するために後で使用できます。

• NodeAutoScalingGroupMinSize: ワーカーノードの Auto Scaling グループがスケールインする最小ノード数を入力します。

• NodeAutoScalingGroupDesiredCapacity: スタック作成時にスケーリングする必要のあるノード数を入力します。

• NodeAutoScalingGroupMaxSize: ワーカーノードの Auto Scaling グループがスケールアウトする最大ノード数を入力します。

• NodeInstanceType: ワーカーノードのインスタンスタイプを選択します。

Note

最新バージョンの Amazon VPC CNI Plugin for Kubernetes でサポートされているインスタンスタイプをこちらに示します。サポートされている最新のインスタンスタイプを利用するには、CNI のバージョンを更新する必要があります。詳細については、「Amazon VPC CNI Plugin for Kubernetes のアップグレード (p. 182)」を参照してください。

Important

リージョンによっては利用できないインスタンスタイプがあります。• NodeImageIdSSMParam: 現在推奨されている、 Amazon EKS が最適化された Linux AMI ID

の Amazon EC2 Systems Manager パラメータが事前に入力されています。GPU で AMI を使用する場合は、amazon-linux-2 を amazon-linux-2-gpu に置き換えます。AmazonEKS でサポートされている別の Kubernetes マイナーバージョンを使用する場合は、1.16 を1.15、1.14、または 1.13 に置き換えることができます。

Note

Amazon EKS ワーカーノード AMI は、Amazon Linux 2 に基づいています。AmazonLinux 2 のセキュリティまたはプライバシーイベントは、Amazon Linux セキュリティセンターで追跡するか、関連付けられた RSS フィードでサブスクライブできます。セキュリティおよびプライバシーイベントには、問題の概要、影響を受けるパッケージ、および問題を修正するためにインスタンスを更新する方法などがあります。

• NodeImageId: （オプション）（Amazon EKS 最適化 AMI の代わりに）独自のカスタム AMI を使用している場合は、リージョンのワーカーノード AMI ID を入力します。ここで値を指定すると、 NodeImageIdSSMParam フィールドの値はすべて上書きされます。

• NodeVolumeSize: ワーカーノードのルートボリュームサイズを GiB 単位で指定します。• KeyName: 起動後に、SSH を使用してワーカーノードに接続するときに使用できる Amazon

EC2 SSH キーペアの名前を入力します。Amazon EC2 キーペアをまだ持っていない場合は、AWS マネジメントコンソールで作成できます。詳細については、『Linux インスタンス用Amazon EC2 ユーザーガイド』の「Amazon EC2 キーペア」を参照してください。

Note

ここでキーペアを与えないと、AWS CloudFormation スタックの作成は失敗します。• BootstrapArguments: kubelet の追加引数など、ワーカーノードブートストラップスクリプト

に渡すオプションの引数を指定します。詳細については、https://github.com/awslabs/amazon-99

https://github.com/aws/amazon-vpc-cni-k8s

https://github.com/aws/amazon-vpc-cni-k8s/blob/release-1.6/pkg/awsutils/vpc_ip_resource_limit.go







eks-ami/blob/master/files/bootstrap.sh でブートストラップスクリプトの使用情報を参照してください。

• VpcId: 「Amazon EKS クラスター VPC を作成する (p. 12)」で作成した VPC の ID を入力します。

• Subnets (サブネット): 「Amazon EKS クラスター VPC を作成する (p. 12)」で作成したサブネットを選択します。Amazon EKS クラスター用の VPC の作成 (p. 158) で説明されているステップを使用して VPC を作成した場合は、ワーカーノードの VPC 内で、起動するプライベートサブネットのみを指定します。

Important

いずれかのサブネットがパブリックサブネットである場合は、パブリック IP アドレスの自動割り当て設定を有効にする必要があります。この設定がパブリックサブネットに対して有効になっていない場合、そのパブリックサブネットにデプロイするワーカーノードにはパブリック IP アドレスが割り当てられず、クラスターやその他のAWS のサービスと通信できなくなります。Amazon EKS AWS CloudFormationVPCテンプレート (p. 158)のいずれかを使用して 03/26/2020 以前に、または eksctl を使用してサブネットがデプロイされた場合、パブリックサブネットではパブリック IPアドレスの自動割り当てが無効になります。サブネットのパブリック IP アドレス割り当てを有効にする方法については、「サブネットのパブリック IPv4 アドレス属性の変更」を参照してください。ワーカーノードがプライベートサブネットにデプロイされている場合、NAT ゲートウェイを介してクラスターや他の AWS のサービスと通信できます。

6. スタックが IAM リソースを作成する可能性があることを確認し、[スタックの作成] を選択します。

7. スタックの作成が完了したら、コンソールで選択し、[出力] を選択します。8. 作成されたノードグループの [NodeInstanceRole] を記録します。これは、Amazon EKS ワーカー

ノードを設定する際、必要になります。

ワーカーノードをクラスターと結合するには

1. AWS IAM オーセンティケーター設定マップをダウンロード、編集、適用します。


curl -o aws-auth-cm.yaml https://amazon-eks.s3.us-west-2.amazonaws.com/cloudformation/2020-04-21/aws-auth-cm.yaml

b. 任意のテキストエディタでファイルを開きます。インスタンスロールの <イイイイイイイイイイイARN (イイイイイイイイイイイイイイイイ)> スニペットを、前の手順で記録した [NodeInstanceRole] の値に置き換え、ファイルを保存します。

Important


apiVersion: v1kind: ConfigMapmetadata: name: aws-auth namespace: kube-systemdata: mapRoles: | - rolearn: <ARN of instance role (not instance profile)> username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers

100




Amazon EKS ユーザーガイドAmazon EKS Windows ワーカーノードの起動

- system:nodes



Note

"aws-iam-authenticator": executable file not found in $PATH エラーが発生した場合、kubectl は、Amazon EKS に設定されていません。詳細については、「aws-iam-authenticator のインストール (p. 196)」を参照してください。その他の認可またはリソースタイプのエラーが発生した場合は、トラブルシューティングセクションの許可されていないか、アクセスが拒否されました(kubectl) (p. 299) を参照してください。





4. (オプション) ゲストブックアプリケーションを起動する (p. 208) — サンプルアプリケーションをデプロイして、クラスターと Linux ワーカーノードをテストします。

Amazon EKS Windows ワーカーノードの起動このトピックは、Amazon EKS クラスターに登録されている Windows ワーカーノードの Auto Scalingグループの起動に役立ちます。ノードがクラスターに参加したら、それらのノードに Kubernetes アプリケーションをデプロイ可能になります。

Important


クラスターに対して Windows サポートを有効にする必要があります。Windows ワーカーノードグループを起動する前に、重要な考慮事項を確認することをお勧めします。詳細については、「Windows サポートの有効化 (p. 59)」を参照してください。

以下から必要なワーカーノード作成方法に対応するタブを選択します。

eksctl

Windows ワーカーノードグループを追加する先の Amazon EKS クラスターと Linux ワーカーノードグループがまだない場合は、代わりに eksctl の開始方法 (p. 3) ガイドに従うことをお勧めします。これらのガイドは、Linux および Windows ワーカーノードで Amazon EKS クラスターを作成するための完全なエンドツーエンドのチュートリアルを提供します。Windows ワーカーノードグループを追加する先の Amazon EKS クラスターと Linux ワーカーノードグループがすでにある場合は、以下の手順を実行して Windows ワーカーノードグループを追加します。

101




eksctl を使用して Windows ワーカーノードを起動するには


eksctl version


Note


1. 以下のコマンドを使用して、ワーカーノードグループを作成します。example の値は独自の値に置き換えます。

eksctl create nodegroup \--region region-code \--cluster windows \--name windows-ng \--node-type t2.large \--nodes 3 \--nodes-min 1 \--nodes-max 4 \--node-ami-family WindowsServer2019FullContainer

Note

eksctl create nodegroup の使用可能なオプションの詳細については、GitHub のREADME プロジェクトを参照するか、以下のコマンドでヘルプページを参照してください。

eksctl create nodegroup --help

出力:

ワーカーノードが作成されると、複数の行の出力が表示されます。出力の最後の行は、次のサンプル行のようになります。

[✓] all nodegroups have up-to-date configuration

2. (オプション) Windows サンプルアプリケーションをデプロイする (p. 63) — サンプルアプリケーションをデプロイして、クラスターと Windows ワーカーノードをテストします。


AWS マネジメントコンソールを使用してワーカーノードを起動するには

これらの手順には、以下の前提条件があります。

• 既存の Amazon EKS クラスターと Linux ワーカーノードグループがある。これらのリソースがない場合は、Amazon EKS の開始方法 (p. 3) ガイドのいずれかに従って作成することをお勧めします。これらのガイドは、Linux ワーカーノードで Amazon EKS クラスターを作成するための完全なエンドツーエンドのチュートリアルを提供します。

• Amazon EKS クラスターの要件を満たす VPC およびセキュリティグループを作成済みです。詳細については、「クラスター VPC に関する考慮事項 (p. 161)」および「Amazon EKS セキュリティグループの考慮事項 (p. 164)」を参照してください。Amazon EKS の開始方法 (p. 3) ガイ

102




ドでは、要件を満たす VPC を作成します。または、「Amazon EKS クラスター用の VPC の作成 (p. 158)」に従って、手動で作成することもできます。

1. クラスターステータスが ACTIVE と表示されるまで待ちます。クラスターがアクティブである前にワーカーノードを起動した場合、ワーカーノードはクラスターへの登録に失敗し、再起動する必要があります。

2. https://console.aws.amazon.com/cloudformation で AWS CloudFormation コンソールを開きます3. [スタックの作成] を選択します。4. [Specify template (テンプレートの指定)] で、 [Amazon S3 URL] を選択し、次の URL をコピーし

て、[Amazon S3 URL] に貼り付けて、[Next (次へ) ] を 2 回選択します。

https://amazon-eks.s3.us-west-2.amazonaws.com/cloudformation/2020-04-21/amazon-eks-windows-nodegroup.yaml

5. Quick create stack ページで、必要に応じて以下のパラメータを入力します。

• Stack name: AWS CloudFormation スタックのスタック名を選択します。たとえば、cluster-name-worker-nodes と呼ぶことができます。

• ClusterName: Amazon EKS クラスター用に作成した際に使用した名前を入力します。

Important


• ClusterControlPlaneSecurityGroup: 「Amazon EKS クラスター VPC を作成する (p. 12)」で生成した AWS CloudFormation 出力の [SecurityGroups] 値を選択します。

• NodeGroupName: ノードグループの名前を入力します。この名前は、ワーカーノードに対して作成される Auto Scaling ノードグループを識別するために後で使用できます。

• NodeAutoScalingGroupMinSize: ワーカーノードの Auto Scaling グループがスケールインする最小ノード数を入力します。

• NodeAutoScalingGroupDesiredCapacity: スタック作成時にスケーリングする必要のあるノード数を入力します。

• NodeAutoScalingGroupMaxSize: ワーカーノードの Auto Scaling グループがスケールアウトする最大ノード数を入力します。

• NodeInstanceType: ワーカーノードのインスタンスタイプを選択します。

Note

最新バージョンの Amazon VPC CNI Plugin for Kubernetes でサポートされているインスタンスタイプをこちらに示します。サポートされている最新のインスタンスタイプを利用するには、CNI のバージョンを更新する必要があります。詳細については、「Amazon VPC CNI Plugin for Kubernetes のアップグレード (p. 182)」を参照してください。

Important

リージョンによっては利用できないインスタンスタイプがあります。• NodeImageIdSSMParam: 現在推奨されている、 Amazon EKS が最適化された Windows Core

AMI ID の Amazon EC2 Systems Manager パラメータが事前に入力されています。Windows の通常版を使用する場合、Core は Full に置き換えます。

• NodeImageId: （オプション）（Amazon EKS 最適化 AMI の代わりに）独自のカスタム AMI を使用している場合は、リージョンのワーカーノード AMI ID を入力します。ここで値を指定すると、 NodeImageIdSSMParam フィールドの値はすべて上書きされます。

• NodeVolumeSize: ワーカーノードのルートボリュームサイズを GiB 単位で指定します。103





• KeyName: 起動後に、SSH を使用してワーカーノードに接続するときに使用できる AmazonEC2 SSH キーペアの名前を入力します。Amazon EC2 キーペアをまだ持っていない場合は、AWS マネジメントコンソールで作成できます。詳細については、『Windows インスタンスの Amazon EC2 ユーザーガイド』の「Amazon EC2 キーペア」を参照してください。

Note

ここでキーペアを与えないと、AWS CloudFormation スタックの作成は失敗します。• BootstrapArguments: -KubeletExtraArgs を使用して、kubelet の追加引数など、ワーカー

ノードブートストラップスクリプトに渡すオプションの引数を指定します。• VpcId: 「Amazon EKS クラスター VPC を作成する (p. 12)」で作成した VPC の ID を選択しま

す。• NodeSecurityGroups: 「Amazon EKS クラスター VPC を作成する (p. 12)」で Linux ワーカー

ノードグループ用に作成したセキュリティグループを選択します。Linux ワーカーノードに複数のセキュリティグループがアタッチされている場合 (Linux ワーカーノードグループがeksctl で作成された場合など)、それらのグループのすべてをここで指定します。

• Subnets (サブネット): 「Amazon EKS クラスター VPC を作成する (p. 12)」で作成したサブネットを選択します。Amazon EKS クラスター用の VPC の作成 (p. 158) で説明されているステップを使用して VPC を作成した場合は、ワーカーノードの VPC 内で、起動するプライベートサブネットのみを指定します。

Important

いずれかのサブネットがパブリックサブネットである場合は、パブリック IP アドレスの自動割り当て設定を有効にする必要があります。この設定がパブリックサブネットに対して有効になっていない場合、そのパブリックサブネットにデプロイするワーカーノードにはパブリック IP アドレスが割り当てられず、クラスターやその他のAWS のサービスと通信できなくなります。Amazon EKS AWS CloudFormationVPCテンプレート (p. 158)のいずれかを使用して 03/26/2020 以前に、または eksctl を使用してサブネットがデプロイされた場合、パブリックサブネットではパブリック IPアドレスの自動割り当てが無効になります。サブネットのパブリック IP アドレス割り当てを有効にする方法については、「サブネットのパブリック IPv4 アドレス属性の変更」を参照してください。ワーカーノードがプライベートサブネットにデプロイされている場合、NAT ゲートウェイを介してクラスターや他の AWS のサービスと通信できます。

6. スタックが IAM リソースを作成する可能性があることを確認し、[スタックの作成] を選択します。

7. スタックの作成が完了したら、コンソールで選択し、[出力] を選択します。8. 作成されたノードグループの [NodeInstanceRole] を記録します。これは、Amazon EKS Windows

ワーカーノードを設定するときに必要になります。

ワーカーノードをクラスターと結合するには

1. AWS IAM オーセンティケーター設定マップをダウンロード、編集、適用します。


curl -o aws-auth-cm-windows.yaml https://amazon-eks.s3.us-west-2.amazonaws.com/cloudformation/2020-04-21/aws-auth-cm-windows.yaml

b. 任意のテキストエディタでファイルを開きます。<ARN of instance role (notinstance profile) of **Linux** worker node> および <ARN of instancerole (not instance profile) of **Windows** worker node> のスニペットを、Linux および Windows ワーカーノード用に記録した NodeInstanceRole の値に置き換え、ファイルを保存します。

104

https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html



Amazon EKS ユーザーガイドセルフマネージド型ワーカーノードの更新

Important


apiVersion: v1kind: ConfigMapmetadata: name: aws-auth namespace: kube-systemdata: mapRoles: | - rolearn: <ARN of instance role (not instance profile) of **Linux** worker node> username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes - rolearn: <ARN of instance role (not instance profile) of **Windows** worker node> username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes - eks:kube-proxy-windows


kubectl apply -f aws-auth-cm-windows.yaml

Note

"aws-iam-authenticator": executable file not found in $PATH エラーが発生した場合、kubectl は、Amazon EKS に設定されていません。詳細については、「aws-iam-authenticator のインストール (p. 196)」を参照してください。その他の認可またはリソースタイプのエラーが発生した場合は、トラブルシューティングセクションの許可されていないか、アクセスが拒否されました(kubectl) (p. 299) を参照してください。



3. (オプション) Windows サンプルアプリケーションをデプロイする (p. 63) — サンプルアプリケーションをデプロイして、クラスターと Windows ワーカーノードをテストします。

セルフマネージド型ワーカーノードの更新新しい Amazon EKS で最適化された AMI がリリースされたら、セフルマネージドワーカーノードグループのノードを新しい AMI に置き換えることを検討する必要があります。同様に、Amazon EKS クラスターの Kubernetes バージョンを更新した場合は、ワーカーノードを更新して、同じ Kubernetes バージョンのワーカーノードを使用する必要があります。

Important

このトピックでは、セルフマネージド型ノードグループのワーカーノードの更新について説明します。マネージド型ノードグループ (p. 87) を使用している場合は、「マネージド型ノードグループの更新 (p. 92)」を参照してください。

105

Amazon EKS ユーザーガイド新しいワーカーノードグループへの移行

クラスター内のセルフマネージド型ノードグループを更新して新しい AMI を使用するには、2 つの基本的な方法があります。

• the section called “新しいワーカーノードグループへの移行” (p. 106) – 新しいワーカーノードグループを作成し、ポッドをそのグループに移行します。既存の AWS CloudFormation スタックの AMI ID を単に更新するよりも、新しいワーカーノードグループに移行することをお勧めします。移行する方法では、NoSchedule として古いノードグループを taint に設定し、既存のポッドのワークロードが新しいスタックで受け入れるようになると、それらのノードは解放されるためです。

• the section called “既存のワーカーノードグループの更新” (p. 111) – 既存のワーカーノードグループの AWS CloudFormation スタックを更新して、新しい AMI が使用されるようにします。この方法は、eksctl を使用して作成されたワーカーノードグループではサポートされていません。

新しいワーカーノードグループへの移行このトピックは、新しいワーカーノードグループを作成し、既存のアプリケーションを新しいグループに適切に移行した後、クラスターから古いワーカーノードグループを削除する場合に役立ちます。

eksctl

eksctl を使用してアプリケーションを新しいワーカーノードグループに移行するには


eksctl version


Note

この手順は、eksctl で作成されたクラスターおよびワーカーノードグループに対してのみ機能します。

1. 既存のワーカーノードグループの名前を取得します。default は実際のクラスター名に置き換えてください。

eksctl get nodegroups --cluster=default

出力:

CLUSTER NODEGROUP CREATED MIN SIZE MAX SIZE DESIRED CAPACITY INSTANCE TYPE IMAGE IDdefault standard-workers 2019-05-01T22:26:58Z 1 4 3 t3.medium ami-05a71d034119ffc12

2. 以下のコマンドを使用して、eksctl で新しいワーカーノードグループを起動します。exampleの値は独自の値に置き換えてください。

Note

利用可能なフラグとその説明については、https://eksctl.io/ を参照してください。

eksctl create nodegroup \--cluster default \--version 1.16 \--name standard-workers-new \--node-type t3.medium \

106

https://eksctl.io/


--nodes 3 \--nodes-min 1 \--nodes-max 4 \--node-ami auto

3. 前のコマンドが完了したら、以下のコマンドを使用して、すべてのワーカーノードが Ready 状態になったことを確認します。

kubectl get nodes

4. 以下のコマンドを使用して、元のノードグループを削除します。example の値は実際のクラスター名とノードグループ名に置き換えてください。

eksctl delete nodegroup --cluster default --name standard-workers


AWS マネジメントコンソールを使用してアプリケーションを新しいワーカーノードグループに移行するには

1. 新しいワーカーノードグループを起動するには、「Amazon EKS Linux ワーカーノードの起動 (p. 95)」の手順に従います。

2. スタックの作成が完了したら、コンソールで選択し、[出力] を選択します。3. 作成されたノードグループの [NodeInstanceRole] を記録します。Amazon EKS ワーカーノードを

クラスターに追加するには、これが必要です。

Note

さらに IAM ポリシーを古いノードグループの IAM ロールにアタッチした場合(Kubernetes Cluster Autoscaler に対するアクセス許可を追加する場合など) は、この同じポリシーを新しいノードグループの IAM ロールにアタッチして、新しいグループでその機能を管理する必要があります。

4. 相互通信できるように、両方のワーカーノードグループのセキュリティグループを更新します。詳細については、「Amazon EKS セキュリティグループの考慮事項 (p. 164)」を参照してください。

a. 両方のワーカーノードグループのセキュリティグループ ID を記録します。これは、AWSCloudFormation スタック出力の [NodeSecurityGroup] 値として示されます。

次の AWS CLI コマンドを使用して、スタック名からセキュリティグループ ID を取得します。これらのコマンドで、oldNodes は、古いワーカーノードスタックの AWSCloudFormation スタック名、newNodes は、移行先のスタックの名前を表します。

oldNodes="<old_node_CFN_stack_name>"newNodes="<new_node_CFN_stack_name>"

oldSecGroup=$(aws cloudformation describe-stack-resources --stack-name $oldNodes \--query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \--output text)newSecGroup=$(aws cloudformation describe-stack-resources --stack-name $newNodes \--query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \--output text)

107



b. 互いにトラフィックを受け入れるように、各ワーカーノードのセキュリティグループに進入ルールを追加します。

以下の AWS CLI コマンドでは、他のセキュリティグループからのすべてのプロトコルのトラフィックをすべて許可するイングレスルールを各セキュリティグループに追加します。これにより、ワークロードを新しいグループに移行している間に、各ワーカーノードグループ内のポッドは相互に通信できるようになります。

aws ec2 authorize-security-group-ingress --group-id $oldSecGroup \--source-group $newSecGroup --protocol -1aws ec2 authorize-security-group-ingress --group-id $newSecGroup \--source-group $oldSecGroup --protocol -1

5. aws-auth configmap を編集して、新しいワーカーノードインスタンスロールを RBAC にマッピングします。

kubectl edit configmap -n kube-system aws-auth

新しいワーカーノードグループの新しい mapRoles エントリを追加します。

apiVersion: v1data: mapRoles: | - rolearn: <ARN of instance role (not instance profile)> username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes - rolearn: arn:aws:iam::111122223333:role/workers-1-10-NodeInstanceRole-U11V27W93CX5 username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes

<イイイイイイイイイイ ARN (イイイイイイイイイイイイイイイイ)> スニペットを、Step 3 (p. 107) で記録した[NodeInstanceRole] 値に置き換え、ファイルを保存して閉じることで、更新後の configmap を適用します。

6. ノードのステータスを監視し、新しいワーカーノードがクラスターに結合され、Ready ステータスになるまで待機します。


7. (オプション) Kubernetes Cluster Autoscaler を使用している場合は、スケーリングアクションの競合を回避するために、デプロイを 0 にスケールダウンします。

kubectl scale deployments/cluster-autoscaler --replicas=0 -n kube-system

8. 以下のコマンドを使用して、(新しいポッドが、置き換えようとしているノードでスケジュールまたは再スケジュールされないように) NoSchedule で削除する各ノードを taint に設定します。

kubectl taint nodes node_name key=value:NoSchedule

ワーカーノードを新しい Kubernetes バージョンにアップグレードする場合は、以下のコードスニペットを使用して、特定の Kubernetes バージョン (この場合は 1.13.12) のすべてのノードを識別して taint に設定できます。

108



K8S_VERSION=1.13.12nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}")for node in ${nodes[@]}do echo "Tainting $node" kubectl taint nodes $node key=value:NoScheduledone

9. クラスターの DNS プロバイダーを決定します。

kubectl get deployments -l k8s-app=kube-dns -n kube-system

出力 (このクラスターでは、DNS 解決に kube-dns を使用していますが、クラスターからはcoredns が返される場合があります)。

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGEkube-dns 1 1 1 1 31m

10. 現在のデプロイで実行しているレプリカが 2 つ未満の場合は、そのデプロイを 2 つのレプリカにスケールアウトします。前のコマンド出力でそのように返された場合は、coredns を kube-dnsに置き換えます。

kubectl scale deployments/kube-dns --replicas=2 -n kube-system

11. 次のコマンドを使用して、クラスターから削除する各ノードをドレーンします。

kubectl drain node_name --ignore-daemonsets --delete-local-data

ワーカーノードを新しい Kubernetes バージョンにアップグレードする場合は、以下のコードスニペットを使用して、特定の Kubernetes バージョン (この場合は 1.13.12) のすべてのノードを識別して解放することができます。

K8S_VERSION=1.13.12nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}")for node in ${nodes[@]}do echo "Draining $node" kubectl drain $node --ignore-daemonsets --delete-local-datadone

12. 古いワーカーノードの解放が完了したら、以前承認したセキュリティグループのイングレスルールを取り消し、AWS CloudFormation スタックを削除してインスタンスを終了します。

Note

さらに IAM ポリシーを古いノードグループの IAM ロールにアタッチした場合(Kubernetes Cluster Autoscaler に対するアクセス許可を追加する場合など) は、ロールからそのポリシーをデタッチしてから、AWS CloudFormation スタックを削除する必要があります。

a. 先ほどワーカーノードのセキュリティグループ用に作成したイングレスルールを取り消します。これらのコマンドで、oldNodes は、古いワーカーノードスタックの AWSCloudFormation スタック名、newNodes は、移行先のスタックの名前を表します。

oldNodes="<old_node_CFN_stack_name>"

109



newNodes="<new_node_CFN_stack_name>"

oldSecGroup=$(aws cloudformation describe-stack-resources --stack-name $oldNodes \--query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \--output text)newSecGroup=$(aws cloudformation describe-stack-resources --stack-name $newNodes \--query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \--output text)aws ec2 revoke-security-group-ingress --group-id $oldSecGroup \--source-group $newSecGroup --protocol -1aws ec2 revoke-security-group-ingress --group-id $newSecGroup \--source-group $oldSecGroup --protocol -1

b. AWS CloudFormation コンソール (https://console.aws.amazon.com/cloudformation) を開きます。

c. 古いワーカーノードスタックを選択します。d. [アクション]、[スタックの削除] の順に選択します。

13. aws-auth configmap を編集して、RBAC から古いワーカーノードインスタンスロールを削除します。

kubectl edit configmap -n kube-system aws-auth

古いワーカーノードグループの mapRoles エントリを削除します。

apiVersion: v1data: mapRoles: | - rolearn: arn:aws:iam::111122223333:role/workers-1-11-NodeInstanceRole-W70725MZQFF8 username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes - rolearn: arn:aws:iam::111122223333:role/workers-1-10-NodeInstanceRole-U11V27W93CX5 username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes

更新された configmap を適用するには、ファイルを保存して閉じます。14. (オプション) Kubernetes Cluster Autoscaler を使用している場合は、デプロイのスケーリングを 1

レプリカに戻します。

Note

必要に応じて、新しい Auto Scaling グループにタグ（k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/<YOUR CLUSTER NAME> など）を付け、新しくタグ付けした Auto Scaling グループを参照するように、Cluster Autoscalerデプロイのコマンドを更新する必要があります。詳細については、「AWS の ClusterAutoscaler」を参照してください。


110



https://github.com/kubernetes/autoscaler/tree/cluster-autoscaler-release-1.3/cluster-autoscaler/cloudprovider/aws

https://github.com/kubernetes/autoscaler/tree/cluster-autoscaler-release-1.3/cluster-autoscaler/cloudprovider/aws

Amazon EKS ユーザーガイド既存のワーカーノードグループの更新

15. (オプション) 最新バージョンの Amazon VPC CNI Plugin for Kubernetes を使用していることを確認します。サポートされている最新のインスタンスタイプを利用するには、CNI のバージョンを更新する必要があります。詳細については、「Amazon VPC CNI Plugin for Kubernetes のアップグレード (p. 182)」を参照してください。

16. クラスターの DNS 解決 (ステップ Step 9 (p. 109) を参照) に kube-dns を使用している場合は、kube-dns デプロイを 1 レプリカにスケーリングしてください。


既存のワーカーノードグループの更新このトピックは、新しい AMI を使用して既存の AWS CloudFormation セルフマネージド型ワーカーノードスタックを更新するのに役立ちます。この手順を使用して、クラスターの更新後にワーカーノードを新しいバージョンの Kubernetes に更新するか、Kubernetes の既存バージョン用の最新の Amazon EKS 最適化AMI に更新することができます。

Important

このトピックでは、セルフマネージド型ノードグループのワーカーノードの更新について説明します。マネージド型ノードグループ (p. 87) を使用している場合は、「マネージド型ノードグループの更新 (p. 92)」を参照してください。

最新のデフォルトの Amazon EKS ワーカーノード AWS CloudFormation テンプレートは、古い AMI を一度に 1 つずつ削除する前に、新しい AMI を使用してインスタンスをクラスターに起動するように設定されています。この設定により、ローリング更新中にクラスター内で Auto Scaling グループのアクティブなインスタンスが必要数確保されるようになります。

Note

この方法は、eksctl を使用して作成されたワーカーノードグループではサポートされていません。eksctl を使用してクラスターまたはワーカーノードグループを作成した場合は、「新しいワーカーノードグループへの移行 (p. 106)」を参照してください。

既存のワーカーノードグループを更新するには

1. クラスターの DNS プロバイダーを決定します。

kubectl get deployments -l k8s-app=kube-dns -n kube-system

出力 (このクラスターでは、DNS 解決に kube-dns を使用していますが、クラスターからはcoredns が返される場合があります)。

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGEkube-dns 1 1 1 1 31m

2. 現在のデプロイで実行しているレプリカが 2 つ未満の場合は、そのデプロイを 2 つのレプリカにスケールアウトします。前のコマンド出力でそのように返された場合は、coredns を kube-dns に置き換えます。


3. (オプション) Kubernetes Cluster Autoscaler を使用している場合は、スケーリングアクションの競合を回避するために、デプロイを 0 にスケールダウンします。


111



Amazon EKS ユーザーガイド既存のワーカーノードグループの更新

4. 現在のワーカーノードグループのインスタンスタイプと必要なインスタンス数を決定します。グループの AWS CloudFormation テンプレートを更新する場合は、後でこれらの値を入力します。

a. https://console.aws.amazon.com/ec2/ で Amazon EC2 コンソールを開きます。b. 左ナビゲーションの [起動設定] を選択し、既存のワーカーノードの起動設定のインスタンスタイ

プを書き留めます。c. 左ナビゲーションの [Auto Scaling グループ] を選択し、既存のワーカーノードの Auto Scaling グ

ループの [Desired (必要)] インスタンス数を書き留めます。5. AWS CloudFormation コンソール (https://console.aws.amazon.com/cloudformation) を開きます。6. ワーカーノードグループスタックを選択し、[Update (更新)] を選択します。7. [Replace current template (現在のテンプレートを置き換える)] を選択し、[Amazon S3 URL] を選択し

ます。8. Amazon S3 URL で、ワーカーノードの AWS CloudFormation テンプレートの最新バージョンを使用

していることを確認するために以下の URL をテキストエリアに貼り付けたら、[次へ] を選択します。


9. [Specify stack details (スタックの詳細の指定)] ページで、以下のパラメータを指定し、[次へ] を選択します。

• NodeAutoScalingGroupDesiredCapacity – Step 4 (p. 112) で記録した必要なインスタンス数を入力するか、スタックの更新時にスケーリングする新しい必要ノード数を入力します。

• NodeAutoScalingGroupMaxSize - ワーカーノードの Auto Scaling グループがスケールアウトする最大ノード数を入力します。更新時にノード数を減らさずにワーカーノードのローリング更新を実行できるように、この値は、必要なキャパシティーよりも 1 ノード多くする必要があります。

• NodeInstanceType - Step 4 (p. 112) で記録したインスタンスタイプを選択するか、別のインスタンスタイプをワーカーノード用に選択します。

Note

最新バージョンの Amazon VPC CNI Plugin for Kubernetes でサポートされているインスタンスタイプをこちらに示します。サポートされている最新のインスタンスタイプを利用するには、CNI のバージョンを更新する必要があります。詳細については、「Amazon VPCCNI Plugin for Kubernetes のアップグレード (p. 182)」を参照してください。

Important

リージョンによっては利用できないインスタンスタイプがあります。• NodeImageIdSSMParam - 更新する AMI ID の Amazon EC2 Systems Manager パラメータ。次の値

は、最新の Amazon EKS 最適化 AMI for Kubernetes バージョン 1.16 を使用します。

/aws/service/eks/optimized-ami/1.16/amazon-linux-2/recommended/image_id

1.16 値は、サポートされているすべての Kubernetes バージョン (p. 52)に変更できます。GPU サポートで Amazon EKS 最適化 AMI を使用する場合は、amazon-linux-2 を amazon-linux-2-gpu に変更します。

Note

Amazon EC2 Systems Manager パラメータを使用すると、AMI ID を検索して指定することなく、後でワーカーノードを更新できます。AWS CloudFormation スタックがこの値を使用している場合、テンプレートの値を変更しない場合でも、スタックの更新によって常に、指定された Kubernetes バージョンで推奨される最新の Amazon EKS 最適化 AMI が起動されます。

• NodeImageId - 独自のカスタム AMI を使用するには、使用する AMI の ID を入力します。112

https://console.aws.amazon.com/ec2/




Amazon EKS ユーザーガイドUbuntu AMI

Important

この値は、NodeImageIdSSMParam に指定されたすべての値を上書きします。NodeImageIdSSMParam 値を使用する場合は、 NodeImageId の値が空白であることを確認します。

10. (オプション) [オプション] ページで、スタックリソースをタグ付けします。[次へ] を選択します。11. [確認] ページで情報を確認し、スタックで IAM リソースを作成することを承認して、[Update stack

(スタックの更新)] を選択します。

Note

クラスター内の各ノードの更新には数分かかります。すべてのノードの更新が完了するのを待ってから、次の手順を実行します。

12. クラスターの DNS プロバイダーは kube-dns の場合は、kube-dns デプロイを 1 レプリカにスケールインします。


13. (オプション) Kubernetes Cluster Autoscaler を使用している場合は、デプロイのスケーリングを 1 レプリカに戻します。


14. (オプション) 最新バージョンの Amazon VPC CNI Plugin for Kubernetes を使用していることを確認します。サポートされている最新のインスタンスタイプを利用するには、CNI のバージョンを更新する必要があります。詳細については、「Amazon VPC CNI Plugin for Kubernetes のアップグレード (p. 182)」を参照してください。

Ubuntu Amazon EKS最適化 AMI公式の Amazon EKS 最適化に加えて、Canonical 社は Amazon EKS と提携し、クラスターで使用できるワーカーノード AMI を作成します。

Canonical 社は、特定用途向けの Kubernetes ノード OS イメージ用のビルドを提供します。この結果、最小化された Ubuntu イメージは Amazon EKS に合わせて最適化され、AWS と共同開発されたカスタムAWS カーネルを含んでいます。詳細については、「Ubuntu および Amazon Elastic Kubernetes Service」と「Ubuntu 18.04 での最適化された Amazon EKS のサポート」を参照してください。

113



https://www.canonical.com/

https://cloud-images.ubuntu.com/aws-eks/

http://aws.amazon.com/blogs/opensource/optimized-support-amazon-eks-ubuntu-1804/


AWS Fargateこの章では、Amazon EKS を使用して AWS Fargate で Kubernetes ポッドを実行する方法について説明します。

AWS Fargate は、コンテナに適切なサイズのコンピューティング能力をオンデマンドで提供するテクノロジーです。AWS Fargate を使用すると、コンテナを実行するために仮想マシンのグループをプロビジョニング、設定、スケールする必要がありません。これにより、サーバータイプの選択、ノードグループをスケールするタイミングの決定、クラスターのパッキングの最適化を行う必要がなくなります。

Fargate で開始するポッド、および、Amazon EKS クラスターの一部として定義されている Fargate プロファイル (p. 120)での実行方法を制御できます。

Amazon EKS は、Kubernetes が提供するアップストリームの拡張可能なモデルを使用して AWS により構築されたコントローラーを使用して、Kubernetes と AWS Fargate を統合します。これらのコントローラーは、Amazon EKS マネージド型 Kubernetes コントロールプレーンの一部として実行され、ネイティブ Kubernetes ポッドを Fargate にスケジューリングします。Fargate コントローラーには、いくつかの変更と検証アドミッションコントローラーに加えて、デフォルトの Kubernetes スケジューラーとともに実行される新しいスケジューラーが含まれています。Fargate で実行する条件を満たすポッドを起動すると、クラスターで実行されている Fargate コントローラーはポッドを Fargate に認識、更新、およびスケジュールします。

Fargate で実行する各ポッドは、独自の分離境界を持ち、基本となるカーネル、CPU リソース、メモリリソース、または Elastic Network Interface を別のポッドと共有しません。

この章では、Fargate で実行されているポッドのさまざまなコンポーネントについて説明し、AmazonEKS で Fargate を使用する際の特別な考慮事項について喚起します。

Amazon EKS での AWS Fargate は、現在以下のリージョンでのみ利用可能です。

リージョン名リージョン

米国東部 (オハイオ) us-east-2

米国東部（バージニア北部） us-east-1

米国西部 (オレゴン) us-west-2

アジアパシフィック (シンガポール) ap-southeast-1

アジアパシフィック (シドニー) ap-southeast-2

アジアパシフィック (東京) ap-northeast-1

欧州 (フランクフルト) eu-central-1

欧州 (アイルランド) eu-west-1

トピック• AWS Fargate に関する考慮事項 (p. 115)• Amazon EKS での AWS Fargate の開始方法 (p. 115)• AWS Fargate プロファイル (p. 120)• Fargate ポッドの設定 (p. 123)

114

https://aws.amazon.com/what-are-containers

Amazon EKS ユーザーガイドFargate に関する考慮事項

AWS Fargate に関する考慮事項Amazon EKS での Fargate の使用についての考慮事項を以下に示します。

• Classic Load Balancer および Network Load Balancer は Fargate で実行されているポッドではサポートされません。入力の場合は、Amazon EKS の ALB Ingress Controller (p. 153) (最小バージョン v1.1.4)を使用することをお勧めします。

• Fargate で実行するには、ポッドがスケジュールされた時点で Fargate プロファイルと一致する必要があります。Fargate プロファイルと一致しないポッドは、Pending としてスタックされる可能性があります。一致する Fargate プロファイルが存在する場合、Fargate に再スケジュールするために作成した保留中のポッドを削除できます。

• デーモンセットは Fargate ではサポートされていません。アプリケーションにデーモンが必要な場合は、そのデーモンをポッドのサイドカーコンテナとして実行するように再設定する必要があります。

• 特権を持つコンテナは Fargate ではサポートされていません。• Fargate で実行されているポッドは、ポッドマニフェストで HostPort または HostNetwork を指定できま

せん。• GPU は現在、Fargate では使用できません。• Fargate で実行されている Pod は、プライベートサブネットでのみサポートされます (AWS サービスへ

の NAT ゲートウェイアクセスがありますが、インターネットゲートウェイへの直接ルートはありません)。そのため、クラスターの VPC にはプライベートサブネットを使用できる必要があります。

• アプリケーションに使用される CPU とメモリを最適化するには、ポッドを Fargate で実行して VerticalPod Autoscaler (p. 146) を使用することをお勧めします。ただし、ポッドのリソース割り当てを変更する場合はポッドを再起動する必要があるため、ポッド更新ポリシーを Auto または Recreate に設定して、正しく機能することを確認します。

• ステートフルアプリケーションは、Fargate で実行されているポッドには推奨されません。代わりに、Amazon S3 または DynamoDB などの AWS ソリューションをポッドデータストレージに使用することをお勧めします。

• Fargate は、他のポッドとリソースを共有することなく、VM 分離環境で各ポッドを実行します。ただし、Kubernetes はシングルテナントオーケストレーターであるため、Fargate はポッドレベルのセキュリティ分離を保証することはできません。個別の Amazon EKS クラスターを使用して、セキュリティを完全に分離する必要がある機密性の高いワークロードまたは信頼できないワークロードを実行する必要があります。

• VPC で DNS 解決と DNS ホスト名を有効にする必要があります。詳細については、「VPC の DNS サポートを更新する」を参照してください。

• Fargate では ??? (p. 176) を使用できません。

Amazon EKS での AWS Fargate の開始方法このトピックでは、Amazon EKS クラスターを使用して AWS Fargate でポッドの実行を開始する方法について説明します。

Note

Amazon EKS での AWS Fargate は、現在、以下のリージョンでのみ利用可能です。


米国東部 (オハイオ) us-east-2

米国東部（バージニア北部） us-east-1

米国西部 (オレゴン) us-west-2

115

https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating

https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating

Amazon EKS ユーザーガイド(オプション) クラスターを作成する


アジアパシフィック (シンガポール) ap-southeast-1

アジアパシフィック (シドニー) ap-southeast-2

アジアパシフィック (東京) ap-northeast-1

欧州 (フランクフルト) eu-central-1

欧州 (アイルランド) eu-west-1

CIDR ブロックを使用してクラスターのパブリックエンドポイントへのアクセスを制限する場合は、Fargate ポッドがクラスターと通信できるように、プライベートエンドポイントアクセスも有効にすることをお勧めします。プライベートエンドポイントが有効になっていない場合、パブリックアクセスに指定する CIDR ブロックに、VPC からの出力ソースを含める必要があります。詳細については、「Amazon EKS クラスターエンドポイントのアクセスコントロール (p. 37)」を参照してください。

(オプション) クラスターを作成するFargate で実行されているポッドは、Kubernetes バージョン 1.14 およびプラットフォームバージョン (p. 52)eks.5 で始まる Amazon EKS クラスターでサポートされています。既存のクラスターは、この機能を利用するために、バージョン 1.14 以降に更新できます。詳細については、「Amazon EKS クラスターの Kubernetes バージョンの更新 (p. 29)」を参照してください。

Fargate がサポートされている Amazon EKS クラスターをまだ作成していない場合は、以下の eksctl コマンドを使用して作成できます。

Note


eksctl version


eksctl create cluster --name my-cluster --version 1.16 --fargate

上記のコマンドで --fargate オプションを追加すると、ノードグループのないクラスターが作成されます。ただし、eksctl では、ポッド実行ロール、default と kube-system の名前空間の Fargate プロファイルを作成し、coredns デプロイにパッチを適用して Fargate で実行できるようにします。

既存のノードが Fargate ポッドと通信できるようにするワーカーノードのない新しいクラスター、またはマネージド型ノードグループ (p. 87)のみを持つクラスターを使用している場合は、「Fargate ポッド実行ロールを作成する (p. 117)」に進みます。

ワーカーノードが関連付けられている既存のクラスターを使用している場合は、これらのノードのポッドが Fargate で実行されているポッドと自由に通信できることを確認する必要があります。Fargate で実行されているポッドは、関連付けられているクラスターのクラスターセキュリティグループを使用するように自動的に設定されます。クラスター内の既存のワーカーノードが、クラスターセキュリティグループとの間でトラフィックを送受信できることを確認する必要があります。マネージド型ノードグループ (p. 87)

116

Amazon EKS ユーザーガイドFargate ポッド実行ロールを作成する

は、クラスターセキュリティグループも使用するように自動的に設定されるため、この互換性のためにノードを変更したり確認したりする必要はありません。

eksctl または Amazon EKS マネージド型 AWS CloudFormation テンプレートで作成された既存のノードグループについては、クラスターセキュリティグループをノードに手動で追加するか、ノードグループのAuto Scaling グループ起動テンプレートを変更して、クラスターセキュリティグループをインスタンスにアタッチできます。詳細については、『Amazon VPC ユーザーガイド』の「インスタンスのセキュリティグループを変更する」を参照してください。

クラスターのクラスターセキュリティグループは、クラスターの [ネットワーキング] セクションの下にある AWS マネジメントコンソールで確認するか、次の AWS CLI コマンドで確認できます。

aws eks describe-cluster --name cluster_name --query cluster.resourcesVpcConfig.clusterSecurityGroupId

Fargate ポッド実行ロールを作成するクラスターが AWS Fargate でポッドを作成する場合、ポッドはユーザーに代わって AWS API を呼び出して、Amazon ECR でコンテナイメージのプルなどの処理を行う必要があります。Amazon EKS ポッド実行ロールでは、この処理を行うための IAM アクセス許可が提供されます。

Note

--fargate オプションを使用して eksctl でクラスターを作成した場合は、クラスターにポッド実行ロールが既にあるため、「クラスターの Fargate プロファイルを作成する (p. 117)」に進んでください。同様に、eksctl を使用して Fargate プロファイルを作成する場合、eksctl ではポッド実行ロールを作成します (まだ存在しない場合)。

Fargate プロファイルを作成する際は、ポッドで使用するポッド実行ロールを指定する必要があります。このロールは、承認のためにクラスターの Kubernetes ロールベースのアクセス制御 (RBAC) に追加されます。これにより、Fargate インフラストラクチャで実行されている kubelet が Amazon EKS クラスターに登録され、クラスター内でノードとして表示されるようになります。詳細については、「ポッド実行ロール (p. 262)」を参照してください。

1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。2. [ロール] を選択してから [ロールの作成] を選びます。3. サービスのリストから [EKS] を選択し、ユースケースに合った [EKS - Fargate ポッド] を選択して、

[Next: Permissions (次へ: アクセス許可)] を選択します。4. [次へ: タグ] を選択します。5. (オプション) タグをキーと値のペアとしてアタッチして、メタデータをロールに追加します。IAM で

のタグの使用の詳細については、『IAM ユーザーガイド』の IAM エンティティのタグ付けを参照してください。

6. [Next: Review] を選択します。7. [Role name (ロール名)] に、ロールの一意の名前 (例: AmazonEKSFargatePodExecutionRole) を入

力し、[ロールの作成] を選択します。

クラスターの Fargate プロファイルを作成するクラスターの Fargate で実行されるポッドをスケジュールする前に、起動時に Fargate を使用するポッドを指定する Fargate プロファイルを定義する必要があります。詳細については、「AWS Fargate プロファイル (p. 120)」を参照してください。

Note

--fargate オプションを使用して eksctl でクラスターを作成した場合、クラスターの Fargateプロファイルは、kube-system と default の名前空間のすべてのポッドのセレクタを使用して

117

https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_SecurityGroups.html#SG_Changing_Group_Membership

https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_SecurityGroups.html#SG_Changing_Group_Membership




Amazon EKS ユーザーガイドクラスターの Fargate プロファイルを作成する

既に作成されています。Fargate で使用するその他の名前空間の Fargate プロファイルを作成するには、以下の手順に従います。

優先する Fargate プロファイルの作成方法に対応するタブを以下で選択します。

eksctl

eksctl でクラスターの Fargate プロファイルを作成するには


eksctl version


• 以下の eksctl コマンドで Fargate プロファイルを作成し、イイイイイイを独自の値に置き換えます。名前空間を指定する必要がありますが、labels オプションは必須ではありません。

eksctl create fargateprofile --cluster cluster_name --name fargate_profile_name --namespace kubernetes_namespace --labels key=value


AWS マネジメントコンソールでクラスターの Fargate プロファイルを作成するには

1. Open the Amazon EKS console at https://console.aws.amazon.com/eks/home#/clusters.2. Fargate プロファイルを作成するクラスターを選択します。3. [Fargate profiles (Fargate プロファイル)] で、[Add profile (Fargate プロファイルの追加)] を選択

します。4. [Configure Fargate profile (Fargate プロファイルの設定] ページで、以下の情報を入力し、[Next

(次へ)] を選択します。

a. [Name (名前)] に Fargate プロファイルの一意の名前を入力します。b. [Pod execution role (ポッド実行ロール)] で、Fargate プロファイルで使用するポッド実行

ロールを選択します。eks-fargate-pods.amazonaws.com サービスプリンシパルを持つIAM ロールのみが表示されます。ここにロールが表示されない場合は、ロールを作成する必要があります。詳細については、「ポッド実行ロール (p. 262)」を参照してください。

c. [Subnets (サブネット)] で、ポッドに使用するサブネットを選択します。デフォルトでは、クラスターの VPC 内のすべてのサブネットが選択されます。Fargate で実行されているポッドでは、プライベートサブネットのみがサポートされるため、パブリックサブネットの選択を解除する必要があります。

d. [Tags (タグ)] では、オプションで Fargate プロファイルにタグを付けることができます。これらのタグは、ポッドなど、プロファイルに関連付けられた他のリソースには伝達されません。

5. [Configure pods selection (ポッドの設定)] ページで、以下の情報を入力し、[Next (次へ)] を選択します。

a. [Namespace (名前空間)] に、kube-system や default など、ポッドと照合する名前空間を入力します。

b. (オプション) 指定された名前空間のポッドがセレクタと一致する必要があるセレクタにKubernetes ラベルを追加します。たとえば、infrastructure: fargate ラベルをセレクタに追加して、指定した名前空間に存在し、なおかつinfrastructure: fargateKubernetes ラベルを持つポッドのみがセレクタに一致するようにできます。

118


Amazon EKS ユーザーガイド(オプション) CoreDNS を更新する

6. [Review and create (確認と作成)] ページで、Fargate プロファイルの情報を確認し、[Create (作成)] を選択します。

(オプション) CoreDNS を更新するデフォルトでは、CoreDNS は Amazon EKS クラスターの Amazon EC2 インフラストラクチャで実行するように設定されています。クラスター内の Fargate でポッドのみを実行する場合は、CoreDNS デプロイを変更して、eks.amazonaws.com/compute-type : ec2 の注釈を削除する必要があります。また、CoreDNS ポッドをターゲットにする Fargate プロファイルを作成する必要もあります。以下のFargate プロファイル JSON ファイルでこの作業が実行されます。

Note

--fargate オプションを使用して eksctl でクラスターを作成した場合、coredns にはFargate で実行されるように既にパッチが適用されているため、「次のステップ (p. 119)」に進んでください。

{ "fargateProfileName": "coredns", "clusterName": "dev", "podExecutionRoleArn": "arn:aws:iam::111122223333:role/AmazonEKSFargatePodExecutionRole", "subnets": [ "subnet-0b64dd020cdff3864", "subnet-00b03756df55e2b87", "subnet-0418fcb68ed294abf" ], "selectors": [ { "namespace": "kube-system", "labels": { "k8s-app": "kube-dns" } } ]}

以下の AWS CLI コマンドを使用すると、この Fargate プロファイルをクラスターに適用できます。まず、coredns.json という名前のファイルを作成し、前のステップの JSON ファイルをそのファイルに貼り付けて、イイイイイイを独自のクラスター値に置き換えます。

aws eks create-fargate-profile --cli-input-json file://coredns.json

次に、以下の kubectl コマンドを使用して、CoreDNS ポッドから eks.amazonaws.com/compute-type : ec2 の注釈を削除します。

kubectl patch deployment coredns -n kube-system --type json \-p='[{"op": "remove", "path": "/spec/template/metadata/annotations/eks.amazonaws.com~1compute-type"}]'

次のステップ• 以下のワークフローを使用すると、Fargate で実行するために既存のアプリケーションの移行を開始で

きます。1. アプリケーションの Kubernetes 名前空間と Kubernetes ラベルに一致する Fargate プロファイルを作

成 (p. 121)します。

119

Amazon EKS ユーザーガイドFargate プロファイル

2. 既存のポッドを削除して再作成し、Fargate でスケジュールされるようにします。たとえば、以下のコマンドでは、coredns デプロイのロールアウトがトリガーされます。名前空間とデプロイタイプを変更して、特定のポッドを更新できます。

kubectl rollout restart -n kube-system deployment coredns

• Amazon EKS の ALB Ingress Controller (p. 153) (バージョン v1.1.4 以降) をデプロイして、Fargate で実行されているポッドの Ingress オブジェクトを許可します。

• Fargate で実行されているポッドの Vertical Pod Autoscaler (p. 146) をデプロイして、アプリケーションに使用される CPU とメモリを最適化します。ポッドの更新ポリシーを Auto または Recreate に設定して、正しく機能するようにしてください。

AWS Fargate プロファイルクラスターの Fargate でポッドをスケジュールする前に、起動時に Fargate を使用するポッドを指定するFargate プロファイルを少なくとも 1 つ定義する必要があります。

Fargate プロファイルにより、管理者はFargate でどのポッドが実行されるかを宣言できます。この宣言は、プロファイルのセレクターを介して行われます。各プロファイルには、名前空間とオプションのラベルを含むセレクターを 5 つまで設定できます。すべてのセレクターに名前空間を定義する必要があります。ラベルフィールドは、複数のオプションのキーと値のペアで構成されます。セレクターと一致するポッド (セレクターの名前空間とセレクターで指定されたすべてのラベルを照合することによって)は、Fargate でスケジュールされます。名前空間セレクターがラベルなしで定義されている場合、AmazonEKS は、プロファイルを使用して、その名前空間で実行されるすべてのポッドを Fargate にスケジュールしようとします。スケジュールされるポッドが Fargate プロファイル内のいずれかのセレクターと一致する場合、そのポッドは Fargate にスケジュールされます。

ポッドが複数の Fargate プロファイルに一致する場合、Amazon EKS は一致するものの 1 つをランダムに選択します。この場合、ポッドの仕様に以下の Kubernetes ラベルを追加することで、ポッドが使用するプロファイルを指定できます eks.amazonaws.com/fargate-profile: profile_name。ただし、ポッドを Fargate にスケジュールするには、そのプロファイル内のセレクターと一致させる必要があります。

Fargate プロファイルを作成するときは、プロファイルを使用して Fargate で実行するポッドの、ポッド実行ロールを指定する必要があります。このロールは承認のためにクラスターの Kubernetes ロールベースアクセス制御 (RBAC) に追加され、Fargate インフラストラクチャで実行されている kubelet がAmazon EKS クラスターに登録され、ノードとしてクラスターに表示されるようにします。ポッド実行ロールは、また、Amazon ECR イメージリポジトリへの読み取りアクセスを許可する IAM アクセス権限を Fargate インフラストラクチャに提供します。詳細については、「ポッド実行ロール (p. 262)」を参照してください。

Fargate プロファイルは変更不可能です。ただし、新しい更新されたプロファイルを作成して既存のプロファイルを置き換え、更新されたプロファイルの作成が完了した後に元のプロファイルを削除することはできます。

Note

Fargate プロファイルを使用して実行中のポッドは、プロファイルが削除されると停止され、保留状態になります。

クラスターのいずれかの Fargate プロファイルが DELETING ステータスである場合は、その Fargate プロファイルの削除が完了するのを待ってから、そのクラスターに他のプロファイルを作成する必要があります。

Fargate プロファイルのコンポーネントFargate プロファイルには、次のコンポーネントが含まれています。

120



Amazon EKS ユーザーガイドFargate プロファイルの作成

{ "fargateProfileName": "", "clusterName": "", "podExecutionRoleArn": "", "subnets": [ "" ], "selectors": [ { "namespace": "", "labels": { "KeyName": "" } } ], "clientRequestToken": "", "tags": { "KeyName": "" }}

ポッド実行ロール

クラスターが AWS Fargate でポッドを作成する場合、ポッドはユーザーに代わって AWS API を呼び出す必要があります。たとえば、Amazon ECR からコンテナイメージをプルします。Amazon EKSポッド実行ロールは、これを行うための IAM アクセス権限を提供します。

Fargate プロファイルを作成するときは、ポッドで使用するポッド実行ロールを指定する必要があります。このロールは、承認のためにクラスターの Kubernetes ロールベースアクセス制御 (RBAC) に追加され、Fargate インフラストラクチャで実行されている kubelet が Amazon EKS クラスターに登録され、ノードとしてクラスターに表示されるようにします。詳細については、「ポッド実行ロール (p. 262)」を参照してください。

Subnets

このプロファイルを使用するポッドを起動するサブネットの ID。現時点では、Fargate で実行されているポッドにはパブリック IP アドレスが割り当てられないため、このパラメータにはプライベートサブネット (インターネットゲートウェイへの直接ルートなし) のみが受け入れられます。

セレクター

この Fargate プロファイルを使用するためにポッドに一致するセレクター。各セレクターには名前空間が関連付けられている必要があります。必要に応じて、名前空間のラベルを指定することもできます。1 つの Fargate プロファイルに最大 5 つのセレクターを指定できます。ポッドは、Fargate プロファイルを使用して実行するセレクターを 1 つのみ一致させる必要があります。名前空間

セレクターの名前空間を指定する必要があります。セレクターは、この名前空間で作成されたポッドのみに一致しますが、複数のセレクターを作成して複数の名前空間をターゲットにすることができます。

ラベル

オプションで、セレクターに一致する Kubernetes ラベルを指定できます。セレクターは、セレクターで指定されているすべてのラベルを持つポッドのみに一致します。

Fargate プロファイルの作成このトピックでは、Fargate プロファイルの作成について説明します。クラスターが Fargate をサポートしている必要があります (Kubernetes バージョン 1.14 およびプラットフォームバージョン (p. 52)以降eks.5)。また、Fargate プロファイルに使用するポッド実行ロールを作成しておく必要があります。

121


Amazon EKS ユーザーガイドFargate プロファイルの作成

詳細については、「ポッド実行ロール (p. 262)」を参照してください。Fargate で実行されているポッドは、プライベートサブネットでのみサポートされます (AWS のサービスへの NAT ゲートウェイアクセスがありますが、インターネットゲートウェイへの直接ルートはありません)。そのため、クラスターのVPC にはプライベートサブネットを使用できる必要があります。

eksctl

eksctl でクラスターの Fargate プロファイルを作成するには


eksctl version


• 以下の eksctl コマンドで Fargate プロファイルを作成し、イイイイイイを独自の値に置き換えます。名前空間を指定する必要がありますが、labels オプションは必須ではありません。

eksctl create fargateprofile --cluster cluster_name --name fargate_profile_name --namespace kubernetes_namespace --labels key=value


AWS マネジメントコンソールでクラスターの Fargate プロファイルを作成するには

1. Open the Amazon EKS console at https://console.aws.amazon.com/eks/home#/clusters.2. Fargate プロファイルを作成するクラスターを選択します。3. [Fargate profiles (Fargate プロファイル)] で、[Add profile (Fargate プロファイルの追加)] を選択

します。4. [Configure Fargate profile (Fargate プロファイルの設定] ページで、以下の情報を入力し、[Next

(次へ)] を選択します。

a. [Name (名前)] に Fargate プロファイルの一意の名前を入力します。b. [Pod execution role (ポッド実行ロール)] で、Fargate プロファイルで使用するポッド実行

ロールを選択します。eks-fargate-pods.amazonaws.com サービスプリンシパルを持つIAM ロールのみが表示されます。ここにロールが表示されない場合は、ロールを作成する必要があります。詳細については、「ポッド実行ロール (p. 262)」を参照してください。

c. [Subnets (サブネット)] で、ポッドに使用するサブネットを選択します。デフォルトでは、クラスターの VPC 内のすべてのサブネットが選択されます。Fargate で実行されているポッドでは、プライベートサブネットのみがサポートされるため、パブリックサブネットの選択を解除する必要があります。

d. [Tags (タグ)] では、オプションで Fargate プロファイルにタグを付けることができます。これらのタグは、ポッドなど、プロファイルに関連付けられた他のリソースには伝達されません。

5. [Configure pods selection (ポッドの設定)] ページで、以下の情報を入力し、[Next (次へ)] を選択します。

a. [Namespace (名前空間)] に、kube-system や default など、ポッドと照合する名前空間を入力します。

b. (オプション) 指定された名前空間のポッドがセレクタと一致する必要があるセレクタにKubernetes ラベルを追加します。たとえば、infrastructure: fargate ラベルをセレクタに追加して、指定した名前空間に存在し、なおかつinfrastructure: fargateKubernetes ラベルを持つポッドのみがセレクタに一致するようにできます。

122

https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-nat-gateway.html


Amazon EKS ユーザーガイドFargate プロファイルの削除

6. [Review and create (確認と作成)] ページで、Fargate プロファイルの情報を確認し、[Create (作成)] を選択します。

Fargate プロファイルの削除このトピックでは、Fargate プロファイルを削除する方法について説明します。

Fargate プロファイルを削除すると、そのプロファイルで Fargate にスケジュールされていたポッドはすべて削除されます。これらのポッドが別の Fargate プロファイルと一致する場合、それらのポッドはそのプロファイルで Fargate にスケジュールされます。Fargate プロファイルがどのプロファイルとも一致しなくなった場合は、Fargate へのスケジュールは行われず、保留中のままになる可能性があります。

一度にクラスター内の 1 つの Fargate プロファイルのみが、 DELETING ステータスになることができます。そのクラスター内の他のプロファイルを削除する前に、Fargate プロファイルの削除が完了するまで待つ必要があります。

クラスターから Fargate プロファイルを削除するには

1. Open the Amazon EKS console at https://console.aws.amazon.com/eks/home#/clusters.2. Fargate プロファイルを削除するクラスターを選択します。3. 削除する Fargate プロファイルを選択し、[Delete (削除)] を選択します。4. [Delete (削除) cluster_name] ページで、クラスターの名前を入力し、[Confirm (確認)] を選択して削

除します。

Fargate ポッドの設定このセクションでは、AWS Fargate で Kubernetes ポッドを実行するための固有のポッド設定の詳細について説明します。

ポッド CPU とメモリKubernetes では、ポッド内の各コンテナに割り当てられるリクエスト、最小量の vCPU およびメモリリソースを定義できます。ポッドは Kubernetes によってスケジュールされ、少なくとも各ポッドに対してリクエストされたリソースがコンピューティングリソース上で利用可能になるようにします。詳細については、Kubernetes のドキュメントの「Managing Compute Resources for Containers」を参照してください。

ポッドが Fargate にスケジュールされている場合、ポッド仕様内の vCPU とメモリの予約によって、ポッドにプロビジョニングする CPU とメモリの量が決まります。

• Init コンテナからの最大リクエストは、Init リクエスト vCPU およびメモリ要件を決定するために使用されます。

• 実行時間の長いコンテナのリクエストは、実行時間の長いリクエスト vCPU とメモリ要件を決定するために合計されます。

• 上記の 2 つの値のうち大きい方が、ポッドで使用する vCPU とメモリリクエストに対して選択されます。

• Fargate は、必要な Kubernetes コンポーネント (kubelet、kube-proxy、および containerd) の各ポッドのメモリ予約に 256 MB を追加します。

Fargate は、ポッドが実行する必要のあるリソースを常に確保するために、vCPU とメモリリクエストの合計に最も近い、以下に示すコンピューティング設定に切り上げられます。

123


https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/

Amazon EKS ユーザーガイドFargate ストレージ

vCPU とメモリの組み合わせを指定しない場合は、使用可能な最小の組み合わせ (.25 vCPU と 0.5 GB のメモリ) が使用されます。

次の表は、Fargate で実行されているポッドで使用可能な vCPU とメモリの組み合わせを示しています。

vCPU 値メモリの値

.25 vCPU 0.5 GB、1 GB、2 GB

.5 vCPU 1 GB、2 GB、3 GB、4 GB

1 vCPU 2 GB、3 GB、4 GB、5 GB、6 GB、7 GB、8 GB

2 vCPU 4 GB ～ 16 GB (1 GB のインクリメント)

4 vCPU 8 GB ～ 30 GB (1 GB のインクリメント)

これらのコンピューティング設定の料金情報については、「AWS Fargate 料金表」を参照してください。

Fargate ストレージFargate で実行されている各 Pod は、プロビジョニング後に、10 GB のコンテナイメージレイヤーストレージを受け取ります。ポッドストレージは一時的なものです。ポッドが停止すると、ストレージは削除されます。

124

https://aws.amazon.com/fargate/pricing/

Amazon EKS ユーザーガイドストレージクラス

ストレージこの章では、 Amazon EKS クラスターのストレージオプションについて説明します。

ストレージクラス (p. 125) トピックでは、インツリー Amazon EBS ストレージプロビジョナーを使用します。Amazon EBS CSI ドライバー (p. 126) は、Kubernetes 1.14 以降のクラスターでストレージを管理するために利用できます。

Note

既存のインツリー Amazon EBS プラグインは引き続きサポートされていますが、CSI ドライバーを使用することで、Kubernetes アップストリームリリースサイクルと CSI ドライバーのリリースサイクルを分離することができます。最終的に、インツリープラグインは廃止され、CSI ドライバーが優先されます。

トピック• ストレージクラス (p. 125)• Amazon EBS CSI ドライバー (p. 126)• Amazon EFS CSI ドライバー (p. 130)• Amazon FSx for Lustre CSI ドライバー (p. 134)

ストレージクラスKubernetes バージョン 1.11 以前に作成された Amazon EKS クラスターは、どのストレージクラスにも作成されませんでした。使用するクラスターのストレージクラスを定義する必要があります。また、永続的なボリューム要求に対してデフォルトのストレージクラスを定義する必要があります。詳細については、Kubernetes ドキュメントの「ストレージクラス」を参照してください。

Note

このトピックでは、インツリー Amazon EBS ストレージプロビジョナーを使用します。Kubernetes 1.14 以降のクラスターでは、ストレージの管理に Amazon EBS CSI ドライバー (p. 126) を使用できます。既存のインツリー Amazon EBS プラグインは引き続きサポートされていますが、CSI ドライバーを使用することで、Kubernetes アップストリームリリースサイクルと CSI ドライバーのリリースサイクルを分離することができます。最終的に、インツリープラグインは廃止され、CSI ドライバーが優先されます。

Amazon EKS クラスターに AWS ストレージクラスを作成するには

1. ストレージクラスに AWS ストレージクラスのマニフェストファイルを作成します。以下の gp2-storage-class.yaml の例では、Amazon EBS gp2 ボリュームタイプを使用する gp2 というストレージクラスを定義しています。

AWS ストレージクラスで使用できるオプションの詳細については、Kubernetes のドキュメントの「AWS EBS」を参照してください。

kind: StorageClassapiVersion: storage.k8s.io/v1metadata: name: gp2 annotations: storageclass.kubernetes.io/is-default-class: "true"provisioner: kubernetes.io/aws-ebsparameters: type: gp2 fsType: ext4

125

https://kubernetes.io/docs/concepts/storage/volumes/#awselasticblockstore

https://kubernetes.io/docs/concepts/storage/storage-classes



https://kubernetes.io/docs/concepts/storage/storage-classes/#aws-ebs

Amazon EKS ユーザーガイドAmazon EBS CSI ドライバー

2. kubectl を使用して、マニフェストファイルからストレージクラスを作成します。

kubectl create -f gp2-storage-class.yaml

出力:

storageclass "gp2" created

デフォルトストレージクラスを定義するには

1. クラスターの既存のストレージクラスを一覧表示します。デフォルトとして設定する前に、ストレージクラスを定義する必要があります。

kubectl get storageclass

出力:

NAME PROVISIONER AGEgp2 kubernetes.io/aws-ebs 8m

2. ストレージクラスを選択して、storageclass.kubernetes.io/is-default-class=true 注釈を設定することで、デフォルトに設定できます。

kubectl patch storageclass gp2 -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

出力:

storageclass "gp2" patched

3. このストレージクラスがデフォルトとして設定されていることを確認します。

kubectl get storageclass

出力:

gp2 (default) kubernetes.io/aws-ebs 12m

Amazon EBS CSI ドライバーAmazon EBS コンテナストレージインターフェイス (CSI) ドライバーは、Amazon EKS クラスターが永続的ボリュームの Amazon EBS ボリュームのライフサイクルを管理できるようにする CSI インターフェイスを提供します。

このトピックでは、Amazon EBS CSI ドライバーを Amazon EKS クラスターにデプロイし、動作することを確認する方法を示します。ドライバーのバージョン v 0.4.0 を使用することをお勧めします。

Note

このドライバーは、Kubernetes バージョン 1.14 以降の Amazon EKS クラスターおよびワーカーノードでのみサポートされています。Fargate では、ドライバはサポートされていません。Amazon EBS CSI ドライバーのアルファ機能は、Amazon EKS クラスターではサポートされ

126



ていません。このドライバーはベータリリースです。本番稼働用に Amazon EKS によって十分にテストされ、サポートされています。ドライバーのサポートは削除されませんが、詳細は変更される可能性があります。ドライバーのスキーマまたはセマンティクスが変更された場合は、次のバージョンへの移行手順が提供されます。

使用可能なパラメータの詳細と、ドライバーの機能を示す完全な例については、GitHub の Amazon EBSコンテナストレージインターフェイス (CSI) ドライバープロジェクトを参照してください。

Amazon EBS CSI ドライバーを Amazon EKS クラスターにデプロイするには

1. ワーカーノードインスタンスプロファイルに対して、Amazon_EBS_CSI_Driver という IAM ポリシーを作成し、Amazon EBS CSI ドライバーがユーザーに代わって AWS API を呼び出せるようにします。次の AWS CLI コマンドを使用して、AWS アカウントで IAM ポリシーを作成します。GitHubでポリシードキュメントを表示することもできます。

a. GitHub からポリシードキュメントをダウンロードします。

curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-ebs-csi-driver/v0.4.0/docs/example-iam-policy.json

b. ポリシーを作成します。

aws iam create-policy --policy-name Amazon_EBS_CSI_Driver \--policy-document file://example-iam-policy.json

返されるポリシー ARN を書き留めておきます。2. ワーカーノード用の IAM ロール名を取得します。次のコマンドを使用して、aws-auth configmap を

出力します。

kubectl -n kube-system describe configmap aws-auth

出力:

Name: aws-authNamespace: kube-systemLabels: <none>Annotations: <none>

Data====mapRoles:----- groups: - system:bootstrappers - system:nodes rolearn: arn:aws:iam::111122223333:role/eksctl-alb-nodegroup-ng-b1f603c5-NodeInstanceRole-GKNS581EASPU username: system:node:{{EC2PrivateDNSName}}

Events: <none>

system:nodes グループが割り当てられている rolearn 値のロール名を記録します。前の出力例では、ロール名は eksctl-alb-Node group-ng-b1f603c5-NodeInstanceRole-GKNS581EASPUになります。クラスターの各ノードグループに 1 つの値が必要です。

3. 次のコマンドを使用して、前に識別した各ワーカーノードの IAM ロールに、新しいAmazon_EBS_CSI_Driver IAM ポリシーをアタッチします。赤いテキストは、自分の AWS アカウント番号とワーカーノードの IAM ロール名に置き換えます。

127



https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/v0.4.0/docs/example-iam-policy.json

https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/v0.4.0/docs/example-iam-policy.json


aws iam attach-role-policy \--policy-arn arn:aws:iam::111122223333:policy/Amazon_EBS_CSI_Driver \--role-name eksctl-alb-nodegroup-ng-b1f603c5-NodeInstanceRole-GKNS581EASPU

4. 次のコマンドを使用して Amazon EBS CSI ドライバーをデプロイします。

Note

このコマンドには kubectl のバージョン 1.14 以降が必要です。kubectl のバージョンは、以下のコマンドを使用して確認できます。kubectl バージョンをインストールまたはアップグレードするには、「kubectl のインストール (p. 190)」を参照してください。

kubectl version --client --short

kubectl apply -k "github.com/kubernetes-sigs/aws-ebs-csi-driver/deploy/kubernetes/overlays/stable/?ref=master"

サンプルアプリケーションをデプロイし、CSI ドライバーが動作していることを確認するには

この手順では、Amazon EBS コンテナストレージインターフェイス (CSI) ドライバー GitHub リポジトリの動的ボリュームプロビジョニングの例を使用して、動的にプロビジョニングされた Amazon EBS ボリュームを使用します。

1. Amazon EBS コンテナストレージインターフェイス (CSI) ドライバー GitHub リポジトリをローカルシステムにクローンします。

git clone https://github.com/kubernetes-sigs/aws-ebs-csi-driver.git

2. dynamic-provisioning サンプルディレクトリに移動します。

cd aws-ebs-csi-driver/examples/kubernetes/dynamic-provisioning/

3. specs ディレクトリから、ebs-sc ストレージクラス、ebs-claim 永続ボリュームクレーム、および app サンプルアプリケーションをデプロイします。

kubectl apply -f specs/

4. ebs-sc ストレージクラスについて説明します。

kubectl describe storageclass ebs-sc

出力:

Name: ebs-scIsDefaultClass: NoAnnotations: kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"storage.k8s.io/v1","kind":"StorageClass","metadata":{"annotations":{},"name":"ebs-sc"},"provisioner":"ebs.csi.aws.com","volumeBindingMode":"WaitForFirstConsumer"}

Provisioner: ebs.csi.aws.comParameters: <none>AllowVolumeExpansion: <unset>MountOptions: <none>ReclaimPolicy: DeleteVolumeBindingMode: WaitForFirstConsumer

128


https://github.com/kubernetes-sigs/aws-ebs-csi-driver/tree/master/examples/kubernetes/dynamic-provisioning



Events: <none>

このストレージクラスは WaitForFirstConsumer ボリュームバインドモードを使用していることに注意してください。つまり、ポッドが永続的ボリュームのクレームを行うまで、ボリュームは動的にプロビジョニングされません。詳細については、Kubernetes ドキュメントの「ボリュームバインドモード」を参照してください。

5. デフォルトの名前空間のポッドを監視し、app ポッドが準備されるまで待ちます。

kubectl get pods --watch

6. デフォルトの名前空間の永続的ボリュームを一覧表示します。default/ebs-claim クレームがある永続的なボリュームを探します。

kubectl get pv

出力:

NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGEpvc-37717cd6-d0dc-11e9-b17f-06fad4858a5a 4Gi RWO Delete Bound default/ebs-claim ebs-sc 30s

7. 永続的ボリュームの詳細を表示します。

kubectl describe pv pvc-37717cd6-d0dc-11e9-b17f-06fad4858a5a

出力:

Name: pvc-37717cd6-d0dc-11e9-b17f-06fad4858a5aLabels: <none>Annotations: pv.kubernetes.io/provisioned-by: ebs.csi.aws.comFinalizers: [kubernetes.io/pv-protection external-attacher/ebs-csi-aws-com]StorageClass: ebs-scStatus: BoundClaim: default/ebs-claimReclaim Policy: DeleteAccess Modes: RWOVolumeMode: FilesystemCapacity: 4GiNode Affinity: Required Terms: Term 0: topology.ebs.csi.aws.com/zone in [regiona]Message:Source: Type: CSI (a Container Storage Interface (CSI) volume source) Driver: ebs.csi.aws.com VolumeHandle: vol-0d651e157c6d93445 ReadOnly: false VolumeAttributes: storage.kubernetes.io/csiProvisionerIdentity=1567792483192-8081-ebs.csi.aws.comEvents: <none>

Amazon EBS ボリューム ID は VolumeHandle として表示されます。8. ポッドがボリュームにデータを正常に書き込んでいることを確認します。

kubectl exec -it app cat /data/out.txt

129

https://kubernetes.io/docs/concepts/storage/storage-classes/#volume-binding-mode

https://kubernetes.io/docs/concepts/storage/storage-classes/#volume-binding-mode

Amazon EKS ユーザーガイドAmazon EFS CSI ドライバー

出力:

Fri Sep 6 19:26:53 UTC 2019Fri Sep 6 19:26:58 UTC 2019Fri Sep 6 19:27:03 UTC 2019Fri Sep 6 19:27:08 UTC 2019Fri Sep 6 19:27:13 UTC 2019Fri Sep 6 19:27:18 UTC 2019

9. 実験が終了したら、このサンプルアプリケーションのリソースを削除してクリーンアップします。

kubectl delete -f specs/

Amazon EFS CSI ドライバーAmazon EFS コンテナストレージインターフェイス (CSI) ドライバーは、Amazon EKS クラスターがファイルシステムの Amazon EFS ボリュームのライフサイクルを管理できるようにする CSI インターフェイスを提供します。

このトピックでは、Amazon EFS CSI ドライバーを Amazon EKS クラスターにデプロイし、動作することを確認する方法を示します。

Note

このドライバーは、Kubernetes バージョン 1.14 以降の Amazon EKS クラスターおよびワーカーノードでサポートされています。Fargate では、ドライバはサポートされていません。AmazonEFS CSI ドライバーのアルファ機能は、Amazon EKS クラスターではサポートされていません。このドライバーはベータリリースです。本番稼働用に Amazon EKS によって十分にテストされ、サポートされています。ドライバーのサポートは削除されませんが、詳細は変更される可能性があります。ドライバーのスキーマまたはセマンティクスが変更された場合は、次のバージョンへの移行手順が提供されます。

使用可能なパラメータの詳細と、ドライバーの機能を示す完全な例については、GitHub の Amazon EFSコンテナストレージインターフェイス (CSI) ドライバープロジェクトを参照してください。

Amazon EFS CSI ドライバーを Amazon EKS クラスターにデプロイするには

• 次のコマンドを使用して Amazon EFS CSI ドライバーをデプロイします。

Note

このコマンドには kubectl バージョン 1.14 以降が必要です。kubectl のバージョンは、以下のコマンドを使用して確認できます。kubectl バージョンをインストールまたはアップグレードするには、「kubectl のインストール (p. 190)」を参照してください。

kubectl version --client --short

kubectl apply -k "github.com/kubernetes-sigs/aws-efs-csi-driver/deploy/kubernetes/overlays/stable/?ref=master"

Amazon EKS クラスターの Amazon EFS ファイルシステムを作成するには

1. Amazon EKS クラスターの VPC ID を見つけます。この ID は Amazon EKS コンソールで確認するか、次の AWS CLI コマンドを使用できます。

130





aws eks describe-cluster --name cluster_name --query "cluster.resourcesVpcConfig.vpcId" --output text

出力:

vpc-exampledb76d3e813

2. クラスターの VPC の CIDR 範囲を見つけます。これは Amazon VPC コンソールで確認するか、次のAWS CLI コマンドを使用できます。

aws ec2 describe-vpcs --vpc-ids vpc-exampledb76d3e813 --query "Vpcs[].CidrBlock" --output text

出力:

192.168.0.0/16

3. Amazon EFS マウントポイントのインバウンド NFS トラフィックを許可するセキュリティグループを作成します。

a. Amazon VPC コンソール (https://console.aws.amazon.com/vpc/) を開きます。b. 左のナビゲーションペインで [セキュリティグループ]、[セキュリティグループの作成] の順に選

択します。c. セキュリティグループの名前と説明を入力し、Amazon EKS クラスターが使用している VPC を

選択します。d. [作成]、[閉じる] の順に選択して終了します。

4. VPC CIDR 範囲からのインバウンド NFS トラフィックを許可するルールをセキュリティグループに追加します。

a. 前のステップで作成したセキュリティグループを選択します。b. [インバウンドルール] タブを選択してから、[ルールの編集] を選択します。c. [ルールの追加] を選択し、以下のフィールドに入力して、[Save rules (ルールの保存)] を選択しま

す。

• [タイプ]: NFS• [ソース]: カスタムVPC CIDR 範囲を貼り付けます。• [説明]:「VPC 内からのインバウンド NFS トラフィックを許可する」などの説明を追加しま

す。5. Amazon EKS クラスターに Amazon EFS ファイルシステムを作成します。

a. Amazon Elastic File System コンソール (https://console.aws.amazon.com/efs/) を開きます。b. [Create file system] を選択します。c. [Configure file system access (ファイルシステムアクセスの設定)] ページで、Amazon EKS クラ

スターが使用している VPC を選択します。d. [セキュリティグループ] で、前のセクションで作成したセキュリティグループを各マウントター

ゲットに追加し [次のステップ] を選択します。e. ファイルシステムのオプション設定を行い、[次のステップ] および [ファイルシステムの作成] を

選択して終了します。

Important

デフォルトでは、新しい Amazon EFS ファイルシステムは root:root によって所有され、root ユーザー (UID 0) のみが読み取り/書き込み/実行のアクセス許可があります。

131

https://console.aws.amazon.com/vpc/

https://console.aws.amazon.com/efs/


コンテナが root として実行されていない場合は、Amazon EFS ファイルシステムのアクセス許可を変更して、他のユーザーがファイルシステムを変更できるようにする必要があります。詳細については、『Amazon Elastic File System ユーザーガイド』の「ネットワークファイルシステム (NFS) レベルでのユーザー、グループ、アクセス許可の使用」を参照してください。

サンプルアプリケーションをデプロイし、CSI ドライバーが動作していることを確認するには

この手順では、Amazon EFS コンテナストレージインターフェイス (CSI) ドライバー GitHub リポジトリの Multiple Pods Read Write Many の例を使用して、静的にプロビジョニングされた Amazon EFS 永続ボリュームを使用し、ReadWriteMany アクセスモードで複数のポッドからアクセスします。

1. Amazon EFS コンテナストレージインターフェイス (CSI) ドライバー GitHub リポジトリをローカルシステムにクローンします。

git clone https://github.com/kubernetes-sigs/aws-efs-csi-driver.git

2. multiple_pods サンプルディレクトリに移動します。

cd aws-efs-csi-driver/examples/kubernetes/multiple_pods/

3. Amazon EFS ファイルシステム ID を取得します。これは Amazon EFS コンソールで確認するか、次の AWS CLI コマンドを使用します。

aws efs describe-file-systems --query "FileSystems[*].FileSystemId" --output text

出力:

fs-582a03f3

4. specs/pv.yaml ファイルを編集し、volumeHandle 値を Amazon EFS ファイルシステム ID に置き換えます。

apiVersion: v1kind: PersistentVolumemetadata: name: efs-pvspec: capacity: storage: 5Gi volumeMode: Filesystem accessModes: - ReadWriteMany persistentVolumeReclaimPolicy: Retain storageClassName: efs-sc csi: driver: efs.csi.aws.com volumeHandle: fs-582a03f3

Note

Amazon EFS は伸縮自在なファイルシステムであるため、ファイルシステムの容量制限は強制されません。永続ボリュームと永続ボリュームクレームの実際のストレージ容量の値は、ファイルシステムを作成するときには使用されません。ただし、ストレージ容量はKubernetes の必須フィールドであるため、この例では 5Gi などの有効な値を指定する必要があります。この値は、Amazon EFS ファイルシステムのサイズを制限しません。

132

https://docs.aws.amazon.com/efs/latest/ug/accessing-fs-nfs-permissions.html




https://github.com/kubernetes-sigs/aws-efs-csi-driver/tree/master/examples/kubernetes/multiple_pods



5. specs ディレクトリから、efs-sc ストレージクラス、efs-claim 永続ボリュームクレーム、efs-pv 永続ボリューム、app1 および app2 サンプルアプリケーションをデプロイします。

kubectl apply -f specs/

6. デフォルトの名前空間のポッドを監視し、app1 および app2 ポッドが準備されるまで待ちます。

kubectl get pods --watch

7. デフォルトの名前空間の永続的ボリュームを一覧表示します。default/efs-claim クレームがある永続的なボリュームを探します。

kubectl get pv

出力:

NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGEefs-pv 5Gi RWX Retain Bound default/efs-claim efs-sc 2m50s

8. 永続的ボリュームの詳細を表示します。

kubectl describe pv efs-pv

出力:

Name: efs-pvLabels: <none>Annotations: kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"v1","kind":"PersistentVolume","metadata":{"annotations":{},"name":"efs-pv"},"spec":{"accessModes":["ReadWriteMany"],"capaci... pv.kubernetes.io/bound-by-controller: yesFinalizers: [kubernetes.io/pv-protection]StorageClass: efs-scStatus: BoundClaim: default/efs-claimReclaim Policy: RetainAccess Modes: RWXVolumeMode: FilesystemCapacity: 5GiNode Affinity: <none>Message:Source: Type: CSI (a Container Storage Interface (CSI) volume source) Driver: efs.csi.aws.com VolumeHandle: fs-582a03f3 ReadOnly: false VolumeAttributes: <none>Events: <none>

Amazon EFS ファイルシステム ID は VolumeHandle として表示されます。9. app1 ポッドがボリュームにデータを正常に書き込んでいることを確認します。

kubectl exec -ti app1 -- tail /data/out1.txt

出力:

133

Amazon EKS ユーザーガイドAmazon FSx for Lustre CSI ドライバー

Wed Sep 18 20:30:48 UTC 2019Wed Sep 18 20:30:53 UTC 2019Wed Sep 18 20:30:58 UTC 2019Wed Sep 18 20:31:03 UTC 2019Wed Sep 18 20:31:08 UTC 2019Wed Sep 18 20:31:13 UTC 2019

10. app2 ポッドがボリューム内に同じデータを表示していることを確認します。

kubectl exec -ti app2 -- tail /data/out1.txt

出力:

Wed Sep 18 20:30:48 UTC 2019Wed Sep 18 20:30:53 UTC 2019Wed Sep 18 20:30:58 UTC 2019Wed Sep 18 20:31:03 UTC 2019Wed Sep 18 20:31:08 UTC 2019Wed Sep 18 20:31:13 UTC 2019

11. 実験が終了したら、このサンプルアプリケーションのリソースを削除してクリーンアップします。

kubectl delete -f specs/

Amazon FSx for Lustre CSI ドライバーAmazon FSx for Lustre コンテナストレージインターフェイス (CSI) ドライバーは、Amazon EKS クラスターがファイルシステムの Amazon FSx for Lustre ボリュームのライフサイクルを管理できるようにするCSI インターフェイスを提供します。

このトピックでは、Amazon FSx for Lustre CSI ドライバーを Amazon EKS クラスターにデプロイし、動作することを確認する方法を示します。ドライバーのバージョン 0.3.0 を使用することをお勧めします。

Note

このドライバーは、Kubernetes バージョン 1.16 以降の Amazon EKS クラスターおよびワーカーノードでサポートされています。Fargate では、ドライバはサポートされていません。AmazonFSx for Lustre CSI ドライバーのアルファ機能は、Amazon EKS クラスターではサポートされていません。このドライバーはベータリリースです。本番稼働用に Amazon EKS によって十分にテストされ、サポートされています。ドライバーのサポートは削除されませんが、詳細は変更される可能性があります。ドライバーのスキーマまたはセマンティクスが変更された場合は、次のバージョンへの移行手順が提供されます。

使用可能なパラメータの詳細と、ドライバーの機能を示す完全な例については、GitHub の Amazon FSxfor Lustre コンテナストレージインターフェイス (CSI) ドライバープロジェクトを参照してください。

前提条件

必要なもの:

• AWS CLI のバージョン 1.18.49 以降がインストールされていること。現在インストールされているバージョンは、aws --version コマンドで確認できます。AWS CLI をインストールまたはアップグレードするには、「AWS CLI のインストール」を参照してください。

• 既存の Amazon EKS クラスター。現在クラスターがない場合は、「??? (p. 3)」を参照してクラスターを作成します。

134






• eksctl のバージョン 0.19.0 以降がインストールされていること。現在インストールされているバージョンは、eksctl version コマンドで確認できます。eksctl をインストールまたはアップグレードする方法については、「eksctl のインストールまたはアップグレード (p. 206)」を参照してください。

• クラスターのバージョンに合った、kubectl の最新バージョンがインストールされていること。現在インストールされているバージョンは、kubectl version --short --client コマンドで確認できます。詳細については、「kubectl のインストール (p. 190)」を参照してください。

Amazon FSx for Lustre CSI ドライバーを Amazon EKS クラスターにデプロイするには

1. AWS Identity and Access Management OIDC プロバイダーを作成し、クラスターに関連付けます。

eksctl utils associate-iam-oidc-provider \ --region region-code \ --cluster prod \ --approve

2. ドライバーがユーザーに代わって AWS API を呼び出すことを許可する IAM ポリシーとサービスアカウントを作成します。

a. 次のテキストをコピーし、fsx-csi-driver.json という名前のファイルに保存します。

{ "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Action":[ "iam:CreateServiceLinkedRole", "iam:AttachRolePolicy", "iam:PutRolePolicy" ], "Resource":"arn:aws:iam::*:role/aws-service-role/s3.data-source.lustre.fsx.amazonaws.com/*" }, { "Action":"iam:CreateServiceLinkedRole", "Effect":"Allow", "Resource":"*", "Condition":{ "StringLike":{ "iam:AWSServiceName":[ "fsx.amazonaws.com" ] } } }, { "Effect":"Allow", "Action":[ "s3:ListBucket", "fsx:CreateFileSystem", "fsx:DeleteFileSystem", "fsx:DescribeFileSystems" ], "Resource":[ "*" ] } ]}

135


b. ポリシーを作成します。

aws iam create-policy \ --policy-name Amazon_FSx_Lustre_CSI_Driver \ --policy-document file://fsx-csi-driver.json

返されるポリシー Amazon リソースネーム (ARN) を書き留めておきます。3. ドライバーの Kubernetes サービスアカウントを作成し、ポリシーをサービスアカウントにアタッチ

します。ポリシーの ARN を、前のステップで返された ARN に置き換えます。

eksctl create iamserviceaccount \ --region region-code \ --name fsx-csi-controller-sa \ --namespace kube-system \ --cluster prod \ --attach-policy-arn arn:aws:iam::111122223333:policy/Amazon_FSx_Lustre_CSI_Driver \ --approve

出力:

サービスアカウントが作成されると、数行の出力が表示されます。出力の最後の行は、次のサンプル行のようになります。

[✓] created serviceaccount "kube-system/fsx-csi-controller-sa"

デプロイされた AWS CloudFormation スタックの名前を書き留めておきます。上記の出力例では、スタックの名前は eksctl-prod-addon-iamserviceaccount-kube-system-fsx-csi-controller-sa です。

4. 作成されたロールのロール ARN を書き留めます。

a. AWS CloudFormation コンソール (https://console.aws.amazon.com/cloudformation) を開きます。b. コンソールが IAM ロールを作成したリージョンに設定されていることを確認してから、[スタッ

ク] を選択します。c. eksctl-prod-addon-iamserviceaccount-kube-system-fsx-csi-controller-sa とい

う名前のスタックを選択します。d. [出力] タブを選択します。[ロール ARN] が [Output(1)] ページに表示されます。

5. 次のコマンドでドライバーをデプロイします。

kubectl apply -k "github.com/kubernetes-sigs/aws-fsx-csi-driver/deploy/kubernetes/overlays/stable/?ref=master"

出力

Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl applyserviceaccount/fsx-csi-controller-sa configuredclusterrole.rbac.authorization.k8s.io/fsx-csi-external-provisioner-role createdclusterrolebinding.rbac.authorization.k8s.io/fsx-csi-external-provisioner-binding createddeployment.apps/fsx-csi-controller createddaemonset.apps/fsx-csi-node createdcsidriver.storage.k8s.io/fsx.csi.aws.com created

6. ドライバーのデプロイにパッチを適用し、ステップ 3 で作成したサービスアカウントを追加します。ARN を、ステップ 4 で書き留めた ARN に置き換えます。

136



kubectl annotate serviceaccount -n kube-system fsx-csi-controller-sa \ eks.amazonaws.com/role-arn=arn:aws:iam::111122223333:role/eksctl-prod-addon-iamserviceaccount-kube-sys-Role1-NPFTLHJ5PJF5 --overwrite=true

Kubernetes ストレージクラス、永続的なボリューム要求、およびサンプルアプリケーションをデプロイして、CSI ドライバーが動作していることを確認するには

この手順では、Amazon FSx for Lustre コンテナストレージインターフェイス (CSI) ドライバー GitHub リポジトリから、Amazon S3 の動的ボリュームプロビジョニングを使用して、動的にプロビジョニングされた Amazon FSx for Lustre ボリュームを使用します。

1. ファイルを作成し、バケットにコピーすることにより、Amazon S3 バケットおよび export という名前のフォルダをそのボリュームに作成します。

aws s3 mb s3://fsx-csiecho test-file >> testfileaws s3 cp testfile s3://fsx-csi/export/testfile

2. 次のコマンドを使って、storageclass マニフェストをダウンロードします。

curl -o storageclass.yaml https://raw.githubusercontent.com/kubernetes-sigs/aws-fsx-csi-driver/master/examples/kubernetes/dynamic_provisioning_s3/specs/storageclass.yaml

3. ファイルを編集し、既存の値 alternate-colored を独自の値に置き換えます。

parameters: subnetId: subnet-056da83524edbe641 securityGroupIds: sg-086f61ea73388fb6b s3ImportPath: s3://ml-training-data-000 s3ExportPath: s3://ml-training-data-000/export deploymentType: SCRATCH_2

• subnetId – Amazon FSx for Lustre ファイルシステムが作成されるサブネット ID。Amazon FSx forLustre は、すべてのアベイラビリティーゾーンでサポートされているわけではありません。https://console.aws.amazon.com/fsx/ で Amazon FSx for Lustre コンソールを開き、使用するサブネットが、サポートされているアベイラビリティーゾーンにあることを確認します。サブネットには、ワーカーノードを含めることも、別のサブネットまたは VPC にすることもできます。指定するサブネットが、ワーカーノードがあるサブネットと同じでない場合は、VPC を接続し、セキュリティグループで必要なポートが開いていることを確認する必要があります。

• securityGroupIds – ワーカーノードのセキュリティグループ ID。• s3ImportPath – 永続ボリュームへのデータのコピー元となる Amazon Simple Storage Service デー

タリポジトリ。ステップ 1 で作成した fsx-csi バケットを指定します。• s3ExportPath – 新規ファイルまたは変更されたファイルのエクスポート先となる Amazon S3 デー

タリポジトリ。ステップ 1 で作成した fsx-csi/export フォルダを指定します。• deploymentType– ファイルシステムのデプロイタイプ。有効な値

は、SCRATCH_1、SCRATCH_2、PERSISTENT_1 です。デプロイの種類の詳細については、「Amazon FSx for Lustre ファイルシステムを作成する」を参照してください。

Note

s3ImportPath および s3ExportPath の Amazon S3 バケットは同じである必要があります。そうでない場合、ドライバーは Amazon FSx for Lustre ファイルシステムを作成できません。s3ImportPath はスタンドアロンとすることができます。ランダムなパスは、s3://

137


https://github.com/kubernetes-sigs/aws-fsx-csi-driver/tree/master/examples/kubernetes/dynamic_provisioning_s3

https://console.aws.amazon.com/fsx/

https://console.aws.amazon.com/fsx/

https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/amazon-vpc-to-amazon-vpc-connectivity-options.html

https://docs.aws.amazon.com/fsx/latest/LustreGuide/getting-started-step1.html


ml-training-data-000/FSxLustre20190308T012310Z のように自動的に作成されます。S3ImportPath の値を指定しないと、s3ExportPath は使用できません。

4. storageclass を作成します。

kubectl apply -f storageclass.yaml

5. 永続的なボリューム要求マニフェストをダウンロードします。

curl -o claim.yaml https://raw.githubusercontent.com/kubernetes-sigs/aws-fsx-csi-driver/master/examples/kubernetes/dynamic_provisioning_s3/specs/claim.yaml

6. (オプション) claim.yaml ファイルを編集します。ストレージ要件と前の手順で選択したdeploymentType に基づいて、次のイを以下のいずれかの増分値に変更します。

storage: 1200Gi

• SCRATCH_2 および PERSISTENT – 1.2 TiB、2.4 TiB、または 2.4 TiB を超える 2.4 TiB の増分。• SCRATCH_1 – 1.2 TiB、2.4 TiB、3.6TiB、または 3.6 TiB を超える 3.6TiB の増分。

7. 永続的なボリューム要求を作成します。

kubectl apply -f claim.yaml

8. ファイルシステムがプロビジョニングされていることを確認します。

kubectl get pvc

出力。

NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGEfsx-claim Bound pvc-15dad3c1-2365-11ea-a836-02468c18769e 1200Gi RWX fsx-sc 7m37s

Note

STATUS は、Bound になる前に 5～10 分間 Pending と表示されることがあります。STATUS が Bound になるまで次のステップに進まないでください。

9. サンプルアプリケーションをデプロイします。

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-fsx-csi-driver/master/examples/kubernetes/dynamic_provisioning_s3/specs/pod.yaml

10. サンプルアプリケーションが実行中であることを確認します。

kubectl get pods

出力

NAME READY STATUS RESTARTS AGEfsx-app 1/1 Running 0 8s

Amazon FSx for Lustre ファイルシステムから Amazon S3 ファイルへのアクセス138


データをインポートし、変更や作成を行わずに読み取る場合は、storageclass.yaml ファイルでs3ExportPath の値は必要ありません。データがサンプルアプリケーションによって Amazon FSx forLustre ファイルシステムに書き込まれたことを確認します。

kubectl exec -it fsx-app ls /data

出力。

export out.txt

サンプルアプリケーションは、ファイルシステムに out.txt ファイルを書き込みました。

s3ExportPath へのファイルのアーカイブ

新しいファイルおよび変更されたファイルについては、Lustre ユーザースペースツールを使用して、s3ExportPath に指定した値を使用してデータを Amazon S3 にアーカイブすることができます。

1. ファイルを Amazon S3 にエクスポートします。

kubectl exec -ti fsx-app -- lfs hsm_archive /data/out.txt

Note

• 新しいファイルは Amazon S3 に自動的に同期されません。s3ExportPath にファイルを同期するには、コンテナイメージに Lustre クライアントをインストールし、lfshsm_archive コマンドを手動で実行する必要があります。コンテナは、CAP_SYS_ADMIN機能を持つ特権モードで実行する必要があります。

• この例では、デモンストレーションのため、ライフサイクルフックを使用して Lustre クライアントをインストールします。通常のアプローチでは、Lustre クライアントでコンテナイメージを構築します。

2. out.txt ファイルが Amazon S3 の s3ExportPath フォルダに書き込まれたことを確認します。

aws s3 ls fsx-csi/export/

出力

2019-12-23 12:11:35 4553 out.txt2019-12-23 11:41:21 10 testfile

139

https://docs.aws.amazon.com/fsx/latest/LustreGuide/install-lustre-client.html

Amazon EKS ユーザーガイドCluster Autoscaler

Auto Scalingこの章では、Amazon EKS クラスターのさまざまな Auto Scaling 設定について説明します。Amazon EKSでサポートされている Kubernetes Auto Scaling には、いくつかのタイプがあります。

• Cluster Autoscaler (p. 140) — Kubernetes Cluster Autoscaler は、リソース不足が原因でポッドが起動できなかった場合、またはクラスター内のノードの利用率が低く、そのポッドをクラスター内の他のノードに再スケジュールできる場合に、クラスター内のノードの数を自動的に調整します。

• Horizontal Pod Autoscaler (p. 144) — Kubernetes Horizontal Pod Autoscaler は、そのリソースの CPU使用率に基づいて、デプロイ、レプリケーションコントローラー、またはレプリカセット内のポッドの数を自動的にスケーリングします。

• Vertical Pod Autoscaler (p. 146) — Kubernetes Vertical Pod Autoscaler は、ポッドの CPU とメモリの予約を自動的に調整し、アプリケーションを「適切なサイズ」にします。これにより、クラスターリソースを効率的に使用し、CPU とメモリを他のポッドに解放できます。

Cluster AutoscalerKubernetes Cluster Autoscaler は、リソース不足が原因でポッドが起動できなかった場合、またはクラスター内のノードの利用率が低く、そのポッドをクラスター内の他のノードに再スケジュールできる場合に、クラスター内のノードの数を自動的に調整します。

このトピックでは、Cluster Autoscaler を Amazon EKS クラスターにデプロイする方法と Amazon EC2Auto Scaling グループを変更するために設定する方法について説明します。Cluster Autoscaler は、より多くのリソースが必要な場合はスケールアウトし、リソース使用率が低い場合はスケールインするように、ワーカーノードグループを変更します。

Amazon EKS クラスターを作成します。このセクションでは、クラスターおよびノードグループを作成できます。クラスターがすでに存在する場合は、Cluster Autoscaler ノードグループの考慮事項 (p. 141) に進んでください。

Amazon EBS ボリュームによってバックアップされ、Kubernetes Cluster Autoscaler (p. 140) を使用する複数のアベイラビリティーゾーンにわたってステートフルアプリケーションを実行している場合、それぞれが単一のアベイラビリティーゾーンにスコープされる複数のノードグループを設定する必要があります。また、--balance-similar-node-groups 機能を有効にする必要があります。しない場合は、複数のアベイラビリティーゾーンにまたがる 1 つのノードグループを作成できます。

要件に合うクラスター作成手順を 1 つ選択してください。

複数のアベイラビリティーゾーンにまたがる 1 つのマネージド型グループを持つクラスターを作成するには

• 次の eksctl コマンドを使用して、単一のマネージド型ノードグループを持つ Amazon EKS クラスターを作成します。詳細については、「Amazon EKS クラスターの作成 (p. 22)」を参照してください。イイイイイイは独自の値に置き換えてください。

eksctl create cluster --name my-cluster --version 1.16 --managed --asg-access

アベイラビリティーゾーンを示す出力部分:

...

140


Amazon EKS ユーザーガイドCluster Autoscaler ノードグループの考慮事項

[✓] using region region-code[✓] setting availability zones to [region-codea region-codeb region-codec][✓] subnets for region-codea - public:192.168.0.0/19 private:192.168.96.0/19[✓] subnets for region-codeb - public:192.168.32.0/19 private:192.168.128.0/19[✓] subnets for region-codec - public:192.168.64.0/19 private:192.168.160.0/19...[✓] nodegroup "ng-6bcca56a" has 2 node(s)[✓] node "ip-192-168-28-68.region-code.compute.internal" is ready[✓] node "ip-192-168-61-153.region-code.compute.internal" is ready[✓] waiting for at least 2 node(s) to become ready in "ng-6bcca56a"[✓] nodegroup "ng-6bcca56a" has 2 node(s)[✓] node "ip-192-168-28-68.region-code.compute.internal" is ready[✓] node "ip-192-168-61-153.region-code.compute.internal" is ready...[✓] EKS cluster "my-cluster" in "region-code" region-code is ready

各アベイラビリティーゾーンの専用マネージド型ノードグループを持つクラスターを作成するには

1. eksctl 次のコマンドを使用して、ノードグループなしで Amazon EKS クラスターを作成します。詳細については、「Amazon EKS クラスターの作成 (p. 22)」を参照してください。クラスターが作成されたアベイラビリティーゾーンを書き留めます。これらのアベイラビリティーゾーンは、ノードグループを作成するときに使用します。赤い変数テキストは独自の値に置き換えてください。

eksctl create cluster --name my-cluster --version 1.16 --without-nodegroup

アベイラビリティーゾーンを示す出力部分:

...[✓] using region region-code[✓] setting availability zones to [region-codea region-codec region-codeb][✓] subnets for region-codea - public:192.168.0.0/19 private:192.168.96.0/19[✓] subnets for region-codec - public:192.168.32.0/19 private:192.168.128.0/19[✓] subnets for region-codeb - public:192.168.64.0/19 private:192.168.160.0/19...[✓] EKS cluster "my-cluster" in "region-code" region is ready

このクラスターは、アベイラビリティーゾーン region-codea、region-codec、region-codebで作成されました。

2. クラスター内のアベイラビリティーゾーンごとに、次の eksctl コマンドを使用してノードグループを作成します。イイイイイイは独自の値に置き換えてください。このコマンドは、最小数が 1、最大数が10 の Auto Scaling グループを作成します。

eksctl create nodegroup --cluster my-cluster --node-zones region-codea --name region-codea --asg-access --nodes-min 1 --nodes 5 --nodes-max 10 --managed

Cluster Autoscaler ノードグループの考慮事項Cluster Autoscaler には、このセクションで説明する追加の IAM およびリソースタグ付けに関する考慮事項が必要です。

ノードグループ IAM ポリシーCluster Autoscaler では、ユーザーに代わって AWS API を呼び出すために、次の IAM アクセス許可が必要です。

141

Amazon EKS ユーザーガイドCluster Auto Scaling をデプロイする

前述の eksctl コマンドを使用してノードグループを作成した場合、これらのアクセス許可は自動的に提供され、ワーカーノードの IAM ロールにアタッチされます。eksctl を使用しなかった場合は、次のドキュメントを使用して IAM ポリシーを作成し、ワーカーノードの IAM ロールにアタッチする必要があります。詳細については、『IAM ユーザーガイド』の「ロールの修正」を参照してください。

{ "Version": "2012-10-17", "Statement": [ { "Action": [ "autoscaling:DescribeAutoScalingGroups", "autoscaling:DescribeAutoScalingInstances", "autoscaling:DescribeLaunchConfigurations", "autoscaling:DescribeTags", "autoscaling:SetDesiredCapacity", "autoscaling:TerminateInstanceInAutoScalingGroup", "ec2:DescribeLaunchTemplateVersions" ], "Resource": "*", "Effect": "Allow" } ]}

Auto Scaling グループタグCluster Auto Scaling では、自動検出できるように、ノードグループ Auto Scaling グループに以下のタグが必要です。

前述の eksctl コマンドを使用してノードグループを作成した場合、これらのタグは自動的に適用されます。そうでない場合は、Auto Scaling グループに以下のタグを手動でタグ付けする必要があります。詳細については、『Linux インスタンス用 Amazon EC2 ユーザーガイド』の「Amazon EC2 リソースにタグを付ける」を参照してください。

キー値

k8s.io/cluster-autoscaler/<cluster-name>

owned

k8s.io/cluster-autoscaler/enabled true

Cluster Auto Scaling をデプロイするCluster Auto Scaling をデプロイするには

1. 次のコマンドを使用して Cluster Autoscaler をクラスターにデプロイします。

kubectl apply -f https://raw.githubusercontent.com/kubernetes/autoscaler/master/cluster-autoscaler/cloudprovider/aws/examples/cluster-autoscaler-autodiscover.yaml

2. 次のコマンドを使用して、デプロイに cluster-autoscaler.kubernetes.io/safe-to-evict注釈を追加します。

kubectl -n kube-system annotate deployment.apps/cluster-autoscaler cluster-autoscaler.kubernetes.io/safe-to-evict="false"

3. 次のコマンドを使用して Cluster Autoscaler デプロイを編集します。

142

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage_modify.html

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html

Amazon EKS ユーザーガイドCluster Autoscaler ログを表示する

kubectl -n kube-system edit deployment.apps/cluster-autoscaler

cluster-autoscaler コンテナコマンドを編集して、<YOUR CLUSTER NAME> をクラスターの名前に置き換え、以下のオプションを追加します。

• --balance-similar-node-groups

• --skip-nodes-with-system-pods=false

spec: containers: - command: - ./cluster-autoscaler - --v=4 - --stderrthreshold=info - --cloud-provider=aws - --skip-nodes-with-local-storage=false - --expander=least-waste - --node-group-auto-discovery=asg:tag=k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/<YOUR CLUSTER NAME> - --balance-similar-node-groups - --skip-nodes-with-system-pods=false

ファイルを保存して閉じ、変更を適用します。4. ウェブブラウザで Cluster Autoscaler リリースページを開き、クラスターの Kubernetes メジャー

バージョンとマイナーバージョンに一致する最新の Cluster Autoscaler バージョンを見つけます。たとえば、クラスターの Kubernetes バージョンが 1.16 である場合、1.16 で始まる最新の ClusterAutoscaler リリースを見つけます。次のステップで使用するために、そのリリースのセマンティックバージョン番号 (1.16.n) を書き留めます。

5. 次のコマンドを使用して、Cluster Autoscaler イメージタグを、前のステップで書き留めたバージョンに設定します。1.15.n は、独自の値に置き換えます。us は、asia または eu に置き換えることができます。

kubectl -n kube-system set image deployment.apps/cluster-autoscaler cluster-autoscaler=us.gcr.io/k8s-artifacts-prod/autoscaling/cluster-autoscaler:v1.15.n

Note

必要とするバージョンによっては、以前のアドレスを gcr.io/google-containers/cluster-autoscaler:v1.n.n に変更する必要があります。イメージアドレスは、リリースページに一覧表示されています。

Cluster Autoscaler ログを表示するCluster Autoscaler をデプロイしたら、ログを表示してクラスターの負荷をモニタリングしていることを確認できます。

次のコマンドを使用して Cluster Autoscaler ログを表示します。

kubectl -n kube-system logs -f deployment.apps/cluster-autoscaler

出力:

I0926 23:15:55.165842 1 static_autoscaler.go:138] Starting main loop

143




Amazon EKS ユーザーガイドHorizontal Pod Autoscaler

I0926 23:15:55.166279 1 utils.go:595] No pod using affinity / antiaffinity found in cluster, disabling affinity predicate for this loopI0926 23:15:55.166293 1 static_autoscaler.go:294] Filtering out schedulablesI0926 23:15:55.166330 1 static_autoscaler.go:311] No schedulable podsI0926 23:15:55.166338 1 static_autoscaler.go:319] No unschedulable podsI0926 23:15:55.166345 1 static_autoscaler.go:366] Calculating unneeded nodesI0926 23:15:55.166357 1 utils.go:552] Skipping ip-192-168-3-111.region-code.compute.internal - node group min size reachedI0926 23:15:55.166365 1 utils.go:552] Skipping ip-192-168-71-83.region-code.compute.internal - node group min size reachedI0926 23:15:55.166373 1 utils.go:552] Skipping ip-192-168-60-191.region-code.compute.internal - node group min size reachedI0926 23:15:55.166435 1 static_autoscaler.go:393] Scale down status: unneededOnly=false lastScaleUpTime=2019-09-26 21:42:40.908059094 ...I0926 23:15:55.166458 1 static_autoscaler.go:403] Starting scale downI0926 23:15:55.166488 1 scale_down.go:706] No candidates for scale down

Horizontal Pod AutoscalerKubernetes Horizontal Pod Autoscaler は、そのリソースの CPU 使用率に基づいて、デプロイ、レプリケーションコントローラー、またはレプリカセット内のポッドの数を自動的にスケーリングします。これにより、アプリケーションは需要の増加に合わせてスケールアウトしたり、リソースが不要になったときにスケールインしたりできるため、ワーカーノードを他のアプリケーションに解放できます。ターゲットの CPU 使用率を設定すると、Horizontal Pod Autoscaler はターゲットを満たすようにアプリケーションをスケールインまたはスケールアウトします。

Horizontal Pod Autoscaler は、Kubernetes の標準の API リソースで、Amazon EKS クラスターにメトリクスソース（Kubernetes メトリクスサーバーなど）がインストールされている必要があります。アプリケーションのスケーリングを開始するために、クラスターに Horizontal Pod Autoscaler をデプロイまたはインストールする必要はありません。詳細については、Kubernetes ドキュメントの「Horizontal PodAutoscaler」を参照してください。

このトピックを使用して、Amazon EKS クラスターの Horizontal Pod Autoscaler を準備し、サンプルアプリケーションで動作することを確認します。

Note

このトピックは、Kubernetes ドキュメントの「Horizontal Pod Autoscaler ウォークスルー」に基づいています。

メトリクスサーバーのインストールKubernetes メトリクスサーバーは、クラスター内のリソース使用状況データを集約します。メトリクスサーバーは、デフォルトでは Amazon EKS クラスターにデプロイされませんが、Horizontal PodAutoscaler に必要なメトリクスを提供します。このトピックでは、Kubernetes メトリクスサーバーをAmazon EKS クラスターにデプロイする方法について説明します。

メトリクスサーバーをクラスターにすでにデプロイしている場合は、次のセクションに進むことができます。次のコマンドを使用して、メトリクスサーバーを確認できます。

kubectl -n kube-system get deployment/metrics-server

このコマンドで NotFound エラーが返された場合は、メトリクスサーバーを Amazon EKS クラスターにデプロイする必要があります。

メトリクスサーバーをデプロイするには

1. 次のコマンドを使用してメトリクスサーバーをデプロイします。

144

https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/



https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/

Amazon EKS ユーザーガイドHorizontal Pod Autoscaler テストアプリケーションを実行する

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.3.6/components.yaml

2. 次のコマンドを使用して、metrics-server デプロイメントで必要な数のポッドが実行されていることを確認します。

kubectl get deployment metrics-server -n kube-system

出力

NAME READY UP-TO-DATE AVAILABLE AGEmetrics-server 1/1 1 1 6m

Horizontal Pod Autoscaler テストアプリケーションを実行するこのセクションでは、サンプルアプリケーションをデプロイして、Horizontal Pod Autoscaler が動作していることを確認します。

Note

この例は、Kubernetes ドキュメントの「Horizontal Pod Autoscaler Walkthrough」に基づいています。

Horizontal Pod Autoscaler のインストールをテストするには

1. 次のコマンドを使用して、シンプルな Apache ウェブサーバーアプリケーションを作成します。

kubectl run httpd --image=httpd --requests=cpu=100m --limits=cpu=200m --expose --port=80

この Apache ウェブサーバーポッドには 200 millicpu の CPU 制限が与えられ、ポート 80 で提供されています。

2. httpd デプロイ用の Horizontal Pod Autoscaler リソースを作成します。

kubectl autoscale deployment httpd --cpu-percent=50 --min=1 --max=10

このコマンドは、デプロイの CPU 使用率が 50%、ポッドが最低 1 つ、ポッドが最大 10 個のAutoscaler を作成します。CPU の平均負荷が 50% を下回ると、Autoscaler はデプロイのポッド数を最小の 1 に減らそうとします。負荷が 50 パーセントを超えると、Autoscaler はデプロイのポッド数を最大の 10 まで増やそうとします。詳細については、Kubernetes ドキュメントの「Horizontal PodAutoscaler の仕組み」を参照してください。

3. 詳細を表示するには、次のコマンドで Autoscaler を説明します。

kubectl describe hpa/httpd

出力:

Name: httpdNamespace: defaultLabels: <none>

145

https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/

https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#how-does-the-horizontal-pod-autoscaler-work

https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#how-does-the-horizontal-pod-autoscaler-work

Amazon EKS ユーザーガイドVertical Pod Autoscaler

Annotations: <none>CreationTimestamp: Fri, 27 Sep 2019 13:32:15 -0700Reference: Deployment/httpdMetrics: ( current / target ) resource cpu on pods (as a percentage of request): 1% (1m) / 50%Min replicas: 1Max replicas: 10Deployment pods: 1 current / 1 desiredConditions: Type Status Reason Message ---- ------ ------ ------- AbleToScale True ReadyForNewScale recommended size matches current size ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request) ScalingLimited False DesiredWithinRange the desired count is within the acceptable rangeEvents: <none>

ご覧のとおり、現在の CPU 負荷は 1 パーセントのみですが、ポッド数は既に最低の境界 (1) にあるため、スケールインすることはできません。

4. ウェブサーバーのロードを作成します。次のコマンドでは、Apache Bench プログラムを使用して、数十万のリクエストを httpd サーバーに送信します。これにより、負荷が大幅に増加し、Autoscalerによってデプロイがスケールアウトされます。

kubectl run apache-bench -i --tty --rm --image=httpd -- ab -n 500000 -c 1000 http://httpd.default.svc.cluster.local/

5. ロードが生成される間、httpd デプロイがスケールアウトされるのを確認します。デプロイとAutoscaler を監視するには、定期的に次のコマンドを実行します。

kubectl get horizontalpodautoscaler.autoscaling/httpd

出力:

NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGEhttpd Deployment/httpd 76%/50% 1 10 10 4m50s

ロードが完了すると、デプロイは 1 にスケールダウンする必要があります。6. サンプルアプリケーションのテストが終了したら、httpd リソースを削除します。

kubectl delete deployment.apps/httpd service/httpd horizontalpodautoscaler.autoscaling/httpd

Vertical Pod AutoscalerKubernetes Vertical Pod Autoscaler は、ポッドの CPU とメモリの予約を自動的に調整し、アプリケーションを「適切なサイズ」にします。この調整により、クラスターリソースの使用率が向上し、他のポッドの CPU とメモリが解放されます。このトピックでは、Vertical Pod Autoscaler をクラスターにデプロイし、動作していることを確認する方法について説明します。

メトリクスサーバーのインストールKubernetes メトリクスサーバーは、クラスター内のリソース使用状況データを集約します。デフォルトでは Amazon EKS クラスターにデプロイされませんが、Vertical Pod Autoscaler に必要なメトリクスが提供

146

https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler

Amazon EKS ユーザーガイドVertical Pod Autoscaler をデプロイする

されます。このトピックでは、Kubernetes メトリクスサーバーを Amazon EKS クラスターにデプロイする方法について説明します。

Note

Prometheus を使用して Vertical Pod Autoscaler のメトリクスを提供することもできます。詳細については、「Prometheus を使用したプレーンメトリクスのコントロール (p. 212)」を参照してください。

メトリクスサーバーをクラスターにすでにデプロイしている場合は、次のセクションに進むことができます。次のコマンドを使用して、メトリクスサーバーを確認できます。

kubectl -n kube-system get deployment/metrics-server

このコマンドで NotFound エラーが返された場合は、メトリクスサーバーを Amazon EKS クラスターにデプロイする必要があります。






出力


Vertical Pod Autoscaler をデプロイするこのセクションでは、Vertical Pod Autoscaler をクラスターにデプロイします。

Vertical Pod Autoscaler をデプロイするには

1. ターミナルウィンドウを開き、Vertical Pod Autoscaler ソースコードをダウンロードするディレクトリに移動します。

2. kubernetes/autoscaler GitHub リポジトリのクローンを作成します。

git clone https://github.com/kubernetes/autoscaler.git

3. vertical-pod-autoscaler ディレクトリを変更します。

cd autoscaler/vertical-pod-autoscaler/

4. （オプション） Vertical Pod Autoscaler の別のバージョンをすでにデプロイしている場合は、次のコマンドを使用して削除します。

./hack/vpa-down.sh

5. 次のコマンドを使用して、Vertical Pod Autoscaler をクラスターにデプロイします。

147

https://github.com/kubernetes/autoscaler

Amazon EKS ユーザーガイドVertical Pod Autoscaler のインストールをテストする

./hack/vpa-up.sh

6. Vertical Pod Autoscaler ポッドが正常に作成されたことを確認します。

kubectl get pods -n kube-system

出力:

NAME READY STATUS RESTARTS AGEaws-node-949vx 1/1 Running 0 122maws-node-b4nj8 1/1 Running 0 122mcoredns-6c75b69b98-r9x68 1/1 Running 0 133mcoredns-6c75b69b98-rt9bp 1/1 Running 0 133mkube-proxy-bkm6b 1/1 Running 0 122mkube-proxy-hpqm2 1/1 Running 0 122mmetrics-server-8459fc497-kfj8w 1/1 Running 0 83mvpa-admission-controller-68c748777d-ppspd 1/1 Running 0 7svpa-recommender-6fc8c67d85-gljpl 1/1 Running 0 8svpa-updater-786b96955c-bgp9d 1/1 Running 0 8s

Vertical Pod Autoscaler のインストールをテストするこのセクションでは、サンプルアプリケーションをデプロイして、Vertical Pod Autoscaler が動作していることを確認します。

Vertical Pod Autoscaler のインストールをテストするには

1. 次のコマンドを使用して hamster.yaml Vertical Pod Autoscaler の例をデプロイします。

kubectl apply -f examples/hamster.yaml

2. hamster サンプルアプリケーションからポッドを取得します。

kubectl get pods -l app=hamster

出力:

hamster-c7d89d6db-rglf5 1/1 Running 0 48shamster-c7d89d6db-znvz5 1/1 Running 0 48s

3. CPU とメモリの予約を表示するには、ポッドの 1 つを記述します。

kubectl describe pod hamster-c7d89d6db-rglf5

出力:

Name: hamster-c7d89d6db-rglf5Namespace: defaultPriority: 0Node: ip-192-168-9-44.region-code.compute.internal/192.168.9.44Start Time: Fri, 27 Sep 2019 10:35:15 -0700Labels: app=hamster pod-template-hash=c7d89d6dbAnnotations: kubernetes.io/psp: eks.privileged vpaUpdates: Pod resources updated by hamster-vpa: container 0:

148


Status: RunningIP: 192.168.23.42IPs: <none>Controlled By: ReplicaSet/hamster-c7d89d6dbContainers: hamster: Container ID: docker://e76c2413fc720ac395c33b64588c82094fc8e5d590e373d5f818f3978f577e24 Image: k8s.gcr.io/ubuntu-slim:0.1 Image ID: docker-pullable://k8s.gcr.io/ubuntu-slim@sha256:b6f8c3885f5880a4f1a7cf717c07242eb4858fdd5a84b5ffe35b1cf680ea17b1 Port: <none> Host Port: <none> Command: /bin/sh Args: -c while true; do timeout 0.5s yes >/dev/null; sleep 0.5s; done State: Running Started: Fri, 27 Sep 2019 10:35:16 -0700 Ready: True Restart Count: 0 Requests: cpu: 100m memory: 50Mi...

元のポッドは 100 millicpu の CPU と 50 メビバイトのメモリを予約していることがわかります。このサンプルアプリケーションでは、100 millicpu はポッドの実行に必要な数よりも少ないため、CPUに制約があります。また、必要とするよりもはるかに少ないメモリを予約します。Vertical PodAutoscaler vpa-recommender デプロイでは、 hamster ポッドを分析して、CPU とメモリの要件が適切かどうかを確認します。調整が必要な場合、vpa-updater は更新された値でポッドを再起動します。

4. vpa-updaterが新しい hamster ポッドを起動するまで待ちます。これには 1~2 分かかります。次のコマンドを使用して、ポッドをモニタリングできます。

Note

新しいポッドが起動されたかどうかが不明な場合は、ポッド名を前のリストと比較します。新しいポッドが起動すると、新しいポッド名が表示されます。

kubectl get --watch pods -l app=hamster

5. 新しい hamster ポッドが開始されたら、そのポッドについて説明し、更新された CPU とメモリの予約を表示します。

kubectl describe pod hamster-c7d89d6db-jxgfv

出力:

Name: hamster-c7d89d6db-jxgfvNamespace: defaultPriority: 0Node: ip-192-168-9-44.region-code.compute.internal/192.168.9.44Start Time: Fri, 27 Sep 2019 10:37:08 -0700Labels: app=hamster pod-template-hash=c7d89d6dbAnnotations: kubernetes.io/psp: eks.privileged vpaUpdates: Pod resources updated by hamster-vpa: container 0: cpu request, memory requestStatus: Running

149


IP: 192.168.3.140IPs: <none>Controlled By: ReplicaSet/hamster-c7d89d6dbContainers: hamster: Container ID: docker://2c3e7b6fb7ce0d8c86444334df654af6fb3fc88aad4c5d710eac3b1e7c58f7db Image: k8s.gcr.io/ubuntu-slim:0.1 Image ID: docker-pullable://k8s.gcr.io/ubuntu-slim@sha256:b6f8c3885f5880a4f1a7cf717c07242eb4858fdd5a84b5ffe35b1cf680ea17b1 Port: <none> Host Port: <none> Command: /bin/sh Args: -c while true; do timeout 0.5s yes >/dev/null; sleep 0.5s; done State: Running Started: Fri, 27 Sep 2019 10:37:08 -0700 Ready: True Restart Count: 0 Requests: cpu: 587m memory: 262144k...

ここでは、CPU 予約が元の値の 5 倍以上である 587 millicpu に増加したことがわかります。メモリは 262,144 キロバイト（約 250 メビバイト、つまり元の値の 5 倍）に増加しました。このポッドはリソース不足であり、Vertical Pod Autoscaler は見積りをより適切な値で修正しました。

6. hamster-vpa リソースの詳細を表示して、新しい推奨事項を表示します。

kubectl describe vpa/hamster-vpa

出力:

Name: hamster-vpaNamespace: defaultLabels: <none>Annotations: kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"autoscaling.k8s.io/v1beta2","kind":"VerticalPodAutoscaler","metadata":{"annotations":{},"name":"hamster-vpa","namespace":"d...API Version: autoscaling.k8s.io/v1beta2Kind: VerticalPodAutoscalerMetadata: Creation Timestamp: 2019-09-27T18:22:51Z Generation: 23 Resource Version: 14411 Self Link: /apis/autoscaling.k8s.io/v1beta2/namespaces/default/verticalpodautoscalers/hamster-vpa UID: d0d85fb9-e153-11e9-ae53-0205785d75b0Spec: Target Ref: API Version: apps/v1 Kind: Deployment Name: hamsterStatus: Conditions: Last Transition Time: 2019-09-27T18:23:28Z Status: True Type: RecommendationProvided Recommendation:

150


Container Recommendations: Container Name: hamster Lower Bound: Cpu: 550m Memory: 262144k Target: Cpu: 587m Memory: 262144k Uncapped Target: Cpu: 587m Memory: 262144k Upper Bound: Cpu: 21147m Memory: 387863636Events: <none>

7. サンプルアプリケーションの試用が終了したら、次のコマンドで削除します。

kubectl delete -f examples/hamster.yaml

151

Amazon EKS ユーザーガイドロードバランシング

ロードバランシングと Ingressこの章では、Amazon EKS クラスター用の以下のロードバランシングおよび Ingress の設定オプションについて説明します。

• the section called “ロードバランシング” (p. 152) – Amazon EKS は、Kubernetes の LoadBalancerサービスタイプを通じて Amazon EC2 インスタンスワーカーノードで実行されているポッドに対してAWS Network Load Balancer および Classic Load Balancer をサポートしています。

• the section called “Amazon EKS の ALB Ingress Controller” (p. 153) – AWS ALB Ingress Controller forKubernetes は、kubernetes.io/ingress.class: alb 注釈を使用して Ingress リソースがクラスターで作成されるたびに、AWS Application Load Balancer および必要な AWS サポートリソースの作成をトリガーするコントローラーです。

ロードバランシングAmazon EKS は、タイプ LoadBalancer の Kubernetes サービスを通じて Amazon EC2 インスタンスワーカーノードで実行されるポッドの Network Load Balancer および Classic Load Balancer をサポートします。Classic Load Balancer と Network Load Balancer は、AWS Fargate (Fargate) で実行されているポッドではサポートされません。Fargate 入力の場合は、Amazon EKS (最小バージョン v1.1.4) で ALBIngress Controller (p. 153) を使用することをお勧めします。

ロードバランサーの設定は、サービス用のマニフェストに追加された注釈により制御されます。デフォルトでは、Classic Load Balancer は LoadBalancer タイプのサービスに使用されます。代わりに NetworkLoad Balancer を使用するには、以下の注釈をサービスに適用します。

service.beta.kubernetes.io/aws-load-balancer-type: nlb

ロードバランサーを指定するサービスマニフェストの例については、Kubernetes ドキュメントの「TypeLoadBalancer」を参照してください。Kubernetes で Network Load Balancer を使用する方法の詳細は、Kubernetes ドキュメントの AWS のネットワークロードバランサー対応を参照してください。

デフォルトでは、LoadBalancer タイプのサービスにより、パブリック側のロードバランサーが作成されます。内部ロードバランサーを使用するには、以下の注釈をサービスに適用します。

service.beta.kubernetes.io/aws-load-balancer-internal: "true"

内部ロードバランサーの場合、Amazon EKS クラスターは、VPC 内で少なくとも 1 つのプライベートサブネットを使用するように設定されている必要があります。Kubernetes は、サブネットがパブリックかプライベートかどうかをルートテーブルで調べます。パブリックサブネットには、インターネットゲートウェイを使ったインターネットへの直接の経路がありますが、プライベートサブネットにはありません。

ロードバランサー用のサブネットのタグ付け各アベイラビリティーゾーンでパブリックサブネットを選択するのではなく (サブネット ID の辞書順)、Kubernetes がそれらのサブネットのみを外部ロードバランサーに使用することを認識できるように、VPC のパブリックサブネットをタグ付けする必要があります。03/26/2020 以降に Amazon EKS AWSCloudFormation テンプレートを使用して VPC を作成する場合、テンプレートによって作成されたサブネットは、作成時にタグ付けされます。Amazon EKS AWS CloudFormation VPC テンプレートの詳細については、「??? (p. 158)」を参照してください。

152

https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer

https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer


Amazon EKS ユーザーガイドAmazon EKS の ALB Ingress Controller

キー値

kubernetes.io/role/elb 1

プライベートサブネットは、Kubernetes が内部ロードバランサーにサブネットを使用できることを認識できるように、次のようにタグ付けする必要があります。03/26/2020 以降に Amazon EKS AWSCloudFormation テンプレートを使用して VPC を作成する場合、テンプレートによって作成されたサブネットは、作成時にタグ付けされます。Amazon EKS AWS CloudFormation VPC テンプレートの詳細については、「??? (p. 158)」を参照してください。

キー値

kubernetes.io/role/internal-elb 1

Amazon EKS の ALB Ingress ControllerAWS ALB Ingress Controller for Kubernetes は、kubernetes.io/ingress.class: alb 注釈を付けてIngress リソースがクラスターで作成されるたびに、Application Load Balancer (ALB) および必要な AWSサポートリソースの作成をトリガーするコントローラーです。Ingress リソースは ALB を設定して、HTTPまたは HTTPS トラフィックをクラスター内の別のポッドにルーティングします。ALB Ingress Controllerは、Amazon EKS クラスターで実行される本稼働用ワークロードに対応しています。

Ingress オブジェクトが ALB Ingress Controller を使用するためには、Ingress 仕様に次の注釈を追加します。詳細については、ドキュメントの「Ingress specification」を参照してください。

annotations: kubernetes.io/ingress.class: alb

ALB Ingress Controller は、次のトラフィックモードをサポートします。

• インスタンス – クラスター内のノードを ALB のターゲットとして登録します。ALB に到達するトラフィックは、サービスの NodePort にルーティングされてから、ポッドにプロキシされます。これがデフォルトのトラフィックモードです。alb.ingress.kubernetes.io/target-type: instance の注釈を使用して明示的に指定することもできます。

Note

Kubernetes サービスでは、このトラフィックモードを使用する NodePort タイプを指定する必要があります。

• IP – ポッドを ALB のターゲットとして登録します。ALB に到達するトラフィックは、サービスのポッドに直接ルーティングされます。このトラフィックモードを使用するには、alb.ingress.kubernetes.io/target-type: ip の注釈を指定する必要があります。

ALB Ingress Controller でサポートされている他の使用可能な注釈については、「Ingress annotations」を参照してください。

このトピックでは、Amazon EKS クラスターで操作できるよう ALB Ingress Controller を設定する方法について説明します。

ALB Ingress Controller を Amazon EKS クラスターにデプロイするには

1. ロードバランサーに使用する VPC のサブネットにタグを付け、そのサブネットを使用できることをALB Ingress Controller に伝えます。詳細については、「サブネットのタグ付け要件 (p. 163)」を参

153

https://github.com/kubernetes-sigs/aws-alb-ingress-controller

https://kubernetes-sigs.github.io/aws-alb-ingress-controller/guide/ingress/spec/

https://kubernetes-sigs.github.io/aws-alb-ingress-controller/guide/ingress/annotation/


照してください。ekctl を使用してクラスターをデプロイした場合は、タグがすでに適用されています。

• VPC 内のすべてのサブネットは、Kubernetes が検出できるように、個別にタグ付けする必要があります。

キー値

kubernetes.io/cluster/<cluster-name>

shared

• VPC のパブリックサブネットにタグを付け、外部ロードバランサー用のサブネットのみを使用できることを ALB Ingress Controller に伝えます。

キー値


• プライベートサブネットは、Kubernetes が内部ロードバランサーにサブネットを使用できることを認識できるように、次のようにタグ付けする必要があります。03/26/2020 以降に Amazon EKSAWS CloudFormation テンプレートを使用して VPC を作成する場合、テンプレートによって作成されたサブネットは、作成時にタグ付けされます。Amazon EKS AWS CloudFormation VPC テンプレートの詳細については、「??? (p. 158)」を参照してください。

キー値


2. IAM OIDC プロバイダーを作成し、クラスターに関連付けます。 eksctl バージョン 0.19.0 以降がインストールされていない場合は、「eksctl のインストールまたはアップグレード (p. 206)」の手順に従ってインストールまたはアップグレードします。インストールされているバージョンは、eksctlversion で確認できます。

eksctl utils associate-iam-oidc-provider \ --region region-code \ --cluster prod \ --approve

3. ユーザーに代わって AWS API を呼び出すことを ALB Ingress Controller ポッドに許可するためのALBIngressControllerIAMPolicy という IAM ポリシーを作成します。次の AWS CLI コマンドを使用して、AWS アカウントで IAM ポリシーを作成します。GitHub でポリシードキュメントを表示することもできます。

aws iam create-policy \ --policy-name ALBIngressControllerIAMPolicy \ --policy-document https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.1.4/docs/examples/iam-policy.json

返されるポリシー ARN を書き留めておきます。4. 次のコマンドを使用して、alb-ingress-controller という名前の Kubernetes サービスアカウン

トを kube-system 名前空間に作成します。さらに、クラスターロールと ALB Ingress Controller で使用するクラスターロールバインディングを作成します。kubectl をインストールしていない場合は、「kubectl のインストール (p. 190)」の手順に従ってインストールします。

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.1.4/docs/examples/rbac-role.yaml

154

https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.1.2/docs/examples/iam-policy.json


5. ALB Ingress Controller の IAM ロールを作成し、このロールを前のステップで作成したサービスアカウントにアタッチします。eksctl でクラスターを作成していない場合は、AWS マネジメントコンソールまたは AWS CLI タブの手順を使用します。

eksctl

次のコマンドは、eksctl で作成したクラスターでのみ使用できます。

eksctl create iamserviceaccount \ --region region-code \ --name alb-ingress-controller \ --namespace kube-system \ --cluster prod \ --attach-policy-arn arn:aws:iam::111122223333:policy/ALBIngressControllerIAMPolicy \ --override-existing-serviceaccounts \ --approve


1. AWS マネジメントコンソールタブで「IAM ロールを作成する (p. 271)」の手順を使用して、eks-alb-ingress-controller という名前の IAM ロールを作成し、このロールに前のステップで作成した ALBIngressControllerIAMPolicy IAM ポリシーをアタッチします。ロールを作成したら、ロールの Amazon リソースネーム (ARN) をメモします。

2. 次のコマンドを使用して、作成したロールの ARN で Kubernetes サービスアカウントに注釈を付けます。

kubectl annotate serviceaccount -n kube-system alb-ingress-controller \eks.amazonaws.com/role-arn=arn:aws:iam::111122223333:role/eks-alb-ingress-controller

AWS CLI

1. AWS CLI タブで「IAM ロールを作成する (p. 271)」の手順を使用して、eks-alb-ingress-controller という名前の IAM ロールを作成し、このロールに前のステップで作成した ALBIngressControllerIAMPolicy IAM ポリシーをアタッチします。ロールを作成したら、ロールの Amazon リソースネーム (ARN) をメモします。

2. 次のコマンドを使用して、作成したロールの ARN で Kubernetes サービスアカウントに注釈を付けます。

kubectl annotate serviceaccount -n kube-system alb-ingress-controller \eks.amazonaws.com/role-arn=arn:aws:iam::111122223333:role/eks-alb-ingress-controller

6. 次のコマンドを使用して、ALB Ingress Controller をデプロイします。

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.1.4/docs/examples/alb-ingress-controller.yaml

7. 次のコマンドを使用して、ALB Ingress Controller のデプロイマニフェストを編集のために開きます。

kubectl edit deployment.apps/alb-ingress-controller -n kube-system

8. --ingress-class=alb 行の後にクラスター名の行を追加します。Fargate で ALB IngressController を実行している場合は、VPC ID の行と、クラスターの AWS リージョン名も追加する必要があります。適切な行を追加したら、ファイルを保存して閉じます。

155


spec: containers: - args: - --ingress-class=alb - --cluster-name=prod - --aws-vpc-id=vpc-03468a8157edca5bd - --aws-region=region-code

9. 次のコマンドを使用して、ALB Ingress Controller が実行されていることを確認します。

kubectl get pods -n kube-system

正常な出力:

NAME READY STATUS RESTARTS AGEalb-ingress-controller-55b5bbcb5b-bc8q9 1/1 Running 0 56s

サンプルアプリケーションをデプロイするには

1. サンプルアプリケーションとしてゲーム 2048 をデプロイし、ALB Ingress Controller が Ingress オブジェクトの結果として Application Load Balancer を作成することを確認します。Amazon EC2 ワーカーノードのみ、1 つ以上の Fargate プロファイル、または両方の組み合わせを持つクラスターにおいて、サンプルアプリケーションを実行できます。クラスターに Amazon EC2 ワーカーノードがあり、Fargate ポッドがない場合は、[Amazon EC2 worker nodes only (EC2 ワーカーノードのみ)] タブを選択します。クラスターに既存の Fargate ポッドがある場合、またはアプリケーションを新しいFargate ポッドにデプロイする場合は、[Fargate] タブを選択します。Fargate ポッドの詳細については、「Amazon EKS での AWS Fargate の開始方法 (p. 115)」を参照してください。

Amazon EC2 worker nodes only

次のコマンドを使用して、アプリケーションをデプロイします。

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.1.4/docs/examples/2048/2048-namespace.yamlkubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.1.4/docs/examples/2048/2048-deployment.yamlkubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.1.4/docs/examples/2048/2048-service.yamlkubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.1.4/docs/examples/2048/2048-ingress.yaml

Fargate

Fargate で使用するクラスターが、サポートされているリージョン (p. 114)のリストに含まれていることを確認します。

a. 次のコマンドを使用して、サンプルアプリケーションの名前空間を含む Fargate プロファイルを作成します。example-values の値は独自の値に置き換えます。

Note

次のコマンドは、eksctl で作成したクラスターでのみ使用できます。eksctl でクラスターを作成していない場合は、AWS マネジメントコンソール (p. 121) でプロファイルを作成できます。name と namespace には、次のコマンドと同じ値を使用します。

156

https://play2048.co/


eksctl create fargateprofile --cluster prod --region region-code --name alb-sample-app --namespace 2048-game

b. 次のコマンドを使用して、マニフェストファイルをダウンロードして適用し、Kubernetes の名前空間、デプロイ、およびサービスを作成します。

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.1.4/docs/examples/2048/2048-namespace.yamlkubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.1.4/docs/examples/2048/2048-deployment.yamlkubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.1.4/docs/examples/2048/2048-service.yaml

c. 次のコマンドを使用して、入力マニフェストファイルをダウンロードします。

curl -o 2048-ingress.yaml https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.1.4/docs/examples/2048/2048-ingress.yaml

d. 2048-ingress.yaml ファイルを編集します。既存の alb.ingress.kubernetes.io/scheme: internet-facing 行の下に、行 alb.ingress.kubernetes.io/target-type: ip を追加します。

e. 次のコマンドを使用して、入力マニフェストファイルを適用します。

kubectl apply -f 2048-ingress.yaml

2. 数分後、次のコマンドを使用して、Ingress リソースが作成されたことを確認します。

kubectl get ingress/2048-ingress -n 2048-game

出力:

NAME HOSTS ADDRESS PORTS AGE2048-ingress * example-2048game-2048ingr-6fa0-352729433.region-code.elb.amazonaws.com 80 24h

Note

Ingress が数分後に作成されていない場合は、次のコマンドを実行して Ingress コントローラーのログを表示します。これらのログには、デプロイに関する問題の診断に役立つエラーメッセージが含まれている場合があります。

kubectl logs -n kube-system deployment.apps/alb-ingress-controller

3. ブラウザを開き、前のコマンドの出力から ADDRESS URL に移動して、サンプルアプリケーションを表示します。

4. サンプルアプリケーションの試用が終了したら、次のコマンドで削除します。

kubectl delete -f https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.1.4/docs/examples/2048/2048-ingress.yamlkubectl delete -f https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.1.4/docs/examples/2048/2048-service.yamlkubectl delete -f https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.1.4/docs/examples/2048/2048-deployment.yamlkubectl delete -f https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.1.4/docs/examples/2048/2048-namespace.yaml

157

Amazon EKS ユーザーガイドAmazon EKS で使用する VPC の作成

Amazon EKS ネットワークこの章では、Amazon EKS で Kubernetes を実行するための以下のネットワーク関連のトピックについて説明します。

• the section called “Amazon EKS で使用する VPC の作成” (p. 159) – Amazon Virtual Private Cloud(Amazon VPC) を使用すると、定義した仮想ネットワーク内で AWS リソースを起動できます。

• the section called “クラスター VPC に関する考慮事項” (p. 161) – VPC とサブネットの要件について説明します。

• the section called “Amazon EKS セキュリティグループの考慮事項” (p. 164) – セキュリティグループの要件について説明します。

• the section called “ポッドネットワーキング (CNI)” (p. 167) – CNI プラグインを使用すると、Kubernetes ポッドでは VPC ネットワークと同じ IP アドレスをポッド内で使用できます。

• the section called “CoreDNS のインストールまたはアップグレード” (p. 182) – CoreDNSは、Kubernetes バージョン 1.13 以降の Amazon EKS クラスターでサポートされています。

• the section called “Amazon EKS に Calico をインストールする” (p. 185) – Project Calicoは、Kubernetes のネットワークポリシーエンジンです。Calico ネットワークポリシーの実施によって、ネットワークのセグメンテーションとテナントの隔離を実装できます。

Amazon EKS クラスター用の VPC の作成Amazon Virtual Private Cloud (Amazon VPC) を使用すると、定義した仮想ネットワーク内で AWS リソースを起動できます。仮想ネットワークは、お客様自身のデータセンターで運用されていた従来のネットワークによく似ていますが、AWS のスケーラブルなインフラストラクチャを使用できるというメリットがあります。詳細については、「Amazon VPC ユーザーガイド」および「Amazon EKS ワーカーノードのクラスターネットワーキングの解明」を参照してください。

既存の VPC を使用する場合は、Amazon EKS で使用するための特定の要件を満たしている必要があります。詳細については、「??? (p. 161)」を参照してください。このトピックでは、次のいずれかの設定を使用して、クラスターの VPC を作成する手順について説明します。

• パブリックサブネットとプライベートサブネット – この VPC には、2 つのパブリックサブネットと 2つのプライベートサブネットがあります。1 つのパブリックサブネットと 1 つのプライベートサブネットが同じアベイラビリティーゾーンにデプロイされます。他のパブリックサブネットとプライベートサブネットは、同じリージョン内の 2 番目のアベイラビリティーゾーンにデプロイされます。このオプションは、すべての実稼働デプロイに推奨されます。このオプションでは、ワーカーノードをプライベートサブネットにデプロイし、Kubernetes がパブリックサブネットにロードバランサーをデプロイできるようにします。これにより、プライベートサブネットのワーカーノードで実行されているポッドへのトラフィックの負荷分散が可能になります。

パブリック IP アドレスは、パブリックサブネットの 1 つにデプロイされたリソースに自動的に割り当てられますが、プライベートサブネットにデプロイされたリソースにはパブリック IP アドレスが割り当てられません。プライベートサブネットのワーカーノードはクラスターや他の AWS のサービスと通信でき、ポッドは各アベイラビリティーゾーンにデプロイされている NAT ゲートウェイを介してインターネットにアウトバウンドで通信できます。すべてのインバウンドトラフィックを拒否し、すべてのアウトバウンドトラフィックを許可するセキュリティグループがデプロイされます。サブネットには、Kubernetes がロードバランサーをデプロイできるようにタグが付けられています。サブネットのタグ付けの詳細については、「??? (p. 163)」を参照してください。このタイプの VPC の詳細については、「パブリックサブネットとプライベートサブネット (NAT) を持つ VPC」を参照してください。

• パブリックサブネットのみ – この VPC には、リージョン内の異なるアベイラビリティーゾーンにデプロイされる 3 つのパブリックサブネットがあります。すべてのワーカーノードには自動的にパブリッ

158

https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/

http://aws.amazon.com/blogs/containers/de-mystifying-cluster-networking-for-amazon-eks-worker-nodes

http://aws.amazon.com/blogs/containers/de-mystifying-cluster-networking-for-amazon-eks-worker-nodes

https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Subnets.html

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-regions-availability-zones

https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-ip-addressing.html#vpc-public-ipv4-addresses


https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_SecurityGroups.html

https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenario2.html


ク IP アドレスが割り当てられ、インターネットゲートウェイを介してインターネットトラフィックを送受信できます。すべてのインバウンドトラフィックを拒否し、すべてのアウトバウンドトラフィックを許可するセキュリティグループがデプロイされます。サブネットには、Kubernetes がロードバランサーをデプロイできるようにタグが付けられています。サブネットのタグ付けの詳細については、「??? (p. 163)」を参照してください。このタイプの VPC の詳細については、「単一パブリックサブネットを持つ VPC」を参照してください。

Important

VPC をデプロイするために、eksctl を使用するか、Amazon EKS AWS CloudFormation VPC テンプレートのいずれかを使用した場合:

• 03/26/2020 以降 – パブリック IPv4 アドレスは、パブリックサブネットによって、パブリックサブネットにデプロイした新しいワーカーノードに自動的に割り当てられます。

• 03/26/2020 より前 – パブリック IPv4 アドレスは、パブリックサブネットによって、パブリックサブネットにデプロイした新しいワーカーノードに自動的に割り当てられません。

この変更は、パブリックサブネットにデプロイした新しいノードグループに、次のような影響を与えます。

• マネージド型ノードグループ (p. 89) – 04/22/2020 以降にノードグループをパブリックサブネットにデプロイした場合は、パブリックサブネットでパブリック IP アドレスの自動割り当てを有効にする必要があります。詳細については、「サブネットの IPv4 アドレス指定属性の変更」を参照してください。

• Linux (p. 95)、Windows (p. 101)、または Arm (p. 66) のセルフマネージド型ノードグループ –03/26/2020 以降にノードグループをパブリックサブネットにデプロイした場合は、パブリックサブネットでパブリック IP アドレスの自動割り当てを有効にするか、パブリック IP アドレスを使用してワーカーノードを起動する必要があります。詳細については、「サブネットのパブリック IPv4 アドレス指定属性の変更」または「インスタンス起動時のパブリック IPv4 アドレスの割り当て」を参照してください。

目的の VPC 設定を表すタブを下で選択します。

Amazon EKS クラスター用の VPC の作成Public and private subnets

パブリックサブネットとプライベートサブネットを持つクラスター VPC を作成するには



https://amazon-eks.s3.us-west-2.amazonaws.com/cloudformation/2020-04-21/amazon-eks-vpc-private-subnets.yaml



159







https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-ip-addressing.html#vpc-public-ip




• VpcBlock: VPC の CIDR 範囲を選択します。デフォルト値をそのまま使用できます。• PublicSubnet01Block: パブリックサブネット 1 の CIDR 範囲を指定します。ロードバランサー

で数多くの IP アドレスを使用できるよう、デフォルト値のままにしておくことをお勧めします。

• PublicSubnet02Block: パブリックサブネット 2 の CIDR 範囲を指定します。ロードバランサーで数多くの IP アドレスを使用できるよう、デフォルト値のままにしておくことをお勧めします。






12. 作成されたサブネットの SubnetIds と、それらをパブリックサブネットとプライベートサブネットのどちらとして作成したかを記録します。ワーカーノードをクラスターに追加するときは、ワーカーノードを起動するサブネットの ID を指定する必要があります。

Only public subnets

パブリックサブネットのみを持つクラスター VPC を作成するには



https://amazon-eks.s3.us-west-2.amazonaws.com/cloudformation/2020-04-21/amazon-eks-vpc-sample.yaml



• VpcBlock: VPC の CIDR 範囲を選択します。デフォルト値をそのまま使用できます。• Subnet01Block: サブネット 1 の CIDR 範囲を指定します。ポッドとロードバランサーで数多く



の IP アドレスを使用できるよう、デフォルト値のままにしておくことをお勧めします。

160






12. 作成されたサブネットの [SubnetIds] を記録します。ワーカーノードをクラスターに追加するときは、ワーカーノードを起動するサブネットの ID を指定する必要があります。

次のステップVPC を作成したら、Amazon EKS の開始方法 (p. 3) ウォークスルーを使用できますが、Amazon EKS クラスター VPC を作成する (p. 12) セクションをスキップして、クラスターにこれらのサブネットおよびセキュリティグループを使用できます。

クラスター VPC に関する考慮事項Amazon EKS のクラスターの作成時には、使用するクラスターの VPC サブネットを指定します。AmazonEKS には、2 つ以上のアベイラビリティーゾーンにサブネットが必要です。パブリックサブネットとプライベートサブネットを持つ VPC をお勧めします。これにより、Kubernetes がパブリックサブネットにパブリックロードバランサーを作成し、プライベートサブネットにあるワーカーノードで実行されているポッドへのトラフィックを負荷分散します。

クラスターを作成するときに、クラスターのリソース (ワーカーノードやロードバランサーなど) をホストするすべてのサブネットを指定します。

Note

インターネット向けのロードバランサーでは、クラスターにパブリックサブネットが必要です。ワーカーノードには、クラスターの詳細分析と起動時のノード登録に対する Amazon EKSAPI に対するアウトバウンドのインターネットアクセスも必要です。コンテナイメージをプルするには、 Amazon S3 および Amazon ECR API にアクセスする必要があります (およびその他 DockerHub などのコンテナレジストリなど) 。詳細については、AWS General Referenceの「Amazon EKS セキュリティグループの考慮事項 (p. 164)」および「AWS IP アドレスの範囲」を参照してください。

Amazon EKS で制御プレーンに使用される Elastic Network Interface をワーカーノード通信に配置する場合のクラスター影響を作成する際に渡すサブネット。

クラスターの作成時にパブリックサブネットまたはプライベートサブネットのみを指定することができますが、これらの設定にはいくつかの制限があります。

• プライベート専用: すべてプライベートサブネットで実行され、Kubernetes ではポッドのインターネット向けロードバランサーを作成することはできません。

• パブリックのみ: すべてパブリックサブネットで実行されます (ワーカーノードを含む)。

Amazon EKS は、プライベートサブネットに Elastic Network Interface を作成し、ワーカーノードへの通信を円滑にします。この通信チャネルは、Kubernetes 機能 (kubectl exec および kubectl logs) をサポート

161

https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html

Amazon EKS ユーザーガイドVPC IP アドレス指定

しています。クラスターの作成時に指定するセキュリティグループは、クラスターコントロールプレーン用に作成された Elastic Network Interfaces に適用されます。

VPC は、DNS ホスト名と DNS 解決がサポートされている必要があります。そうしないと、ワーカーノードをクラスターに登録できません。詳細については、「Amazon VPC ユーザーガイド」の「VPC でのDNS の使用」を参照してください。

VPC IP アドレス指定ワーカーノードが適切に機能するためには、パブリック IP アドレスを使用してインターネットにアクセスできる必要があります。ワーカーノードがプライベートサブネットにデプロイされている場合、サブネットには NAT ゲートウェイへのデフォルトルートが必要です。NAT ゲートウェイには、ワーカーノードにインターネットアクセスを提供するためにパブリック IP アドレスを割り当てる必要があります。セルフマネージド型ワーカーノードをパブリックサブネットにデプロイしている場合は、パブリック IP アドレスを自動的に割り当てるように、そのサブネットを設定する必要があります。または、ワーカーノードインスタンスの起動時に、これらのインスタンスにパブリック IP アドレスを割り当てる必要があります。マネージド型ワーカーノードをパブリックサブネットにデプロイしている場合は、パブリック IP アドレスを自動的に割り当てるように、そのサブネットを設定する必要があります。そうしないと、ワーカーノードにパブリック IP アドレスが割り当てられません。次のコマンドを使用して、パブリックサブネットがパブリック IP アドレスを自動割り当てするように設定されているかどうかを確認します。

aws ec2 describe-subnets \ --filters "Name=vpc-id,Values=VPC-ID" | grep 'SubnetId\|MapPublicIpOnLaunch'

出力

"MapPublicIpOnLaunch": false,"SubnetId": "subnet-aaaaaaaaaaaaaaaaa","MapPublicIpOnLaunch": false,"SubnetId": "subnet-bbbbbbbbbbbbbbbbb",

MapPublicIpOnLaunch が false に設定されているサブネットの場合は、設定を true に変更します。

aws ec2 modify-subnet-attribute --map-public-ip-on-launch --subnet-id subnet-aaaaaaaaaaaaaaaaa

Important

03/26/2020 より前に Amazon EKS AWS CloudFormation テンプレート (p. 158)を使用して VPCをデプロイした場合は、パブリックサブネットの設定を変更する必要があります。

VPC 内で Amazon EKS クラスターに使用されるプライベート (RFC 1918) とパブリック (非 RFC 1918)の両方の CIDR 範囲を定義できます。詳細については、Amazon VPC ユーザーガイドの「VPC とサブネット」および「VPC での IP アドレス指定」を参照してください。

Amazon EKS コントロールプレーンは、クラスターごとに最大 4 つのクロスアカウントの Elastic NetworkInterface を VPC に作成します。指定するサブネットに、クロスアカウントの Elastic Network Interface とポッドに十分な IP アドレスがあることを確認します。

Important

Docker は Amazon EKS クラスターの 172.17.0.0/16 CIDR 範囲で実行されます。クラスターの VPC サブネットがこの範囲と重ならないようにすることをお勧めします。重なっている場合は、以下のエラーが発生します。

162

https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-dns.html





https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-ip-addressing.html

Amazon EKS ユーザーガイドVPC のタグ付け要件

Error: : error upgrading connection: error dialing backend: dial tcp 172.17.nn.nn:10250: getsockopt: no route to host

VPC のタグ付け要件バージョン 1.15 より前の Amazon EKS クラスターを作成すると、Amazon EKS は指定したサブネットが含まれている VPC に次の方法でタグ付けし、Kubernetes で VPC を検出できるようにします。

キー値

kubernetes.io/cluster/<cluster-name> shared

• Key: <cluster-name> 値は、Amazon EKS クラスター名と一致します。• 値: shared 値は、この VPC を使用することを複数のクラスターに許可します。

1.15 クラスターでは、このタグは必須ではないか、Amazon EKS によって作成されません。すでにこのタグを持つ VPC に 1.15 クラスターをデプロイしても、タグは削除されません。

サブネットのタグ付け要件Amazon EKS クラスターを作成すると、 Amazon EKS は Kubernetes が指定したサブネットを次の方法でタグ付けし、それらを Kubernetes で検出できるようにします。

Note

クラスターがリソースに使用するすべてのサブネット (パブリックおよびプライベート) にはこのタグが必要です。

キー値

kubernetes.io/cluster/<cluster-name> shared

• Key: <cluster-name> 値は、Amazon EKS クラスターと一致します。• 値: shared 値は、複数のクラスターによるこのサブネットの使用を許可します。

内部ロードバランサー用のプライベートサブネットのタグ付け要件プライベートサブネットは、Kubernetes が内部ロードバランサーにサブネットを使用できることを認識できるように、次のようにタグ付けする必要があります。03/26/2020 以降に Amazon EKS AWSCloudFormation テンプレートを使用して VPC を作成する場合、テンプレートによって作成されたサブネットは、作成時にタグ付けされます。Amazon EKS AWS CloudFormation VPC テンプレートの詳細については、「??? (p. 158)」を参照してください。

キー値


163

Amazon EKS ユーザーガイドAmazon EKS セキュリティグループの考慮事項

外部ロードバランサー用のパブリックサブネットタグ付けオプション各アベイラビリティーゾーンでパブリックサブネットを選択するのではなく (サブネット ID の辞書順)、Kubernetes がそれらのサブネットのみを外部ロードバランサーに使用することを認識できるように、VPC のパブリックサブネットをタグ付けする必要があります。03/26/2020 以降に Amazon EKS AWSCloudFormation テンプレートを使用して VPC を作成する場合、テンプレートによって作成されたサブネットは、作成時にタグ付けされます。Amazon EKS AWS CloudFormation VPC テンプレートの詳細については、「??? (p. 158)」を参照してください。

キー値


Amazon EKS セキュリティグループの考慮事項以下のセクションでは、Kubernetes のバージョンと Amazon EKS プラットフォームのバージョンに応じて、クラスター、コントロールプレーン、およびクラスターのワーカーノードのセキュリティグループに対して必要最小限のセキュリティグループ設定および推奨されるセキュリティグループ設定について説明します。

クラスターセキュリティグループ (Kubernetes 1.14 および eks.3 プラットフォームバージョンを実行している Amazon EKS クラスターから利用可能)Kubernetes バージョン 1.14およびプラットフォームバージョン (p. 52) eks.3 以降の Amazon EKS クラスターは、クラスター作成の一環としてクラスターセキュリティグループを作成します（または、クラスターがこの Kubernetes バージョンおよびプラットフォームバージョンにアップグレードされた場合）。このセキュリティグループは、コントロールプレーンとマネージド型ノードグループ (p. 87)からのすべてのトラフィックが相互に自由に流れるように設計されています。クラスターセキュリティグループをコントロールプレーンのクロスアカウント Elastic Network Interface およびマネージド型ノードグループインスタンスに割り当てることにより、この通信を許可するために複雑なセキュリティグループルールを設定する必要がありません。このセキュリティグループが割り当てられているインスタンスまたはネットワークインターフェイスは、このセキュリティグループを使用して他のリソースと自由に通信できます。

クラスターのクラスターセキュリティグループは、クラスターの [ネットワーキング] セクションの下にある AWS マネジメントコンソールで確認するか、次の AWS CLI コマンドで確認できます。

aws eks describe-cluster --name cluster_name --query cluster.resourcesVpcConfig.clusterSecurityGroupId

クラスターで Kubernetes バージョン 1.14 およびプラットフォームバージョン (p. 52) eks.3 以降が実行されている場合は、クラスターセキュリティグループを既存および将来的なすべてのワーカーノードグループに追加することをお勧めします。詳細については、Amazon VPC ユーザーガイドの「VPC のセキュリティグループ」を参照してください。Amazon EKS マネージド型ノードグループ (p. 87)は、クラスターセキュリティグループを使用するように自動的に設定されます。

プロトコルポート範囲送信元送信先

推奨インバウンドトラフィック

すべてすべて Self

164



Amazon EKS ユーザーガイドコントロールプレーンおよびワーカーノー

ドのセキュリティグループ (Kubernetes バージョン 1.14 およびプラットフォームバージョン eks.3 以前の Amazon EKS クラスター対応) プロトコルポート範囲送信元送信先

推奨アウトバウンドトラフィック

すべてすべて 0.0.0.0/0

コントロールプレーンおよびワーカーノードのセキュリティグループ (Kubernetes バージョン 1.14 およびプラットフォームバージョン (p. 52) eks.3 以前のAmazon EKS クラスター対応)Kubernetes バージョン 1.14 以前の Amazon EKS クラスターおよびプラットフォームバージョン (p. 52)eks.3 では、コントロールプレーンとワーカーノード間の通信は、手動でコントロールプレーンのセキュリティグループを作成し、クラスターの作成時にそのセキュリティグループを指定することによって設定されます。クラスターの作成時に、このセキュリティグループは、クラスターのクロスアカウント ElasticNetwork Interface にアタッチされます。

クラスターのコントロールプレーンセキュリティグループは、[ネットワーキング] セクション（[追加セキュリティグループ] と表示されている）の下にある AWS マネジメントコンソールか、次の AWS CLI コマンドで確認できます。

aws eks describe-cluster --name cluster_name --query cluster.resourcesVpcConfig.securityGroupIds

Amazon EKS の開始方法 (p. 3) ウォークスルーの AWS CloudFormation テンプレートを使用してワーカーノードを起動すると、AWS CloudFormation によりワーカーノードとの通信を許可するようにコントロールプレーンのセキュリティグループが変更されます。Amazon EKS では、各コントロールプレーンに専用のセキュリティグループ（クラスターごとに 1 つ）を使用することを強くお勧めします。コントロールプレーンセキュリティグループを他の Amazon EKS クラスターまたはリソースと共有している場合、それらのリソースへの接続をブロックまたは中断することがあります。

ワーカーノードのセキュリティグループとワークノードへのコントロールプレーン通信のセキュリティグループは、ワーカーノードの特権付きのポートとの通信を行わないように設定されています。アプリケーションでコントロールプレーンまたはワーカーノードからの追加のインバウンドまたはアウトバウンドアクセスが必要な場合は、これらのルールをクラスターに関連付けられているセキュリティグループに追加する必要があります。詳細については、Amazon VPC ユーザーガイドの「VPC のセキュリティグループ」を参照してください。

Note

特権付きのポートでプロキシ機能を許可したり、CNCF 適合テストを自分で実行するには、コントロールプレーンとワーカーノードのセキュリティグループを編集する必要があります。ワーカーノード側のセキュリティグループは、コントロールプレーンからのポート 0-65535 のインバウンドアクセスを許可する必要があり、コントロールプレーン側は、ポート 0-65535 のワーカーノードへのアウトバウンドアクセスを許可する必要があります。

コントロールプレーンセキュリティグループ


最小インバウンドトラフィック

TCP 443 すべてのワーカーノードセキュリティグループ

165

https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html

Amazon EKS ユーザーガイドコントロールプレーンおよびワーカーノー

ドのセキュリティグループ (Kubernetes バージョン 1.14 およびプラットフォームバージョン eks.3 以前の Amazon EKS クラスター対応) プロトコルポート範囲送信元送信先

クラスターエンドポイントのプライベートアクセス (p. 37)が有効になっている場合: API サーバークライアントトラフィックを生成する任意のセキュリティグループ (クラスターの VPC内の踏み台ホスト上での kubectlコマンドなど)



クラスターエンドポイントのプライベートアクセス (p. 37)が有効になっている場合: API サーバークライアントトラフィックを生成する任意のセキュリティグループ (クラスターの VPC内の踏み台ホスト上での kubectlコマンドなど)

最小アウトバウンドトラフィック



TCP 1025-65535 すべてのワーカーノードセキュリティグループ

ワーカーノードセキュリティグループ


最小インバウンドトラフィック (他のワーカーノード)

ワーカーノードでワーカー間通信に使用されるプロトコル

ワーカーノードでワーカー間通信に使用されるポート

すべてのワーカーノードセキュリティグループ

最小インバウンドトラフィック (コントロールプレーン)

TCP 10250 コントロールプレーンセキュリティグループ

166

Amazon EKS ユーザーガイドポッドネットワーキング (CNI)



すべて

TCP

すべて

443, 1025-65535

すべてのワーカーノードセキュリティグループ

コントロールプレーンセキュリティグループ

最小アウトバウンドトラフィック *

TCP 443 コントロールプレーンセキュリティグループ


すべてすべて 0.0.0.0/0

* ワーカーノードには、クラスターの詳細分析と起動時のノード登録に対する Amazon EKS API に対するアウトバウンドのインターネットアクセスも必要です。コンテナイメージをプルするには、 Amazon S3および Amazon ECR API にアクセスする必要があります (およびその他 DockerHub などのコンテナレジストリなど) 。詳細については、AWS General Reference の「AWS IP アドレスの範囲」を参照してください。

ワーカーノードに複数のセキュリティグループを関連付ける場合は、セキュリティグループの 1 つに次のタグを適用する必要があります。ワーカーノードにセキュリティグループを 1 つのみ関連付ける場合、タグはオプションです。タグ付けの詳細については、「コンソールでのタグの処理 (p. 286)」を参照してください。

キー値


ポッドネットワーキング (CNI)Amazon EKS は、Kubernetes 用の Amazon VPC コンテナネットワークインターフェイス (CNI) プラグインを介したネイティブ VPC をサポートします。この CNI プラグインを使用すると、Kubernetes ポッドは VPC ネットワーク上と同じ IP アドレスをポッド内に持つことができます。この CNI プラグインは、GitHub で管理されているオープンソースのプロジェクトです。

167

https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html


Amazon EKS ユーザーガイドCNI 設定変数

CNI プラグインは、Kubernetes ノードに VPC IP アドレスを割り当て、各ノードのポッドに必要なネットワークを設定します。このプラグインは 2 つの主なコンポーネントで構成されています。

• L-IPAM デーモンは、インスタンスへの Elastic Network Interface の接続、Elastic Network Interface へのセカンダリ IP アドレスの割り当て、スケジュールされた際に Kubernetes ポッドに割り当てるために各ノードにおける IP アドレスの「ウォームプール」の維持を行います。

• CNI プラグインは、ホストネットワークの接続 (例: インターフェイスと仮想イーサネットペアの設定)とポッド名前空間への正しいインターフェイスの追加を行います。

設計およびネットワーク設定の詳細については、「AWS VPC を使用した Kubernetes ネットワーキング用CNI プラグイン」を参照してください。

Elastic Network Interface と、Amazon EC2 インスタンスタイプによるセカンダリ IP アドレス制限が適用されます。一般的に、インスタンスが大きいほど、より多くの IP アドレスをサポートできます。詳細については、Linux インスタンス用 Amazon EC2 ユーザーガイドの「各インスタンスタイプのネットワークインターフェイスごとの IP アドレス」を参照してください。

トピック• CNI 設定変数 (p. 168)• 外部ソースネットワークアドレス変換 (SNAT) (p. 174)• CNI カスタムネットワーク (p. 176)• CNI Metrics Helper (p. 179)• Amazon VPC CNI Plugin for Kubernetes のアップグレード (p. 182)

CNI 設定変数Kubernetes 向け Amazon VPC CNI プラグインでは、多数の設定オプションがサポートされており、環境変数を通じて設定します。次の環境変数を使用できます。すべてオプションです。

AWS_VPC_CNI_NODE_PORT_SUPPORT

タイプ – ブール値

168

https://github.com/aws/amazon-vpc-cni-k8s/blob/master/README.md





デフォルト値 – true

NodePort サービスがワーカーノードのプライマリネットワークインターフェイスで有効になっているかどうかを指定します。これには、追加の iptables ルールと、プライマリインターフェイスのカーネルのリバースパスフィルターが loose に設定されていることが必要です。

AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG


デフォルト値 – false

ポッドが、クラスターの resourcesVpcConfig に依存しないサブネットおよびセキュリティグループ (コントロールプレーンリソースと同じ VPC 内) を使用できるかどうかを指定します。デフォルトでは、ポッドはワーカーノードのプライマリインターフェイスと同じサブネットとセキュリティグループを共有します。この変数を true に設定すると、ipamD が Elastic Network Interface のワーカーノードの ENIConfig にあるセキュリティグループとサブネットを使用します。ポッドが存在する各サブネットで ENIConfig カスタムリソース定義を作成する必要があます。その後各ワーカーノードにアノテーションをつけて特定の ENIConfig を使用するようにします (複数のワーカーノードに同じ ENIConfig を使用してアノテーションを付けることができます)。ワーカーノードに 1 度に付けられるアノテーションは、単一の ENIConfig のみです。また、ENIConfig のサブネットはワーカーノードが存在する同じアベイラビリティーゾーンに属する必要があります。詳細については、「CNI カスタムネットワーク (p. 176)」を参照してください。

ENI_CONFIG_ANNOTATION_DEF

タイプ – 文字列

デフォルト値 – k8s.amazonaws.com/eniConfig

ノードアノテーションキー名を指定します。これは、AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true の場合に使用する必要があります。アノテーション値は、ENIConfig 名を設定するために使用されます。アノテーションはラベルよりも優先されます。

ENI_CONFIG_LABEL_DEF


デフォルト値 – k8s.amazonaws.com/eniConfig

ノードラベルのキー名を指定します。これは、AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=trueの場合に使用する必要があります。ラベル値は、ENIConfig 名を設定するために使用されます。アノテーションはラベルよりも優先されます。ラベルを使用するには、キーk8s.amazonaws.com/eniConfig を持つアノテーションが定義されており、アノテーションキー ENI_CONFIG_ANNOTATION_DEF の値がノードで設定されていないことを確認してください。アベイラビリティーゾーンに基づいて ENIConfig を選択するには、これを failure-domain.beta.kubernetes.io/zone に設定し、各アベイラビリティーゾーンに ENIConfig カスタムリソース (us-east-1a など) を作成します。詳細については、「CNI カスタムネットワーク (p. 176)」を参照してください。

AWS_VPC_ENI_MTU – v1.6.0 以降

タイプ – 整数

デフォルト – 9001

アタッチされた ENI の MTU サイズを設定するために使用されます。有効な範囲は 576 から 9001 です。

AWS_VPC_K8S_CNI_EXTERNALSNAT


169



外付け NAT ゲートウェイを使用してセカンダリ ENI IP アドレスの SNAT を指定するかどうかを指定します。trueに設定した場合、SNAT iptables ルールとオフ VPC IP ルールは適用されず、これらのルールがすでに適用されている場合は削除されます。

外部 VPN、直接接続、外部 VPC からポッドへのインバウンド通信を許可する必要があり、ポッドがインターネットゲートウェイ経由で直接インターネットにアクセスする必要がない場合は、SNAT を無効にします。ノードがプライベートサブネットで実行され、AWS NAT ゲートウェイまたは別の外部 NAT デビス経由でインターネットに接続している必要があります。

詳細については、「外部ソースネットワークアドレス変換 (SNAT) (p. 174)」を参照してください。AWS_VPC_K8S_CNI_RANDOMIZESNAT


デフォルト値 – hashrandom

有効な値 – hashrandom、prng、none

SNAT iptables ルールが接続の送信ポートをランダム化するかどうかを指定します。これは、AWS_VPC_K8S_CNI_EXTERNALSNAT=false の場合に使用する必要があります。有効にすると (hashrandom)、SNAT iptables ルールに --random フラグが追加されます。ハッシュベース(--random-fully) ではなく擬似乱数生成を使用するには、環境変数に prng を使用します。--random-fully をサポートしていない iptables の以前のバージョンでは、このオプションが --random にフォールバックします。送信接続の順次ポート割り当てに依存している場合は、この機能を無効にします (none)。

Note

none 以外のオプションを使用すると、送信接続にソースポートが割り当てられますが、これは OS レベルで設定されたエフェメラルポート範囲の一部であるとは限りません (/proc/sys/net/ipv4/ip_local_port_range)。これは、ip_local_port_range で見つかったポート範囲に基づいてトラフィックを制限する NACL があるかどうかに関係します。

AWS_VPC_K8S_CNI_EXCLUDE_SNAT_CIDRS – v1.6.0 以降


デフォルト – 空

SNAT から除外する IPv4 CIDR のカンマ区切りリストを指定します。リスト内のすべての項目に、iptables ルールとオフ VPC IP ルールが適用されます。項目が有効な IPv4 範囲にない場合はスキップされます。これは、AWS_VPC_K8S_CNI_EXTERNALSNAT=false の場合に使用する必要があります。

WARM_ENI_TARGET


デフォルト値 – 1

ipamD デーモンがノード上のポッド割り当てに使用できるようにしておく必要があるフリーの ElasticNetwork Interface (およびそのすべての使用可能な IP アドレス) の数を指定します。デフォルトでは、ipamD は 1 つの Elastic Network Interface とそのすべての IP アドレスを、ポッドの割り当て用に維持します。

Note

ネットワークインターフェイスごとの IP アドレスの数はインスタンスタイプによって異なります。詳細については、『Linux インスタンス用 Amazon EC2 ユーザーガイド』の「各インスタンスタイプのネットワークインターフェイスごとの IP アドレス」を参照してください。

170




たとえば、m4.4xlarge は 1 つのネットワークインターフェイスと 30 個の IP アドレスを持って起動されます。ノードに 5 つのポッドが配置され、5 つのフリーの IP アドレスが IP アドレスウォームプールから削除されると、ipamD は WARM_ENI_TARGET フリーインターフェイスがノードで使用できるようになるまで追加のインターフェイスを割り当てようとします。

Note

WARM_IP_TARGET が設定されると、この環境変数は無視され、代わりにWARM_IP_TARGET動作が使用されます。

WARM_IP_TARGET


デフォルト – なし

ipamD デーモンがノード上のポッド割り当てに使用できるようにしておく必要があるフリーの IP アドレスの数を指定します。たとえば、WARM_IP_TARGET が 10 に設定されると、ipamD は常に 10 個のフリーの IP アドレスを維持しようとします。ノードの Elastic Network Interface がフリーのアドレスを提供できない場合、ipamD はWARM_IP_TARGET フリー IP アドレスが使用できるようになるまでより多くのインターフェイスの割り当てを試みます。

Note

この環境変数は WARM_ENI_TARGET 動作をオーバーライドします。MINIMUM_IP_TARGET – v1.6.0 以降



ipamD デーモンによってノードのポッドに割り当てられる必要がある IP アドレスの総数を指定します。MINIMUM_IP_TARGET は WARM_IP_TARGET と同じように機能しますが、常に空けておく IP アドレスのターゲット数を設定するのではなく、割り当てられる IP アドレスの合計数の下限としてターゲット数を設定します。

MINIMUM_IP_TARGET は事前スケーリング用で、WARM_IP_TARGET は動的スケーリング用です。たとえば、クラスターの予想ポッド密度がノードあたり約 30 ポッドであるとします。WARM_IP_TARGET を 30 に設定して、CNI によって初めから十分な IP が割り当てられるようにした場合、30 個のポッドがノードにデプロイされます。CNI によってさらに 30 個の IP が割り当てられると、合計で 60 個の IP が使用済みになり、関連するサブネットで IP の枯渇が進みます。代わりに、MINIMUM_IP_TARGET を 30 に、WARM_IP_TARGET を 2 に設定した場合、30 個のポッドがデプロイされた後、CNI によってさらに 2 つの IP が割り当てられます。これにより伸縮性を持たせながら、IP の使用数は、WARM_IP_TARGET のみを設定する場合の約半分に (60 個から 32 個に) 抑えられます。

また、特にスケーリング時に、プライベート IP アドレスの割り当てまたは割り当て解除に必要な呼び出しの数も減るため、クラスターの信頼性も向上します。

MAX_ENI



ノードにアタッチされる ENI の最大数を指定します。MAX_ENI が設定されていないか、0 以下の場合、設定は使用されず、ENI の最大数は常に問題のインスタンスタイプの最大数に等しくなります。MAX_ENI が正の数であっても、インスタンスタイプの最大数によって制限されます。

AWS_VPC_K8S_CNI_LOGLEVEL


171


デフォルト値 – DEBUG

有効な値 – trace、debug、info、warn、error、critical、または off (大文字と小文字は区別されません)

ipamd のログレベルを指定します。AWS_VPC_K8S_CNI_LOG_FILE


デフォルト値 – 未設定

有効な値: stdout またはファイルパス

ipamd のログ出力を書き込む場所を指定します。stdout を指定するか、/var/log/aws-routed-eni/ipamd.log などのデフォルトファイルを上書きできます。

AWS_VPC_K8S_PLUGIN_LOG_FILE


デフォルト値 – 未設定

有効な値 – stdout またはファイルパス。

aws-cni プラグインのログ出力を書き込む場所を指定します。stdout を指定するか、/var/log/aws-routed-eni/plugin.log などのデフォルトファイルを上書きできます。

AWS_VPC_K8S_PLUGIN_LOG_LEVEL


有効な値 – trace、debug、info、warn、error、critical、または off (大文字と小文字は区別されません)

aws-cni プラグインのログレベルを指定します。INTROSPECTION_BIND_ADDRESS


デフォルト値 – 127.0.0.1:61679

詳細分析エンドポイントのバインドアドレスを指定します。Unix ドメインソケットは、ソケットパスの前に unix: プレフィックスを付けて指定することができます。

DISABLE_INTROSPECTION



ワーカーノードで詳細分析エンドポイントを無効にするかどうかを指定します。これを true に設定すると、aws-cni-support.sh スクリプトの実行時にノードから取得できるデバッグ情報が減少します。

DISABLE_METRICS



172


Prometheus メトリクスエンドポイントを ipamd で無効にするかどうかを指定します。デフォルトでは、メトリクスは :61678/metrics で公開されます。

AWS_VPC_K8S_CNI_VETHPREFIX


デフォルト値 – eni

CNI のホスト側 veth デバイス名の生成に使用する veth プレフィクスを指定します。プレフィックスの長さは 4 文字までです。

ADDITIONAL_ENI_TAGS – v1.6.0 以降


デフォルト – {}

値の例 – {"tag_key": "tag_val"}

ENI に適用されるメタデータは、請求などの目的でリソースを分類および整理するのに役立ちます。各タグはカスタム定義キーとオプションの値で構成されます。タグキーには最大 128 文字を含めることができます。タグの値に使用できるのは 256 文字までです。タグは、ホスト上のすべての ENI に追加されます。

Important

カスタムタグには k8s.amazonaws.com プレフィックスを含めないでください。このプレフィックスは予約されています。タグに k8s.amazonaws.com が含まれている場合、そのタグの追加は無視されます。

CLUSTER_NAME


デフォルト値 – ""

割り当てられた ENI をタグ付けするクラスター名を指定します。

割り当てに関連する ENI タグ

このプラグインは、ENI で次のタグを操作します。• cluster.k8s.amazonaws.com/name

• node.k8s.amazonaws.com/instance_id

• node.k8s.amazonaws.com/no_manage

クラスター名タグ

タグ cluster.k8s.amazonaws.com/name は、ENI を作成した aws-node デーモンセットのクラスター名に設定されます。

インスタンス ID タグ

タグ node.k8s.amazonaws.com/instance_id は、この ENI を割り当てた aws-node インスタンスのインスタンス ID に設定されます。

管理タグなし

node.k8s.amazonaws.com/no_manage タグは、マシンにアタッチされた ENI をプライベートIP アドレス用に構成したり使用したりすべきでないかどうかを判断するために、aws-node デー

173

Amazon EKS ユーザーガイド外部 SNAT

モンセットによって読み取られます。このタグは CNI プラグイン自体によって設定されるのではなく、ENI がホストネットワーキングポッド用であるか、Kubernetes とは無関係な他のプロセス用であるかを示すためにユーザーが設定できます。

Note

no_manage タグが付いた ENI をアタッチすると、kubelet の --max-pods 設定オプションの値が正しくなくなります。このタグを使用する場合、このプラグインと kubelet で、それぞれ設定オプション MAX_ENI と --max-pods 設定オプションを更新することを検討してください。

注

すべてのワーカーノードで実行されている L-IPAMD (aws-node デーモンセット) には、KubernetesAPI サーバーへのアクセスが必要です。Kubernetes API サーバーに到達できない場合、ipamD が終了し、CNI はポッドの IP アドレスを取得できなくなります。L-IPAMD が Kubernetes API サーバーにアクセスできるかどうかを確認すには、次のようにします。

kubectl get svc kubernetes

出力

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEkubernetes ClusterIP 10.0.0.1 <none> 443/TCP 29d

ワーカーノードに SSH 接続して、ワーカーノードが API サーバーにアクセスできるかどうかを確認します。

telnet 10.0.0.1 443

出力

Trying 10.0.0.1...Connected to 10.0.0.1.Escape character is '^]'.

出力の最後の行を受け取った場合、Kubernetes API サーバーにアクセスできます。

外部ソースネットワークアドレス変換 (SNAT)VPC 内の通信 (ポッドからポッドなど) は、プライベート IP アドレス間で直接行われ、ソースネットワークアドレス変換 (SNAT) を必要としません。トラフィックの宛先が VPC の外部のアドレスである場合に、Kubernetes の Amazon VPC CNI プラグインは各ポッドのプライベート IP アドレスを、そのポッドのデフォルトの Amazon EC2 インスタンスワーカーノードのプライマリ Elastic Network Interface に割り当てられたプライマリプライベート IP アドレスに変換します。SNAT:

• ポッドがインターネットと双方向に通信できるようにします。ワーカーノードはパブリックサブネットにあり、そのプライマリネットワークインターフェイスのプライマリプライベート IP アドレスに、パブリック IP アドレスまたは Elastic IP アドレスが割り当てられている必要があります。以下の図に示すように、トラフィックはパブリック IP アドレスまたは Elastic IP アドレスとの間で変換され、インターネットゲートウェイによってインターネットとの間でルーティングされます。

174


https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html

https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Subnets.html#vpc-subnet-basics

https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Subnets.html#vpc-subnet-basics



https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-eips.html

https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Internet_Gateway.html

https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Internet_Gateway.html

Amazon EKS ユーザーガイド外部 SNAT

インターネットゲートウェイは、ポッドのプライマリプライベート IP アドレスと、ポッドの AmazonEC2 インスタンスワーカーノードのプライマリ Elastic Network Interface に割り当てられたパブリックIP アドレスまたは Elastic IP アドレスとの間の変換方法しか認識しないため、SNAT が必要です。

• 他のプライベート IP アドレススペース (VPC ピア接続、Transit VPC、Direct Connect など) のデバイスが、Amazon EC2 インスタンスワーカーノードのプライマリ Elastic Network Interface のプライマリプライベート IP アドレスが割り当てられていないポッドと直接通信しないようにします。

他のプライベート IP アドレススペース内のインターネットまたはデバイスが通信する必要のあるポットに、そのポッドの Amazon EC2 インスタンスワーカーノードのプライマリ Elastic Network Interface に割り当てられたプライマリプライベート IP アドレスが割り当てられていない場合は、以下の操作が必要です。

• パブリックサブネットの NAT デバイスへのルートがあるプライベートサブネットにワーカーノードをデプロイします。

• 以下のコマンドを使用して、CNI プラグイン aws-node DaemonSet で外部 SNAT を有効にします。

kubectl set env daemonset -n kube-system aws-node AWS_VPC_K8S_CNI_EXTERNALSNAT=true

外部 SNAT が有効になると、トラフィックの宛先が VPC の外部のアドレスである場合に、CNI プラグインはポッドのプライベート IP アドレスを、そのポッドの Amazon EC2 インスタンスワーカーノードのプライマリ Elastic Network Interface に割り当てられたプライマリプライベート IP アドレスに変換しません。以下の図に示すように、ポッドからインターネットへのトラフィックは、NAT デバイスのパブリック IP アドレスとの間で外部的に変換され、インターネットゲートウェイによってインターネットとの間でルーティングされます。

175

https://docs.aws.amazon.com/AmazonVPC/latest/PeeringGuide/what-is-vpc-peering.html

https://docs.aws.amazon.com/aws-technical-content/latest/aws-vpc-connectivity-options/transit-vpc.html

https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html

https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-nat-comparison.html

Amazon EKS ユーザーガイドCNI カスタムネットワーク

CNI カスタムネットワークデフォルトでは、新しいネットワークインターフェイスがポッドに割り当てられると、ipamD はワーカーノードのプライマリ Elastic Network Interface (ENI) のセキュリティグループとサブネットを使用します。ただし、ポッドのネットワークインターフェイスが、コントロールプレーンのセキュリティグループと同じ VPC 内にある別のセキュリティグループまたはサブネットを使用する必要があるユースケースもあります。次に例を示します。

• サブネットの使用できる IP アドレスの数は限られています。これにより、クラスターに作成できるポッドの数が制限されます。ポッドグループの別のサブネットを使用することで、使用可能な IP アドレスの数を増やすことができます。

• セキュリティ上の理由から、ポッドはノードのプライマリネットワークインターフェイスとは異なるセキュリティグループまたはサブネットを使用する必要があります。

• ワーカーノードはパブリックサブネットで設定されます。ポッドは、NAT ゲートウェイを使用してプライベートサブネットに配置します。詳細については、「外部ソースネットワークアドレス変換(SNAT) (p. 174)」を参照してください。

Note

カスタムネットワークは、セルフマネージド型ノードグループには設定できますが、マネージド型ノードグループや Fargate には設定できません。このトピックで説明するユースケースでは、Amazon VPC CNI plugin for Kubernetes バージョン 1.4.0 以降が必要です。CNI のバージョンを確認して必要に応じて更新するには、「Amazon VPC CNI Plugin for Kubernetes のアップグレード (p. 182)」を参照してください。

カスタムネットワークを有効にすると、使用可能な Elastic Network Interface (およびポッド用に使用可能なすべての IP アドレス) が、それを使用する各ワーカーノードから効率的に削除されます。カスタムネットワークが有効になると、ワーカーノードのプライマリネットワークインターフェイスはポッドの配置には使用されません。

CNI カスタムネットワークを設定するには

1. セカンダリ CIDR ブロックをクラスターの VPC に関連付けます。詳細については、 Amazon VPCユーザーガイドの「VPC とセカンダリ IPv4 CIDR ブロックを関連付ける」を参照してください。

2. セカンダリ CIDR ブロックを使用して、アベイラビリティーゾーンごとに VPC にサブネットを作成します。カスタムサブネットは、ワーカーノードが起動されるサブネットとは異なる VPC CIDR ブ

176

https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/cni-proposal.md


https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/working-with-vpcs.html#add-ipv4-cidr


ロックに属している必要があります。詳細については、Amazon VPC ユーザーガイドの「VPC でサブネットを作成する」を参照してください。

3. aws-node デーモンセットで AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true 環境変数を trueに設定します。

kubectl set env daemonset aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true

4. 現在インストールされている CNI バージョンを表示します。


出力:


5. バージョン 1.3 以降の CNI がインストールされている場合は、ステップ 6 に進むことができます。クラスター用に新しい ENIConfig カスタムリソースを定義します。

a. ENIConfig.yaml というファイルを作成して、次の内容を貼り付けます。

apiVersion: apiextensions.k8s.io/v1beta1kind: CustomResourceDefinitionmetadata: name: eniconfigs.crd.k8s.amazonaws.comspec: scope: Cluster group: crd.k8s.amazonaws.com version: v1alpha1 names: plural: eniconfigs singular: eniconfig kind: ENIConfig

b. 次のコマンドを使用して、クラスターにファイルを適用します。

kubectl apply -f ENIConfig.yaml

6. ポッドをスケジュールするサブネットごとに ENIConfig カスタムリソースを作成します。

a. Elastic Network Interface 設定ごとに固有のファイルを作成します。各ファイルには、以下の内容が含まれ、name の値は一意であることが必要です。サブネットのアベイラビリティーゾーンと一致する name の値を使用することを強くお勧めします。これにより、マルチ AZ Auto Scalingグループのデプロイが簡単になるためです (以下のステップ 5c を参照)。この例では、us-west-2a.yaml という名前のファイルが作成されます。name、subnet、securityGroupsのイイイイイを独自の値に置き換えます。この例では、ベストプラクティスに従い、name の値を、サブネットが存在するアベイラビリティーゾーンに設定します。ポッドにアタッチする特定のセキュリティグループがない場合、現時点ではその値を空のままにしておくことができます。後で、ENIConfig でワーカーノードのセキュリティグループを指定します。

Note

サブネットとセキュリティグループの組み合わせごとに、独自のカスタムリソースが必要です。

apiVersion: crd.k8s.amazonaws.com/v1alpha1kind: ENIConfigmetadata:

177

https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/working-with-vpcs.html#AddaSubnet

https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/working-with-vpcs.html#AddaSubnet


name: us-west-2aspec: securityGroups: - sg-0dff111a1d11c1c11 subnet: subnet-011b111c1f11fdf11

b. 以下のコマンドを使用して、作成したカスタムリソースファイルをそれぞれクラスターに適用します。

kubectl apply -f us-west-2a.yaml

c. (オプション。ただし、マルチ AZ ワーカーノードグループでは推奨) デフォルトでは、Kubernetes はノードのアベイラビリティーゾーンを failure-domain.beta.kubernetes.io/zone ラベルに適用します。上記のステップ 6a で推奨されているように VPC の各アベイラビリティーゾーンに基づいて ENIConfig カスタムリソースに名前を付けた場合は、以下のコマンドを使用して、Kubernetes によってワーカーノードのアベイラビリティーゾーンの対応する ENIConfig が自動的に適用されるようにできます。

kubectl set env daemonset aws-node -n kube-system ENI_CONFIG_LABEL_DEF=failure-domain.beta.kubernetes.io/zone

Note

ENI_CONFIG_ANNOTATION_DEF 環境変数のキーが k8s.amazonaws.com/eniConfig になっている注釈が、aws-node デーモンセットのコンテナ仕様にないことを確認します。その注釈がある場合は、ENI_CONFIG_LABEL_DEF 値が上書きされるため、削除する必要があります。kubectl describe daemonset aws-node -nkube-system | grep ENI_CONFIG_ANNOTATION_DEF コマンドを使用して、その変数が設定されているかどうかを確認できます。出力が返されない場合、その変数は設定されていません。

7. 設定した ENIConfig ごとに、新しいセルフマネージド型ワーカーノードグループを作成します。

a. 以下の式を使用して、各ワーカーノードでスケジュールできるポッドの最大数を決定します。

maxPods = (number of interfaces - 1) * (max IPv4 address per interface - 1) + 2

たとえば、m5.large インスタンスタイプは、3 つのネットワークインターフェイスと、インターフェイスごとに 10 個の IPv4 アドレスをサポートします。これらの値を式に代入すると、以下の計算に示すように、インスタンスは最大 20 のポッドをサポートできるのがわかります。

maxPods = (3 - 1) * (10 - 1) + 2 = 20

インスタンスタイプごとのネットワークインターフェイスの最大数の詳細については、Linux インスタンス用 Amazon EC2 ユーザーガイドの「Elastic Network Interface」を参照してください。

b. Amazon EKS Linux ワーカーノードの起動 (p. 95) の [Self-managed nodes (セルフマネージド型ノード)] タブにある手順に従って、新しいセルフマネージド型ワーカーノードグループをそれぞれ作成します。AWS CloudFormation テンプレートを開いた後、指示に従って値を入力します。[BootstrapArguments] フィールドに、次の値を入力します。

--use-max-pods false --kubelet-extra-args '--max-pods=20'

8. ワーカーノードグループが作成されたら、ワーカーノードグループごとに作成されたセキュリティグループを記録し、それを関連付けられた ENIConfig に適用します。次のコマンドで各 ENIConfigを編集し、eniconfig-name を独自の値に置き換えます。

178


Amazon EKS ユーザーガイドCNI Metrics Helper

kubectl edit eniconfig.crd.k8s.amazonaws.com/eniconfig-name

上記の手順 5a および 5c のベストプラクティスに従った場合、eniconfig-name はアベイラビリティーゾーン名に対応します。

spec セクションは、次のようになります。

spec: securityGroups: - sg-0dff222a2d22c2c22 subnet: subnet-022b222c2f22fdf22

9. クラスター内にポッドが配置されているワーカーノードがある場合は、この手順を完了する前にそれらを終了する必要があります。新しいカスタムのネットワーキング機能は、k8s.amazonaws.com/eniConfig ラベルで登録されている新しいノードでのみ使用されます。

CNI Metrics HelperCNI メトリクスヘルパーは、Elastic Network Interface と IP アドレス情報を収集し、クラスターレベルでメトリクスを集計し、メトリクスを Amazon CloudWatch に発行するために使用できるツールです。

Amazon EKS クラスターを管理するときは、割り当てられた IP アドレスの数と、使用可能な IP アドレスの数を調べることができます。CNI メトリクスヘルパーは、以下のために役立ちます。

• メトリクスを経時的に追跡する• IP の割り当てと再利用に関連する問題をトラブルシューティングおよび診断する• キャパシティープランニングに関する洞察を提供する

ワーカーノードがプロビジョニングされると、CNI プラグインはノードのサブネットからプライマリElastic Network Interface (eth0) にセカンダリ IP アドレスのプールを自動的に割り当てます。この IP アドレスのプールはウォームプールと呼ばれ、そのサイズはワーカーノードのインスタンスタイプによって決まります。たとえば、c4.large インスタンスは 3 つの Elastic Network Interface と、インターフェイスごとに 9 つの IP アドレスをサポートできます。IP アドレスの 1 つが Elastic Network Interface 自体用に予約されているため、特定のポッドに使用できる IP アドレスの数は最大数 (10) より 1 つ小さくなります。詳細については、Linux インスタンス用 Amazon EC2 ユーザーガイドの「各インスタンスタイプのネットワークインターフェイスごとの IP アドレス」を参照してください。

IP アドレスのプールが枯渇すると、プラグインは別の Elastic Network Interface をインスタンスに自動的にアタッチし、別のセカンダリ IP アドレスのセットをそのインターフェイスに割り当てます。このプロセスは、ノードが追加の Elastic Network Interface をサポートできなくなるまで続きます。

クラスターに対して次のメトリクスが収集され、CloudWatch にエクスポートされます。

• クラスターがサポートできる Elastic Network Interface の最大数• ポッドに割り当てられている Elastic Network Interface の数• 現在ポッドに割り当てられている IP アドレスの数• 使用可能な IP アドレスの合計数と最大数• ipamD エラーの数

CNI メトリクスヘルパーのデプロイCNI メトリクスヘルパーには、CloudWatch にメトリクスデータを送信するためのcloudwatch:PutMetricData アクセス許可が必要です。このセクションでは、そのアクセス許可を持

179




つ IAM ポリシーを作成し、ワーカーノードインスタンスロールに適用して、CNI メトリクスヘルパーをデプロイします。

CNI メトリクスヘルパーに IAM ポリシーを作成するには

1. allow_put_metrics_data.json という名前のファイルを作成し、次のポリシードキュメントを入力します。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "cloudwatch:PutMetricData", "Resource": "*" } ]}

2. ワーカーノードインスタンスプロファイルに対して、CNIMetricsHelperPolicy という IAM ポリシーを作成し、CNI Metrics Helper がユーザーに代わって AWS API を呼び出せるようにします。次のAWS CLI コマンドを使用して、AWS アカウントで IAM ポリシーを作成します。

aws iam create-policy --policy-name CNIMetricsHelperPolicy \--description "Grants permission to write metrics to CloudWatch" \--policy-document file://allow_put_metrics_data.json

返されるポリシー ARN を書き留めておきます。3. ワーカーノード用の IAM ロール名を取得します。次のコマンドを使用して、aws-auth configmap を

出力します。

kubectl -n kube-system describe configmap aws-auth

出力:

Name: aws-authNamespace: kube-systemLabels: <none>Annotations: <none>

Data====mapRoles:----- groups: - system:bootstrappers - system:nodes rolearn: arn:aws:iam::111122223333:role/eksctl-prod-nodegroup-standard-wo-NodeInstanceRole-GKNS581EASPU username: system:node:{{EC2PrivateDNSName}}

Events: <none>

system:nodes グループが割り当てられている rolearn 値のロール名を記録します。この出力例では、ロール名は eksctl-prod-nodegroup-standard-wo-NodeInstanceRole-GKNS581EASPUになります。クラスターの各ノードグループに 1 つの値が必要です。

180


4. 次のコマンドを使用して、前に識別した各ワーカーノードの IAM ロールに、新しいCNIMetricsHelperPolicy IAM ポリシーをアタッチします。赤いテキストは、自分の AWS アカウント番号とワーカーノードの IAM ロール名に置き換えます。

aws iam attach-role-policy \--policy-arn arn:aws:iam::111122223333:policy/CNIMetricsHelperPolicy \--role-name eksctl-prod-nodegroup-standard-wo-NodeInstanceRole-GKNS581EASPU

CNI メトリクスヘルパーをデプロイするには

• 次のコマンドを使用して CNI メトリクスヘルパーマニフェストを適用します。

kubectl apply -f https://raw.githubusercontent.com/aws/amazon-vpc-cni-k8s/release-1.6/config/v1.6/cni-metrics-helper.yaml

メトリクスダッシュボードの作成CNI メトリクスヘルパーをデプロイしたら、CloudWatch コンソールで CNI メトリクスを表示できます。このトピックでは、クラスターの CNI メトリクスを表示するためのダッシュボードを作成する方法について説明します。

CNI メトリクスダッシュボードを作成するには

1. https://console.aws.amazon.com/cloudwatch/ にある CloudWatch コンソールを開きます。2. 左のナビゲーションで、[メトリクス] を選択します。3. [Custom Namespaces (カスタム名前空間)] で、[Kubernetes] を選択します。4. [CLUSTER_ID] を選択します。5. [すべてのメトリクス] タブで、ダッシュボードに追加するメトリクスを選択します。6. [アクション]、[ダッシュボードに追加] の順に選択します。7. [Select a dashboard (ダッシュボードの選択)] セクションで [新規作成] を選択し、ダッシュボードの名

前（「EKS-CNI-metrics」など）を入力します。8. [Select a widget type (ウィジェットタイプの選択)] セクションで、 [数値] を選択します。9. [Customize the widget title (ウィジェットタイトルのカスタマイズ)] セクションで、ダッシュボードタ

イトルの論理名 (「EKS CNI メトリクス」など) を入力します。10. [ダッシュボードに追加] を選択して終了します。これで、以下に示すように、CNI メトリクスがモニ

タリングできるダッシュボードに追加されます。

181

https://console.aws.amazon.com/cloudwatch/

Amazon EKS ユーザーガイドCNI のアップグレード

Amazon VPC CNI Plugin for Kubernetes のアップグレードAmazon EKS クラスターを起動すると、最新バージョンの Amazon VPC CNI plugin for Kubernetes がクラスターに適用されます。プラグインの確実な最新バージョンは、新しいクラスターがそれを使用するように切り替えられる前に、短期間 GitHub で利用できます。Amazon EKS は、新しいバージョンがリリースされたときに、クラスター上の CNI プラグインを自動的にアップグレードしません。既存のクラスターでCNI プラグインの新しいバージョンを取得するには、プラグインを手動でアップグレードする必要があります。

推奨される最新バージョンはバージョン 1.6.1 です。GitHub で、プラグインの使用可能な各リリースを確認し、各バージョンのリリースノートを閲覧できます。

CNI プラグインバージョンを確認して最新の推奨バージョンにアップグレードするには、次の手順を使用します。

Amazon VPC CNI Plugin for Kubernetes のバージョンを確認するには

• 次のコマンドを使用して、クラスターの CNI バージョンを出力します。


出力:


この出力例の CNI バージョンは 1.5.7 で、現在の推奨バージョン 1.6.1 より古いものです。CNI をアップグレードするには、次の手順を使用します。

Amazon VPC CNI Plugin for Kubernetes をアップグレードするには

• CNI バージョンを最新の推奨バージョンにアップグレードするには、以下のコマンドを使用します。


CoreDNS のインストールまたはアップグレードCoreDNS は、Kubernetes バージョン 1.13 以降の Amazon EKS クラスターでサポートされています。Kubernetes バージョン 1.10 で作成されたクラスターは、デフォルトの DNS およびサービス検出プロバイダーとして kube-dns に付属していました。1.10 クラスターから更新し、DNS とサービス検出にCoreDNS を使用する場合は、CoreDNS をインストールして、kube-dns を削除する必要があります。

クラスターですでに CoreDNS が実行されているかどうかを確認するには、次のコマンドを使用します。

kubectl get pod -n kube-system -l k8s-app=kube-dns

出力のポッド名に coredns と示されている場合、CoreDNS はすでにクラスターで実行されています。それ以外の場合は、以下の手順を使用して、DNS およびサービス検出プロバイダーを CoreDNS に更新します。

182


https://github.com/aws/amazon-vpc-cni-k8s/releases

https://github.com/aws/amazon-vpc-cni-k8s/releases

Amazon EKS ユーザーガイドCoreDNS のインストールまたはアップグレード

Note

CoreDNS のサービスは、引き続き下位互換性のため kube-dns と呼ばれます。

kubectl を使用して、更新された Amazon EKS クラスターに CoreDNS をインストールするには

1. クラスターの kube-dns デプロイに {"eks.amazonaws.com/component": "kube-dns"} セレクタを追加します。これにより、2 つの DNS デプロイメントが同じラベルセットのコントロールをめぐって競合するのを防ぐことができます。

kubectl patch -n kube-system deployment/kube-dns --patch \'{"spec":{"selector":{"matchLabels":{"eks.amazonaws.com/component":"kube-dns"}}}}'

2. CoreDNS をクラスターにデプロイします。

a. クラスターの DNS IP アドレスを DNS_CLUSTER_IP 環境変数に設定します。

export DNS_CLUSTER_IP=$(kubectl get svc -n kube-system kube-dns -o jsonpath='{.spec.clusterIP}')

b. REGION 環境変数をクラスターの AWS region-code に設定します。

export REGION="region-code"

c. Amazon EKS リソースバケットから CoreDNS マニフェストをダウンロードします。

curl -o dns.yaml https://amazon-eks.s3.us-west-2.amazonaws.com/cloudformation/2020-04-21/dns.yaml

d. dns.yaml ファイルのプレースホルダーを環境変数の値に置き換え、更新後のマニフェストをクラスターに適用します。次のコマンドでは、1 つのステップでこれを完了することができます。

cat dns.yaml | sed -e "s/REGION/$REGION/g" | sed -e "s/DNS_CLUSTER_IP/$DNS_CLUSTER_IP/g" | kubectl apply -f -

e. クラスターから coredns ポッド名を取得します。

COREDNS_POD=$(kubectl get pod -n kube-system -l eks.amazonaws.com/component=coredns \-o jsonpath='{.items[0].metadata.name}')

f. coredns ポッドに対してクエリを実行し、リクエストを受信していることを確認します。

kubectl get --raw /api/v1/namespaces/kube-system/pods/$COREDNS_POD:9153/proxy/metrics \| grep 'coredns_dns_request_count_total'

Note

クラスターの DNS リクエストの回数に応じて、出力が正常に返るまでには数分かかる場合があります。

次の正常な出力において、23 は DNS リクエストの合計数です。

✓ HELP coredns_dns_request_count_total Counter of DNS requests made per zone, protocol and family.✓ TYPE coredns_dns_request_count_total counter

183

Amazon EKS ユーザーガイドCoreDNS のアップグレード

coredns_dns_request_count_total{family="1",proto="udp",server="dns://:53",zone="."} 23

3. 「the section called “CoreDNS のアップグレード” (p. 184)」のステップを実行して、CoreDNS をクラスター用の推奨バージョンにアップグレードします。

4. kube-dns デプロイをゼロレプリカにスケールダウンします。

kubectl scale -n kube-system deployment/kube-dns --replicas=0

5. 古い kube-dns リソースをクリーンアップします。

kubectl delete -n kube-system deployment/kube-dns serviceaccount/kube-dns configmap/kube-dns

CoreDNS のアップグレード1. クラスターの coredns デプロイの現在のバージョンを確認します。

kubectl describe deployment coredns --namespace kube-system | grep Image | cut -d "/" -f 3

出力:

coredns:v1.1.3

対応する Kubernetes バージョンに対して推奨される coredns のバージョンは以下のとおりです。


1.16 1.15 1.14 1.13 1.12

CoreDNS 1.6.6 1.6.6 1.6.6 1.6.6 1.6.6

2. coredns の現在のバージョンが 1.5.0 以降かつ推奨バージョンより前の場合、このステップをスキップしてください。現在のバージョンが 1.5.0 より前の場合、proxy プラグインではなく forward プラグインを使用するように coredns の設定マップを変更する必要があります。

a. 次のコマンドを使用して設定マップを開きます。

kubectl edit configmap coredns -n kube-system

b. 次の行の proxy を forward に置き換えます。ファイルを保存し、エディタを終了します。

proxy . /etc/resolv.conf

3. coredns を推奨バージョンに更新して、region-code をお客様のリージョンに、1.6.6 をお客様のクラスターの coredns の推奨バージョンに置き換えます。

kubectl set image --namespace kube-system deployment.apps/coredns \ coredns=602401143452.dkr.ecr.us-west-2.amazonaws.com/eks/coredns:v1.6.6

184

Amazon EKS ユーザーガイドAmazon EKS に Calico をインストールする

Amazon EKS に Calico をインストールするProject Calico は、Kubernetes のネットワークポリシーエンジンです。Calico ネットワークポリシーの実施によって、ネットワークのセグメンテーションとテナントの隔離を実装できます。これは、マルチテナント環境でテナントを相互に分離する必要がある場合や、開発、ステージング、本稼働用に個別の環境を作成する場合に便利です。ネットワークポリシーは、ネットワークの入力および出力ルールを作成できる点で AWS セキュリティグループと似ています。インスタンスをセキュリティグループに割り当てるのではなく、ポッドセレクタおよびラベルを使用してネットワークポリシーをポッドに割り当てます。次の手順では、Amazon EKS クラスターに Calico をインストールする方法について説明します。

Note

Amazon EKS で Fargate を使用する場合、Calico はサポートされません。

Amazon EKS クラスターに Calico をインストールするには

1. 「aws/amazon-vpc-cni-k8sGitHub プロジェクト」から Calico マニフェストを適用します。このマニフェストによって、kube-system 名前空間にデーモンセットが作成されます。

kubectl apply -f https://raw.githubusercontent.com/aws/amazon-vpc-cni-k8s/release-1.6/config/v1.6/calico.yaml

2. kube-system デーモンセットを監視して、calico-node デーモンセットのポッドが READY 状態でDESIRED 数になるまで待機します。この場合、Calico は動作しています。

kubectl get daemonset calico-node --namespace kube-system

出力:

NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGEcalico-node 3 3 3 3 3 <none> 38s

Calico を Amazon EKS クラスターから削除するには

• Amazon EKS クラスターで Calico が不要になった場合は、以下のコマンドを使用してデーモンセットを削除できます。

kubectl delete -f https://raw.githubusercontent.com/aws/amazon-vpc-cni-k8s/release-1.6/config/v1.6/calico.yaml

Stars Policy デモこのセクションでは、Project Calico ドキュメントに用意されている「Stars Policy デモ」について説明していきます。このデモでは、Amazon EKS クラスターにフロントエンド、バックエンド、およびクライアントサービスを作成します。また、このデモでは、各サービス間で利用可能な入力および出力のパスを示す管理 GUI が作成されます。

ネットワークポリシーを作成する前に、サービスはすべて、双方向に通信できます。ネットワークポリシーを適用すると、クライアントはフロントエンドサービスとのみ、バックエンドはフロントエンドとのみ通信できることがわかります。

185

https://www.projectcalico.org/


https://docs.projectcalico.org/v3.1/getting-started/kubernetes/tutorials/stars-policy/

Amazon EKS ユーザーガイドStars Policy デモ

Stars Policy デモを実行するには

1. フロントエンド、バックエンド、クライアント、および管理 UI サービスを適用します。

kubectl apply -f https://docs.projectcalico.org/v3.3/getting-started/kubernetes/tutorials/stars-policy/manifests/00-namespace.yamlkubectl apply -f https://docs.projectcalico.org/v3.3/getting-started/kubernetes/tutorials/stars-policy/manifests/01-management-ui.yamlkubectl apply -f https://docs.projectcalico.org/v3.3/getting-started/kubernetes/tutorials/stars-policy/manifests/02-backend.yamlkubectl apply -f https://docs.projectcalico.org/v3.3/getting-started/kubernetes/tutorials/stars-policy/manifests/03-frontend.yamlkubectl apply -f https://docs.projectcalico.org/v3.3/getting-started/kubernetes/tutorials/stars-policy/manifests/04-client.yaml

2. すべてのポッドが Running ステータスになるまで待機します。

kubectl get pods --all-namespaces --watch

3. 管理 UI に接続するには、ローカルポート 9001 をクラスター上で実行されている management-uiサービスに転送します。

kubectl port-forward service/management-ui -n management-ui 9001

4. ローカルシステムでブラウザを開き、http://localhost:9001/ を指定します。管理 UI が表示されます。[C] ノードはクライアントサービス、[F] ノードはフロントエンドサービス、[B] ノードはバックエンドサービスを表します。各ノードには、他のすべてのノードへの完全な通信アクセスが含まれます (太字で色付けされた行)。

186

http://localhost:9001/


5. 相互にサービスを分離するには、次のネットワークポリシーを適用します。

kubectl apply -n stars -f https://docs.projectcalico.org/v3.3/getting-started/kubernetes/tutorials/stars-policy/policies/default-deny.yamlkubectl apply -n client -f https://docs.projectcalico.org/v3.3/getting-started/kubernetes/tutorials/stars-policy/policies/default-deny.yaml

6. ブラウザを更新します。管理 UI はノードに到達できなくなるため、UI に表示されないことがわかります。

7. 管理 UI がサービスにアクセスできるように、次のネットワークポリシーを適用します。

kubectl apply -f https://docs.projectcalico.org/v3.3/getting-started/kubernetes/tutorials/stars-policy/policies/allow-ui.yamlkubectl apply -f https://docs.projectcalico.org/v3.3/getting-started/kubernetes/tutorials/stars-policy/policies/allow-ui-client.yaml

8. ブラウザを更新します。管理 UI は再びノードに到達できますが、ノードは相互に通信できないことがわかります。

187


9. フロントエンドサービスからバックエンドサービスへのトラフィックを許可するには、次のネットワークポリシーを適用します。

kubectl apply -f https://docs.projectcalico.org/v3.3/getting-started/kubernetes/tutorials/stars-policy/policies/backend-policy.yaml

10. client 名前空間からフロントエンドサービスへのトラフィックを許可するには、次のネットワークポリシーを適用します。

kubectl apply -f https://docs.projectcalico.org/v3.3/getting-started/kubernetes/tutorials/stars-policy/policies/frontend-policy.yaml

188


11. (オプション) デモが完了したら、以下のコマンドを使用してリソースを削除することができます。

kubectl delete -f https://docs.projectcalico.org/v3.3/getting-started/kubernetes/tutorials/stars-policy/manifests/04-client.yamlkubectl delete -f https://docs.projectcalico.org/v3.3/getting-started/kubernetes/tutorials/stars-policy/manifests/03-frontend.yamlkubectl delete -f https://docs.projectcalico.org/v3.3/getting-started/kubernetes/tutorials/stars-policy/manifests/02-backend.yamlkubectl delete -f https://docs.projectcalico.org/v3.3/getting-started/kubernetes/tutorials/stars-policy/manifests/01-management-ui.yamlkubectl delete -f https://docs.projectcalico.org/v3.3/getting-started/kubernetes/tutorials/stars-policy/manifests/00-namespace.yaml

189

Amazon EKS ユーザーガイドkubectl のインストール

クラスター認証の管理Amazon EKS では、Kubernetes クラスターの認証に IAM を使用します (AWS CLI のバージョン 1.18.49以降で使用可能な aws eks get-token コマンド、または AWS IAM Authenticator for Kubernetes 経由で)。ただし、承認には、Kubernetes ネイティブのロールベースのアクセスコントロール (RBAC) を引き続き使用します。つまり、IAM は有効な IAM エンティティの認証にのみ使用されます。Amazon EKS クラスターの Kubernetes API とやり取りするためのアクセス許可はすべて、従来の Kubernetes RBAC システムを使用して管理されます。

トピック• kubectl のインストール (p. 190)• aws-iam-authenticator のインストール (p. 196)• kubeconfig を Amazon EKS 用に作成します。 (p. 199)• クラスターのユーザーまたは IAM ロールの管理 (p. 202)

kubectl のインストールKubernetes では、クラスター API サーバーとの通信に kubectl というコマンドラインユーティリティを使用します。kubectl バイナリは、多数のオペレーティングシステムのパッケージで利用できます。このオプションは多くの場合、手動のダウンロードおよびインストールプロセスよりはるかに簡単です。Kubernetes のドキュメントにある個別のオペレーティングシステムやパッケージマネージャー用の手順に従えばインストールできます。

このトピックは、MacOS、Linux、Windows オペレーティングシステム用の Amazon EKS 提供の kubectlバイナリをダウンロードしてインストールするのに役立ちます。これらのバイナリは、アップストリームコミュニティのバージョンと同じであり、Amazon EKS または AWS に固有ではありません。

190





Note

Amazon EKS クラスターコントロールプレーンとのマイナーバージョンの相違が 1 つ以内である kubectl バージョンを使用する必要があります。たとえば、1.12 の kubectl クライアントは、Kubernetes 1.11、1.12、および 1.13 クラスターで動作します。

macOS

MacOS で kubectl をインストールするには

1. クラスターの Kubernetes バージョンに応じて、Amazon EKS 提供の kubectl バイナリを AmazonS3 からダウンロードします。

• Kubernetes 1.16:

curl -o kubectl https://amazon-eks.s3.us-west-2.amazonaws.com/1.16.8/2020-04-16/bin/darwin/amd64/kubectl



Note

このバージョンは、1.15.10 および 1.15.11 のクラスターで使用できます。• Kubernetes 1.14:






2. (オプション) ダウンロードされたバイナリを SHA-256 サムで検証します。

a. クラスターの Kubernetes バージョンに応じて、SHA-256 サム (MacOS 版) をダウンロードします。


curl -o kubectl.sha256 https://amazon-eks.s3.us-west-2.amazonaws.com/1.16.8/2020-04-16/bin/darwin/amd64/kubectl.sha256



• Kubernetes 1.14:191







b. ダウンロードしたバイナリの SHA-256 サムを確認します。

openssl sha1 -sha256 kubectl

c. コマンド出力で生成された SHA-256 sum とダウンロードした SHA-256 ファイルを比較します。両者は一致する必要があります。

3. バイナリへの実行アクセス権限を適用します。

chmod +x ./kubectl

4. バイナリを PATH のフォルダにコピーします。既に kubectl のバージョンが既にインストールされている場合、$HOME/bin/kubectl を作成し、$HOME/bin が $PATH の最初にあることを確認することをお勧めします。

mkdir -p $HOME/bin && cp ./kubectl $HOME/bin/kubectl && export PATH=$PATH:$HOME/bin

5. (オプション) シェルを開いたときに設定されるように、シェルの初期化ファイルに $HOME/binパスを追加します。

echo 'export PATH=$PATH:$HOME/bin' >> ~/.bash_profile

6. kubectl をインストールしたら、以下のコマンドを使用してそのバージョンを確認できます。

kubectl version --short --client

Linux

Linux で kubectl をインストールするには

1. クラスターの Kubernetes バージョンに応じて、Amazon EKS 提供の kubectl バイナリを AmazonS3 からダウンロードします。


curl -o kubectl https://amazon-eks.s3.us-west-2.amazonaws.com/1.16.8/2020-04-16/bin/linux/amd64/kubectl



192


Note








a. クラスターの Kubernetes バージョンに応じて、SHA-256 sum (Linux 版) をダウンロードします。


curl -o kubectl.sha256 https://amazon-eks.s3.us-west-2.amazonaws.com/1.16.8/2020-04-16/bin/linux/amd64/kubectl.sha256










openssl sha1 -sha256 kubectl

c. コマンド出力で生成された SHA-256 sum とダウンロードした SHA-256 ファイルを比較します。両者は一致する必要があります。


193


chmod +x ./kubectl

4. バイナリを PATH のフォルダにコピーします。既に kubectl のバージョンが既にインストールされている場合、$HOME/bin/kubectl を作成し、$HOME/bin が $PATH の最初にあることを確認することをお勧めします。

mkdir -p $HOME/bin && cp ./kubectl $HOME/bin/kubectl && export PATH=$PATH:$HOME/bin

5. (オプション) シェルを開いたときに設定されるように、シェルの初期化ファイルに $HOME/binパスを追加します。

Note

このステップでは、Bash シェルを使用していることを前提としています。別のシェルを使用している場合は、特定のシェル初期化ファイルを使用するよう、コマンドを変更します。

echo 'export PATH=$PATH:$HOME/bin' >> ~/.bashrc

6. kubectl をインストールしたら、以下のコマンドを使用してそのバージョンを確認できます。


Windows

Windows で kubectl をインストールするには

1. PowerShell ターミナルを開きます。2. クラスターの Kubernetes バージョンに応じて、Amazon EKS 提供の kubectl バイナリを Amazon

S3 からダウンロードします。


curl -o kubectl.exe https://amazon-eks.s3.us-west-2.amazonaws.com/1.16.8/2020-04-16/bin/windows/amd64/kubectl.exe



Note






194




a. クラスターの Kubernetes バージョンに応じて、SHA-256 sum (Windows 版) をダウンロードします。


curl -o kubectl.exe.sha256 https://amazon-eks.s3.us-west-2.amazonaws.com/1.16.8/2020-04-16/bin/windows/amd64/kubectl.exe.sha256










Get-FileHash kubectl.exe

c. コマンド出力で生成された SHA-256 sum とダウンロードした SHA-256 ファイルを比較します。2 つの出力が一致しなければなりません。ただし、PowerShell の出力は大文字になります。

4. バイナリを PATH のフォルダにコピーします。コマンドラインユーティリティで使用する PATH内に既存のディレクトリがある場合、そのディレクトリにバイナリをコピーします。それ以外の場合は、以下のステップを完了します。

a. コマンドラインのバイナリ用に新しいディレクトリ (C:\bin など) を作成します。b. kubectl.exe バイナリを新しいディレクトリにコピーします。c. ユーザーまたはシステムの PATH 環境変数を編集し、新しいディレクトリを PATH に追加し

ます。d. 新しい PATH 変数を取得するには、古い PowerShell ターミナルを閉じ、新しいターミナル

を開きます。5. kubectl をインストールしたら、以下のコマンドを使用してそのバージョンを確認できます。


195

Amazon EKS ユーザーガイドaws-iam-authenticator のインストール

aws-iam-authenticator のインストールAmazon EKS では、Kubernetes クラスターの認証に IAM を使用します (AWS IAM Authenticator forKubernetes 経由で)。Amazon EKS を使用するようにストックの kubectl クライアントを設定できます。そのためには、AWS IAM Authenticator for Kubernetes をインストールし、それを認証に使用するようにkubectl 設定ファイルを変更します。

macOS

Homebrew を使用して aws-iam-authenticator をインストールするには

aws-iam-authenticator をインストールする最も簡単な方法は、Homebrew を使用することです。

1. Mac で Homebrew がまだインストールされていない場合は、以下のコマンドでインストールします。


2. 以下のコマンドを使用して aws-iam-authenticator をインストールします。

brew install aws-iam-authenticator

3. aws-iam-authenticator バイナリの動作をテストします。

aws-iam-authenticator help

MacOS で aws-iam-authenticator をインストールするには

以下の手順に従って、aws-iam-authenticator の AWS 提供バージョンをインストールすることもできます。

1. Amazon EKS 提供の aws-iam-authenticator バイナリを Amazon S3 からダウンロードします。

curl -o aws-iam-authenticator https://amazon-eks.s3.us-west-2.amazonaws.com/1.16.8/2020-04-16/bin/darwin/amd64/aws-iam-authenticator

2. (オプション) ダウンロードしたバイナリを同じバケットプレフィックスの SHA-256 サムで検証します。

a. システムの SHA-256 サムをダウンロードします。

curl -o aws-iam-authenticator.sha256 https://amazon-eks.s3.us-west-2.amazonaws.com/1.16.8/2020-04-16/bin/darwin/amd64/aws-iam-authenticator.sha256


openssl sha1 -sha256 aws-iam-authenticator

c. コマンド出力で生成された SHA-256 サムとダウンロードした aws-iam-authenticator.sha256 ファイルを比較します。両者は一致する必要があります。


196



https://brew.sh/

https://brew.sh/


chmod +x ./aws-iam-authenticator

4. バイナリを $PATH のフォルダにコピーします。$HOME/bin/aws-iam-authenticator を作成し、$HOME/bin が $PATH の先頭になっていることをお勧めします。

mkdir -p $HOME/bin && cp ./aws-iam-authenticator $HOME/bin/aws-iam-authenticator && export PATH=$PATH:$HOME/bin

5. $HOME/bin を PATH 環境変数に追加します。

echo 'export PATH=$PATH:$HOME/bin' >> ~/.bash_profile



Linux

Linux で aws-iam-authenticator をインストールするには

1. Amazon EKS 提供の aws-iam-authenticator バイナリを Amazon S3 からダウンロードします。

curl -o aws-iam-authenticator https://amazon-eks.s3.us-west-2.amazonaws.com/1.16.8/2020-04-16/bin/linux/amd64/aws-iam-authenticator



curl -o aws-iam-authenticator.sha256 https://amazon-eks.s3.us-west-2.amazonaws.com/1.16.8/2020-04-16/bin/linux/amd64/aws-iam-authenticator.sha256


openssl sha1 -sha256 aws-iam-authenticator

c. コマンド出力で生成された SHA-256 サムとダウンロードした aws-iam-authenticator.sha256 ファイルを比較します。両者は一致する必要があります。


chmod +x ./aws-iam-authenticator

4. バイナリを $PATH のフォルダにコピーします。$HOME/bin/aws-iam-authenticator を作成し、$HOME/bin が $PATH の先頭になっていることをお勧めします。

mkdir -p $HOME/bin && cp ./aws-iam-authenticator $HOME/bin/aws-iam-authenticator && export PATH=$PATH:$HOME/bin

5. $HOME/bin を PATH 環境変数に追加します。

echo 'export PATH=$PATH:$HOME/bin' >> ~/.bashrc

197




Windows

Chocolatey を使用して aws-iam-authenticator を Windows にインストールするには


2. PowerShell ターミナルウィンドウを開き、次のコマンドを使用して、aws-iam-authenticator をインストールします。

choco install -y aws-iam-authenticator



Windows で aws-iam-authenticator をインストールするには

1. PowerShell ターミナルウィンドウを開き、Amazon EKS で発行されたaws-iam-authenticator バイナリを Amazon S3 からダウンロードします。

curl -o aws-iam-authenticator.exe https://amazon-eks.s3.us-west-2.amazonaws.com/1.16.8/2020-04-16/bin/windows/amd64/aws-iam-authenticator.exe



curl -o aws-iam-authenticator.sha256 https://amazon-eks.s3.us-west-2.amazonaws.com/1.16.8/2020-04-16/bin/windows/amd64/aws-iam-authenticator.exe.sha256


Get-FileHash aws-iam-authenticator.exe

c. コマンド出力で生成された SHA-256 sum とダウンロードした SHA-256 ファイルを比較します。2 つの出力が一致しなければなりません。ただし、PowerShell の出力は大文字になります。

3. バイナリを PATH のフォルダにコピーします。コマンドラインユーティリティで使用する PATH内に既存のディレクトリがある場合、そのディレクトリにバイナリをコピーします。それ以外の場合は、以下のステップを完了します。

a. コマンドラインのバイナリ用に新しいディレクトリ (C:\bin など) を作成します。b. aws-iam-authenticator.exe バイナリを新しいディレクトリにコピーします。c. ユーザーまたはシステムの PATH 環境変数を編集し、新しいディレクトリを PATH に追加し

ます。d. 新しい PATH 変数を取得するには、古い PowerShell ターミナルを閉じ、新しいターミナル

を開きます。4. aws-iam-authenticator バイナリの動作をテストします。

198



Amazon EKS ユーザーガイドkubeconfig を Amazon EKS 用に作成します。


既存の Amazon EKS クラスターがある場合は、そのクラスターの kubeconfig ファイルを作成します。詳細については、「kubeconfig を Amazon EKS 用に作成します。 (p. 199)」を参照してください。それ以外の場合は、Amazon EKS クラスターの作成 (p. 22) を参照の上、新しい Amazon EKS クラスターを作成します。

kubeconfig を Amazon EKS 用に作成します。このセクションでは、クラスター用の kubeconfig ファイルを作成し、また、既存のファイルを更新します。

このセクションでは、kubeconfig を作成または更新する 2 つの手順を示します。最初の手順に従ってAWS CLI update-kubeconfig コマンドで kubeconfig をすばやく作成または更新することも、2 番目の手順に従って手動で kubeconfig を作成することもできます。

Amazon EKS では、クラスターの認証に、AWS CLI のバージョン 1.18.49 以降で使用可能な aws eks get-token コマンドを使用するか、または AWS IAM Authenticator for Kubernetes を kubectl と共に使用します。システムに AWS CLI をインストール済みである場合、AWS IAM Authenticator for Kubernetes でデフォルトで使用される認証情報は、以下のコマンドで返されるものと同じです。

aws sts get-caller-identity

詳細については、AWS Command Line Interface ユーザーガイドの「AWS CLI の設定」を参照してください。

kubeconfig ファイルを AWS CLI で作成するには

1. AWS CLI のバージョン 1.18.49 以降がインストールされていることを確認します。AWS CLI をインストールまたはアップグレードするには、AWS Command Line Interface ユーザーガイドの「AWS コマンドラインインターフェイスのインストール」を参照してください。

Note

システムの Python のバージョンは 2.7.9 以降であることが必要です。そうでない場合は、AWS CLI で Amazon EKS を呼び出すと hostname doesn't match エラーが発生します。


aws --version

Important


2. クラスターの kubeconfig を作成または更新するには、AWS CLI update-kubeconfig コマンドを使用します。

• デフォルトでは、最終的な設定ファイルは、ホームディレクトリのデフォルト kubeconfig パス(.kube/config) に作成されるか、その場所で既存 kubeconfig とマージされます。別のパスは --kubeconfig オプションを使用して指定できます。

199


https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html





• kubectl コマンドを実行するときに、認証に使用する --role-arn オプションを指定して IAMロール ARN を指定できます。それ以外の場合は、デフォルトの AWS CLI または SDK の認証情報チェーンの中の IAM エンティティが使用されます。デフォルトの AWS CLI または SDK の ID を表示するには、 aws sts get-caller-identity コマンドを実行します。

• 詳細については、aws eks update-kubeconfig help コマンドを使用するか、AWS CLI CommandReference の「update-kubeconfig」を参照してください。

Note

以下のコマンドを実行するには、指定したクラスター名に対する eks:DescribeClusterIAM アクセス許可がアカウントに割り当てられている必要があります。

aws eks --region region-code update-kubeconfig --name cluster_name


kubectl get svc

Note


出力:


kubeconfig ファイルを手動で作成するには

1. デフォルトの ~/.kube フォルダを作成します (まだない場合)。

mkdir -p ~/.kube

2. テキストエディタを開き、優先するクライアントトークン方式に応じて、以下の kubeconfig コードブロックのいずれかをコピーします。

• AWS CLI aws eks get-token コマンドを使用するには (AWS CLI のバージョン 1.18.49 以降が必要です):

apiVersion: v1clusters:- cluster: server: <endpoint-url> certificate-authority-data: <base64-encoded-ca-cert> name: kubernetescontexts:- context: cluster: kubernetes user: aws name: awscurrent-context: aws

200

https://docs.aws.amazon.com/cli/latest/reference/eks/update-kubeconfig.html


kind: Configpreferences: {}users:- name: aws user: exec: apiVersion: client.authentication.k8s.io/v1alpha1 command: aws args: - "eks" - "get-token" - "--cluster-name" - "<cluster-name>" ✓ - "--role" ✓ - "<role-arn>" ✓ env: ✓ - name: AWS_PROFILE ✓ value: "<aws-profile>"

• AWS IAM Authenticator for Kubernetes を使用するには:

apiVersion: v1clusters:- cluster: server: <endpoint-url> certificate-authority-data: <base64-encoded-ca-cert> name: kubernetescontexts:- context: cluster: kubernetes user: aws name: awscurrent-context: awskind: Configpreferences: {}users:- name: aws user: exec: apiVersion: client.authentication.k8s.io/v1alpha1 command: aws-iam-authenticator args: - "token" - "-i" - "<cluster-name>" ✓ - "-r" ✓ - "<role-arn>" ✓ env: ✓ - name: AWS_PROFILE ✓ value: "<aws-profile>"

3. <endpoint-url> をクラスターに作成された endpoint URL に置き換えます。4. <base64-encoded-ca-cert> をクラスターに作成された certificateAuthority.data に置き

換えます。5. <cluster-name> をクラスター名に置き換えます。6. (オプション) デフォルトの AWS 認証情報プロバイダーチェーンの代わってクラスターのオペレー

ションを実行するための IAM ロールを引き受けるには、-r または --role 行と、<role-arn> 行をコメント解除し、使用する IAM ロール ARN を実際のユーザーに置き換えます。

7. (オプション) デフォルトの AWS 認証情報プロバイダーチェーンに代わって常に特定の名前付き AWS認証情報プロファイルを使用するには、env 行をコメント解除し、<aws-profile> を、使用するプロファイル名に置き換えます。

201


Amazon EKS ユーザーガイドクラスターのユーザーまたは IAM ロールの管理

8. ファイル名にクラスター名を入れて、ファイルをデフォルトの kubectl フォルダに保存します。たとえば、クラスター名が devel の場合、ファイルは ~/.kube/config-devel に保存します。

9. そのファイルパスを KUBECONFIG 環境変数に追加し、クラスター設定をどこで探せばいいか、kubectl に教えます。

• macOS または Linux 上の Bash シェルの場合:

export KUBECONFIG=$KUBECONFIG:~/.kube/config-devel

• Windows 上の PowerShell の場合:

$ENV:KUBECONFIG="{0};{1}" -f $ENV:KUBECONFIG, "$ENV:userprofile\.kube\config-devel"

10. (オプション) シェルを開くと設定されるように、シェルの初期化ファイルに設定を追加します。

• macOS の場合、Bash シェル。

echo 'export KUBECONFIG=$KUBECONFIG:~/.kube/config-devel' >> ~/.bash_profile

• Linux の場合、Bash シェル。

echo 'export KUBECONFIG=$KUBECONFIG:~/.kube/config-devel' >> ~/.bashrc

• Windows 上の PowerShell の場合:

[System.Environment]::SetEnvironmentVariable('KUBECONFIG', $ENV:KUBECONFIG, 'Machine')


kubectl get svc

Note


出力:


クラスターのユーザーまたは IAM ロールの管理Amazon EKS クラスターを作成すると、このクラスターを作成した IAM エンティティユーザーまたはロール (例: フェデレーティッドユーザー) は、クラスターの RBAC 設定で system:masters のアクセス許可が自動的に付与されます。クラスターを操作する権限を他の AWS ユーザーやロールに付与するには、Kubernetes 内の aws-auth ConfigMap を編集する必要があります。

202

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html


Note

さまざまな IAM アイデンティティの詳細については、IAM ユーザーガイドの「アイデンティティ(ユーザー、グループ、ロール)」を参照してください。Kubernetes の RBAC 設定の詳細については、RBAC 認可の使用を参照してください。すべての ConfigMap 設定については、GitHub の「Full Configuration Format」を参照してください。

aws-auth ConfigMap は、Amazon EKS の開始方法 (p. 3)ガイドの一部として適用されます。このガイドでは、Amazon EKS クラスターの作成からサンプル Kubernetes アプリケーションのデプロイまで、最初から終わりまでのウォークスルーを行います。ConfigMap は、ワーカーノードをクラスターに追加するために当初作成されたものですが、RBAC を IAM ユーザーとロールに追加するために使用することもできます。まだワーカーノードを起動して aws-authConfigMap を適用していない場合は、次の手順に従って適用できます。

aws-auth ConfigMap をクラスターに適用するには

1. aws-authConfigMap が適用済みであるかどうかを確認します。

kubectl describe configmap -n kube-system aws-auth

「Error from server (NotFound): configmaps "aws-auth" not found」というエラーが表示された場合は、以下のステップを実行してストック ConfigMap を適用します。

2. AWS オーセンティケーター設定マップをダウンロード、編集、適用します。

a. 設定マップをダウンロードします。

curl -o aws-auth-cm.yaml https://amazon-eks.s3.us-west-2.amazonaws.com/cloudformation/2020-04-21/aws-auth-cm.yaml

b. 任意のテキストエディタでファイルを開きます。<イイイイイイイイイイイイイイイイ) イイイイイイイイイイ ARN)>スニペットを、ワーカーノードに関連付けられた IAM ロールの Amazon リソースネーム (ARN)に置き換えて、ファイルを保存します。ワーカーノードグループの AWS CloudFormation スタック出力を検査し、次の値を探すことができます。

• InstanceRoleARN (eksctl で作成されたワーカーノードグループ用)• NodeInstanceRole (AWS マネジメントコンソールの Amazon EKS で発行された AWS

CloudFormation テンプレートで作成されたワーカーノードグループ用)

Important


apiVersion: v1kind: ConfigMapmetadata: name: aws-auth namespace: kube-systemdata: mapRoles: | - rolearn: <ARN of instance role (not instance profile)> username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes


203



https://kubernetes.io/docs/reference/access-authn-authz/rbac/

https://github.com/kubernetes-sigs/aws-iam-authenticator#full-configuration-format



Note




IAM ユーザーまたはロールを Amazon EKS クラスターに追加するには

1. kubectl が使用している AWS 認証情報が、クラスターですでに認証されていることを確認します。クラスターを作成した IAM ユーザーには、デフォルトでこれらのアクセス許可が付与されています。

2. aws-auth ConfigMap を開きます。

kubectl edit -n kube-system configmap/aws-auth

Note

「Error from server (NotFound): configmaps "aws-auth" not found」というエラーが表示された場合は、前の手順を使用してストック ConfigMap を適用します。

ConfigMap の例:

✓ Please edit the object below. Lines beginning with a '✓' will be ignored,✓ and an empty file will abort the edit. If an error occurs while saving this file will be✓ reopened with the relevant failures.✓apiVersion: v1data: mapRoles: | - rolearn: arn:aws:iam::111122223333:role/doc-test-worker-nodes-NodeInstanceRole-WDO5P42N3ETB username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodeskind: ConfigMapmetadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"v1","data":{"mapRoles":"- rolearn: arn:aws:iam::111122223333:role/doc-test-worker-nodes-NodeInstanceRole-WDO5P42N3ETB\n username: system:node:{{EC2PrivateDNSName}}\n groups:\n - system:bootstrappers\n - system:nodes\n"},"kind":"ConfigMap","metadata":{"annotations":{},"name":"aws-auth","namespace":"kube-system"}} creationTimestamp: 2018-04-04T18:49:10Z name: aws-auth namespace: kube-system resourceVersion: "780" selfLink: /api/v1/namespaces/kube-system/configmaps/aws-auth

204


uid: dcc31de5-3838-11e8-af26-02e00430057c

3. IAM ユーザー、ロール、または AWS アカウントを configMap に追加します。

• IAM ユーザーを追加するには、ConfigMap の mapUsers セクションの data の下にユーザーの詳細を追加します。ファイルに存在しない場合は、このセクションを追加します。各エントリは、次のパラメータをサポートしています。• userarn: 追加する IAM ユーザーの ARN。• username: IAM ユーザーにマッピングする Kubernetes 内のユーザー名。• groups: ユーザーがマッピングされている、Kubernetes 内のグループのリスト。詳細について

は、Kubernetes ドキュメントのデフォルトのロールとロールのバインディングを参照してください。

• IAM ロールを (たとえば、フェデレーティッドユーザー) に追加するには、 ConfigMap のmapRoles セクションの data の下にロールの詳細を追加します。ファイルに存在しない場合は、このセクションを追加します。各エントリは、次のパラメータをサポートしています。• rolearn: 追加する IAM ロールの ARN 。• username: IAM ロールにマッピングする Kubernetes 内のユーザー名。• groups: ロールがマッピングされている、Kubernetes 内のグループのリスト。詳細について

は、Kubernetes ドキュメントのデフォルトのロールとロールのバインディングを参照してください。

たとえば、次のブロックには以下が含まれます。

• mapRoles セクション。ワーカーノードが自分でクラスターに登録できるように、ワーカーノードインスタンスロールを追加します。

• mapUsers セクション。デフォルトの AWS アカウントの AWS ユーザー admin と、別の AWS アカウントの ops-user が含まれます。いずれのユーザーも system:masters グループに追加されます。

✓ Please edit the object below. Lines beginning with a '✓' will be ignored,✓ and an empty file will abort the edit. If an error occurs while saving this file will be✓ reopened with the relevant failures.✓apiVersion: v1data: mapRoles: | - rolearn: arn:aws:iam::555555555555:role/devel-worker-nodes-NodeInstanceRole-74RF4UBDUKL6 username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes mapUsers: | - userarn: arn:aws:iam::555555555555:user/admin username: admin groups: - system:masters - userarn: arn:aws:iam::111122223333:user/ops-user username: ops-user groups: - system:masters

4. ファイルを保存し、テキストエディタを終了します。

205

https://kubernetes.io/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings


https://kubernetes.io/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings

Amazon EKS ユーザーガイドeksctl のインストールまたはアップグレード

eksctl コマンドラインユーティリティ

この章では、Amazon EKS で Kubernetes クラスターを作成および管理するためのシンプルなコマンドラインユーティリティである eksctl について説明します。eksctl コマンドラインユーティリティにより、最も高速かつ簡単な方法で、Amazon EKS 用に新しいクラスターとワーカーノードを作成できます。

詳細および公式のドキュメントを参照するには、https://eksctl.io/ にアクセスしてください。

eksctl のインストールまたはアップグレードこのセクションは、eksctl コマンドラインユーティリティの最新バージョンをインストールまたはアップグレードするのに役立ちます。

以下からクライアントの設定を最もよく表しているタブを選択します。

macOS

Homebrew を使用して macOS で eksctl をインストールまたはアップグレードするには

Amazon EKS と macOS の使用を開始する最も簡単な方法は、Homebrew を使用して eksctl をインストールすることです。eksctl Homebrew レシピは、eksctl と Amazon EKS に必要なその他の依存関係 (kubectl、aws-iam-authenticator など) をインストールします。

1. Mac OS で Homebrew をまだインストールしていない場合は、以下のコマンドでインストールします。


2. Weaveworks Homebrew tap をインストールします。

brew tap weaveworks/tap

3. eksctl をインストールまたはアップグレードします。

• 以下のコマンドを使用して、eksctl をインストールします。

brew install weaveworks/tap/eksctl

• eksctl がすでにインストールされている場合は、以下のコマンドでアップグレードします。

brew upgrade eksctl && brew link --overwrite eksctl


eksctl version

Note

GitTag のバージョンは 0.19.0 以上であることが必要です。そうでない場合は、端末の出力にインストールエラーやアップグレードエラーがないか確認するか、以下からリリースのアーカイブを手動でダウンロードします https://github.com/weaveworks/eksctl/

206

https://github.com/weaveworks/eksctl

https://brew.sh/


Amazon EKS ユーザーガイドeksctl のインストールまたはアップグレード

releases/download/0.19.0/eksctl_Darwin_amd64.tar.gz、eksctl を展開し、実行します。

Linux

curl を使用して Linux で eksctl をインストールまたはアップグレードするには

1. 以下のコマンドを使用して、eksctl の最新リリースをダウンロードして解凍します。

curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp

2. 抽出したバイナリを /usr/local/bin に移動します。

sudo mv /tmp/eksctl /usr/local/bin


eksctl version

Note

GitTag のバージョンは 0.19.0 以上であることが必要です。成功しない場合、端末の出力でインストールまたはアップグレードエラーがないか確認するか、ステップ 1 のアドレスを https://github.com/weaveworks/eksctl/releases/download/0.19.0/eksctl_$(uname -s)_amd64.tar.gz に置き換えて、ステップ1 ～ 3 をもう一度実行します。

Windows

Chocolatey を使用して Windows で eksctl をインストールまたはアップグレードするには


2. eksctl および aws-iam-authenticator をインストールまたはアップグレードします。

• 次のコマンドでバイナリをインストールします。

chocolatey install -y eksctl aws-iam-authenticator

• すでにインストールされている場合は、以下のコマンドでアップグレードします。

chocolatey upgrade -y eksctl aws-iam-authenticator


eksctl version

Note

GitTag のバージョンは 0.19.0 以上であることが必要です。そうでない場合は、端末の出力にインストールエラーやアップグレードエラーがないか確認するか、以下からリリースのアーカイブを手動でダウンロードします https://github.com/weaveworks/eksctl/releases/download/0.19.0/eksctl_Windows_amd64.zip、eksctl を展開し、実行します。

207







ゲストブックアプリケーションを起動する

このトピックでは、Amazon EKS クラスターをテストするためのサンプルのゲストブックアプリケーションを作成します。

Note

ゲストブックの例の設定の詳細については、Kubernetes のドキュメントの https://github.com/kubernetes/examples/blob/master/guestbook-go/README.md を参照してください。

ゲストブックアプリケーションを作成するには

1. Redis マスターレプリケーションコントローラーを作成します。

kubectl apply -f https://raw.githubusercontent.com/kubernetes/examples/master/guestbook-go/redis-master-controller.json

Note


出力:

replicationcontroller "redis-master" created

2. Redis マスターサービスを作成します。

kubectl apply -f https://raw.githubusercontent.com/kubernetes/examples/master/guestbook-go/redis-master-service.json

出力:

service "redis-master" created

3. Redis スレーブレプリケーションコントローラーを作成します。

kubectl apply -f https://raw.githubusercontent.com/kubernetes/examples/master/guestbook-go/redis-slave-controller.json

出力:

replicationcontroller "redis-slave" created

4. Redis スレーブサービスを作成します。

208

https://github.com/kubernetes/examples/blob/master/guestbook-go/README.md

https://github.com/kubernetes/examples/blob/master/guestbook-go/README.md


kubectl apply -f https://raw.githubusercontent.com/kubernetes/examples/master/guestbook-go/redis-slave-service.json

出力:

service "redis-slave" created

5. ゲストブックレプリケーションコントローラーを作成します。

kubectl apply -f https://raw.githubusercontent.com/kubernetes/examples/master/guestbook-go/guestbook-controller.json

出力:

replicationcontroller "guestbook" created

6. ゲストブックサービスを作成します。

kubectl apply -f https://raw.githubusercontent.com/kubernetes/examples/master/guestbook-go/guestbook-service.json

出力:

service "guestbook" created

7. クラスターのサービスをクエリし、guestbook サービスの [External IP] 列が自動入力されるまで待機します。

Note

IP アドレスが有効になるまで数分かかる場合があります。

kubectl get services -o wide

8. 外部 IP アドレスが有効になったら、ウェブブラウザでポート 3000 のそのアドレスにアクセスして、ゲストブックを表示します。たとえば、 http://a7a95c2b9e69711e7b1a3022fdcfdf2e-1985673473.region.elb.amazonaws.com:3000

Note

DNS が伝播され、ゲストブックが表示されるまで数分かかることがあります。

209


Important

ブラウザで外部 IP アドレスに接続できない場合は、会社のファイアウォールによって標準以外のポート (例: 3000) がブロックされていないことを確認してください。検証するには、ゲストネットワークに切り替えます。

ゲストブックアプリケーションをクリーンアップするには

ゲストブックアプリケーションを使用し終えたら、作成したリソースをクリーンアップする必要があります。

• 次のコマンドは、ゲストブックアプリケーションのすべてのサービスとレプリケーションコントローラーを削除します。

kubectl delete rc/redis-master rc/redis-slave rc/guestbook svc/redis-master svc/redis-slave svc/guestbook

Note


Amazon EKS クラスターの使用が終わったら、追加課金を発生させないように、クラスターとそのリソースを削除してください。詳細については、「クラスターの削除 (p. 45)」を参照してください。

210


Kubernetes メトリクスサーバーのインストール

Kubernetes メトリクスサーバーは、クラスター内のリソース使用状況データを集約し、デフォルトではAmazon EKS クラスターにデプロイされません。メトリクスサーバーは一般的に、他の Kubernetes アドオン (Horizontal Pod Autoscaler (p. 144) や Kubernetes Dashboard (p. 217) など) によって使用されます。詳細については、Kubernetes ドキュメントの「Resource metrics pipeline」を参照してください。このトピックでは、Kubernetes メトリクスサーバーを Amazon EKS クラスターにデプロイする方法について説明します。






出力


211

https://kubernetes.io/docs/tasks/debug-application-cluster/resource-metrics-pipeline/

Amazon EKS ユーザーガイド未加工メトリクスの表示

Prometheus を使用したプレーンメトリクスのコントロール

Kubernetes API サーバーは、モニタリングと分析に役立つ多数のメトリクスを公開します。これらのメトリクスは、/metrics HTTP API を参照するメトリクスエンドポイントを介して内部的に公開されます。他のエンドポイントと同様に、このエンドポイントは Amazon EKS コントロールプレーンに公開されます。このトピックでは、このエンドポイントを使用してクラスターの動作を表示および分析する方法をいくつか説明します。

未加工メトリクスの表示未加工メトリクスの出力を表示するには、--raw フラグを付けて kubectl を使用します。このコマンドを使用すると、任意の HTTP パスを渡して未加工のレスポンスを返すことができます。

kubectl get --raw /metrics

出力例:

...✓ HELP rest_client_requests_total Number of HTTP requests, partitioned by status code, method, and host.✓ TYPE rest_client_requests_total counterrest_client_requests_total{code="200",host="127.0.0.1:21362",method="POST"} 4994rest_client_requests_total{code="200",host="127.0.0.1:443",method="DELETE"} 1rest_client_requests_total{code="200",host="127.0.0.1:443",method="GET"} 1.326086e+06rest_client_requests_total{code="200",host="127.0.0.1:443",method="PUT"} 862173rest_client_requests_total{code="404",host="127.0.0.1:443",method="GET"} 2rest_client_requests_total{code="409",host="127.0.0.1:443",method="POST"} 3rest_client_requests_total{code="409",host="127.0.0.1:443",method="PUT"} 8✓ HELP ssh_tunnel_open_count Counter of ssh tunnel total open attempts✓ TYPE ssh_tunnel_open_count counterssh_tunnel_open_count 0✓ HELP ssh_tunnel_open_fail_count Counter of ssh tunnel failed open attempts✓ TYPE ssh_tunnel_open_fail_count counterssh_tunnel_open_fail_count 0

この未加工出力は、API サーバーが公開する内容をそのまま返します。これらのメトリクスは Prometheus形式で表されます。この形式により、API サーバーはさまざまなメトリクスを行に分けて公開できます。各行には、メトリクス名、タグ、および値が含まれます。

metric_name{"tag"="value"[,...]} value

このエンドポイントは特定のメトリクスを探している場合に役立ちますが、通常はこれらのメトリクスを経時分析する必要があります。分析するには、Prometheus をクラスターにデプロイします。Prometheusは、公開されているエンドポイントを整理しデータを集計するモニタリングおよび時系列データベースであり、結果をフィルタリング、グラフ化、およびクエリできるようにします。

212

https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md

https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md

https://prometheus.io/

Amazon EKS ユーザーガイドPrometheus のデプロイ

Prometheus のデプロイこのトピックは、Helm V3 を使用して Prometheus をクラスターにデプロイする際に役立ちます。既にHelm がインストールされている場合は、helm version コマンドでバージョンを確認できます。Helmは Kubernetes クラスターのパッケージマネージャーです。Helm の詳細およびインストール方法については、「Amazon EKS での Helm の使用 (p. 216)」を参照してください。

Amazon EKS クラスター用に Helm を設定した後、以下の手順でそれを使用して Prometheus をデプロイできます。

Helm を使用して Prometheus をデプロイするには

1. Prometheus 名前空間を作成します。

kubectl create namespace prometheus

2. Prometheus をデプロイします。

helm install prometheus stable/prometheus \ --namespace prometheus \ --set alertmanager.persistentVolume.storageClass="gp2",server.persistentVolume.storageClass="gp2"

3. prometheus 名前空間のすべてのポッドが READY 状態になっていることを確認します。

kubectl get pods -n prometheus

出力:

NAME READY STATUS RESTARTS AGEprometheus-alertmanager-59b4c8c744-r7bgp 1/2 Running 0 48sprometheus-kube-state-metrics-7cfd87cf99-jkz2f 1/1 Running 0 48sprometheus-node-exporter-jcjqz 1/1 Running 0 48sprometheus-node-exporter-jxv2h 1/1 Running 0 48sprometheus-node-exporter-vbdks 1/1 Running 0 48sprometheus-pushgateway-76c444b68c-82tnw 1/1 Running 0 48sprometheus-server-775957f748-mmht9 1/2 Running 0 48s

4. kubectl を使用して、Prometheus コンソールをローカルマシンにポート転送します。

kubectl --namespace=prometheus port-forward deploy/prometheus-server 9090

5. ウェブブラウザで localhost:9090 にアクセスして、Prometheus コンソールを表示します。6. [- insert metric at cursor (カーソルの位置のメトリクスを挿入)] メニューからメトリクスを選択し、[実

行] を選択します。[グラフ] タブを選択して、一定期間のメトリクスを表示します。次の図では、一定期間の container_memory_usage_bytes を示します。

213

localhost:9090


7. 上部のナビゲーションバーから、[ステータス]、[ターゲット] の順に選択します。

214


サービス検出を使用して Prometheus に接続されているすべての Kubernetes エンドポイントが表示されます。

215


Amazon EKS での Helm の使用Kubernetes 用の Helm パッケージマネージャーを使用すると、Kubernetes クラスターにアプリケーションをインストールし、管理できます。詳細については、Helm のドキュメントを参照してください。このトピックは、Helm バイナリをインストールして実行する際に役立ちます。これにより、ローカルシステムで Helm CLI を使用してチャートをインストールおよび管理することができます。

Important

Amazon EKS クラスターに Helm チャートをインストールするには、あらかじめ Amazon EKSで動作するように kubectl を設定しておく必要があります。この設定をまだ行っていない場合は、続行する前に aws-iam-authenticator のインストール (p. 196)および kubeconfig をAmazon EKS 用に作成します。 (p. 199)を参照してください。次のコマンドがクラスターに対して成功した場合は、正しく設定されています。

kubectl get svc

ローカルシステムに Helm バイナリをインストールするには

1. クライアントオペレーティングシステムに適したコマンドを実行します。

• macOS で Homebrew を使用している場合は、次のコマンドを使用してバイナリをインストールします。

brew install helm

• Windows で Chocolatey を使用している場合は、次のコマンドを使用してバイナリをインストールします。

choco install kubernetes-helm

• Linux を使用している場合は、次のコマンドを使用してバイナリをインストールします。

curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 > get_helm.shchmod 700 get_helm.sh./get_helm.sh

2. PATH で新しいバイナリを取得するため、現在のターミナルウィンドウを閉じて新しいターミナルウィンドウを開きます。

3. 次のコマンドを使用して、Helm が実行されていることを確認します。

helm help

4. この時点で、任意の Helm コマンド (helm install chart_name など) を実行して、クラスター内の Helm チャートをインストール、変更、削除、またはクエリすることができます。Helm を初めて使用する場合で、インストールするチャートがないときは、次の操作を実行できます。

• サンプルチャートをインストールして試します。Helm Quickstart Guide の「Install an ExampleChart」を参照してください。

• eks-chart GitHub リポジトリ、または Helm Hub から Amazon EKS チャートをインストールします。

216

https://docs.helm.sh/

https://brew.sh/

https://chocolatey.org/

https://helm.sh/docs/intro/quickstart/

https://helm.sh/docs/intro/quickstart#install-an-example-chart

https://helm.sh/docs/intro/quickstart#install-an-example-chart

https://github.com/aws/eks-charts

https://hub.helm.sh/charts?q=eks


チュートリアル: Kubernetes ダッシュボード (ウェブ UI) のデプロイ

このチュートリアルでは、Kubernetes ダッシュボードを、CPU およびメモリメトリクスを備えたAmazon EKS クラスターにデプロイする手順について説明します。クラスターを表示および管理するダッシュボードに安全に接続できる Amazon EKS 管理者サービスアカウントの作成にも役立ちます。

前提条件このチュートリアルでは、以下のことを前提としています。

• 「Amazon EKS の開始方法 (p. 3)」のステップに従って、Amazon EKS クラスターを作成しました。• コントロールプレーン Elastic Network Interface およびワーカーノードのセキュリティグループ

は、Amazon EKS セキュリティグループの考慮事項 (p. 164) の推奨設定に従います。• Amazon EKS クラスターと通信するよう設定されている (p. 16)kubectl クライアントを使用していま

す。

ステップ 1: Kubernetes メトリクスサーバーをデプロイする

Kubernetes メトリクスサーバーは、クラスター内のリソース使用状況データを集約し、デフォルトではAmazon EKS クラスターにデプロイされません。Kubernetes ダッシュボードでは、メトリクスサーバーを使用して、時間の経過に伴う CPU やメモリの使用状況など、クラスターのメトリクスを収集します。

217


Amazon EKS ユーザーガイドステップ 2: ダッシュボードのデプロイ






出力


ステップ 2: ダッシュボードのデプロイ次のコマンドを使用して Kubernetes ダッシュボードをデプロイします。

kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-beta8/aio/deploy/recommended.yaml

出力:

namespace/kubernetes-dashboard createdserviceaccount/kubernetes-dashboard createdservice/kubernetes-dashboard createdsecret/kubernetes-dashboard-certs createdsecret/kubernetes-dashboard-csrf createdsecret/kubernetes-dashboard-key-holder createdconfigmap/kubernetes-dashboard-settings createdrole.rbac.authorization.k8s.io/kubernetes-dashboard createdclusterrole.rbac.authorization.k8s.io/kubernetes-dashboard createdrolebinding.rbac.authorization.k8s.io/kubernetes-dashboard createdclusterrolebinding.rbac.authorization.k8s.io/kubernetes-dashboard createddeployment.apps/kubernetes-dashboard createdservice/dashboard-metrics-scraper createddeployment.apps/dashboard-metrics-scraper created

ステップ 3: eks-admin サービスアカウントおよびクラスターロールバインディングの作成

デフォルトでは、Kubernetes ダッシュボードユーザーのアクセス許可は制限されています。このセクションでは、管理者レベルのアクセス権限を使用してダッシュボードに安全に接続するために使用できる、eks-admin サービスアカウントおよびクラスターロールバインディングを作成します。詳細については、Kubernetes ドキュメントのサービスアカウントの管理を参照してください。

218

https://kubernetes.io/docs/admin/service-accounts-admin/

Amazon EKS ユーザーガイドステップ 4: ダッシュボードに接続する

eks-admin サービスアカウントおよびクラスターロールバインディングを作成するには

Important

この手順で作成された、この例のサービスアカウントにはクラスターの完全な cluster-admin(スーパーユーザー) 権限があります。詳細については、Kubernetes ドキュメントの RBAC 認証の使用を参照してください。

1. 以下のテキストを使用して、eks-admin-service-account.yaml という名前のファイルを作成します。このマニフェストでは、サービスアカウントと、eks-admin と呼ばれるクラスターロールバインディングを定義します。

apiVersion: v1kind: ServiceAccountmetadata: name: eks-admin namespace: kube-system---apiVersion: rbac.authorization.k8s.io/v1beta1kind: ClusterRoleBindingmetadata: name: eks-adminroleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-adminsubjects:- kind: ServiceAccount name: eks-admin namespace: kube-system

2. サービスアカウントおよびクラスターロールバインディングをクラスターに適用する。

kubectl apply -f eks-admin-service-account.yaml

出力:

serviceaccount "eks-admin" createdclusterrolebinding.rbac.authorization.k8s.io "eks-admin" created

ステップ 4: ダッシュボードに接続するこれで、Kubernetes ダッシュボードがクラスターにデプロイされました。クラスターを表示および管理するのに使用できる管理者サービスアカウントがあるため、このサービスアカウントを使用してダッシュボードに接続できます。

Kubernetes ダッシュボードに接続するには

1. eks-admin サービスアカウントの認証トークンを取得します。出力から<authentication_token>の値をコピーします。このトークンを使用してダッシュボードに接続します。

kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep eks-admin | awk '{print $1}')

出力:

219



Amazon EKS ユーザーガイドステップ 4: ダッシュボードに接続する

Name: eks-admin-token-b5zv4Namespace: kube-systemLabels: <none>Annotations: kubernetes.io/service-account.name=eks-admin kubernetes.io/service-account.uid=bcfe66ac-39be-11e8-97e8-026dce96b6e8

Type: kubernetes.io/service-account-token

Data====ca.crt: 1025 bytesnamespace: 11 bytestoken: <authentication_token>

2. kubectl proxy を開始します。

kubectl proxy

3. ウェブブラウザで以下のリンクを開いて、ダッシュボードエンドポイントにアクセスします。http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/#!/login

4. [トークン] を選択して、前のコマンドからの<authentication_token>出力を [トークン] フィールドに貼り付け、[サインイン] を選択します。

Note

CPU とメモリメトリクスがダッシュボードに表示されるまでに数分かかることがあります。

220

http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/#!/login



Amazon EKS ユーザーガイドステップ 5: 次のステップ

ステップ 5: 次のステップKubernetes ダッシュボードに接続した後、eks-admin サービスアカウントを使用してクラスターを表示および管理できます。ダッシュボードの使用の詳細については、GitHub のプロジェクトドキュメントを参照してください。

221


Amazon EKS ユーザーガイドシナリオ

AWS App Meshこのトピックは、で実行されている実際のサービスで AWS App Mesh を使用する場合に役立ちます。

シナリオApp Mesh で使用する方法を説明するために、次の特性を持つアプリケーションがあると仮定します。

• serviceA と serviceB という名前の 2 つのサービスを含めます。• どちらのサービスも、apps.local という名前の名前空間に登録されます。• ServiceA は、HTTP/2、ポート 80 を介して serviceB と通信します。• すでに serviceB のバージョン 2 をデプロイし、apps.local 名前空間に serviceBv2 という名前で

登録しました。

次の要件があります。

• トラフィックの 100% を serviceA から送信する前に、serviceBv2 にバグがないことを確認するため、トラフィックの 75% を serviceA から serviceB へ、25% を serviceBv2 へ送信する。

• トラフィックの重み付けを簡単に調整して、信頼性が証明されたら、トラフィックの 100% がserviceBv2 へ転送されるようにする。すべてのトラフィックが serviceBv2 に送信されたら、serviceB を非推奨にする。

• 上記の要件を満たすために、実際のサービスの既存のアプリケーションコードまたはサービス検出登録を変更する必要はありません。

要件を満たすために、仮想サービス、仮想ノード、仮想ルーター、およびルートを含む App Mesh サービスメッシュを作成することにしました。メッシュを実装した後、サービスのを更新し、Envoy プロキシを使用します。更新されると、サービスは相互に直接ではなく、Envoy プロキシを介して相互に通信します。

前提条件App Mesh は、DNS、AWS Cloud Map、またはその両方に登録された Linux サービスをサポートします。この入門ガイドを使用するには、DNS に登録されている既存のサービスが 3 つあることをお勧めします。サービスが存在しない場合でもサービスメッシュとそのリソースを作成できますが、実際のサービスをデプロイするまでメッシュを使用することはできません。

残りの手順では、実際のサービスが serviceA、serviceB、serviceBv2 という名前で、すべてのサービスが apps.local という名前の名前空間を通じて検出可能であることを前提としています。

ステップ 1: メッシュと仮想サービスを作成するサービスメッシュは、サービス間のネットワークトラフィックの論理的な境界であり、サービスはその中に存在します。詳細については、「サービスメッシュ) を参照してください。仮想サービスは、実際のサービスを抽象化したものです。詳細については、「仮想サービス) を参照してください。

222

https://docs.aws.amazon.com/app-mesh/latest/userguide/meshes.html

https://docs.aws.amazon.com/app-mesh/latest/userguide/virtual_services.html

Amazon EKS ユーザーガイドステップ 2: 仮想ノードの作成

次のリソースを作成します。

• シナリオ内のすべてのサービスが apps.local 名前空間に登録されているため、apps という名前のメッシュ。

• serviceb.apps.local という名前の仮想サービス。仮想サービスは、その名前で検出可能なサービスを表しており、別の名前を参照するようにコードを変更したくないためです。servicea.apps.local という名前の仮想サービスが、後の手順で追加されます。

AWS マネジメントコンソールまたは AWS CLI バージョン 1.18.16 以降を使用して、次の手順を完了できます。AWS CLI を使用している場合は、aws --version コマンドを使用して、インストールされているAWS CLI のバージョンを確認します。バージョン 1.18.16 以降をインストールしていない場合は、AWSCLI をインストールまたは更新する必要があります。使用するツールのタブを選択します。


1. https://console.aws.amazon.com/appmesh/get-startedで、App Mesh コンソールの初回実行ウィザードを開きます。

2. [メッシュ名] に「apps」と入力します。3. [仮想サービス名] に「serviceb.apps.local」と入力します。4. 続行するには、[Next] を選択します。

AWS CLI

1. create-mesh コマンドを使用してメッシュを作成します。

aws appmesh create-mesh --mesh-name apps

2. create-virtual-service コマンドを使用して仮想サービスを作成します。

aws appmesh create-virtual-service --mesh-name apps --virtual-service-name serviceb.apps.local --spec {}

ステップ 2: 仮想ノードの作成仮想ノードは、実際のサービスの論理ポインタとして機能します。詳細については、「仮想ノード) を参照してください。

仮想ノードの 1 つが serviceB という名前の実際のサービスを表すため、serviceB という名前の仮想ノードを作成します。仮想ノードが表す実際のサービスは、serviceb.apps.local というホスト名を使用して DNS から検出可能です。または、AWS Cloud Map を使用して実際のサービスを検出することもできます。仮想ノードは、ポート 80 で HTTP/2 プロトコルを使用してトラフィックをリッスンします。ヘルスチェックと同様に、その他のプロトコルもサポートされます。serviceA および serviceBv2 の仮想ノードは、後のステップで作成します。


1. [仮想ノード名] に「serviceB」と入力します。2. [サービス検出方法] で [DNS] を選択し、[DNS ホスト名] に「serviceb.apps.local」と入力し

ます。3. [リスナー] で、[ポート] に「80」に入力し、[プロトコル] で [http2] を選択します。4. 続行するには、[Next] を選択します。

223



https://console.aws.amazon.com/appmesh/get-started

https://docs.aws.amazon.com/cli/latest/reference/appmesh/create-mesh.html

https://docs.aws.amazon.com/cli/latest/reference/appmesh/create-virtual-service.html

https://docs.aws.amazon.com/app-mesh/latest/userguide/virtual_nodes.html

Amazon EKS ユーザーガイドステップ 3: 仮想ルーターとルートを作成する

AWS CLI

1. 次の内容で、create-virtual-node-serviceb.json というファイルを作成します。

{ "meshName": "apps", "spec": { "listeners": [ { "portMapping": { "port": 80, "protocol": "http2" } } ], "serviceDiscovery": { "dns": { "hostname": "serviceB.apps.local" } } }, "virtualNodeName": "serviceB"}

2. JSON ファイルを入力として使用して、create-virtual-node コマンドで仮想ノードを作成します。

aws appmesh create-virtual-node --cli-input-json file://create-virtual-node-serviceb.json

ステップ 3: 仮想ルーターとルートを作成する仮想ルーターは、メッシュ内の 1 つ以上の仮想サービスのトラフィックをルーティングします。詳細については、の「仮想ルーター」および「ルート」を参照してください。

次のリソースを作成します。

• serviceB という仮想ルーター。serviceB.apps.local 仮想サービスは、他のサービスとのアウトバウンド通信を開始しないためです。前に作成した仮想サービスは、実際の serviceb.apps.localサービスの抽象化であることに注意してください。仮想サービスは、仮想ルーターにトラフィックを送信します。仮想ルーターは、ポート 80 で HTTP/2 プロトコルを使用してトラフィックをリッスンします。その他のプロトコルもサポートされています。

• serviceB という名前のルート。このルートはトラフィックの 100% を serviceB 仮想ノードにルーティングします。serviceBv2 仮想ノードを追加したら、後の手順で重みを変更します。このガイドでは説明しませんが、ルートにフィルタ条件を追加したり、通信の問題が発生したときに Envoy プロキシが仮想ノードへのトラフィックの送信を複数回試行する再試行ポリシーを追加したりできます。


1. [仮想ルーター名] に「serviceB」と入力します。2. [リスナー] で、[ポート] に [80] を指定し、[プロトコル] に[http2] を選択します。3. [ルート名] に「serviceB」と入力します。4. [ルートタイプ] で、[http2] を選択します。5. [仮想ノード名] で [serviceB] を選択し、[重み] に「100」と入力します。6. 続行するには、[Next] を選択します。

224

https://docs.aws.amazon.com/cli/latest/reference/appmesh/create-virtual-node.html

https://docs.aws.amazon.com/app-mesh/latest/userguide/virtual_routers.html

https://docs.aws.amazon.com/app-mesh/latest/userguide/routes.html

Amazon EKS ユーザーガイドステップ 4: 確認と作成

AWS CLI

1. 仮想ルーターを作成します。

a. 次の内容で、create-virtual-router.json というファイルを作成します。

{ "meshName": "apps", "spec": { "listeners": [ { "portMapping": { "port": 80, "protocol": "http2" } } ] }, "virtualRouterName": "serviceB"}

b. JSON ファイルを入力として使用し、create-virtual-router コマンドで仮想ルーターを作成します。

aws appmesh create-virtual-router --cli-input-json file://create-virtual-router.json

2. ルートを作成します。

a. 次の内容で、create-route.json というファイルを作成します。

{ "meshName" : "apps", "routeName" : "serviceB", "spec" : { "httpRoute" : { "action" : { "weightedTargets" : [ { "virtualNode" : "serviceB", "weight" : 100 } ] }, "match" : { "prefix" : "/" } } }, "virtualRouterName" : "serviceB"}

b. JSON ファイルを入力として使用し、create-route コマンドを使用でルートを作成します。

aws appmesh create-route --cli-input-json file://create-route.json

ステップ 4: 確認と作成前の手順と照らし合わせて設定を確認します。

225

https://docs.aws.amazon.com/cli/latest/reference/appmesh/create-virtual-router.html

https://docs.aws.amazon.com/cli/latest/reference/appmesh/create-route.html

Amazon EKS ユーザーガイドステップ 5: 追加のリソースを作成する


いずれかのセクションに変更を加える必要がある場合は、[Edit] を選択します。設定が適切であることを確認したら、[Create mesh service] を選択します。

AWS CLI

describe-mesh コマンドで作成したメッシュの設定を確認します。

aws appmesh describe-mesh --mesh-name apps

describe-virtual-service コマンドで作成した仮想サービスの設定を確認します。

aws appmesh describe-virtual-service --mesh-name apps --virtual-service-name serviceb.apps.local

describe-virtual-node コマンドで作成した仮想ノードの設定を確認します。

aws appmesh describe-virtual-node --mesh-name apps --virtual-node-name serviceB

describe-virtual-router コマンドで作成した仮想ルーターの設定を確認します。

aws appmesh describe-virtual-router --mesh-name apps --virtual-router-name serviceB

describe-route コマンドで作成したルートの設定を確認します。

aws appmesh describe-route --mesh-name apps \ --virtual-router-name serviceB --route-name serviceB

ステップ 5: 追加のリソースを作成するこのシナリオを完了するには、次のことを行う必要があります。

• serviceBv2 という名前の仮想ノードと、serviceA という名前の別の仮想ノードを作成します。両方の仮想ノードは、HTTP/2 ポート 80 経由でリクエストをリッスンします。serviceA 仮想ノードの場合は、serviceb.apps.local のバックエンドを設定します。serviceA 仮想ノードからのすべてのアウトバウンドトラフィックが、serviceb.apps.local という名前の仮想サービスに送信されるためです。このガイドでは説明しませんが、仮想ノードのアクセスログを書き込むファイルパスを指定することもできます。

• servicea.apps.local という名前の追加の仮想サービスを 1 つ作成します。これにより、すべてのトラフィックが serviceA 仮想ノードに直接送信されます。

• 前の手順で作成した serviceB ルートを更新して、トラフィックの 75% を serviceB 仮想ノードに送信し、25% を serviceBv2 仮想ノードに送信します。時間の経過とともに、serviceBv2 が 100%のトラフィックを受信するまで、継続して重みを変更することができます。すべてのトラフィックがserviceBv2 に送信されたら、serviceB 仮想ノードと実際のサービスを非推奨にできます。重みを変更しても、serviceb.apps.local 仮想サービス名および実際のサービス名は変更されないため、コードを変更する必要はありません。serviceb.apps.local 仮想サービスは仮想ルーターにトラフィックを送信し、仮想ルーターはトラフィックを仮想ノードにルーティングすることに注意してください。仮想ノードのサービス検出名は、いつでも変更できます。


1. 左のナビゲーションペインで [メッシュ] を選択します。

226

https://docs.aws.amazon.com/cli/latest/reference/appmesh/describe-mesh.html

https://docs.aws.amazon.com/cli/latest/reference/appmesh/describe-virtual-service.html

https://docs.aws.amazon.com/cli/latest/reference/appmesh/describe-virtual-node.html

https://docs.aws.amazon.com/cli/latest/reference/appmesh/describe-virtual-router.html

https://docs.aws.amazon.com/cli/latest/reference/appmesh/describe-route.html


2. 前の手順で作成した apps メッシュを選択します。3. 左側のナビゲーションペインで、[仮想ノード] を選択します。4. Create virtual node を選択します。5. [仮想ノード名] に「serviceBv2」と入力し、[Service discovery method (サービス検出方法)] で

[DNS] を選択して、[DNS ホスト名] に「servicebv2.apps.local」と入力します。6. [リスナー] で、[ポート] に「80」と入力し、[プロトコル] で [http2] を選択します。7. Create virtual node を選択します。8. もう一度 [Create virtual node] を選択し、[仮想ノード名] に「serviceA」と入力します。

[Service discovery method (サービス検出方法)] で [DNS] を選択し、[DNS ホスト名] に「servicea.apps.local」と入力します。

9. [Additional configuration (追加設定)] を展開します。10. 選択 Add backend.serviceb.apps.local と入力します。11. [ポート] に「80」を入力し、[プロトコル] で [http2] を選択して、[Create virtual node] を選択し

ます。12. 左側のナビゲーションペインで [仮想ルーター] を選択し、リストから [serviceB] 仮想ルーター

を選択します。13. [ルート] で、前のステップで作成した ServiceB という名前のルートを選択し、[Edit] を選択し

ます。14. [仮想ノード名] で、[serviceB] の [重み] の値を [75] に変更します。15. [Add target] を選択し、ドロップダウンリストから [serviceBv2] を選択して、[重み] の値を [25]

に設定します。16. Save を選択します。17. 左側のナビゲーションペインで、[仮想サービス] を選択し、[Create virtual service] を選択しま

す。18. [仮想サービス名] に「servicea.apps.local」と入力し、[プロバイダー] で [Virtual node]

を選択します。次に、[仮想ノード] で [serviceA] を選択し、[Create virtual service.] を選択します。

AWS CLI

1. serviceBv2 仮想ノードを作成します。

a. 次の内容で、create-virtual-node-servicebv2.json というファイルを作成します。

{ "meshName": "apps", "spec": { "listeners": [ { "portMapping": { "port": 80, "protocol": "http2" } } ], "serviceDiscovery": { "dns": { "hostname": "serviceBv2.apps.local" } } }, "virtualNodeName": "serviceBv2"}

b. 仮想ノードを作成します。

227


aws appmesh create-virtual-node --cli-input-json file://create-virtual-node-servicebv2.json

2. serviceA 仮想ノードを作成します。

a. 次の内容で、create-virtual-node-servicea.json というファイルを作成します。

{ "meshName" : "apps", "spec" : { "backends" : [ { "virtualService" : { "virtualServiceName" : "serviceb.apps.local" } } ], "listeners" : [ { "portMapping" : { "port" : 80, "protocol" : "http2" } } ], "serviceDiscovery" : { "dns" : { "hostname" : "servicea.apps.local" } } }, "virtualNodeName" : "serviceA"}

b. 仮想ノードを作成します。

aws appmesh create-virtual-node --cli-input-json file://create-virtual-node-servicea.json

3. 前の手順で作成した serviceb.apps.local 仮想サービスを更新して、そのトラフィックをserviceB 仮想ルーターに送信します。仮想サービスが最初に作成された時点では、serviceB仮想ルーターがまだ作成されていないため、トラフィックはどこにも送信されませんでした。

a. 次の内容で、update-virtual-service.json というファイルを作成します。

{ "meshName" : "apps", "spec" : { "provider" : { "virtualRouter" : { "virtualRouterName" : "serviceB" } } }, "virtualServiceName" : "serviceb.apps.local"}

b. update-virtual-service コマンドを使用して、仮想サービスを更新します。

228

https://docs.aws.amazon.com/cli/latest/reference/appmesh/update-virtual-service.html


aws appmesh update-virtual-service --cli-input-json file://update-virtual-service.json

4. 前のステップで作成した serviceB ルートを更新します。

a. 次の内容で、update-route.json というファイルを作成します。

{ "meshName" : "apps", "routeName" : "serviceB", "spec" : { "http2Route" : { "action" : { "weightedTargets" : [ { "virtualNode" : "serviceB", "weight" : 75 }, { "virtualNode" : "serviceBv2", "weight" : 25 } ] }, "match" : { "prefix" : "/" } } }, "virtualRouterName" : "serviceB"}

b. update-route コマンドを使用してルートを更新します。

aws appmesh update-route --cli-input-json file://update-route.json

5. serviceA 仮想サービスを作成します。

a. 次の内容で、create-virtual-servicea.json というファイルを作成します。

{ "meshName" : "apps", "spec" : { "provider" : { "virtualNode" : { "virtualNodeName" : "serviceA" } } }, "virtualServiceName" : "servicea.apps.local"}

b. 仮想サービスを作成します。

aws appmesh create-virtual-service --cli-input-json file://create-virtual-servicea.json

メッシュの概要

229

https://docs.aws.amazon.com/cli/latest/reference/appmesh/update-route.html

Amazon EKS ユーザーガイドステップ 6: サービスを更新する

サービスメッシュを作成する前に、servicea.apps.local、serviceb.apps.local、およびservicebv2.apps.local という 3 つの実際のサービスがありました。実際のサービスに加えて、実際のサービスを表す次のリソースを含むサービスメッシュが作成されました。

• 2 つの仮想サービス。プロキシは、仮想ルーターを経由して、servicea.apps.local 仮想サービスからのすべてのトラフィックを serviceb.apps.local 仮想サービスに送信します。

• serviceA、serviceB、および serviceBv2 という 3 つの仮想ノード。Envoy プロキシは、仮想ノードに対して設定されたサービス検出情報を使用して、実際のサービスの IP アドレスを検索します。

• Envoy プロキシがインバウンドトラフィックの 75% を serviceB 仮想ノードに、25% を serviceBv2仮想ノードにルーティングするように指定する 1 つのルートを持つ仮想ルーター。

ステップ 6: サービスを更新するメッシュを作成したら、次のタスクを完了する必要があります。

• 各でデプロイする Envoy プロキシが、1 つ以上の仮想ノードの設定を読み取ることを許可します。プロキシの認証方法の詳細については、「プロキシの認証」を参照してください。

• 既存の各を更新して、Envoy プロキシを使用します。

230

https://docs.aws.amazon.com/app-mesh/latest/userguide/proxy-authorization.html

Amazon EKS ユーザーガイドPrerequisites

Tutorial: Configure App Meshintegration with Kubernetes

When you integrate AWS App Mesh with Kubernetes, you manage App Mesh resources, such as virtualservices and virtual nodes, through Kubernetes. You also automatically add the App Mesh sidecarcontainer images to Kubernetes pod specifications. This tutorial guides you through the installation of thefollowing open source components that enable this integration:

• App Mesh controller for Kubernetes – The controller is accompanied by the deployment of threeKubernetes custom resource definitions: mesh, virtual service, and virtual node. The controllerwatches for creation, modification, and deletion of the custom resources and makes changes to thecorresponding App Mesh mesh, virtual service (including virtual router and route), andvirtual node resources through the App Mesh API. To learn more or contribute to the controller, seethe GitHub project.

• App Mesh sidecar injector for Kubernetes – The injector installs as a webhook and injects the followingcontainers into Kubernetes pods that are running in specific, labeled namespaces. To learn more orcontribute, see the GitHub project.• App Mesh Envoy proxy –Envoy uses the configuration defined in the App Mesh control plane to

determine where to send your application traffic..• App Mesh proxy route manager – The route manager sets up a pod’s network namespace withiptables rules that route ingress and egress traffic through Envoy.

The features discussed in this topic are available as an open-source beta. This means that these featuresare well tested. Support for the features will not be dropped, though details may change. If the schemaor schematics of a feature changes, instructions for migrating to the next version will be provided. Thismigration may require deleting, editing, and re-creating Kubernetes API objects.

Prerequisites• An existing Kubernetes cluster running version 1.13 or later. If you don't have an existing cluster, you can

deploy one using the Getting Started with Amazon EKS guide.• The AWS CLI version 1.18.16 or later installed. To install or upgrade the, see Installing the AWS CLI.• A kubectl client that is configured to communicate with your Kubernetes cluster. If you're using Amazon

Elastic Kubernetes Service, you can use the instructions for installing kubectl and configuring akubeconfig file.

• Helm version 3.0 or later installed. If you don't have Helm installed, you can install it by completing theinstructions in Using Helm with Amazon EKS.

Step 1: Install the integration componentsInstall the integration components one time to each cluster that hosts pods that you want to use with AppMesh

To install the integration components

1. Add the eks-charts repository to Helm.

231

https://docs.aws.amazon.com/app-mesh/latest/userguide/meshes.html




https://docs.aws.amazon.com/app-mesh/latest/userguide/irtual_nodes.html

https://github.com/aws/aws-app-mesh-controller-for-k8s

https://github.com/aws/aws-app-mesh-inject

https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html


https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html

https://docs.aws.amazon.com/eks/latest/userguide/create-kubeconfig.html

https://docs.aws.amazon.com/eks/latest/userguide/helm.html

Amazon EKS ユーザーガイドStep 1: Install the integration components

helm repo add eks https://aws.github.io/eks-charts

2. Install the App Mesh Kubernetes custom resource definitions (CRD).

kubectl apply -k https://github.com/aws/eks-charts/stable/appmesh-controller/crds?ref=master

3. Create a Kubernetes namespace for the controller.

kubectl create ns appmesh-system

4. Set the following variables. Replace cluster-name and region-code with the values for yourexisting cluster.

export CLUSTER_NAME=cluster-nameexport AWS_REGION=region-code

5. Create an OpenID Connect (OIDC) identity provider for your cluster. If you don't have eksctlinstalled, you can install it with the instructions in Installing or Upgrading eksctl. If you'd prefer tocreate the provider using the console, see Enabling IAM Roles for Service Accounts on your Cluster.

eksctl utils associate-iam-oidc-provider \ --region=$AWS_REGION \ --cluster $CLUSTER_NAME \ --approve

6. Create an IAM role, attach the AWSAppMeshFullAccess and AWSCloudMapFullAccess AWSmanaged policies to it, and bind it to the appmesh-controller Kubernetes service account. The roleenables the controller to add, remove, and change App Mesh resources.

Note

The command creates an AWS IAM role with an auto-generated name. You are not able tospecify the IAM role name that is created.

eksctl create iamserviceaccount \ --cluster $CLUSTER_NAME \ --namespace appmesh-system \ --name appmesh-controller \ --attach-policy-arn arn:aws:iam::aws:policy/AWSCloudMapFullAccess,arn:aws:iam::aws:policy/AWSAppMeshFullAccess \ --override-existing-serviceaccounts \ --approve

If you prefer to create the service account using the AWS Management Console or AWS CLI, seeCreating an IAM Role and Policy for your Service Account. If you use the AWS Management Consoleor AWS CLI to create the account, you also need to map the role to a Kubernetes service account. Formore information, see Specifying an IAM Role for your Service Account.

7. Deploy the App Mesh controller. For a list of all configuration options, see Configuration on GitHub.

helm upgrade -i appmesh-controller eks/appmesh-controller \ --namespace appmesh-system \ --set region=$AWS_REGION \ --set serviceAccount.create=false \ --set serviceAccount.name=appmesh-controller

8. Confirm that the controller version is v0.3.0 or later. You can view the change log on GitHub.

232

https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html#installing-eksctl

https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html

https://console.aws.amazon.com/iam/home?#policies/arn:aws:iam::aws:policy/AWSAppMeshFullAccess$jsonEditor

https://console.aws.amazon.com/iam/home?#policies/arn:aws:iam::aws:policy/AWSCloudMapFullAccess$jsonEditor

https://docs.aws.amazon.com/eks/latest/userguide/create-service-account-iam-policy-and-role.html#create-service-account-iam-role

https://docs.aws.amazon.com/eks/latest/userguide/specify-service-account-role.html

https://github.com/aws/eks-charts/blob/master/stable/appmesh-controller/README.md#configuration

https://github.com/aws/aws-app-mesh-controller-for-k8s/blob/master/CHANGELOG.md

Amazon EKS ユーザーガイドStep 2: Deploy App Mesh resources

kubectl get deployment -n appmesh-system appmesh-controller -o json | jq -r ".spec.template.spec.containers[].image" | cut -f2 -d ':'

9. Install the App Mesh sidecar injector and create a mesh with the name my-mesh. For a list of allconfiguration options, see Configuration on GitHub.

helm upgrade -i appmesh-inject eks/appmesh-inject \ --namespace appmesh-system \ --set mesh.name=my-mesh \ --set mesh.create=true

Note

If you view the log for the running container, you may see a line that includes the followingtext, which can be safely ignored.

Neither --kubeconfig nor --master was specified. Using the inClusterConfig. This might not work.

Step 2: Deploy App Mesh resourcesWhen you deploy an application in Kubernetes, you also create the Kubernetes custom resources so thatthe controller can create the corresponding App Mesh resources.

To deploy App Mesh resources

1. Create a Kubernetes namespace to deploy App Mesh resources to.

kubectl create ns my-app-1

2. Create an App Mesh virtual node.

a. Create a file named virtual-node.yaml with the following contents. The file will be usedto create an App Mesh virtual node named my-service-a in the my-app-1 namespace.The virtual node represents a Kubernetes service that is created in a later step. Thevirtual node will communicate to a backend virtual service named my-service-b.my-app-1.svc.cluster.local, but it is not created in this tutorial.

apiVersion: appmesh.k8s.aws/v1beta1kind: VirtualNodemetadata: name: my-service-a namespace: my-app-1spec: meshName: my-mesh listeners: - portMapping: port: 80 protocol: http serviceDiscovery: dns: hostName: my-service-a.my-app-1.svc.cluster.local backends: - virtualService: virtualServiceName: my-service-b.my-app-1.svc.cluster.local

233

https://github.com/aws/eks-charts/tree/master/stable/appmesh-inject#configuration


Virtual nodes have capabilities, such as end-to-end encryption and health checks, that aren'tcovered in this tutorial. For more information, see Virtual nodes. To see all available settings for avirtual node that you can set in the preceding spec, run the following command.

aws appmesh create-virtual-node --generate-cli-skeleton yaml-input

b. Deploy the virtual node.

kubectl apply -f virtual-node.yaml

c. View all of the resources in the my-app-1 namespace.

kubectl -n my-app-1 get all

Output

NAME AGEmesh.appmesh.k8s.aws/my-mesh 17m

NAME AGEvirtualnode.appmesh.k8s.aws/my-service-a 16m

This output shows the mesh and the virtual node that exist in the my-app-1 namespace.d. Confirm that the virtual node was created in App Mesh.

Note

Even though the name of the virtual node created in Kubernetes is my-service-a,the name of the virtual node created in App Mesh is my-service-a-my-app-1. Thecontroller appends the Kubernetes namespace name to the App Mesh virtual node namewhen it creates the App Mesh resource. The namespace name is added because inKubernetes you can create virtual nodes with the same name in different namespaces,but in App Mesh a virtual node name must be unique within a mesh.

aws appmesh describe-virtual-node --mesh-name my-mesh --virtual-node-name my-service-a-my-app-1

Output

{ "virtualNode": { "meshName": "my-mesh", "metadata": { "arn": "arn:aws:appmesh:us-west-2:111122223333:mesh/my-mesh/virtualNode/my-service-a-my-app-1", "createdAt": "2020-03-20T08:18:19.510000-05:00", "lastUpdatedAt": "2020-03-20T08:18:19.510000-05:00", "meshOwner": "111122223333", "resourceOwner": "111122223333", "uid": "111a11b1-c11d-1e1f-gh1i-j11k1l111m711", "version": 1 }, "spec": { "backends": [ { "virtualService": {

234

https://docs.aws.amazon.com/app-mesh/latest/userguide/virtual_nodes.html


"virtualServiceName": "my-service-b.my-app-1.svc.cluster.local" } } ], "listeners": [ { "portMapping": { "port": 80, "protocol": "http" } } ], "serviceDiscovery": { "dns": { "hostname": "my-service-a.my-app-1.svc.cluster.local" } } }, "status": { "status": "ACTIVE" }, "virtualNodeName": "my-service-a-my-app-1" }}

Note the value of arn in the preceding output. You will use it in a later step.3. Create an App Mesh virtual service, virtual router, and route.

a. Create a file named virtual-service.yaml with the following contents. The file will be usedto create a virtual service that uses a virtual router provider to route traffic to the virtual nodenamed my-service-a that was created in the previous step. The value for name is the fullyqualified domain name (FQDN) of the actual Kubernetes service that this virtual service abstracts.The service is created in the section called “Step 3: Create or update services” (p. 239). Thecontroller will create the App Mesh virtual service, virtual router, and route resources. You canspecify many more capabilities for your routes and use protocols other than http. For moreinformation, see Virtual services, Virtual router, and Route .

apiVersion: appmesh.k8s.aws/v1beta1kind: VirtualServicemetadata: name: my-service-a.my-app-1.svc.cluster.local namespace: my-app-1spec: meshName: my-mesh virtualRouter: name: my-service-a-virtual-router listeners: - portMapping: port: 80 protocol: http routes: - name: my-service-a-route http: match: prefix: / action: weightedTargets: - virtualNodeName: my-service-a weight: 1

235





To see all available settings for a virtual service, virtual router, and route that you can set in thepreceding spec, run any of the following commands.

aws appmesh create-virtual-service --generate-cli-skeleton yaml-inputaws appmesh create-virtual-router --generate-cli-skeleton yaml-inputaws appmesh create-route --generate-cli-skeleton yaml-input

b. Create the virtual service.

kubectl apply -f virtual-service.yaml

c. View the virtual service resource.

kubectl describe virtualservice my-service-a.my-app-1.svc.cluster.local -n my-app-1

Abbreviated output

Name: my-service-a.my-app-1.svc.cluster.localNamespace: my-app-1Labels: <none>Annotations: kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"appmesh.k8s.aws/v1beta1","kind":"VirtualService","metadata":{"annotations":{},"name":"my-service-a.my-app-1.svc.cluster.loc...API Version: appmesh.k8s.aws/v1beta1Kind: VirtualService...Spec: Mesh Name: my-mesh Routes: Http: Action: Weighted Targets: Virtual Node Name: my-service-a Weight: 1 Match: Prefix: / Name: my-service-a-route Virtual Router: Listeners: Port Mapping: Port: 80 Protocol: http Name: my-service-a-virtual-routerStatus: Conditions: Last Transition Time: 2020-03-20T13:24:37Z Status: True Type: VirtualRouterActive Last Transition Time: 2020-03-20T13:24:37Z Status: True Type: RoutesActive Last Transition Time: 2020-03-20T13:24:38Z Status: True Type: VirtualServiceActiveEvents: <none>

d. Confirm that the virtual service was created in your mesh. The Kubernetes controller did notappend the Kubernetes namespace name to the App Mesh virtual service name when it createdthe virtual service in App Mesh because the virtual service's name is a unique FQDN.

236


aws appmesh describe-virtual-service --virtual-service-name my-service-a.my-app-1.svc.cluster.local --mesh-name=my-mesh

Output

{ "virtualService": { "meshName": "my-mesh", "metadata": { "arn": "arn:aws:appmesh:us-west-2:111122223333:mesh/my-mesh/virtualService/my-service-a.my-app-1.svc.cluster.local", "createdAt": "2020-03-20T08:24:37.434000-05:00", "lastUpdatedAt": "2020-03-20T08:24:37.434000-05:00", "meshOwner": "111122223333", "resourceOwner": "111122223333", "uid": "111a11b1-c11d-1e1f-gh1i-j11k1l111m711", "version": 1 }, "spec": { "provider": { "virtualRouter": { "virtualRouterName": "my-service-a-virtual-router-my-app-1" } } }, "status": { "status": "ACTIVE" }, "virtualServiceName": "my-service-a.my-app-1.svc.cluster.local" }}

e. Confirm that the virtual router was created in your mesh.

Note

Though the virtual router created in Kubernetes is my-service-a-virtual-router,the name of the virtual router created in App Mesh is my-service-a-virtual-router-my-app-1.

aws appmesh describe-virtual-router --virtual-router-name my-service-a-virtual-router-my-app-1 --mesh-name=my-mesh

Output

{ "virtualRouter": { "meshName": "my-mesh", "metadata": { "arn": "arn:aws:appmesh:us-west-2:111122223333:mesh/my-mesh/virtualRouter/my-service-a-virtual-router-my-app-1", "createdAt": "2020-03-20T08:24:37.285000-05:00", "lastUpdatedAt": "2020-03-20T08:24:37.285000-05:00", "meshOwner": "111122223333", "resourceOwner": "111122223333", "uid": "111a11b1-c11d-1e1f-gh1i-j11k1l111m711", "version": 1 }, "spec": { "listeners": [ {

237


"portMapping": { "port": 80, "protocol": "http" } } ] }, "status": { "status": "ACTIVE" }, "virtualRouterName": "my-service-a-virtual-router-my-app-1" }}

f. Confirm that the route was created in your mesh. The Kubernetes controller did not append theKubernetes namespace name to the App Mesh route name when it created the route in App Meshbecause route names are unique to a virtual router.

aws appmesh describe-route --route-name my-service-a-route --virtual-router-name my-service-a-virtual-router-my-app-1 --mesh-name my-mesh

Output

{ "route": { "meshName": "my-mesh", "metadata": { "arn": "arn:aws:appmesh:us-west-2:111122223333:mesh/my-mesh/virtualRouter/my-service-a-virtual-router-my-app-1/route/my-service-a-route", "createdAt": "2020-03-20T08:24:37.331000-05:00", "lastUpdatedAt": "2020-03-20T08:24:37.331000-05:00", "meshOwner": "111122223333", "resourceOwner": "111122223333", "uid": "111a11b1-c11d-1e1f-gh1i-j11k1l111m711", "version": 1 }, "routeName": "my-service-a-route", "spec": { "httpRoute": { "action": { "weightedTargets": [ { "virtualNode": "my-service-a-my-app-1", "weight": 1 } ] }, "match": { "prefix": "/" } } }, "status": { "status": "ACTIVE" }, "virtualRouterName": "my-service-a-virtual-router-my-app-1" }}

238

Amazon EKS ユーザーガイドStep 3: Create or update services

Step 3: Create or update servicesAny pods that you want to use with App Mesh must have the App Mesh sidecar containers added to them.The injector automatically adds the sidecar containers to any pod deployed into a namespace that youspecify.

To create or update services

1. To enable sidecar injection for the namespace, label the namespace.

kubectl label namespace my-app-1 appmesh.k8s.aws/sidecarInjectorWebhook=enabled

2. Enable proxy authorization. We recommend that you enable each Kubernetes deployment to streamthe configuration for its own App Mesh virtual node.

a. Create a file named proxy-auth.json with the following contents.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "appmesh:StreamAggregatedResources", "Resource": [ "arn:aws:appmesh:region-code:111122223333:mesh/my-mesh/virtualNode/my-service-a-my-app-1" ] } ]}

b. Create the policy.

aws iam create-policy --policy-name my-policy --policy-document file://proxy-auth.json

Note the ARN of the policy in the output returned. You'll use it in the next step.c. Create an IAM role, attach the policy you created in the previous step to it, create a Kubernetes

service account and bind the policy to the Kubernetes service account. The role enables thecontroller to add, remove, and change App Mesh resources.

eksctl create iamserviceaccount \ --cluster $CLUSTER_NAME \ --namespace my-app-1 \ --name my-service-a \ --attach-policy-arn arn:aws:iam::111122223333:policy/my-policy \ --override-existing-serviceaccounts \ --approve

If you prefer to create the service account using the AWS Management Console or AWS CLI,see Creating an IAM Role and Policy for your Service Account. If you use the AWS ManagementConsole or AWS CLI to create the account, you also need to map the role to a Kubernetes serviceaccount. For more information, see Specifying an IAM Role for your Service Account.

3. Create a Kubernetes service and deployment. If you have an existing deployment that you want to usewith App Mesh, you need to update its namespace to my-app-1 so that the sidecar containers areautomatically added to the pods and the pods are redeployed.

239

https://docs.aws.amazon.com/eks/latest/userguide/create-service-account-iam-policy-and-role.html#create-service-account-iam-role

https://docs.aws.amazon.com/eks/latest/userguide/specify-service-account-role.html


a. Create a file named example-service.yaml with the following contents.

apiVersion: v1kind: Servicemetadata: name: my-service-a namespace: my-app-1 labels: app: nginxspec: selector: app: nginx ports: - protocol: TCP port: 80 targetPort: 80---apiVersion: apps/v1kind: Deploymentmetadata: name: my-service-a namespace: my-app-1 labels: app: nginxspec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: serviceAccountName: my-service-a containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80

You can override the default behavior of the injector for individual pods. For example, notice in thepreceding spec that the name of the deployment is my-service-a. By default, this name mustbe the same as the name of the virtual node that you created in the section called “Step 2: DeployApp Mesh resources” (p. 233). If you want the name of the virtual node to be different than thename of the deployment, then you must add an annotation to your spec for the virtualNodesetting. To familiarize yourself with the settings that you can override, see Default behavior andhow to override on GitHub.

b. Deploy the service.

kubectl apply -f example-service.yaml

c. View the service and deployment.

kubectl -n my-app-1 get pods

Output

NAME READY STATUS RESTARTS AGE

240

https://github.com/aws/aws-app-mesh-inject/blob/master/README.md#default-behavior-and-how-to-override

https://github.com/aws/aws-app-mesh-inject/blob/master/README.md#default-behavior-and-how-to-override


my-service-a-658c47c864-g9p9l 2/2 Running 0 26smy-service-a-658c47c864-grn8w 2/2 Running 0 26smy-service-a-658c47c864-lc5qk 2/2 Running 0 26s

d. View the details for one of the pods that was deployed.

kubectl -n my-app-1 describe pod my-service-a-7fd6966748-79674

Abbreviated output

Name: my-service-a-658c47c864-g9p9lNamespace: my-app-1...Init Containers: proxyinit: Container ID: docker://5f45b51566681be12eb851d48a47199e5a09d8661a16296bca826c93d3703ae6 Image: 111345817488.dkr.ecr.us-west-2.amazonaws.com/aws-appmesh-proxy-route-manager:v2 Image ID: docker-pullable://111345817488.dkr.ecr.us-west-2.amazonaws.com/aws-appmesh-proxy-route-manager@sha256:1111111111111111111111111111111111111111111111111111111111111111 Port: <none> Host Port: <none> State: Terminated Reason: Completed Exit Code: 0 Started: Fri, 20 Mar 2020 08:37:05 -0500 Finished: Fri, 20 Mar 2020 08:37:06 -0500 Ready: True Restart Count: 0 Requests: cpu: 10m memory: 32Mi Environment: APPMESH_START_ENABLED: 1 APPMESH_IGNORE_UID: 1337 APPMESH_ENVOY_INGRESS_PORT: 15000 APPMESH_ENVOY_EGRESS_PORT: 15001 APPMESH_APP_PORTS: 80 APPMESH_EGRESS_IGNORED_IP: 169.254.169.254 APPMESH_EGRESS_IGNORED_PORTS: 22 AWS_ROLE_ARN: arn:aws:iam::111122223333:role/eksctl-appmesh-1-addon-iamserviceaccount-my-Role1-MVK5HIHHL4WT AWS_WEB_IDENTITY_TOKEN_FILE: /var/run/secrets/eks.amazonaws.com/serviceaccount/token Mounts: /var/run/secrets/eks.amazonaws.com/serviceaccount from aws-iam-token (ro) /var/run/secrets/kubernetes.io/serviceaccount from my-service-a-token-s29ls (ro)Containers: nginx: Container ID: docker://022c01578fa71129213a0de9df0748ff410f468739edc872bb1888843020bd88 Image: nginx:1.14.2 Image ID: docker-pullable://nginx@sha256:1111111111111111111111111111111111111111111111111111111111111111 Port: 80/TCP Host Port: 0/TCP State: Running Started: Fri, 20 Mar 2020 08:37:11 -0500 Ready: True Restart Count: 0 Environment:

241

Amazon EKS ユーザーガイドStep 4: Clean up

AWS_ROLE_ARN: arn:aws:iam::111122223333:role/eksctl-appmesh-1-addon-iamserviceaccount-my-Role1-MVK5HIHHL4WT AWS_WEB_IDENTITY_TOKEN_FILE: /var/run/secrets/eks.amazonaws.com/serviceaccount/token Mounts: /var/run/secrets/eks.amazonaws.com/serviceaccount from aws-iam-token (ro) /var/run/secrets/kubernetes.io/serviceaccount from my-service-a-token-s29ls (ro) envoy: Container ID: docker://742934a0722734762890ae925a4c143b739ba114ab33acf14919c4069773f492 Image: 840364872350.dkr.ecr.us-west-2.amazonaws.com/aws-appmesh-envoy:v1.12.2.1-prod Image ID: docker-pullable://840364872350.dkr.ecr.us-west-2.amazonaws.com/aws-appmesh-envoy@sha256:1111111111111111111111111111111111111111111111111111111111111111 Port: 9901/TCP Host Port: 0/TCP State: Running Started: Fri, 20 Mar 2020 08:37:18 -0500 Ready: True Restart Count: 0 Requests: cpu: 10m memory: 32Mi Environment: APPMESH_VIRTUAL_NODE_NAME: mesh/my-mesh/virtualNode/my-service-a-my-app-1 APPMESH_PREVIEW: 0 ENVOY_LOG_LEVEL: info AWS_REGION: us-west-2 AWS_ROLE_ARN: arn:aws:iam::111122223333:role/eksctl-appmesh-1-addon-iamserviceaccount-my-Role1-MVK5HIHHL4WT AWS_WEB_IDENTITY_TOKEN_FILE: /var/run/secrets/eks.amazonaws.com/serviceaccount/token Mounts: /var/run/secrets/eks.amazonaws.com/serviceaccount from aws-iam-token (ro) /var/run/secrets/kubernetes.io/serviceaccount from my-service-a-token-s29ls (ro)...

In the preceding output, you can see that the proxyinit and envoy containers were added tothe pod.

Step 4: Clean upRemove all of the example resources created in this tutorial. The controller also removes the resources thatwere created in App Mesh.

kubectl delete namespace my-app-1

(Optional) You can remove the Kubernetes integration components.

helm delete appmesh-controller -n appmesh-systemhelm delete appmesh-inject -n appmesh-system

242


深層学習コンテナAWS ディープラーニングコンテナは、Amazon EKS および Amazon Elastic Container Service (AmazonECS) の TensorFlow でモデルをトレーニングして提供するための Docker イメージのセットです。深層学習コンテナは、Amazon ECR で利用でき、TensorFlow、Nvidia CUDA (GPU インスタンス用)、およびインテル MKL (CPU インスタンス用) ライブラリを使用して最適化された環境を提供します。

Amazon EKS で AWS Deep Learning Containers の使用を開始するには、AWS Deep Learning AMI 開発者ガイドの「Amazon EKS での AWS Deep Learning Containers」を参照してください。

243

https://docs.aws.amazon.com/dlami/latest/devguide/deep-learning-containers-eks.html

Amazon EKS ユーザーガイドIdentity and access management

Amazon EKS でのセキュリティAWS では、クラウドのセキュリティが最優先事項です。AWS のお客様は、セキュリティを最も重視する組織の要件を満たすように構築されたデータセンターとネットワークアーキテクチャから利点を得られます。

セキュリティは、AWS とお客様の間の共有責任です。共有責任モデルでは、これをクラウドのセキュリティおよびクラウド内のセキュリティとして説明しています。

• クラウドのセキュリティ – AWS は、AWS クラウドで AWS のサービスを実行するインフラストラクチャの保護を担います。Amazon EKS に対して、AWS は Kubernetes コントロールプレーンに責任があり、これにはコントロールプレーンノードと etcd データベースが含まれています。AWS コンプライアンスプログラムの一環として、サードパーティーの監査が定期的にセキュリティの有効性をテストおよび検証しています。Amazon EKS に適用するコンプライアンスプログラムの詳細については、「コンプライアンスプログラムによる AWS 対象範囲内のサービス」を参照してください。

• クラウド内のセキュリティ – お客様の責任事項には、次の領域が含まれます。• セキュリティグループをお客様の VPC に Amazon EKS コントロールプレーンからお客様の VPC の

中へトラフィックの通過を許可するセキュリティグループの設定を含むデータプレーンのセキュリティ設定。

• ワーカーノードとコンテナそのものの設定。• ワーカーノードのゲストオペレーティングシステム (更新やセキュリティパッチを含みます)• その他の関連アプリケーションソフトウェア :

• ファイアウォールのルールなど、ネットワークコントロールの設定および管理。• IAM を使う、またはそれに追加しての ID とアクセス管理のプラットフォームレベルの運営。

• お客様のデータの機密性、企業の要件、該当する法律および規制

このドキュメントは、Amazon EKS を使用する際に共有責任モデルを適用する方法を理解するのに役立ちます。以下のトピックでは、セキュリティおよびコンプライアンスの目的を達成するために Amazon EKSを設定する方法を示します。また、Amazon EKS リソースのモニタリングや保護に役立つ他の AWS サービスの使用方法についても説明します。

トピック• Amazon EKS の Identity and Access Management (p. 244)• Amazon EKS でのログ記録とモニタリング (p. 277)• Amazon EKS のコンプライアンス検証 (p. 278)• Amazon EKS の耐障害性 (p. 278)• Amazon EKS でのインフラストラクチャセキュリティ (p. 279)• Amazon EKS での設定と脆弱性の分析 (p. 280)• ポッドのセキュリティポリシー (p. 280)

Amazon EKS の Identity and Access ManagementAWS Identity and Access Management (IAM) は、管理者が AWS リソースへのアクセスを安全にコントロールするために役立つ AWS のサービスです。IAM 管理者は、Amazon EKS リソースを使用するため

244

http://aws.amazon.com/compliance/shared-responsibility-model/

http://aws.amazon.com/compliance/programs/


http://aws.amazon.com/compliance/services-in-scope/


Amazon EKS ユーザーガイド対象者

に認証 (サインイン) および承認 (アクセス許可を持つ) される者を制御します。IAM は、追加料金なしで使用できる AWS のサービスです。

対象者AWS Identity and Access Management (IAM) の用途は、Amazon EKS で行う作業によって異なります。

サービスユーザー – ジョブを実行するために Amazon EKS サービスを使用する場合は、管理者が必要なアクセス許可と認証情報を用意します。作業を実行するためにさらに多くの Amazon EKS 機能を使用するとき、追加のアクセス許可が必要になる場合があります。アクセスの管理方法を理解すると、管理者から適切なアクセス許可をリクエストするのに役に立ちます。Amazon EKS の機能にアクセスできない場合は、「Amazon EKS Identity and Access のトラブルシューティング (p. 277)」を参照してください。

サービス管理者 – 社内の Amazon EKS リソースを担当している場合は、おそらく Amazon EKS へのフルアクセスがあります。従業員がどの Amazon EKS 機能とリソースアクセスする必要があるかを決定するのは管理者の仕事です。その後で、サービスユーザーのアクセス許可を変更するために、IAM 管理者にリクエストを送信する必要があります。IAM の基本概念については、このページの情報を確認します。お客様の会社で Amazon EKS の IAM を利用する方法の詳細については、「Amazon EKS と IAM の連携 (p. 248)」を参照してください。

IAM 管理者 – IAM 管理者は、Amazon EKS へのアクセスを管理するポリシーの作成方法の詳細について確認する場合があります。IAM で使用できる Amazon EKS アイデンティティベースのポリシーの例を表示するには、「Amazon EKS アイデンティティベースのポリシーの例 (p. 251)」を参照してください。

アイデンティティを使用した認証認証は、アイデンティティ認証情報を使用して AWS にサインインする方法です。AWS マネジメントコンソールを使用するサインインの詳細については、IAM ユーザーガイドの「IAM コンソールとサインインページ」を参照してください。

AWS アカウントのルートユーザー、IAM ユーザーとして、または IAM ロールを引き受けて、認証されている (AWS にサインインしている) 必要があります。会社のシングルサインオン認証を使用することも、Google や Facebook を使用してサインインすることもできます。このような場合、管理者は以前にIAM ロールを使用して ID フェデレーションを設定しました。他の会社の認証情報を使用して AWS にアクセスした場合、ロールを間接的に割り当てられています。

AWS マネジメントコンソールへ直接サインインするには、ルートユーザー E メールまたは IAM ユーザー名とパスワードを使用します。ルートユーザーまたは IAM を使用して AWS にプログラム的にアクセスできます。AWS では、SDK とコマンドラインツールを提供して、お客様の認証情報を使用して、リクエストに暗号で署名できます。AWS ツールを使用しない場合は、リクエストに自分で署名する必要があります。これには、インバウンド API リクエストを認証するためのプロトコル、署名バージョン 4 を使用します。リクエストの認証の詳細については、AWS General Referenceの「署名バージョン 4 の署名プロセス」を参照してください。

使用する認証方法を問わず、追加のセキュリティ情報の提供を要求される場合もあります。たとえば、AWS では多要素認証 (MFA) を使用してアカウントのセキュリティを高めることを推奨しています。詳細については、IAM ユーザーガイドの「AWS のデバイスに多要素認証 (MFA) を使用」を参照してください。

AWS アカウントのルートユーザーAWS アカウントを初めて作成する場合は、このアカウントのすべての AWS サービスとリソースに対して完全なアクセス権限を持つシングルサインインアイデンティティで始めます。このアイデンティティはAWS アカウントルートユーザーと呼ばれ、アカウントの作成に使用した E メールアドレスとパスワードでのサインインによりアクセスします。強くお勧めしているのは、日常的なタスクには、それが管理者タスクであっても、ルートユーザーを使用しないことです。代わりに、最初の IAM ユーザーを作成するためだけにルートユーザーを使用するというベストプラクティスに従います。その後、ルートユーザー認証情

245

https://docs.aws.amazon.com/IAM/latest/UserGuide/console.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/console.html

https://console.aws.amazon.com/

https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html

https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#create-iam-users

https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#create-iam-users

Amazon EKS ユーザーガイドアイデンティティを使用した認証

報を安全な場所に保管し、それらを使用して少数のアカウントおよびサービス管理タスクのみを実行します。

IAM ユーザーとグループIAM ユーザーは、単一のユーザーまたはアプリケーションに特定のアクセス許可がある AWS アカウント内のアイデンティティです。IAM ユーザーは、ユーザー名とパスワード、アクセスキーのセットなど、長期的な認証情報を持つことができます。アクセスキーを生成する方法の詳細については、IAM ユーザーガイドの「IAM ユーザーのアクセスキーの管理」を参照してください。IAM ユーザーにアクセスキーを生成するとき、必ずキーペアを表示して安全に保存してください。後になって、シークレットアクセスキーを回復することはできません。新しいアクセスキーペアを生成する必要があります。

IAM グループは、IAM ユーザーのコレクションを指定するアイデンティティです。グループとしてサインインすることはできません。グループを使用して、一度に複数のユーザーに対してアクセス許可を指定できます。多数の組のユーザーがある場合、グループを使用すると管理が容易になります。たとえば、IAMAdmin という名前のグループを設定して、そのグループに IAM リソースを管理するアクセス許可を与えることができます。

ユーザーは、ロールとは異なります。ユーザーは 1 人の特定の人またはアプリケーションに一意に関連付けられますが、ロールはそれを必要とする任意の人が引き受けるようになっています。ユーザーには永続的な長期の認証情報がありますが、ロールでは一時的な認証情報が利用できます。詳細については、IAMユーザーガイドの「IAM ユーザーの作成が適している場合 (ロールではなく)」を参照してください。

IAM ロールIAM ロールは、特定のアクセス許可を持つ、AWS アカウント内のアイデンティティです。これは IAMユーザーに似ていますが、特定のユーザーに関連付けられていません。ロールを切り替えて、AWS マネジメントコンソールで IAM ロールを一時的に引き受けることができます。ロールを引き受けるには、AWSCLI または AWS API オペレーションを呼び出すか、カスタム URL を使用します。ロールを使用する方法の詳細については、IAM ユーザーガイドの「IAM ロールの使用」を参照してください。

IAM ロールと一時的な認証情報は、次の状況で役立ちます。

• 一時的な IAM ユーザーアクセス許可 – IAM ユーザーは、特定のタスクに対して複数の異なるアクセス許可を一時的に IAM ロールで引き受けることができます。

• フェデレーティッドユーザーアクセス – IAM ユーザーを作成する代わりに、AWS Directory Service、エンタープライズユーザーディレクトリ、またはウェブ ID プロバイダーに既存のアイデンティティを使用できます。このようなユーザーはフェデレーティッドユーザーと呼ばれます。AWS では、ID プロバイダーを通じてアクセスがリクエストされたとき、フェデレーティッドユーザーにロールを割り当てます。フェデレーティッドユーザーの詳細については、IAM ユーザーガイドの「フェデレーティッドユーザーとロール」を参照してください。

• クロスアカウントアクセス – IAM ロールを使用して、自分のアカウントのリソースにアクセスすることを別のアカウントの信頼済みプリンシパルに許可できます。ロールは、クロスアカウントアクセスを許可する主な方法です。ただし、一部の AWS のサービスでは、(ロールをプロキシとして使用する代わりに) リソースにポリシーを直接アタッチできます。クロスアカウントアクセスでのロールとリソースベースのポリシーの違いの詳細については、IAM ユーザーガイドの「IAM ロールとリソースベースのポリシーとの相違点」を参照してください。

• AWS サービスアクセス – サービスロールは、サービスがお客様に代わってお客様のアカウントでアクションを実行するために引き受ける IAM ロールです。一部の AWS のサービス環境を設定するときに、サービスが引き受けるロールを定義する必要があります。このサービスロールには、サービスが必要とする AWS のリソースにサービスがアクセスするために必要なすべてのアクセス権限を含める必要があります。サービスロールはサービスによって異なりますが、多くのサービスロールでは、そのサービスの文書化された要件を満たしている限り、アクセス権限を選択することができます。サービスロールは、お客様のアカウント内のみでアクセスを提供します。他のアカウントのサービスへのアクセス権を付与するためにサービスロールを使用することはできません。IAM 内部からロールを作成、修正、削除できます。たとえば、Amazon Redshift がお客様に代わって Amazon S3 バケットにアクセスし、バケッ

246

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html



https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_access-management.html#intro-access-roles

https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_access-management.html#intro-access-roles

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html


Amazon EKS ユーザーガイドポリシーを使用したアクセスの管理

トからデータを Amazon Redshift クラスターにロードすることを許可するロールを作成できます。詳細については、IAM ユーザーガイドのAWS サービスにアクセス権限を委任するロールの作成を参照してください。

• Amazon EC2で実行されているアプリケーション – IAM ロールを使用して、EC2 インスタンスで実行され、AWS CLI または AWS API リクエストを作成しているアプリケーションの一時的な認証情報を管理できます。これは、EC2 インスタンス内でのアクセスキーの保存に推奨されます。AWS ロールを EC2インスタンスに割り当て、そのすべてのアプリケーションで使用できるようにするには、インスタンスにアタッチされたインスタンスプロファイルを作成します。インスタンスプロファイルにはロールが含まれ、EC2 インスタンスで実行されるプログラムは一時認証情報を取得することができます。詳細については、IAM ユーザーガイドの「Amazon EC2 インスタンスで実行されるアプリケーションに IAM ロールを使用してアクセス権限を付与する」を参照してください。

IAM ロールを使用するべきかどうかについては、IAM ユーザーガイドの「IAM ロール (ユーザーではない)の作成が適している場合」を参照してください。

ポリシーを使用したアクセスの管理AWS でアクセスをコントロールするには、ポリシーを作成して IAM アイデンティティや AWS リソースにアタッチします。ポリシーは AWS のオブジェクトであり、アイデンティティやリソースに関連付けて、これらのアクセス許可を定義します。AWS は、エンティティ (ルートユーザー、IAM ユーザーまたはIAM ロール) によってリクエストが行われると、それらのポリシーを評価します。ポリシーでのアクセス許可により、リクエストが許可されるか拒否されるかが決まります。大半のポリシーは JSON ドキュメントとして AWS に保存されます。JSON ポリシードキュメントの構造と内容の詳細については、IAM ユーザーガイドの「JSON ポリシー概要」を参照してください。

IAM 管理者は、ポリシーを使用して、AWS リソースへのアクセスを許可するユーザーと、これらのリソースで実行できるアクションを指定できます。すべての IAM エンティティ (ユーザーまたはロール) は、アクセス許可のない状態からスタートします。言い換えると、デフォルト設定では、ユーザーは何もできず、自分のパスワードを変更することすらできません。何かを実行するアクセス許可をユーザーに付与するには、管理者がユーザーにアクセス許可ポリシーをアタッチする必要があります。また、管理者は、必要なアクセス許可があるグループにユーザーを追加できます。管理者がグループにアクセス許可を付与すると、そのグループ内のすべてのユーザーにこれらのアクセス許可が付与されます。

IAM ポリシーは、オペレーションの実行方法を問わず、アクションのアクセス許可を定義します。たとえば、iam:GetRole アクションを許可するポリシーがあるとします。このポリシーがあるユーザーは、AWS マネジメントコンソール、AWS CLI、または AWS API からロールの情報を取得できます。

アイデンティティベースのポリシーアイデンティティベースのポリシーは、IAM ユーザー、ロール、グループなどのアイデンティティにJSON ドキュメントとしてアタッチできるアクセス許可ポリシーです。これらのポリシーは、アイデンティティが実行できるアクション、リソース、および条件を制御します。アイデンティティベースのポリシーを作成する方法については、IAM ユーザーガイドの「IAM ポリシーの作成」を参照してください。

アイデンティティベースのポリシーは、さらにインラインポリシーまたは管理ポリシーに分類できます。インラインポリシーは、単一のユーザー、グループ、またはロールに直接埋め込まれています。管理ポリシーは、AWS アカウント内の複数のユーザー、グループ、およびロールにアタッチできるスタンドアロンポリシーです。管理ポリシーには、AWS 管理ポリシーとカスタマー管理ポリシーが含まれます。管理ポリシーまたはインラインポリシーのいずれかを選択する方法については、IAM ユーザーガイドの「管理ポリシーとインラインポリシーの比較」を参照してください。

リソースベースのポリシーリソースベースのポリシーは、Amazon S3 バケットなどのリソースにアタッチする JSON ポリシードキュメントです。サービス管理者は、これらのポリシーを使用して、特定のプリンシパル (アカウントメンバー、ユーザー、またはロール) がそのリソースに対して実行する条件およびアクションを定義するこ

247

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose_role

https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose_role

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#choosing-managed-or-inline

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#choosing-managed-or-inline

Amazon EKS ユーザーガイドAmazon EKS と IAM の連携

とができます。リソースベースのポリシーはインラインポリシーです。マネージド型のリソースベースのポリシーはありません。

アクセスコントロールリスト (ACL)アクセスコントロールリスト (ACL) は、どのプリンシパル (アカウントメンバー、ユーザー、またはロール) にリソースへのアクセス許可を付与するかを制御する一種のポリシーです。ACL は、リソースベースのポリシーと似ていますが、JSON ポリシードキュメント形式を使用しません。ACL をサポートするサービスとして Amazon S3、AWS WAF、Amazon VPC などがあります。ACL の詳細については、『AmazonSimple Storage Service 開発者ガイド』の「アクセスコントロールリスト (ACL) の概要」を参照してください。

その他のポリシータイプAWS では、別のあまり一般的ではないポリシータイプもサポートしています。これらのポリシータイプでは、より一般的なポリシータイプで付与された最大のアクセス許可を設定できます。

• アクセス許可の境界 – アクセス許可の境界は、アイデンティティベースのポリシーが IAM エンティティ(IAM ユーザーまたはロール) に付与できるアクセス許可の上限を設定する高度な機能です。エンティティのアクセス許可の境界を設定できます。結果として得られるアクセス許可は、エンティティの IDベースのポリシーとそのアクセス許可の境界の共通部分です。Principal フィールドでユーザーまたはロールを指定するリソースベースのポリシーは、アクセス許可の境界では制限されません。これらのポリシーのいずれかを明示的に拒否した場合、その許可は無効になります。アクセス許可の境界の詳細については、IAM ユーザーガイドの「IAM エンティティのアクセス許可の境界」を参照してください。

• サービスコントロールポリシー (SCP) – SCP は、AWS Organizations で組織や組織単位 (OU) に最大権限を指定する JSON ポリシーです。AWS Organizations は、お客様のビジネスが所有する複数の AWSアカウントをグループ化し、一元的に管理するサービスです。組織内のすべての機能を有効にすると、サービス制御ポリシー (SCP) を一部またはすべてのアカウントに適用できます。SCP はメンバーアカウントのエンティティに対するアクセス許可を制限します (各 AWS アカウントのルートユーザーなど)。組織および SCP の詳細については、AWS Organizations ユーザーガイドの「SCP の動作」を参照してください。

• セッションポリシー – セッションポリシーは、ロールまたはフェデレーティッドユーザーの一時セッションをプログラムで作成する際にパラメータとして渡す高度なポリシーです。結果として得られるセッションのアクセス許可は、ユーザーまたはロールの ID ベースのポリシーとセッションポリシーの共通部分です。また、リソースベースのポリシーからアクセス許可が派生する場合もあります。これらのポリシーのいずれかを明示的に拒否した場合、その許可は無効になります。詳細については、IAM ユーザーガイドの「セッションポリシー」を参照してください。

複数のポリシータイプ1 つのリクエストに複数のタイプのポリシーが適用されると、結果として作成されるアクセス許可を理解するのがさらに複雑になります。複数のポリシータイプが関連するとき、リクエストを許可するかどうかを AWS が決定する方法の詳細については、IAM ユーザーガイドの「ポリシーの評価ロジック」を参照してください。

Amazon EKS と IAM の連携Amazon EKS へのアクセスを管理するために IAM 使用する前に、Amazon EKS で使用できる IAM 機能を理解しておく必要があります。IAM と連携する Amazon EKS や他の AWS のサービスの動作の概要については、『IAM ユーザーガイド』の「IAM と連携する AWS のサービス」を参照してください。

トピック• Amazon EKS アイデンティティベースのポリシー (p. 249)• Amazon EKS リソースベースのポリシー (p. 250)

248

https://docs.aws.amazon.com/AmazonS3/latest/dev/acl-overview.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_about-scps.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html


• Amazon EKS タグに基づいた承認 (p. 250)• Amazon EKS IAM ロール (p. 250)

Amazon EKS アイデンティティベースのポリシーIAM アイデンティティベースのポリシーでは、許可または拒否されたアクションとリソースを指定でき、さらにアクションが許可または拒否された条件を指定できます。Amazon EKS は、特定のアクション、リソース、および条件キーをサポートします。JSON ポリシーで使用するすべての要素については、IAMユーザーガイドの「IAM JSON ポリシーエレメントのリファレンス」を参照してください。

アクションIAM アイデンティティベースのポリシーの Action エレメントは、そのポリシーにより許可または拒否される特定のアクションについて説明します。ポリシーアクションの名前は通常、関連する AWS API オペレーションと同じです。このアクションは、関連付けられたオペレーションを実行するためのアクセス許可を付与するポリシーで使用されます。

Amazon EKS のポリシーアクションは、アクションの前にプレフィックス eks: を使用します。たとえば、Amazon EKS クラスターについて説明する情報を入手するアクセス許可を他のユーザーに付与するには、ポリシーに DescribeCluster アクションを含めます。ポリシーステートメントには、Action または NotAction エレメントを含める必要があります。

単一のステートメントに複数のアクションを指定するには、次のようにコンマで区切ります。

"Action": ["eks:action1", "eks:action2"]

ワイルドカード (*) を使用して複数のアクションを指定することができます。たとえば、Describe という単語で始まるすべてのアクションを指定するには、次のアクションを含めます。

"Action": "eks:Describe*"

Amazon EKS のアクションを一覧表示するには、IAM ユーザーガイドの「Amazon Elastic KubernetesService で定義されるアクション」を参照してください。

リソースResource エレメントは、アクションが適用されるオブジェクトを指定します。ステートメントには、Resource または NotResource エレメントを含める必要があります。ARN を使用して、またはステートメントがすべてのリソースに適用されることを示すワイルドカード (*) を使用して、リソースを指定します。

Amazon EKS クラスターリソースの ARN は次のようになります。

arn:${Partition}:eks:${Region}:${Account}:cluster/${ClusterName}

ARN の形式の詳細については、「Amazon リソースネーム (ARN) と AWS のサービスの名前空間」を参照してください。

たとえば、ステートメントで dev クラスターを指定するには、次の ARN を使用します。

"Resource": "arn:aws:eks:region-code:123456789012:cluster/dev"

特定のアカウントとリージョンに属するすべてのクラスターを指定するには、ワイルドカード (*) を使用します。

249

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonelasticcontainerserviceforkubernetes.html#amazonelasticcontainerserviceforkubernetes-actions-as-permissions


https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html


"Resource": "arn:aws:eks:region-code:123456789012:cluster/*"

リソースの作成など、一部の Amazon EKS アクションは、特定のリソースで実行できません。このような場合は、ワイルドカード (*) を使用する必要があります。

"Resource": "*"

Amazon EKS リソースタイプおよびその ARN のリストを表示するには、IAM ユーザーガイドの「Amazon Elastic Kubernetes Service で定義されるリソース」を参照してください。どのアクションで、各リソースの ARN を指定することができるかについては、「Amazon Elastic Kubernetes Service で定義されるアクション」を参照してください。

条件キー

Amazon EKS にはサービス固有条件キーがありませんが、いくつかのグローバル条件キーの使用がサポートされています。すべての AWS グローバル条件キーを確認するには、IAM ユーザーガイドの「AWS グローバル条件コンテキストキー」を参照してください。

例

Amazon EKS アイデンティティベースのポリシーの例を表示するには、「Amazon EKS アイデンティティベースのポリシーの例 (p. 251)」を参照してください。

Amazon EKS クラスターを作成すると、このクラスターを作成した IAM エンティティユーザーまたはロール (例: フェデレーティッドユーザー) は、クラスターの RBAC 設定で system:masters のアクセス許可が自動的に付与されます。クラスターを操作する権限を他の AWS ユーザーやロールに付与するには、Kubernetes 内の aws-auth ConfigMap を編集する必要があります。

ConfigMap の使用の詳細については、クラスターのユーザーまたは IAM ロールの管理 (p. 202) を参照してください。

Amazon EKS リソースベースのポリシーAmazon EKS では、リソースベースのポリシーはサポートされていません。

Amazon EKS タグに基づいた承認タグを Amazon EKS リソースにアタッチすることも、Amazon EKS へのリクエストでタグを渡すこともできます。タグに基づいてアクセスを制御するには、eks:ResourceTag/key-name、aws:RequestTag/key-name、または aws:TagKeys の条件キーを使用して、ポリシーの条件要素でタグ情報を提供します。Amazon EKS リソースのタグ付けの詳細については、「Amazon EKS リソースのタグ付け (p. 285)」を参照してください。

Amazon EKS IAM ロールIAM ロールは、特定のアクセス許可を持つ、AWS アカウント内のエンティティです。

Amazon EKS を使用した一時的な認証情報の使用

一時的な認証情報を使用して、フェデレーションでサインイン、IAM ロールを引き受ける、またはクロスアカウントロールを引き受けることができます。一時的なセキュリティ認証情報を取得するには、AssumeRole または GetFederationToken などの AWS STS API オペレーションを呼び出します。

Amazon EKSでは、一時認証情報の使用をサポートしています。

250

https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonelasticcontainerserviceforkubernetes.html#amazonelasticcontainerserviceforkubernetes-resources-for-iam-policies



https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html


https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html


https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html

https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html

https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html

Amazon EKS ユーザーガイドアイデンティティベースのポリシーの例

サービスにリンクされたロールサービスにリンクされたロールによって、AWS サービスが他のサービスのリソースにアクセスして自動的にアクションを完了できます。サービスにリンクされたロールは、IAM アカウント内に表示され、サービスによって所有されます。IAM 管理者は、サービスにリンクされたロールのアクセス許可を表示できますが、編集することはできません。

Amazon EKS はサービスにリンクされたロールをサポートします。Amazon EKS サービスにリンクされたロールの作成または管理の詳細については、「Amazon EKS のサービスにリンクされたロールの使用 (p. 254)」を参照してください。

サービスロールこの機能では、サービスのロールをユーザーに代わって引き受けることをサービスに許可します。このロールにより、サービスはユーザーに代わって他のサービスのリソースにアクセスし、アクションを実行できます。サービスロールは、IAM アカウントに表示され、サービスによって所有されます。つまり、IAM 管理者は、このロールのアクセス許可を変更できます。ただし、これを行うことにより、サービスの機能が損なわれる場合があります。

Amazon EKS ではサービスロールがサポートされています。詳細については、「the section called “クラスターの IAM ロール” (p. 258)」および「the section called “ワーカーノード IAM ロール” (p. 260)」を参照してください。

Amazon EKS で IAM ロールを選択するAmazon EKS でクラスターリソースを作成するときは、お客様に代わって他のいくつかの AWS リソースへのアクセスを Amazon EKS に許可するロールを選択する必要があります。以前に作成したサービスロールがある場合、Amazon EKS により、選択できるロールのリストが表示されます。Amazon EKS 管理ポリシーがアタッチされたロールを選択することが重要です。詳細については、「the section called “既存のクラスターロールの確認” (p. 258)」および「the section called “既存のワーカーノードロールの確認” (p. 261)」を参照してください。

Amazon EKS アイデンティティベースのポリシーの例デフォルトでは、IAM ユーザーおよびロールには、Amazon EKS リソースを作成または変更するアクセス許可がありません。また、AWS マネジメントコンソール、AWS CLI、または AWS API を使用してタスクを実行することもできません。IAM 管理者は、ユーザーとロールに必要な、指定されたリソースで特定の API オペレーションを実行するアクセス許可をユーザーとロールに付与する IAM ポリシーを作成する必要があります。続いて、管理者はそれらのアクセス権限が必要な IAM ユーザーまたはグループにそのポリシーをアタッチします。

JSON ポリシードキュメントのこれらの例を使用して、IAM アイデンティティベースのポリシーを作成する方法については、IAM ユーザーガイドの「[JSON] タブでのポリシーの作成」を参照してください。

Amazon EKS クラスターを作成すると、このクラスターを作成した IAM エンティティユーザーまたはロール (例: フェデレーティッドユーザー) は、クラスターの RBAC 設定で system:masters のアクセス許可が自動的に付与されます。クラスターを操作する権限を他の AWS ユーザーやロールに付与するには、Kubernetes 内の aws-auth ConfigMap を編集する必要があります。

ConfigMap の使用の詳細については、クラスターのユーザーまたは IAM ロールの管理 (p. 202) を参照してください。

トピック• ポリシーのベストプラクティス (p. 252)• Amazon EKS コンソールを使用する (p. 252)• 自分のアクセス許可の表示をユーザーに許可する (p. 253)• Kubernetes クラスターの更新 (p. 253)• すべてのクラスターの一覧表示または説明 (p. 254)

251

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-role

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor



ポリシーのベストプラクティスアイデンティティベースのポリシーは非常に強力です。アカウント内で、Amazon EKS リソースを作成、アクセス、または削除できるかどうかを決定します。これらのアクションを実行すると、AWS アカウントに追加料金が発生する可能性があります。アイデンティティベースのポリシーを作成または編集するときは、以下のガイドラインと推奨事項に従います。

• AWS 管理ポリシーの使用を開始する – Amazon EKS の使用をすばやく開始するには、AWS 管理ポリシーを使用して、従業員に必要なアクセス許可を付与します。これらのポリシーはアカウントですでに有効になっており、AWS によって管理および更新されています。詳細については、IAM ユーザーガイドの「AWS 管理ポリシーを使用したアクセス許可の使用開始」を参照してください。

• 最小権限を付与する – カスタムポリシーを作成するときは、タスクを実行するために必要なアクセス許可のみを付与します。最小限のアクセス権限から開始し、必要に応じて追加のアクセス権限を付与します。この方法は、寛容なアクセス権限で始め、後でそれらを強化しようとするよりも安全です。詳細については、IAM ユーザーガイドの「最小権限を付与する」を参照してください。

• 機密性の高いオペレーションに MFA を有効にする – 追加セキュリティとして、機密性の高リソースまたは API オペレーションにアクセスするために IAM ユーザーに対して、多要素認証 (MFA) の使用を要求します。詳細については、IAM ユーザーガイドの「AWS のデバイスに多要素認証 (MFA) を使用」を参照してください。

• 追加セキュリティに対するポリシー条件を使用する – 実行可能な範囲内で、アイデンティティベースのポリシーがリソースにアクセスできる条件を定義します。たとえば、要求が発生しなければならない許容 IP アドレスの範囲を指定するための条件を記述できます。指定された日付または時間範囲内でのみリクエストを許可する条件を書くことも、SSL や MFA の使用を要求することもできます。ポリシー要素の詳細については、IAM ユーザーガイドの「IAM JSON ポリシー要素: 条件」を参照してください。

Amazon EKS コンソールを使用するAmazon EKS コンソールにアクセスするには、一連の最小限のアクセス許可が必要です。これらのアクセス許可により、AWS アカウントの Amazon EKS リソースの詳細をリストおよび表示できます。最小限必要なアクセス許可よりも制限されたアイデンティティベースのポリシーを作成すると、そのポリシーをアタッチしたエンティティ (IAM ユーザーまたはロール) に対してはコンソールが意図したとおりに機能しません。

これらのエンティティがまだ Amazon EKS コンソールを使用できるようにするには、AmazonEKSAdminPolicy など、独自の名前を持つポリシーを作成します。エンティティにポリシーをアタッチします。詳細については、『IAM ユーザーガイド』の「ユーザーへのアクセス許可の追加」を参照してください。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "eks:*" ], "Resource": "*" }, { "Effect": "Allow", "Action": "iam:PassRole", "Resource": "*", "Condition": { "StringEquals": { "iam:PassedToService": "eks.amazonaws.com" } }

252

https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-use-aws-defined-policies

https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html


https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console


} ]}

AWS CLI または AWS API のみを呼び出すユーザーには、最小限のコンソールアクセス許可を付与する必要はありません。代わりに、実行しようとしている API オペレーションに一致するアクションのみへのアクセスが許可されます。

自分のアクセス許可の表示をユーザーに許可するこの例は

この例では、ユーザー ID にアタッチされたインラインおよび管理ポリシーの表示を IAM ユーザーに許可するポリシーを作成する方法を示します。このポリシーには、コンソールで、または AWS CLI か AWSAPI を使用してプログラム的に、このアクションを完了するアクセス許可が含まれています。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "ViewOwnUserInfo", "Effect": "Allow", "Action": [ "iam:GetUserPolicy", "iam:ListGroupsForUser", "iam:ListAttachedUserPolicies", "iam:ListUserPolicies", "iam:GetUser" ], "Resource": ["arn:aws:iam::*:user/${aws:username}"] }, { "Sid": "NavigateInConsole", "Effect": "Allow", "Action": [ "iam:GetGroupPolicy", "iam:GetPolicyVersion", "iam:GetPolicy", "iam:ListAttachedGroupPolicies", "iam:ListGroupPolicies", "iam:ListPolicyVersions", "iam:ListPolicies", "iam:ListUsers" ], "Resource": "*" } ]}

Kubernetes クラスターの更新この例は、リージョンを問わず、アカウントの dev クラスターの Kubernetes バージョンをユーザーが更新できるようにするポリシーを作成する方法を示しています。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "eks:UpdateClusterVersion", "Resource": "arn:aws:eks:*:111122223333:cluster/dev" }

253

Amazon EKS ユーザーガイドサービスにリンクされたロールの使用

]}

すべてのクラスターの一覧表示または説明この例は、すべてのクラスターの一覧表示または説明するための読み取り専用アクセス許可をユーザーに許可するポリシーを作成する方法を示しています。update-kubeconfig AWS CLI コマンドを使用するには、アカウントでクラスターの一覧表示と説明が可能である必要があります。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "eks:DescribeCluster", "eks:ListClusters" ], "Resource": "*" } ]}

Amazon EKS のサービスにリンクされたロールの使用Amazon Elastic Kubernetes Service は、AWS Identity and Access Management (IAM) のサービスにリンクされたロールを使用します。サービスにリンクされたロールは、Amazon EKS に直接リンクされた一意のタイプの IAM ロールです。サービスにリンクされたロールは、Amazon EKS による事前定義済みのロールであり、ユーザーに代わってサービスから AWS の他のサービスを呼び出すために必要なすべてのアクセス権限を備えています。

トピック• Using Roles for Amazon EKS (p. 254)• Using Roles for Amazon EKS Nodegroups (p. 256)

Using Roles for Amazon EKSAmazon Elastic Kubernetes Service は、AWS Identity and Access Management (IAM) サービスにリンクされたロールを使用します。サービスにリンクされたロールは、Amazon EKS に直接リンクされた一意のタイプの IAM ロールです。サービスにリンクされたロールは、Amazon EKS による事前定義済みのロールであり、ユーザーに代わってサービスから AWS の他のサービスを呼び出すために必要なすべてのアクセス権限を備えています。

サービスにリンクされたロールを使用すると、必要なアクセス許可を手動で追加する必要がなくなるため、Amazon EKS の設定が簡単になります。Amazon EKS はサービスにリンクされたロールのアクセス許可を定義し、別途定義されている場合を除き、Amazon EKS のみがそのロールを引き受けることができます。定義されるアクセス権限には、信頼ポリシーやアクセス権限ポリシーなどがあり、そのアクセス権限ポリシーをその他の IAM エンティティにアタッチすることはできません。

サービスにリンクされたロールを削除するには、まずその関連リソースを削除します。これにより、リソースへの意図しないアクセスによるアクセス許可の削除が防止され、Amazon EKS リソースは保護されます。

サービスにリンクされたロールをサポートする他のサービスについては、「IAM と連携する AWS サービス」を参照の上、「サービスにリンクされたロール」列が「はい」になっているサービスを検索してくだ

254








さい。サービスにリンクされたロールに関するドキュメントをサービスで表示するには、[はい] リンクを選択します。

Amazon EKS のサービスにリンクされたロールのアクセス許可Amazon EKS では、[AWSServiceRoleForAmazonEKS] と呼ばれるサービスにリンクされたロールを使用します – These permissions are required for Amazon EKS to manage clusters in your account. Thesepolicies are related to management of the following resources: network interfaces, security groups, logs,and VPCs.

Note

AWSServiceRoleForAmazonEKS サービスにリンクされたロールは、クラスターの作成に必要なロールとは異なります。詳細については、「the section called “クラスターの IAM ロール” (p. 258)」を参照してください。

AWSServiceRoleForAmazonEKS サービスにリンクされたロールは、ロールを引き受ける上で次のサービスを信頼します。

• eks.amazonaws.com

ロールのアクセス権限ポリシーは、指定したリソースに対して以下のアクションを実行することをAmazon EKS に許可します。

• AWSServiceRoleForAmazonEKS

IAM エンティティ (ユーザー、グループ、ロールなど) がサービスにリンクされたロールを作成、編集、削除できるようにするには、アクセス権限を設定する必要があります。詳細については、IAM ユーザーガイドの「サービスにリンクされたロールのアクセス許可」を参照してください。

Amazon EKS のサービスにリンクされたロールの作成サービスにリンクされたロールを手動で作成する必要はありません。AWS マネジメントコンソール、AWS CLI、AWS API で create a cluster を行うと、サービスにリンクされたロールが Amazon EKS で自動的に作成されます。

このサービスにリンクされたロールを削除した後で再度作成する必要が生じた場合は、同じ方法でアカウントにロールを再作成できます。サービスにリンクされたロールは、create a cluster を行うと AmazonEKS で再度自動的に作成されます。

Amazon EKS のサービスにリンクされたロールの編集Amazon EKS では、 AWSServiceRoleForAmazonEKS サービスにリンクされたロールを編集することはできません。サービスにリンクされたロールを作成すると、多くのエンティティによってロールが参照される可能性があるため、ロール名を変更することはできません。ただし、IAM を使用したロールの説明の編集はできます。詳細については、IAM ユーザーガイドの「サービスにリンクされたロールの編集」を参照してください。

Amazon EKS のサービスにリンクされたロールの削除サービスにリンクされたロールが必要な機能またはサービスが不要になった場合には、そのロールを削除することをお勧めします。そうすることで、使用していないエンティティがアクティブにモニタリングされたり、メンテナンスされたりすることがなくなります。ただし、手動で削除する前に、サービスにリンクされたロールをクリーンアップする必要があります。

サービスにリンクされたロールのクリーンアップ

IAM を使用してサービスにリンクされたロールを削除するには、最初に、そのロールで使用されているリソースをすべて削除する必要があります。

255

https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSServiceRoleForAmazonEKS%24jsonEditor

https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions

https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role


Note

リソースを削除する際に、Amazon EKS サービスでロールが使用されている場合、削除は失敗することがあります。失敗した場合は、数分待ってから再度オペレーションを実行してください。

AWSServiceRoleForAmazonEKS で使用されている Amazon EKS リソースを削除するには

1. Open the Amazon EKS console at https://console.aws.amazon.com/eks/home#/clusters.2. クラスターを選択します。3. [クラスター] ページで、[ノードグループ] セクションにマネージド型ノードグループがある場合、そ

れぞれを個別に選択し、[削除] を選択します。4. 削除確認ウィンドウにノードグループの名前を入力し、[確認] を選択して削除します。5. この手順をクラスター内の他のすべてのノードグループに対して繰り返します。すべての削除操作が

完了するまで待ちます。6. クラスターのページで [削除] を選択します。7. この手順をアカウント内の他のすべてのクラスターに対して繰り返します。

サービスにリンクされたロールを手動で削除する

IAM コンソール、AWS CLI、AWS API を使用して、AWSServiceRoleForAmazonEKS サービスにリンクされたロールを削除します。詳細については、IAM ユーザーガイドの「サービスにリンクされたロールの削除」を参照してください。

Amazon EKS サービスにリンクされたロールがサポートされるリージョンAmazon EKS は、サービスを利用できるすべてのリージョンで、サービスにリンクされたロールの使用をサポートします。詳細については、「Amazon EKS Service Endpoints and Quotas」を参照してください。

Using Roles for Amazon EKS NodegroupsAmazon EKS は、AWS Identity and Access Management (IAM) のサービスにリンクされたロールを使用します。サービスにリンクされたロールは、Amazon EKS に直接リンクされた一意のタイプの IAM ロールです。サービスにリンクされたロールは、Amazon EKS による事前定義済みのロールであり、ユーザーに代わってサービスから AWS の他のサービスを呼び出すために必要なすべてのアクセス権限を備えています。

サービスにリンクされたロールを使用すると、必要なアクセス許可を手動で追加する必要がなくなるため、Amazon EKS の設定が簡単になります。Amazon EKS はサービスにリンクされたロールのアクセス許可を定義し、別途定義されている場合を除き、Amazon EKS のみがそのロールを引き受けることができます。定義されるアクセス権限には、信頼ポリシーやアクセス権限ポリシーなどがあり、そのアクセス権限ポリシーをその他の IAM エンティティにアタッチすることはできません。

サービスにリンクされたロールを削除するには、まずその関連リソースを削除します。これにより、リソースへの意図しないアクセスによるアクセス許可の削除が防止され、Amazon EKS リソースは保護されます。

サービスにリンクされたロールをサポートする他のサービスについては、「IAM と連携する AWS サービス」を参照の上、「サービスにリンクされたロール」列が「はい」になっているサービスを検索してください。サービスにリンクされたロールに関するドキュメントをサービスで表示するには、[はい] リンクを選択します。

Amazon EKS のサービスにリンクされたロールのアクセス許可Amazon EKS では、サービスにリンクされたロールとして AWSServiceRoleForAmazonEKSNodegroup–These permissions are required for managing nodegroups in your account. These policies are related to

256


https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role







management of the following resources: Auto Scaling groups, security groups, launch templates and IAMinstance profiles. を使用します。

AWSServiceRoleForAmazonEKSNodegroup サービスにリンクされたロールは、ロールを引き受ける上で次のサービスを信頼します。

• eks-nodegroup.amazonaws.com

ロールのアクセス権限ポリシーは、指定したリソースに対して以下のアクションを実行することをAmazon EKS に許可します。

• AWSServiceRoleForAmazonEKS

IAM エンティティ (ユーザー、グループ、ロールなど) がサービスにリンクされたロールを作成、編集、削除できるようにするには、アクセス権限を設定する必要があります。詳細については、IAM ユーザーガイドの「サービスにリンクされたロールのアクセス許可」を参照してください。

Amazon EKS のサービスにリンクされたロールの作成

サービスにリンクされたロールを手動で作成する必要はありません。AWS マネジメントコンソール、AWS CLI、または AWS API で CreateNodegroup を行うと、サービスにリンクされたロールがAmazon EKS で自動的に作成されます。

Important

このサービスにリンクされたロールがアカウントに表示されるのは、このロールでサポートされている機能を使用する別のサービスでアクションが完了した場合です。 Amazon EKS を January1, 2017 より前に使用していた場合は、サービスにリンクされたロールのサポートが開始された時点で、Amazon EKS によって AWSServiceRoleForAmazonEKSNodegroup ロールがアカウントに作成されています。詳細については、「IAM アカウントに新しいロールが表示される」を参照してください。

Amazon EKS でのサービスにリンクされたロールの作成 (AWS API)

サービスにリンクされたロールを手動で作成する必要はありません。AWS マネジメントコンソール、AWS CLI、または AWS API でマネージド型ノードグループを作成すると、Amazon EKS によってサービスリンクロールが作成されます。

このサービスにリンクされたロールを削除した後で再度作成する必要が生じた場合は、同じ方法でアカウントにロールを再作成できます。別のマネージド型ノードグループを作成すると、 Amazon EKS によってサービスリンクロールが再度作成されます。

Amazon EKS のサービスにリンクされたロールの編集

Amazon EKS では、AWSServiceRoleForAmazonEKSNodegroup サービスにリンクされたロールを編集することはできません。サービスにリンクされたロールを作成すると、多くのエンティティによってロールが参照される可能性があるため、ロール名を変更することはできません。ただし、IAM を使用したロールの説明の編集はできます。詳細については、IAM ユーザーガイドの「サービスにリンクされたロールの編集」を参照してください。

Amazon EKS のサービスにリンクされたロールの削除

サービスにリンクされたロールが必要な機能またはサービスが不要になった場合には、そのロールを削除することをお勧めします。そうすることで、使用していないエンティティがアクティブにモニタリングされたり、メンテナンスされたりすることがなくなります。ただし、手動で削除する前に、サービスにリンクされたロールをクリーンアップする必要があります。

257

https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSServiceRoleForAmazonEKSNodegroup%24jsonEditor

https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions

https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared



Amazon EKS ユーザーガイドクラスターの IAM ロール

サービスにリンクされたロールのクリーンアップ

IAM を使用してサービスにリンクされたロールを削除するには、最初に、そのロールで使用されているリソースをすべて削除する必要があります。

Note

リソースを削除する際に、Amazon EKS サービスでロールが使用されている場合、削除は失敗することがあります。失敗した場合は、数分待ってから再度オペレーションを実行してください。

AWSServiceRoleForAmazonEKSNodegroup で使用されている Amazon EKS リソースを削除するには

1. Open the Amazon EKS console at https://console.aws.amazon.com/eks/home#/clusters.2. クラスターを選択します。3. [クラスター] ページで、[ノードグループ] セクションにマネージド型ノードグループがある場合、そ

れぞれを個別に選択し、[削除] を選択します。4. 削除確認ウィンドウにクラスターの名前を入力し、[確認] を選択して削除します。5. クラスター内のその他のノードグループと、アカウント内のその他のクラスターについて、この手順

を繰り返します。

サービスにリンクされたロールを手動で削除する

IAM コンソール、AWS CLI、AWS API を使用して、AWSServiceRoleForAmazonEKSNodegroup サービスにリンクされたロールを削除します。詳細については、IAM ユーザーガイドの「サービスにリンクされたロールの削除」を参照してください。

Amazon EKS サービスにリンクされたロールがサポートされるリージョン

Amazon EKS は、サービスを利用できるすべてのリージョンで、サービスにリンクされたロールの使用をサポートします。詳細については、「Amazon EKS Service Endpoints and Quotas」を参照してください。

Amazon EKS クラスターの IAM ロールAmazon EKS によって管理される Kubernetes クラスターは、ユーザーに代わって他の AWS のサービスを呼び出し、サービスで使用するリソースを管理します。Amazon EKS クラスターを使用するには、次のIAM ポリシーを持つ IAM ロールを作成する必要があります。

• AmazonEKSClusterPolicy

Note

2020 年 4 月 16 日までは、AmazonEKSServicePolicy も必須であり、推奨される名前はeksServiceRole でした。AWSServiceRoleForAmazonEKS サービスにリンクされたロールでは、このポリシーは必須でなくなりました。

既存のクラスターロールの確認次の手順を使用して、アカウントにすでに Amazon EKS クラスタースロールがあるかどうかを確認できます。

IAM コンソールで eksClusterRole を確認するには

1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。

258





https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AmazonEKSClusterPolicy%24jsonEditor

https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AmazonEKSServicePolicy%24jsonEditor


Amazon EKS ユーザーガイドクラスターの IAM ロール

2. ナビゲーションペインで [ロール] を選択します。3. ロールのリストで eksClusterRole を検索します。eksClusterRole が含まれているロールが存

在しない場合は、「Amazon EKS クラスターロールの作成 (p. 259)」を参照してロールを作成します。eksClusterRole が含まれているロールが存在する場合は、このロールを選択してアタッチされているポリシーを表示します。

4. [アクセス許可] を選択します。5. AmazonEKSClusterPolicy 管理ポリシーがロールにアタッチされていることを確認します。ポリシー

がアタッチされている場合、Amazon EKS クラスターロールは適切に設定されています。6. [信頼関係]、[信頼関係の編集] を選択します。7. 信頼関係に以下のポリシーが含まれていることを確認します。信頼関係が以下のポリシーと一致する

場合、[Cancel] を選択します。信頼関係が一致しない場合、ポリシーを [Policy Document] ウィンドウにコピーし、[Update Trust Policy] を選択します。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "eks.amazonaws.com" }, "Action": "sts:AssumeRole" } ]}

Amazon EKS クラスターロールの作成アカウントにクラスターロールがまだない場合は、AWS マネジメントコンソールまたは AWSCloudFormation を使用して作成できます。ロールの作成に使用するツールの名前を選択します。


IAM コンソールで Amazon EKS クラスターロールを作成するには

1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。2. [ロール] を選択してから [ロールの作成] を選びます。3. サービスのリストから [EKS] を選択し、ユースケースに合った [EKS - Cluster (EKS - クラス

ター)] を選択して、[Next: Permissions (次へ: アクセス許可)] を選択します。4. [次へ: タグ] を選択します。5. (オプション) タグをキーと値のペアとしてアタッチして、メタデータをロールに追加しま


6. [Next: Review] を選択します。7. [ロール名] に、ロールの一意の名前 (eksClusterRole など) を入力し、[ロールの作成] を選択し

ます。

AWS CloudFormation

AWS CloudFormation で Amazon EKS クラスターロールを作成するには

1. 以下の AWS CloudFormation テンプレートをローカルシステムのテキストファイルに保存します。

259




Amazon EKS ユーザーガイドワーカーノード IAM ロール

---AWSTemplateFormatVersion: '2010-09-09'Description: 'Amazon EKS Cluster Role'

Resources:

eksClusterRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Principal: Service: - eks.amazonaws.com Action: - sts:AssumeRole ManagedPolicyArns: - arn:aws:iam::aws:policy/AmazonEKSClusterPolicy

Outputs:

RoleArn: Description: The role that Amazon EKS will use to create AWS resources for Kubernetes clusters Value: !GetAtt eksClusterRole.Arn Export: Name: !Sub "${AWS::StackName}-RoleArn"

Note

2020 年 4 月 16 日までは、ManagedPolicyArns にarn:aws:iam::aws:policy/AmazonEKSServicePolicy のエントリがありました。AWSServiceRoleForAmazonEKS サービスにリンクされたロールでは、このポリシーは必須でなくなりました。

2. AWS CloudFormation コンソール (https://console.aws.amazon.com/cloudformation) を開きます。3. [スタックの作成] を選択します。4. [テンプレートの指定] で、[テンプレートファイルのアップロード] を選択し、[ファイルの選択] を

選択します。5. 作成したファイルを選択し、[Next (次へ)] を選択します。6. [スタックの名前] に eksClusterRole などのロール名を入力し、[次へ] を選択します。7. [スタックオプションの設定] ページで、[Next (次へ)] を選択します。8. [Review (レビュー)] ページで、情報を確認して、スタックで IAM リソースが作成されることを認

識し、[スタックの作成] を選択します。

Amazon EKS ワーカーノード IAM ロールAmazon EKS ワーカーノード kubelet デーモンは、ユーザーに代わって AWS API への呼び出しを実行します。ワーカーノードは、IAM インスタンスプロファイルおよび関連ポリシーを通じて、これらの APIコールのアクセス許可を受け取ります。ワーカーノードを起動してクラスターに登録する前に、起動するときに使用するワーカーノード用の IAM ロールを作成する必要があります。この要件は Amazon が提供する Amazon EKS 最適化 AMI、または使用する予定の他のワーカーノード AMI で起動したワーカーノードに適用されます。ワーカーノードを使用するには、次の IAM ポリシーを持つ IAM ロールを作成する必要があります。

260


Amazon EKS ユーザーガイドワーカーノード IAM ロール

• AmazonEKSWorkerNodePolicy

• AmazonEKS_CNI_Policy

• AmazonEC2ContainerRegistryReadOnly

既存のワーカーノードロールの確認以下の手順を使用して、アカウントにすでに Amazon EKS ワーカーノードロールがあるかどうかを確認できます。

IAM コンソールで NodeInstanceRole を確認するには

1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。2. ナビゲーションペインで [Roles (ロール) ] を選択します。3. ロールのリストで NodeInstanceRole を検索します。NodeInstanceRole を含むロールがない場

合は、「Amazon EKS ワーカーノード IAM ロールの作成 (p. 261)」を参照してロールを作成します。NodeInstanceRole を含むロールがある場合は、ロールを選択して、アタッチされたポリシーを表示します。

4. [アクセス許可] を選択します。5. AmazonEKSWorkerNodePolicy、AmazonEKS_CNI_Policy、および

AmazonEC2ContainerRegistryReadOnly 管理ポリシーがロールにアタッチされていることを確認します。ポリシーがアタッチされている場合、Amazon EKS ワーカーノードロールは適切に設定されています。

6. [信頼関係]、[信頼関係の編集] を選択します。7. 信頼関係に以下のポリシーが含まれていることを確認します。信頼関係が以下のポリシーと一致する


{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action": "sts:AssumeRole" } ]}

Amazon EKS ワーカーノード IAM ロールの作成「AWS マネジメントコンソールの使用開始 (p. 10)」または「eksctl の開始方法 (p. 3)」トピックの手順に従ってワーカーノードを作成した場合、ワーカーノードのロールはすでにあるため、手動で作成する必要はありません。アカウントに Amazon EKS ワーカーノードロールがまだない場合は、AWS マネジメントコンソールまたは AWS CloudFormation を使用してそのロールを作成できます。ロールの作成に使用するツールの名前を選択します。


IAM コンソールで Amazon EKS ワーカーノードロールを作成するには

1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。2. [ロール] を選択してから [ロールの作成] を選びます。

261

https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy%24jsonEditor

https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy%24jsonEditor

https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly%24jsonEditor



Amazon EKS ユーザーガイドポッド実行ロール

3. サービスのリストから [EC2] を選択し、[Next: Permissions (次へ: アクセス許可)] を選択します。4. [Filter policies (フィルタポリシー)] ボックスに「AmazonEKSWorkerNodePolicy」と入力しま

す。[AmazonEKSWorkerNodePolicy] の左側にあるチェックボックスをオンにします。5. [Filter policies (フィルタポリシー)] ボックスに「AmazonEKS_CNI_Policy」と入力します。

[AmazonEKS_CNI_Policy] の左側にあるチェックボックスをオンにします。6. [Filter policies (フィルタポリシー)] ボックスに「AmazonEC2ContainerRegistryReadOnly」

と入力します。[AmazonEC2ContainerRegistryReadOnly] の左側にあるチェックボックスをオンにします。

7. [次へ: タグ] を選択します。8. (オプション) タグをキーと値のペアとしてアタッチして、メタデータをロールに追加しま


9. [Next: Review] を選択します。10. [ロール名] にロールの一意の名前 (NodeInstanceRole など) を入力します。[ロールの説明]

で、現在のテキストを「Amazon EKS - Node Group Role」などの説明テキストに置き換え、[ロールの作成] を選択します。

AWS CloudFormation

AWS CloudFormation を使用して Amazon EKS ワーカーノードロールを作成するには

1. AWS CloudFormation コンソール (https://console.aws.amazon.com/cloudformation) を開きます。2. [スタックの作成] を選択し、[With new resources (standard) 新しいリソースを使用 (標準)] を選択

します。3. [Specify template (テンプレートを指定)] で、[Amazon S3 URL] を選択します。4. 以下の URL を [Amazon S3 URL] テキストエリアに貼り付け、[Next (次へ)] を選択します。

https://amazon-eks.s3.us-west-2.amazonaws.com/cloudformation/2020-04-21/amazon-eks-nodegroup-role.yaml

5. [Specify stack details (スタックの詳細の指定)] ページで、[スタックの名前] に「eks-node-group-instance-role」などの名前を入力し、[Next (次へ)] を選択します。

6. (オプション) [Configure stack options (スタックオプションの設定)] ページで、スタックリソースをタグ付けできます。[次へ] を選択します。

7. [確認] ページで、[機能] セクションのチェックボックスをオンにして、[スタックの作成] を選択します。

8. スタックが作成されたら、コンソールで選択し、[出力] を選択します。9. 作成された IAM ロールの [NodeInstanceRole] 値を記録します。これは、ノードグループを作成

するときに必要です。

ポッド実行ロールAmazon EKS ポッド実行ロールは、ポッドを AWS Fargate インフラストラクチャで実行するために必要です。

クラスターが AWS Fargate インフラストラクチャにポッドを作成する場合、ポッドはユーザーに代わって AWS API を呼び出す必要があります。たとえば、Amazon ECR からコンテナーイメージをプルします。Amazon EKS ポッド実行ロールは、これを行うための IAM アクセス許可を提供します。

Fargate プロファイルを作成するときは、ポッドで使用するポッド実行ロールを指定する必要があります。このロールは、承認のためにクラスターの Kubernetes ロールベースのアクセスコントロール (RBAC)に追加され、Fargate インフラストラクチャで実行されている kubelet が Amazon EKS クラスターに登

262





Amazon EKS ユーザーガイドポッド実行ロール

録されます。これにより、Fargate インフラストラクチャがクラスター内でノードとして表示されるようになります。

Fargate プロファイルを作成する前に、次の IAM ポリシーで IAM ロールを作成する必要があります。

• AmazonEKSFargatePodExecutionRolePolicy

既存のポッド実行ロールの確認以下の手順を使用して、アカウントにすでに Amazon EKS ポッド実行ロールがあるかどうかを確認できます。

IAM コンソールで AmazonEKSFargatePodExecutionRole を確認するには

1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。2. ナビゲーションペインで [Roles (ロール) ] を選択します。3. ロールのリストで AmazonEKSFargatePodExecutionRole を検索します。ロールが存在しない場

合は、「Amazon EKS ポッド実行ロールの作成 (p. 263)」を参照してロールを作成します。ロールが存在する場合は、そのロールを選択して、アタッチされているポリシーを表示します。

4. [Permissions] を選択します。5. AmazonEKSFargatePodExecutionRolePolicy Amazon マネージドポリシーがロールにアタッチされて

いることを確認します。ポリシーがアタッチされている場合、Amazon EKS ポッド実行ロールは適切に設定されています。

6. [Trust Relationship]、[Edit Trust Relationship] を選択します。7. 信頼関係に以下のポリシーが含まれていることを確認します。信頼関係が以下のポリシーと一致する


{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "eks-fargate-pods.amazonaws.com" }, "Action": "sts:AssumeRole" } ]}

Amazon EKS ポッド実行ロールの作成以下の手順を使用して、アカウントにまだ Amazon EKS ポッド実行ロールがない場合、作成することができます。

1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。2. [ロール] を選択してから [ロールの作成] を選びます。3. サービスのリストから [EKS] を選択し、ユースケースに合った [EKS - Fargate ポッド] を選択して、

[Next: Permissions (次へ: アクセス許可)] を選択します。4. [次へ: タグ] を選択します。5. (オプション) タグをキーと値のペアとしてアタッチして、メタデータをロールに追加します。IAM で

のタグの使用の詳細については、『IAM ユーザーガイド』の IAM エンティティのタグ付けを参照してください。

263

https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AmazonEKSFargatePodExecutionRolePolicy%24jsonEditor




Amazon EKS ユーザーガイドサービスアカウントの IAM ロール

6. [Next: Review] を選択します。7. [Role name (ロール名)] に、ロールの一意の名前 (例: AmazonEKSFargatePodExecutionRole) を入

力し、[ロールの作成] を選択します。

サービスアカウントの IAM ロールAmazon EKS クラスターのサービスアカウントの IAM ロールを使用すると、 IAM ロールを Kubernetesサービスアカウントに関連付けることができます。このサービスアカウントは、そのサービスアカウントを使用するポッドのコンテナ AWS にアクセス許可を提供できます。この機能を使用すると、ワーカーノード IAM ロールに拡張されたアクセス許可を提供する必要がなくなり、そのノードのポッドが AWSAPI を呼び出せるようになります。

アプリケーションは AWS 認証情報で AWS API リクエストに署名する必要があります。この機能により、Amazon EC2 インスタンスプロファイルで Amazon EC2 インスタンスに認証情報を提供するのと類似した方法で、アプリケーションで使用される認証情報を管理する方法が提供されます。AWS 認証情報を作成してコンテナに配布したり、Amazon EC2 インスタンスのロールを使用したりする代わりに、IAM ロールを Kubernetes サービスアカウントと関連付けることができます。ポッドのコンテナにあるアプリケーションは、AWS SDK または AWS CLI を使用して権限付与された AWS のサービスへの API リクエストを実行できます。

サービスアカウントの IAM ロール機能には、次の利点があります。

• 最小権限サービスアカウントの IAM ロール機能 —を使用すると、ワーカーノード IAM ロールに拡張されたアクセス許可を提供する必要がなくなり、そのノードのポッドが AWS API を呼び出せるようになります。IAM アクセス許可の範囲をサービスアカウントに設定でき、そのサービスアカウントを使用するポッドのみがアクセス許可にアクセスできます。また、この機能により、kiam や kube2iam などのサードパーティーのソリューションが不要になります。

• 認証情報の隔離— コンテナは、それが属するサービスアカウントに関連付けられている IAM ロールの認証情報のみを取得できます。コンテナは、別のポッドに属する別のコンテナを対象とした認証情報にアクセスすることはできません。

• 監査性— 遡及的な監査を確実に行うため、CloudTrail を介してアクセスとイベントのロギングを利用できます。

開始するには、クラスターでのサービスアカウントの IAM ロールの有効化 (p. 268) を参照してください。

eksctl を使用したエンドツーエンドのチュートリアルについては、「チュートリアル: サービスアカウントに IAM を使用するように DaemonSet を更新する (p. 275)」を参照してください。

サービスアカウントの技術概要の IAM ロール2014 年に、OpenID Connect (OIDC) を使用したフェデレーティッドアイデンティティのサポート AWSIdentity and Access Management が追加されました。この機能により、サポートされている ID プロバイダーで AWS API コールを認証し、有効な OIDC JSON ウェブトークン (JWT) を受け取ることができます。このトークンを AWS STS AssumeRoleWithWebIdentity API オペレーションに渡し、 IAM一時的なロールの認証情報を受け取ることができます。これらの認証情報を使用して、Amazon S3 やDynamoDB などの任意の AWS サービスとやり取りできます。

Kubernetes は、独自の内部 ID システムとして長い間、サービスアカウントを使用してきました。ポッドは、Kubernetes API サーバーのみが検証できる自動マウントトークン（OIDC JWT ではない）を使用してKubernetes API サーバーで認証できます。これらのレガシーサービスアカウントトークンは期限切れにならず、署名キーの更新は難しいプロセスです。Kubernetes バージョン 1.12 では、サービスアカウント IDを含む OIDC JSON ウェブトークンである新しい ProjectedServiceAccountToken 機能のサポートが追加され、設定可能な対象者がサポートされます。

264


Amazon EKS は、ProjectedServiceAccountToken JSON ウェブトークンの署名キーを含むクラスターごとにパブリック OIDC 検出エンドポイントをホストするようになり、IAM などの外部システムがKubernetes によって発行された OIDC トークンを検証して受け入れることができるようになりました。

IAM ロールの設定

IAM では、クラスターの OIDC プロバイダー、サービスアカウント名前空間、および（オプションで）サービスアカウント名に限定された信頼関係を持つ IAM ロールを作成し、サービスアカウントに関連付ける IAM ポリシーをアタッチします。以下の StringEquals および StringLike 条件に複数のエントリを追加して、ロールで複数のサービスアカウントまたは名前空間を使用できます。

• ロールを特定のサービスアカウントに絞り出すには:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::AWS_ACCOUNT_ID:oidc-provider/OIDC_PROVIDER" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "OIDC_PROVIDER:sub": "system:serviceaccount:SERVICE_ACCOUNT_NAMESPACE:SERVICE_ACCOUNT_NAME" } } } ]}

• ロールを名前空間全体にスコープするには（名前空間を境界として使用するため）:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::AWS_ACCOUNT_ID:oidc-provider/OIDC_PROVIDER" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringLike": { "OIDC_PROVIDER:sub": "system:serviceaccount:SERVICE_ACCOUNT_NAMESPACE:*" } } } ]}

サービスアカウント設定

Kubernetes では、eks.amazonaws.com/role-arn 注釈をサービスアカウントに追加することで、クラスター内のサービスアカウントに関連付ける IAM ロールを定義します。

apiVersion: v1kind: ServiceAccountmetadata:

265


annotations: eks.amazonaws.com/role-arn: arn:aws:iam::AWS_ACCOUNT_ID:role/IAM_ROLE_NAME

ポッドの設定

クラスターの Amazon EKSPod Identity Webhook は、この注釈を持つサービスアカウントに関連付けられているポッドを監視し、以下の環境変数をそれらに適用します。

AWS_ROLE_ARN=arn:aws:iam::AWS_ACCOUNT_ID:role/IAM_ROLE_NAMEAWS_WEB_IDENTITY_TOKEN_FILE=/var/run/secrets/eks.amazonaws.com/serviceaccount/token

Note

クラスターでは、環境変数とトークンファイルのマウントを設定するために、mutating なウェブフックを使用する必要はありません。これらの環境変数を手動で追加するようにポッドを設定できます。

SDK のサポートされているバージョンAWS (p. 268)は、最初に認証情報チェーンプロバイダーでこれらの環境変数を探します。ロールの認証情報は、この条件を満たすポッドに使用されます。

Note

ポッドがサービスアカウントに関連付けられた IAM ロールの AWS 認証情報を使用する場合、AWS CLI またはそのポッドのコンテナ内の他の SDK は、そのロールによって提供される認証情報を排他的に使用します。ワーカーノード IAM ロールから任意の IAM アクセス許可を継承しなくなりました。

デフォルトでは、root として実行されるコンテナにのみ、Web ID トークンファイルを読み取るための適切なファイルシステムアクセス許可があります。コンテナを root として実行するか、マニフェスト内のコンテナに以下のセキュリティコンテキストを渡すことで、これらのアクセス許可を付与できます。fsGroup ID は任意であり、いずれかの有効なグループ ID を選択できます。ポッドにセキュリティコンテキストを設定することの意味の詳細については、Kubernetes ドキュメントの「Configure a SecurityContext for a Pod or Container」を参照してください。

apiVersion: apps/v1kind: Deploymentmetadata: name: my-appspec: template: metadata: labels: app: my-app spec: serviceAccountName: my-app containers: - name: my-app image: my-app:latest securityContext: fsGroup: 1337...

クロスアカウント IAM アクセス許可

クロスアカウントの IAM アクセス許可を設定するには、別のアカウントのクラスターから ID プロバイダーを作成するか、連鎖した AssumeRole オペレーションを使用します。次の例では、アカウント A は、サービスアカウントの IAM ロールをサポートする Amazon EKS クラスターを所有しています。そのクラスターで実行されているポッドは、アカウント B の IAM アクセス許可を引き受ける必要があります。

266

https://github.com/aws/amazon-eks-pod-identity-webhook

https://kubernetes.io/docs/tasks/configure-pod-container/security-context/

https://kubernetes.io/docs/tasks/configure-pod-container/security-context/


Example : 別のアカウントのクラスターから ID プロバイダーを作成する

Example

この例では、アカウント A はアカウント B にクラスターからの OIDC 発行者 URL を提供します。アカウント B は、アカウント A のクラスターからの OIDC 発行者 URL を使用して、クラスターでのサービスアカウントの IAM ロールの有効化 (p. 268) およびサービスアカウントの IAM ロールとポリシーの作成 (p. 270) の手順に従います。次に、クラスター管理者は、アカウント A のクラスターのサービスアカウントに注釈を付けて、アカウント B のロールを使用します。

apiVersion: v1kind: ServiceAccountmetadata: annotations: eks.amazonaws.com/role-arn: arn:aws:iam::ACCOUNT_B_AWS_ACCOUNT_ID:role/IAM_ROLE_NAME

Example : 連鎖された AssumeRole オペレーションを使用する

Example

この例では、アカウント B は、アカウント A のクラスターのポッドに付与するアクセス許可を持つ IAMポリシーを作成します。アカウント B は、以下に示すように、アカウント A (111111111111) へのAssumeRole アクセス許可を許可する信頼関係を持つ IAM ロールにそのポリシーをアタッチします。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111111111111:root" }, "Action": "sts:AssumeRole", "Condition": {} } ]}

アカウント A は、次に示すように、クラスターの OIDC 発行者 URL で作成された ID プロバイダーから認証情報を取得する信頼ポリシーを持つロールを作成します。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::111111111111:oidc-provider/oidc.eks.region-code.amazonaws.com/id/EXAMPLEC061A78C479E31025A21AC4CDE191335D05820BE5CE" }, "Action": "sts:AssumeRoleWithWebIdentity" } ]}

アカウント A は、アカウント B が作成したロールを引き受けるための以下のアクセス許可を持つポリシーをそのロールにアタッチします。

{ "Version": "2012-10-17",

267


"Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::222222222222:role/account-b-role" } ]}

アカウント B のロールを引き受けるポッドのアプリケーションコードは、account_b_role とaccount_a_role の 2 つのプロファイルを使用します。account_b_role プロファイルでは、ソースとして account_a_role プロファイルを使用します。AWS CLI の場合、~/.aws/config ファイルは次の例のようになります。

[profile account_b_role]source_profile = account_a_rolerole_arn=arn:aws:iam::222222222222:role/account-b-role

[profile account_a_role]web_identity_token_file = /var/run/secrets/eks.amazonaws.com/serviceaccount/token role_arn=arn:aws:iam::111111111111:role/account-a-role

他の AWS SDK の連鎖されたプロファイルを指定するには、そのドキュメントを参照してください。

サポートされる AWS SDK の使用ポッド内のコンテナは、OIDC ウェブ ID トークンファイルを介して IAM ロールを引き受けることをサポートする AWS SDK バージョンを使用する必要があります。Linux ディストリビューションのパッケージマネージャーに含まれている AWS SDK は、この機能をサポートするのに十分なほど新しくない可能性があります。以下に示す最低限の SDK バージョンを使用してください。

• Java (バージョン 2) — 2.10.11• Java — 1.11.704• Go — 1.23.13• Python (Boto3) — 1.9.220• Python (botocore) — 1.12.200• AWS CLI — 1.16.232• Node — 2.521.0• Ruby — 2.11.345• C++ — 1.7.174• .NET — 3.3.659.1• PHP — 3.110.7

Cluster Autoscaler や ALB Ingress Controller など、一般的な Kubernetes アドオンの多くは、サービスアカウントの IAM ロールをサポートします。Kubernetes の CNI プラグインKubernetesの Amazon VPC CNIプラグインは、サポートされているバージョンの AWS SDK for Go で更新されています。サービスアカウントの IAM ロール機能を使用して、CNIが機能するために必要な権限を提供できます。

サポートされている SDK を使用していることを確認するには、コンテナを構築する際に、「アマゾンウェブサービスのツール」で、希望する SDK のインストール手順に従ってください。

クラスターでのサービスアカウントの IAM ロールの有効化サービスアカウントの IAM ロール機能は、新しい Amazon EKS Kubernetes バージョン 1.14 以降のおクラスター、および 2019 年 9 月 3 日以降にバージョン 1.13 に更新されたクラスターで利用できます。

268

https://github.com/aws/aws-sdk-java-v2/releases/tag/2.10.11

https://github.com/aws/aws-sdk-java/releases/tag/1.11.704

https://github.com/aws/aws-sdk-go/releases/tag/v1.23.13

https://github.com/boto/boto3/releases/tag/1.9.220

https://github.com/boto/botocore/releases/tag/1.12.200

https://github.com/aws/aws-cli/releases/tag/1.16.232

https://github.com/aws/aws-sdk-js/releases/tag/v2.521.0

https://github.com/aws/aws-sdk-ruby/releases/tag/v2.11.345

https://github.com/aws/aws-sdk-cpp/releases/tag/1.7.174

https://github.com/aws/aws-sdk-net/releases/tag/3.3.659.1

https://github.com/aws/aws-sdk-php/releases/tag/3.110.7


https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/CA_with_AWS_IAM_OIDC.md



https://aws.amazon.com/tools/

https://aws.amazon.com/tools/


既存のクラスターは、この機能を利用するために、バージョン 1.13 以降に更新できます。詳細については、Amazon EKS クラスターの Kubernetes バージョンの更新 (p. 29) を参照してください。

クラスターがサービスアカウントの IAM ロールをサポートしている場合、 OpenID Connect 発行者 URLが関連付けられます。この URL は、Amazon EKS コンソールで表示するか、次の AWS CLI コマンドを使用して取得できます。

Important

このコマンドで適切な出力を得るには、最低でも AWS CLI のバージョン 1.18.49 を使用する必要があります。詳細については、AWS Command Line Interface ユーザーガイドの「AWS CLI のインストール」を参照してください。

aws eks describe-cluster --name cluster_name --query "cluster.identity.oidc.issuer" --output text

出力:

https://oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E

クラスターでサービスアカウントの IAM ロールを使用するには、IAM コンソールで OIDC ID プロバイダーを作成する必要があります。

eksctl

eksctl を使用してクラスターの IAM OIDC ID プロバイダーを作成するには

1. 以下のコマンドを使用して、eksctl のバージョンを確認します。この手順では、eksctl をインストール済みで、お使いの eksctl バージョンが 0.19.0 以上であることを前提としています。

eksctl version


2. 次のコマンドを使用して、クラスターの OIDC ID プロバイダーを作成します。cluster_nameを独自の値に置き換えます。

eksctl utils associate-iam-oidc-provider --cluster cluster_name --approve


AWS マネジメントコンソールを使用してクラスターの IAM OIDC ID プロバイダーを作成するには

1. クラスターの Amazon EKS コンソールの説明から OIDC 発行者 URL を取得するか、次の AWSCLI コマンドを使用します。

Important



269

https://openid.net/connect/





2. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。3. ナビゲーションペインで、[ID プロバイダー] を選択し、[プロバイダーの作成] をクリックしま

す。4. [プロバイダーのタイプ] で [Choose a provider type] を選択してから、[OpenID Connect] を選択し

ます。5. Provider URL に、クラスターの OIDC 発行者 URL を貼り付けます。6. [対象者] に、「sts.amazonaws.com」と入力し、[次のステップ] を選択します。7. プロバイダー情報が正しいことを確認し、[作成] を選択して ID プロバイダーを作成します。

クラスターの IAM OIDC ID プロバイダーを有効にしたら、クラスター内のサービスアカウントに関連付ける IAM ロールを作成できます。詳細については、「サービスアカウントの IAM ロールとポリシーの作成 (p. 270)」を参照してください。

サービスアカウントの IAM ロールとポリシーの作成ポッド内のコンテナに付与するアクセス許可を指定する IAM ポリシーを作成する必要があります。IAMの新しい権限ポリシーを作成する方法は複数あります。目的の操作のいくつかをすでに実行できる完全なAWS 管理ポリシーをコピーし、特定の要件に応じてカスタマイズできます。詳細については、IAM ユーザーガイドの「新しいポリシーの作成」を参照してください。

また、Kubernetes サービスアカウントに関連付ける前に、サービスアカウントで使用する IAM ロールを作成する必要があります。信頼関係の範囲はクラスターとサービスアカウントに限定されるため、各クラスターとサービスアカウントの組み合わせには独自のロールが必要です。それから、ポッドのコンテナに必要なアクセス許可を付与するロールに特定の IAM ポリシーをアタッチできます。以下の手順でこれを行う方法について説明します。

IAM ポリシーの作成

この手順では、アプリケーションに使用できる 2 つのポリシーの例を示します。

• Amazon S3 バケットへの読み取り専用アクセスを許可するポリシー。このバケットに設定情報またはブートストラップスクリプトを保存できます。ポッドのコンテナは、バケットからファイルを読み取り、アプリケーションにロードできます。

• AWS Marketplace から有料コンテナイメージを許可するポリシー。

1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。2. ナビゲーションペインで、[Policies (ポリシー)] を選択し、[Create Policy (ポリシーの作成)] を選択し

ます。3. [JSON] タブを選択します。4. Policy Document フィールドに、サービスアカウントに適用する次のいずれかのポリシーを貼り付け

るか、独自のポリシードキュメントをフィールドに貼り付けます。ビジュアルエディタを使用して独自のポリシーを作成することもできます。

以下の例では、my-pod-secrets-bucket Amazon S3 バケットにアクセス許可を付与します。ポリシードキュメントを特定のニーズに応じて変更できます。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject"

270


https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html



], "Resource": [ "arn:aws:s3:::my-pod-secrets-bucket/*" ] } ]}

次の例では、AWS Marketplace から有料コンテナイメージを使用するために必要なアクセス許可を付与します。

{ "Version": "2012-10-17", "Statement": [ { "Action": [ "aws-marketplace:RegisterUsage" ], "Effect": "Allow", "Resource": "*" } ]}

5. [ポリシーの確認] を選択します。6. ポリシーの名前と説明を入力し、[ポリシーの作成]を選択します。7. 後でロールを作成するときに使用するポリシーの Amazon リソースネーム (ARN) を記録します。

IAM ロールを作成する

サービスアカウントの IAM ロールを作成します。ロールの作成に使用するツールの名前が付いているタブを選択します。

eksctl

次のコマンドを使用して、サービスアカウントと IAM ロールを作成します。example values の値は独自の値に置き換えます。

Note

このコマンドは、eksctl で作成したクラスターでのみ使用できます。eksctl でクラスターを作成していない場合は、AWS マネジメントコンソールまたは AWS CLI タブの手順を使用します。

eksctl create iamserviceaccount \ --name service_account_name \ --namespace service_account_namespace \ --cluster cluster_name \ --attach-policy-arn IAM_policy_ARN \ --approve \ --override-existing-serviceaccounts

IAM ロールを作成し、IAM ポリシーをアタッチした AWS CloudFormation テンプレートがデプロイされました。ロールは Kubernetes サービスアカウントに関連付けられました。


1. クラスターの Amazon EKS コンソールの説明から OIDC 発行者 URL を取得するか、次の AWSCLI コマンドを使用します。

271


Important



2. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。3. ナビゲーションペインで [ロール]、[ロールの作成] の順に選択します。4. [Select type of trusted entity (信頼されたエンティティの種類を選択)] セクションで、[Web identity

(ウェブ ID)] を選択します。5. [Choose a web identity provider (ウェブ ID プロバイダーを選択)] セクションで、次の操作を行い

ます。

1. [Identity provider (ID プロバイダー)] で、クラスターの URL を選択します。2. [Audience (対象者)] で [sts.amazonaws.com] を選択します。

6. [Next: Permissions (次へ: アクセス許可)] を選択します。7. [Attach Policy (ポリシーをアタッチする)] セクションで、サービスアカウントに使用するポリシー

を選択します。[次へ: タグ] を選択します。8. [Add tags (optional) (タグの追加 (オプション))] 画面で、アカウントのタグを追加できます。[次

へ: 確認] を選択します。9. [Role Name (ロール名)] にロール名を入力し、[Create Role (ロールの作成)] を選択します。10. ロールが作成されたら、コンソールでロールを選択して編集用に開きます。11. [信頼関係] タブを選択してから、[信頼関係の編集] を選択します。

1. OIDC プロバイダーのサフィックスを編集し、:aud から :sub に変更します。2. sts.amazonaws.com をサービスアカウント ID に置き換えます。

結果の行は次のようになります。

"oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E:sub": "system:serviceaccount:SERVICE_ACCOUNT_NAMESPACE:SERVICE_ACCOUNT_NAME"

12. [Update Trust Policy (信頼ポリシーの更新)] を選択して終了します。13. IAM ロールを Kubernetes サービスアカウントに関連付けます。詳細については、「サービスア

カウントの IAM ロールの指定 (p. 273)」を参照してください。

AWS CLI

1. 次のコマンドを使用して、AWS アカウント ID を環境変数に設定します。

AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query "Account" --output text)

2. 次のコマンドを使用して、OIDC ID プロバイダーを環境変数に設定します。クラスター名を置き換えます。

Important


272





OIDC_PROVIDER=$(aws eks describe-cluster --name cluster-name --query "cluster.identity.oidc.issuer" --output text | sed -e "s/^https:\/\///")

3. 次のコードブロックをコンピューターにコピーし、 namespace と service-account-name を独自の値に置き換えます。

read -r -d '' TRUST_RELATIONSHIP <<EOF{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::${AWS_ACCOUNT_ID}:oidc-provider/${OIDC_PROVIDER}" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "${OIDC_PROVIDER}:sub": "system:serviceaccount:namespace:service-account-name" } } } ]}EOFecho "${TRUST_RELATIONSHIP}" > trust.json

4. 前のステップで変更したコードブロックを実行して、trust.json という名前のファイルを作成します。

5. 次の AWS CLI コマンドを実行してロールを作成し、IAM ロール名と説明を置き換えます。

aws iam create-role --role-name IAM_ROLE_NAME --assume-role-policy-document file://trust.json --description "IAM_ROLE_DESCRIPTION"

6. 次のコマンドを実行して、IAM ロール名と ARN ポリシーを置き換えて、IAM ポリシーをロールにアタッチします。

aws iam attach-role-policy --role-name IAM_ROLE_NAME --policy-arn=IAM_POLICY_ARN

7. IAM ロールを Kubernetes サービスアカウントに関連付けます。詳細については、「サービスアカウントの IAM ロールの指定 (p. 273)」を参照してください。

サービスアカウントの IAM ロールの指定Kubernetes では、サービスアカウントに次の注釈を追加して、クラスター内のサービスアカウントに関連付ける IAM ロールを定義します。

Note

eksctl を使用してサービスアカウントで使用する IAM ロールを作成した場合、これはロールの作成時に指定したサービスアカウントですでに実行されています。

apiVersion: v1kind: ServiceAccountmetadata: annotations:

273


eks.amazonaws.com/role-arn: arn:aws:iam::AWS_ACCOUNT_ID:role/IAM_ROLE_NAME

IAM ロールで使用するためにサービスアカウントにパッチを適用するには

1. 次のコマンドを使用して、サービスアカウントで使用する IAM ロールの ARN でサービスアカウントに注釈を付けます。ポッドで使用する alternate-colored のサンプル値は、必ず独自の値に置き換えてください。

kubectl annotate serviceaccount -n SERVICE_ACCOUNT_NAMESPACE SERVICE_ACCOUNT_NAME \eks.amazonaws.com/role-arn=arn:aws:iam::AWS_ACCOUNT_ID:role/IAM_ROLE_NAME

2. 認証情報環境変数を適用するために、サービスアカウントに関連付けられている既存のポッドを削除して再作成します。変更ウェブフックは、すでに実行されているポッドには適用されません。次のコマンドは、既存の aws-node DaemonSet ポッドを削除し、サービスアカウントの注釈を使用してデプロイします。名前空間、デプロイタイプ、およびラベルを変更して、特定のポッドを更新できます。

kubectl delete pods -n kube-system -l k8s-app=aws-node

3. ポッドがすべて再起動したことを確認します。

kubectl get pods -n kube-system -l k8s-app=aws-node

4. ポッドの 1 つについて説明し、AWS_WEB_IDENTITY_TOKEN_FILE および AWS_ROLE_ARN 環境変数が存在することを確認します。

kubectl exec -n kube-system aws-node-9rgzw env | grep AWS

出力:

AWS_VPC_K8S_CNI_LOGLEVEL=DEBUGAWS_ROLE_ARN=arn:aws:iam::AWS_ACCOUNT_ID:role/IAM_ROLE_NAMEAWS_WEB_IDENTITY_TOKEN_FILE=/var/run/secrets/eks.amazonaws.com/serviceaccount/token

IAM ロールは、前のステップで Kubernetes サービスアカウントを作成したときに、eksctl によって作成されました。

Amazon EC2 インスタンスプロファイルの認証情報へのアクセスの制限デフォルトでは、ワーカーノードで実行されているすべてのコンテナには、ワーカーノードにアタッチされている ??? (p. 260) に割り当てられたすべてのアクセス許可があります。Amazon EC2 インスタンスメタデータサービスは、インスタンスで実行されているプロセスに認証情報を提供します。詳細については、「インスタンスメタデータからのセキュリティ認証情報の取得」を参照してください。

Pod のサービスアカウントの IAM ロールを実装すると、Pod のコンテナには、サービスアカウントとワーカーノード IAM ロールに割り当てられたすべてのアクセス許可が割り当てられます。クラスター内のすべての Pod に対してサービスアカウントの IAM ロールを実装する場合、Pod 内のコンテナがワーカーノード IAM ロールに割り当てられたアクセス許可を使用しないようにすることができます。ただし、Pod が機能する必要があるワーカーノード IAM ロールには、特定のキーのアクセス許可がある可能性があることに注意してください。Pod が必要なすべてのアクセス許可を持つように、サービスアカウントの IAM ロールを適切にスコープすることが重要です。たとえば、ワーカーノード IAM ロールには、Amazon ECR からコンテナイメージをプルするためのアクセス許可が割り当てられます。Pod にこれらのアクセス許可が割り当てられていない場合、Pod は Amazon ECR からコンテナイメージを取得できません。

274

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#instance-metadata-security-credentials


ワーカーノード上のすべての Pod のすべてのコンテナが、ワーカーノード IAM ロールに割り当てられたアクセス許可を使用しないようにするには (サービスアカウントに割り当てられたアクセス権限は引き続き許可します)、ワーカーノードで次の iptables コマンドを実行するか (rootとして)、インスタンスブートストラップユーザーデータスクリプトを含めます。

Important

これらのコマンドは、ワーカーノードで実行されているすべてのコンテナが、ワーカーノードIAM ロールの認証情報だけでなく、インスタンスメタデータサービスにメタデータクエリを実行するのを完全にブロックします。サービスアカウントの IAM ロールを実装していない Pod を実行するワーカーノードでは、これらのコマンドを実行しないでください。実装すると、ノード上のどのコンテナもワーカーノード IAM ロールに割り当てられたアクセス許可を持たなくなります。

yum install -y iptables-servicesiptables --insert FORWARD 1 --in-interface eni+ --destination 169.254.169.254/32 --jump DROPiptables-save | tee /etc/sysconfig/iptables systemctl enable --now iptables

チュートリアル: サービスアカウントに IAM を使用するようにDaemonSet を更新するAmazon VPC CNI plugin for Kubernetes は、Amazon EKS クラスター内のポッドネットワーキング用のネットワーキングプラグインです。CNI プラグインは、Kubernetes ノードに VPC IP アドレスを割り当て、各ノードのポッドに必要なネットワークを設定します。このプラグインでは、ユーザーに代わってAWS API を呼び出すために、AWS 管理ポリシー AmazonEKS_CNI_Policy によって提供される IAM アクセス許可が必要です。デフォルトでは、このポリシーはワーカーノード IAM ロールにアタッチされます。ただし、この方法を使用すると、ワーカーノードのすべてのポッドは CNI プラグインと同じアクセス許可を持ちます。サービスアカウント機能の IAM ロールを使用して AmazonEKS_CNI_Policy アクセス許可を付与してから、ワーカーノード IAM ロールからポリシーを削除できます。

使いやすさにより、このトピックでは eksctl を使用してサービスアカウントに IAM ロールを設定します。ただし、AWS マネジメントコンソール、AWS CLI、または AWS SDK のいずれかを使用する場合、同じ基本概念が適用されますが、クラスターでのサービスアカウントの IAM ロールの有効化 (p. 268) の手順を使用するためのステップを変更する必要があります。

サービスアカウントの IAM ロールを使用するように CNI プラグインを設定するには

1. 以下のコマンドを使用して、eksctl のバージョンを確認します。この手順では、eksctl をインストール済みで、お使いの eksctl バージョンが 0.19.0 以上であることを前提としています。

eksctl version


2. クラスターの Amazon VPC CNI Plugin for Kubernetes のバージョンを確認します。次のコマンドを使用して、クラスターの CNI バージョンを出力します。


出力:


275





CNI バージョンが 1.6.1 以前である場合は、次のステップを実行してサービスアカウントを作成し、CNI バージョンを最新バージョンにアップグレードします。

a. 次のコマンドを使用して、クラスターの OIDC ID プロバイダーを作成します。クラスター名を独自の値に置き換えます。

eksctl utils associate-iam-oidc-provider --cluster cluster_name --approve

b. 次のコマンドを使用して、Kubernetes サービスアカウントを作成します。cluster_name を独自の値に置き換えます。このコマンドは、IAM ロールを作成し、AmazonEKS_CNI_Policy AWSマネージド型ポリシーをそのロールにアタッチして、IAM ロールをサービスアカウントにバインドする AWS CloudFormation スタックをデプロイします。

eksctl create iamserviceaccount \ --name aws-node \ --namespace kube-system \ --cluster cluster_name \ --attach-policy-arn arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy \ --approve \ --override-existing-serviceaccounts

c. CNI バージョンを最新バージョンにアップグレードします。マニフェストは、前のステップで作成した aws-node サービスアカウントを指定します。


3. ロールアウトを監視し、デプロイの DESIRED 数が UP-TO-DATE 数と一致するのを待ちます。Ctrl+cを押して、終了します。

kubectl get -n kube-system daemonset.apps/aws-node --watch

4. aws-node DaemonSet 内の Pod を一覧表示します。

kubectl get pods -n kube-system -l k8s-app=aws-node

出力:

NAME READY STATUS RESTARTS AGEaws-node-mp88b 1/1 Running 0 17maws-node-n4tcd 1/1 Running 0 20saws-node-qt9dl 1/1 Running 0 17m

5. クラスターの Amazon VPC CNI Plugin for Kubernetes のバージョンを再確認し、バージョンが 1.6.1であることを確かめます。


出力:


6. ポッドの 1 つについて説明し、AWS_WEB_IDENTITY_TOKEN_FILE および AWS_ROLE_ARN 環境変数が存在することを確認します。

276

Amazon EKS ユーザーガイドトラブルシューティング

kubectl exec -n kube-system aws-node-9rgzw env | grep AWS

出力:

AWS_VPC_K8S_CNI_LOGLEVEL=DEBUGAWS_ROLE_ARN=arn:aws:iam::111122223333:role/eksctl-prod-addon-iamserviceaccount-kube-sys-Role1-V66K5I6JLDGKAWS_WEB_IDENTITY_TOKEN_FILE=/var/run/secrets/eks.amazonaws.com/serviceaccount/token

IAM ロールは、前のステップで Kubernetes サービスアカウントを作成したときに、eksctl によって作成されました。

7. AmazonEKS_CNI_Policy ポリシーをワーカーノード IAM ロールから削除します。

a. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。b. 左のナビゲーションで、[ロール] を選択し、ノードインスタンスロールを検索します。c. ノードインスタンスロールの [アクセス許可] タブを選択し、AmazonEKS_CNI_Policy の右側に

ある [X] を選択します。d. [デタッチ] を選択して終了します。

これで、CNI プラグインポッドは独自のロールから IAM アクセス許可を取得しており、インスタンスロールはこれらのアクセス許可を他のポッドに提供できなくなりました。

Amazon EKS Identity and Access のトラブルシューティングAmazon EKS および IAM を操作するときに発生する可能性のある一般的な問題を診断して修正する方法については、「IAM のトラブルシューティング (p. 303)」を参照してください。

Amazon EKS でのログ記録とモニタリングAmazon EKS コントロールプレーンのログ記録は、Amazon EKS コントロールプレーンからアカウントのCloudWatch Logs に直接監査および診断ログを提供します。これらのログを使用すると、クラスターの保護と実行が容易になります。CloudWatch の Amazon EKS クラスターごとに、必要なログタイプを選択することができ、ログがログストリームとしてグループに送信されます。詳細については、「Amazon EKSコントロールプレーンのログ記録 (p. 42)」を参照してください。

Note

Amazon CloudWatch で Amazon EKS 認証ログをチェックすると、次のサンプルテキストのようなテキストを含むエントリが表示されます。

level=info msg="mapping IAM role" groups="[]" role="arn:aws:iam::111122223333:role/XXXXXXXXXXXXXXXXXX-NodeManagerRole-XXXXXXXX" username="eks:node-manager"

このテキストを含むエントリが必要です。username は、マネージド型ノードグループとFargate の特定のオペレーションを実行する Amazon EKS 内部サービスロールです。

Amazon EKS は、AWS CloudTrail と統合されています。このサービスは、Amazon EKS でユーザーやロール、または AWS サービスによって実行されたアクションを記録するサービスです。CloudTrailは、Amazon EKS のすべての API コールをイベントとしてキャプチャします。キャプチャされた呼び出しには、Amazon EKS コンソールの呼び出しと、Amazon EKS API オペレーションへのコード呼び出しが含

277




Amazon EKS ユーザーガイドコンプライアンス検証

まれます。詳細については、「AWS CloudTrail による Amazon EKS API コールのログ記録 (p. 289)」を参照してください。

Kubernetes API サーバーは、モニタリングと分析に役立つ多数のメトリクスを公開します。詳細については、「??? (p. 212)」を参照してください。

Amazon EKS のコンプライアンス検証サードパーティーの監査者は、複数の Amazon EKS コンプライアンスプログラムの一環として AWS のセキュリティとコンプライアンスを評価します。このプログラムには、SOC、PCI、ISO、HIPAA などがあります。

特定のコンプライアンスプログラムの範囲内の AWS サービスのリストについては、「コンプライアンスプログラムによる AWS 対象範囲内のサービス」を参照してください。一般的な情報については、「AWSコンプライアンスプログラム」を参照してください。

サードパーティーの監査レポートをダウンロードするには、AWS Artifact を使用します。詳細については、「AWS Artifact のレポートのダウンロード」を参照してください。

Amazon EKS サービスを使用する際のお客様のコンプライアンス責任は、データの機密性、貴社のコンプライアンス目的、および適用法規や規則によって決まります。AWS ではコンプライアンスに役立つ以下のリソースを用意しています。

• セキュリティおよびコンプライアンスのクイックスタートガイド – これらのデプロイガイドでは、アーキテクチャ上の考慮事項について説明し、セキュリティとコンプライアンスに重点を置いたベースライン環境を AWS にデプロイするための手順を説明します。

• HIPAA のセキュリティとコンプライアンスに関するホワイトペーパーを作成する – このホワイトペーパーでは、企業が AWS を使用して HIPAA 準拠のアプリケーションを作成する方法について説明します。

• AWS コンプライアンスのリソース – このワークブックとガイドのコレクションは、お客様の業界や場所に適用される場合があります。

• AWS Config – この AWS サービスでは、自社プラクティス、業界ガイドライン、および規制に対するリソースの設定の準拠状態を評価します。

• AWS Security Hub – この AWS サービスでは、AWS 内のセキュリティ状態を包括的に表示しており、セキュリティ業界の標準およびベストプラクティスへの準拠を確認するのに役立ちます。

Amazon EKS の耐障害性AWS のグローバルインフラストラクチャは AWS リージョンとアベイラビリティーゾーンを中心として構築されます。AWS リージョンには、低レイテンシー、高いスループット、そして高度の冗長ネットワークで接続されている複数の物理的に独立・隔離されたアベイラビリティーゾーンがあります。アベイラビリティーゾーンでは、アベイラビリティーゾーン間で中断することなく自動的にフェイルオーバーするアプリケーションとデータベースを設計および運用することができます。アベイラビリティーゾーンは、従来の単一または複数のデータセンターインフラストラクチャよりも可用性、耐障害性、および拡張性が優れています。

Amazon EKS は、高可用性を確保するために、複数のアベイラビリティーゾーンで Kubernetes コントロールプレーンインスタンスを実行します。Amazon EKS は、異常なコントロールプレーンインスタンスを自動的に検出して置換するために、コントロールプレーンインスタンスのバージョンのアップグレードやパッチ適用を自動的に行います。

このコントロールプレーンは、リージョン内の 3 つのアベイラビリティーゾーンにまたがって動作する 2つ以上の API サーバーノードと 3 つの etcd ノードで構成されています。Amazon EKS は、異常なコントロールプレーンインスタンスを自動的に検出して置き換え、必要に応じてリージョン内のアベイラビリ

278





https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html

http://aws.amazon.com/quickstart/?awsf.quickstart-homepage-filter=categories%23security-identity-compliance

https://d0.awsstatic.com/whitepapers/compliance/AWS_HIPAA_Compliance_Whitepaper.pdf

http://aws.amazon.com/compliance/resources/

https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html

https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html

Amazon EKS ユーザーガイドインフラストラクチャセキュリティ

ティーゾーン全体でそれらを再起動します。Amazon EKS は、高可用性を維持するために AWS リージョンのアーキテクチャを利用します。そのため、Amazon EKS は API サーバーエンドポイントの可用性のSLA を提供できます。

AWSのリージョンやアベイラビリティーゾーンの詳細については、AWSグローバルインフラストラクチャを参照してください。

Amazon EKS でのインフラストラクチャセキュリティ

マネージド型サービスとしての Amazon EKS は、ホワイトペーパー「Amazon Web Services: セキュリティプロセスの概要」に記載されている AWS グローバルネットワークセキュリティの手順で保護されています。

AWS が公開した API コールを使用して、ネットワーク経由で Amazon EKS にアクセスします。クライアントで Transport Layer Security (TLS) 1.0 以降がサポートされている必要があります。TLS 1.2 以降が推奨されています。また、Ephemeral Diffie-Hellman (DHE) や Elliptic Curve Ephemeral Diffie-Hellman(ECDHE) などの Perfect Forward Secrecy (PFS) を使用した暗号スイートもクライアントでサポートされている必要があります。これらのモードは、Java 7 以降など、最近のほとんどのシステムでサポートされています。

また、リクエストは、アクセスキー ID と、IAM プリンシパルに関連付けられているシークレットのアクセスキーを使用して署名する必要があります。または、AWS Security Token Service (AWS STS) を使用して、一時的なセキュリティ認証情報を生成し、リクエストに署名することもできます。

Amazon EKS のクラスターの作成時には、使用するクラスターの VPC サブネットを指定します。AmazonEKS には、2 つ以上のアベイラビリティーゾーンにサブネットが必要です。パブリックサブネットとプライベートサブネットを持つ VPC をお勧めします。これにより、Kubernetes がパブリックサブネットにパブリックロードバランサーを作成し、プライベートサブネットにあるワーカーノードで実行されているポッドへのトラフィックを負荷分散します。

VPC に関する考慮事項の詳細については、「クラスター VPC に関する考慮事項 (p. 161)」を参照してください。

「Amazon EKS の開始方法 (p. 3)」ウォークスルーで提供されている AWS CloudFormation テンプレートを使用して VPC およびワーカーノードグループを作成した場合、コントロールプレーンとワーカーノードのセキュリティグループは推奨設定で設定されます。

セキュリティグループの考慮事項の詳細については、「Amazon EKS セキュリティグループの考慮事項 (p. 164)」を参照してください。

新しいクラスターを作成すると、Amazon EKS によってマネージド型の Kubernetes API サーバーのエンドポイントが作成されます。これは、クラスターとの通信に使用します (kubectl などの Kubernetes 管理ツールを使用)。デフォルトでは、この API サーバーエンドポイントはインターネットに公開され、APIサーバーへのアクセスは AWS Identity and Access Management (IAM) とネイティブの Kubernetes ロールベースアクセスコントロール (RBAC) の組み合わせを使用して保護されます。

Kubernetes API サーバーへのプライベートアクセスを有効にすると、ワーカーノードと API サーバー間のすべての通信が VPC 内に留まります。インターネットから API サーバーにアクセスできる IP アドレスを制限するか、API サーバーへのインターネットアクセスを完全に無効にできます。

クラスターエンドポイントアクセスの変更の詳細については、「クラスターエンドポイントのアクセスの変更 (p. 37)」を参照してください。

Project Calico (p. 185) などのツールを使用して、ネットワークポリシーを実装できます。Project Calico はサードパーティのオープンソースプロジェクトです。詳細については、Project Calico のドキュメントを参照してください。

279



http://aws.amazon.com/about-aws/global-infrastructure/

http://aws.amazon.com/about-aws/global-infrastructure/

https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf

https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf

https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html



https://docs.projectcalico.org/v3.7/introduction/

Amazon EKS ユーザーガイド設定と脆弱性の分析

Amazon EKS での設定と脆弱性の分析Amazon EKS プラットフォームのバージョンは、現在の Kubernetes パッチバージョンと、どのKubernetes API サーバーのフラグが有効かを含む、クラスターコントロールプレーンの機能を表します。新しいクラスターは、最新のプラットフォームバージョンでデプロイされます。詳細については、「プラットフォームのバージョン (p. 52)」を参照してください。

Amazon EKS クラスターを更新 (p. 29)し、新しい Kubernetes バージョンにすることができます。新しいKubernetes バージョンが Amazon EKS で利用可能になったら、利用可能な最新のバージョンが使用できるように、クラスターをタイムリーに更新することをお勧めします。EKS の Kubernetes のバージョンの詳細については、「Amazon EKS Kubernetes バージョン (p. 47)」を参照してください。

Amazon Linux セキュリティセンターで Amazon Linux 2 のセキュリティイベントまたはプライバシーイベントを追跡するか、関連する RSS フィードをサブスクライブします。セキュリティおよびプライバシーイベントには、影響を受ける問題の概要、パッケージ、および問題を修正するためにインスタンスを更新する手順などがあります。

Amazon Inspector を使用すると、ワーカーノードの意図しないネットワークアクセシビリティと、それらの Amazon EC2 インスタンスの脆弱性を確認できます。

ポッドのセキュリティポリシーKubernetes ポッドのセキュリティポリシーのアドミッションコントローラーは、一連のルールに対してポッドの作成を検証し、リクエストを更新します。デフォルトでは、Amazon EKS クラスターには、制限のない、完全な許容度のセキュリティポリシーが設定されています。詳細については、Kubernetes ドキュメントの「Pod Security Policies」を参照してください。

Note

ポッドセキュリティポリシーのアドミッションコントローラーは、Kubernetes バージョン 1.13以降を実行している Amazon EKS クラスターでのみ有効になります。ポッドのセキュリティポリシーを使用するには、クラスターの Kubernetes のバージョンを少なくとも 1.13 に更新する必要があります。詳細については、「Amazon EKS クラスターの Kubernetes バージョンの更新 (p. 29)」を参照してください。

Amazon EKS のデフォルトのポッドセキュリティポリシーKubernetes バージョン 1.13 以降の Amazon EKS クラスターには、eks.privileged という名前のデフォルトのポッドセキュリティポリシーがあります。このポリシーには、システムに受け入れ可能な種類のポッドについて制限がありません。これは、PodSecurityPolicy コントローラーを無効にしてKubernetes を実行するのと同じです。

Note

このポリシーは、PodSecurityPolicy コントローラーが有効になっていないクラスターとの下位互換性を維持するために作成されたものです。クラスターと個別名前空間およびサービスアカウントに対してより制限の高いポリシーを作成してから、デフォルトポリシーを削除し、より制限の高いポリシーを有効にすることができます。

次のコマンドを使用してデフォルトのポリシーを表示できます。

kubectl get psp eks.privileged

出力:

280



https://docs.aws.amazon.com/inspector/latest/userguide/inspector_introduction.html

https://kubernetes.io/docs/concepts/policy/pod-security-policy/

Amazon EKS ユーザーガイドAmazon EKS のデフォルトのポッドセキュリティポリシー

NAME PRIV CAPS SELINUX RUNASUSER FSGROUP SUPGROUP READONLYROOTFS VOLUMESeks.privileged true * RunAsAny RunAsAny RunAsAny RunAsAny false *

詳細については、次のコマンドを使用してポリシーについて説明できます。

kubectl describe psp eks.privileged

出力:

Name: eks.privileged

Settings: Allow Privileged: true Allow Privilege Escalation: 0xc0004ce5f8 Default Add Capabilities: <none> Required Drop Capabilities: <none> Allowed Capabilities: * Allowed Volume Types: * Allow Host Network: true Allow Host Ports: 0-65535 Allow Host PID: true Allow Host IPC: true Read Only Root Filesystem: false SELinux Context Strategy: RunAsAny User: <none> Role: <none> Type: <none> Level: <none> Run As User Strategy: RunAsAny Ranges: <none> FSGroup Strategy: RunAsAny Ranges: <none> Supplemental Groups Strategy: RunAsAny Ranges: <none>

次の例は、eks.privileged ポッドセキュリティポリシー、そのクラスターロール、およびロールバインドに対する完全な YAML ファイルを示しています。

---apiVersion: policy/v1beta1kind: PodSecurityPolicymetadata: name: eks.privileged annotations: kubernetes.io/description: 'privileged allows full unrestricted access to pod features, as if the PodSecurityPolicy controller was not enabled.' seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*' labels: kubernetes.io/cluster-service: "true" eks.amazonaws.com/component: pod-security-policyspec: privileged: true allowPrivilegeEscalation: true allowedCapabilities: - '*' volumes: - '*' hostNetwork: true hostPorts: - min: 0

281


max: 65535 hostIPC: true hostPID: true runAsUser: rule: 'RunAsAny' seLinux: rule: 'RunAsAny' supplementalGroups: rule: 'RunAsAny' fsGroup: rule: 'RunAsAny' readOnlyRootFilesystem: false

---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata: name: eks:podsecuritypolicy:privileged labels: kubernetes.io/cluster-service: "true" eks.amazonaws.com/component: pod-security-policyrules:- apiGroups: - policy resourceNames: - eks.privileged resources: - podsecuritypolicies verbs: - use

---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata: name: eks:podsecuritypolicy:authenticated annotations: kubernetes.io/description: 'Allow all authenticated users to create privileged pods.' labels: kubernetes.io/cluster-service: "true" eks.amazonaws.com/component: pod-security-policyroleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: eks:podsecuritypolicy:privilegedsubjects: - kind: Group apiGroup: rbac.authorization.k8s.io name: system:authenticated

デフォルトのポッドセキュリティポリシーを削除するには

クラスターのカスタムポッドセキュリティポリシーを作成したら、デフォルトの Amazon EKSeks.privileged ポッドセキュリティポリシーを削除して、カスタムポリシーを有効にできます。

1. privileged-podsecuritypolicy.yaml という名前のファイルを作成し、前の例の完全なeks.privileged YAML ファイルのコンテンツをそのファイルに貼り付けます (これにより、ポッドセキュリティポリシー、ClusterRole、関連付けられた ClusterRoleBinding を削除することができます)。

2. 次のコマンドを使用して YAML を削除します。

kubectl delete -f privileged-podsecuritypolicy.yaml

282


デフォルトのポッドセキュリティポリシーをインストールまたは復元するには

Kubernetes の以前のバージョンからアップグレードする場合、またはデフォルトの Amazon EKSeks.privileged ポッドセキュリティポリシーを変更または削除した場合は、以下の手順で復元できます。

1. privileged-podsecuritypolicy.yaml という名前のファイルを作成し、以下の YAML ファイルの内容をそのファイルに貼り付けます。

---apiVersion: policy/v1beta1kind: PodSecurityPolicymetadata: name: eks.privileged annotations: kubernetes.io/description: 'privileged allows full unrestricted access to pod features, as if the PodSecurityPolicy controller was not enabled.' seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*' labels: kubernetes.io/cluster-service: "true" eks.amazonaws.com/component: pod-security-policyspec: privileged: true allowPrivilegeEscalation: true allowedCapabilities: - '*' volumes: - '*' hostNetwork: true hostPorts: - min: 0 max: 65535 hostIPC: true hostPID: true runAsUser: rule: 'RunAsAny' seLinux: rule: 'RunAsAny' supplementalGroups: rule: 'RunAsAny' fsGroup: rule: 'RunAsAny' readOnlyRootFilesystem: false

---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata: name: eks:podsecuritypolicy:privileged labels: kubernetes.io/cluster-service: "true" eks.amazonaws.com/component: pod-security-policyrules:- apiGroups: - policy resourceNames: - eks.privileged resources: - podsecuritypolicies verbs: - use

---apiVersion: rbac.authorization.k8s.io/v1

283


kind: ClusterRoleBindingmetadata: name: eks:podsecuritypolicy:authenticated annotations: kubernetes.io/description: 'Allow all authenticated users to create privileged pods.' labels: kubernetes.io/cluster-service: "true" eks.amazonaws.com/component: pod-security-policyroleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: eks:podsecuritypolicy:privilegedsubjects: - kind: Group apiGroup: rbac.authorization.k8s.io name: system:authenticated

2. 次のコマンドを使用して YAML を適用します。

kubectl apply -f privileged-podsecuritypolicy.yaml

284

Amazon EKS ユーザーガイドタグの基本

Amazon EKS リソースのタグ付けAmazon EKS リソースを管理しやすくするために、タグ形式で各リソースに独自のメタデータを割り当てることができます。ここでは、タグとその作成方法について説明します。

コンテンツ• タグの基本 (p. 285)• リソースのタグ付け (p. 285)• タグの制限 (p. 286)• コンソールでのタグの処理 (p. 286)• CLI または API でのタグの操作 (p. 287)

タグの基本タグとは、AWS リソースに付けるラベルです。タグはそれぞれ、1 つのキーとオプションの 1 つの値で構成されており、どちらもお客様側が定義します。

タグを使用すると、 AWS リソースを目的、所有者、環境などで分類できます。同じ型のリソースが多い場合に、割り当てたタグに基づいて特定のリソースをすばやく識別できます。たとえば、Amazon EKS クラスターに一連のタグを定義して、各クラスターの所有者とスタックレベルを追跡できます。リソースタイプごとに一貫した一連のタグキーを考案することをお勧めします。追加したタグに基づいてリソースを検索およびフィルタリングできます。

タグは自動的にはリソースに割り当てられません。タグを追加したら、いつでもタグキーと値は編集でき、タグはリソースからいつでも削除できます。リソースを削除すると、リソースのタグも削除されます。

タグには、Amazon EKS に関連する意味はなく、完全に文字列として解釈されます。タグの値を空の文字列に設定することはできますが、タグの値を null に設定することはできません。特定のリソースについて既存のタグと同じキーを持つタグを追加した場合、古い値は新しい値によって上書きされます。

AWS マネジメントコンソール、AWS CLI、および Amazon EKS API を使用して、タグで作業できます。Note

Amazon EKS タグは、現在では eksctl にサポートされていません。

AWS Identity and Access Management (IAM) を使用している場合は、AWS アカウント内のどのユーザーがタグを作成、編集、削除するアクセス許可を持つかを制御できます。

リソースのタグ付け新規または既存の Amazon EKS クラスターおよびマネージド型ノードグループにタグを付けることができます。

Amazon EKS コンソールを使用している場合、新規リソースには作成時にタグを適用でき、既存のリソースには関連するリソースページの [Tags (タグ)] タブを使用していつでもタグを適用できます。

Amazon EKS API、AWS CLI、または AWS SDK を使用している場合、関連する API アクションの tagsパラメータを使用して新規リソースにタグを適用でき、TagResource API アクションを使用して既存のリソースにタグを適用できます。詳細については、「TagResource」を参照してください。

285

https://docs.aws.amazon.com/eks/latest/APIReference/API_TagResource.html

Amazon EKS ユーザーガイドタグの制限

リソース作成アクションによっては、リソースの作成時にリソースのタグを指定できます。リソースの作成時にタグを適用できない場合、リソースの作成プロセスは失敗します。これにより、作成時にタグ付けするリソースが、指定したタグで作成されるか、まったく作成されないことが確認されます。作成時にリソースにタグを付ける場合、リソースの作成後にカスタムのタグ付けスクリプトを実行する必要はありません。

次の表では、タグ付け可能な Amazon EKS リソースと、作成時にタグ付け可能なリソースについて説明します。

Amazon EKS リソースのタグ付けのサポート

リソースタグをサポートタグの伝播をサポート作成時のタグ付けをサポート (Amazon EKSAPI、AWS CLI、AWSSDK)

Amazon EKS クラスター

はいいいえ。クラスタータグは、クラスターに関連付けられた他のリソースには伝達されません。

はい

Amazon EKS マネージド型ノードグループ

はいいいえ。マネージド型ノードグループタグは、ノードグループに関連付けられた他のリソースには伝達されません。

はい

タグの制限タグには以下のような基本制限があります。

• リソースあたりのタグの最大数は 50 です。• タグキーは、リソースごとにそれぞれ一意である必要があります。また、各タグキーに設定できる値は

1 つのみです。• キーの最大長 – 128 文字 (Unicode) (UTF-8)• 値の最大長 – 256 文字 (Unicode) (UTF-8)• 複数の AWS サービス間およびリソース間でタグ付けスキーマを使用する場合、他のサービスでも許

可される文字に制限が適用されることがあるのでご注意ください。一般的に使用が許可される文字は、UTF-8 で表現できる文字、数字、スペース、および +、-、=、.、_、:、/、@。

• タグのキーと値は大文字と小文字が区別されます。• aws:、AWS:、またはその大文字または小文字の組み合わせを、キーまたは値のプレフィックスとし

て使用しないでください。これらの文字列は AWS による使用のために予約されています。このプレフィックスが含まれるタグのキーや値を編集したり削除することはできません。このプレフィックスを持つタグは、リソースあたりのタグ数の制限時には計算されません。

コンソールでのタグの処理新規または既存のクラスターおよびマネージド型ノードグループに関連付けられたタグは、Amazon EKSコンソールを使用して管理することができます。

286

Amazon EKS ユーザーガイド作成時に個々のリソースにタグを追加する

Amazon EKS コンソールでリソース固有のページを選択すると、リソースリストが表示されます。たとえば、ナビゲーションペインで [Clusters (クラスター)] を選択すると、Amazon EKS クラスターのリストがコンソールに表示されます。そのリスト (特定のクラスターなど) からリソースを 1 つ選択すると、そのリソースでタグがサポートされている場合は、[Tags (タグ)] タブでタグを表示および管理できます。

作成時に個々のリソースにタグを追加する作成時に Amazon EKS クラスターおよびマネージド型ノードグループにタグを追加できます。詳細については、「Amazon EKS クラスターの作成 (p. 22)」を参照してください。

個々のリソースでのタグの追加と削除Amazon EKS では、クラスターに関連付けられたタグをリソースのページから直接追加または削除できます。

個々のリソースのタグを追加または削除するには

1. https://console.aws.amazon.com/eks/home#/clusters にある Amazon EKS コンソールを開きます。2. ナビゲーションバーから、使用するリージョンを選択します。3. ナビゲーションペインで [Clusters] を選択します。4. 特定のクラスターを選択し、下にスクロールして、[Manage tags (タグの管理)] を選択します。5. [Update tags (タグの更新)] ページで、必要に応じてタグを追加または削除します。

• タグ — を追加するには、[Add Tag (タグの追加)] を選択して、各タグのキーと値を指定します。• タグ — を削除するには、[Remove tag (タグの削除)] を選択します。

6. 追加または削除するタグごとにこのプロセスを繰り返し、[Update (更新)] を選択して終了します。

CLI または API でのタグの操作リソースのタグの追加、更新、リスト表示、および削除には、次の AWS CLI コマンドまたは AmazonEKS API オペレーションを使用します。

Amazon EKS リソースのタグ付けのサポート

タスク AWS CLI API アクション

1 つ以上のタグを追加、または上書きします。

tag-resource TagResource

1 つ以上のタグを削除します。 untag-resource UntagResource

以下の例では、AWS CLI を使用して、リソースに対してタグ付けまたはタグ削除する方法を示しています。

例 1: 既存のクラスターへのタグ付け

次のコマンドは既存のクラスターにタグ付けします。

aws eks tag-resource --resource-arn resource_ARN --tags team=devs

例 2: 既存のクラスターでのタグ削除

次のコマンドは既存のクラスターからタグを削除します。

287


https://docs.aws.amazon.com/cli/latest/reference/tag-resource.html

https://docs.aws.amazon.com/eks/latest/APIReference/API_TagResource.html

https://docs.aws.amazon.com/cli/latest/reference/untag-resource.html

https://docs.aws.amazon.com/eks/latest/APIReference/API_UntagResource.html

Amazon EKS ユーザーガイドCLI または API でのタグの操作

aws eks untag-resource --resource-arn resource_ARN --tag-keys tag_key

例 3: リソースのタグのリスト取得

次のコマンドは、既存のリソースに関連付けられているタグのリストを取得します。

aws eks list-tags-for-resource --resource-arn resource_ARN

一部のリソース作成アクションでは、リソースの作成時にタグを指定できます。以下のアクションでは、作成時のタグ付けがサポートされます。

タスク AWS CLI AWS Tools for WindowsPowerShell

API アクション

クラスターの作成 create-cluster New-EKSCluster CreateCluster

マネージド型ノードグループを作成する

create-nodegroup

New-EKSNodegroup CreateNodegroup

288

https://docs.aws.amazon.com/cli/latest/reference/eks/create-cluster.html

https://docs.aws.amazon.com/powershell/latest/reference/items/New-EKSCluster.html

https://docs.aws.amazon.com/eks/latest/APIReference/API_CreateCluster.html

https://docs.aws.amazon.com/cli/latest/reference/eks/create-nodegroup.html

https://docs.aws.amazon.com/cli/latest/reference/eks/create-nodegroup.html

https://docs.aws.amazon.com/powershell/latest/reference/items/New-EKSNodegroup.html

https://docs.aws.amazon.com/eks/latest/APIReference/API_CreateNodegroup.html

Amazon EKS ユーザーガイドCloudTrail 内の Amazon EKS 情報

AWS CloudTrail を使用した AmazonEKS API コールのログ作成

Amazon EKS は、AWS CloudTrail と統合されています。このサービスは、Amazon EKS でユーザーやロール、または AWS サービスによって実行されたアクションを記録するサービスです。CloudTrailは、Amazon EKS のすべての API コールをイベントとしてキャプチャします。キャプチャされた呼び出しには、Amazon EKS コンソールの呼び出しと、Amazon EKS API オペレーションへのコード呼び出しが含まれます。

証跡を作成する場合は、Amazon EKS のイベントなど、Amazon S3 バケットへの CloudTrail イベントの継続的な配信を有効にすることができます。証跡を設定しない場合でも、CloudTrail コンソールの [Eventhistory (イベント履歴)] で最新のイベントを表示できます。CloudTrail によって収集された情報を使用して、リクエストの作成元の IP アドレス、リクエストの実行者、リクエストの実行日時などの詳細を調べて、Amazon EKS に対してどのようなリクエストが行われたかを判断できます。

CloudTrail の詳細については、「AWS CloudTrail User Guide」を参照してください。

CloudTrail 内の Amazon EKS 情報CloudTrail は、アカウント作成時に AWS アカウントで有効になります。Amazon EKS でアクティビティが発生すると、そのアクティビティは [Event history (イベント履歴)] の AWS の他のサービスのイベントとともに CloudTrail イベントに記録されます。最近のイベントは、AWS アカウントで表示、検索、ダウンロードできます。詳細については、「CloudTrail イベント履歴でのイベントの表示」を参照してください。

Amazon EKSのイベントなど、AWS アカウントのイベントの継続的な記録については、証跡を作成します。証跡により、CloudTrail はログファイルを Amazon S3 バケットに配信できます。デフォルトでは、コンソールで作成した証跡がすべての AWS リージョンに適用されます。証跡では、AWS パーティションのすべてのリージョンからのイベントがログに記録され、指定した Amazon S3 バケットにログファイルが配信されます。さらに、より詳細な分析と AWS ログで収集されたデータに基づいた行動のためにその他の CloudTrail サービスを設定できます。詳細については、以下を参照してください。

• 証跡を作成するための概要• CloudTrail でサポートされるサービスと統合• CloudTrail の Amazon SNS 通知の設定• 「複数のリージョンから CloudTrail ログファイルを受け取る」および「複数のアカウントから

CloudTrail ログファイルを受け取る」

Amazon EKS アクションはすべて CloudTrail によって記録されます。また、これらのアクションはAmazon EKS API Referenceで説明されています。たとえば、[CreateCluster]、[ListClusters]、[DeleteCluster] セクションの呼び出しは、CloudTrail ログファイルにエントリを生成します。

各イベントまたはログエントリには、リクエストの生成者に関する情報が含まれます。この ID 情報は以下のことを確認するのに役立ちます。

• リクエストが、ルートまたは AWS Identity and Access Management (IAM) ユーザー認証情報のどちらを使用して送信されたかどうか。

• リクエストが、ロールとフェデレーティッドユーザーのどちらの一時的なセキュリティ認証情報を使用して送信されたか.

289

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html#cloudtrail-aws-service-specific-topics-integrations

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/getting_notifications_top_level.html

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html

https://docs.aws.amazon.com/eks/latest/APIReference/


https://docs.aws.amazon.com/eks/latest/APIReference/API_ListClusters.html

https://docs.aws.amazon.com/eks/latest/APIReference/API_DeleteCluster.html

Amazon EKS ユーザーガイドAmazon EKS ログファイルエントリの概要

• リクエストが、別の AWS サービスによって送信されたかどうか。

詳細については、「CloudTrail userIdentity 要素」を参照してください。

Amazon EKS ログファイルエントリの概要証跡は、指定した Amazon S3 バケットにイベントをログファイルとして配信できる設定です。CloudTrailログファイルには、1 つ以上のログエントリが含まれます。イベントは任意の送信元からの単一のリクエストを表し、リクエストされたアクション、アクションの日時、リクエストのパラメータなどに関する情報が含まれます。CloudTrail ログファイルは、パブリック API コールの順序付けられたスタックトレースではないため、特定の順序では表示されません。

以下の例は、CreateCluster アクションの実例となる CloudTrail ログエントリを示しています。

{ "eventVersion": "1.05", "userIdentity": { "type": "IAMUser", "principalId": "AKIAIOSFODNN7EXAMPLE", "arn": "arn:aws:iam::111122223333:user/username", "accountId": "111122223333", "accessKeyId": "AKIAIOSFODNN7EXAMPLE", "userName": "username" }, "eventTime": "2018-05-28T19:16:43Z", "eventSource": "eks.amazonaws.com", "eventName": "CreateCluster", "awsRegion": "region-code", "sourceIPAddress": "205.251.233.178", "userAgent": "PostmanRuntime/6.4.0", "requestParameters": { "resourcesVpcConfig": { "subnetIds": [ "subnet-a670c2df", "subnet-4f8c5004" ] }, "roleArn": "arn:aws:iam::111122223333:role/AWSServiceRoleForAmazonEKS-CAC1G1VH3ZKZ", "clusterName": "test" }, "responseElements": { "cluster": { "clusterName": "test", "status": "CREATING", "createdAt": 1527535003.208, "certificateAuthority": {}, "arn": "arn:aws:eks:region-code:111122223333:cluster/test", "roleArn": "arn:aws:iam::111122223333:role/AWSServiceRoleForAmazonEKS-CAC1G1VH3ZKZ", "version": "1.10", "resourcesVpcConfig": { "securityGroupIds": [], "vpcId": "vpc-21277358", "subnetIds": [ "subnet-a670c2df", "subnet-4f8c5004" ] } } }, "requestID": "a7a0735d-62ab-11e8-9f79-81ce5b2b7d37", "eventID": "eab22523-174a-499c-9dd6-91e7be3ff8e3",

290

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html


Amazon EKS ユーザーガイドAmazon EKS サービスにリンクされたロールのログエントリ

"readOnly": false, "eventType": "AwsApiCall", "recipientAccountId": "111122223333"}

Amazon EKS サービスにリンクされたロールのログエントリAmazon EKS サービスにリンクされたロールは、AWS リソースへの API コールを行います。Amazon EKS サービスにリンクされたロールによって行われたコールには、CloudTrail ログエントリが username: AWSServiceRoleForAmazonEKS と username:AWSServiceRoleForAmazonEKSNodegroup で表示されます。Amazon EKS およびサービスにリンクされたロールの詳細については、「the section called “サービスにリンクされたロールの使用” (p. 254)」を参照してください。

次の例の CloudTrail ログエントリは、sessionContext に記録された、AWSServiceRoleForAmazonEKSNodegroup サービスにリンクされたロールによって実行されたDeleteInstanceProfile アクションを示しています。

{ "eventVersion": "1.05", "userIdentity": { "type": "AssumedRole", "principalId": "AROA3WHGPEZ7SJ2CW55C5:EKS", "arn": "arn:aws:sts::111122223333:assumed-role/AWSServiceRoleForAmazonEKSNodegroup/EKS", "accountId": "111122223333", "accessKeyId": "AKIAIOSFODNN7EXAMPLE", "sessionContext": { "sessionIssuer": { "type": "Role", "principalId": "AROA3WHGPEZ7SJ2CW55C5", "arn": "arn:aws:iam::111122223333:role/aws-service-role/eks-nodegroup.amazonaws.com/AWSServiceRoleForAmazonEKSNodegroup", "accountId": "111122223333", "userName": "AWSServiceRoleForAmazonEKSNodegroup" }, "webIdFederationData": {}, "attributes": { "mfaAuthenticated": "false", "creationDate": "2020-02-26T00:56:33Z" } }, "invokedBy": "eks-nodegroup.amazonaws.com" }, "eventTime": "2020-02-26T00:56:34Z", "eventSource": "iam.amazonaws.com", "eventName": "DeleteInstanceProfile", "awsRegion": "us-east-1", "sourceIPAddress": "eks-nodegroup.amazonaws.com", "userAgent": "eks-nodegroup.amazonaws.com", "requestParameters": { "instanceProfileName": "eks-11111111-2222-3333-4444-abcdef123456" }, "responseElements": null, "requestID": "11111111-2222-3333-4444-abcdef123456", "eventID": "11111111-2222-3333-4444-abcdef123456", "eventType": "AwsApiCall", "recipientAccountId": "111122223333"}

291

https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteInstanceProfile.html


AWS Outposts での Amazon EKSKubernetes version 1.14.8 Amazon EKS プラットフォームバージョン eks.5 および Kubernetes version1.13.12 Amazon EKS プラットフォームバージョン eks.6 以降では、AWS Outposts で Amazon EKSノードを作成して実行できます。AWS Outposts は、オンプレミス施設でネイティブの AWS のサービス、インフラストラクチャ、および運用モデルを有効にします。AWS Outposts 環境では、AWS クラウドで使用するのと同じ AWS API、ツール、インフラストラクチャを使用できます。AWS Outposts のAmazon EKS ワーカーノードは、オンプレミスのデータおよびアプリケーションに近接して実行する必要がある低レイテンシーのワークロードに最適です。AWS Outposts の詳細については、AWS Outpostsユーザーガイドを参照してください。

前提条件Amazon EKS ワーカーノードを AWS Outposts で使用するための前提条件を次に示します。

• オンプレミスのデータセンターに Outpost をインストールして設定しておく必要があります。• Outpost と AWS リージョンの間に信頼できるネットワーク接続が必要です。• Outpost の AWS リージョンは Amazon EKS をサポートする必要があります。サポートされているリー

ジョンのリストについては、AWS General Referenceの「Amazon EKS サービスエンドポイント」を参照してください。

制約事項Outposts での Amazon EKS の使用に関する制限事項を次に示します。

• AWS Identity and Access Management、Application Load Balancer、Network Load Balancer、ClassicLoad Balancer、Amazon Route 53 は、Outposts ではなく AWS リージョンで実行します。これにより、サービスとコンテナ間のレイテンシーが増加します。

• AWS Fargate は AWS Outposts で使用できません。

ネットワーク接続に関する考慮事項以下に、Amazon EKS AWS Outposts のネットワーク接続に関する考慮事項を示します。

• Outpost とその AWS リージョン間のネットワーク接続が失われた場合、ノードは引き続き実行されます。ただし、接続が復元されるまで、新しいノードを作成したり、既存のデプロイで新しいアクションを実行したりすることはできません。インスタンスに障害が発生した場合、インスタンスは自動的に置き換えられません。Kubernetes マスターはリージョンで実行され、アベイラビリティーゾーンへの接続の喪失などの原因でハートビートが失われると、障害が発生する可能性があります。障害のあるハートビートにより、Outposts のポッドが異常とマークされ、最終的にノードのステータスがタイムアウトし、ポッドに削除のマークが付けられます。詳細については、Kubernetes ドキュメントの「NodeController」を参照してください。

• Outpost と AWS リージョン間で、信頼性が高く、可用性が高い、低レイテンシーの接続を提供することをお勧めします。

292

https://docs.aws.amazon.com/outposts/latest/userguide/

https://docs.aws.amazon.com/outposts/latest/userguide/


https://kubernetes.io/docs/concepts/architecture/nodes/#node-controller

https://kubernetes.io/docs/concepts/architecture/nodes/#node-controller

Amazon EKS ユーザーガイドOutpost に Amazon EKS ノードを作成する

Outpost に Amazon EKS ノードを作成するOutpost での Amazon EKS ノードの作成は、AWS クラウドでの Amazon EKS ノードの作成と似ています。Outpost に Amazon EKS ノードを作成するときは、Outpost に関連付けられたサブネットを指定する必要があります。

Outpost は AWS リージョンの拡張であり、アカウント内の VPC を複数のアベイラビリティーゾーンおよび関連する任意の Outpost ロケーションにまたがるように拡張できます。Outpost を設定するとき、サブネットをそれに関連付けて、リージョン VPC 環境をオンプレミス施設に拡張します。Outpost のインスタンスは、サブネットが関連付けられたアベイラビリティーゾーンと同様に、リージョン VPC の一部として表示されます。

AWS CLI を使用して Outpost に Amazon EKS ノードを作成するには、Outpost に関連付けられたセキュリティグループとサブネットを指定します。

Outpost に Amazon EKS ノードグループを作成するには

1. VPC を作成します。

aws ec2 create-vpc --cidr-block 10.0.0.0/16

2. Outpost サブネットを作成します。Outpost 用に作成されるサブネットには、--outpost-arn パラメータを指定する必要があります。(この手順は、AWS Outposts では異なります)。

aws ec2 create-subnet --vpc-id vpc-xxxxxxxx --cidr-block 10.0.3.0/24 \ –-outpost-arn arn:aws:outposts:us-west-2:123456789012:outpost/op-xxxxxxxxxxxxxxxx

3. Outpost のサブネットを指定して、クラスターを作成します。(この手順は、AWS Outposts では異なります)。

293

Amazon EKS ユーザーガイドOutpost に Amazon EKS ノードを作成する

aws eks --region region-code create-cluster --name eks-outpost --role-arn \ arn:aws:iam::123456789012:role/eks-service-role-AWSServiceRoleForAmazonEKS-OUTPOST \ --resources-vpc-config subnetIds=subnet-xxxxxxxx,subnet-yyyyyyyy,securityGroupIds=sg-xxxxxxxx

4. ノードグループを作成します。Outpost で使用できるインスタンスタイプを指定します。(この手順は、AWS Outposts では異なります)。

eksctl create nodegroup --cluster eks-outpost \ --version auto \ --name outpost-workers \ --node-type c5.large \ --node-ami auto \ --nodes 3 \ --nodes-min 1 \ --nodes-max 4

5. アプリケーションとサービスをデプロイします。

kubectl apply -f kubernetes/deployment.yaml

294

Amazon EKS ユーザーガイド管理ツール

関連プロジェクトこれらのオープンソースプロジェクトは、Amazon EKS によって管理されているクラスターを含め、AWS上で実行されている Kubernetes クラスターの機能を拡張します。

管理ツールAmazon EKS および Kubernetes クラスターに関連する管理ツール。

eksctleksctl は、Amazon EKS 上にクラスターを作成するためのシンプルな CLI ツールです。

• プロジェクト URL: https://eksctl.io/• プロジェクトドキュメント: https://eksctl.io/• AWS オープンソースブログ: eksctl: Amazon EKS Cluster with One Command (1 つのコマンドによる

Amazon EKS クラスター)

AWS Service OperatorAWS Service Operator では、kubectl を使用して AWS リソースを作成できます。

• プロジェクト URL: https://github.com/aws/aws-service-operator-k8s• プロジェクトドキュメント: https://github.com/aws/aws-service-operator-k8s/blob/master/README.md• AWS オープンソースブログ: AWS Service Operator for Kubernetes Now Available (AWS Service

Operator for Kubernetes の使用開始)

ネットワークAmazon EKS および Kubernetes クラスターに関連するネットワークプロジェクト。

Amazon VPC CNI Plugin for KubernetesAmazon EKS は、Amazon VPC CNI plugin for Kubernetes を経由してネイティブな VPC ネットワーキングをサポートします。この CNI プラグインを使用すると、Kubernetes ポッドは VPC ネットワーク上と同じ IP アドレスをポッド内に持つことができます。詳細については、「ポッドネットワーキング(CNI) (p. 167)」および「CNI 設定変数 (p. 168)」を参照してください。

• プロジェクト URL: https://github.com/aws/amazon-vpc-cni-k8s• プロジェクトドキュメント: https://github.com/aws/amazon-vpc-cni-k8s/blob/master/README.md

AWS Application Load Balancer (ALB) IngressController for KubernetesAWS ALB Ingress Controller は、Application Load Balancer をプロビジョニングすることによってKubernetes イングレスリソースを満たします。

295

https://eksctl.io/

https://eksctl.io/

http://aws.amazon.com/blogs/opensource/eksctl-eks-cluster-one-command/

http://aws.amazon.com/blogs/opensource/eksctl-eks-cluster-one-command/

https://github.com/aws/aws-service-operator-k8s

https://github.com/aws/aws-service-operator-k8s/blob/master/README.md

http://aws.amazon.com/blogs/opensource/aws-service-operator-kubernetes-available/

http://aws.amazon.com/blogs/opensource/aws-service-operator-kubernetes-available/



Amazon EKS ユーザーガイドExternalDNS

• プロジェクト URL: https://github.com/kubernetes-sigs/aws-alb-ingress-controller• プロジェクトドキュメント: https://github.com/kubernetes-sigs/aws-alb-ingress-controller/tree/master/

docs• AWS オープンソースブログ: Kubernetes Ingress with AWS ALB Ingress Controller (AWS ALB Ingress

Controller を使用する Kubernetes Ingress)

ExternalDNSExternalDNS は、公開された Kubernetes サービスとそのイングレスを、Amazon Route 53 や AWSService Discovery を含む DNS プロバイダーと同期させます。

• プロジェクト URL: https://github.com/kubernetes-incubator/external-dns• プロジェクトドキュメント: https://github.com/kubernetes-incubator/external-dns/blob/master/docs/

tutorials/aws.md

セキュリティAmazon EKS および Kubernetes クラスターに関連するセキュリティプロジェクト。

AWS IAM AuthenticatorAWSIAM 認証情報を使用して Kubernetes クラスターへの認証を行うためのツール。詳細については、「aws-iam-authenticator のインストール (p. 196)」を参照してください。

• プロジェクト URL: https://github.com/kubernetes-sigs/aws-iam-authenticator• プロジェクトドキュメント: https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/

README.md• AWS オープンソースブログ: Deploying the AWS IAM Authenticator to kops (Heptio Authenticator の

kops へのデプロイ)

機械学習Amazon EKS および Kubernetes クラスターに関連する機械学習プロジェクト。

KubeflowKubernetes 用の機械学習ツールキット。

• プロジェクト URL: https://www.kubeflow.org/• プロジェクトドキュメント: https://www.kubeflow.org/docs/• AWS オープンソースブログ: Kubeflow on Amazon EKS (Amazon EKS の Kubeflow)

Auto ScalingAmazon EKS および Kubernetes クラスターに関連する自動スケーリングプロジェクト。

296


https://github.com/kubernetes-sigs/aws-alb-ingress-controller/tree/master/docs

https://github.com/kubernetes-sigs/aws-alb-ingress-controller/tree/master/docs

http://aws.amazon.com/blogs/opensource/kubernetes-ingress-aws-alb-ingress-controller/

http://aws.amazon.com/blogs/opensource/kubernetes-ingress-aws-alb-ingress-controller/

https://github.com/kubernetes-incubator/external-dns

https://github.com/kubernetes-incubator/external-dns/blob/master/docs/tutorials/aws.md

https://github.com/kubernetes-incubator/external-dns/blob/master/docs/tutorials/aws.md


https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/README.md

https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/README.md

http://aws.amazon.com/blogs/opensource/deploying-heptio-authenticator-kops/

http://aws.amazon.com/blogs/opensource/deploying-heptio-authenticator-kops/

https://www.kubeflow.org/

https://www.kubeflow.org/docs/

http://aws.amazon.com/blogs/opensource/kubeflow-amazon-eks/

Amazon EKS ユーザーガイドCluster Autoscaler

Cluster AutoscalerCluster Autoscaler は、CPU とメモリーの負荷に基づいて Kubernetes クラスターのサイズを自動的に調整するツールです。

• プロジェクト URL: https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler• プロジェクトドキュメント: https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/

cloudprovider/aws/README.md• Amazon EKS ワークショップ: https://eksworkshop.com/scaling/deploy_ca/

EscalatorEscalator は、Kubernetes 用のバッチまたはジョブ最適化水平オートスケーラーです。

• プロジェクト URL: https://github.com/atlassian/escalator• プロジェクトドキュメント: https://github.com/atlassian/escalator/blob/master/docs/README.md

モニタリングAmazon EKS および Kubernetes クラスターに関連するモニタリングプロジェクト。

PrometheusPrometheus はオープンソースのシステムモニタリングおよび警告ツールキットです。

• プロジェクト URL: https://prometheus.io/• プロジェクトドキュメント: https://prometheus.io/docs/introduction/overview/• Amazon EKS ワークショップ: https://eksworkshop.com/intermediate/240_monitoring/

継続的インテグレーション/継続的デプロイメントAmazon EKS および Kubernetes クラスターに関連する CI/CD プロジェクト。

Jenkins XAmazon EKS および Kubernetes クラスター上の最新のクラウドアプリケーション用 CI/CD ソリューション。

• プロジェクト URL: https://jenkins-x.io/• プロジェクトドキュメント: https://jenkins-x.io/documentation/• AWS オープンソースブログ: Continuous Delivery with Amazon EKS and Jenkins X (Amazon EKS と

Jenkins X による継続的デリバリー)

297


https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md

https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md

https://eksworkshop.com/scaling/deploy_ca/

https://github.com/atlassian/escalator

https://github.com/atlassian/escalator/blob/master/docs/README.md

https://prometheus.io/

https://prometheus.io/docs/introduction/overview/

https://eksworkshop.com/intermediate/240_monitoring/

https://jenkins-x.io/

https://jenkins-x.io/documentation/

http://aws.amazon.com/blogs/opensource/continuous-delivery-eks-jenkins-x/

http://aws.amazon.com/blogs/opensource/continuous-delivery-eks-jenkins-x/

Amazon EKS ユーザーガイド容量不足

Amazon EKS のトラブルシューティング

この章では、Amazon EKS の使用中に表示される一般的なエラーとその回避方法について説明します。

容量不足Amazon EKS を作成しようとするときに、次のエラーが表示された場合、指定したアベイラビリティーゾーンに、クラスターをサポートするために十分な容量がありません。

Cannot create cluster 'example-cluster' because region-1d, the targeted ✓✓✓✓✓✓✓✓✓✓✓✓, does not currently have sufficient capacity to support the cluster.Retry and choose from these ✓✓✓✓✓✓✓✓✓✓✓✓s: region-1a, region-1b, region-1c

このエラーメッセージによって返されるアベイラビリティーゾーンでホストされているクラスター VPC 内のサブネットを使用して、クラスターを再作成してください。

aws-iam-authenticator Not Found"aws-iam-authenticator": executable file not found in $PATH というエラーが発生した場合、kubectl は、Amazon EKS に設定されていません。詳細については、「aws-iam-authenticatorのインストール (p. 196)」を参照してください。

ワーカーノードをクラスターに結合できませんワーカーノードがクラスターに結合されない一般的な理由はいくつかあります。

• aws-auth-cm.yaml ファイルでは、ワーカーノードに対する IAM ロール ARN が正しくない。ワーカーノードの IAM ロール ARN (インスタンスプロファイルの ARN ではない) が aws-auth-cm.yamlファイルで指定されていることを確かめてください。詳細については、「Amazon EKS Linux ワーカーノードの起動 (p. 95)」を参照してください。

• ワーカーノードの AWS CloudFormation テンプレートの ClusterName がワーカーノードを参加させたいクラスターの名前と正確に一致しない。このフィールドに正しくない値を渡すと、ワーカーノードの /var/lib/kubelet/kubeconfig ファイルの設定が正しくないために、ノードはクラスターに結合されません。

• ワーカーノードは、クラスターによって所有されているためタグ付けされていません。ワーカーノードには、次のタグが適用されている必要があります。<cluster_name> はクラスターの名前に置き換えられます。

キー値


• ワーカーノードは、パブリック IP アドレスを使用してクラスターにアクセスできない場合があります。パブリックサブネットにデプロイされたワーカーノードにパブリック IP アドレスが割り当てられていることを確認します。割り当てられていない場合は、起動後にワーカーノードに Elastic IP アドレスを関

298

Amazon EKS ユーザーガイド許可されていないか、アクセ

スが拒否されました (kubectl)

連付けることができます。詳細については、「Elastic IP アドレスを実行中のインスタンスまたはネットワークインターフェイスに関連付ける」を参照してください。デプロイされたインスタンスにパブリック IP アドレスを自動的に割り当てるようにパブリックサブネットが設定されていない場合は、その設定を有効にすることをお勧めします。詳細については、「サブネットの IPv4 アドレス指定属性の変更」を参照してください。ワーカーノードがプライベートサブネットにデプロイされている場合、サブネットには、パブリック IP アドレスが割り当てられた NAT ゲートウェイへのルートが必要です。

許可されていないか、アクセスが拒否されました(kubectl)

kubectl コマンドの実行中に次のいずれかのエラーが発生した場合、kubectl が Amazon EKS に対して適切に設定されていないか、使用している IAM ユーザーまたはロール認証情報が Amazon EKS クラスターで十分なアクセス許可を持つ Kubernetes RBAC ユーザーにマッピングされていません。

• could not get token: AccessDenied: Access denied

• error: You must be logged in to the server (Unauthorized)

• error: the server doesn't have a resource type "svc"

これは、クラスターが AWS 認証情報のあるセット (IAM ユーザーまたはロール) から作成されたが、kubectl は別の認証情報のセットを使用していることが原因である可能性があります。

Amazon EKS クラスターが作成されたら、クラスターを作成する IAM エンティティ (ユーザーまたはロール) は、管理者 (system:master アクセス許可が付与されている) として Kubernetes RBAC 認証テーブルに追加されます。最初は、その IAM ユーザーだけが kubectl を使用して Kubernetes API サーバーを呼び出すことができます。詳細については、「クラスターのユーザーまたは IAM ロールの管理 (p. 202)」を参照してください。また、AWS IAM Authenticator for Kubernetes では、AWS SDK for Go を使用して、Amazon EKS クラスターに対して認証を行います。コンソールを使用してクラスターを作成する場合は、クラスター上で kubectl コマンドを実行する際、同じ IAM ユーザー認証情報が AWS SDK 認証情報チェーンにあることを確認する必要があります。

AWS CLI をインストールして設定する場合は、ユーザーの IAM 認証情報を設定できます。AWS CLI がユーザーに対して適切に設定されている場合は、AWS IAM Authenticator for Kubernetes を使用してこれらの認証情報も検索できます。詳細については、AWS Command Line Interface ユーザーガイドの「AWSCLI の設定」を参照してください。

Amazon EKS クラスターを作成するロールを引き受ける場合は、kubectl が同じロールを引き受けるように設定されていることを確認する必要があります。次のコマンドを使用して、IAM ロールを使用するように kubeconfig ファイルを更新します。詳細については、「kubeconfig を Amazon EKS 用に作成します。 (p. 199)」を参照してください。

aws --region region-code eks update-kubeconfig --name cluster_name --role-arn arn:aws:iam::aws_account_id:role/role_name

Kubernetes RBAC ユーザーに IAM ユーザーをマップするには、クラスターのユーザーまたは IAM ロールの管理 (p. 202) を参照するか、ユーザーをマップする方法についてのビデオを視聴してください。

hostname doesn't matchシステムの Python のバージョンは 2.7.9 以降であることが必要です。そうでない場合は、AWS CLI でAmazon EKS を呼び出すと hostname doesn't match エラーが発生します。詳細については、PythonRequests FAQ の「What are "hostname doesn't match" errors?｣を参照してください。

299

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html#using-instance-addressing-eips-associating

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html#using-instance-addressing-eips-associating






https://www.youtube.com/watch?time_continue=3&v=97n9vWV3VcU

http://docs.python-requests.org/en/master/community/faq/#what-are-hostname-doesn-t-match-errors

Amazon EKS ユーザーガイドgetsockopt: no route to host

getsockopt: no route to hostDocker は Amazon EKS クラスターの 172.17.0.0/16 CIDR 範囲で実行されます。クラスターの VPC サブネットがこの範囲と重ならないようにすることをお勧めします。重なっている場合は、以下のエラーが発生します。

Error: : error upgrading connection: error dialing backend: dial tcp 172.17.nn.nn:10250: getsockopt: no route to host

マネージド型ノードグループのエラーAWS マネジメントコンソールで「インスタンスが kubernetes クラスターに参加できませんでした」というエラーが表示された場合は、クラスターのプライベートエンドポイントアクセスが有効になっているか、パブリックエンドポイントアクセス用に CIDR ブロックが正しく設定されていることを確認します。詳細については、「Amazon EKS クラスターエンドポイントのアクセスコントロール (p. 37)」を参照してください。

マネージド型ノードグループで正常性の問題が発生した場合は、Amazon EKS から問題の診断に役立つエラーメッセージが返されます。以下のエラーメッセージとそれに関連する説明を下に示します。

• AutoScalingGroupNotFound: マネージド型ノードグループに関連付けられている Auto Scaling グループが見つかりませんでした。同じ設定で Auto Scaling グループを再作成して復旧できる場合があります。

• Ec2SecurityGroupNotFound: クラスターのクラスターセキュリティグループが見つかりませんでした。クラスターを再作成する必要があります。

• Ec2SecurityGroupDeletionFailure: マネージド型ノードグループのリモートアクセスセキュリティグループを削除できませんでした。セキュリティグループから依存関係を削除します。

• Ec2LaunchTemplateNotFound: マネージド型ノードグループの Amazon EC2 起動テンプレートが見つかりませんでした。同じ設定で起動テンプレートを再作成して復旧できる場合があります。

• Ec2LaunchTemplateVersionMismatch: マネージド型ノードグループの Amazon EC2 起動テンプレートのバージョンが、Amazon EKS が作成したバージョンと一致しません。Amazon EKS が作成したバージョンに戻して復旧できる場合があります。

• IamInstanceProfileNotFound: マネージド型ノードグループの IAM インスタンスプロファイルが見つかりませんでした。同じ設定でインスタンスプロファイルを再作成して復旧できる場合があります。

• IamNodeRoleNotFound: マネージド型ノードグループの IAM ロールが見つかりませんでした。同じ設定で IAM ロールを再作成して復旧できる場合があります。

• AsgInstanceLaunchFailures: インスタンスの起動中に Auto Scaling グループに障害が発生しています。• NodeCreationFailure: 起動したインスタンスを Amazon EKS クラスターに登録できません。この障害

の一般的な原因は、ワーカーノード IAM ロール (p. 260)のアクセス許可が不十分か、ノードのアウトバウンドのインターネットアクセスがないことです。ワーカーノードが適切に機能するためには、パブリック IP アドレスを使用してインターネットにアクセスできる必要があります。詳細については、「??? (p. 162)」を参照してください。ワーカーノードには、インターネットに対して開いているポートも必要です。詳細については、「??? (p. 164)」を参照してください。

• InstanceLimitExceeded: AWS アカウントが、指定されたインスタンスタイプのインスタンスをこれ以上起動できません。Amazon EC2 インスタンス制限の引き上げをリクエストして復旧できる場合があります。

• InsufficientFreeAddresses: マネージド型ノードグループに関連付けられている 1 つ以上のサブネットに、新しいノードに使用できる十分な IP アドレスがありません。

• AccessDenied: Amazon EKS または 1 つ以上のマネージド型ノードがクラスター API サーバーと通信できません。

• InternalFailure: これらのエラーは、通常、Amazon EKS サーバー側の問題が原因で発生します。

300

Amazon EKS ユーザーガイドCNI ログ収集ツール

CNI ログ収集ツールAmazon VPC CNI plugin for Kubernetes には、独自のトラブルシューティングスクリプト (ワーカーノードの /opt/cni/bin/aws-cni-support.sh で閲覧化) があり、サポートケースや一般的なトラブルシューティング用の診断ログ収集のため利用できます。

ワーカーノードでスクリプトを実行するには、以下のコマンドを使用します。

sudo bash /opt/cni/bin/aws-cni-support.sh

Note

指定された場所にスクリプトが存在しない場合は、CNI コンテナの実行に失敗します。手動でスクリプトをダウンロードして実行するには、次のコマンドを使用します。

curl -O https://raw.githubusercontent.com/awslabs/amazon-eks-ami/master/log-collector-script/linux/eks-log-collector.shsudo bash eks-log-collector.sh

このスクリプトは、次の診断情報を収集します。デプロイした CNI バージョンは、スクリプトバージョンより前のバージョンである可能性があります。

This is version 0.6.1. New versions can be found at https://github.com/awslabs/amazon-eks-ami

Trying to collect common operating system logs... Trying to collect kernel logs... Trying to collect mount points and volume information... Trying to collect SELinux status... Trying to collect iptables information... Trying to collect installed packages... Trying to collect active system services... Trying to collect Docker daemon information... Trying to collect kubelet information... Trying to collect L-IPAMD information... Trying to collect sysctls information... Trying to collect networking infomation... Trying to collect CNI configuration information... Trying to collect running Docker containers and gather container data... Trying to collect Docker daemon logs... Trying to archive gathered information...

Done... your bundled logs are located in /var/log/eks_i-0717c9d54b6cfaa19_2020-03-24_0103-UTC_0.6.1.tar.gz

診断情報が収集され、に保存されます。

/var/log/eks_i-0717c9d54b6cfaa19_2020-03-24_0103-UTC_0.6.1.tar.gz

Container runtime network not ready (コンテナランタイムネットワークの準備ができていません)

以下のような Container runtime network not ready エラーと承認エラーが表示される場合があります。

301

Amazon EKS ユーザーガイドTLS ハンドシェイクタイムアウト

4191 kubelet.go:2130] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized4191 reflector.go:205] k8s.io/kubernetes/pkg/kubelet/kubelet.go:452: Failed to list *v1.Service: Unauthorized4191 kubelet_node_status.go:106] Unable to register node "ip-10-40-175-122.ec2.internal" with API server: Unauthorized4191 reflector.go:205] k8s.io/kubernetes/pkg/kubelet/kubelet.go:452: Failed to list *v1.Service: Unauthorized

これらのエラーは、AWS IAM 認証システム設定マップがワーカーノードに適用されていないことに関連している可能性があります。この設定マップは、クラスターに登録するための Kubernetes RBAC アクセス許可 system:bootstrappers および system:nodes をワーカーノードに付与します。詳細については、「Amazon EKS Linux ワーカーノードの起動 (p. 95)」の [Self-managed nodes (セルフマネージド型ノード)] タブにある「ワーカーノードをクラスターと結合するには」を参照してください。インスタンスプロファイル ARN ではなく、設定マップのインスタンスロールのロール ARN を指定してください。

以下の例のように、/ 以外のパスが含まれる場合、認証システムは [ロール ARN] を認識しません。

arn:aws:iam::111122223333:role/development/apps/prod-iam-role-NodeInstanceRole-621LVEXAMPLE

/ 以外のパスを含む設定マップでロール ARN を指定するときは、パスをドロップする必要があります。上記の ARN は以下のように指定します。

arn:aws:iam::111122223333:role/prod-iam-role-NodeInstanceRole-621LVEXAMPLE

TLS ハンドシェイクタイムアウトワーカーノードがパブリック API サーバーエンドポイントへの接続を確立できない場合、以下のようなエラーが発生する可能性があります。

server.go:233] failed to run Kubelet: could not init cloud provider "aws": error finding instance i-1111f2222f333e44c: "error listing AWS instances: \"RequestError: send request failed\\ncaused by: Post net/http: TLS handshake timeout\""

kubelet プロセスは、API サーバーエンドポイントを継続的に再生成およびテストします。このエラーは、コントロールプレーンでクラスターのローリング更新を行う手順 (設定の変更やバージョンの更新など) で一時的に発生することもあります。

この問題を解決するには、ルートテーブルとセキュリティグループをチェックして、ワーカーノードからのトラフィックがパブリックエンドポイントに到達できることを確認します。

Error: ErrImagePull1.12 のワーカーノードを中国のリージョンにデプロイしている場合、kubelet ログのエラーメッセージに次のテキストが表示されることがあります。

Failed: Failed to pull image "xxxxxx.dkr.ecr.region-code.amazonaws.com.cn"

この問題を解決するには、ワーカーノードがデプロイされているのと同じリージョンにある AmazonElastic Container Registry リポジトリからイメージをプルしてください。

302

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-friendly-names

Amazon EKS ユーザーガイドIAM

IAM のトラブルシューティングこのトピックでは、IAM での Amazon EKS の使用中に表示される一般的なエラーとその回避方法について説明します。

AccessDeniedExceptionAWS API オペレーションの呼び出し時に AccessDeniedException を受け取った場合、使用しているAWS Identity and Access Management (IAM) ユーザーまたはロールの認証情報には、その呼び出しに必要なアクセス許可がありません。

An error occurred (AccessDeniedException) when calling the DescribeCluster operation: User: arn:aws:iam::111122223333:user/user_name is not authorized to perform: eks:DescribeCluster on resource: arn:aws:eks:region:111122223333:cluster/cluster_name

上記のメッセージ例では、ユーザーは Amazon EKS DescribeCluster API オペレーションを呼び出す権限を持っていません。ユーザーに Amazon EKS 管理権限を付与するには、Amazon EKS アイデンティティベースのポリシーの例 (p. 251)を参照してください。

IAM に関する一般的な情報については、『IAM ユーザーガイド』の「ポリシーを使用したアクセス制御」を参照してください。

iam:PassRole を実行する権限がないiam:PassRole アクションを実行する権限がないというエラーが表示された場合、管理者に問い合わせ、サポートを依頼する必要があります。お客様のユーザー名とパスワードを発行したのが、担当の管理者です。Amazon EKS にロールを渡すことができるようにポリシーを更新するよう、管理者に依頼します。

一部の AWS サービスでは、新しいサービスロールまたはサービスにリンクされたロールを作成せずに、既存のロールをサービスに渡すことができます。そのためには、サービスにロールを渡すアクセス許可が必要です。

以下の例のエラーは、marymajor という IAM ユーザーがコンソールを使用して Amazon EKS でアクションを実行しようする場合に発生します。ただし、アクションでは、サービスロールによって付与されたアクセス許可がサービスにある必要があります。メアリーには、ロールをサービスに渡すアクセス許可がありません。

User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole

この場合、メアリーは担当の管理者に iam:PassRole アクションを実行できるようにポリシーの更新を依頼します。

アクセスキーを表示する場合IAM ユーザーアクセスキーを作成した後は、いつでもアクセスキー ID を表示できます。ただし、シークレットアクセスキーをもう一度表示することはできません。シークレットアクセスキーを紛失した場合は、新しいキーペアを作成する必要があります。

アクセスキーは、アクセスキー ID (例: AKIAIOSFODNN7EXAMPLE) とシークレットアクセスキー (例:wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY) の 2 つの部分から構成されます。ユーザー名とパスワードと同様に、リクエストを認証するために、アクセスキー ID とシークレットアクセスキーの両方を使用する必要があります。ユーザー名とパスワードと同様に、アクセスキーをしっかり管理してください。

303

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html

Amazon EKS ユーザーガイド管理者として Amazon EKS へのアクセスを他のユーザーに許可する

Important

正規ユーザー ID を確認するためであっても、アクセスキーをサードパーティーに提供しないでください。提供すると、第三者がアカウントへの永続的アクセスを取得する場合があります。

アクセスキーペアを作成する場合、アクセスキー ID とシークレットアクセスキーを安全な場所に保存するように求めるプロンプトが表示されます。このシークレットアクセスキーは、作成時にのみ使用できます。シークレットアクセスキーを紛失した場合、新しいアクセスキーを IAM ユーザーに追加する必要があります。最大 2 つのアクセスキーを持つことができます。すでに 2 つある場合は、新しいキーペアを作成する前に、いずれかを削除する必要があります。手順を表示するには、IAM ユーザーガイドの「アクセスキーの管理」を参照してください。

管理者として Amazon EKS へのアクセスを他のユーザーに許可するAmazon EKS へのアクセスを他のユーザーに許可するには、アクセスを必要とする人またはアプリケーションの IAM エンティティ (ユーザーまたはロール) を作成する必要があります。ユーザーは、このエンティティの認証情報を使用して AWS にアクセスします。次に、Amazon EKS の適切なアクセス許可を付与するポリシーを、そのエンティティにアタッチする必要があります。

すぐに開始するには、IAM ユーザーガイドの「IAM が委任した最初のユーザーおよびグループの作成」を参照してください。

自分の AWS アカウント以外のユーザーに AmazonEKS リソースへのアクセスを許可する場合他のアカウントのユーザーや組織外のユーザーが、リソースへのアクセスに使用できるロールを作成できます。ロールを引き受けるように信頼されたユーザーを指定することができます。リソースベースのポリシーまたはアクセスコントロールリスト (ACL) をサポートするサービスの場合、それらのポリシーを使用して、リソースへのアクセスを付与できます。

詳細については、以下を参照してください。

• Amazon EKS でこれらの機能がサポートされるかどうかを確認するには、「Amazon EKS と IAM の連携 (p. 248)」を参照してください。

• 所有している AWS アカウント間でリソースへのアクセスを付与する方法については、IAM ユーザーガイドの「所有している別の AWS アカウントへのアクセスを IAM ユーザーに許可」を参照してください。

• サードパーティーの AWS アカウントにリソースへのアクセスを提供する方法については、IAM ユーザーガイドの「第三者が所有する AWS アカウントへのアクセス権を付与する」を参照してください。

• ID フェデレーションを介してアクセスを提供する方法については、IAM ユーザーガイドの「外部で認証されたユーザー (ID フェデレーション) へのアクセスの許可」を参照してください。

• クロスアカウントアクセスでのロールとリソースベースのポリシーの使用の違いの詳細については、IAM ユーザーガイドの「IAM ロールとリソースベースのポリシーとの相違点」を参照してください。

304

https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html#FindingCanonicalId

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey

https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started_create-delegated-user.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html



Amazon EKS のサービスクォータ次の表は、変更できる AWS アカウントの Amazon EKS のデフォルトのクォータを示しています。クォータの引き上げをリクエストするには、AWS サポートセンターのページを開き、必要に応じてサインインして [ケースの作成] を選択します。[Service Limit increase] を選択します。フォームに入力して送信します。

リソースデフォルトのクォータ

1 アカウント (1 リージョン) あたりの AmazonEKS クラスターの最大数

100

クラスターあたりのマネージド型ノードグループの最大数

30

マネージド型ノードグループあたりのノードの最大数

100

クラスターあたりの Fargate プロファイルの最大数

10

Fargate プロファイルあたりの最大セレクター数 5

Fargate プロファイルセレクターあたりのラベルペアの最大数

5

同時 Fargate ポッドの最大数 (リージョンあたり、アカウントあたり)

100

1 秒あたりの Fargate ポッドの最大起動数 (リージョンあたり、アカウントあたり)

1 (最大 10 までの一時バーストあり)

次の表に、変更できない Amazon EKS のクォータを示します。

リソースデフォルトのクォータ

クラスターあたりのコントロールプレーンセキュリティグループの最大数 (クラスターの作成時に指定されます)

4

クラスターあたりのパブリックエンドポイントアクセスの CIDR 範囲の最大数

40

305

https://console.aws.amazon.com/support/home#/


Amazon EKS のドキュメント履歴次の表は、Amazon EKS ユーザーガイドの主な更新や新機能の一覧です。また、お客様からいただいたフィードバックに対応するために、ドキュメントを頻繁に更新しています。

update-history-change update-history-description update-history-date

Kubernetes バージョン 1.16 Kubernetes バージョン 1.16 の新しいクラスターとバージョンアップグレードのサポートが追加されました。

April 30, 2020

サービスにリンクされたロールAWSServiceRoleForAmazonEKSを追加

サービスにリンクされたロールAWSServiceRoleForAmazonEKSを追加しました。

April 16, 2020


March 10, 2020

Amazon EKS リージョンの拡張 (p. 306)

Amazon EKS が北京 (cn-north-1) リージョンおよび寧夏(cn-northwest-1) リージョンで利用可能になりました。

February 26, 2020

Amazon FSx for Lustre CSI ドライバー

Kubernetes 1.14 Amazon EKSクラスターに Amazon FSx forLustre CSI ドライバーをインストールするトピックを追加しました。

December 23, 2019

クラスターのパブリックアクセスエンドポイントへのネットワークアクセスを制限

Amazon EKS では、KubernetesAPI サーバーのパブリックアクセスエンドポイントと通信できるCIDR 範囲を制限できるようになりました。

December 20, 2019

VPC 外部からクラスターのプライベートアクセスエンドポイントアドレスを解決

Amazon EKS では、VPC 外部から Kubernetes API サーバーのプライベートアクセスエンドポイントを解決できるようになりました。

December 13, 2019

(ベータ) Amazon EC2 A1 インスタンスワーカーノード

Amazon EKS クラスターに登録するAmazon EC2 A1 インスタンスワーカーノードを起動します。

December 4, 2019

Amazon EKS での AWS Fargate Amazon EKS Kubernetes クラスターで、Fargate でのポッドの実行がサポートされるようになりました。

December 3, 2019

AWS Outposts でのクラスターの作成

Amazon EKS では、AWSOutpost でのクラスターの作成がサポートされるようになりました。

December 3, 2019

306

https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html#kubernetes-1.16

https://docs.aws.amazon.com/eks/latest/userguide/using-service-linked-roles-eks.html




https://docs.aws.amazon.com/eks/latest/userguide/fsx-csi.html

https://docs.aws.amazon.com/eks/latest/userguide/fsx-csi.html

https://docs.aws.amazon.com/eks/latest/userguide/cluster-endpoint.html






https://docs.aws.amazon.com/eks/latest/userguide/arm-support.html

https://docs.aws.amazon.com/eks/latest/userguide/arm-support.html

https://aws.amazon.com/ec2/instance-types/a1/

https://docs.aws.amazon.com/eks/latest/userguide/fargate.html

https://docs.aws.amazon.com/eks/latest/userguide/eks-on-outposts.html

https://docs.aws.amazon.com/eks/latest/userguide/eks-on-outposts.html



Amazon EKS がカナダ (中部)(ca-central-1) リージョンで利用可能になりました。

November 21, 2019

マネージド型ノードグループ Amazon EKS マネージド型ノードグループは、Amazon EKSKubernetes クラスターのノード（Amazon EC2 インスタンス）のプロビジョニングとライフサイクル管理を自動化します。

November 18, 2019

Amazon EKS プラットフォームのバージョンの更新

CVE-2019-11253に対応する新しいプラットフォームバージョン。

November 6, 2019

Kubernetes 1.11 は Amazon EKSで廃止されました

Kubernetes バージョン 1.11 はAmazon EKS でサポートされなくなりました。サービスの中断を防ぐため、1.11 クラスターはバージョン 1.12 以降に更新してください。

November 4, 2019


Amazon EKS が南米 (サンパウロ) (sa-east-1) リージョンで利用可能になりました。

October 16, 2019

Windows サポート Kubernetes バージョン 1.14 を実行する Amazon EKS クラスターが Windows ワークロードをサポートするようになりました。

October 7, 2019

Auto Scaling Amazon EKS クラスターでサポートされるさまざまなタイプのKubernetes Auto Scaling の一部を説明する章を追加しました。

September 30, 2019

Kubernetes ダッシュボードの更新

ベータ 2.0 バージョンを使用するために Kubernetes ダッシュボードを Amazon EKS クラスターにインストールするためのトピックを更新しました。

September 28, 2019

Amazon EFS CSI ドライバー Kubernetes 1.14 Amazon EKS クラスターに Amazon EFS CSI ドライバーをインストールするトピックを追加しました。

September 19, 2019

Amazon EKS最適化 AMI ID のAmazon EC2 Systems Managerパラメータ

Amazon EC2 Systems Managerパラメータを使用して AmazonEKS最適化 AMI ID を取得するためのトピックを追加しました。このパラメータを使用すると、AMIID を検索する必要がなくなります。

September 18, 2019

Amazon EKS リソースへのタグ付け

Amazon EKS クラスターのタグ付けを管理します。

September 16, 2019

307

https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html

https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html



https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html


https://docs.aws.amazon.com/eks/latest/userguide/windows-support.html

https://docs.aws.amazon.com/eks/latest/userguide/autoscaling.html

https://docs.aws.amazon.com/eks/latest/userguide/dashboard-tutorial.html

https://docs.aws.amazon.com/eks/latest/userguide/dashboard-tutorial.html

https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html

https://docs.aws.amazon.com/eks/latest/userguide/retrieve-ami-id.html



https://docs.aws.amazon.com/eks/latest/userguide/eks-using-tags.html

https://docs.aws.amazon.com/eks/latest/userguide/eks-using-tags.html


Amazon EBS CSI ドライバー Kubernetes 1.14 Amazon EKS クラスターに Amazon EBS CSI ドライバーをインストールするトピックを追加しました。

September 9, 2019

CVE-2019-9512 およびCVE-2019-9514 用のパッチが適用された新しい Amazon EKS 最適化 AMI

Amazon EKS では、CVE-2019-9512 およびCVE-2019-9514 に対応するように Amazon EKS 最適化 AMI を更新しました。

September 6, 2019

Amazon EKS の Kubernetes 1.11を廃止

2019 年 11 月 4 日、AmazonEKS の Kubernetes バージョン 1.11 が廃止されます。同日より、新しい 1.11 クラスターを作成することはできません。Kubernetes バージョン1.11を実行している Amazon EKS クラスターはすべて、利用可能な最新のプラットフォームバージョンの Kubernetes バージョン 1.12に更新されます。

September 4, 2019

サービスアカウントの IAM ロール

Amazon EKS クラスターのサービスアカウントの IAM ロールを使用すると、 IAM ロールをKubernetes サービスアカウントに関連付けることができます。この機能を使用すると、ワーカーノード IAM ロールに拡張されたアクセス許可を提供する必要がなくなり、そのノードのポッドがAWS API を呼び出せるようになります。

September 3, 2019


September 3, 2019


Amazon EKS が中東 (バーレーン) (me-south-1) リージョンで利用可能になりました。

August 29, 2019


CVE-2019-9512 およびCVE-2019-9514 に対応する新しいプラットフォームバージョン。

August 28, 2019


CVE-2019-11247 およびCVE-2019-11249に対応する新しいプラットフォームバージョン。

August 5, 2019


Amazon EKS がアジアパシフィック (香港) (ap-east-1)リージョンで利用可能になりました。

July 31, 2019

308

https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html

https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html






https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html


https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html

https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html











Kubernetes 1.10 は Amazon EKSで廃止されました

Kubernetes バージョン 1.10 はAmazon EKS でサポートされなくなりました。サービスの中断を防ぐため、1.10 クラスターはバージョン 1.11 以降に更新してください。

July 30, 2019

ALB Ingress Controller に関するトピックが追加されました

AWS ALB Ingress Controller forKubernetes は、Ingress リソースが作成されたときに ApplicationLoad Balancer の作成をトリガーするコントローラーです。

July 11, 2019

新しい Amazon EKS 最適化 AMI 不要な kubectl バイナリを AMIから削除します。

July 3, 2019


June 18, 2019

AWS-2019-005 用のパッチが適用された新しい Amazon EKS 最適化 AMI

Amazon EKSで、AWS-2019-005 で説明されている脆弱性に対処するため、Amazon EKS 最適化 AMI が更新されました。

June 17, 2019


Kubernetes 1.11 および 1.10 クラスター用の新しいプラットフォームバージョン。Kubelet 証明書のカスタム DNS 名をサポートし、etcd パフォーマンスは向上しています。

May 21, 2019

Amazon EKS の Kubernetes 1.10を廃止

2019 年 7 月 22 日、AmazonEKS の Kubernetes バージョン 1.10 が廃止されます。同日より、新しい 1.10 クラスターを作成することはできません。Kubernetes バージョン1.10を実行している Amazon EKS クラスターはすべて、利用可能な最新のプラットフォームバージョンの Kubernetes バージョン 1.11に更新されます。

May 21, 2019

eksctl の開始方法この入門ガイドは、eksctl(Amazon EKS での Kubernetesクラスターの作成および管理用のシンプルなコマンドラインユーティリティ) を使用して、Amazon EKS の開始に必要なすべてのリソースをインストールするのに役立ちます。

May 10, 2019

309



https://docs.aws.amazon.com/eks/latest/userguide/alb-ingress.html

https://docs.aws.amazon.com/eks/latest/userguide/alb-ingress.html


https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-1.13.html




https://aws.amazon.com/security/security-bulletins/AWS-2019-005/





https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html


AWS CLI get-token コマンド (p. 306)

aws eks get-token コマンドがAWS CLI に追加されたので、クラスター API サーバー通信用のクライアントセキュリティトークンを作成するために、AWS IAMAuthenticator for Kubernetes をインストールする必要がなくなりました。この新しい機能を利用するには、インストール済みの AWSCLI を最新バージョンにアップグレードしてください。詳細については、『AWS Command LineInterface ユーザーガイド』の「AWS コマンドラインインターフェイスのインストール」を参照してください。

May 10, 2019


Kubernetes 1.12 クラスター用の新しいプラットフォームバージョン。Kubelet 証明書のカスタムDNS 名をサポートし、etcd パフォーマンスは向上しています。このバージョンでは、ワーカーノードの Kubelet デーモンによって、数秒ごとに新しい証明書が要求されるというバグが修正されています。

May 8, 2019

Prometheus チュートリアル Amazon EKS クラスターへのPrometheus のデプロイに関するトピックが追加されました。

April 5, 2019

Amazon EKS コントロールプレーンのログ記録

Amazon EKS コントロールプレーンのログ記録を使用すると、Amazon EKS コントロールプレーンからアカウントのCloudWatch Logs に直接監査ログと診断ログが提供されるため、クラスターのセキュリティ保護と運用が容易になります。

April 4, 2019

Kubernetes バージョン1.12 (p. 306)

Kubernetes バージョン 1.12 の新しいクラスターとバージョンアップグレードのサポートが追加されました。

March 28, 2019

App Mesh 入門ガイドの追加 App Mesh と Kubernetes の入門用ドキュメントが追加されました。

March 27, 2019

Amazon EKS API サーバーエンドポイントのプライベートアクセス

Amazon EKS クラスターのKubernetes API サーバーエンドポイントのパブリックアクセスを無効にする方法に関するドキュメントが追加されました。

March 19, 2019

310





https://docs.aws.amazon.com/eks/latest/userguide/prometheus.html

https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html

https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html

https://docs.aws.amazon.com/eks/latest/userguide/mesh-gs-k8s.html





Kubernetes メトリクスサーバーのインストールに関するトピックの追加

Kubernetes メトリクスサーバーは、クラスター内のリソース使用状況データを集約します。

March 18, 2019

関連するオープンソースプロジェクトのリストの追加

これらのオープンソースプロジェクトは、Amazon EKS によって管理されているクラスターを含め、AWS 上で実行されているKubernetes クラスターの機能を拡張します。

March 15, 2019

Helm のローカルインストールに関するトピックの追加

Kubernetes 用の helm パッケージマネージャーを使用すると、Kubernetes クラスターにアプリケーションをインストールし、管理できます。このトピックは、helm バイナリと tiller バイナリをローカルにインストールして実行する際に役立ちます。これにより、ローカルシステムでhelm CLI を使用してチャートをインストールおよび管理することができます。

March 11, 2019


CVE-2019-1002100 に対応するために Amazon EKS Kubernetes1.11 クラスターをパッチレベル1.11.8 に更新する新しいプラットフォームバージョン。

March 8, 2019

クラスターの上限の引き上げ Amazon EKS では、リージョン内で作成できるクラスターの数が3 から 50 に増えました。

February 13, 2019


Amazon EKS を欧州 (ロンドン)(eu-west-2)、欧州 (パリ) (eu-west-3)、アジアパシフィック(ムンバイ) (ap-south-1) の各リージョンで利用できるようになりました。

February 13, 2019

ALAS-2019-1156 用のパッチが適用された新しい Amazon EKS 最適化 AMI

Amazon EKSで、ALAS-2019-1156 で説明されている脆弱性に対処するため、Amazon EKS 最適化 AMI が更新されました。

February 11, 2019


Amazon EKS がアジアパシフィック (ソウル) (ap-northeast-2) リージョンで利用可能になりました。

January 9, 2019

ALAS2-2019-1141 用のパッチが適用された新しい Amazon EKS最適化 AMI

Amazon EKSで、ALAS2-2019-1141 で参照されている CVE に対処するため、Amazon EKS 最適化 AMI が更新されました。

January 9, 2019

311

https://docs.aws.amazon.com/eks/latest/userguide/metrics-server.html









https://discuss.kubernetes.io/t/kubernetes-security-announcement-v1-11-8-1-12-6-1-13-4-released-to-address-medium-severity-cve-2019-1002100/5147

https://docs.aws.amazon.com/eks/latest/userguide/service_limits.html




https://alas.aws.amazon.com/ALAS-2019-1156.html




https://alas.aws.amazon.com/AL2/ALAS-2019-1141.html



さらに、Amazon EKS は、欧州 (フランクフルト) (eu-central-1)、アジアパシフィック (東京) (ap-northeast-1)、アジアパシフィック (シンガポール) (ap-southeast-1)、およびアジアパシフィック (シドニー)(ap-southeast-2) の 4 つの追加リージョンでも利用できるようになりました。

December 19, 2018

Amazon EKS クラスターの更新 Amazon EKS クラスターのKubernetes バージョン更新およびワーカーノード交換のドキュメントが追加されました。

December 12, 2018


Amazon EKS が欧州 (ストックホルム) (eu-north-1) リージョンで利用可能になりました。

December 11, 2018


CVE-2018-1002105 に対応するため、Kubernetes をパッチレベル 1.10.11 に更新する新しいプラットフォームバージョン。

December 4, 2018

Application Load Balancer 進入コントローラーバージョンのバージョン 1.0.0 のサポートが追加されました

Application Load Balancer 進入コントローラーで、AWS の公式サポートを備えたバージョン 1.0.0がリリースされました。

November 20, 2018

CNI ネットワーク設定のサポートを追加しました。

Kubernetes 向け Amazon VPCCNI プラグインのバージョン1.2.1 が、セカンダリポッドネットワークインターフェイスのカスタムネットワーク設定をサポートするようになりました。

October 16, 2018

MutatingAdmissionWebhook とValidatingAdmissionWebhook のサポートが追加されました。

Amazon EKS プラットフォームのバージョン 1.10-eks.2 がMutatingAdmissionWebhookおよびValidatingAdmissionWebhookアドミッションコントローラーをサポートするようになりました。

October 10, 2018

パートナー AMI 情報が追加されました

Canonical 社は Amazon EKS と提携し、クラスターで使用できるワーカーノード AMI を作成しました。

October 3, 2018

AWS CLI update-kubeconfig コマンドの説明が追加されました。

Amazon EKS で update-kubeconfig が AWS CLI に追加され、クラスターにアクセスするための kubeconfig ファイルの作成プロセスが簡単になりました。

September 21, 2018

312




https://docs.aws.amazon.com/eks/latest/userguide/update-workers.html



https://aws.amazon.com/security/security-bulletins/AWS-2018-020/





https://docs.aws.amazon.com/eks/latest/userguide/cni-custom-network.html

https://docs.aws.amazon.com/eks/latest/userguide/cni-custom-network.html




https://docs.aws.amazon.com/eks/latest/userguide/eks-partner-amis.html

https://docs.aws.amazon.com/eks/latest/userguide/eks-partner-amis.html




新しい Amazon EKS 最適化AMI。

Amazon EKS で、さまざまなセキュリティ修正と AMI 最適化を提供する Amazon EKS 最適化AMI (GPU サポートあり/なし) が更新されました。

September 13, 2018


Amazon EKS が欧州 (アイルランド) (eu-west-1) リージョンで利用可能になりました。

September 5, 2018


Kubernetes アグリゲーションレイヤーと水平ポッドオートスケーラー (HPA) をサポートする新しいプラットフォームバージョン。

August 31, 2018

新しい Amazon EKS 最適化 AMIと GPU サポート

Amazon EKS は、Amazon EKS最適化 AMI を更新し、新しいAWS CloudFormation ワーカーノードのテンプレートとブートストラップスクリプトを使用できます。さらに、新しい AmazonEKS 最適化 AMI GPU サポートが利用可能になりました。

August 22, 2018

ALAS2-2018-1058 用のパッチが適用された新しい Amazon EKS最適化 AMI

Amazon EKSで、ALAS2-2018-1058 で参照されている CVE に対処するため、Amazon EKS 最適化 AMI が更新されました。

August 14, 2018

Amazon EKS 最適化 AMI のビルドスクリプト

Amazon EKS で、Amazon EKS最適化 AMI のビルドに使用されているビルドスクリプトをオープンソース化されました。これらのビルドスクリプトは現在 GitHubで入手できます。

July 10, 2018

Amazon EKS 初回リリース (p. 306)

サービス開始時の初版ドキュメント

June 5, 2018

313





https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/

https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/







https://docs.aws.amazon.com/eks/latest/userguide/gpu-ami.html






https://alas.aws.amazon.com/AL2/ALAS-2018-1058.html



aws documentation - amazon eks - ユーザーガイド...aws fargate..... 112 fargate...

Documents