Amazon EKS でのアプリケーション負荷分散 - Amazon EKS

Amazon EKS でのアプリケーション負荷分散

Kubernetes Ingress を作成するとき、アプリケーショントラフィックの負荷分散を行う AWS Application Load Balancer (ALB) がプロビジョニングされます。詳細については、「Application Load Balancer ユーザーガイド」の「Application Load Balancer とは?」および Kubernetes ドキュメントの「Ingress」を参照してください。ALB は、ノードまたは AWS Fargate にデプロイされたポッドで使用できます。ALB をパブリックサブネットまたはプライベートサブネットにデプロイできます。

アプリケーショントラフィックは、OSI モデルの L7 で負荷分散されます。L4 でネットワークトラフィックの負荷を分散するには、Kubernetes ServiceLoadBalancer タイプを作成することができます。このタイプは、 AWS ネットワークロードバランサーをプロビジョニングします。詳細については、「Amazon EKS でのネットワーク負荷分散」を参照してください。2 種類の負荷分散の違いについては、AWS ウェブサイトの「Elastic Load Balancing の特徴」を参照してください。

Prerequisites

あるアプリケーションに対してアプリケーショントラフィックの負荷分散を行うには、次の要件を満たす必要があります。

  • 既存のクラスターがある。既存のクラスターがない場合は、「Amazon EKS の使用開始」を参照してください。既存のクラスターのバージョンを更新する必要がある場合は、クラスターの更新 を参照して下さい。

  • クラスターにプロビジョニングされた AWS Load Balancer Controller。詳細については、「AWS Load Balancer Controller」を参照してください。

  • 少なくとも 2 つのサブネットが異なるアベイラビリティーゾーンに存在している。AWS Load Balancer Controller は、各アベイラビリティーゾーンから 1 つずつサブネットを選択します。タグ付けされたサブネットがアベイラビリティーゾーンで複数見つかった場合、コントローラーは、サブネット ID が辞書式順序で最初に来るサブネットを選択します。

    ワーカーノードにアタッチされた複数のセキュリティグループを使用している場合は、次のように 1 つのセキュリティグループにタグを付ける必要があります。cluster-name をクラスター名に置き換えます。

    • キーkubernetes.io/cluster/cluster-name

    • shared または owned

  • AWS Load Balancer Controller バージョン v2.1.1 以前を使用している場合、サブネットに次のようにタグ付けする必要があります。バージョン 2.1.2 以降を使用している場合、このタグはオプションです。ただし、次のいずれかの場合は、サブネットにタグ付けることをお勧めします。同じVPCで実行されている複数のクラスターがあるか、VPCでサブネットを共有する複数の AWS サービスがあります。または、各クラスターに対してロードバランサーをプロビジョニングする場所を詳細に制御する必要があります。cluster-name をクラスター名に置き換えます。

    • キーkubernetes.io/cluster/cluster-name

    • shared または owned

  • パブリックサブネットとプライベートサブネットは次の要件を満たしている必要があります。Service オブジェクトまたは Ingress オブジェクトのアノテーションとしてサブネット ID を明示的に指定しない限り、これは例外です。Service オブジェクトまたは 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 クラスター VPC の作成」を参照してください。

      • キー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 クラスター VPC の作成」を参照してください。

      • キーkubernetes.io/role/elb

      • 1

    サブネットロールのタグが明示的に追加されていない場合、Kubernetes サービスコントローラーはクラスター VPC サブネットのルートテーブルを調べます。これは、サブネットがプライベートかパブリックかを判断するためです。この動作に頼らないことをお勧めします。代わりに、プライベートまたはパブリックロールタグを明示的に追加します。AWS ロードバランサーコントローラーは、ルートテーブルを検査しません。また、自動検出を正常に実行するには、プライベートタグとパブリックタグが必要です。

Considerations

  • Kubernetes Ingress リソースが アノテーションを使用してクラスターで作成されるたびに、AWS Load Balancer Controller によって ALB およびサポートに必要な AWS リソースと kubernetes.io/ingress.class: alb のアノテーションが作成されます。Ingress リソースは ALB を設定して、HTTP または HTTPS トラフィックをクラスター内の別のポッドにルーティングします。Ingress オブジェクトが AWS Load Balancer Controller を使用するためには、Kubernetes Ingress 仕様に次のアノテーションを追加します。詳細については、GitHub の「Ingress specification (Ingress 仕様)」を参照してください。

    annotations: kubernetes.io/ingress.class: alb
  • AWS Load Balancer Controller は、次のトラフィックモードをサポートしています。

    • インスタンス – クラスター内のノードを ALB のターゲットとして登録します。ALB に到達するトラフィックは、サービスの NodePort にルーティングされてから、ポッドにプロキシされます。これがデフォルトのトラフィックモードです。alb.ingress.kubernetes.io/target-type: instance の注釈を使用して明示的に指定することもできます。

      注記

      このトラフィックモードを使用するには、Kubernetes サービスで NodePort または "LoadBalancer" タイプを指定する必要があります。

    • IP - ポッドを ALB のターゲットとして登録します。ALB に到達するトラフィックは、サービスのポッドに直接ルーティングされます。このトラフィックモードを使用するには、 alb.ingress.kubernetes.io/target-type: ip の注釈を指定する必要があります。IP ターゲットタイプは、ターゲットのポッドが Fargate で実行されている場合に必要です。

  • コントローラーによって作成された ALB にタグを付けるには、次のアノテーションをコントローラーに追加します: alb.ingress.kubernetes.io/tags。AWS Load Balancer Controller でサポートされるすべての使用可能なアノテーションのリストについては、GitHub の「Ingress アノテーション」を参照してください。

  • ALB コントローラーのバージョンをアップグレードまたはダウングレードすると、ALB コントローラーのバージョンに依存する機能が大きく変更される可能性があります。各リリースで導入された新しい変更の詳細については、ALB Controller リリースノートGitHub で。

