クベネフィット

クベネフィット

原作者	グーグル
開発者	クラウドネイティブコンピューティング財団
初回リリース	0.2 [1] / 2014年9月9日; 10年前 (2014-09-09)
安定版リリース	1.31.1 [2] / 2024年9月12日; 2か月前 (12 September 2024)
リポジトリ	github.com/kubernetes/kubernetes
書かれた	行く
タイプ	クラスタ管理ソフトウェア
ライセンス	Apache ライセンス 2.0
Webサイト	Kubernetes の新機能

Kubernetes（/ ˌ k ( j ) uː b ər ˈ n ɛ t ɪ s、 - ˈ n eɪ t ɪ s、 - ˈ n eɪ t iː z、 - ˈ n ɛ t iː z /、K8s）^[3]は、ソフトウェアの展開、スケーリング、管理を自動化するためのオープンソースの コンテナ オーケストレーションシステムです。 ^{[4] [5]もともと}Googleによって設計されたこのプロジェクトは、現在では世界中の貢献者コミュニティによって維持されており、商標はCloud Native Computing Foundationが保有しています。

Kubernetesという名前はギリシャ語のκυβερνήτης (kubernḗtēs)に由来し、統治者、操舵手、パイロットを意味します。Kubernetesは、 Kとsの間にある8つの文字（数字の頭文字）を数えて、 K8sと略されることがよくあります。^[6]

Kubernetesは、仮想マシンまたはベアメタルのいずれか1台以上のコンピュータをクラスターに組み立て、コンテナ内でワークロードを実行できるようにします。containerdやCRI-Oなどのさまざまなコンテナランタイムで動作します。^{[7]あらゆるサイズとスタイルのワークロードを実行および管理するのに適しているため、クラウドやデータセンターで広く採用されています。このプラットフォームには、}独立系ソフトウェアベンダー（ISV）からの複数のディストリビューションと、すべての主要なパブリッククラウドベンダーからのクラウドホスト型サービスがあります。 ^[8]

Kubernetesは世界で最も広く導入されているソフトウェアシステムの1つであり^{[9] 、} Google、Microsoft、Amazon、Apple、Meta、Nvidia、Reddit、Pinterestなどの企業で使用されています。

Kubernetes（古代ギリシャ語：κυβερνήτης、ローマ字表記：  kubernḗtēs、「舵取り、航海士」または「ガイド」 、サイバネティクスの語源）^[5]は、2014年6月6日にGoogleによって発表されました。 ^[10]このプロジェクトは、Googleの従業員であるJoe Beda、Brendan Burns、Craig McLuckieによって考案され、作成されました。Ville Aikas、Dawn Chen、Brian Grant、Tim Hockin、Daniel Smithなど、Googleの他のメンバーもすぐにプロジェクトの構築に加わりました。^{[11] [12]} Red HatやCoreOSなどの他の企業もすぐにこの取り組みに加わり、Clayton ColemanやKelsey Hightowerなどの著名な貢献者がいました。^[10]

Kubernetesの設計と開発は、GoogleのBorgクラスタマネージャに触発され、Promise Theoryに基づいています。^{[13] [14]} Kubernetesのトップコントリビューターの多くは、以前にBorgに取り組んでいました。^{[15] [16]}彼らは、スタートレックの元ボーグキャラクターであるセブンオブナインにちなんでKubernetesを「 Project 7」というコード名で名付け、 ^{[17] 7本スポークの船の舵をロゴにしました（Tim Hockinによるデザイン）。C} ++で書かれたBorgとは異なり、^{[15] Kubernetesは}Go言語で書かれています。

Kubernetesは2014年6月に発表され、バージョン1.0は2015年7月21日にリリースされました。^{[18] Googleは}Linux Foundationと協力してCloud Native Computing Foundation (CNCF) ^[19]を設立し、Kubernetesをシード技術として提供しました。

GoogleはすでにマネージドKubernetesサービスであるGKEを提供しており、Red Hatは2014年のKubernetesプロジェクト開始以来、OpenShiftの一部としてKubernetesをサポートしていました。^[20] 2017年には、主要な競合他社がKubernetesに集結し、ネイティブサポートを追加することを発表しました。

