クラシック: NLB 2.0 による DSR ロード・バランシングのセットアップ

バージョン 2.0 NLB はクラシック・クラスターでのみ作成でき、VPC クラスターでは作成できません。 VPC クラスターでロード・バランシングを行うには、VPC ロード・バランサーを使用したアプリの公開を参照してください。

ポートを公開し、レイヤー 4 のネットワーク・ロード・バランサー (NLB) のポータブル IP アドレスを使用してコンテナー化アプリに公開します。バージョン 2.0 NLB について詳しくは、NLB 2.0 のコンポーネントおよびアーキテクチャーを参照してください。

前提条件

既存のバージョン 1.0 NLB を 2.0 に更新することはできません。新規 NLB 2.0 を作成する必要があります。クラスター内でバージョン 1.0 と 2.0 の NLB を同時に実行できます。

NLB 2.0 を作成する前に、前提条件として次の手順を実行する必要があります。

NLB 2.0 で複数ゾーン内のアプリ・ポッドに要求を転送できるようにするには、サポート Case を開いて VLAN の容量集約を要求します。この構成設定によって、ネットワークの中断や障害が発生することはありません。
1. IBM Cloud コンソールにログインします。
2. メニュー・バーの**「サポート」をクリックし、「Case の管理」タブをクリックして、「新規 Case の作成 (Create new case)」**をクリックします。
3. Case フィールドに、以下の情報を入力します。トピック: ネットワーク-プロビジョニングサブトピック: クラシック-VLAN
4. 説明に Please set up the network to allow capacity aggregation on the public and private VLANs associated with my account. This is related to /docs/containers?topic=containers-loadbalancer-v2#ipvs_provision, and is needed so I can configure NLB v2.0 LoadBalancers in my Classic Kubernetes Cluster. という情報を追加します。特定の VLAN (1 つのクラスターのみに対するパブリック VLAN など) について容量集約を許可する場合は、説明でこれらの VLAN ID を指定できます。
5. **「送信」**をクリックします。
IBM Cloud インフラストラクチャー・アカウントの仮想ルーター機能 (VRF) を有効にする必要があります。 VRF を有効にするには、VRF の有効化を参照してください。 VRF が既に有効になっているかどうかを確認するには、ibmcloud account show コマンドを使用します。 VRF を有効にできない、または有効にしない場合は、VLAN スパンニングを有効にします。 VRF または VLAN スパンニングが有効になると、NLB 2.0 は、アカウント内のさまざまなサブネットにパケットをルーティングできるようになります。
Calico pre-DNAT ネットワーク・ポリシーを使用して NLB 2.0 へのトラフィックを管理する場合は、applyOnForward: true フィールドと doNotTrack: true フィールドをポリシーの spec セクションに追加し、preDNAT: true を削除する必要があります。applyOnForward: true は、トラフィックがカプセル化されて転送されるときに、Calico ポリシーが適用されるようにします。doNotTrack: true は、ワーカー・ノードが DSR を使用して接続を追跡する必要なしに、応答パケットをクライアントに直接返せるようにします。例えば、Calico ポリシーを使用して特定の IP アドレスから NLB IP アドレスへのトラフィックのみを許可する場合、ポリシーは以下のようになります。
```
apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: allowlist
spec:
  applyOnForward: true
  doNotTrack: true
  ingress:
  - action: Allow
    destination:
      nets:
      - <loadbalancer_IP>/32
      ports:
      - 80
    protocol: TCP
    source:
      nets:
      - <client_address>/32
  selector: ibm.role=='worker_public'
  order: 500
  types:
  - Ingress
```

次は、複数ゾーン・クラスターでの NLB 2.0 のセットアップまたは単一ゾーン・クラスターでの NLB 2.0 のセットアップの手順に従ってください。

複数ゾーン・クラスターでの NLB 2.0 のセットアップ

始める前に:

