クラシック: NLB 1.0 による基本的なロード・バランシングのセットアップ

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

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

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

開始前に

パブリック・ネットワーク・ロード・バランサー (NLB) を複数のゾーンに作成するためには、ゾーンごとに 1 つ以上のパブリック VLAN にポータブル・サブネットを用意する必要があります。プライベート NLB を複数のゾーンに作成するためには、ゾーンごとに 1 つ以上のプライベート VLAN にポータブル・サブネットを用意する必要があります。クラスター用のサブネットの構成に記載されているステップに従うことにより、サブネットを追加できます。
IBM Cloud インフラストラクチャー・アカウントの仮想ルーター機能 (VRF) を有効にする必要があります。 VRF を有効にするには、VRF の有効化を参照してください。 VRF が既に有効になっているかどうかを確認するには、ibmcloud account show コマンドを使用します。 VRF を有効にできない、または有効にしない場合は、VLAN スパンニングを有効にします。 VRF または VLAN スパンニングが有効になると、NLB 1.0 は、アカウント内のさまざまなサブネットにパケットをルーティングできるようになります。
default ネームスペース用の「作家または、 マネージャー IBM Cloud IAM サービスのアクセスロール」がインストールされていることを確認してください。
必要な数のワーカー・ノードがあることを確認します。
- クラシック・クラスター: ネットワーク・トラフィックをエッジ・ワーカー・ノードに制限する場合は、NLB が均等にデプロイされるように、各ゾーンで 2 つ以上のエッジ・ワーカー・ノードを有効にしてください。
クラスター・ノードが再ロードされるか、クラスター・マスターの更新に新しい keepalived イメージが含まれる場合、ロード・バランサーの仮想 IP は新しいノードのネットワーク・インターフェースに移動されます。これが発生した場合は、ロード・バランサーへの長期接続を再確立する必要があります。接続の再確立が迅速に行われるよう、アプリケーションに再試行ロジックを組み込むことを検討してください。

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

アプリをクラスターにデプロイします。デプロイメント構成ファイルの metadata セクションに、ラベルを追加しておく必要があります。このカスタム・ラベルにより、アプリが実行されるすべてのポッドが識別されてロード・バランシングに含められます。

パブリック・インターネットまたはプライベート・ネットワークに公開するアプリのロード・バランサー・サービスを作成します。

myloadbalancer.yaml などの名前のサービス構成ファイルを作成します。
公開するアプリのロード・バランサー・サービスを定義します。ゾーン、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>"
    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>
    ```

    `service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type`
    :   `private` または `public` ロード・バランサーを指定するアノテーション。 このアノテーションを指定せず、ワーカー・ノードがパブリック VLAN に接続されている場合は、パブリック `LoadBalancer` サービスが作成されます。 ワーカー・ノードがプライベート VLAN にのみ接続されている場合は、プライベート `LoadBalancer` サービスが作成されます。

    `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>` を実行します。

    `selector`
    :   アプリ・デプロイメント YAML の `<selector_key>` セクションで使用したラベル・キー (`<selector_value>`) と値 (`spec.template.metadata.labels`)。

    `port`
    :   サービスが listen するポート。

    `loadBalancerIP`
    :   オプション: プライベート・ロード・バランサーを作成するには、またはパブリック・ロード・バランサー用に特定のポータブル IP アドレスを使用するには、使用する IP アドレスを指定します。 IP アドレスは、アノテーションで指定する VLAN およびゾーンになければなりません。 IP アドレスを指定しない場合:
        :   クラスターがパブリック VLAN 上にある場合、ポータブル・パブリック IP アドレスが使用されます。 ほとんどのクラスターはパブリック VLAN 上にあります。
        :   クラスターがプライベート VLAN 上にのみ存在する場合は、ポータブル・プライベート IP アドレスが使用されます。

    プライベート VLAN `2234945` 上の指定した IP アドレスを使用するプライベート NLB 1.0 サービスを `dal12` に作成するための構成ファイルの例:

    ```yaml {: codeblock}
    apiVersion: v1
    kind: Service
    metadata:
      name: myloadbalancer
      annotations:
        service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: private
        service.kubernetes.io/ibm-load-balancer-cloud-provider-zone: "dal12"
        service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan: "2234945"
    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.
      loadBalancerIP: 172.21.xxx.xxx
    ```
3. オプション：「 `spec.loadBalancerSourceRanges` 」フィールドにIPアドレスを指定することで、NLBサービスを特定のIPアドレス範囲にのみ利用可能にすることができます。「 `loadBalancerSourceRanges` 」は、クラスター内の `kube-proxy` によって、ワーカーノード上のiptablesルールを使用して実装されます。 詳細については、『 [Kubernetes 』のドキュメント](https://kubernetes.io/docs/concepts/services-networking/){: external}を参照してください。

4. クラスター内にサービスを作成します。

```sh {: pre}
    kubectl apply -f myloadbalancer.yaml
    ```

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

kubectl describe service myloadbalancer

出力例:

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

パブリック NLB を作成した場合、インターネットからアプリにアクセスします。
1. 任意の Web ブラウザーを開きます。
2. NLB のポータブル・パブリック IP アドレスとポートを入力します。
```
    http://169.xx.xxx.xxx:8080
    ```
```
手順 2～4 を繰り返して、各ゾーンにバージョン 1.0 の NLB を追加します。
NLB 1.0 のソース IP 保持を有効にする場合は必ず、アプリ・ポッドにエッジ・ノード・アフィニティーを追加して、エッジ・ワーカー・ノードにアプリ・ポッドをスケジュールするようにしてください。着信要求を受信するには、アプリ・ポッドをエッジ・ノードにスケジュールする必要があります。
オプション: ロード・バランサー・サービスは、サービスの NodePort を介してアプリを使用できるようにします。 NodePort には、クラスター内のすべてのノードのすべてのパブリック IP アドレスおよびプライベート IP アドレスでアクセスできます。 NLB サービスを使用しつつ、NodePort へのトラフィックをブロックするには、ロード・バランサー・サービスまたはノード・ポート・サービスへのインバウンド・トラフィックの制御を参照してください。

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

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

