クラシック: 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 は、アカウント内のさまざまなサブネットにパケットをルーティングできるようになります。
Writer または Manager IBM Cloud IAMサービスのアクセス・ロールが default ネームスペースにあることを確認してください。
必要な数のワーカー・ノードがあることを確認します。
- クラシック・クラスター: ネットワーク・トラフィックをエッジ・ワーカー・ノードに制限する場合は、NLB が均等にデプロイされるように、各ゾーンで 2 つ以上のエッジ・ワーカー・ノードを有効にしてください。
クラスター・ノードが再ロードされるか、クラスター・マスターの更新に新しい keepalived イメージが含まれる場合、ロード・バランサーの仮想 IP は新しいノードのネットワーク・インターフェースに移動されます。これが発生した場合は、ロード・バランサーへの長期接続を再確立する必要があります。アプリケーションに再試行ロジックを組み込んで、接続の再確立を素早く行えるようにしてください。

複数ゾーン・クラスターで NLB 1.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>"
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 に作成するための構成ファイルの例:
```
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 は、ワーカー・ノードの Iptables ルールを介してクラスター内の kube-proxy によって実装されます。詳細については、Kubernetesのドキュメントを参照してください。
4. クラスター内にサービスを作成します。
```
kubectl apply -f myloadbalancer.yaml
```

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

kubectl describe service myloadbalancer

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

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 アドレスが必要です。詳しくは、クラスター用のサブネットの構成を参照してください。
Writer または Manager IBM Cloud IAMサービスのアクセス・ロールが default ネームスペースにあることを確認してください。
クラスター・ノードが再ロードされるか、クラスター・マスターの更新に新しい keepalived イメージが含まれる場合、ロード・バランサーの仮想 IP は新しいノードのネットワーク・インターフェースに移動されます。これが発生した場合は、ロード・バランサーへの長期接続を再確立する必要があります。アプリケーションに再試行ロジックを組み込んで、接続の再確立を素早く行えるようにしてください。

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

アプリをクラスターにデプロイします。構成ファイルの metadata セクションで、デプロイメントにラベルを追加しておく必要があります。このラベルは、アプリが実行されるすべてのポッドを識別して、それらのポッドがロード・バランシングに含まれるようにするために必要です。
パブリック・インターネットまたはプライベート・ネットワークに公開するアプリのロード・バランサー・サービスを作成します。
1. myloadbalancer.yaml などの名前のサービス構成ファイルを作成します。
2. 公開するアプリのロード・バランサー・サービスを定義します。
```
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 の spec.template.metadata.labels セクションで使ったラベルのキー (<selector_key>) と値 (<selector_value>) です。
  
  port
  
  サービスが listen するポート。
  
  loadBalancerIP
  
  オプション: プライベート・ロード・バランサーを作成するには、またはパブリック・ロード・バランサー用に特定のポータブル IP アドレスを使用するには、使用する IP アドレスを指定します。 IP アドレスは、アノテーションで指定する VLAN 上になければなりません。 IP アドレスを指定しない場合:
  
  クラスターがパブリック VLAN 上にある場合、ポータブル・パブリック IP アドレスが使用されます。ほとんどのクラスターはパブリック VLAN 上にあります。
  
  クラスターがプライベート VLAN 上にのみ存在する場合は、ポータブル・プライベート IP アドレスが使用されます。
  
  プライベート VLAN 2234945 上の指定した IP アドレスを使用するプライベート NLB 1.0 サービスを作成するための構成ファイルの例:
```
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 は、ワーカー・ノードの 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 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 が有効になっている場合、エッジ・ノード上のロード・バランサー・ポッドは、着信要求を他のワーカー・ノード上のアプリ・ポッドに転送できません。

アプリのポッドを強制的にエッジノードにデプロイするには、アプリのデプロイにエッジノードのアフィニティ・ルールとトレレーションを追加します。

エッジ・ノード・アフィニティーとエッジ・ノード耐障害性を追加したデプロイメント 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 を取得します。
1. クラスターのポータブル・パブリック VLAN をリストします。
```
ibmcloud ks cluster get --cluster <cluster_name_or_ID> --show-resources
```
  出力例
```
...

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 に接続されたワーカー・ノードにデプロイされたことを確認します。
1. クラスター内のポッドをリストします。 <selector> を、アプリに使用したラベルに置き換えます。
```
kubectl get pods -o wide app=<selector>
```
  出力例
```
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. ワーカー・ノードの詳細情報をリストします。
```
kubectl describe node <worker_node_ID>
```
  出力例
```
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 であることを確認します。