• VMware（Pivotal Cloud Foundryの提唱者）^[21]は8月に、
• メソスフィア社（マラソンとメソスの提唱者）^[22]は9月に、
• Docker社（ Dockerの提唱者）^[23]は10月に、
• Microsoft Azure ^[24]も10月に、
• AWSは11月にElastic Kubernetes Service (EKS) ^[25]を介してKubernetesをサポートすることを発表しました。

2018年3月6日、Kubernetesプロジェクトはコミット数ではGitHubプロジェクトのリストで9位、作成者と問題数ではLinuxカーネルに次いで2位に達しました。^[26]

バージョン1.18までは、KubernetesはN-2サポートポリシーに従っており、最新の3つのマイナーバージョンに対してセキュリティアップデートとバグ修正が提供されていました。^[27]バージョン1.19以降、KubernetesはN-3サポートポリシーに従います。^[28]

Kubernetesは、 CPU、メモリ^[29]、またはカスタムメトリック^[30]に基づいてアプリケーションを展開、維持、拡張するメカニズムを総合的に提供する一連のビルディングブロック（「プリミティブ」）を定義します。Kubernetesは疎結合で拡張可能であり、さまざまなワークロードのニーズに対応します。Kubernetesで実行される内部コンポーネント、拡張機能、コンテナはKubernetes APIに依存しています。^[31]プラットフォームは、リソースをオブジェクトとして定義することでコンピューティングリソースとストレージリソースを制御し、それらをオブジェクトとして管理できます。

Kubernetesはプライマリ/レプリカアーキテクチャを採用しています。Kubernetesのコンポーネントは、個々のノードを管理するものと、コントロールプレーンの一部であるものに分けられます。^{[31] [32]}

Kubernetesマスターノードは、クラスターのKubernetesコントロールプレーンを処理し、そのワークロードを管理し、システム全体の通信を誘導します。Kubernetesコントロールプレーンは、TLS暗号化、RBAC、強力な認証方法、ネットワーク分離などのさまざまなコンポーネントで構成されており、それぞれ独自のプロセスがあり、単一のマスターノードまたは高可用性クラスターをサポートする複数のマスターで実行できます。^[32] Kubernetesコントロールプレーンのさまざまなコンポーネントは次のとおりです。^[33]

Etcd ^[34]は、永続的で軽量な分散型のキーバリューデータストアです（もともとContainer Linux用に開発されました）。クラスタの構成データを確実に保存し、任意の時点でのクラスタ全体の状態を表します。etcdは、ネットワークパーティションが発生した場合に可用性よりも一貫性を重視します（ CAP定理を参照）。一貫性は、サービスを正しくスケジュールして運用するために不可欠です。

APIサーバーは、JSON over HTTPを使用してKubernetes APIを提供し、Kubernetesへの内部インターフェースと外部インターフェースの両方を提供します。^{[31] [35]} APIサーバーは、RESTリクエストを処理および検証し、etcd内のAPIオブジェクトの状態を更新します。これにより、クライアントはワーカーノード間でワークロードとコンテナを構成できます。^[36] APIサーバーは、etcdのwatch APIを使用してクラスターを監視し、重要な構成変更を展開したり、クラスターの状態の相違をetcdで宣言された目的の状態に戻したりします。

たとえば、人間のオペレーターが特定の「ポッド」（下記参照）のインスタンスを3つ実行する必要があると指定すると、etcdはこの事実を保存します。デプロイメントコントローラが2つのインスタンスしか実行されていないことを検出した場合（etcdの宣言と競合します）、^[37]そのポッドの追加インスタンスの作成をスケジュールします。^[32]

スケジューラは、リソースの可用性やその他の制約に基づいて、スケジュールされていないポッド（スケジュールされるワークロードの基本単位）が実行されるノードを選択する拡張可能なコンポーネントです。スケジューラは、各ノードのリソース割り当てを追跡して、ワークロードが利用可能なリソースを超えてスケ​​ジュールされないようにします。この目的のために、スケジューラは、リソース要件、リソースの可用性、およびサービス品質、アフィニティ/アンチアフィニティ要件、データの局所性などのユーザー提供の制約またはポリシーディレクティブを認識している必要があります。スケジューラの役割は、リソースの「供給」をワークロードの「需要」に一致させることです。^[38]

Kubernetesでは、単一のクラスター内で複数のスケジューラを実行できます。そのため、Kubernetesスケジューリングフレームワークに準拠している限り、スケジューラプラグインをネイティブのバニラスケジューラのインプロセス拡張として開発し、別のスケジューラとして実行することでインストールできます。^[39]これにより、クラスター管理者は、デフォルトのKubernetesスケジューラの動作を必要に応じて拡張または変更できます。

