Loading article…
| Kubernetes (K8s) | |||
|---|---|---|---|
 | |||
| 原作者 | グーグル | ||
| 開発者 | クラウドネイティブコンピューティング財団 | ||
| リリース | 0.2 [ 1 ] / 2014年9月9日 ( 2014-09-09 ) | ||
| 安定放出 |
| ||
| 執筆 | 行く | ||
| タイプ | クラスタ管理ソフトウェア | ||
| ライセンス | Apache License 2.0 | ||
| Webサイト | kubernetes.io | ||
| リポジトリ |
| ||
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 ]元々はGoogleによって設計されたこのプロジェクトは、現在では世界中の貢献者コミュニティによって維持されており、商標はCloud Native Computing Foundationが保有しています。
Kubernetesという名前は、古代ギリシャ語のκυβερνήτης、kubernḗtēs (操舵手、パイロット)に由来し、これはサイバネティクスや (ラテン語を経由して)知事という言葉の語源でもあります。「Kubernetes」はしばしば数字の短縮形「K8s」で略され、これは「文字 K、8 文字、s」を意味します。[ 5 ]
Kubernetes は、仮想マシンまたはベアメタルのいずれかの 1 台以上のコンピュータをクラスタに組み立て、コンテナでワークロードを実行できるようにします。containerdやCRI-Oなどのさまざまなコンテナ ランタイムと連携します。[ 6 ]あらゆる規模とスタイルのワークロードの実行と管理に適しているため、クラウドやデータ センターで広く採用されています。このプラットフォームには、独立系ソフトウェア ベンダー(ISV) から提供されるものや、主要なパブリック クラウド ベンダーすべてから提供されるクラウド ホスト型サービスなど、複数のディストリビューションがあります。[ 7 ]
このソフトウェアは、制御プレーンと、実際のアプリケーションが実行されるノードで構成されています。REST ベースの API とやり取りするために使用できるツールなどが含まれていkubeadmます。[ 8 ]kubectl
Kubernetesは、2014年6月6日にGoogleによって発表されました。[ 9 ]このプロジェクトは、Google社員のJoe Beda、Brendan Burns、Craig McLuckieによって構想され、作成されました。その後すぐに、Ville Aikas、Dawn Chen、Brian Grant、Tim Hockin、Daniel Smithなど、Googleの他の社員もプロジェクトの構築に協力しました。[ 10 ] [ 11 ] Red HatやCoreOSなどの他の企業もすぐにこの取り組みに参加し、Clayton ColemanやKelsey Hightowerなどの著名な貢献者が参加しました。[ 9 ]
Kubernetes の設計と開発は、Google のBorgクラスタマネージャに触発され、約束理論に基づいています。[ 12 ] [ 13 ] Kubernetesの主要貢献者の多くは、以前に Borg の開発に携わっていました。[ 14 ] [ 15 ]彼らは、スタートレックの元Borg のキャラクター、セブン・オブ・ナインにちなんで Kubernetes を「プロジェクト 7」とコードネームし[ 16 ]、ロゴには 7 本のスポークを持つ船の舵輪 (Tim Hockin 氏によるデザイン) を採用しました。C ++で書かれた Borg とは異なり、[ 14 ] Kubernetes はGo言語で書かれています。
Kubernetesは2014年6月に発表され、バージョン1.0は2015年7月21日にリリースされました。[ 17 ] GoogleはLinux Foundationと協力してCloud Native Computing Foundation（CNCF）[ 18 ]を設立し、Kubernetesをシードテクノロジーとして提供しました。
GoogleはすでにマネージドKubernetesサービスであるGKEを提供しており、Red Hatは2014年のKubernetesプロジェクト開始以来、OpenShiftの一部としてKubernetesをサポートしていた。[ 19 ] 2017年には、主要な競合企業がKubernetesに結集し、ネイティブサポートを追加すると発表した。
2018年3月6日、Kubernetesプロジェクトはコミット数でGitHubプロジェクトのリストで9位、Linuxカーネルに次いで作者と課題数で2位にランクインした。[ 25 ]
バージョン 1.18 までは、Kubernetes は N-2 サポート ポリシーに従っており、これは最新の 3 つのマイナー バージョンに対してセキュリティ アップデートとバグ修正が行われることを意味します。[ 26 ]バージョン 1.19 以降、Kubernetes は N-3 サポート ポリシーに従います。[ 27 ]
Kubernetes は、 CPU、メモリ、またはカスタム メトリックに基づいてアプリケーションをデプロイ、保守、スケーリングするメカニズムをまとめて提供する一連の構成要素 (「プリミティブ」) を定義します。 [ 28 ] Kubernetes は疎結合で、さまざまなワークロードのニーズを満たすように拡張可能です。Kubernetes 上で実行される内部コンポーネント、拡張機能、およびコンテナは、Kubernetes API に依存しています。[ 29 ] [ 30 ]
このプラットフォームは、リソースをオブジェクトとして定義することで、コンピューティングリソースとストレージリソースを制御し、それらをオブジェクトとして管理できるようにします。
Kubernetes はプライマリ/レプリカ アーキテクチャに従います。Kubernetes のコンポーネントは、個々のノードを管理するものと、コントロール プレーンの一部であるものに分けられます。[ 29 ] [ 31 ]
Kubernetes コントロール プレーンはワークロードを管理し、システム全体の通信を制御します。TLS暗号化、ロール ベース アクセス制御(RBAC)、強力な認証方法、ネットワーク分離など、さまざまなコンポーネントで構成されており、それぞれが独自のプロセスで、単一ノードまたは高可用性クラスタをサポートする複数のノードで実行できます。[ 31 ] Kubernetes コントロール プレーンのさまざまなコンポーネントは次のとおりです。[ 32 ]
Etcd [ 33 ]は、永続的で軽量な分散型キーバリューデータストアです（元々は CoreOS の一部として開発されました）。クラスタの構成データを確実に保存し、任意の時点でのクラスタの全体的な状態を表します。Etcd は、ネットワーク分断が発生した場合に可用性よりも一貫性を優先します（CAP 定理を参照）。一貫性は、サービスを正しくスケジューリングおよび運用するために不可欠です。
API サーバーは、 JSON over HTTPSを使用してKubernetes APIを提供し、Kubernetes への内部インターフェースと外部インターフェースの両方を提供します。[ 29 ] [ 34 ] API サーバーは、 RESTリクエストを処理、検証し、etcd 内の API オブジェクトの状態を更新することで、クライアントがワーカー ノード全体でワークロードとコンテナを構成できるようにします。[ 35 ] API サーバーは、etcd の watch API を使用してクラスターを監視し、重要な構成変更を展開し、またはクラスターの状態の乖離を etcd で宣言された目的の状態に復元します。
例えば、人間のオペレーターが特定の「ポッド」（下記参照）のインスタンスが 3 つ実行されている必要があると指定すると、etcd はこの事実を保存します。Deployment コントローラーが、実行されているインスタンスが 2 つしかないことを検出した場合（etcd の宣言と矛盾）、[ 36 ]そのポッドの追加インスタンスの作成をスケジュールします。[ 31 ]
スケジューラは、リソースの可用性やその他の制約に基づいて、スケジュールされていないポッド（スケジュールされるワークロードの基本単位）が実行されるノードを選択する拡張可能なコンポーネントです。スケジューラは、ワークロードが利用可能なリソースを超えてスケジュールされないように、各ノードのリソース割り当てを追跡します。この目的のために、スケジューラは、リソース要件、リソースの可用性、およびサービス品質、アフィニティ/アンチアフィニティ要件、データ局所性などのユーザーが提供するその他の制約またはポリシー指示を知っている必要があります。スケジューラの役割は、リソースの「供給」をワークロードの「需要」に合わせることです。[ 37 ]
Kubernetes では、単一のクラスタ内で複数のスケジューラを実行できます。そのため、Kubernetes スケジューリング フレームワークに準拠している限り、ネイティブの標準スケジューラを別のスケジューラとして実行することで、スケジューラプラグインを開発してインストールできます。[ 38 ]これにより、クラスタ管理者は、ニーズに応じてデフォルトの Kubernetes スケジューラの動作を拡張または変更できます。
コントローラーは、実際のクラスタの状態を目的の状態に導く調整ループであり、API サーバーと通信して、管理するリソース (ポッドやサービス エンドポイントなど) を作成、更新、削除します。[ 39 ] [ 34 ]
コントローラの例としては、ReplicaSet コントローラがあります。これは、クラスタ全体で指定された数のポッドのコピーを実行することで、レプリケーションとスケーリングを処理します。また、基盤となるノードが故障した場合に、代替ポッドの作成も処理します。[ 39 ]コア Kubernetes システムの一部である他のコントローラには、各マシン (またはマシンのサブセット) で正確に 1 つのポッドを実行する DaemonSet コントローラや、完了するまで実行されるポッド (たとえば、バッチ ジョブの一部として) を実行する Job コントローラなどがあります。[ 40 ]ラベル セレクタは、コントローラが管理するポッドのセットを指定するコントローラの定義の一部を構成することがよくあります。[ 41 ]
コントローラーマネージャは、複数のコアKubernetesコントローラー（上記で説明した例を含む）を管理する単一のプロセスであり、標準のKubernetesインストールの一部として配布され、ノードの喪失に対応します。[ 32 ]
クラスターにはカスタムコントローラーをインストールすることもできます。これにより、カスタムリソースと組み合わせて使用することで、Kubernetesの動作とAPIをさらに拡張できます（下記のカスタムリソース、コントローラー、オペレーターを参照）。
ノード（ワーカーまたはミニオンとも呼ばれる）は、コンテナ（ワークロード）がデプロイされるマシンです。クラスタ内のすべてのノードは、コンテナランタイムと、これらのコンテナのプライマリネットワーク構成との通信に必要な以下のコンポーネントを実行する必要があります。
kubelet は各ノードの実行状態を担当し、ノード上のすべてのコンテナが正常であることを保証します。コントロール プレーンの指示に従って、ポッドに編成されたアプリケーション コンテナの起動、停止、および維持を管理します。[ 29 ] [ 42 ] kubelet はポッドの状態を監視し、望ましい状態でない場合は、ポッドを同じノードに再デプロイします。ノードの状態は、ハートビート メッセージを介して数秒ごとに API サーバーに中継されます。コントロール プレーンがノード障害を検出すると、上位レベルのコントローラーがこの状態の変化を監視し、別の正常なノードでポッドを起動することが期待されます。[ 43 ]
コンテナランタイムは、コンテナの起動、調整、および終了を含むコンテナのライフサイクルを担当します。kubelet は、コンテナランタイムインターフェイス (CRI) [ 44 ] [ 45 ]を介してコンテナランタイムとやり取りし、コア Kubernetes のメンテナンスを実際の CRI 実装から分離します。
当初、kubelet はコンテナ ランタイムとしてDockerと密接に結合していました[ 46 ]。その後、CRI と、一方では Docker と、他方では (CRI を介して) Kubelet とインターフェースする「dockershim」が開発されました。2020 年 11 月[ 47 ]から2022 年 4 月まで、Kubernetes はshimを非推奨にしました。[ 48 ] [ 44 ] [ 49 ] 2022 年 5 月に v1.24 がリリースされると、「dockershim」は完全に削除され、コンテナ ランタイムとしての Docker の公式サポートが終了しました。[ 50 ]
2026年現在、広く使用されているCRI準拠のコンテナランタイムには、containerdとCRI-Oが含まれます。
kube-proxy はネットワークプロキシとロードバランサーの実装であり、他のネットワーク操作とともにサービス抽象化をサポートします。[ 29 ]受信リクエストの IP とポート番号に基づいて、トラフィックを適切なコンテナにルーティングする役割を担います。
Kubernetesでは、名前空間を使用して、処理するリソースを個別の重複しないコレクションに分離します。[ 51 ]これらは、複数のチームやプロジェクトにまたがる多数のユーザーが存在する環境、あるいは開発、テスト、本番などの分離された環境で使用することを目的としています。
Kubernetes におけるコンピューティングの基本的なデプロイ単位はポッド[ 52 ]であり、これは同じノード上に配置された 1 つ以上のコンテナで構成されます。[ 29 ]各ポッドにはクラスタ内で一意の IP アドレスが割り当てられ、アプリケーションは競合のリスクなしにポートを使用できます。[ 53 ]ポッド内では、すべてのコンテナが共有コンテキストを持ち、互いに参照できます。
コンテナはポッド内に存在します。コンテナはマイクロサービスの最下層であり、実行中のアプリケーション、ライブラリ、およびそれらの依存関係を保持します。最も一般的な使用例では、各ポッドに1つのコンテナが含まれます。
Kubernetesは、単純なPodよりも高レベルのワークロードの抽象化をいくつかサポートしています。これにより、ユーザーは個々のPodを個別に管理する代わりに、これらの高レベルの抽象化を宣言的に定義および管理できます。Kubernetesの標準インストールでサポートされているこれらの抽象化のいくつかを以下に説明します。
ReplicaSet の目的は、常に安定したレプリカ Pod のセットを実行することです。そのため、指定された数の同一の Pod の可用性を保証するためによく使用されます。[ 54 ] ReplicaSet は、Kubernetes が特定の Pod に対して宣言されたインスタンスの数を維持できるようにするグループ化メカニズムとも言えます。ReplicaSet の定義にはセレクターが使用され、その評価によって関連付けられているすべての Pod が識別されます。
ReplicationController は ReplicaSet と同様に、指定された数のポッドレプリカが常に必要な数だけ存在するようにするという点で ReplicaSet と同様の目的と動作をします。ReplicationController ワークロードは ReplicaSet の前身でしたが、最終的にはセットベースのラベルセレクタを使用するために ReplicaSet に置き換えられ、非推奨となりました。[ 54 ]
デプロイメントは、ReplicaSet の上位レベルの管理メカニズムです。ReplicaSet コントローラは ReplicaSet のスケールを管理しますが、Deployment コントローラは ReplicaSet に対して何が起こるか（更新をロールアウトする必要があるか、ロールバックする必要があるかなど）を管理します。Deployment がスケールアップまたはスケールダウンされると、ReplicaSet の宣言が変更され、宣言された状態の変更は ReplicaSet コントローラによって管理されます。[ 36 ]
StatefulSet は、ポッドのインスタンス間の一意性と順序付けの特性を強制するコントローラーであり、ステートフルアプリケーションの実行に使用できます。[ 55 ]ステートレス アプリケーションのスケーリングは実行中のポッドを追加するだけで済みますが、ステートフル ワークロードの場合は、ポッドが再起動されたときに状態を保持する必要があるため、スケーリングがより困難になります。アプリケーションがスケールアップまたはスケールダウンされた場合、状態を再分配する必要がある場合があります。
データベースはステートフルなワークロードの一例です。高可用性モードで実行される場合、多くのデータベースはプライマリインスタンスとセカンダリインスタンスという概念を備えています。この場合、インスタンスの順序付けという概念が重要になります。Apache Kafkaのような他のアプリケーションは、データをブローカー間で分散するため、ブローカーはそれぞれ異なります。この場合、インスタンスの一意性という概念が重要になります。
DaemonSet は、クラスタ内のすべてのノードに Pod が作成されることを保証する役割を担います。[ 56 ]一般的に、ほとんどのワークロードは、アプリケーションが必要とする可用性とパフォーマンス要件に応じて、必要なレプリカ数に応じてスケーリングされます。ただし、他のシナリオでは、クラスタ内のすべてのノードに Pod をデプロイし、ノードが追加されるにつれて Pod の総数をスケールアップし、削除されるときにそれらをガベージ コレクションする必要がある場合があります。これは、ログ収集、イングレス コントローラ、ストレージ サービスなど、ワークロードが実際のノードまたはホスト マシンに何らかの依存を持つユース ケースで特に役立ちます。
Kubernetes サービスとは、マルチティアアプリケーションの 1 つの層のように、連携して動作する一連の Pod です。サービスを構成する Pod のセットは、ラベル セレクタによって定義されます。[ 29 ] Kubernetes は、環境変数を使用するか Kubernetes DNS を使用するかの2 つのサービス検出モードを提供します。 [ 57 ]サービス検出では、サービスに安定した IP アドレスとDNS 名が割り当てられ、セレクタに一致する Pod 間でその IP アドレスのネットワーク接続にラウンド ロビン方式でトラフィックの負荷分散が行われます (障害によって Pod がマシン間を移動する場合でも)。[ 53 ]デフォルトでは、サービスはクラスタ内で公開されます (たとえば、バックエンドPod がサービスにグループ化され、フロントエンド Pod からのリクエストがそれらの間で負荷分散される) が、サービスはクラスタ外にも公開できます (たとえば、クライアントがフロントエンド Pod にアクセスできるようにするため)。[ 58 ]
Kubernetes コンテナのファイルシステムは、デフォルトでは一時的なストレージを提供します。つまり、コンテナを再起動すると、そのファイルシステムは消去されます。したがって、この形式のストレージは、単純なアプリケーション以外では非常に制限があります。Kubernetes ボリューム[ 59 ]は、永続的なストレージを提供します。このストレージは、ポッド内のコンテナの共有ディスク領域としても使用できます。ボリュームは、ポッド構成で定義された特定のマウントポイントにコンテナ内にマウントされ、他のボリュームにマウントしたり、他のボリュームにリンクしたりすることはできません。同じボリュームを、異なるコンテナによってファイルシステムツリーの異なるポイントにマウントすることができます。
一般的なアプリケーション課題の一つは、機密データを含む可能性のある構成情報をどこに保存し管理するかを決定することです。構成データは、個々のプロパティのようなきめ細かい情報から、JSONやXMLドキュメントなどの構成ファイル全体のような大まかな情報まで、あらゆるものを含みます。Kubernetesは、このニーズに対応するために、ConfigMapsとSecretsという密接に関連する2つのメカニズムを提供しており、どちらもアプリケーションを再構築することなく構成変更を行うことができます。
ConfigMapとSecretのデータは、Deploymentを介してこれらのオブジェクトがバインドされているアプリケーションのすべてのインスタンスで利用可能になります。SecretまたはConfigMapは、そのノード上のPodが必要とする場合にのみノードに送信され、ノードのメモリにのみ保存されます。SecretまたはConfigMapに依存するPodが削除されると、バインドされているすべてのSecretとConfigMapのメモリ上のコピーも削除されます。
ConfigMap または Secret のデータは、次のいずれかの方法でポッドからアクセスできます。[ 60 ]
Secret と ConfigMap の最大の違いは、Secret は特に安全で機密性の高いデータを格納するように設計されている点です。ただし、デフォルトでは保存時に暗号化されておらず、クラスター内で Secret の使用を完全に安全にするには追加の設定が必要です。[ 61 ] Secret は、証明書、イメージ レジストリを操作するための認証情報、パスワード、およびSSHキーなどの機密データやセンシティブなデータを保存するために使用されることがよくあります。
Kubernetes では、クライアント (ユーザーまたは内部コンポーネント) が、ポッドやノードなどのシステム内の任意の API オブジェクトにラベルと呼ばれるキーを添付できます。これに対応して、ラベルセレクタは、一致するオブジェクトに解決されるラベルに対するクエリです。[ 29 ]サービスが定義されると、サービス ルーター/ロード バランサーがトラフィックをルーティングするポッド インスタンスを選択するために使用するラベルセレクタを定義できます。したがって、ポッドのラベルを変更したり、サービスのラベルセレクタを変更したりするだけで、トラフィックを受け取るポッドと受け取らないポッドを制御でき、ブルー/グリーン デプロイメントやA/B テストなどのさまざまなデプロイメント パターンをサポートするために使用できます。サービスが実装リソースをどのように利用するかを動的に制御するこの機能により、インフラストラクチャ内の疎結合が実現されます。
例えば、アプリケーションのポッドにシステム（例えば、、tierなどの値を持つ）と（例えば、、などの値を持つ）のラベルがある場合、およびのすべてのノードに対する操作では、次のようなラベルセレクタを使用できます。[ 41 ]frontendbackendrelease_trackcanaryproductionbackendcanary
tier=backend AND release_track=canary
ラベルと同様に、フィールドセレクターを使用してKubernetesリソースを選択できます。ラベルとは異なり、選択はユーザー定義の分類ではなく、選択対象のリソースに固有の属性値に基づいて行われます。metadata.nameと は、metadata.namespaceすべてのKubernetesオブジェクトに存在するフィールドセレクターです。使用できるその他のセレクターは、オブジェクト/リソースの種類によって異なります。
アドオンは、Kubernetesクラスタ内で実行されるアプリケーションとして実装される追加機能です。ポッドは、Deployment、ReplicationControllerなどによって管理されます。アドオンは多数存在します。特に重要なものをいくつか挙げます。
コンテナは、ソフトウェアの移植性を高める方法として登場しました。コンテナには、サービスを実行するために必要なすべてのパッケージが含まれています。付属のファイルシステムにより、コンテナは非常に移植性が高く、開発環境で簡単に使用できます。コンテナは、設定変更をほとんど、あるいは全く行わずに、開発環境からテスト環境、あるいは本番環境へと移行できます。
これまでKubernetesはステートレスなサービスにのみ適していました。しかし、多くのアプリケーションにはデータベースがあり、永続性が必要となるため、Kubernetes用の永続ストレージが開発されました。コンテナ用の永続ストレージの実装は、Kubernetes管理者、DevOpsエンジニア、クラウドエンジニアにとって最大の課題の一つです。コンテナ自体は一時的なものですが、そのデータの多くはそうではないため、コンテナの終了やハードウェア障害が発生した場合でもデータが確実に保持されるようにする必要があります。Kubernetesやコンテナ化されたアプリケーションでコンテナをデプロイする際、組織は永続ストレージが必要であることに気づくことがよくあります。データベース、ルートイメージ、およびコンテナで使用されるその他のデータに対して、高速で信頼性の高いストレージを提供する必要があります。
ランドスケープに加えて、Cloud Native Computing Foundation (CNCF) は、コンテナ接続ストレージパターンを定義するのに役立つブログなど、Kubernetes Persistent Storage に関するその他の情報を公開しています。このパターンは、ストレージシステムまたはサービスのコンポーネントとして Kubernetes 自体を使用するものと考えることができます。[ 62 ]
これらのアプローチやその他のアプローチの相対的な人気に関する詳細情報は、CNCF のランドスケープ調査でも確認できます。この調査では、Datacore Software のステートフル永続ストレージプラットフォームであるOpenEBS [ 63 ]とストレージオーケストレーションプロジェクトであるRook が、 2019 年秋の時点で評価中である可能性が最も高い 2 つのプロジェクトであることが示されています。[ 64 ]
コンテナアタッチドストレージは、Kubernetesが普及するにつれて登場したデータストレージの一種です。コンテナアタッチドストレージのアプローチまたはパターンは、Kubernetes自体に特定の機能を提供しつつ、主にブロック、ファイル、オブジェクト、およびインターフェースをKubernetes上で実行されるワークロードに提供します。[ 65 ]
コンテナアタッチドストレージの一般的な属性には、カスタムリソース定義などのKubernetes拡張機能の使用、およびストレージやデータ管理のために別途開発およびデプロイされる機能にKubernetes自体を使用することが含まれます。カスタムリソース定義またはKubernetes自体によって提供される機能の例には、Kubernetes自体によって提供される再試行ロジック、および通常カスタムリソース定義を介して提供される利用可能なストレージメディアとボリュームのインベントリの作成と維持などがあります。[ 66 ] [ 67 ]
Kubernetes バージョン 1.9 では、コンテナストレージインターフェイス (CSI) の最初のアルファ版がリリースされました。[ 68 ]以前は、ストレージボリュームプラグインが Kubernetes ディストリビューションに含まれていました。標準化された CSI を作成することで、外部ストレージシステムとのインターフェースに必要なコードが Kubernetes のコアコードベースから分離されました。わずか 1 年後、CSI 機能は Kubernetes で一般提供 (GA) されました。[ 69 ]
Kubernetes コントロール プレーンの重要なコンポーネントは API サーバーであり、これはクラスターの他の部分やエンド ユーザー、外部コンポーネントから呼び出すことができる HTTP API を公開します。この API はREST API であり、宣言的な性質を持ち、コントロール プレーンに公開されている API と同じです。[ 70 ] API サーバーは、すべてのレコードを永続的に保存するために etcd によってサポートされています。[ 71 ]
Kubernetesでは、すべてのオブジェクトがクラスタの状態の「意図の記録」として機能し、オブジェクトの書き込み者がクラスタに望む望ましい状態を定義できます。[ 72 ]そのため、ほとんどのKubernetesオブジェクトは、次のとおり同じネストされたフィールドのセットを持っています。
spec: エンドユーザーまたは他の上位レベルのコントローラーによって制御できる、リソースの望ましい状態を記述します。statusリソースの現在の状態を記述します。この状態は、リソースのコントローラーによって常に更新されます。Kubernetes内のすべてのオブジェクトは、同じAPI規約に従います。その一部を以下に示します。
metadata: [ 73 ]namespaceオブジェクトを細分化するラベル。name: 定義された名前空間内でオブジェクトを一意に識別する文字列。uid: クラスター内の任意の API オブジェクトを一意に識別する文字列。型、名前、名前空間、時間に関係なく、つまり、同じ型、名前、名前空間を持つ削除や再作成の場合でも一意に識別されます。metadata.ownerReferencesフィールドで定義されます: [ 74 ]controllerフィールドによって定義されます。Kubernetes API は、標準の Kubernetes インストールに含まれていないオブジェクトを表すカスタム リソースを使用して拡張できます。これらのカスタム リソースは、カスタム リソース定義(CRD) を使用して宣言されます。CRD は、現在実行中のクラスタをシャットダウンまたは再起動することなく、動的に登録および登録解除できるリソースの一種です。[ 76 ]
カスタムコントローラーは、Kubernetes APIと連携するもう1つの拡張メカニズムであり、標準でプリインストールされているKubernetesコントローラーマネージャーのデフォルトコントローラーと同様です。これらのコントローラーはカスタムリソースと連携して宣言型APIを実現します。ユーザーはカスタムリソースを介してシステムの望ましい状態を宣言でき、変更を監視して調整するのはカスタムコントローラーの役割です。
カスタム リソースとカスタム コントローラーの組み合わせは、Kubernetesオペレーターと呼ばれることが多い。[ 77 ]オペレーターの主なユース ケースは、サービスまたは一連のサービスを管理する人間のオペレーターの目的を捉え、それを自動化を使用して実装し、この自動化をサポートする宣言型 API を使用することである。特定のアプリケーションやサービスを管理する人間のオペレーターは、システムがどのように動作すべきか、どのようにデプロイするか、問題が発生した場合にどのように対応するかについて深い知識を持っている。
オペレーターが解決する問題の例としては、アプリケーションの状態のバックアップを取得して復元すること、アプリケーション コードのアップグレードと、データベース スキーマや追加の構成設定などの関連する変更の処理などが挙げられます。Cloud Native Computing Foundation のインキュベーション プログラムの下で注目すべきプロジェクトのいくつかは、Argo、Open Policy Agent、Istio など、Kubernetes を拡張するためにオペレーター パターンを採用しています。[ 78 ]
Kubernetesは、APIへのアクセスを制御するために以下の戦略を定義しています。[ 79 ]
Kubernetes API サーバーは、CA 証明書を使用してトランスポート層セキュリティ (TLS) を強制するために、HTTPSトラフィックを処理するTCP ポートでリッスンします。[ 32 ]
Kubernetesの旧バージョンでは、APIサーバーはHTTPポートとHTTPSポートの両方でのリッスンをサポートしていました（HTTPポート番号にはトランスポートセキュリティが全くありませんでした）。これはv1.10で非推奨となり、最終的にKubernetesのv1.20でサポートが終了しました。[ 80 ]
Kubernetes API サーバーへのすべてのリクエストは認証されることが想定されており、いくつかの認証戦略をサポートしています。その一部を以下に示します。[ 81 ]
ユーザーは通常、 kubeconfigファイルでクラスタ URL の詳細と必要な認証情報を指定および定義することが求められます。kubeconfig ファイルでは、kubectl や公式の Kubernetes クライアント ライブラリなどの他の Kubernetes ツールがネイティブにサポートしています。[ 82 ]
Kubernetes API は、次の認証モードをサポートしています: [ 83 ]
Kubernetesは、いくつかの公式APIクライアントをサポートしています。
同じ API 設計原則が、Kubernetes クラスターの作成、構成、管理を行うプログラムを利用する API の定義に使用されています。これは Cluster API と呼ばれています。[ 86 ]この API に具現化されている重要な概念は、Infrastructure as Softwareの使用、つまり Kubernetes クラスターのインフラストラクチャ自体が、他の Kubernetes リソースと同様に管理できるリソース / オブジェクトであるという考え方です。同様に、クラスターを構成するマシンも Kubernetes リソースとして扱われます。この API は、コア API とプロバイダー実装の 2 つの部分から構成されています。プロバイダー実装は、クラウドプロバイダー固有の機能で構成されており、Kubernetes がクラウドプロバイダーのサービスやリソースと十分に統合された方法でクラスター API を提供できるようにします。[ 32 ]
Kubernetesは、マイクロサービスベースの実装をホストする方法としてよく使用されます。なぜなら、Kubernetesとその関連ツールのエコシステムは、あらゆるマイクロサービスアーキテクチャの主要な懸念事項に対処するために必要なすべての機能を提供するからです。
Kubernetesに対するよくある批判は、複雑すぎるという点である。Googleもこれを認めている。[ 87 ]
さまざまなベンダーが、Kubernetes をデプロイする Kubernetes ベースのプラットフォームまたはインフラストラクチャ as a Service (IaaS) を提供しています。[ 88 ] [ 89 ]
これらは通常、オープンソース、商用、またはマネージドディストリビューションに分類されます。注目すべきディストリビューションのいくつかを以下に示します。[ 90 ]
以下のグラフは、各リリースがサポートされている期間を視覚化したものです[ 92 ]
{{cite web}}: CS1メンテナンス: アーカイブサービスは非推奨になりました (リンク)上の150万のプロジェクトと比較すると、Kubernetesはコミット数で9位、作成者/課題数で2位であり、Linuxに次ぐ2位である。
最も重要なプライマリ サービスの 1 つは API サーバーです。これは、ユーザーが Kubernetes のワークロードと組織単位を構成できるようにするため、クラスタ全体の主要な管理ポイントとなります。また、etcd ストアとデプロイされたコンテナのサービスの詳細が一致していることを確認する役割も担っています。さまざまなコンポーネント間の橋渡し役として機能し、クラスタの健全性を維持し、情報とコマンドを配信します。