重要: NLB 2.0 の前提条件を満たしてください。
パブリック NLB を複数のゾーンに作成するためには、ゾーンごとに 1 つ以上のパブリック VLAN にポータブル・サブネットを用意する必要があります。プライベート NLB を複数のゾーンに作成するためには、ゾーンごとに 1 つ以上のプライベート VLAN にポータブル・サブネットを用意する必要があります。クラスター用のサブネットの構成に記載されているステップに従うことにより、サブネットを追加できます。
ネームスペースの default ライター or マネージャー IBM Cloud IAM service access role あることを確認してください。
必要な数のワーカー・ノードがあることを確認します。
- クラシック・クラスター: ネットワーク・トラフィックをエッジ・ワーカー・ノードに制限する場合は、NLB が均等にデプロイされるように、各ゾーンで 2 つ以上のエッジ・ワーカー・ノードを有効にしてください。
クラスター・ノードが再ロードされるか、クラスター・マスターの更新に新しい keepalived イメージが含まれる場合、ロード・バランサーの仮想 IP は新しいノードのネットワーク・インターフェースに移動されます。これが発生した場合は、ロード・バランサーへの長期接続を再確立する必要があります。アプリケーションに再試行ロジックを組み込んで、接続の再確立を素早く行えるようにしてください。

複数ゾーン・クラスターで NLB 2.0 をセットアップするには、次の手順を実行します。

アプリをクラスターにデプロイします。構成ファイルの metadata セクションで、デプロイメントにラベルを追加しておく必要があります。このカスタム・ラベルにより、アプリが実行されるすべてのポッドが識別されてロード・バランシングに含められます。
パブリック・インターネットまたはプライベート・ネットワークに公開するアプリのロード・バランサー・サービスを作成します。
1. myloadbalancer.yaml などの名前のサービス構成ファイルを作成します。
2. 公開するアプリのロード・バランサー・サービスを定義します。ゾーン、VLAN、および IP アドレスを指定できます。
```
apiVersion: v1
kind: Service
metadata:
  name: myloadbalancer
  annotations:
    service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: <public_or_private>
    service.kubernetes.io/ibm-load-balancer-cloud-provider-zone: "<zone>"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan: "<vlan_id>"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "ipvs"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-ipvs-scheduler: "<algorithm>"
spec:
 type: LoadBalancer
 selector:
   <selector_key>: <selector_value>
 ports:
  - protocol: TCP
    port: 8080
    targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
 loadBalancerIP: <IP_address>
 externalTrafficPolicy: Local
```
  service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type:
  
  private または public ロード・バランサーを指定するアノテーション。
  
  service.kubernetes.io/ibm-load-balancer-cloud-provider-zone:
  
  ロード・バランサー・サービスのデプロイ先のゾーンを指定するアノテーション。ゾーンを表示するには、ibmcloud ks zone ls を実行します。
  
  service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan:
  
  ロード・バランサー・サービスのデプロイ先の VLAN を指定するアノテーション。 VLAN を表示するには、ibmcloud ks vlan ls --zone <zone> を実行します。
  
  service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "ipvs"
  
  バージョン 2.0 のロード・バランサーを指定するアノテーション。
  
  service.kubernetes.io/ibm-load-balancer-cloud-provider-ipvs-scheduler:
  
  オプション: スケジューリング・アルゴリズムを指定するアノテーション。使用可能な値は、ラウンドロビン（デフォルト）の場合は "rr" ソースハッシュの場合は "sh" です。詳しくは、2.0: スケジューリング・アルゴリズムを参照してください。
  
  selector
  
  アプリ・デプロイメント YAML の <selector_key> セクションで使用したラベル・キー (<selector_value>) と値 (spec.template.metadata.labels)。
  
  port
  
  サービスが listen するポート。
  
  loadBalancerIP
  
  オプション: プライベート NLB を作成するには、またはパブリック NLB 用に特定のポータブル IP アドレスを使用するには、使用する IP アドレスを指定します。 IP アドレスは、アノテーションで指定するゾーンと VLAN になければなりません。 IP アドレスを指定しない場合: クラスターがパブリック VLAN 上にある場合は、ポータブル・パブリック IP アドレスが使用されます。ほとんどのクラスターはパブリック VLAN 上にあります。クラスターがプライベート VLAN 上にのみ存在する場合は、ポータブル・プライベート IP アドレスが使用されます。
  
  externalTrafficPolicy: Local
  
  Local に設定します。
  
  ラウンドロビン・スケジューリング・アルゴリズムを使用するNLB2.0サービスを dal12 に作成するための設定ファイルの例：