コントローラーは、 APIサーバーと通信して管理するリソース（ポッドやサービスエンドポイントなど）を作成、更新、削除し、実際のクラスターの状態を望ましい状態に導く調整ループです。^{[40] [35]}

コントローラーの例としては、ReplicaSet コントローラーがあります。これは、指定された数のポッドのコピーをクラスター全体で実行することで、レプリケーションとスケーリングを処理します。また、コントローラーは、基盤となるノードに障害が発生した場合に代替ポッドを作成する処理も行います。^[40]コア Kubernetes システムの一部である他のコントローラーには、すべてのマシン (またはマシンのサブセット) で正確に 1 つのポッドを実行する DaemonSet コントローラーや、完了するまで実行されるポッドを実行する Job コントローラー (バッチ ジョブの一部としてなど) などがあります。^[41]ラベル セレクターは、コントローラーが管理するポッドのセットを指定するコントローラー定義の一部を形成することがよくあります。^[42]

コントローラマネージャは、複数のコアKubernetesコントローラ（上記の例を含む）を管理する単一のプロセスであり、標準のKubernetesインストールの一部として分散され、ノードの損失に応答します。^[33]

クラスターにカスタム コントローラーをインストールすることもできます。これにより、カスタム リソースと組み合わせて使用​​することで、Kubernetes の動作と API をさらに拡張できるようになります (以下のカスタム リソース、コントローラー、オペレーターを参照)。

ノードはワーカーまたはミニオンとも呼ばれ、コンテナ (ワークロード) がデプロイされるマシンです。クラスター内のすべてのノードは、これらのコンテナのプライマリ ネットワーク構成と通信するために、コンテナランタイムと以下のコンポーネントを実行する必要があります。

kubeletは各ノードの実行状態を管理し、ノード上のすべてのコンテナが正常であることを確認します。コントロールプレーンの指示に従って、ポッドに編成されたアプリケーションコンテナの起動、停止、および保守を行います。^{[31] [43]} kubelet はポッドの状態を監視し、望ましい状態でない場合はポッドを同じノードに再デプロイします。ノードのステータスは、ハートビートメッセージを介して数秒ごとに API サーバーに中継されます。コントロールプレーンがノードの障害を検出すると、上位レベルのコントローラーがこの状態の変化を観察し、別の正常なノードでポッドを起動することが期待されます。^[44]

コンテナランタイムは、コンテナの起動、調整、終了など、コンテナのライフサイクルを担当します。kubeletはコンテナランタイムインターフェース（CRI）^{[45] [46]}を介してコンテナランタイムと対話します。これにより、コアKubernetesのメンテナンスが実際のCRI実装から 切り離されます。

もともと、kubeletは「dockershim」を介してDockerランタイム^{[47]とのみインターフェースしていました。しかし、2020年11月[48]}から2022年4月まで、Kubernetesはshimを非推奨にし、代わりにcontainerdを介してコンテナと直接インターフェースするか、Dockerをコンテナランタイムインターフェース（CRI）に準拠したランタイムに置き換えました。^{[49] [45] [50]} 2022年5月のv1.24のリリースにより、「dockershim」は完全に削除されました。^[51]

kubeletと互換性のある一般的なコンテナランタイムの例としては、containerd（当初はDocker経由でサポートされていました）、rkt ^[52]、CRI-Oなどがあります。

kube-proxyはネットワークプロキシとロードバランサーの実装であり、他のネットワーク操作とともにサービス抽象化をサポートしています。^[31]着信リクエストのIPとポート番号に基づいて、トラフィックを適切なコンテナにルーティングする役割を担っています。

Kubernetesでは、処理するリソースを、異なる重複しないコレクションに分離するために名前空間が利用されます。 ^[53]これらは、複数のチームやプロジェクトにまたがる多くのユーザーが存在する環境や、開発、テスト、本番などの環境を分離している環境での使用を目的としています。

Kubernetesの基本的なスケジューリング単位はポッド^[54]であり、同じノード上に共存することが保証されている1つ以上のコンテナで構成されています。^[31] Kubernetesの各ポッドにはクラスター内で一意のIPアドレスが割り当てられているため、アプリケーションは競合のリスクなしにポートを使用できます。^[55]ポッド内では、すべてのコンテナが相互に参照できます。

