Container Service for Kubernetes (ACK) は、認定Kubernetes適合プログラムの条項に厳密に準拠しています。 このトピックでは、更新ノート、主要な変更、新機能、非推奨の機能とAPI、機能ゲートなど、Kubernetes 1.30の更新について説明します。
コンポーネントのバージョン
Kubernetes 1.30では、次の主要コンポーネントバージョンがサポートされています。
キーコンポーネント | バージョン |
Kubernetes | 1.30.1-aliyun.1 |
etcd | v3.5.9 |
containerd | 1.6.28 |
CoreDNS | v1.9.3.10-7dfca203-aliyun |
CSI | v1.30.1-98960d8-aliyun |
CNI | フランネルv0.15.1.22-20a397e6-aliyun |
TerwayおよびTerwayControlplane 1.9.0以降 説明 Kubernetes 1.30以降、クラスターを作成し、ネットワークプラグインとしてTerwayを選択してネットワークポリシーを設定すると、ネットワークポリシーの実装は拡張バークレーパケットフィルター (eBPF) に基づいて行われます。 クラスターとコンポーネントの更新は、既存の動作を変更しません。 詳細については、「ACKクラスターでのネットワークポリシーの使用」をご参照ください。 |
メモの更新
項目 | 説明 | 解決策 |
オペレーティングシステム | CentOSとAlibaba Cloud Linux 2は、ノードプールオペレーティングシステムとしてサポートされなくなりました。 詳細については、「 [製品の変更] Alibaba Cloud Linux 2およびCentOS 7の廃止」をご参照ください。 | ノードプールを更新することで、ノードプールのオペレーティングシステムを変更できます。 詳細については、「ノードプールの更新」をご参照ください。 Alibaba Cloudの公式オペレーティングシステムContainerOSおよびAlibaba Cloud Linux 3を使用することを推奨します。 |
kube-proxy | 1.29以降のバージョンのKubernetesでは、kube-proxyはconntrack_maxの値の設定に使用されるメソッドを更新します。 conntrack_maxの値は、kube-proxy設定とノード上のCPUコア数に基づいて計算および更新できます。 1.23から1.28までのKubernetesバージョンでは、kube-proxyはクラスター管理者が手動で設定したconntrack_maxの値を上書きしません。 Kubernetesバージョンを1.29に更新すると、kube-proxyは新しいロジックに基づいてconntrack_maxの値を自動的に減少させる場合があります。 詳細については、「 #120448」をご参照ください。 | conntrack_maxの値を変更した場合は、更新前に syctls値が変更されているかどうかを確認するには、クラスター検査機能を有効にします。 詳細については、「クラスター検査機能の操作」をご参照ください。 |
特徴
Kubernetes 1.29
PreStopフックにスリープモードが追加されています。 このモードでは、コンテナが終了する前に指定された期間一時停止できます。 詳細については、「KEP-3960: PreStopフックのスリープアクションの紹介」をご参照ください。
SidecarContainers機能はベータ版に達し、デフォルトで有効になっています。 この機能を使用すると、
restartPolicy
をAlways
に設定して、initコンテナーをサイドカーコンテナーとして実行できます。 Sidecarコンテナーは、メインアプリケーションコンテナーやその他のinitコンテナーに影響を与えることなく、独立して開始、停止、および再起動できます。 詳細については、「サイドカーコンテナ」をご参照ください。サービスCIDRは、ClusterIPサービスのIPアドレス範囲を動的に指定するためにサポートされています。 この機能はAlphaに達し、デフォルトで無効になっています。 サービスで使用可能なIPアドレスの数を動的に増やす方法の詳細については、「KEP-1880: 複数のサービスCIDR」をご参照ください。
Persistent volume要求 (PVC) とコンテナーAPIは、同じResourceRequirements構造を使用して、リソース
要求
と制限
を定義します。 その結果、コンテナAPIのリソース
構造が変更された場合、たとえば、クレーム
フィールドが追加された場合、PVC APIのリソース構造も変更されます。 この問題を防ぐために、PVC APIは、リクエスト
と制限
のみで構成される独立したVolumeResourceRequirements構造を使用するようになりました。 構造はクレーム
ではありません。 詳細については、「ボリュームリソースの要件」をご参照ください。PodReadyToStartContainers
機能はベータ版に達し、デフォルトで有効になっています。 この機能は、ポッドのサンドボックス化されたランタイム環境が作成され (ランタイム環境の準備ができました) 、ネットワークが構成されていることを示します。 これにより、kubeletはポッドのステータスを知ることができます。 詳細については、「ポッド条件」をご参照ください。ポッドアフィニティとポッドアンチアフィニティはmatchLabelKeysとmismatchLabelKeysをサポートして、デプロイのローリング更新中にスケジューラが古いポッドと新しいポッドを区別できないという問題を解決します。 この問題が発生すると、ポッドはポッドアフィニティまたはポッドアンチアフィニティのルールに基づいてスケジュールされません。 ポッドアフィニティのmatchLabelKeysを構成すると、デプロイによって
pod-template-hash
ラベルがReplicaSetに追加されます。 このように、Deploymentの各ポッドは同じハッシュ文字列を持ちます。 これにより、スケジューラは、同じ更新バッチ内のポッドを区別するために、同じpod-template-hash
値を持つポッドを評価することができます。 詳しくは、「KEP-3633」をご参照ください。コアKubernetes APIリソースに加えて、ValidatingAdmissionPoliciesはCustomResourceDefinitions (CRD) とAPI拡張機能もサポートしています。 これにより、ポリシーの信頼性とクラスター構成の有効性が確保されます。 詳細については、「タイプチェック」をご参照ください。
UserNamespacesPodSecurityStandards機能ゲートが追加され、ユーザー名前空間がPod Security Standardsをサポートできるようになりました。 この機能ゲートを有効にすると、root以外のユーザーIDまたはポッドセキュリティコンテキストで指定されたユーザーIDを使用してコンテナーを実行できます。 このフィーチャゲートはAlphaに達しており、デフォルトではfalseに設定されています。 特徴ゲートは、後のバージョンでは偽状態のままであってもよい。 詳細については、「KEP-127: フィーチャゲートに基づくPSSの更新」をご参照ください。
ノードオブジェクトにDisableNodeKubeProxyVersion機能ゲートが追加されました。
status.nodeInfo.kubeProxyVersion
フィールドは非推奨です。 これは、Kubernetesのノードに対してkubeProxyVersion
フィールドが無効になっていることを意味します。 kubeletが正しいkube-proxyバージョンを認識できない場合があります。 したがって、このフィールドの値は不正確です。 このフィーチャゲートはAlphaに達しており、デフォルトではfalseに設定されています。JobBackoffLimitPerIndex機能ゲートはベータに達し、デフォルトでtrueに設定されています。 この機能ゲートを使用すると、インデックス付きジョブの各インデックスの再試行の最大試行回数を指定できます。 インデックス付きジョブの詳細については、「静的作業割り当てによる並列処理のインデックス付きジョブ」をご参照ください。
Kubernetes 1.30
ImageMaximumGCAgeを使用すると、kubeletを使用して、ガベージコレクションの前に未使用のイメージの最大TTLを設定できます。 TTLが終了しても画像が使用されない場合、画像はガベージコレクションによって削除されます。 デフォルト値は
「0」
です。これは、TTLが設定されていないことを意味します。 この機能ゲートは、Kubernetes 1.29でAlphaに達し、Kubernetes 1.30でBetaに達しました。image_pull_duration_seconds
メトリックがkubeletに追加され、イメージプル時間が追跡されます。 詳細については、「アルファKubernetesメトリクスのリスト」をご参照ください。LegacyServiceAccountTokenCleanUp機能ゲートはGAに達し、デフォルトで有効になっています。 ServiceAccountに関連付けられた自動生成されたSecretが一定期間 (デフォルトでは1年) 内に使用されず、ポッドにマウントされていない場合、kube-controller-managerは
kubernetes.io/legacy-token-invalid-since
ラベルをシークレットに追加します。 シークレットは無効としてマークされます。 ラベル値は現在の日付です。 シークレットが無効としてマークされた日から、一定期間 (デフォルトでは1年) 内にまだ使用されていない場合、kube-controller-managerはシークレットを自動的に削除します。 このラベルがあるが削除されていないSecretsの場合、kubernetes.io/legacy-token-invalid-since
ラベルを削除して、Secretsを再度有効にすることができます。 詳細については、「自動生成されたレガシーServiceAccount token clean up」および「legacy ServiceAccount token cleaner」をご参照ください。Kubernetes 1.30で、
-- nodeport-address
がkube-proxyに設定されていない場合 (このフラグはデフォルトでは設定されていません) 、NodePort Serviceの更新により、すべてのノードIPアドレスが更新されるのではなく、プライマリノードIPアドレスのみが更新されます。 詳細については、「 #122724」をご参照ください。構成の競合とセキュリティの問題を防ぐために、OIDC発行者URLとAPIサーバーServiceAccount発行者URLを同じパラメーターで構成しないでください。 詳細については、「 #123561」をご参照ください。
LoadBalancerIPMode機能ゲートを使用すると、
. status.loadBalancer.ingress.ipMode
フィールドをLoadBalancerサービスに設定し、指定したロードバランサーIPアドレスに送信されるリクエストの転送アクションを指定します。 このフィールドは、. status.loadBalancer.ingress.ip
フィールドを指定します。 LoadBalancerIPMode機能ゲートがベータに達しました。 詳細については、「ロードバランサーステータスのIPModeの指定」および「ロードバランサーIP Mode For Services」をご参照ください。ContainerResourceメトリクスに基づく水平ポッドオートスケーラー (HPA) は、Kubernetes 1.30で安定に達しました。 これにより、HPAは、ポッドのリソース使用量に基づいてスケーリングするのではなく、ポッド内の各コンテナのリソース使用量に基づいて自動スケーリングを構成できます。 このようにして、ポッド内の重要なコンテナに対してスケーリングしきい値を個別に設定できます。 詳細については、「Container resource metrics」をご参照ください。
AdmissionWebhookMatchConditionsフィーチャーゲートがGAに達し、デフォルトで有効になっています。 この機能ゲートは無効にできません。 この機能ゲートを使用すると、承認Webhookの一致条件を定義して、Webhookをよりきめ細かくトリガーできます。 詳細については、「ダイナミックアドミッションコントロール」をご参照ください。
JobSuccessPolicy機能ゲートは、ジョブに属するポッドのグループが成功したときにジョブが完了したことを要求するために追加されます。 ジョブが完了したことを示す特定のインデックス (ポッドインデックスX、Y、Zなど) またはインデックスの数 (3つなど) を指定できます。 この機能ゲートはアルファに達しました。 詳細については、「ジョブの成功 /完了ポリシー」をご参照ください。
RelaxedEnvironmentVariableValidation機能ゲートは、等号 (
=
) を除いて、環境変数で使用されるほとんどの印刷可能なASCII文字 (32から126までのすべての文字) を制御するために追加されます。 この機能ゲートはAlphaに達し、デフォルトで無効になっています。 詳細については、「 #123385」をご参照ください。CustomResourceFieldSelectors
機能ゲートを追加して、CRDのselectableFields
を設定します。 このようにして、特定の条件を満たすCRDを見つけたり管理したりするために、Field Selectorsを訴えてList、Watch、DeleteCollectionリクエストをフィルタリングできます。 この機能ゲートはAlphaに達し、デフォルトで無効になっています。 詳細については、「カスタムリソースフィールドセレクタ」をご参照ください。CRDValidationRatcheting機能ゲートのアップデートがリリースされました。 新しいCRD検証ラチェットが追加された後、既存のリソースが更新後に無効になった場合でも、検証に失敗したリソースが更新されない場合、APIサーバーはリソースの更新をブロックしません。 これにより、既存のリソースやユーザーへの影響を回避できます。 このように、CRDは、移行中にOpenAPI v3スキーマを介して検証できます。 この機能ゲートはベータに達し、デフォルトで有効になっています。 詳細については、「CRD検証ラチェット」をご参照ください。
Downward APIは
status.hostIPs
フィールドを使用してIPv4/IPv6デュアルスタックをサポートします。status.hostIP
リストの最初のIPアドレスは、常にstatus.hostIP
と同じです。 詳細については、「Downward API」をご参照ください。NodeLogQuery機能ゲートを使用すると、
/logs
エンドポイントを使用してノードサービスログを照会できます。 この機能ゲートはベータに達しており、デフォルトではfalseに設定されています。 詳細は、「ログクエリ」をご参照ください。
非推奨の機能
Kubernetes 1.29
CronJobsはサポートしなくなりました。
CRON_TZ
またはTZ
設定で. spec.schedule
.. spec.timeZone
フィールドは代替として使用されます。 このフィールドは、Kubernetes 1.25以降のバージョンで使用できます。 詳細については、「CronJobの制限」をご参照ください。Alphaのネットワーク /v1alpha API ClusterCIDRが削除されました。
Kubernetes 1.30
kubectl applyコマンドの
-- prune-whitelist
パラメーターが削除されました。-- prune-allowlist
を使用することを推奨します。 詳細については、「 -- prune」をご参照ください。承認プラグインはKubernetes 1.27では廃止され、Kubernetes 1.30では削除されます。 PodSecurityの承認プラグインを使用することを推奨します。 このプラグインはKubernetes 1.25でStableに達しており、デフォルトで有効になっています。 詳細については、「PodSecurity」をご参照ください。
非推奨API
flowcontrol.apiserver.k8s.io/v1beta2 APIバージョンのFlowSchemaとPriorityLevelConfigurationは、Kubernetes 1.29で非推奨になります。 flowcontrol.apiserver.k8s.io/v1 API (Kubernetes 1.29以降のバージョンで利用可能) またはflowcontrol.apiserver.k8s.io/v1beta3 API (Kubernetes 1.26以降のバージョンで利用可能) の使用を推奨します。
flowcontrol.apiserver.k8s.io/v1の主な変更点:
PriorityLevelConfigurationの
spec.limited.assuredConcurrencyShares
フィールドの名前がspec.limited.nominalConcurrencyShares
に変更されました。 デフォルト値は30で、明示的な値0を30に変更することはできません。flowcontrol.apiserver.k8s.io/v1beta3の主な変更点:
PriorityLevelConfigurationの
spec.limited.assuredConcurrencyShares
フィールドの名前がspec.limited.nominalConcurrencyShares
に変更されました。
機能ゲート
Kubernetesでサポートされている機能ゲート、機能ゲートのバージョン、および機能の詳細については、「機能ゲート」をご参照ください。
フィーチャーゲートのステージは次のとおりです。
アルファ: デフォルトでは、この機能は無効になっています。
ベータ: デフォルトでは、この機能は有効になっています。
GA: デフォルトでは、この機能は有効になっており、無効にすることはできません。対応する機能ゲートウェイは不要です。
関連ドキュメント
Kubernetes 1.29および1.30のリリースノートの詳細については、「CHANGELOG-1 29」および「CHANGELOG-1 30」をご参照ください。