IBM Cloud Docs
1.1.30バージョン情報と更新アクション

1.1.30バージョン情報と更新アクション

IBM Cloud® Kubernetes Serviceのバージョン 1.30 に関する情報を確認してください。 Kubernetes プロジェクトのバージョン 1.30について詳しくは、 Kubernetes の変更ログを参照してください。

This badge indicates Kubernetes version 1.30 certification for IBM Cloud Kubernetes Service
Kubernetes version 1.30 certification badge

IBM Cloud Kubernetes Serviceは、CNCFKubernetesソフトウェア適合性認定プログラムに基づくバージョン1.30の認定Kubernetes製品です。 Kubernetes ® は、The Linux Foundation の米国およびその他の国における登録商標であり、The Linux Foundation のライセンスに従って使用されます。

リリース・タイムライン

以下の表はIBM Cloud® Kubernetes Serviceのバージョン1.30のリリース予定です。 この情報は、バージョンがサポート対象外になる可能性がある一般的な時間を見積もるなど、計画の目的に使用できます。

剣標 (†) の付いた日付は暫定的な日付であり、変更されることがあります。

IBM Cloud Kubernetes Service バージョン 1.30
バージョン サポートされましたか？ リリース日 サポート終了日
1.30 ある 2024 年 5 月 29 日 2025 年 8 月 13 日 †

更新の準備

この情報は、クラスタをバージョン1.30にアップデートする際に、デプロイ済みアプリに影響を与える可能性のあるアップデートをまとめたものです。 変更の完全なリストについては、バージョン 1.30の コミュニティー Kubernetes 変更ログ および IBM バージョン変更ログ を参照してください。 Kubernetes の有用な警告を確認することもできます。

バージョン 1.30 でプロビジョンされた VPC ワーカー・ノードでは、VPC インスタンス・メタデータ・サービスが有効になっています。 詳細については、VPCインスタンス・メタデータ についてを参照してください

マスターの前に行う更新

以下の表に、Kubernetes マスターを更新する前に実行する必要があるアクションを示します。

マスターを Kubernetes 1.30
タイプ 説明
Calico オペレーターの名前空間のマイグレーション クラスターがバージョン 1.29にアップグレードされた場合は、 Calico オペレーターの名前空間のマイグレーションが開始されています。 クラスターをバージョン 1.30にアップグレードするには、その前にこのマイグレーションを完了する必要があります。 次のコマンドでデータが返されない場合、マイグレーションは完了しています: kubectl get nodes -l projectcalico.org/operator-node-migration --no-headers --ignore-not-found ; kubectl get deployment calico-typha -n kube-system -o name --ignore-not-found。
VPCクラスタをバージョン1.30に作成または更新する際のVPEゲートウェイの変更 1.30クラスタを作成する場合、または1.30に更新する場合、VPCクラスタに使用されるVPEゲートウェイに重要な変更があります。 このような変化には対処が必要かもしれない。 変更を確認し、必要なアクションを決定するには、VPEゲートウェイの作成情報 を参照してください。

マスターの後に行う更新

以下の表に、Kubernetes マスターを更新した後に実行する必要があるアクションを示します。

マスターを Kubernetes 1.30
タイプ 説明
非推奨: ポッド container.apparmor.security.beta.kubernetes.io のアノテーション。 ポッドの container.apparmor.security.beta.kubernetes.io アノテーションが非推奨になりました。 これらのアノテーションは、ポッドおよびコンテナーの securityContext.appArmorProfile フィールドに置き換えられます。 これらの非推奨アノテーションにポッドが依存している場合は、代わりに securityContext.appArmorProfile フィールドを使用するようにアノテーションを更新します。 詳しくは、 Restrict a Container 's Access to Resources with AppArmor を参照してください。
非サポート: kubectl apply --prune-whitelist オプション kubectl apply の非推奨の --prune-whitelist オプションは削除され、 --prune-allowlist オプションに置き換えられました。 以前の動作に依存したスクリプトがある場合は更新してください。
kubectl get cronjob 出力 kubectl get cronjob 出力が変更され、タイム・ゾーン列が含まれるようになりました。 以前の動作に依存したスクリプトがある場合は更新してください。
KubernetesAPIサーバの監査ポリシー Kubernetes API サーバー default および verbose 監査ポリシー が更新されました。 アプリが以前のポリシーに依存している場合は、それを更新する。

バージョン 1.30 で作成された VPC クラスターの重要なネットワーキングの変更

バージョン 1.30以降、 IBM Cloud Kubernetes Service では、Secure by Default Cluster VPC Networking という VPC クラスター用の新しいセキュリティー機能が導入されました。