コンテナはポッド内に存在します。コンテナはマイクロサービスの最下位レベルであり、実行中のアプリケーション、ライブラリ、およびそれらの依存関係を保持します。

Kubernetes は、単純なポッドよりも高いレベルのワークロードの抽象化をいくつかサポートしています。これにより、ユーザーは個々のポッドを自分で管理する代わりに、これらの高レベルの抽象化を宣言的に定義および管理できます。Kubernetes の標準インストールでサポートされているこれらの抽象化のいくつかを以下で説明します。

レプリカセットの目的は、いつでも実行されているレプリカポッドの安定したセットを維持することです。そのため、指定された数の同一のポッドの可用性を保証するためによく使用されます。^[56]レプリカセットは、Kubernetesが特定のポッドに対して宣言されたインスタンスの数を維持できるようにするグループ化メカニズムであると言うこともできます。レプリカセットの定義にはセレクターが使用され、その評価により、それに関連付けられているすべてのポッドが識別されます。

ReplicationControllerはReplicaSetに似ており、同じ目的を果たし、ReplicaSetと同様に動作します。つまり、常に指定された数のポッドレプリカが存在するようにします。ReplicationControllerワークロードはReplicaSetの前身でしたが、最終的にはセットベースのラベルセレクターを使用するReplicaSetに取って代わられ、廃止されました。^[56]

デプロイメントはレプリカセットのより高レベルの管理メカニズムです。レプリカセット コントローラがレプリカセットのスケールを管理する一方で、デプロイメント コントローラはレプリカセットに何が起こるか (更新をロールアウトする必要があるか、ロールバックする必要があるかなど) を管理します。デプロイメントがスケールアップまたはスケールダウンされると、レプリカセットの宣言が変更され、宣言された状態の変更はレプリカセット コントローラによって管理されます。^[37]

StatefulSetsは、ポッドのインスタンス間の一意性と順序付けの特性を強制するコントローラーであり、ステートフルアプリケーションを実行するために使用できます。^[57]ステートレスアプリケーションのスケーリングは実行中のポッドを追加するだけですが、ステートフルワークロードの場合は、ポッドが再起動された場合に状態を保持する必要があるため、スケーリングはより困難です。アプリケーションがスケールアップまたはスケールダウンされた場合、状態を再配布する必要がある場合があります。

データベースはステートフル ワークロードの一例です。高可用性モードで実行される場合、多くのデータベースにはプライマリ インスタンスとセカンダリ インスタンスの概念が付属しています。この場合、インスタンスの順序付けの概念が重要です。Apache Kafkaなどの他のアプリケーションは、ブローカー間でデータを分散するため、ブローカーはそれぞれ異なります。この場合、インスタンスの一意性の概念が重要です。

DaemonSet は、クラスター内のすべてのノードにポッドが作成されるようにする役割を担っています。^[58]一般的に、ほとんどのワークロードは、アプリケーションの必要に応じて、可用性とパフォーマンスの要件に応じて、必要なレプリカ数に応じてスケーリングされます。ただし、他のシナリオでは、クラスター内のすべてのノードにポッドをデプロイし、ノードが追加されるたびにポッドの合計数を増やし、ノードが削除されるたびにガベージコレクションを実行する必要がある場合があります。これは、ログ収集、イングレス コントローラー、ストレージ サービスなど、ワークロードが実際のノードまたはホスト マシンに何らかの依存関係を持つユース ケースで特に役立ちます。

Kubernetesサービスは、多層アプリケーションの 1 つの層のように連携して動作するポッドのセットです。サービスを構成するポッドのセットは、ラベル セレクターによって定義されます。^[31] Kubernetes は、環境変数を使用するか、Kubernetes DNS を使用するかの 2 つのサービス検出モードを提供します。 ^[59]サービス検出は、安定した IP アドレスとDNS 名をサービスに割り当て、セレクターに一致するポッド間でその IP アドレスのネットワーク接続にラウンドロビン方式でトラフィックの負荷を分散します (障害によりポッドがマシン間で移動する場合も含む)。^[55]デフォルトでは、サービスはクラスター内で公開されます (たとえば、バックエンドポッドがサービスにグループ化され、フロントエンド ポッドからの要求がそれらの間で負荷分散される場合があります)。ただし、サービスはクラスターの外部に公開することもできます (たとえば、クライアントがフロントエンド ポッドに到達できるようにするため)。^[60]

