Kubernetes
Kubernetes（K8s）
原作者グーグル
開発者クラウドネイティブコンピューティング財団
初回リリース0.2 [ 1 ] / 2014年9月9日 （2014年9月9日）
安定版リリース
1.341.35.0 [ 2 ] / 2025年12月17日 （2025年12月17日）
リポジトリ
書かれた行く
タイプクラスタ管理ソフトウェア
ライセンスApacheライセンス2.0
WebサイトKubernetes .ioWikidataで編集する

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（操舵手、パイロット）に由来し、これはサイバネティクス（cybernetics ）や（ラテン語を通して）ガバナー（governor）の語源でもあります。「Kubernetes」はしばしば数字を縮めた「K8s」で略され、「文字Kの後に8つの文字が続き、最後にsが続く」という意味になります。[ 5 ]

Kubernetesは、1台以上のコンピュータ（仮想マシンまたはベアメタル）をクラスタ化し、コンテナ内でワークロードを実行できるようにします。containerdやCRI-Oなど、様々なコンテナランタイムと連携します。[ 6 ]あらゆる規模とスタイルのワークロードの実行と管理に適しているため、クラウドやデータセンターで広く採用されています。このプラットフォームには、独立系ソフトウェアベンダー（ISV）によるディストリビューションだけでなく、主要なパブリッククラウドベンダーが提供するクラウドホスト型のサービスなど、複数のディストリビューションが存在します。[ 7 ]

このソフトウェアは、コントロールプレーンと、実際のアプリケーションが実行されるノードで構成されています。RESTベースのAPIと連携するためのツールやなどのツールも含まれていkubeadmます。[ 8 ]kubectl

歴史

2017 Google Cloud Summit での Google Kubernetes Engine の講演

Kubernetesは2014年6月6日にGoogleによって発表されました。[ 9 ]このプロジェクトは、Google社員のジョー・ベダ、ブレンダン・バーンズ、クレイグ・マクラッキーによって考案・開発されました。その後すぐに、ヴィル・アイカス、ドーン・チェン、ブライアン・グラント、ティム・ホッキン、ダニエル・スミスなど、Googleの他の社員もプロジェクトの構築に協力しました。[ 10 ] [ 11 ]その後すぐに、 Red HatやCoreOSなどの企業もこの取り組みに加わり、クレイトン・コールマンやケルシー・ハイタワーといった著名な貢献者も加わりました。[ 9 ]

Kubernetesの設計と開発は、GoogleのBorgクラスタマネージャに触発され、 Promise Theoryに基づいています。[ 12 ] [ 13 ] Kubernetesのトップコントリビューターの多くは、以前Borgに携わっていました。[ 14 ] [ 15 ]彼らは、スタートレックの元ボーグキャラクターであるセブン・オブ・ナインにちなんでKubernetesを「 Project 7」というコードネームで呼び、 [ 16 ] Kubernetesのロゴには7本スポークの舵輪（ティム・ホッキンのデザイン）が使われました。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位になりました。[ 26 ]

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

概念

Kubernetesアーキテクチャ図

Kubernetesは、 CPU、メモリ、またはカスタムメトリックに基づいてアプリケーションをデプロイ、保守、スケーリングするためのメカニズムを総合的に提供する一連の構成要素（「プリミティブ」）を定義します。 [ 29 ] Kubernetesは疎結合で拡張可能であり、さまざまなワークロードのニーズに対応します。Kubernetes上で実行される内部コンポーネント、拡張機能、コンテナはKubernetes APIに依存しています。[ 30 ] [ 31 ]

プラットフォームは、リソースをオブジェクトとして定義し、そのオブジェクトとして管理することで、コンピューティング リソースとストレージ リソースを制御します。

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

コントロールプレーン

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

その他

Etcd [ 34 ]は、永続的、軽量、分散型のキーバリューデータストアです（元々はCoreOSの一部として開発されました）。クラスタの構成データを確実に保存し、任意の時点におけるクラスタ全体の状態を表します。Etcdは、ネットワーク分断発生時に可用性よりも一貫性を重視します（ CAP定理参照）。一貫性は、サービスの適切なスケジューリングと運用に不可欠です。

APIサーバー

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

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

APIサーバーは、セキュリティ監視とフォレンジック分析のためのリクエストを記録するための監査ログをサポートしています。[ 33 ]ログプロパティが設定されていない場合、またはログに十分な詳細がない場合、組織は悪意のあるアクションや異常な動作を識別して追跡することができなくなり、脅威アクターが検知されずに活動できるようになります。[ 38 ]

スケジューラ

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

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

コントローラー

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

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

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

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

ノード

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

クベレット

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

コンテナランタイム

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

当初、kubeletは「dockershim」を介してDockerランタイム[ 48 ]とのみインターフェースしていました。しかし、2020年11月[ 49 ]から2022年4月にかけて、Kubernetesはshimを廃止し、containerdを介してコンテナと直接インターフェースするか、DockerをContainer Runtime Interface（CRI）に準拠したランタイムに置き換えることになりました。[ 50 ] [ 46 ] [ 51 ] 2022年5月のv1.24のリリースにより、「dockershim」は完全に削除されました。[ 52 ]

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

