Kubernetes 1.23 について知っておくべきことすべて

[[442113]]

[51CTO.com クイック翻訳]近日リリース予定のKubernetesのクリスマスバージョンには、成熟度、セキュリティ、スケーラビリティの面で45の機能強化が含まれます。この記事では、Kubernetes API、コンテナとインフラストラクチャ、ストレージ、ネットワーク、セキュリティに関する重要な更新に焦点を当てます。

Kubernetes API

まず、拡張可能な Kubernetes API を見てみましょう。 3 つの主要な変更、api-machinery、CLI、および autoscaling SIG がバージョン 1.23 の一部としてリリースされます。

Kubectl イベント コマンド

これまでは、kubectl get コマンドのオプションとデータ収集方法によって制限されていた可能性があります。このため、1.23 アルファ バージョンでは、新しいコマンド kubectl event が起動されます。 kubectl の get events を使用すると、クラスターの全体的なステータスをより簡単に観察し、関連する問題を解決できます。具体的には、主な機能は次のとおりです。

• 特定のリソースに関連するすべてのイベントを表示する機能
• クラスター内の特定のイベントを監視する
• 特定の名前空間でイベントをステータスまたはタイプ別にフィルタリングする

上記の機能に加えて、設計ドキュメントを参照して、今後のバージョンでリリースされる新機能について確認することもできます。新しい kubectl バージョンをインストールした直後から kubectl events コマンドを使い始めることができることにも言及しておく価値があります。

HPA API を一般公開しました

Horizo​​ntal Pod Autoscaler (HPA) は、さまざまな指標に基づいて Pod の数を自動的に拡張できる Kubernetes のコア コンポーネントです。 HPA は、レプリカ セット、デプロイメント、CPU 使用率などのよく知られたインジケーター ステータス セットを含むリソースをスケールアップまたはスケールダウンできます。これは 2015 年から Kubernetes API の一部となっています。本日、ついに一般提供 (GA) に到達しました。

クライアントとコントローラーですでに HPA を使用している場合は、v2beta1 の代わりに v2 を直接使用できます。このリリースから、HPA が Kubernetes API のコア コンポーネントになり、最終製品に追加される準備ができていることがわかります。そのため、HPA を安心してご利用いただけます。

CRD 検証式言語

カスタム リソース定義 (CRD) は、Kubernetes を拡張し、カスタマイズ可能なすべてのリソースで動作できるようにする強力な抽象化レイヤーとして機能します。ただし、ユーザーが新しいカスタム リソースとそれに関連する仕様を定義する場合、Webhook、コントローラー、クライアント ツールを使用した検証が面倒になる可能性があります。幸いなことに、Common Expression Language などのインライン式言語を CRD に統合して検証することができます。

バージョン 1.23 では、検証ルールがアルファ機能として提供され、x-kubernetes-validation-rules を簡単に追加できるようになりました。 Kubernetes のドキュメントでも同様の例を見ることができます。

 ...
     オープンAPIV3スキーマ:
       タイプ: オブジェクト
       プロパティ:
         仕様:
           タイプ: オブジェクト
           x-kubernetes-検証ルール:
            -ルール: "self.minReplicas <= self.replicas"  
              メッセージ: 「レプリカは minReplicas 以上である必要があります。」  
            -ルール: "self.replicas <= self.maxReplicas"  
              メッセージ: 「レプリカは maxReplicas 以下である必要があります。」  
           プロパティ:
            ...
            最小レプリカ数:
              タイプ:整数 
            レプリカ:
              タイプ:整数 
            最大レプリカ数:
               タイプ:整数 
           必須：
            -最小レプリカ数
            - レプリカ
            -最大レプリカ数

2 番目のルールに違反する次のカスタム リソース インスタンスを作成するとします。

 APIバージョン: "stable.example.com/v1"  
種類: CronTab
メタデータ:
名前: 新しい cron オブジェクト
仕様:
   最小レプリカ数: 0
   レプリカ: 20
   最大レプリカ数: 10

Kubernetes API は次のエラー メッセージで応答します。

 CronTab 「my-new-cron-object」  無効です:
 * spec: 無効な値: map[string]interface {}{ "maxReplicas" :10, "minReplicas" :0, "replicas" :20}: レプリカはmaxReplicas以下にする必要があります。

ご覧のとおり、クラスターで CRD を使用する場合は、Open API アーキテクチャとコントローラーで対応する検証メカニズムを使用する必要があります。この新しいバージョンでは、それらを x-kubernetes-validation-rules に移行し、Kubernetes API に面倒な作業を任せることができます。

コンテナとインフラストラクチャ

新しいバージョンでは、Windows とノード SIG という 2 つの注目すべき機能が見つかりました。これらは、一時コンテナーと Windows 特権コンテナーに属します。

一時コンテナ

一時コンテナを使用して、他のポッドの状態を観察し、トラブルシューティングやデバッグを行うことができます。この新しい機能には CLI コマンドも付属しています。ユーザーは kubectl debug を使用して簡単にトラブルシューティングを行うことができます。実際、コマンドはポッドのコンテナ内で実行され、kubectl exec コマンドはコンテナ内でプロセスを実行します。