Kubernetes コンテナのファイルシステムは、デフォルトで一時的なストレージを提供します。つまり、ポッドを再起動すると、そのようなコンテナ上のすべてのデータが消去されるため、この形式のストレージは、些細なアプリケーションを除いて非常に制限されます。Kubernetesボリューム^[61]は、ポッド自体の存続期間中存在する永続的なストレージを提供します。このストレージは、ポッド内のコンテナの共有ディスク領域として使用することもできます。ボリュームは、ポッド構成によって定義されたコンテナ内の特定のマウント ポイントにマウントされ、他のボリュームにマウントしたり、他のボリュームにリンクしたりすることはできません。同じボリュームを、異なるコンテナによってファイル システム ツリーの異なるポイントにマウントできます。

一般的なアプリケーションの課題は、構成情報をどこに保存して管理するかを決めることです。構成情報の一部には機密データが含まれている可能性があります。構成データは、個々のプロパティのように細かいものから、JSONやXMLドキュメントなどの構成ファイル全体のような粗い情報まで、何でもかまいません。Kubernetes は、このニーズに対応するために、 ConfigMapとSecretsと呼ばれる 2 つの密接に関連したメカニズムを提供します。どちらも、アプリケーションの再構築を必要とせずに構成を変更できます。

ConfigMap と Secret のデータは、Deployment を介してこれらのオブジェクトがバインドされているアプリケーションのすべてのインスタンスで利用できるようになります。Secret や ConfigMap は、そのノードのポッドで必要な場合にのみノードに送信され、ノードのメモリにのみ保存されます。Secret または ConfigMap に依存するポッドが削除されると、バインドされているすべての Secret と ConfigMap のメモリ内コピーも削除されます。

ConfigMapまたはSecretのデータは、次のいずれかの方法でポッドからアクセスできます。^[62]

1. 環境変数として、コンテナの起動時に kubelet によって ConfigMap から使用されます。
2. コンテナのファイルシステム内でアクセス可能なボリューム内にマウントされ、コンテナを再起動せずに自動再ロードをサポートします。

SecretとConfigMapの最大の違いは、Secretは安全で機密性の高いデータを格納するために特別に設計されているが、デフォルトでは保存時に暗号化されず、クラスター内でSecretを完全に安全に使用するために追加の設定が必要であることです。^{[63] Secretは、証明書、イメージレジストリを操作するための資格情報、パスワード、} SSHキーなどの機密データや機密性の高いデータを格納するためによく使用されます。

Kubernetes を使用すると、クライアント (ユーザーまたは内部コンポーネント) は、ポッドやノードなど、システム内の任意の API オブジェクトにラベルと呼ばれるキーを添付できます。同様に、ラベル セレクターは、一致するオブジェクトに解決されるラベルに対するクエリです。^[31]サービスが定義されると、サービス ルーター/ロード バランサーがトラフィックのルーティング先のポッド インスタンスを選択するために使用するラベル セレクターを定義できます。したがって、ポッドのラベルを変更するか、サービスのラベル セレクターを変更するだけで、どのポッドにトラフィックが送信され、どのポッドにトラフィックが送信されないかを制御できます。これは、ブルーグリーン デプロイメントやA/B テストなどのさまざまなデプロイメント パターンをサポートするために使用できます。サービスが実装リソースをどのように利用するかを動的に制御するこの機能により、インフラストラクチャ内で疎結合が実現します。

たとえば、アプリケーションのポッドにシステムのラベルtier（たとえばfrontend、backendなどの値）とシステムのラベル（たとえば、などrelease_trackの値）がある場合、すべてのノードとノードに対する操作では、次のようなラベルセレクタを使用できます。^[42]canaryproductionbackendcanary

tier=backend AND release_track=canary

ラベルと同様に、フィールド セレクターを使用して Kubernetes リソースを選択することもできます。ラベルとは異なり、選択はユーザー定義の分類ではなく、選択されているリソースに固有の属性値に基づいて行われます。metadata.nameこれらは、metadata.namespaceすべての Kubernetes オブジェクトに存在するフィールド セレクターです。使用できるその他のセレクターは、オブジェクト/リソース タイプによって異なります。

アドオンは、Kubernetes クラスター内で実行されるアプリケーションとして実装される追加機能です。ポッドは、デプロイメント、レプリケーション コントローラーなどによって管理できます。アドオンは多数あります。重要なものをいくつか示します。

