1.1.28バージョン情報と更新アクション
このバージョンは非推奨。 クラスタをできるだけ早く サポートされているバージョン に更新してください。
IBM Cloud® Kubernetes Serviceのバージョン 1.28 に関する情報を確認します。 Kubernetes プロジェクト・バージョン 1.28について詳しくは、 Kubernetes 変更ログを参照してください。
IBM Cloud Kubernetes Serviceは、CNCFKubernetesソフトウェア適合性認定プログラムに基づくバージョン1.28の認定Kubernetes製品です。 Kubernetes ® は、The Linux Foundation の米国およびその他の国における登録商標であり、The Linux Foundation のライセンスに従って使用されます。
リリース・タイムライン
以下の表はIBM Cloud® Kubernetes Serviceのバージョン1.28のリリース予定です。 この情報は、バージョンがサポート対象外になる可能性がある一般的な時間を見積もるなど、計画の目的に使用できます。
剣標 (†
) の付いた日付は暫定的な日付であり、変更されることがあります。
バージョン | サポートされましたか? | リリース日 | サポート終了日 |
---|---|---|---|
1.28 | ある | 2023 年 9 月 20 日 | 2025年5月31日 † |
更新の準備
この情報は、クラスタをバージョン1.28にアップデートする際に、デプロイ済みアプリに影響を与える可能性のあるアップデートをまとめたものです。 変更の完全なリストについては、 コミュニティー Kubernetes 変更ログ と、バージョン 1.28の IBM バージョン変更ログ を参照してください。 Kubernetes の役立つ警告を確認することもできます。
IBM Cloud Kubernetes Service バージョン 1.28 では、コア・ノードとコントロール・プレーン・コンポーネント間のサポートされるスキューが 1 マイナー・バージョン拡張されて いません。 サポートされるスキューは n-2
のままです。 詳しくは、 Kubernetes コミュニティー情報の「 コントロール・プレーンとノードのバージョンの間のサポートされるスキューの変更 」を参照してください。
マスターの前に行う更新
以下の表に、Kubernetes マスターを更新する前に実行する必要があるアクションを示します。
タイプ | 説明 |
---|---|
ポッド hostPort |
hostNetwork: true を設定してポートを宣言するポッドは、 hostPort フィールド・セットを自動的に取得します。 以前は、 Deployment 、 DaemonSet 、またはその他のワークロード・リソースのポッド・テンプレートで hostPort が設定されていました。 ここで、 hostPort は Pod リソースにのみ設定されます。 アプリが以前の動作に依存している場合は、それに応じてアップデートしてください。 |
VPC クラスターに対するネットワーキングの変更 | バージョン 1.27 およびそれ以前では、VPC クラスターは IBM Cloud Container Registry から Container Registry のプライベート クラウド サービス エンドポイントを通してイメージを取得します。 バージョン 1.28 以降の場合、イメージがプライベート・サービス・エンドポイントではなく VPE ゲートウェイを介してプルされるように、このネットワーク・パスが更新されます。 更新アクションについては、 VPC クラスターのネットワーキングの変更 を参照してください。 |
マスターの後に行う更新
タイプ | 説明 |
---|---|
kubectl version 出力および --short オプション |
kubectl version 出力は、前の kubectl version --short 出力と一致するように変更されました。 さらに、 --short オプションは削除されました。 以前の動作に依存したスクリプトがある場合は更新してください。 |
kubelet レガシー iptables チェーン |
kubelet は、 KUBE-MARK-DROP および KUBE-MARK-MASQ iptables チェーンを作成しなくなりました。 アプリがこれらのチェーンに依存している場合は、それに応じて更新してください。 詳しくは、 Kubernetesの IPTables Chains Are Not API を参照してください。 |
VPC クラスターのネットワーキングの変更
バージョン 1.27 およびそれ以前では、VPC クラスターは IBM Cloud Container Registry から Container Registry のプライベート クラウド サービス エンドポイントを通してイメージを取得します。 バージョン 1.28 以降の場合、イメージがプライベート・サービス・エンドポイントではなく VPE ゲートウェイを介してプルされるように、このネットワーク・パスが更新されます。 この変更は VPC 内のすべてのクラスタに影響します。VPC 内の 1 つのクラスタをバージョン 1.28 に作成または更新すると、バージョンに関係なく、その VPC 内のすべてのクラスタのネットワーク パスが更新されます。 セキュリティ グループ、ネットワーク ACL、およびネットワーク ポリシーのセットアップによっては、バージョン 1.28 に更新した後もワーカーがコンテナ イメージを正常にプルできるように変更する必要があるかもしれません。
以下のイメージは、プライベート・サービス・エンドポイントではなく、レジストリー用の VPE ゲートウェイを使用する、バージョン 1.28の新しいネットワーク・パスを示しています。
バージョン 1.28でネットワーク・パスが更新されたため、バージョン 1.28 で実行する VPC クラスターを作成または更新すると、VPC に新しい VPE ゲートウェイが追加されます。 この VPE ゲートウェイは、特に IBM Cloud Container Registry からイメージを引き出すために使用され、少なくとも 1 つのクラスターワーカーを持つ VPC 内の各ゾーンに 1 つの IP アドレスが割り当てられます。 すべての icr.io
ドメイン・ネームを新しい VPE ゲートウェイ IP アドレスに解決する DNS エントリーが VPC 全体に追加されます。 ネットワーク・セキュリティー・コンポーネントの構成方法によっては、新しい VPE への接続が許可されていることを確認するためのアクションが必要になる場合があります。
必要な作業
VPC クラスターのワーカー・ノードが Container Registry からイメージをプルし続けるようにするために実行する必要がある手順は、ネットワーク・セキュリティーのセットアップによって異なります。
- すべてのセキュリティー・グループ、ネットワーク ACL、およびネットワーク・ポリシーに対してデフォルトのネットワーク・ルールを使用する場合は、アクションを実行する必要はありません。
- VPC 内の特定の TCP 接続をブロックするカスタマイズされたネットワーク・セキュリティー・セットアップがある場合は、バージョン 1.28の新規クラスターを更新または作成する前に、追加のアクションを実行する必要があります。 レジストリー用の新しい VPE ゲートウェイへの接続が許可されるように、以下のセクションで調整を行います。
追加のステップを実行する必要があるかどうかに関係なく、バージョン 1.28 を実行しない他のクラスターを VPC 内に保持する場合は、それらのクラスターで クラスター・マスターをリフレッシュ する必要があります。 これにより、新しい VPE へのトラフィックが許可されるように、正しい更新が non-1.28 クラスターに適用されます。
カスタム・セキュリティー・グループがあります。 何を変更すればよいですか?
バージョン 1.28のクラスターを更新または作成すると、必要な許可ルールが自動的に IBM管理対象 kube-<cluster_ID>
クラスター・セキュリティー・グループに追加されます。 ただし、 kube-<cluster_ID>
クラスター・セキュリティー・グループ・ルールを使用 しない VPC クラスターを作成した場合は、レジストリーの VPE ゲートウェイへのトラフィックを許可するために、以下のセキュリティー・グループ・ルールが実装されていることを確認する必要があります。
カスタム・セットアップでルールがまだ実装されていない場合は、 ルールを追加 します。 これらの各ルールは、VPC 内のゾーンごとに作成する必要があり、ゾーンの VPC アドレス接頭部範囲全体を宛先 CIDR として指定する必要があります。 VPC 内の各ゾーンの
VPC アドレス接頭部の範囲を見つけるには、 ibmcloud is vpc-address-prefixes <vpc_name_or_id>
を実行します。
カスタムセキュリティグループに以下のルールを追加する。
ルール・タイプ | プロトコル | 宛先の IP または CIDR | 宛先ポート |
---|---|---|---|
アウトバウンド | TCP | VPC アドレス接頭部の範囲全体 | 443 |
これらの規則をより限定的にするには、VPE ゲートウェイによって使用されるセキュリティー・グループに宛先を設定するか、正確な VPE ゲートウェイ予約 IP アドレスを指定します。 VPC 内のすべてのクラスター・ワーカーが削除されると、これらの IP アドレスが変更される可能性があることに注意してください。
カスタム ACL があります。 何を変更すればよいですか?
クラスター・ワーカーに適用される VPC ネットワーク ACL が、特定の発信トラフィックと着信トラフィックのみを許可するようにカスタマイズされている場合は、VPE Gateway for Registry との間の接続を許可するために、以下の ACL ルールまたは同等のルールが実装されていることを確認してください。 ルールがまだ実装されていない場合は、 ルールを追加 します。 これらの各ルールは、VPC 内のゾーンごとに作成する必要があり、ゾーンの VPC アドレス接頭部範囲全体をソース (アウトバウンド・ルールの場合) または宛先 (インバウンド・ルールの場合) として指定する必要があります。 CIDR。 VPC 内の各ゾーンの VPC アドレス接頭部の範囲を見つけるには、 ibmcloud is vpc-address-prefixes <vpc_name_or_id>
を実行します。 各ルールの優先順位は、このトラフィックを拒否するルール
(すべてのトラフィックを拒否するルールなど) より高くする必要があります。
カスタムACLに以下のルールを追加する。
ルール・タイプ | プロトコル | 送信元の IP または CIDR | 送信元ポート | 宛先の IP または CIDR | 宛先ポート |
---|---|---|---|---|---|
アウトバウンド/許可 | TCP | VPC アドレス接頭部の範囲全体 | 任意 | VPC アドレス接頭部の範囲全体 | 443 |
インバウンド/許可 | TCP | VPC アドレス接頭部の範囲全体 | 443 | VPC アドレス接頭部の範囲全体 | 任意 |
カスタム・ネットワーク・ポリシーがあります。 何を変更すればよいですか?
Calico ポリシーを使用してクラスター・ワーカーからのアウトバウンド接続を制限する場合は、以下のポリシー・ルールを追加して VPE Gateway for Registry への接続を許可する必要があります。 このポリシーは、VPC 内のゾーンごとに作成する必要があり、ゾーンの VPC アドレス接頭部範囲全体を宛先 CIDR として指定する必要があります。 VPC 内の各ゾーンの VPC アドレス接頭部の範囲を見つけるには、 ibmcloud is vpc-address-prefixes <vpc_name_or_id>
を実行します。
apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
name: allow-vpe-gateway-registry
spec:
egress:
- action: Allow
destination:
nets:
- <entire-vpc-address-prefix-range> # example: 10.245.0.0/16
ports:
- 443
protocol: TCP
source: {}
order: 500
selector: ibm.role == 'worker_private'
types:
- Egress