K8sは最新かつ最高のスレートの期限を待っています。拡張機能のバージョン管理はベータ版に到達します。

ソフトウェア コンテナ オーケストレーション システムである Kubernetes は、水曜日にバージョン 1.11 がリリースされ、いくつかの有用な機能強化がもたらされる予定です。

このソフトウェアは現在、カスタムリソース定義（CRD）のアルファ版をサポートしています。CRDは、コンテナクラスターにカスタムリソース（拡張機能）を定義できるAPIです。1.11以降（Red HatのCoreOSチームがこちらで詳しく説明しています）、CRDのバージョン管理はより安定したベータ版に移行します。

バージョン管理は、クライアント ソフトウェアのバージョン変更に対応するためにカスタム拡張機能を手動で調整する代わりに、アプリケーションの進化に合わせてアプリケーションの管理を自動化するメカニズムを提供します。

Red Hat のシニアプリンシパルソフトウェアエンジニア兼 OpenShift アーキテクトの Derek Carr 氏は、 The Registerとの電話インタビューで、Kubernetes を強化して、時間の経過とともに変化する拡張機能をユーザーが管理できるようにするのが目標だと語った。

「Kubernetes APIが進化するのと同じように、プラットフォームの拡張機能も進化する必要があります」と彼は述べた。「そして、そのための重要なメカニズムがバージョン管理です。」

CRD 仕様では、「scale」と「status」という 2 つのサブリソースのサポートが実装されました。

前者は、コントローラーなどのシステムがクラスターと通信するのに役立ちHorizontalPodAutoscalerますPodDisruptionBudget。

後者は、spec と status という 2 つの Kubernetes オブジェクト フィールドを分離することにより、オペレーター (パッケージ化された Kubernetes アプリケーション) の作成者に、より具体的なリソース アクセス制御を提供します。

スペックは、ユーザーが定義するオブジェクトの望ましい状態です。ステータスは、システムによって報告されるオブジェクトの実際の状態です。権限の観点からこれら2つを区別することで、システムの信頼性が向上します。

ポッド優先度とプリエンプション機能もベータ版に移行します。名前の通り、ポッド優先度を使用すると、Kubernetesユーザーはポッド（同一ホスト上のコンテナのグループ）のスケジューリング優先度を他のポッドよりも高く設定できます。

カー氏は、クラスタ上で実行されるワークロードはすべて同じではないと説明した。「多くのユーザーにとって、クラスタのノードサイズは固定されているか、特定のコストプロファイルに制限されています」と彼は述べた。「ポッド優先度は、2つのポッド間の相対的な順位付けを可能にします。」

Kubernetes スケジューラは、ランキングを使用して特定のクラスターを優先したり、既存のクラスターを優先してより重要なクラスターのためのスペースを確保したりします。

最近のKubernetesの取り組みの焦点について尋ねられると、Carr氏は、オーケストレーションソフトウェアが誰にも邪魔されないようにするために多大な努力が払われていると述べた。

「Kubernetes を中心に構築したいと考えているすべての人が、やりたいことをできるようにしたいのです」と Carr 氏は語りました。