```
apiVersion: v1
kind: Service
metadata:
  name: myloadbalancer
  annotations:
    service.kubernetes.io/ibm-load-balancer-cloud-provider-zone: "dal12"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "ipvs"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-ipvs-scheduler: "rr"
spec:
  type: LoadBalancer
   selector:
     app: nginx
   ports:
    - protocol: TCP
      port: 8080
      targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
   externalTrafficPolicy: Local
```
3. オプション: spec.loadBalancerSourceRanges フィールドに IP を指定して、NLB サービスを限定された範囲の IP アドレスでのみ使用できるようにします。loadBalancerSourceRanges は、ワーカー・ノードの Iptables ルールを介してクラスター内の kube-proxy によって実装されます。詳細は Kubernetesのドキュメントを参照。
4. クラスター内にサービスを作成します。
```
kubectl apply -f myloadbalancer.yaml
```

NLB サービスが正常に作成されたことを確認します。 NLB サービスが適切に作成され、アプリが利用可能になるまでに数分かかることがあります。

kubectl describe service myloadbalancer

CLI 出力例:

NAME:                   myloadbalancer
Namespace:              default
Labels:                 <none>
Selector:               app=liberty
Type:                   LoadBalancer
Zone:                   dal10
IP:                     172.21.xxx.xxx
LoadBalancer Ingress:   169.xx.xxx.xxx
Port:                   <unset> 8080/TCP
NodePort:               <unset> 32040/TCP
Endpoints:              172.30.xxx.xxx:8080
Session Affinity:       None
Events:
    FirstSeen    LastSeen    Count    From            SubObjectPath    Type     Reason                      Message
    ---------    --------    -----    ----            -------------    ----     ------                      -------
    10s            10s            1        {service-controller }      Normal CreatingLoadBalancer    Creating load balancer
    10s            10s            1        {service-controller }        Normal CreatedLoadBalancer    Created load balancer

LoadBalancer Ingress IP アドレスは、NLB サービスに割り当てられたポータブル・パブリック IP アドレスです。

パブリック NLB を作成した場合、インターネットからアプリにアクセスします。
1. 任意の Web ブラウザーを開きます。
2. NLB のポータブル・パブリック IP アドレスとポートを入力します。
```
http://169.xx.xxx.xxx:8080
```
高可用性を確保するために、ステップ 2 から 4 を繰り返して、アプリ・インスタンスが存在する各ゾーンに NLB 2.0 を追加します。
オプション: NLB サービスは、サービスの NodePort を介してアプリを使用できるようにします。 NodePort には、クラスター内のすべてのノードのすべてのパブリック IP アドレスおよびプライベート IP アドレスでアクセスできます。 NLB サービスを使用しつつ、NodePort へのトラフィックをブロックするには、ロード・バランサー・サービスまたはノード・ポート・サービスへのインバウンド・トラフィックの制御を参照してください。

次に、NLB サブドメインを登録できます。

単一ゾーン・クラスターでの NLB 2.0 のセットアップ

始める前に:

重要: NLB 2.0 の前提条件を満たしてください。
NLB サービスに割り当てることのできるポータブル・パブリック IP アドレスまたはポータブル・プライベート IP アドレスが必要です。詳しくは、クラスター用のサブネットの構成を参照してください。
ネームスペースの default ライター or マネージャー IBM Cloud IAM service access role あることを確認してください。
クラスター・ノードが再ロードされるか、クラスター・マスターの更新に新しい keepalived イメージが含まれる場合、ロード・バランサーの仮想 IP は新しいノードのネットワーク・インターフェースに移動されます。これが発生した場合は、ロード・バランサーへの長期接続を再確立する必要があります。アプリケーションに再試行ロジックを組み込んで、接続の再確立を素早く行えるようにしてください。

単一ゾーン・クラスターで NLB 2.0 サービスを作成するには、以下のようにします。