kubeプロキシ

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

名前空間

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

ポッド

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

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

ワークロード

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

レプリカセット、レプリケーションコントローラ、デプロイメント

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

ReplicationControllerはReplicaSet に似ており、ReplicaSet と同じ目的と動作を持ちます。つまり、常に指定された数のポッドレプリカが必要に応じて存在するようにすることです。ReplicationController ワークロードは ReplicaSet の前身でしたが、最終的にはセットベースのラベルセレクターを使用する ReplicaSet に置き換えられ、廃止されました。[ 56 ]

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

ステートフルセット

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

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

デーモンセット

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

サービス

Kubernetes クラスター内のサービスが Pod ネットワークとどのように相互作用するかを示す簡略化されたビュー

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

ボリューム

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

ConfigMapとシークレット

アプリケーションにおける一般的な課題の一つは、構成情報（機密データを含む場合もある）の保存場所と管理方法を決定することです。構成データは、個々のプロパティのようなきめの細かいものから、JSONやXMLドキュメントといった構成ファイル全体のような粗い情報まで、多岐にわたります。Kubernetesは、このニーズに対応するために、 ConfigMapとSecretという密接に関連する2つのメカニズムを提供しています。どちらも、アプリケーションの再構築を必要とせずに構成を変更できます。

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

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

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

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

ラベルとセレクタ

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

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

tier=backend AND release_track=canary

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

アドオン

アドオンは、Kubernetes クラスター内で実行されるアプリケーションとして実装された追加機能です。ポッドは、デプロイメントやレプリケーションコントローラーなどによって管理されます。アドオンは数多く存在しますが、特に重要なものは以下のとおりです。

DNS
クラスターDNSは、環境内の他のDNSサーバーに加えて、KubernetesサービスのDNSレコードを提供するDNSサーバーです。Kubernetesによって起動されたコンテナは、DNS検索にこのDNSサーバーを自動的に含めます。
ウェブUI
これはKubernetesクラスター用の汎用WebベースUIです。管理者は、クラスター内で実行されているアプリケーションだけでなく、クラスター自体の管理とトラブルシューティングを行うことができます。
リソース監視
コンテナ リソース モニタリングは、コンテナに関するメトリックを中央データベースに記録し、そのデータを参照するための UI を提供します。
コスト監視
Kubernetes コスト監視アプリケーションを使用すると、ポッド、ノード、名前空間、ラベルごとにコストを内訳できます。
クラスターレベルのログ記録
ノードまたはポッドの障害発生時にイベントデータの損失を防ぐため、コンテナログは検索/閲覧インターフェースを備えた中央ログストアに保存できます。Kubernetesはログデータ用のネイティブストレージを提供していませんが、既存の多くのログソリューションをKubernetesクラスターに統合できます。

ストレージ

コンテナは、ソフトウェアを移植可能にする手段として登場しました。コンテナには、サービスの実行に必要なすべてのパッケージが含まれています。提供されるファイルシステムにより、コンテナは極めて移植性が高く、開発環境でも容易に使用できます。コンテナは、設定変更をほとんど、あるいは全く行わずに、開発環境からテスト環境、あるいは本番環境に移行できます。

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

Cloud Native Computing Foundation （CNCF）は、Kubernetes Persistent Storageに関する情報を公開しており、その中にはコンテナ接続ストレージパターンの定義に役立つブログ記事も含まれています。このパターンは、Kubernetes自体をストレージシステムまたはサービスのコンポーネントとして使用するものと考えることができます。[ 64 ]

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

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

コンテナ接続ストレージ（Container Attached Storage）の共通の特性として、カスタムリソース定義などのKubernetes拡張機能の利用や、ストレージやデータ管理のために別途開発・導入される機能をKubernetes自体で実現できることが挙げられます。カスタムリソース定義またはKubernetes自体によって提供される機能の例としては、Kubernetes自体によって提供される再試行ロジックや、利用可能なストレージメディアとボリュームのインベントリの作成と維持（通常はカスタムリソース定義を介して提供される）などが挙げられます。[ 68 ] [ 69 ]

コンテナ ストレージ インターフェース (CSI)

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

API

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

APIオブジェクト

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オペレーターと呼ばれることがよくあります。[ 79 ]オペレーターの主な使用例は、サービスまたはサービスセットを管理する人間のオペレーターの目的を捉え、自動化と、この自動化をサポートする宣言型APIを使用して実装することです。特定のアプリケーションやサービスを管理する人間のオペレーターは、システムがどのように動作するべきか、どのように展開するか、そして問題が発生した場合にどのように対応するかについて深い知識を持っています。

オペレーターが解決する問題の例としては、アプリケーションの状態のバックアップの取得と復元、アプリケーションコードのアップグレード、データベーススキーマや追加の構成設定などの関連する変更への対応などが挙げられます。Cloud Native Computing Foundationのインキュベーションプログラムでは、Argo、Open Policy Agent、Istioなど、オペレーターパターンに従ってKubernetesを拡張する注目すべきプロジェクトがいくつか存在します。[ 80 ]