ドメイン名

クラスター DNS は、環境内の他の DNS サーバーに加えて、Kubernetes サービスの DNS レコードを提供する DNS サーバーです。Kubernetes によって起動されたコンテナーは、DNS 検索にこの DNS サーバーを自動的に含めます。

ウェブUI

これは、Kubernetes クラスター用の汎用 Web ベース UI です。管理者は、クラスター内で実行されているアプリケーションやクラスター自体を管理およびトラブルシューティングできます。

リソース監視

コンテナ リソース モニタリングは、コンテナに関するメトリックを中央データベースに記録し、そのデータを参照するための UI を提供します。

コスト監視

Kubernetes コスト監視アプリケーションを使用すると、ポッド、ノード、名前空間、ラベルごとにコストを内訳できます。

クラスターレベルのログ記録

ノードまたはポッドの障害時にイベント データが失われないように、コンテナ ログを検索/参照インターフェイスを備えた中央ログ ストアに保存できます。Kubernetes はログ データ用のネイティブ ストレージを提供しませんが、多くの既存のログ ソリューションを Kubernetes クラスターに統合できます。

コンテナは、ソフトウェアを移植可能にする方法として登場しました。コンテナには、サービスを実行するために必要なすべてのパッケージが含まれています。提供されるファイル システムにより、コンテナは移植性が非常に高く、開発時に簡単に使用できます。コンテナは、構成変更をまったく行わず、または比較的わずかな変更で、開発からテストまたは本番環境に移行できます。

歴史的に、Kubernetes はステートレス サービスにのみ適していました。しかし、多くのアプリケーションにはデータベースがあり、永続性が求められるため、Kubernetes 用の永続ストレージが作成されます。コンテナ用の永続ストレージの実装は、Kubernetes 管理者、DevOps、クラウド エンジニアにとって最大の課題の 1 つです。コンテナは一時的なものですが、そのデータはますます一時的なものではなくなってきています。そのため、コンテナの終了やハードウェア障害が発生した場合でも、データの存続を保証する必要があります。Kubernetes またはコンテナ化されたアプリケーションを使用してコンテナを展開する場合、組織は永続ストレージが必要であることに気付くことがよくあります。コンテナが使用するデータベース、ルート イメージ、その他のデータ用に、高速で信頼性の高いストレージを提供する必要があります。

こうした状況に加えて、Cloud Native Computing Foundation (CNCF) は、コンテナ接続ストレージパターンの定義に役立つブログなど、Kubernetes Persistent Storage に関するその他の情報を公開しています。このパターンは、Kubernetes 自体をストレージシステムまたはサービスのコンポーネントとして使用するものと考えることができます。^[64]

これらのアプローチや他のアプローチの相対的な人気に関する詳細は、CNCFのランドスケープ調査でも確認できます。この調査では、Datacore Softwareのステートフル永続ストレージプラットフォームであるOpenEBS ^[65]とストレージオーケストレーションプロジェクトであるRook​​が、2019年秋の時点で評価される可能性が最も高い2つのプロジェクトであることが示されています。^[66]

コンテナ接続ストレージは、Kubernetesが注目を集めるにつれて登場したデータストレージの一種です。コンテナ接続ストレージのアプローチまたはパターンは、Kubernetes上で実行されるワークロードに主にブロック、ファイル、オブジェクト、およびインターフェースを提供しながら、特定の機能についてはKubernetes自体に依存しています。^[67]

コンテナ接続ストレージの一般的な属性には、カスタムリソース定義などのKubernetesの拡張機能の使用や、ストレージやデータ管理用に別途開発および展開される機能にKubernetes自体を使用することが含まれます。カスタムリソース定義またはKubernetes自体によって提供される機能の例には、Kubernetes自体によって提供される再試行ロジックや、通常はカスタムリソース定義を介して提供される利用可能なストレージメディアとボリュームのインベントリの作成と維持などがあります。^{[68] [69]}

Kubernetesバージョン1.9では、コンテナストレージインターフェース（CSI）の最初のアルファリリースが導入されました。^[70]以前は、ストレージボリュームプラグインはKubernetesディストリビューションに含まれていました。標準化されたCSIを作成することで、外部ストレージシステムとのインターフェースに必要なコードがコアKubernetesコードベースから分離されました。わずか1年後、CSI機能はKubernetesで一般提供（GA）されました。^[71]