バージョン 1.23 では、PodSpec.EphemeralContainer のポッド仕様の一部としてエフェメラル コンテナを追加できるようになります。コンテナ仕様に似ていますが、さまざまなリソース要求やポートは含まれず、結局のところ、ポッドに一時的に追加されるだけです。たとえば、Debian コンテナを my-service ポッドに追加し、対話的に接続して、ユーザーがリアルタイムでデバッグできるようにすることができます。詳細については、次のコード スニペットを参照してください。

 $ kubectl デバッグ -it -m debian my-service --bash  
ルート@デバッグ:~# ps x
   PID TTY STAT TIMEコマンド
     1 ? Ss 0:00 /一時停止
    11 ? Ss 0:00 バッシュ
   127 ? R+ 0:00 ps x

実際、一時コンテナはバージョン 1.22 ではすでにアルファ状態になっています。今回、バージョン1.23でベータ版にアップグレードされます。まだ試していない場合は、さまざまなデバッグ コンテナのイメージを作成し、kubectl debug コマンドをツールボックスに含めることをお勧めします。

Windows 特権コンテナとホスト ネットワーク モード

強力なコンテナ インスタンスとして、特権コンテナはホスト リソースにアクセスして使用できます。これは、ホスト上で直接実行されるプロセスと非常によく似ています。 Linux コンテナは広く使用されていますが、ある程度のセキュリティ上の脅威をもたらしますが、ホストインスタンスの管理には有益です。

バージョン 1.23 のリリースにより、Windows インスタンスの特権コンテナおよびホスト ネットワーク モードがベータ版にアップグレードされます。クラスターに Windows ノードがある場合、または将来的に Windows ノードを追加する予定がある場合は、機能と GA 計画について設計ドキュメントを確認してください。

ストレージ

バージョン 1.23 では、ストレージ SIG の変更は主に、ボリュームのマウント時のボリューム所有権の変更に反映されます。

現在、ボリュームがバインドされる前に、ボリュームの権限はポッド仕様の fsGroup 値に再帰的に更新されます。当然のことながら、ボリュームが非常に大きい場合、所有権の変更により、ポッドの作成中に長い待機時間が発生する可能性があります。したがって、ユーザーが権限と所有権の変更を操作する方法を指定できるように、新しいフィールド pod.Spec.SecurityContext.FSGroupChangePolicy を追加する必要があることがよくあります。

バージョン 1.23 では、この機能は GA にアップグレードされました。関連する戦略を指定するには、次の 2 つのオプションを使用できます。

• 常に: fsGroup フィールドと一致するように、さまざまな権限と所有権を常に変更します。
• OnRootMismatch: 最上位ディレクトリが fsGroup フィールドと一致しない場合にのみ、対応する権限と所有権を変更します。

権限の変更に敏感なデータベースなどのアプリケーションを使用している場合は、新しいフィールドを確認し、ポッドの作成中に長時間待機する必要がないようにポッド仕様に含めてください。

ネットワーキング

IPv6 は、Kubernetes バージョン 1.9 でアルファ機能として追加されて以来、Kubernetes チームにとって待望の機能でした。最新リリースでは、デュアルスタック IPv4/IPv6 ネットワークがようやく一般提供されました。

この機能には、さまざまなポッドおよびサービスの複数の IPv4/IPv6 アドレスの認識が含まれます。また、ネイティブ IPv4 から IPv4 への通信、およびクラスターとの IPv6 から IPv6 への通信もサポートします。

Kubernetes はデュアルスタック ネットワークを提供しますが、基盤となるインフラストラクチャとクラウド プロバイダーの機能によって制限される場合があります。ノードにはルーティング可能な IPv4/IPv6 ネットワーク インターフェースが必要であり、ポッドにはデュアル スタック ネットワーク接続が必要であるため、ポッドとサービスに IP アドレスを割り当てるにはデュアル スタック対応プラグインも必要です。現在、kubenet などの CNI プラグインはすでにデュアルスタック ネットワークをサポートしており、Kubeadm と kind もこのエコシステムのサポートを徐々に追加しています。

安全

認証 SIG に関するバージョン 1.23 の機能強化は、主に Pod セキュリティ標準のベータ バージョンへのアップグレードに反映されています。

以前のバージョンでは、Pod セキュリティ標準は、PodSecurityPolicy に代わるアルファ機能でした。名前空間とラベルの助けを借りて、ポッドの権限を制限し、それに応じてポリシーを適用する方法を作成しました。これをデプロイメントに含めることで、ポッドとクラスターのセキュリティを強化できます。

まとめ

Kubernetes は 2021 年の最終リリースで、API とインフラストラクチャを強化し、スケーラビリティと信頼性を向上させます。さらに、ストレージ、ネットワーク、セキュリティの改善により、Kubernetes は将来を見据えた真の業界をリードするコンテナ オーケストレーション プラットフォームとなっています。

最後に、Kubernetes ブログとリリース ノートをチェックして、最新の機能強化について詳しく学んでください。

原題: Kubernetes バージョン 1.23 がリリースされました: 知っておくべきことすべて、著者: Amir Kaushansky

[51CTOによる翻訳。パートナーサイトに転載する場合は、元の翻訳者と出典を51CTO.comとして明記してください。