大まかには、 IBM Cloud Kubernetes Service VPC クラスターのセキュリティー態勢が、すべてのアウトバウンド・トラフィックを許可することから、必要に応じてトラフィックを選択的にブロックするメカニズムをユーザーに提供することから、クラスター機能にとって重要ではないすべてのトラフィックをブロックし、必要に応じてトラフィックを選択的に許可するメカニズムをユーザーに提供するように変更されました。

バージョン 1.30 以降の新しい IBM Cloud Kubernetes Service VPC クラスターをプロビジョンする場合、デフォルトのプロビジョニング動作では、クラスターが機能するために必要なトラフィックのみが許可されます。 それ以外のアクセスは遮断される。 「Secure by Default Networking」を実装するために、デフォルトの VPC セキュリティー・グループ設定と、一般的な IBM サービス用の新しい仮想プライベート・エンドポイント (VPE) が変更されています。

「Secure by Default Networking」には、以下のような重要な注意事項があります。

  • VPC クラスターにのみ適用されます。 クラシック・クラスターは影響を受けません。

  • 既存のクラスターには影響しません。 VPC内の既存のクラスタは現在と同様に機能します。

  • バージョン 1.30で新しくプロビジョンされた IBM Cloud Kubernetes Service クラスターにのみ適用されます。 バージョン 1.30にアップグレードされた既存の IBM Cloud Kubernetes Service クラスターのセキュリティー・グループ構成 (行ったカスタマイズを含む) は変更されません。

  • バージョン 1.30 以降で作成されたクラスターのデフォルトの動作では、Secure by Default アウトバウンド・トラフィック保護が有効になります。 ただし、UI、CLI、API、および Terraform の新規パラメーターでは、この機能を無効にすることができます。 クラスターの作成後に、アウトバウンド・トラフィック保護を有効または無効にすることもできます。

  • VPC でカスタム DNS リゾルバーを使用している場合、新しいバージョン 1.30 クラスターをプロビジョンすると、IKS 管理セキュリティー・グループ (kube-<clusterID>) 上のリゾルバー IP アドレスを介したトラフィックを許可するルールが自動的に追加されます。

デフォルトで作成されるセキュリティー・グループ、ルール、および VPE を含む、Secure by Default Cluster VPC ネットワーキングの概要については、 Understanding Secure by Default Cluster VPC Networking を参照してください。

どの接続が許可されているか。

デフォルトでセキュア・アウトバウンド・トラフィック保護が有効になっている VPC クラスターでは、以下の接続が許可されます。

  • VPE ゲートウェイを介して必要なコンテナー・イメージをプルするために、内部 IBM *.icr.io レジストリーにアクセスします。
  • VPE ゲートウェイを介したクラスター・マスターおよび IBM Cloud Kubernetes Service API へのアクセス。
  • プライベート IBM ネットワークを介したロギングやモニタリングなど、その他の重要な IBM サービスへのアクセス。
  • IBM CloudDNSにアクセスする。

どの接続がブロックされていますか?

デフォルトでブロックされている接続の以下の例を確認してください。 アプリが必要とするこれらの外部ソースまたはその他の外部ソースへのアウトバウンド・トラフィックを選択的に有効にすることができます。

  • quay.io や Docker Hub などのパブリック・レジストリーからイメージをプルしています。
  • パブリック・ネットワークを介した任意のサービスへのアクセス。

ワーカーとマスターの間のバックアップ通信の変更点

VPC クラスター・ワーカーは、プライベート・ネットワークを使用してクラスター・マスターと通信します。 以前は、パブリック・サービス・エンドポイントが有効になっていた VPC クラスターでは、プライベート・ネットワークがブロックまたは使用不可の場合、クラスター・ワーカーは、パブリック・ネットワークを使用してクラスター・マスターと通信するようにフォールバックできました。

Secure by Default アウトバウンド・トラフィック保護を使用するクラスターでは、クラスター・ワーカーからのパブリック・アウトバウンド・トラフィックがブロックされるため、パブリック・ネットワークへのフォールバックはオプションではありません。 このパブリック・ネットワーク・バックアップ・オプションを許可するために、アウトバウンド・トラフィック保護を使用不可にすることもできますが、より良い代替方法があります。 代わりに、プライベート・ネットワークを介したワーカーとマスターの間の接続に一時的な問題がある場合は、その時点で、 kube-clusterID セキュリティー・グループに一時的なセキュリティー・グループ・ルールを追加して、クラスター・マスターの apiserver ポートへのアウトバウンド・トラフィックを許可することができます。 この方法では、すべてのトラフィックではなく、 apiserver のトラフィックのみを許可します。 後で問題が解決されたら、一時ルールを削除できます。

1.30 クラスターの作成後のアウトバウンド・トラフィックの許可