開始前に

ネットワーク・ロード・バランサー (NLB) サービスに割り当てることのできるポータブル・パブリック IP アドレスまたはポータブル・プライベート IP アドレスが必要です。詳しくは、クラスター用のサブネットの構成を参照してください。
default ネームスペース用の「作家または、 マネージャー IBM Cloud IAM サービスのアクセスロール」がインストールされていることを確認してください。
クラスター・ノードが再ロードされるか、クラスター・マスターの更新に新しい keepalived イメージが含まれる場合、ロード・バランサーの仮想 IP は新しいノードのネットワーク・インターフェースに移動されます。これが発生した場合は、ロード・バランサーへの長期接続を再確立する必要があります。接続の再確立が迅速に行われるよう、アプリケーションに再試行ロジックを組み込むことを検討してください。

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

アプリをクラスターにデプロイします。デプロイメント構成ファイルの metadata セクションに、ラベルを追加しておく必要があります。このカスタム・ラベルにより、アプリが実行されるすべてのポッドが識別されてロード・バランシングに含められます。

パブリック・インターネットまたはプライベート・ネットワークに公開するアプリのロード・バランサー・サービスを作成します。

myloadbalancer.yaml などの名前のサービス構成ファイルを作成します。
公開するアプリのロード・バランサー・サービスを定義します。

    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>"
    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>
    ```
    `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>` を実行します。

    `selector`
    :   アプリ・デプロイメント YAML の `<selector_key>` セクションで使用したラベル・キー (`<selector_value>`) と値 (`spec.template.metadata.labels`)。

    `port`
    :   サービスが listen するポート。

    `loadBalancerIP`
    :   オプション: プライベート・ロード・バランサーを作成するには、またはパブリック・ロード・バランサー用に特定のポータブル IP アドレスを使用するには、使用する IP アドレスを指定します。 IP アドレスは、アノテーションで指定する VLAN 上になければなりません。 IP アドレスを指定しない場合:
        :   クラスターがパブリック VLAN 上にある場合、ポータブル・パブリック IP アドレスが使用されます。 ほとんどのクラスターはパブリック VLAN 上にあります。
        :   クラスターがプライベート VLAN 上にのみ存在する場合は、ポータブル・プライベート IP アドレスが使用されます。

    プライベート VLAN `2234945` 上の指定した IP アドレスを使用するプライベート NLB 1.0 サービスを作成するための構成ファイルの例:

    ```yaml {: codeblock}
    apiVersion: v1
    kind: Service
    metadata:
      name: myloadbalancer
      annotations:
        service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: private
        service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan: "2234945"
    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.
      loadBalancerIP: 172.21.xxx.xxx
    ```
3. オプション：「 `spec.loadBalancerSourceRanges` 」フィールドにIPアドレスを指定することで、NLBサービスを特定のIPアドレス範囲にのみ利用可能にすることができます。「 `loadBalancerSourceRanges` 」は、クラスター内の `kube-proxy` によって、ワーカーノード上のiptablesルールを使用して実装されます。 詳細については、『 [Kubernetes 』のドキュメント](https://kubernetes.io/docs/concepts/services-networking/){: external}を参照してください。

4. クラスター内にサービスを作成します。

```sh {: pre}
    kubectl apply -f myloadbalancer.yaml
    ```

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

kubectl describe service myloadbalancer

出力例:

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 1.0 のソース IP 保持を有効にする場合は必ず、アプリ・ポッドにエッジ・ノード・アフィニティーを追加して、エッジ・ワーカー・ノードにアプリ・ポッドをスケジュールするようにしてください。着信要求を受信するには、アプリ・ポッドをエッジ・ノードにスケジュールする必要があります。
オプション: ロード・バランサー・サービスは、サービスの NodePort を介してアプリを使用できるようにします。 NodePort には、クラスター内のすべてのノードのすべてのパブリック IP アドレスおよびプライベート IP アドレスでアクセスできます。 NLB サービスを使用しつつ、NodePort へのトラフィックをブロックするには、ロード・バランサー・サービスまたはノード・ポート・サービスへのインバウンド・トラフィックの制御を参照してください。

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

ソース IP 保持の有効化

この機能は、バージョン 1.0 のネットワーク・ロード・バランサー (NLB) にのみあります。バージョン 2.0 の NLB では、クライアント要求のソース IP アドレスはデフォルトで保持されます。

アプリへのクライアント要求がクラスターに送信されると、ロード・バランサー・サービス・ポッドがその要求を受け取ります。ロード・バランサー・サービス・ポッドと同じワーカー・ノードにアプリ・ポッドが存在しない場合、NLB は異なるワーカー・ノードに要求を転送します。リクエストの発信元IPアドレスは、ロードバランサーサービスのポッドが実行されているワーカーノードのパブリックIPアドレスに変更されます。

クライアントリクエストの元の送信元IPアドレスを保持するには、ロードバランサーサービスで送信元IPを有効にすることができます。 TCP の接続先はアプリ・ポッドになるので、アプリはイニシエーターの実際のソース IP アドレスを認識できます。クライアントの IP を保持すると、例えば、アプリ・サーバーがセキュリティーやアクセス制御ポリシーを適用する必要がある場合などに役に立ちます。

ソース IP を有効にした場合は、ロード・バランサー・サービス・ポッドは、同じワーカー・ノードにデプロイされているアプリ・ポッドにのみ要求を転送しなければなりません。通常、ロード・バランサー・サービス・ポッドも、アプリ・ポッドをデプロイしたワーカー・ノードにデプロイされます。しかし、次のように、ロード・バランサー・ポッドとアプリ・ポッドが同じワーカー・ノードにスケジュールされない状況もあります。

エッジ・ノードにテイントがあるため、これらのエッジ・ノードにデプロイできるのはロード・バランサー・サービス・ポッドのみです。このようなノードにはアプリ・ポッドをデプロイできません。
複数のパブリック VLAN またはプライベート VLAN にクラスターが接続されている場合、1 つの VLAN のみに接続されているワーカー・ノードにアプリ・ポッドはデプロイされます。 NLB の IP アドレスがワーカー・ノードとは別の VLAN に接続されているという理由で、このようなワーカー・ノードにはロード・バランサー・サービス・ポッドはデプロイされない可能性があります。

ロード・バランサー・サービス・ポッドもデプロイできる特定のワーカー・ノードに強制的にアプリをデプロイするには、アフィニティー・ルールと耐障害性をアプリのデプロイメントに追加する必要があります。

エッジ・ノードのアフィニティー・ルールと耐障害性を追加する

ワーカー・ノードにエッジ・ノードのラベルを付け、さらにエッジ・ノードにテイントを適用する場合、ロード・バランサー・サービス・ポッドはそれらのエッジ・ノードにのみデプロイされ、アプリ・ポッドはエッジ・ノードにデプロイできません。 NLB サービスのソース IP が有効になっている場合、エッジ・ノード上のロード・バランサー・ポッドは、着信要求を他のワーカー・ノード上のアプリ・ポッドに転送できません。

アプリのPodをエッジノードに強制的にデプロイするには、アプリのデプロイメントにエッジノードのアフィニティルールと許容範囲を追加してください。

エッジ・ノード・アフィニティーとエッジ・ノード耐障害性を追加したデプロイメント YAML のサンプル

apiVersion: apps/v1
kind: Deployment
metadata:
  name: with-node-affinity
spec:
  selector:
    matchLabels:
      <label_name>: <label_value>
  template:
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: dedicated
                operator: In
                values:
                - edge
      tolerations:
        - key: dedicated
          value: edge
...

affinity および tolerations の各セクションでは、いずれも dedicated が key として、 edge が value として設定されています。

複数のパブリック VLAN またはプライベート VLAN にアフィニティー・ルールを追加する

複数のパブリック VLAN またはプライベート VLAN にクラスターが接続されている場合は、1 つの VLAN のみに接続されているワーカー・ノードにアプリ・ポッドはデプロイされる可能性があります。 NLB の IP アドレスが、そのようなワーカー・ノードとは別の VLAN に接続されていると、ロード・バランサー・サービス・ポッドはそのようなワーカー・ノードにデプロイされません。

ソース IP を有効にした場合は、アフィニティー・ルールをアプリのデプロイメントに追加して、NLB の IP アドレスと同じ VLAN にあるワーカー・ノードにアプリ・ポッドをスケジュールしてください。

始める前に

アカウントにログインします。該当する場合は、適切なリソース・グループをターゲットにします。クラスターのコンテキストを設定します。

NLB サービスのパブリック IP アドレスを取得します。 LoadBalancer Ingress フィールドの IP アドレスを確認してください。
```
kubectl describe service <loadbalancer_service_name>
```

NLB サービスが接続する VLAN ID を取得します。

クラスターのポータブル・パブリック VLAN をリストします。

    ibmcloud ks cluster get --cluster <cluster_name_or_ID> --show-resources
    ```
    出力例
    ```sh {: screen}
    ...
    Subnet VLANs
    VLAN ID   Subnet CIDR       Public   User-managed
    2234947   10.xxx.xx.xxx/29  false    false
    2234945   169.36.5.xxx/29   true     false
    ```