Kubernetesコントロールプレーンの主要コンポーネントはAPIサーバーであり、クラスターの他の部分やエンドユーザー、外部コンポーネントから呼び出すことができるHTTP APIを公開しています。このAPIはREST APIであり、宣言型であり、コントロールプレーンに公開されているAPIと同じです。^[72] APIサーバーはetcdによってサポートされており、すべてのレコードを永続的に保存します。^[73]

Kubernetesでは、すべてのオブジェクトはクラスターの状態の「意図の記録」として機能し、オブジェクトの作成者がクラスターに望む望ましい状態を定義することができます。^[74]そのため、ほとんどのKubernetesオブジェクトには、次のように同じネストされたフィールドのセットがあります。

• spec: エンドユーザーまたは他の上位レベルのコントローラーによって制御できるリソースの望ましい状態を記述します。
• status: リソースのコントローラーによってアクティブに更新されるリソースの現在の状態を説明します。

Kubernetes 内のすべてのオブジェクトは同じ API 規則に従います。これには次のようなものがあります。

• ネストされたオブジェクトフィールドには次のメタデータが必要ですmetadata: ^[75]
  • namespace: オブジェクトが細分化されるラベル。
  • name: 定義された名前空間内でオブジェクトを一意に識別する文字列。
  • uid: 空間と時間を超えて同じ名前のオブジェクトを区別できる一意の文字列 (同じ名前の削除や再作成でも)。
• フィールドで定義された別のコントローラによって管理される可能性があるmetadata.ownerReferences: ^[76]
  • フィールドによって定義される制御対象オブジェクトの管理コントローラとなるオブジェクトは、最大で 1 つだけですcontroller。
• 所有者が削除された場合はガベージコレクションされる可能性があります: ^[77]
  • オブジェクトが削除されると、すべての依存オブジェクトも連鎖的に削除される可能性があります。

Kubernetes APIは、カスタムリソースを使用して拡張できます。カスタムリソースは、標準のKubernetesインストールの一部ではないオブジェクトを表します。これらのカスタムリソースは、カスタムリソース定義（CRD）を使用して宣言されます。CRDは、現在実行中のクラスターをシャットダウンまたは再起動せずに動的に登録および登録解除できる一種のリソースです。^[78]

カスタム コントローラーは、Kubernetes API と対話する別の拡張メカニズムであり、標準のプリインストールされた Kubernetes コントローラー マネージャーのデフォルト コントローラーに似ています。これらのコントローラーは、カスタム リソースと対話して宣言型 API を可能にします。ユーザーはカスタム リソースを介してシステムの望ましい状態を宣言でき、変更を監視して調整するのはカスタム コントローラーの役割です。

カスタム リソースとカスタム コントローラーの組み合わせは、 Kubernetes Operatorと呼ばれることがよくあります。Operator の主な使用例は、サービスまたはサービス セットを管理している人間のオペレーターの目的を捉え、自動化を使用して実装し、この自動化をサポートする宣言型 API を使用することです。特定のアプリケーションとサービスを管理する人間のオペレーターは、システムがどのように動作するか、どのように展開するか、問題が発生した場合にどのように対応するかについて深い知識を持っています。

オペレータによって解決される問題の例としては、アプリケーションの状態のバックアップの取得と復元、データベーススキーマや追加の構成設定などの関連する変更と並行したアプリケーションコードのアップグレードの処理などがあります。Cloud Native Computing Foundationのインキュベーションプログラムでは、Argo、Open Policy Agent、Istioなど、Kubernetesを拡張するためにオペレータパターンを採用している注目すべきプロジェクトがいくつかあります。^[79]

KubernetesはAPIへのアクセスを制御するために以下の戦略を定義しています。^[80]

Kubernetes APIサーバーは、CA証明書を使用してトランスポート層セキュリティ（TLS）を適用するために、HTTPSトラフィックを処理するTCPポートをリッスンします。^[33]

Kubernetesの古いバージョンでは、APIサーバーはHTTPポートとHTTPSポートの両方でのリッスンをサポートしていました（HTTPポート番号にはまったくトランスポートセキュリティがありませんでした）。これはバージョン1.10で非推奨となり、Kubernetesのバージョン1.20では最終的にサポートされなくなりました。^[81]