IngressGroups を使用して複数の Ingress リソース間でアプリケーションロードバランサーを共有するには

Ingress を グループに入れるには、Kubernetes Ingress リソース仕様に次のアノテーションを追加します。

alb.ingress.kubernetes.io/group.name: my-group

グループ名は、次のようにする必要があります。

  • 長さが 63 文字以下。

  • 名前は、小文字の英文字、-、および . で構成されます。

  • 数字または文字で始めます。

コントローラは、同じ Ingress グループ内のすべての Ingress の Ingress ルールを自動的にマージします。これは、単一のALBでそれらをサポートしています。Ingress で定義されたほとんどのアノテーションは、その Ingress で定義されたパスにのみ適用されます。デフォルトでは、Ingress リソースはどの Ingress グループにも属していません。

警告

潜在的なセキュリティリスク: Ingress リソースを作成または変更する RBAC 権限を持つすべての Kubernetes ユーザーが同じ信頼境界内にある場合にのみ、Ingress に Ingress グループを指定します。アノテーションをグループ名で追加すると、他の Kubernetes ユーザが、同じ Ingress グループに属する Ingress を作成または変更する可能性があります。これにより、優先度の高いルールで既存のルールを上書きするなど、望ましくない動作が発生する可能性があります。

Ingress リソースの順序番号を追加できます。

alb.ingress.kubernetes.io/group.order: '10'

番号は 1 ~ 1000 の範囲で指定できます。同じ Ingress グループ内のすべての Ingress について、最小の番号を持つものが最初に評価されます。このアノテーションがない Ingress はすべて、値 0 で評価されます。番号が小さいルールと番号が大きいルールが重複すると、番号が小さいルールが上書きされる可能性があります。デフォルトでは、同じIngressグループ内の Ingresses 間のルールは、辞書式順序に基づいて名前空間と名前が決定されます。

重要

同じ Ingress グループの各 Ingress に、一意のプライオリティ番号があることを確認します。  Ingress 間で重複する順序番号を持つことはできません。

サンプルアプリケーションをデプロイするには

Amazon EC2 ノード、Fargate ポッド、またはその両方を持つクラスターで、サンプルアプリケーションを実行できます。

  1. Fargate にデプロイする場合は、Fargate プロファイルを作成します。Fargate にデプロイしない場合は、このステップを省略してください。次のコマンドを実行するか、コマンドにある AWS Management Console と name に同じ値を使用して、namespace でプロファイルを作成できます。

    eksctl create fargateprofile \ --cluster my-cluster \ --region region-code \ --name alb-sample-app \ --namespace game-2048
  2. サンプルアプリケーションとしてゲーム 2048 をデプロイし、AWS Load Balancer Controller が Ingress オブジェクトの結果として AWS ALB を作成することを確認します。デプロイ先のサブネットのタイプに関する手順を実行します。

    • 、Public

      kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.3.0/docs/examples/2048/2048_full.yaml
    • プライベート

      1. マニフェストをダウンロードします。

        curl -o 2048_full.yaml https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.3.0/docs/examples/2048/2048_full.yaml
      2. ファイルを編集して、alb.ingress.kubernetes.io/scheme: internet-facing と記述された行を探します。

      3. internet-facinginternal に変更し、ファイルを保存します。

      4. マニフェストをクラスターに適用します。

        kubectl apply -f 2048_full.yaml
  3. 数分後、次のコマンドを使用して、Ingress リソースが作成されたことを確認します。

    kubectl get ingress/ingress-2048 -n game-2048

    出力:

    NAME CLASS HOSTS ADDRESS PORTS AGE ingress-2048 <none> * k8s-game2048-ingress2-xxxxxxxxxx-yyyyyyyyyy.us-west-2.elb.amazonaws.com 80 2m32s
    注記

    プライベートサブネットでロードバランサーを作成した場合、前の出力のアドレスの前に internal- が付けられます。Ingress が数分後に作成されていない場合は、次のコマンドを実行して Load Balancer Controller のログを表示します。これらのログには、デプロイに関する問題の診断に使用できるエラーメッセージが含まれている場合があります。

    kubectl logs -n kube-system deployment.apps/aws-load-balancer-controller
  4. パブリックサブネットにデプロイした場合は、ブラウザを開き、前のコマンドの出力から ADDRESS URL に移動してサンプルアプリケーションを表示します。何も表示されない場合は、ブラウザを更新してからもう一度試してください。プライベートサブネットにデプロイした場合は、踏み台ホストなどの VPC 内のデバイスからページを表示する必要があります。詳細については、AWS での Linux 踏み台ホストを参照してください。

    
                    2048 サンプルアプリケーション
  5. サンプルアプリケーションの試用が終了したら、次のコマンドを実行してサンプルアプリケーションを削除します。

    kubectl delete -f https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.3.0/docs/examples/2048/2048_full.yaml