アプリをクラスターにデプロイします。構成ファイルの metadata セクションで、デプロイメントにラベルを追加しておく必要があります。このラベルは、アプリが実行されるすべてのポッドを識別して、それらのポッドがロード・バランシングに含まれるようにするために必要です。
パブリック・インターネットまたはプライベート・ネットワークに公開するアプリのロード・バランサー・サービスを作成します。
1. myloadbalancer.yaml などの名前のサービス構成ファイルを作成します。
2. 公開するアプリのロード・バランサー 2.0 サービスを定義します。
```
apiVersion: v1
kind: Service
metadata:
  name: myloadbalancer
  annotations:
    service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: <public_or_private>
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan: "<vlan_id>"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "ipvs"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-ipvs-scheduler: "<algorithm>"
spec:
  type: LoadBalancer
  selector:
    <selector_key>: <selector_value>
  ports:
   - protocol: TCP
     port: 8080
     targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
  loadBalancerIP: <IP_address>
  externalTrafficPolicy: Local
```
  service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type:
  
  private または public ロード・バランサーを指定するアノテーション。
  
  service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan:
  
  オプション: ロード・バランサー・サービスのデプロイ先の VLAN を指定するアノテーション。 VLAN を表示するには、ibmcloud ks vlan ls --zone <zone> を実行します。
  
  service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "ipvs"
  
  ロード・バランサー 2.0 を指定するアノテーション。
  
  service.kubernetes.io/ibm-load-balancer-cloud-provider-ipvs-scheduler:
  
  オプション: スケジューリング・アルゴリズムを指定するアノテーション。使用可能な値は、ラウンドロビン（デフォルト）の場合は "rr" ソースハッシュの場合は "sh" です。詳しくは、2.0: スケジューリング・アルゴリズムを参照してください。
  
  selector
  
  アプリ・デプロイメント YAML の <selector_key> セクションで使用したラベル・キー (<selector_value>) と値 (spec.template.metadata.labels)。
  
  port
  
  サービスが listen するポート。
  
  loadBalancerIP
  オプション: プライベート NLB を作成するには、またはパブリック NLB 用に特定のポータブル IP アドレスを使用するには、使用する IP アドレスを指定します。 IP アドレスは、アノテーションで指定する VLAN 上になければなりません。 IP アドレスを指定しない場合:
  - クラスターがパブリック VLAN 上にある場合、ポータブル・パブリック IP アドレスが使用されます。ほとんどのクラスターはパブリック VLAN 上にあります。
  - クラスターがプライベート VLAN 上にのみ存在する場合は、ポータブル・プライベート IP アドレスが使用されます。
  externalTrafficPolicy: Local
  
  Local に設定します。
3. オプション: spec.loadBalancerSourceRanges フィールドに IP を指定して、NLB サービスを限定された範囲の IP アドレスでのみ使用できるようにします。loadBalancerSourceRanges は、ワーカー・ノードの Iptables ルールを介してクラスター内の kube-proxy によって実装されます。詳細は Kubernetesのドキュメントを参照。
4. クラスター内にサービスを作成します。
```
kubectl apply -f myloadbalancer.yaml
```

NLB サービスが正常に作成されたことを確認します。サービスが作成され、アプリが利用可能になるまでに数分かかることがあります。

kubectl describe service myloadbalancer

CLI 出力例:

NAME:                   myloadbalancer
Namespace:              default
Labels:                 <none>
Selector:               app=liberty
Type:                   LoadBalancer
Location:               dal10
IP:                     172.21.xxx.xxx
LoadBalancer Ingress:   169.xx.xxx.xxx
Port:                   <unset> 8080/TCP
NodePort:               <unset> 32040/TCP
Endpoints:              172.30.xxx.xxx:8080
Session Affinity:       None
Events:
    FirstSeen    LastSeen    Count    From            SubObjectPath    Type     Reason                      Message
    ---------    --------    -----    ----            -------------    ----     ------                      -------
    10s            10s            1        {service-controller }      Normal CreatingLoadBalancer    Creating load balancer
    10s            10s            1        {service-controller }        Normal CreatedLoadBalancer    Created load balancer

LoadBalancer Ingress IP アドレスは、NLB サービスに割り当てられたポータブル・パブリック IP アドレスです。

