Kubernetes 1.20が利用可能になりました

2020 年の 3 番目で最後のリリースとなる Kubernetes 1.20 を発表できることを嬉しく思います。このリリースには 42 の機能強化が含まれています。安定版で 11 の機能強化、ベータ版で 15 の機能強化、アルファ版で 16 の機能強化です。

前回の拡張リリース サイクルに続き、バージョン 1.20 は通常の 11 週間の更新サイクルに戻りました。これは、しばらくの間で最も機能が充実したリリースの 1 つであり、Kubernetes のイノベーションのペースが依然として加速していることを示しています。さらに重要なのは、バージョン 1.20 に含まれる強化された機能の数が安定バージョンよりもさらに多いことです。これは、クラウド ネイティブ エコシステムには、探求する価値のある革新の余地がまだたくさんあることを証明しています。

[[356702]]

コアテーマ

ストレージボリュームのスナップショット操作が安定バージョンに移行

この機能は、ボリューム スナップショット操作をトリガーする標準的な方法を提供し、ユーザーが任意の Kubernetes 環境およびサポートされているストレージ プログラムにわたってポータブルな方法でスナップショット操作を組み込むことを可能にします。

さらに、これらの Kubernetes スナップショット プリミティブは、アプリケーションまたはクラスター レベルでのバックアップ ソリューションを含む、Kubernetes 向けの高度なエンタープライズ グレードのストレージ管理機能を開発するための基本的な構成要素として機能します。

スナップショットをサポートするには、Kubernetes ディストリビューションでスナップショット コントローラー、スナップショット CRD、検証 Webhook をバンドルし、クラスター上でスナップショット機能をサポートする CSI ドライバーをデプロイする必要があることに注意してください。

Kubectl デバッグ機能がベータ段階に突入

kubectl アルファ デバッグ機能はバージョン 1.20 でベータ ステージに入り、現在は kubectl debug に名前が変更されています。この機能により、ユーザーは kubectl を通じて一般的なデバッグ ワークフローを直接サポートできるようになります。ベータ版では、サポートされているトラブルシューティング ソリューションは次のとおりです。

• 異なるコンテナ イメージまたはコマンドを使用するレプリカ ポッドを作成して、起動時にクラッシュするワークロードをトラブルシューティングします。
• デバッグ ツールを使用して、Pod または一時コンテナ (一時コンテナはアルファ機能であり、デフォルトでは有効になっていません) の新しいレプリカを追加することにより、ディストリビューションのないコンテナのトラブルシューティングを行います。
• ホスト名前空間でコンテナを作成して実行し、ホスト ファイル システムにアクセスさせることで、ノードのトラブルシューティングを行います。新しい組み込みコマンドとして、kubectl debug は「debug」という名前の他の kubectl プラグインよりも優先されることに注意してください。影響を受けるプラグインの名前を変更する必要があります。

バージョン 1.20 では、kubectl alpha debug を引き続き使用することは推奨されておらず、今後のバージョンで削除する予定です。 kubectl debug を使用するようにスクリプトを更新してください。 kubectl debug の詳細については、「実行中の Pod のデバッグ」を参照してください。

ベータ機能: API の優先順位付けと公平性

バージョン 1.18 で初めて導入された機能である API 優先度と公平性 (APF) は、Kubernetes バージョン 1.20 ではデフォルトで有効になっています。つまり、kube-apiserver は受信リクエストを優先度別に分類できます。

アルファ機能の更新: IPV4/IPV6

デュアルスタック サービスに関するユーザーとコミュニティからのフィードバックをサポートするために、IPv4/IPv6 デュアル スタックが再実装されました。つまり、IPv4 と IPv6 の両方のサービス クラスターの IP アドレスを 1 つのサービスに割り当てることができ、サービス内で単一 IP スタックとデュアル IP スタックを切り替えることもできます。

一般バージョンの機能: プロセスPIDを制限して安定性を向上

プロセス ID (pid) は、Linux マシン上の基本的なリソースです。ホストの安定性に影響を与えないようにするには、タスク制限に達してもリソース制限に達しないようにバランスを取る必要があります。

管理者は、ユーザー Pod が pid 枯渇を引き起こしてホスト デーモン (ランタイム、kubelet など) を停止させないようにするためのメカニズムが必要です。また、さらに重要なこととして、コンテナ間の pid を制限して、ノード上の他のワークロードに過度の影響を与えないようにします。 1 年前にデフォルトで有効化された後、SIG Node は、安定性を向上させるためにプロセス PID を制限する機能を、SupportNodePidsLimit (ノードからポッドへの PID 分離) と SupportPodPidsLimit (ポッドによる PID の制限) によってようやく一般公開しました。

アルファ機能: 正常なノードシャットダウン

ユーザーとクラスター管理者はどちらも、ポッドの終了フェーズを含む、事前に決められたライフサイクルにポッドが従うことを期待しています。現在、ポッドはノードがシャットダウンされたときに予想される終了ライフサイクルに従わないため、正常に終了できず、一部のワークロードで問題が発生する可能性があります。 GracefulNodeShutdown 機能は現在アルファ版で利用可能であり、ノード システムのシャットダウン状態を kubelet に通知し、システムのシャットダウン中に各 Pod を正常にシャットダウンするために使用されます。

主な変更点

Dockershim の廃止

Docker のコンテナ ランタイム インターフェイス (CRI) として、新しいバージョン 1.20 で dockershim が廃止されることを発表しました。これは、Docker サポートが利用できなくなり、後続のリリースで完全に削除されることを意味します。ただし、心配する必要はありません。Docker によって生成されたイメージは Open Container Initiative (OCI) イメージ仕様に準拠しているため、CRI 互換のすべてのランタイムでクラスターによって正常に使用できます。 Kubernetes コミュニティは、廃止の決定に関する詳細なブログ記事を公開しており、専用の FAQ ページも含まれています。

実行プローブタイムアウト処理

長年存在していた exec プローブのタイムアウト バグがようやく修正されました (このバグは、すでに修正された新しいバージョンを使用している既存の Pod 定義に影響する可能性があります)。修正がリリースされる前は、exec プローブはフィールド timeoutSeconds を考慮していませんでした。代わりに、プローブは、結果が返されるまで、構成された制限を超えても無期限に実行されます。この変更後、値が指定されていない場合、プローブはデフォルトで 1 秒間のみ適用されます。プローブに 1 秒以上かかる場合、既存の Pod 定義が自立していない可能性があります。この修正により、クラスター オペレーターが以前の動作に戻すことができる ExecProbeTimeout と呼ばれる機能ゲートも追加されます。ただし、この機能は後続のリリースではロックされ、削除されます。以前の動作を復元するには、クラスター オペレーターはこの機能ゲートを false に設定する必要があります。