Kubernetes APIサーバーへのすべてのリクエストは認証されることが想定されており、いくつかの認証戦略をサポートしています。そのうちのいくつかを以下に示します。^[82]

1. X.509クライアント証明書
2. 無記名トークン
3. プログラムによる API アクセスを目的としたサービス アカウント トークン

ユーザーは通常、 kubeconfigファイルで必要な資格情報とともにクラスターURLの詳細を示して定義することが求められますが、これはkubectlや公式Kubernetesクライアントライブラリなどの他のKubernetesツールによってネイティブにサポートされています。^[83]

Kubernetes APIは以下の認証モードをサポートしています: ^[84]

1. ノード認証モード: kubelet が適切に機能するために、実行を許可される API リクエストの操作の固定リストを付与します。
2. 属性ベースのアクセス制御 (ABAC)モード: 属性を組み合わせた定義済みのアクセス制御ポリシーを使用して、ユーザーにアクセス権を付与します。
3. ロールベースのアクセス制御 (RBAC)モード: ユーザーに付与されたロールに基づいてユーザーにアクセス権を付与します。各ロールは許可されるアクションのリストを定義します。
4. Webhookモード: REST APIサービスにクエリを実行し、ユーザーが特定のアクションを実行する権限を持っているかどうかを判断します。^[33]

Kubernetes はいくつかの公式 API クライアントをサポートしています。

• kubectl: Kubernetesコントロールプレーンと対話するためのコマンドライン^[85]
• Kubernetesが管理するC、.NET、Go、Haskell、Java、JavaScript、Perl、Python、Ruby用の公式クライアントライブラリ^[86]

同じAPI設計原則が、Kubernetesクラスターを作成、構成、管理するためのプログラムを利用するAPIの定義にも使用されています。これはクラスターAPIと呼ばれます。^[87] APIに具体化された重要な概念は、インフラストラクチャをソフトウェアとして使用することです。つまり、Kubernetesクラスターインフラストラクチャ自体が、他のKubernetesリソースと同様に管理できるリソース/オブジェクトであるという概念です。同様に、クラスターを構成するマシンもKubernetesリソースとして扱われます。APIには、コアAPIとプロバイダー実装の2つの部分があります。プロバイダー実装は、クラウドプロバイダー固有の機能で構成されており、Kubernetesは、クラウドプロバイダーのサービスやリソースと適切に統合された方法でクラスターAPIを提供できます。^[33]

Kubernetes は、マイクロサービスベースの実装をホストする方法としてよく使用されます。Kubernetes とそれに関連するツールのエコシステムは、あらゆるマイクロサービス アーキテクチャの主要な問題に対処するために必要なすべての機能を提供するためです。

さまざまなベンダーがKubernetesベースのプラットフォームやKubernetesを導入するIaaS（ Infrastructure as a Service）を提供しています。^{[88] [89]}

これらは通常、オープンソース、商用、またはマネージドディストリビューションに分類されます。いくつかの注目すべきディストリビューションを以下に示します。^[90]

• アマゾンEKS-D
• k0s
• k3s
• SUSE Rancher Kubernetes Engine (RKE)
• OKD.IO Red Hat OpenShift を支える Kubernetes のコミュニティ ディストリビューション

• D2iQ Kubernetes プラットフォーム
• Mirantis Kubernetes Engine (旧Docker Enterprise)
• レッドハット オープンシフト
• VMwareタンズ

• Alibaba Cloud ACK (Kubernetes 向け Alibaba Cloud コンテナ サービス)
• Amazon EKS (Elastic Kubernetes サービス)
• Canonical MicroK8s と Charmed Kubernetes
• DigitalOceanマネージド Kubernetes サービス
• Google GKE (Google Kubernetes エンジン)
• Huawei CCE (Huawei クラウド コンテナ エンジン)
• IBMクラウド Kubernetes サービス
• Microsoft AKS (Azure Kubernetes サービス)
• OpsCare Plus マネージド サービスを備えたMirantis Kubernetes Engine
• Kubernetes向けOracleコンテナエンジン
• Platform9 マネージド Kubernetes
• ウインドリバーシステムズウインドリバースタジオ

以下のチャートは、各リリースがサポートされている期間を示しています^[91]

• Docker (ソフトウェア)
• クラスタ管理ソフトウェアの一覧
• オープンサービスメッシュ
• オープンシフト

• 公式サイト
• GitHub上の Kubernetes