パブリック NLB を作成した場合、インターネットからアプリにアクセスします。
1. 任意の Web ブラウザーを開きます。
2. NLB のポータブル・パブリック IP アドレスとポートを入力します。
```
http://169.xx.xxx.xxx:8080
```
オプション: NLB サービスは、サービスの NodePort を介してアプリを使用できるようにします。 NodePort には、クラスター内のすべてのノードのすべてのパブリック IP アドレスおよびプライベート IP アドレスでアクセスできます。 NLB サービスを使用しつつ、NodePort へのトラフィックをブロックするには、ロード・バランサー・サービスまたはノード・ポート・サービスへのインバウンド・トラフィックの制御を参照してください。

次に、NLB サブドメインを登録できます。

スケジューリング・アルゴリズム

NLB 2.0 がネットワーク接続をアプリ・ポッドにどのように割り当てるかは、スケジューリング・アルゴリズムによって決まります。クライアント要求がクラスターに到着すると、NLB は、スケジューリング・アルゴリズムに基づいて要求パケットをワーカー・ノードにルーティングします。 To use a scheduling algorithm, specify its Keepalived short name in the scheduler annotation of your NLB service configuration file: service.kubernetes.io/ibm-load-balancer-cloud-provider-ipvs-scheduler: "rr". 以下のリストで、IBM Cloud Kubernetes Service でサポートされるスケジューリング・アルゴリズムを確認してください。スケジューリング・アルゴリズムを指定しなかった場合、デフォルトでラウンドロビン・アルゴリズムが使われる。詳しくは、Keepalived のドキュメントを参照のこと。

サポートされるスケジューリング・アルゴリズム

ラウンドロビン (rr): NLB は、ワーカー・ノードに接続をルーティングするときにアプリ・ポッドのリストを循環し、各アプリ・ポッドを同等に扱います。ラウンドロビンは、バージョン 2.0 NLB のデフォルトのスケジューリング・アルゴリズムです。
ソース・ハッシュ (sh): NLB は、クライアント要求パケットのソース IP アドレスに基づいてハッシュ・キーを生成します。次に NLB は、静的に割り当てられたハッシュ・テーブルでそのハッシュ・キーを検索し、該当範囲のハッシュを処理するアプリ・ポッドに要求をルーティングします。このアルゴリズムにより、特定のクライアントからの要求は常に同じアプリ・ポッドに送信されるようになります。 Kubernetes は、Iptables ルールを使用します。これにより、ワーカー上のランダム・ポッドに要求が送信されます。このスケジューリング・アルゴリズムを使用するには、ワーカー・ノード 1 つにつきアプリ・ポッドが 1 つのみデプロイされるようにする必要があります。例えば、各ポッドのラベルが run=<app_name> である場合は、アプリ・デプロイメントの spec セクションに以下のアンチアフィニティー・ルールを追加します:

spec:
  affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 100
      podAffinityTerm:
        labelSelector:
          matchExpressions:
          - key: run
            operator: In
            values:
            - <APP_NAME>
        topologyKey: kubernetes.io/hostname

サポートされないスケジューリング・アルゴリズム

宛先ハッシュ (dh)

パケットの宛先 (NLB の IP アドレスとポート) を使用して、着信要求を処理するワーカー・ノードが決定されます。ただし、IBM Cloud Kubernetes Service 内の NLB の IP アドレスとポートは変わりません。 NLB が存在するワーカー・ノードから要求が出ていかず、1 つのワーカー上のアプリ・ポッドのみがすべての着信要求を処理することになります。

動的接続カウント・アルゴリズム

以下のアルゴリズムは、クライアントと NLB の間の動的な接続数に基づくものです。しかし、直接サービス・リターン (DSR) では NLB 2.0 のポッドがパケットのリターン・パスに含まれないため、NLB は確立された接続を追跡しません。

最小接続数 (lc)
局所性ベースの最小接続 (lblc)
レプリケーションによる局所性ベースの最小接続 (lblcr)
キューなし (nq)
最短予想遅延 (seq)

加重型ポッド・アルゴリズム

以下のアルゴリズムは、重みづけされたアプリ・ポッドに基づくものです。しかし、IBM Cloud Kubernetes Service のロード・バランシングでは、すべてのアプリ・ポッドに等しい重みが割り当てられます。

重み付き最小接続 (wlc)
重み付きラウンドロビン (wrr)