アウトバウンド・トラフィック保護を有効にしてバージョン 1.30 クラスターを作成した場合、外部ネットワーク接続を必要とする依存関係が原因で、アプリまたはサービスでダウン時間が発生する可能性があります。 アウトバウンド・トラフィックを選択的に有効にするか、すべてのアウトバウンド・トラフィックを許可するかについては、以下のオプションを確認してください。

詳しくは、 VPC クラスターでのアウトバウンド・トラフィック保護の管理 を参照してください。

VPEゲートウェイ作成情報

When a VPC cluster is created at or updated to version 1.30, the following VPE gateways are created if they do not exist.

バージョン1.30におけるVPEゲートウェイの変更点
VPEのDNS名 サービス バージョン
s3.direct.<region>.cloud-object-storage.appdomain.cloud および *.s3.direct.<region>.cloud-object-storage.appdomain.cloud Cloud Object Storage バージョン1.30以降
config.direct.cloud-object-storage.cloud.ibm.com Cloud Object Storageの構成 バージョン1.30以降
<region>.private.iaas.cloud.ibm.com VPC インフラストラクチャー バージョン1.30以降
icr.io」と「*.icr.io* Container Registry バージョン1.28以降
api.<region>.containers.cloud.ibm.com* IBM Cloud Kubernetes Service バージョン1.28以降
  • クラスタが1.30にアップデートされた場合、これらのVPE Gatewayはクラスタが1.28または1.29のときに作成されているため、すでに存在しているはずです。 これらのVPEゲートウェイは、VPC内のすべてのリソースで共有され、最初に作成されると、これらのサービスに関連するIPアドレスを変更し、アクセスを制限します。

VPC 内のリソースが、VPE ゲートウェイがまだ存在しないこれらのサービスのいずれかを使用している場合は、アップデートの前と、場合によってはアップデート中に、以下に説明するアクションを実行して、リソースが引き続きアクセスできるようにする必要があります。

1.30クラスタを新規に作成するか、既存の1.29クラスタのマスタをアップグレードするかによって、実行する手順は異なります。

  • 新しい1.30クラスタには、上記のSecure by Default設定が適用されます。
  • アップグレードされた既存の1.29クラスタは、引き続き古いセキュリティグループモデルを使用します。

バージョン1.30へのアップグレード時に作成されるVPEゲートウェイ

1.30用の3つの新しいVPEゲートウェイが、VPCにまだ存在していなければ作成される。 また、クラスターワーカーがいる各ゾーンのVPEゲートウェイには、ゾーンごとに1つのIPアドレスが追加されます。 これらのIPアドレスは、そのゾーンの既存のVPCサブネットの1つから取得される。

VPEゲートウェイは既存の'kube-<vpcID> セキュリティグループに入れられ、デフォルトではすべてのトラフィックを許可する。 このセキュリティグループを変更しない限り、新しいVPE Gatewayへのインバウンドアクセスを許可するルールを追加する必要はない。

kube-<vpcID> セキュリティ・グループを変更した場合は、これらのサービスを使用するVPC内のすべてのリソースが、このセキュリティ・グループへのインバウンド・アクセスを許可されていることを確認する必要があります。 また、サブネット上のネットワークACL、リソース自体のセキュリティグループ、またはカスタムVPCルートが、これらの新しいVPEゲートウェイへのアクセスをブロックしていないことを確認してください。

新しい1.30クラスタ作成時の新しいVPEゲートウェイ設定

VPEゲートウェイがまだVPCに存在しない場合は、5つの新しいVPEゲートウェイが作成される。 また、クラスタワーカーがいる各ゾーンのVPEゲートウェイには、ゾーンごとに1つのIPアドレスが追加されます。 これらのIPアドレスは、そのゾーンの既存のVPCサブネットの1つから取得される。

VPE ゲートウェイは新しい「kube-vpegw-<vpcID> セキュリティグループに入れられ、クラスタワーカーセキュリティグループ「kube-<clusterID> 新しい VPE ゲートウェイへのインバウンドトラフィックのみが許可されます。

クラスタを作成する前に、これらのエンドポイントにアクセスするVPC内のリソースについて、サブネット上のネットワークACL、リソース自体のセキュリティグループ、または新しいVPEゲートウェイへのアクセスをブロックするカスタムVPCルートがないことを確認してください。

クラスタが更新されたら、「kube-vpegw-<vpcID> セキュリティ・グループが作成されるのを確認してください。 作成後、必要なインバウンドルールを追加して、クラスタワーカーではないすべてのリソースが、作成される新しいVPEゲートウェイにアクセスできるようにします。 VPC内のすべてのクラスタワーカーは、クラスタの作成時に自動的に追加されるセキュリティグループルールによって、すでにこれらのVPEゲートウェイにアクセスできることに注意してください。

同様の使用例についての詳細は、VPCアプリケーションのトラブルシューティング を参照してください。

一般的な問題とトラブルシューティング