メインコンテンツまでスキップ
IntroFundamentalsObservabilitySecurityNetworkingAutomationAI/MLTroubleshooting
Switch to Essentials →

IPモード

前述のように、作成したNLBは「インスタンスモード」で動作しています。インスタンスターゲットモードはAWS EC2インスタンス上で実行されているPodをサポートしています。このモードでは、AWS NLBはインスタンスにトラフィックを送信し、個々のワーカーノード上のkube-proxyがKubernetesクラスター内の1つ以上のワーカーノードを介してPodにトラフィックを転送します。

AWS Load Balancer Controllerは、「IPモード」で動作するNLBの作成もサポートしています。このモードでは、AWS NLBはKubernetesクラスター内のワーカーノードを経由する余分なネットワークホップを排除して、Serviceの背後にあるKubernetes Podに直接トラフィックを送信します。IPターゲットモードは、AWS EC2インスタンスとAWS Fargateの両方で実行されているPodをサポートしています。

IPモード

前の図は、ターゲットグループモードがインスタンスとIPの場合で、アプリケーショントラフィックの流れがどのように異なるかを説明しています。

ターゲットグループモードがインスタンスの場合、トラフィックは各ノードに作成されたServiceのノードポート経由で流れます。このモードでは、kube-proxyがこのServiceを実行しているPodにトラフィックをルーティングします。ServiceのPodは、ロードバランサーからトラフィックを受信したノードとは異なるノードで実行されている可能性があります。ServiceA（緑）とServiceB（ピンク）は「インスタンスモード」で動作するように設定されています。

一方、ターゲットグループモードがIPの場合、トラフィックはロードバランサーからServiceのPodに直接流れます。このモードでは、kube-proxyのネットワークホップをバイパスします。ServiceC（青）は「IPモード」で動作するように設定されています。

前の図の数字は以下を表しています。

  1. ServiceがデプロイされているEKSクラスター
  2. Serviceを公開するELBインスタンス
  3. インスタンスまたはIPのいずれかに設定できるターゲットグループモードの設定
  4. Serviceが公開されているロードバランサーに設定されたリスナープロトコル
  5. Serviceの宛先を決定するために使用されるターゲットグループルール設定

NLBをIPターゲットモードで構成したい理由はいくつかあります：

  1. 受信接続のためのより効率的なネットワークパスを作成し、EC2ワーカーノード上のkube-proxyをバイパスします
  2. externalTrafficPolicyや様々な構成オプションのトレードオフなどの側面を考慮する必要がなくなります
  3. アプリケーションがEC2ではなくFargateで実行されている場合

NLBの再構成​

NLBをIPモードを使用するように再構成し、インフラストラクチャにどのような影響があるかを見てみましょう。

これはServiceを再構成するために適用するパッチです：

~/environment/eks-workshop/modules/exposing/load-balancer/ip-mode/nlb.yaml
apiVersion: v1
kind: Service
metadata:
  name: ui-nlb
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
  namespace: ui

kustomizeでマニフェストを適用します：

~$kubectl apply -k ~/environment/eks-workshop/modules/exposing/load-balancer/ip-mode


ロードバランサーの構成が更新されるまで数分かかります。以下のコマンドを実行して、アノテーションが更新されたことを確認します：


~$kubectl describe service/ui-nlb -n ui
...
Annotations:              service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
...


以前と同じURLを使用してアプリケーションにアクセスできるはずですが、NLBは現在IPモードを使用してアプリケーションを公開しています。


~$ALB_ARN=$(aws elbv2 describe-load-balancers --query 'LoadBalancers[?contains(LoadBalancerName, `k8s-ui-uinlb`) == `true`].LoadBalancerArn' | jq -r '.[0]')
~$TARGET_GROUP_ARN=$(aws elbv2 describe-target-groups --load-balancer-arn $ALB_ARN | jq -r '.TargetGroups[0].TargetGroupArn')
~$aws elbv2 describe-target-health --target-group-arn $TARGET_GROUP_ARN
{
    "TargetHealthDescriptions": [
        {
            "Target": {
                "Id": "10.42.180.183",
                "Port": 8080,
                "AvailabilityZone": "us-west-2a"
            },
            "HealthCheckPort": "8080",
            "TargetHealth": {
                "State": "initial",
                "Reason": "Elb.RegistrationInProgress",
                "Description": "Target registration is in progress"
            }
        }
    ]
}


前のセクションで観察した3つのターゲットから、たった1つのターゲットに変わっていることに注目してください。なぜでしょうか？EKSクラスター内のEC2インスタンスを登録する代わりに、ロードバランサーコントローラーは現在個々のPodを登録し、トラフィックを直接送信しています。これはAWS VPC CNIとPodそれぞれがファーストクラスのVPC IPアドレスを持つという事実を活用しています。


uiコンポーネントを3つのレプリカにスケールアップして、何が起こるか見てみましょう：


~$kubectl scale -n ui deployment/ui --replicas=3
~$kubectl wait --for=condition=Ready pod -n ui -l app.kubernetes.io/name=ui --timeout=60s


ロードバランサーのターゲットを再度確認します：


~$ALB_ARN=$(aws elbv2 describe-load-balancers --query 'LoadBalancers[?contains(LoadBalancerName, `k8s-ui-uinlb`) == `true`].LoadBalancerArn' | jq -r '.[0]')
~$TARGET_GROUP_ARN=$(aws elbv2 describe-target-groups --load-balancer-arn $ALB_ARN | jq -r '.TargetGroups[0].TargetGroupArn')
~$aws elbv2 describe-target-health --target-group-arn $TARGET_GROUP_ARN
{
    "TargetHealthDescriptions": [
        {
            "Target": {
                "Id": "10.42.180.181",
                "Port": 8080,
                "AvailabilityZone": "us-west-2c"
            },
            "HealthCheckPort": "8080",
            "TargetHealth": {
                "State": "initial",
                "Reason": "Elb.RegistrationInProgress",
                "Description": "Target registration is in progress"
            }
        },
        {
            "Target": {
                "Id": "10.42.140.129",
                "Port": 8080,
                "AvailabilityZone": "us-west-2a"
            },
            "HealthCheckPort": "8080",
            "TargetHealth": {
                "State": "healthy"
            }
        },
        {
            "Target": {
                "Id": "10.42.105.38",
                "Port": 8080,
                "AvailabilityZone": "us-west-2a"
            },
            "HealthCheckPort": "8080",
            "TargetHealth": {
                "State": "initial",
                "Reason": "Elb.RegistrationInProgress",
                "Description": "Target registration is in progress"
            }
        }
    ]
}


予想通り、ui Deploymentのレプリカ数に一致する3つのターゲットが表示されるようになりました。


アプリケーションが同じように機能することを確認したい場合は、次のコマンドを実行してください。それ以外の場合は次のモジュールに進むことができます。


~$curl --head -X GET --retry 30 --retry-all-errors --retry-delay 15 --connect-timeout 30 --max-time 60 \
  -k $(kubectl get service -n ui ui-nlb -o jsonpath="{.status.loadBalancer.ingress[*].hostname}")