クラシック・クラスター: Ingress コントローラーがゾーンにデプロイされないのはなぜですか?

インフラストラクチャー・プロバイダーおよびバージョン:

クラシック
Red Hat OpenShift バージョン 4

oc get svc -n openshift-ingress を実行する場合、1 つ以上のゾーンにパブリック Ingress コントローラーがありません。

router-default サービスがデプロイされないか、または、そのサービスに外部 IP アドレスが割り当てられていない可能性があります。例えば、単一ゾーン・クラスターで、次のように表示される場合があります。

NAME                                         TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)                      AGE
router-default                               LoadBalancer   172.21.47.119   <none>         80:32637/TCP,443:31719/TCP   26m
router-internal-default                      ClusterIP      172.21.51.30    <none>         80/TCP,443/TCP,1936/TCP      26m

複数ゾーン・クラスターがある場合、1 つのゾーンに Ingress コントローラー・サービスがありません。たとえば、 dal10、 dal12、 dal13 にワーカーノードを持つマルチゾーンクラスターの場合、 dal10 には「 router-default 」サービスが、 dal12 には「 router-dal12 」サービスが表示されることがありますが、 dal13 には「 router-dal13 」サービスが表示されないことがあります。ワーカーノードが配置されている最初のゾーンにあるIngressコントローラーサービスの名前は常に router-default となり、その後クラスターに追加するゾーンにあるIngressコントローラーサービスの名前は、 router-dal12 のような形式になることに注意してください。また、あるゾーンには Ingress コントローラー・サービスがなく、別のゾーンには 2 つ以上の Ingress コントローラー・サービスがあることがわかります。
```
NAME                                         TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)                      AGE
router-default                               LoadBalancer   172.21.47.119   169.XX.XX.XX   80:32637/TCP,443:31719/TCP   26m
router-dal12                                 LoadBalancer   172.21.47.119   169.XX.XX.XX   80:32637/TCP,443:31719/TCP   26m
router-internal-default                      ClusterIP      172.21.51.30    <none>         80/TCP,443/TCP,1936/TCP      26m
```

ルーター・サービスがデプロイされない理由として、次のいずれかが考えられます。

Ingress コントローラー・サービスがデプロイされていない場合、または Ingress コントローラー・サービスに外部 IP アドレスが割り当てられていない場合: 標準クラスターでは、ゾーン内にクラスターを初めて作成するときに、そのゾーン内のパブリック VLAN とプライベート VLAN が IBM Cloud インフラストラクチャー・アカウントに自動的にプロビジョンされます。そのゾーンでは、指定したパブリックVLANに対して1つのパブリックポータブルサブネットが、指定したプライベートVLANに対して1つのプライベートポータブルサブネットが要求されます。 Red Hat OpenShift on IBM Cloud の場合、VLAN のサブネット数の上限は 40 個です。ゾーン内のクラスタのVLANがすでにその制限に達している場合、 Ingressサブドメインのプロビジョニングに失敗し、デフォルトのパブリックIngressコントローラーのプロビジョニングも失敗します。 VLANに含まれるサブネットの数を確認するには、 IBM Cloud インフラストラクチャコンソールで、 [Network ] > [ IP Management ] > [VLANs ] を選択します。クラスターの作成に使用した VLAN の **「VLAN の数 (VLAN Number)」**をクリックします。 **「サブネット」**セクションで、サブネットが 40 個以上存在するかどうかを確認します。
1 つのゾーンに Ingress コントローラー・サービスがない場合: Ingress コントローラー・サービスが作成されると、クラスター内の複数のゾーンに自動的に分散されます。 Ingress コントローラー・サービスの作成時に、クラスターの作成に使用した最初のゾーンのネットワークの準備ができていない場合は、そのゾーンの Ingress コントローラー・サービスが別のゾーンに配置されている可能性があります。 1 つのゾーンに 2 つの Ingress コントローラー・サービスが作成され、初期ゾーンには Ingress コントローラー・サービスが作成されない場合があります。

IP アドレスのない Ingress コントローラー・サービスの VLAN の問題、または Ingress コントローラー・サービスのないゾーンの複数ゾーン Ingress コントローラー・サービスの問題を解決します。

VLAN 問題の解決

IP アドレスのない Ingress コントローラー・サービスの VLAN の問題を解決するには、以下のようにします。

オプション 1 ：新しい VLAN が必要な場合は、 IBM Cloud のサポートに連絡して申請してください。その後、その新規 VLAN を使用するクラスターを作成します。

