バージョン 4.15 クラスターを作成した後、VPC 内の他のクラスターで実行されているアプリケーションで障害が発生する

仮想プライベートクラウド 4.15 そしてその後

Satellite ストレージを使用する際、非サテライトクラスターに関する問題のトラブルシューティングを行います。

カスタムセキュリティグループのみを使用しており、バージョン 4.15 クラスタを作成した後、VPC 内の他のクラスタでワーカーの作成失敗とイメージのプルエラーが発生します。

以下のステップは、管理対象セキュリティー・グループの使用をオプトアウトし、代わりに独自のカスタム・セキュリティー・グループを使用しているシナリオにのみ適用されます。

セキュア・バイ・デフォルト・クラスターVPCネットワーキングがバージョン 4.15 で導入されたことで、ネットワーク・トラフィックの管理に新しいVPEゲートウェイとマネージド・セキュリティ・グループが使用されるようになった。

これらの新しいリソースやルールにより、以前のクラスターの作成方法によっては、VPC内の既存のクラスターでネットワークエラーが発生する可能性があります。

バージョン 4.15 クラスターを作成する前に、管理対象クラスター・セキュリティー・グループを使用しないクラスターを作成しました。

例えば、以前に --cluster-security-group オプションを指定した cluster create vpc-gen2 コマンドを使用してクラスターを作成し、 cluster オプションを含めなかったとします。

初めて Secure by Default クラスターを作成すると、以下のリソースが作成されます。

共有 VPE ゲートウェイ・セキュリティー・グループが作成されます (kube-vpegw-<vpcID>)。すべての新規および既存の共有 VPE ゲートウェイが、それを使用するように更新されます。
以前に同じ VPC 内に存在していた kube-<clusterID> などの管理対象セキュリティー・グループは、新しいルールで更新され、新しい共有 VPE ゲートウェイ・セキュリティー・グループを介したトラフィックが許可されます。
同じ VPC 内の今後の非セキュア・バイ・デフォルト・クラスターでは、IKS 管理クラスター・セキュリティー・グループ (kube-<clusterID>) を介した新しい共有 VPE ゲートウェイ・セキュリティー・グループを介したトラフィックが許可されます。

管理対象クラスター・セキュリティー・グループを使用しない既存または将来の非セキュア・クラスターは、VPE ゲートウェイを介してサービスにアクセスできなくなります。例えばレジストリ、 Red Hat OpenShift on IBM Cloud APIなど。

この問題を修正するには、お客様が定義したセキュリティー・グループの 1 つから、共有 VPE ゲートウェイ・セキュリティー・グループにインバウンド・セキュリティー・グループ・ルールを追加します。

セキュリティー・グループと kube-vpegw-<vpcID> セキュリティー・グループの両方のセキュリティー・グループ ID を見つけます。
```
ibmcloud is security-groups
```
カスタム・セキュリティー・グループから kube-vpegw-<vpcID> にリモート・ルールを追加します。
```
ibmcloud is sg-rulec KUBE-VPEGW-VPCID inbound icmp_tcp_udp --remote YOUR_SG_ID
```
カスタム・セキュリティー・グループから kube-vpegw-<vpcID> にリモート・ルールを追加します。
```
ibmcloud is sg-rulec  <your SG> outbound icmp_tcp_udp --remote  <ID of kube-vpegw-vpcID>
```