APIセキュリティ

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

輸送セキュリティ

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

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

認証

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

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

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

承認

Kubernetes APIは次の認証モードをサポートしています。[ 85 ]

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

Kubernetesの設定が過度に許可されている場合、権限昇格が可能になり、脅威アクターがポッドを制御できるようになる可能性があります。[ 86 ]管理者は、権限昇格を無効にし、最小権限の原則を適用するポッドセキュリティ標準とセキュリティコンテキストを適用する必要があります。[ 87 ] [ 88 ]

APIクライアント

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

クラスターAPI

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

用途

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

批判

Kubernetesに対するよくある批判は、複雑すぎるというものです。Googleもこれを認めています。[ 92 ]

配布

様々なベンダーがKubernetesベースのプラットフォームやKubernetesを導入するIaaS（Infrastructure as a Service ）を提供しています。 [ 93 ] [ 94 ]

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

オープンソースディストリビューション

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

商業流通

マネージドディストリビューション

リリースタイムライン

リリースタイムライン
バージョン 発売日 寿命終了日[ 97 ]注記
サポート対象外: 1.0 2015年7月10日 オリジナルリリース
サポート対象外: 1.12015年11月9日 [ 98 ]
サポート対象外: 1.22016年3月16日 2016年10月23日 [ 99 ]
サポート対象外: 1.32016年7月1日 2016年11月1日 [ 100 ]
サポート対象外: 1.42016年9月26日 2017年4月21日 [ 101 ]
サポート対象外: 1.52016年12月12日 2017年10月1日 [ 102 ]
サポート対象外: 1.62017年3月28日 2017年11月23日 [ 103 ]
サポート対象外: 1.72017年6月30日 2018年4月4日 [ 104 ]
サポート対象外: 1.82017年8月28日 2018年7月12日 [ 105 ]
サポート対象外: 1.92017年12月15日 2018年9月29日 [ 106 ]
サポート対象外: 1.102018年3月28日 2019年2月13日 [ 107 ]
サポート対象外: 1.112018年7月3日 2019年5月1日 [ 108 ]
サポート対象外: 1.122018年9月27日 2019年7月8日 [ 109 ]
サポート対象外: 1.132018年12月3日 2019年10月15日 [ 110 ]
サポート対象外: 1.142019年3月25日 2019年12月11日 [ 111 ]
サポート対象外: 1.152019年6月20日 2020年5月6日 [ 112 ]
サポート対象外: 1.162019年10月22日 2020年9月2日 [ 113 ]
サポート対象外: 1.172019年12月9日 2021年1月13日 [ 114 ]
サポート対象外: 1.182020年3月25日 2021年6月18日 [ 115 ]
サポート対象外: 1.192020年8月26日[ 116 ]2021年10月28日 Kubernetesバージョン1.19以降、サポート期間は1年間の完全サポートと2か月のメンテナンスモード期間に延長されました。[ 28 ] [ 117 ]
サポート対象外: 1.202020年12月8日 2022年2月28日 [ 118 ]
サポート対象外: 1.212021年4月8日 2022年6月28日 [ 119 ]
サポート対象外: 1.222021年8月4日 2022年10月28日 [ 120 ]
サポート対象外: 1.232021年12月7日 2023年2月28日 [ 121 ]
サポート対象外: 1.242022年5月3日 2023年7月28日 [ 122 ]
サポート対象外: 1.252022年8月23日 2023年10月27日 [ 123 ]
サポート対象外:1.262022年12月9日 2024年2月24日 [ 124 ]
サポート対象外:1.272023年4月11日 2024年6月28日 [ 125 ]
サポート対象外:1.282023年8月15日 2024年10月28日 [ 126 ]
サポート対象外:1.292023年12月13日 2025年2月28日 [ 127 ]
サポート対象外:1.302024年4月17日 2025年6月28日 [ 128 ]
サポート対象外:1.312024年8月13日 2025年10月28日 [ 129 ]
サポート対象:1.322024年12月11日 2026年2月28日 [ 130 ]
サポート対象:1.332025年4月23日 2026年6月28日 [ 131 ]
最新バージョン:1.342025年8月27日 2026年10月27日 [ 132 ]
伝説：
サポートされていません
サポートされている
最新バージョン
プレビュー版
将来のバージョン

サポートウィンドウ

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

参照