オプション 2 ：利用可能な別の VLAN がある場合は、既存のクラスターで VLAN スパンニングを設定できます。 VLANスパンニングがすでに有効になっているかどうかを確認するには、 ibmcloud ks vlan spanning get --region REGION コマンドを使用します。続いて、使用可能なサブネットがある他方の VLAN を使用する新規ワーカー・ノードをクラスターに追加できます。ゾーンごとに、少なくとも2つのワーカーノードを作成してください。 Ingress コントローラーが自動的にデプロイできるように、IP アドレスが使用可能になりました。

オプション 3 ：VLAN 内のすべてのサブネットを使用していない場合は、それらのサブネットをクラスターに追加することで、VLAN 上のサブネットを再利用できます。

使用したいサブネットが使用可能であることを確認します。使用しているインフラストラクチャー・アカウントが、複数の IBM Cloud アカウントで共有されている場合があります。この場合、ibmcloud oc subnetsバインドされたクラスター**があるサブネットを表示するために ** コマンドを実行しても、自分のクラスターの情報のみが表示されます。サブネットが使用可能であり、他のアカウントやチームで使用されていないことをインフラストラクチャー・アカウント所有者に確認してください。
ibmcloud ks cluster subnet add コマンドを使用して、クラスターで既存のサブネットを使用できるようにします。
クラスターにサブネットが正常に作成されて追加されたことを確認します。サブネットの CIDR は Subnet VLANs セクションにリストされます。
```
ibmcloud ks cluster get --cluster CLUSTER_NAME --show-resources
```
次の例の出力では、2 番目のサブネットがパブリック VLAN の 2234945 に追加されています。
```
Subnet VLANs
VLAN ID   Subnet CIDR          Public   User-managed
2234947   10.xxx.xx.xxx/29     false    false
2234945   169.xx.xxx.xxx/29    true     false
2234945   169.xx.xxx.xxx/29    true     false
```
追加したサブネットのポータブル IP アドレスがクラスター内の Ingress コントローラーに使用されていることを確認します。サービスが新しいサブネットのポータブル IP アドレスを使用するには、数分かかる場合があります。
- Ingress サブドメインなし: ibmcloud ks cluster get --cluster CLUSTER を実行して、Ingress サブドメイン にデータが取り込まれていることを確認します。
- Ingress コントローラーがゾーンにデプロイされない: oc get svc -n openshift-ingress を実行して、欠落している Ingress コントローラーが外部 IP アドレスを使用してデプロイされていることを確認します。

複数ゾーン Ingress コントローラー・サービスのデプロイメントの問題の解決

Ingressコントローラーサービスがデプロイされなかったゾーンに、Ingressコントローラーサービスを作成します。重複する Ingress コントローラー・サービスが最初に別のゾーンに作成された場合は、その Ingress コントローラー・サービスを削除 しない でください。

Ingressコントローラーサービスがデプロイされていないゾーンに、そのIngressコントローラーサービス用のYAMLファイルを作成します。 Ingress コントローラー・サービスの router-<zone> に名前を付けます。

 apiVersion: v1
 kind: Service
 metadata:
   annotations:
     service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: public
   finalizers:
   - service.kubernetes.io/load-balancer-cleanup
   labels:
     app: router
     ingresscontroller.operator.openshift.io/owning-ingresscontroller: default
     router: router-default
   name: router-<zone>
   namespace: openshift-ingress
 spec:
   externalTrafficPolicy: Cluster
   selector:
     ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default
   sessionAffinity: None
   type: LoadBalancer

クラスター内に Ingress コントローラー・サービスを作成します。
```
oc create -f router-<zone>.yaml
```

Ingress コントローラー・サービスが正しいゾーンに作成されていることを確認します。出力で、EXTERNAL IP アドレスを取得します。

oc get svc router-<zone> -n openshift-ingress

出力例

NAME                         TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                      AGE
router-dal12                 LoadBalancer   172.21.57.132    169.XX.XX.XX    80/TCP,443/TCP,1940/TCP      3m

デフォルトの Ingress コントローラーのサブドメインを取得します。出力で、<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud のような形式のサブドメインを探します。
```
ibmcloud ks nlb-dns ls -c CLUSTER_NAME_OR_ID
```
Ingress コントローラー・サービスの IP アドレスを Ingress コントローラーのサブドメインに登録します。
```
ibmcloud ks nlb-dns add -c CLUSTER_NAME_OR_ID --ip ROUTER_SVC_IP --nlb-host ROUTER_SUBDOMAIN
```