2. **Subnet VLANs** の下にある出力で、先ほど取得した NLB の IP アドレスと一致するサブネット CIDR を見つけ、その VLAN ID をメモします。

    例えば、NLB サービスの IP アドレスが `169.36.5.xxx` の場合、前のステップの出力例で一致するサブネットは `169.36.5.xxx/29` です。 そのサブネットが接続する VLAN ID は、`2234945` です。

前の手順で記録しておいたVLAN IDについて、アプリ展開にアフィニティルールを追加します。

例えば、複数の VLAN がある場合に、2234945 のパブリック VLAN にあるワーカー・ノードにのみアプリ・ポッドをデプロイするには、以下のようにします。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: with-node-affinity
spec:
  selector:
    matchLabels:
      <label_name>: <label_value>
  template:
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: publicVLAN
                operator: In
                values:
                - "2234945"
...

サンプル YAML では、affinity セクションの publicVLAN は key、"2234945" は value です。

更新したデプロイメント構成ファイルを適用します。
```
kubectl apply -f with-node-affinity.yaml
```

アプリ・ポッドが、指定した VLAN に接続されたワーカー・ノードにデプロイされたことを確認します。

クラスター内のポッドをリストします。 <selector> を、アプリに使用したラベルに置き換えます。

    kubectl get pods -o wide app=<selector>
    ```
    出力例
    ```sh {: screen}
    NAME                   READY     STATUS              RESTARTS   AGE       IP               NODE
    cf-py-d7b7d94db-vp8pq  1/1       Running             0          10d       172.30.xxx.xxx   10.176.48.78
    ```
2. 出力で、アプリのポッドを確認します。 ポッドがあるワーカー・ノードの **NODE** ID をメモします。

    前のステップの出力例では、アプリ・ポッド `cf-py-d7b7d94db-vp8pq` がワーカー・ノード `10.176.48.78` にあります。

3. ワーカー・ノードの詳細情報をリストします。

```sh {: pre}
    kubectl describe node <worker_node_ID>
    ```
    出力例

    ```sh {: screen}
    NAME:                   10.xxx.xx.xxx
    Role:
    Labels:                 arch=amd64
    beta.kubernetes.io/arch=amd64
    beta.kubernetes.io/os=linux
    failure-domain.beta.kubernetes.io/region=us-south
    failure-domain.beta.kubernetes.io/zone=dal10
    ibm-cloud.kubernetes.io/encrypted-docker-data=true
    kubernetes.io/hostname=10.xxx.xx.xxx
    privateVLAN=2234945
    publicVLAN=2234967
    ...
    ```
4. 出力の **Labels** セクションのパブリック VLAN またはプライベート VLAN が、前の手順で指定した VLAN であることを確認します。