参考文献

  1. ^ "v0.2" . github.com . 2014年9月9日. 2022年11月23日時点のオリジナルよりアーカイブ。 2022年11月23日閲覧。
  2. ^ 「リリース 1.35.0」 . 2025年12月17日. 2025年12月17日閲覧。
  3. ^ "kubernetes/kubernetes" . GitHub . 2017年4月21日時点のオリジナルよりアーカイブ。2017年3月28日閲覧。
  4. ^ 「Kubernetesとは？」 Kubernetes . 2017年4月1日時点のオリジナルよりアーカイブ。2017年3月31日閲覧。
  5. ^ 「Kubernetesの概要」 . Kubernetes . 2023年1月8日時点のオリジナルよりアーカイブ。2022年1月4日閲覧。
  6. ^ 「コンテナランタイム」 . Kubernetes . 2019年7月18日時点のオリジナルよりアーカイブ。2021年11月14日閲覧。
  7. ^ 「ターンキークラウドソリューション」Kubernetesドキュメント。2023年7月24日時点のオリジナルよりアーカイブ。2023年7月25日閲覧。
  8. ^ 「Kubernetes API」 . Kubernetes . 2025年3月30日時点のオリジナルよりアーカイブ。2025年4月26日閲覧。
  9. ^ a b Metz, Cade. 「Googleがクラウドコンピューティングの秘密兵器をオープンソース化」 Wired . 2015年9月10日時点のオリジナルよりアーカイブ。 2015年9月24日閲覧。
  10. ^メッツ、ケイド。「Google、クラウド強化に向けた秘密の青写真を公開」。Wired 。 2016年7月1日時点のオリジナルよりアーカイブ。2016年6月27日閲覧。
  11. ^ Burns, Brendan (2018年7月20日)、「Kubernetesの歴史とその背後にあるコミュニティ」 、 2022年2月27日時点のオリジナルよりアーカイブ
  12. ^ Kubernetes: The Documentary [PART 1]、2022年1月21日、 2023年12月14日閲覧。
  13. ^ “kelseyhightower/status/1527333243845873664” . X (旧Twitter) . 2022年5月19日時点のオリジナルよりアーカイブ。 2023年12月14日閲覧。
  14. ^ a b Abhishek Verma、Luis Pedrosa、Madhukar R. Korupolu、David Oppenheimer、Eric Tune、John Wilkes（2015年4月21日～24日）。「Borgを用いたGoogleでの大規模クラスタ管理」。EuroSys （欧州コンピュータシステム会議）の議事録。2017年7月27日時点のオリジナルよりアーカイブ。
  15. ^ 「Borg、Omega、Kubernetes - ACM Queue」 . queue.acm.org . 2016年7月9日時点のオリジナルよりアーカイブ。 2016年6月27日閲覧。
  16. ^ 「アーリーステージのスタートアップHeptio、Kubernetesフレンドリー化を目指す」。2023年7月18日時点のオリジナルよりアーカイブ。2016年12月6日閲覧。
  17. ^ 「Kubernetesが1.0に到達、Googleが新たに設立されたクラウドネイティブコンピューティング財団に技術を寄付」 TechCrunch 、 2015年7月21日。2015年9月23日時点のオリジナルよりアーカイブ。 2015年9月24日閲覧。
  18. ^ 「Cloud Native Computing Foundation」。2017年7月3日時点のオリジナルよりアーカイブ。
  19. ^ 「Red HatとGoogle、Kubernetesで協力し、Dockerコンテナの大規模管理を実現」 2014年7月10日. 2019年7月2日時点のオリジナルよりアーカイブ。2022年8月6日閲覧。
  20. ^ 「VMwareとPivotalがPivotal Container Service（PKS）をリリース、Google Cloudとの連携でエンタープライズ顧客にKubernetesを提供」 2017年8月29日. 2022年10月6日時点のオリジナルよりアーカイブ。 2022年8月6日閲覧。
  21. ^ Lardinois, Frederic (2017年9月6日). 「Mesosphere、データセンターオペレーティングシステムにKubernetesサポートを追加」 . 2017年9月6日時点のオリジナルよりアーカイブ。2022年8月6日閲覧。
  22. ^ 「Docker、Dockerプラットフォームの機能強化を発表。エンタープライズITにおけるKubernetesの管理を簡素化・強化」 2017年10月17日。2020年9月26日時点のオリジナルよりアーカイブ。
  23. ^ Monroy, Gabe (2017年10月24日). 「AKS（マネージドKubernetes）とAzure Container Registryの改善点の紹介」 . 2018年2月7日時点のオリジナルよりアーカイブ。2022年8月6日閲覧。
  24. ^ 「Amazon Elastic Container Service for Kubernetes（プレビュー）のご紹介」 2017年11月29日. 2017年11月30日時点のオリジナルよりアーカイブ。 2022年8月6日閲覧。
  25. ^ 「Cisco Elastic Container Service for Kubernetes（プレビュー）のご紹介」。2025年2月14日時点のオリジナルよりアーカイブ。2025年2月6日閲覧。
  26. ^ Conway, Sarah (2018年3月6日). 「KubernetesはCNCF初の卒業プロジェクト」 . Cloud Native Computing Foundation . 2018年10月29日時点のオリジナルよりアーカイブ。2018年12月3日閲覧。GitHub上の150万のプロジェクトと比較すると、Kubernetesはコミット数で9位、作成者/問題数で2位であり、Linuxに次ぐ2位です。
  27. ^ 「Kubernetesのバージョンとバージョンスキューのサポートポリシー」Kubernetes . 2019年7月16日時点のオリジナルよりアーカイブ。2020年3月3日閲覧。
  28. ^ a b「Kubernetes 1.19リリース発表 > Kubernetesのサポート期間を1年に延長」 Kubernetes 2020年8月26日. 2020年8月28日時点のオリジナルよりアーカイブ。 2020年8月28日閲覧。
  29. ^ 「カスタムメトリックを使用してKubernetesの自動スケーリングを構成する」。Bitnami。BitRock。 2018年11月15日。 2019年3月27日時点のオリジナルよりアーカイブ。 2018年12月27日閲覧。
  30. ^ a b c d e f g h「Kubernetes入門」DigitalOcean . 2015年10月1日時点のオリジナルよりアーカイブ。2015年9月24日閲覧。
  31. ^ 「Kubernetes API」 . Kubernetes . 2025年3月30日時点のオリジナルよりアーカイブ。2025年4月26日閲覧。
  32. ^ a b c「Kubernetes Infrastructure」 . OpenShiftコミュニティドキュメント. OpenShift. 2015年7月6日時点のオリジナルよりアーカイブ。 2015年9月24日閲覧。
  33. ^ a b c d e f「Kubernetes Hardening Guide」（PDF） .米国国防総省. 2024年1月26日閲覧。
  34. ^ 「etcdとは？ | IBM」 . www.ibm.com . 2021年10月1日. 2025年10月16日閲覧。
  35. ^ a b Marhubi, Kamal (2015年9月26日). 「Kubernetes from the ground up: API server」 . kamalmarhubi.com. 2015年10月29日時点のオリジナルよりアーカイブ。 2015年11月2日閲覧。
  36. ^ Ellingwood, Justin (2018年5月2日). 「Kubernetes入門」 . DigitalOcean . 2018年7月5日時点のオリジナルよりアーカイブ。 2018年7月20日閲覧。最も重要なプライマリサービスの一つはAPIサーバーです。これはクラスター全体の主要な管理ポイントであり、ユーザーはAPIサーバーを通じてKubernetesのワークロードと組織単位を設定できます。また、etcdストアとデプロイされたコンテナのサービス詳細が一致していることを確認する役割も担っています。様々なコンポーネント間の橋渡し役として、クラスターの健全性を維持し、情報やコマンドを配信します。
  37. ^ a b「デプロイメント」 . Kubernetes . 2019年9月22日時点のオリジナルよりアーカイブ。2022年2月27日閲覧。
  38. ^ 「Traceability Loss - Kubernetes」 . Fluid Attacks Database . 2025年12月10日閲覧。
  39. ^ 「Kubernetesコンテナオーケストレーションの3本の柱 - Rancher Labs」rancher.com、2017年5月18日。2017年6月24日時点のオリジナルよりアーカイブ。2017年5月22日閲覧。
  40. ^ 「スケジューリングフレームワーク」 . Kubernetesドキュメント. 2023年7月23日時点のオリジナルよりアーカイブ。 2023年7月24日閲覧。
  41. ^ a b「レプリケーションコントローラの概要」 .ドキュメント. CoreOS . 2015年9月22日時点のオリジナルよりアーカイブ。 2015年11月2日閲覧。
  42. ^ Sanders, Jake (2015年10月2日). 「Kubernetes: エキサイティングな実験的機能」 . Livewyer . 2015年10月20日時点のオリジナルよりアーカイブ。 2015年11月2日閲覧。
  43. ^ a b「Intro: Docker and Kubernetes training - Day 2」 . Red Hat . 2015年10月20日. 2015年10月29日時点のオリジナルよりアーカイブ。 2015年11月2日閲覧。
  44. ^ Marhubi, Kamal (2015年8月27日). 「Kubeletとは何か？」 kamalmarhubi.com. 2015年11月13日時点のオリジナルよりアーカイブ。 2015年11月2日閲覧。
  45. ^ 「Kubernetes セキュリティ | 問題とベストプラクティス | Snyk」 . snyk.io. 2020年7月26日. 2021年5月16日閲覧。
  46. ^ a b「Kubernetesにおけるコンテナランタイムインターフェース（CRI）の導入」Kubernetes 2016年12月19日。2018年5月27日時点のオリジナルよりアーカイブ。 2021年5月16日閲覧。
  47. ^ 「Container Runtime Interface (CRI)」 . Kubernetesドキュメント. 2022年9月20日時点のオリジナルよりアーカイブ。 2023年7月24日閲覧。
  48. ^ 「Kubernetes v1.12: RuntimeClass の紹介」 kubernetes.io 2018年10月10日。2019年3月31日時点のオリジナルよりアーカイブ。 2018年11月14日閲覧。
  49. ^ 「Dockershimの廃止 - Kubernetes Githubリポジトリ - PR 94624」 . Github.com . 2020年12月1日時点のオリジナルよりアーカイブ。2022年9月30日閲覧。
  50. ^ 「Don't Panic: Kubernetes and Docker」 Kubernetes Blog 2020年12月2日. 2020年12月3日時点のオリジナルよりアーカイブ。 2020年12月22日閲覧。
  51. ^ "kubernetes/community" . GitHub . 2016年8月20日時点のオリジナルよりアーカイブ。2021年5月16日閲覧。
  52. ^ 「更新：Dockershim削除に関するFAQ」Kubernetesブログ、2022年2月17日。2022年2月17日時点のオリジナルよりアーカイブ。 2022年3月16日閲覧。
  53. ^ 「名前空間」 . kubernetes.io . 2019年10月3日時点のオリジナルよりアーカイブ。2019年10月6日閲覧。
  54. ^ "Pods" . kubernetes.io . 2019年5月8日時点のオリジナルよりアーカイブ。2018年12月17日閲覧。
  55. ^ a bランゲマック、ジョン (2015-02-11). 「Kubernetes 101 – ネットワーキング」。ダス・ブリンケン・リヒテン。2015 年 10 月 25 日にオリジナルからアーカイブされました。2015 年 11 月 2 日に取得。
  56. ^ a b "ReplicaSet" . kubernetes.io . 2019年7月16日時点のオリジナルよりアーカイブ。2020年3月3日閲覧。
  57. ^ 「StatefulSets」 . kubernetes.io .
  58. ^ "DaemonSet" . kubernetes.io . 2019年11月4日時点のオリジナルよりアーカイブ。2019年11月16日閲覧。
  59. ^ "Service" . kubernetes.io . 2019年5月8日時点のオリジナルよりアーカイブ。2018年11月21日閲覧。
  60. ^ジョン・ランゲマック (2015-02-15). 「Kubernetes 101 – クラスターへの外部アクセス」。ダス・ブリンケン・リヒテン。2015-10-26 のオリジナルからアーカイブ。2015 年 11 月 2 日に取得。
  61. ^ "Volumes" . kubernetes.io . 2019年10月12日時点のオリジナルよりアーカイブ。2019年10月6日閲覧。
  62. ^ "ConfigMaps" . Kubernetesドキュメント. 2023年7月23日時点のオリジナルよりアーカイブ。 2023年7月24日閲覧。
  63. ^ 「Secrets」 . Kubernetes . 2023年7月22日時点のオリジナルよりアーカイブ。2023年7月23日閲覧。
  64. ^ 「Container Attached Storage: A primer」 . Cloud Native Computing Foundation . 2018年4月19日. 2021年6月21日時点のオリジナルよりアーカイブ。 2021年5月16日閲覧。
  65. ^ 「DataoreがOpenEBSの元開発元MayaDataを買収」。datacore.com 。 2021年11月18日。
  66. ^ 「CNCF SURVEY 2019」（PDF）. cncf.io.
  67. ^ 「コンテナ接続ストレージ：入門」 . Cloud Native Computing Foundation . 2018年4月19日. 2020年10月9日閲覧。
  68. ^ 「Container Attached Storage | SNIA」www.snia.org . 2020年10月9日閲覧。
  69. ^ 「クラウドネイティブアプリケーションのチェックリスト：クラウドネイティブストレージ」www.replex.io . 2020年10月9日閲覧。
  70. ^ 「Kubernetes向けContainer Storage Interface（CSI）Alphaのご紹介」 kubernetes.io 2018年1月10日
  71. ^ 「Container Storage Interface (CSI) for Kubernetes GA」 kubernetes.io 2019年1月15日. 2022年8月22日時点のオリジナルよりアーカイブ。 2022年8月22日閲覧。
  72. ^ Marinescu, Dan C. (2018-01-01)、Marinescu, Dan C. (編)、「Chapter 8 - Cloud Hardware and Software」、Cloud Computing (Second Edition)、Morgan Kaufmann、pp.  281–319、doi : 10.1016/b978-0-12-812810-7.00011-x、ISBN 978-0-12-812810-7、 2023年11月8日取得{{citation}}: CS1 maint: ISBNによる作業パラメータ（リンク）
  73. ^ 「Kubernetes用etcdクラスターの運用」Kubernetesドキュメント。2023年7月23日時点のオリジナルよりアーカイブ。2023年7月24日閲覧。
  74. ^ 「Kubernetesのオブジェクト」 . Kubernetesドキュメント. 2023年7月24日閲覧。
  75. ^ 「API Conventions」 . GitHub . Kubernetes. 2023年7月23日時点のオリジナルよりアーカイブ。 2023年7月24日閲覧。
  76. ^ 「所有者と従属者」 . Kubernetesドキュメント. 2023年7月24日閲覧。
  77. ^ 「ガベージコレクション」。Kubernetesドキュメント。2023年7月23日時点のオリジナルよりアーカイブ。 2023年7月24日閲覧。
  78. ^ 「カスタムリソース」 . Kubernetesドキュメント. 2023年7月24日閲覧。
  79. ^ 「Operators」 . Kubernetesドキュメント. 2025年1月14日時点のオリジナルよりアーカイブ。 2025年1月12日閲覧。
  80. ^ 「クラウドネイティブランドスケープ」 . Cloud Native Computing Foundation . 2023年7月23日時点のオリジナルよりアーカイブ。 2023年7月24日閲覧。
  81. ^ 「Kubernetes APIへのアクセス制御」 . Kubernetesドキュメント. 2023年7月23日時点のオリジナルよりアーカイブ。 2023年7月24日閲覧。
  82. ^ 「apiserver の安全でないポートを削除する · Issue #91506 · kubernetes/kubernetes」。GitHub 。
  83. ^ 「認可」 . Kubernetesドキュメント. 2023年7月24日閲覧。
  84. ^ 「kubeconfigファイルを使用したクラスターアクセスの整理」Kubernetesドキュメント。2023年7月23日時点のオリジナルよりアーカイブ。2023年7月24日閲覧。
  85. ^ 「認可の概要」 . Kubernetesドキュメント. 2023年7月24日閲覧。
  86. ^ 「ロールベースアクセス制御のベストプラクティス」Kubernetesドキュメント。2025年12月10日閲覧。
  87. ^ 「Podセキュリティ標準」 . Kubernetesドキュメント. 2025年12月10日閲覧。
  88. ^ 「過剰な権限 - Kubernetes」 . Fluid Attacks Database . 2025年12月10日閲覧。
  89. ^ 「コマンドラインツール（kubectl）」 . Kubernetesドキュメント. 2023年7月23日時点のオリジナルよりアーカイブ。 2023年7月24日閲覧。
  90. ^ 「クライアントライブラリ」 . Kubernetesドキュメント. 2023年7月23日時点のオリジナルよりアーカイブ。 2023年7月24日閲覧。
  91. ^ 「入門 - Cluster API ブック」 . cluster-api.sigs.k8s.io .
  92. ^アンダーソン、ティム。「GoogleはKubernetesコンテナ技術が複雑すぎるため、ユーザーに代わってすべてを実行するAutopilot機能を導入せざるを得なかったことを認める」 The Register。
  93. ^ 「最も人気のあるKubernetesディストリビューション7選」 。 2021年7月25日時点のオリジナルよりアーカイブ。2021年12月28日閲覧。
  94. ^ MSV, Janakiram. 「Kubernetes開発者エコシステムにPaaSが必要な理由」 Forbes . 2021年4月12日時点のオリジナルよりアーカイブ。 2021年5月16日閲覧。
  95. ^ 「2022年に注目すべき5つのクラウドネイティブトレンド」 The New Stack、2022年1月3日。 2022年2月3日閲覧。
  96. ^ Kokalitcheva, Kia (2023年12月8日). 「スクープ：Nutanixがクラウドサーバー企業D2iQの資産を買収」 . axios.com . 2023年12月14日時点のオリジナルよりアーカイブ。2025年8月8日閲覧。
  97. ^ a b「Kubernetes Patch Releases」 . GitHub . 2022年5月4日. 2021年12月16日時点のオリジナルよりアーカイブ。2022年5月9日閲覧。
  98. ^ 「Kubernetes 1.1 パフォーマンスアップグレード、ツールの改善、そして成長するコミュニティ」 kubernetes.io 2015年11月9日。2022年10月6日時点のオリジナルよりアーカイブ。2024年1月13日閲覧。
  99. ^ 「Kubernetes 1.2: さらなるパフォーマンス向上、アプリケーションの導入と管理の簡素化」 kubernetes.io 2016年3月17日. 2022年10月6日時点のオリジナルよりアーカイブ。 2024年1月13日閲覧。
  100. ^ 「Kubernetes 1.3: クラウドネイティブとエンタープライズワークロードの橋渡し」 kubernetes.io 2016年7月6日。2022年10月6日時点のオリジナルよりアーカイブ。2024年1月13日閲覧。
  101. ^ “Kubernetes 1.4: Kubernetes 上でどこでも簡単に実行可能に” . kubernetes.io . 2016年9月26日. 2022年10月6日時点のオリジナルよりアーカイブ。2024年1月13日閲覧。
  102. ^ 「Kubernetes 1.5：本番環境ワークロードのサポート」 kubernetes.io 2016年12月13日。2022年10月6日時点のオリジナルよりアーカイブ。2024年1月13日閲覧。
  103. ^ 「Kubernetes 1.6: 大規模なマルチユーザー、マルチワークロード」 . kubernetes.io . 2017年3月28日. 2022年10月6日時点のオリジナルよりアーカイブ。 2024年1月13日閲覧。
  104. ^ 「Kubernetes 1.7：セキュリティ強化、ステートフルアプリケーションアップデート、拡張性」 kubernetes.io 2017年6月30日。2022年10月6日時点のオリジナルよりアーカイブ。 2024年1月13日閲覧。
  105. ^ 「Kubernetes 1.8: セキュリティ、ワークロード、機能の深さ」 kubernetes.io 2017年9月29日。2022年10月6日時点のオリジナルよりアーカイブ。2024年1月13日閲覧。
  106. ^ 「Kubernetes 1.9: アプリワークロードのGAリリースとエコシステムの拡張」 kubernetes.io 2017年12月15日。2022年10月6日時点のオリジナルよりアーカイブ。 2024年1月13日閲覧。
  107. ^ “Kubernetes 1.10: ストレージ、セキュリティ、ネットワークの安定化” . kubernetes.io . 2018年3月26日. 2022年10月6日時点のオリジナルよりアーカイブ。2021年1月30日閲覧。
  108. ^ 「Kubernetes 1.11: クラスター内ロードバランシングとCoreDNSプラグインが一般提供へ」 kubernetes.io 2018年6月27日。
  109. ^ 「Kubernetes 1.12: Kubelet TLS BootstrapとAzure Virtual Machine Scale Sets (VMSS)が一般提供に移行」 kubernetes.io 2018年9月27日。2022年10月6日時点のオリジナルよりアーカイブ。 2021年1月30日閲覧。
  110. ^ 「Kubernetes 1.13: Kubeadmによる簡素化されたクラスター管理、Container Storage Interface (CSI)、およびデフォルトDNSとしてのCoreDNSの一般提供開始」 kubernetes.io 2018年12月3日。 2022年10月6日時点のオリジナルよりアーカイブ。 2021年1月30日閲覧。
  111. ^ 「Kubernetes 1.14: Windowsノードの実稼働レベルのサポート、Kubectlアップデート、永続的なローカルボリュームのGA」 kubernetes.io 2019年3月25日。2022年10月6日時点のオリジナルよりアーカイブ。 2021年1月30日閲覧。
  112. ^ 「Kubernetes 1.15: 拡張性と継続的な改善」 . kubernetes.io . 2019年6月19日. 2022年10月6日時点のオリジナルよりアーカイブ。2021年1月30日閲覧。
  113. ^ 「Kubernetes 1.16: カスタムリソース、刷新されたメトリクス、ボリューム拡張」 . kubernetes.io . 2019年9月18日. 2022年10月6日時点のオリジナルよりアーカイブ。2021年1月30日閲覧。
  114. ^ 「Kubernetes 1.17: 安定性」 . kubernetes.io . 2019年12月9日.
  115. ^ “Kubernetes 1.18: Fit & Finish” . kubernetes.io . 2020年3月25日. 2024年1月13日時点のオリジナルよりアーカイブ。 2024年1月13日閲覧。
  116. ^ 「Kubernetes 1.19リリースアナウンスメント」 . Kubernetes . 2020年8月26日. 2020年8月28日時点のオリジナルよりアーカイブ。2020年8月28日閲覧。
  117. ^ 「Kubernetes 1.19: Paw-sitiveを強調」 Kubernetes 2020年8月26日. 2020年8月28日時点のオリジナルよりアーカイブ。 2024年1月13日閲覧。
  118. ^ “Kubernetes 1.20: The Raddest Release” . kubernetes.io . 2020年12月8日. 2020年12月9日時点のオリジナルよりアーカイブ。2020年12月9日閲覧。
  119. ^ 「Kubernetes 1.21: コミュニティへの力」 kubernetes.io 2021年4月8日。
  120. ^ “Kubernetes 1.22: 新たなピークに到達” . kubernetes.io . 2021年8月4日. 2022年10月6日時点のオリジナルよりアーカイブ。2021年9月7日閲覧。
  121. ^ “Kubernetes 1.23: The Next Frontier” . kubernetes.io . 2021年12月7日. 2022年10月6日時点のオリジナルよりアーカイブ。 2022年1月16日閲覧。
  122. ^ “Kubernetes 1.24: Stargazer” . kubernetes.io . 2022年5月3日. 2022年10月6日時点のオリジナルよりアーカイブ。2022年5月9日閲覧。
  123. ^ “Kubernetes v1.25: Combiner” . kubernetes.io . 2022年8月23日. 2022年10月6日時点のオリジナルよりアーカイブ。2022年8月28日閲覧。
  124. ^ 「Kubernetes v1.26: Electrifying」 . kubernetes.io . 2022年12月9日.
  125. ^ 「Kubernetes v1.27: Chill Vibes」 . kubernetes.io . 2023年4月11日.
  126. ^ 「Kubernetes v1.28: Planternetes」 . kubernetes.io . 2023年8月15日.
  127. ^ 「Kubernetes v1.29: Mandala」 . kubernetes.io . 2023年12月13日.
  128. ^ 「Kubernetes v1.30: Uwubernetes」 . kubernetes.io . 2024年4月17日.
  129. ^ "Kubernetes v1.31: Elli" . kubernetes.io。 2024 年 8 月 13 日。
  130. ^ “Kubernetes v1.32: Penelope” . kubernetes.io . 2024年12月11日. 2024年12月26日時点のオリジナルよりアーカイブ。 2025年1月2日閲覧。
  131. ^ 「Kubernetes v1.33: Octarine」 . kubernetes.io . 2025年4月23日.
  132. ^ 「Kubernetes v1.34: Of Wind & Will (O' WaW)」 . kubernetes.io . 2025年11月11日.
「 https://en.wikipedia.org/w/index.php?title=Kubernetes&oldid=1334507967」から取得