**このページの改善にご協力ください** このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。 # Application Load Balancer を使用してアプリケーションと HTTP トラフィックをルーティングする **注記** **新規:** Amazon EKS Auto Mode は、ロードバランシングの定型作業を自動化します。詳細については、以下を参照してください。 [サンプルロードバランサーワークロードを EKS 自動モードにデプロイする](auto-elb-example.md) [IngressClass を作成して Application Load Balancer を設定する](auto-configure-alb.md) Kubernetes `ingress` を作成するとき、アプリケーショントラフィックの負荷分散を行う AWS Application Load Balancer (ALB) がプロビジョニングされます。詳細については、「*Application Load Balancer ユーザーガイド*」の「[Application Load Balancer とは？](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)」および Kubernetes ドキュメントの「[Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/)」を参照してください。ALB は、ノードまたは AWS Fargate にデプロイされたポッドで使用できます。ALB をパブリックサブネットまたはプライベートサブネットにデプロイできます。 アプリケーショントラフィックは、OSI モデルの `L7` で負荷分散されます。`L4` でネットワークトラフィックの負荷を分散するには、`LoadBalancer` タイプの Kubernetes `service` をデプロイします このタイプは、 AWS Network Load Balancer をプロビジョニングします。詳細については、「[Network Load Balancer を使用して TCP および UDP トラフィックをルーティングする](network-load-balancing.md)」を参照してください。2 種類の負荷分散の違いについては、AWS ウェブサイトの「[Elastic Load Balancing の特徴](https://aws.amazon.com/elasticloadbalancing/features/)」を参照してください。 ## 前提条件 あるアプリケーションに対してアプリケーショントラフィックの負荷分散を行うには、次の要件を満たす必要があります。 + 既存のクラスターがある。既存のクラスターがない場合は、「[Amazon EKS の使用を開始する](getting-started.md)」を参照してください。既存のクラスターのバージョンを更新する必要がある場合は、[既存のクラスターを新しい Kubernetes バージョンに更新する](update-cluster.md) を参照して下さい。 + クラスターに AWS Load Balancer Controller がデプロイされている。詳細については、「[AWS Load Balancer Controller を使用してインターネットトラフィックをルーティングする](aws-load-balancer-controller.md)」を参照してください。バージョン `2.7.2` 以降をお勧めします。 + 少なくとも 2 つのサブネットが異なるアベイラビリティーゾーンに存在している。AWS Load Balancer Controller は、各アベイラビリティーゾーンから 1 つずつサブネットを選択します。タグ付けされたサブネットがアベイラビリティーゾーンで複数見つかった場合、コントローラーは、サブネット ID が辞書式順序で最初に来るサブネットを選択します。各サブネットには最低 8 個の利用可能な IP アドレスが必要です。 ワーカーノードにアタッチされた複数のセキュリティグループを使用している場合は、次のように 1 つのセキュリティグループにタグを付ける必要があります。{{マイクラスター}} の部分は自分のクラスター名に置き換えます。 + **キー** – `kubernetes.io/cluster/` + **値** – `shared` または `owned` + AWS Load Balancer Controller バージョン `2.1.1` 以前を使用している場合、サブネットに次のようにタグ付けする必要があります。バージョン `2.1.2` 以降を使用している場合、このタグ付けはオプションです。ただし、次のいずれかの場合は、サブネットにタグ付けることをお勧めします。同じVPCで実行されている複数のクラスターがあるか、VPCでサブネットを共有する複数の AWS サービスがあります。または、各クラスターに対してロードバランサーをプロビジョニングする場所を詳細に制御する必要があります。{{マイクラスター}} の部分は自分のクラスター名に置き換えます。 + **キー** – `kubernetes.io/cluster/` + **値** – `shared` または `owned` + パブリックサブネットとプライベートサブネットは次の要件を満たしている必要があります。サービスオブジェクトまたは Ingress オブジェクトのアノテーションとしてサブネット ID を明示的に指定しない限り、これは例外です。サービスオブジェクトまたは Ingress オブジェクトのアノテーションとしてサブネット ID を明示的に指定して、ロードバランサーをプロビジョニングすることを想定しています。このような状況では、Kubernetesと AWS Load Balancer Controller は、これらのサブネットを直接使用してロードバランサーを作成します。次のタグは必要ありません。 + **プライベートサブネット** — 次の形式でタグ付けする必要があります。これは、Kubernetes と AWS ロードバランサーコントローラーが、サブネットを内部ロードバランサーに使用できることを認識できるようにするためです。`eksctl` または Amazon EKS AWS CloudFormation テンプレートを使用して、2020 年 3 月 26 日以降に VPC を作成する場合、サブネットは、作成時に適切にタグ付けされます。Amazon EKS AWS CloudFormation VPC テンプレートの詳細については、「[Amazon EKS クラスターの Amazon VPC を作成する](creating-a-vpc.md)」を参照してください。 + **キー** – `kubernetes.io/role/internal-elb` + **値** – `1` + **パブリックサブネット** — 次の形式でタグ付けする必要があります。これは、Kubernetes は、外部ロードバランサー用に指定されたサブネットのみを使用できることを認識できるようにするためです。この方法では、Kubernetes は各アベイラビリティーゾーンでパブリックサブネットを (サブネット ID に基づいて辞書順に) 選択しません `eksctl` または Amazon EKS AWS CloudFormation テンプレートを使用して、2020 年 3 月 26 日以降に VPC を作成する場合、サブネットは、作成時に適切にタグ付けされます。Amazon EKS AWS CloudFormation VPC テンプレートの詳細については、「[Amazon EKS クラスターの Amazon VPC を作成する](creating-a-vpc.md)」を参照してください。 + **キー** – `kubernetes.io/role/elb` + **値** – `1` サブネットロールタグが明示的に追加されていない場合、Kubernetes サービスコントローラーはクラスター VPC サブネットのルートテーブルを調べます。これは、サブネットがプライベートかパブリックかを判断するためです。この動作に頼らないことをお勧めします。代わりに、プライベートまたはパブリックロールタグを明示的に追加します。AWS Load Balancer Controller は、ルートテーブルを検査しません。また、自動検出を正常に実行するには、プライベートタグとパブリックタグが必要です。 + Kubernetes のイングレスリソースが `kubernetes.io/ingress.class: alb` アノテーションを使用してクラスターで作成されるたびに、[AWS Load Balancer Controller](https://github.com/kubernetes-sigs/aws-load-balancer-controller) により ALB およびサポートされる必要な AWS リソースが作成されます。イングレスリソースは、HTTP または HTTPS トラフィックをクラスター内の別の Pod にルーティングするように ALB を設定します。イングレスオブジェクトで AWS Load Balancer Controller を使用できるようにするには、Kubernetes イングレス仕様に次のアノテーションを追加します。詳細については、GitHub の「[Ingress specification (Ingress 仕様)](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/ingress/spec/)」を参照してください。 ``` annotations: kubernetes.io/ingress.class: alb ``` **注記** `IPv6` Pod への負荷分散を行う場合は、イングレス仕様に次のアノテーションを追加します。`IPv6` を使用して負荷分散を行えるのは、IP ターゲットにのみです。インスタンスターゲットには行えません。このアノテーションを使用しない場合、負荷分散には `IPv4` が使用されます。 ``` alb.ingress.kubernetes.io/ip-address-type: dualstack ``` + AWS Load Balancer Controller は、次のトラフィックモードをサポートしています。 + **インスタンス** – クラスター内のノードを ALB のターゲットとして登録します。ALB に到達するトラフィックは、サービスの `NodePort` にルーティングされてから、Pod にプロキシされます。これがデフォルトのトラフィックモードです。`alb.ingress.kubernetes.io/target-type: instance` の注釈を使用して明示的に指定することもできます。 **注記** Kubernetes サービスでは、このトラフィックモードを使用する `NodePort` または `LoadBalancer` タイプを指定する必要があります。 + **IP** － ポッドを ALB のターゲットとして登録します。ALB に到達するトラフィックは、サービスの Pod に直接ルーティングされます。このトラフィックモードを使用するには、 `alb.ingress.kubernetes.io/target-type: ip` の注釈を指定する必要があります。IP ターゲットタイプは、ターゲット Pod が Fargate または Amazon EKS Hybrid Nodes で実行されている場合には必須です。 + コントローラーによって作成された ALB にタグを付けるには、次のアノテーションをコントローラーに追加します: `alb.ingress.kubernetes.io/tags`。AWS Load Balancer Controller でサポートされるすべての使用可能なアノテーションのリストについては、GitHub の「[Ingress アノテーション](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/ingress/annotations/)」を参照してください。 + ALB コントローラーのバージョンをアップグレードまたはダウングレードすると、ALB コントローラーのバージョンに依存する機能が大きく変更される可能性があります。各リリースで導入された新しい変更の詳細については、GitHub で [ALB Controller リリースノート](https://github.com/kubernetes-sigs/aws-load-balancer-controller/releases)を参照してください。 ## イングレスグループで ALB を再利用する `IngressGroups` を使用して複数のサービスのリソース間で Application Load Balancer を共有できます。 イングレスをグループに入れるには、Kubernetes のイングレスリソース仕様に次のアノテーションを追加します。 ``` alb.ingress.kubernetes.io/group.name: my-group ``` グループ名は、次のようにする必要があります。 + 長さが 63 文字以下。 + 名前は、小文字の英文字、`-`、および `.` で構成されます。 + 数字または文字で始めます。 コントローラーは、同じイングレスグループ内のすべてのイングレスのイングレスルールを自動的にマージします。これは、単一のALBでそれらをサポートしています。イングレスで定義されたほとんどのアノテーションは、そのイングレスで定義されたパスにのみ適用されます。デフォルトでは、イングレスリソースはどのイングレスグループにも属していません。 **警告** **潜在的なセキュリティリスク** イングレスリソースを作成または変更する RBAC 権限を持つすべての Kubernetes ユーザーが同じ信頼境界内にいる場合にのみ、イングレスにイングレスグループを指定します。アノテーションをグループ名で追加すると、他の Kubernetes ユーザーが、同じイングレスグループに属するイングレスを作成または変更する可能性があります。これにより、優先度の高いルールで既存のルールを上書きするなど、望ましくない動作が発生する可能性があります。 イングレスリソースの順序番号を追加できます。 ``` alb.ingress.kubernetes.io/group.order: '10' ``` 番号は 1 ～ 1000 の範囲で指定できます。同じイングレスグループ内のすべてのイングレスについて、最小の番号を持つものが最初に評価されます。このアノテーションがないイングレスはすべて、値 0 で評価されます。番号が小さいルールと番号が大きいルールが重複すると、番号が小さいルールが上書きされる可能性があります。デフォルトでは、同じイングレスグループ内のイングレス間のルールの順序は、名前空間と名前に基づき辞書式順序で決定されます。 **重要** 同じイングレスグループの各イングレスに、一意のプライオリティ番号があることを確認します。　 イングレス間で重複する順序番号を持つことはできません。 ## (オプション) サンプルアプリケーションをデプロイする + クラスター VPC に少なくとも 1 つのパブリックサブネットまたはプライベートサブネットが存在する。 + クラスターに AWS Load Balancer Controller がデプロイされている。詳細については、「[AWS Load Balancer Controller を使用してインターネットトラフィックをルーティングする](aws-load-balancer-controller.md)」を参照してください。バージョン `2.7.2` 以降をお勧めします。 Amazon EC2 ノード、Fargate ポッド、またはその両方を持つクラスターで、サンプルアプリケーションを実行できます。 1. Fargate にデプロイしない場合は、このステップを省略してください Fargate にデプロイする場合は、Fargate プロファイルを作成します。次のコマンドを実行するか、コマンドにある AWS マネジメントコンソール と `name` に同じ値を使用して、[`namespace`](fargate-profile.md#create-fargate-profile) でプロファイルを作成できます。example values は実際に使用する値に置き換えます。 ``` eksctl create fargateprofile \ --cluster my-cluster \ --region region-code \ --name alb-sample-app \ --namespace game-2048 ``` 1. サンプルアプリケーションとしてゲーム [2048](https://play2048.co/) をデプロイし、AWS Load Balancer Controller がイングレスオブジェクトの結果として AWS ALB を作成することを確認します。デプロイ先のサブネットのタイプに関する手順を実行します。 1. `IPv6` ファミリーを使用して作成したクラスター内の Pod にデプロイしている場合には、次のステップに進みます。 + **Public**:: ``` kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.14.1/docs/examples/2048/2048_full.yaml ``` + **プライベート**:: 1. マニフェストをダウンロードします。 ``` curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.14.1/docs/examples/2048/2048_full.yaml ``` 1. ファイルを編集して、`alb.ingress.kubernetes.io/scheme: internet-facing` と記述された行を探します。 1. {{インターネット接続}}を `internal` に変更し、ファイルを保存します。 1. マニフェストをクラスターに適用します。 ``` kubectl apply -f 2048_full.yaml ``` 1. [IPv6 ファミリー](cni-ipv6.md)を使用して作成したクラスター内の Pod にデプロイする場合、次の手順を完了します。 1. マニフェストをダウンロードします。 ``` curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.14.1/docs/examples/2048/2048_full.yaml ``` 1. エディタでファイルを開き、イングレス仕様のアノテーションに次の行を追加します。 ``` alb.ingress.kubernetes.io/ip-address-type: dualstack ``` 1. インターネット向けの Pod ではなく、内部の Pod への負荷分散を行う場合は、`alb.ingress.kubernetes.io/scheme: {{internet-facing}} ` という行を `alb.ingress.kubernetes.io/scheme: internal` に変更します。 1. ファイルを保存します。 1. マニフェストをクラスターに適用します。 ``` kubectl apply -f 2048_full.yaml ``` 1. 数分後、次のコマンドを使用して、イングレスリソースが作成されたことを確認します。 ``` kubectl get ingress/ingress-2048 -n game-2048 ``` 出力例は次のとおりです。 ``` NAME CLASS HOSTS ADDRESS PORTS AGE ingress-2048 * k8s-game2048-ingress2-xxxxxxxxxx-yyyyyyyyyy.region-code.elb.amazonaws.com 80 2m32s ``` **注記** プライベートサブネットでロードバランサーを作成した場合、前の出力の `ADDRESS` の下の値の前に `internal-` が付けられます。 イングレスが数分後に作成されていない場合は、次のコマンドを実行して AWS Load Balancer Controller のログを表示します。これらのログには、デプロイに関する問題の診断に使用できるエラーメッセージが含まれている場合があります。 ``` kubectl logs -f -n kube-system -l app.kubernetes.io/instance=aws-load-balancer-controller ``` 1. パブリックサブネットにデプロイした場合は、ブラウザを開き、前のコマンドの出力から `ADDRESS` URL に移動してサンプルアプリケーションを表示します。何も表示されない場合は、ブラウザを更新してからもう一度試してください。プライベートサブネットにデプロイした場合は、踏み台ホストなどの VPC 内のデバイスからページを表示する必要があります。詳細については、[AWS での Linux 踏み台ホスト](https://aws.amazon.com/quickstart/architecture/linux-bastion/)を参照してください。 ![2048 サンプルアプリケーション](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/2048.png) 1. サンプルアプリケーションの試用が終了したら、次のコマンドのいずれかを実行して削除します。 + ダウンロードしたコピーを適用するのではなくマニフェストを適用した場合は、次のコマンドを使用します。 ``` kubectl delete -f https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.14.1/docs/examples/2048/2048_full.yaml ``` + マニフェストをダウンロードして編集した場合は、次のコマンドを使用します。 ``` kubectl delete -f 2048_full.yaml ```