Kubernetes
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2026/09/06 22:08 UTC 版)
| |
|
| 作者 | |
|---|---|
| 開発元 | Cloud Native Computing Foundation |
| 初版 | 2014年6月7日[1] |
| 最新版 | |
| リポジトリ | https://github.com/kubernetes/kubernetes |
| プログラミング 言語 |
Go |
| 対応OS | Linux(ノードはWindows Serverも可) |
| サポート状況 | 開発中 |
| 種別 | クラスター管理ソフトウェア・コンテナオーケストレーション |
| ライセンス | Apache License 2.0 |
| 公式サイト | kubernetes.io |
Kubernetes(クバネティス[3]/クバネテス/クーベネティス[4][5]、K8sと略記される[6])は、コンテナ化したアプリケーションのデプロイ、スケーリング、および管理を自動化するための、オープンソースのコンテナオーケストレーションシステムである[7][8]。多数のサーバーをひとまとまりのクラスターとして扱い、その上でコンテナをどこに配置するか、止まったときにどう立て直すか、負荷に応じて数をどう増減するかを、利用者が記述した「あるべき状態」に基づいて自動的に調整する[8]。
元はGoogleが社内のクラスター管理システムBorgで得た経験を基に設計し、2014年6月にオープンソースとして公開した[9]。2015年7月のバージョン1.0公開と同時に、GoogleがLinux Foundationと共同で設立したCloud Native Computing Foundation(CNCF)へ寄贈され、以後はCNCFの下でコミュニティが開発を続けている[10]。2018年3月にはCNCFで最初の「卒業」(成熟)プロジェクトとなった[11]。
クラスターは、全体の状態を管理する「コントロールプレーン」と、実際にコンテナを動かす「ノード」から構成され、利用者はコンテナの集まりである「ポッド」などのオブジェクトをYAMLやJSONで宣言的に記述してAPIへ登録する[12]。本体はGoで書かれ、Apache License 2.0で公開されている。2021年以降は年3回のペースで新しいマイナーバージョンが公開され[13]、2026年8月にはバージョン1.37が公開された[14]。
Google CloudのGoogle Kubernetes Engine(GKE)、Microsoft AzureのAzure Kubernetes Service(AKS)、Amazon Web ServicesのAmazon Elastic Kubernetes Service(EKS)をはじめ、多くのクラウドサービス事業者がKubernetesクラスターの構築と運用を代行するマネージドサービスを提供しており[15][16][17]、Red HatのOpenShiftのようにKubernetesを組み込んだソフトウェア製品(ディストリビューション)も多い。CNCFが2024年に実施した年次調査では、回答組織の80%がKubernetesを本番環境で利用していた[18]。
名称
“Kubernetes”(希: κυβερνήτης、koo-ber-nay'-tace[19][20]、クベルネテス)は、ギリシャ語で航海長または水先案内人を意味し、サイバネティクス(人工頭脳学)の語源でもある[21]。
「K8s」という略記は、先頭の“K”と末尾の“s”の間に8文字があることから作られたヌメロニムである[6]。Google内での開発初期のコードネームはProject Sevenであり、スター・トレックに登場する、「より親しみやすいBorg」であるセブン・オブ・ナインに由来する[22]。これは前身となったGoogle社内システムの名がBorgであったことを踏まえた命名であり、舵輪をかたどったロゴにある7本のスポークはこのコードネームに由来している[22]。
歴史
Kubernetesは、Googleが社内で10年以上使ってきたクラスター管理の仕組みを、外部でも使える形に作り直して2014年に公開したものである。翌2015年に業界横断の財団CNCFへ移されてからは、クラウド事業者やソフトウェア企業が競合関係を越えて開発に参加し、2017年ごろにはコンテナオーケストレーションの標準的な選択肢となった。その後は年3回のリリースを重ねながら、Windows対応、ストレージやネットワークのAPI整備、ランタイムの世代交代、AI・機械学習向けの機能拡充を進めている。
起源(2013年〜2014年)
Kubernetesの設計は、Googleが社内で運用してきたクラスター管理システム「Borg」から強い影響を受けており[23][24]、Borgの主要な開発者の多くが開発に参加した。Borgは、Googleの多数のサービスを大規模なサーバー群で動かすために、ジョブをどのマシンに置くか、故障したらどう動かし直すかを自動で決める仕組みであり[23]、Kubernetesはその考え方をコンテナ向けに整理し直したものである[24]。
開発は当初、ジョー・ベダ(Joe Beda)、ブレンダン・バーンズ(Brendan Burns)、クレイグ・マクラッキー(Craig McLuckie)の3人によって始まり[25]、すぐにブライアン・グラント(Brian Grant)やティム・ホッキン(Tim Hockin)など他のGoogleのエンジニアも加わった。最初のコミットは2014年6月6日にGitHubへ登録され、250ファイル・47,501行のGo・シェルスクリプト・Markdownから始まった[9]。Googleは2014年6月にKubernetesを発表し[26]、同年11月には自社クラウド上でKubernetesクラスターを提供するサービスGoogle Container Engine(後のGoogle Kubernetes Engine)を発表した[27]。
バージョン1.0とCNCFの設立(2015年〜2016年)
Kubernetes 1.0は2015年7月21日に、オレゴン州ポートランドで開かれたオライリーのイベントOSCON 2015で発表された[28][10]。同時に、GoogleはLinux Foundationと共同でCloud Native Computing Foundation(CNCF)を設立し、Kubernetesを最初の「種となる技術」として提供した。CNCFにはIBM、インテル、Twitter、Red Hat、VMware、Docker社など多数の企業が創設メンバーとして参加した[28]。単一企業の製品ではなく中立の財団が管理する形をとったことが、後に競合するクラウド事業者が同じソフトウェアを採用する土台となった。
2015年11月のバージョン1.1では、負荷に応じてポッドの数を自動で増減する水平ポッドオートスケーラー(Horizontal Pod Autoscaler)、HTTPの入口を定義するIngress(ベータ版)、バッチ処理向けのJobなどが追加された[29]。2016年3月には開発主体がCNCFへ正式に移管され[30]、同年7月のバージョン1.3では、データベースのように状態を持つアプリケーションを扱うPetSet(後のStatefulSet)や、手元のパソコンで試すための小型版minikubeが登場した[31]。同年12月のバージョン1.5では、Docker以外のコンテナランタイムも差し替えて使えるようにする共通仕様Container Runtime Interface(CRI)がアルファ版として導入された[32]。
業界標準への普及(2017年〜2018年)
2017年には、それまで独自のオーケストレーション技術を推していた企業が相次いでKubernetesを採用した。8月にAmazon Web Services(AWS)がCNCFにプラチナメンバーとして加盟し[33]、10月にはDocker社が自社のオーケストレーション機能Swarmと同等の位置づけでKubernetesを統合・サポートすると発表した[34]。同月、マイクロソフトはKubernetes専用のマネージドサービスAKS(Azure Kubernetes Service)のプレビュー版を発表し[35]、CNCFはソフトウェアがKubernetesの仕様に正しく従っていることを示す「Kubernetes適合認証プログラム」(Certified Kubernetes)をベータ版として発表した[36]。11月にはGoogleがGoogle Container EngineをGoogle Kubernetes Engine(GKE)へ改名し[37]、AWSがre:Invent 2017でマネージドサービスAmazon Elastic Container Service for Kubernetes(後のAmazon EKS)を発表した[38][39]。これにより主要なパブリッククラウド3社がいずれもKubernetesのマネージドサービスを持つことになった。
2018年3月6日、KubernetesはCNCFのインキュベーション段階を終えて最初の「卒業」プロジェクトとなった[11][40]。この時点でKubernetesプロジェクトは、GitHub上の約150万プロジェクトの中でコミット数が第9位、コントリビューター数とissue数ではLinuxカーネルに次ぐ第2位に達していた[11]。同年6月にはAmazon EKSが正式提供となり[17][41]、AKSも同月に正式提供となった[16]。企業の再編も進み、Red Hatはコンテナ専業のCoreOS(etcdの開発元)を買収し[42]、VMwareはKubernetes創始者のうち2人(マクラッキーとベダ)が創業したHeptioを買収した[43]。技術面では、CRIにネイティブ対応した軽量ランタイムcontainerd 1.1が公開され[44]、バージョン1.10でGPUなどを扱うデバイスプラグインとストレージの共通仕様Container Storage Interface(CSI)のベータ版が[45]、12月のバージョン1.13でCSIの正式版とCoreDNSの既定DNSサーバー化が実現した[46]。監視ツールのPrometheusが2018年8月にKubernetesに続くCNCFの2番目の卒業プロジェクトとなるなど、周辺プロジェクトの成熟も進んだ[47]。
成熟と世代交代(2019年〜2022年)
2019年3月のバージョン1.14でWindows Serverをノードとして使う機能が正式版となり、LinuxコンテナとWindowsコンテナを同じクラスターで動かせるようになった[48][49]。コンテナランタイムでは、Kubernetes専用に設計されたCRI-Oの開発をCNCFがホストすることになり[50]、一方で2016年に対応が追加されていたCoreOS由来のランタイムrktは、2019年8月にCNCFがプロジェクトをアーカイブ(開発終了)した[51]。
2020年には、コミュニティが用語の見直しを行い、それまで「マスター」と呼んでいたクラスター管理側の構成要素を「コントロールプレーン」と呼ぶことを勧告した[52]。クラスター構築ツールkubeadmが付けるノードのラベルも、バージョン1.20で新名称を併存させ、1年以上の移行期間を置いたうえで旧名称を削除する計画が立てられた[53]。同年8月のバージョン1.19ではIngress APIが正式版となり、各バージョンのパッチ提供期間が9か月から1年に延長された[54][55]。12月のバージョン1.20では、Docker Engineを直接呼び出すための内部部品dockershimが非推奨となった[56][57]。プロジェクトは、Dockerで作ったコンテナイメージはそのまま使え、変わるのはノード上でコンテナを起動するランタイムだけであると説明した[58]。
2021年4月、リリースチームは年4回(四半期ごと)だったリリース周期を年3回に変更する提案を承認し、同年8月のバージョン1.22から新しい周期が適用された[13][59]。2022年5月のバージョン1.24でdockershimはkubeletから削除され、以後はcontainerdやCRI-OなどCRI対応ランタイムを使うか、Docker Engineを使い続ける場合はアダプターcri-dockerdを介する構成となった[60][61]。
2023年以降
2023年10月、HTTPやTCPの通信をクラスター外から受け入れる新しいAPI群Gateway APIのバージョン1.0が正式版となり、Ingressより役割分担と拡張性を重視した設計が標準となった[62]。同月、AWSが2021年に公開したノード自動増減ツールKarpenterがベータ版に達し、AWSはこれをCNCF傘下のKubernetes SIG Autoscalingへ寄贈する手続きを進めていると発表した[63]。2024年6月6日にプロジェクトは最初のコミットから10周年を迎えた[9]。
2025年8月のバージョン1.34では、GPUなど特殊なハードウェアをポッドに割り当てる仕組みDynamic Resource Allocation(DRA)の中核が正式版となり、AI・機械学習ワークロードの基盤としての整備が進んだ[64]。同年7月にはAWSがAmazon EKSで1クラスターあたり10万ノードまでの対応を発表するなど[65]、大規模なAI学習基盤としての利用も広がっている。2026年4月のバージョン1.36[66]に続き、2026年8月26日に公開されたバージョン1.37は67件の改良を含み、うち16件が正式版(Stable)に昇格した[14]。2026年7月に横浜で開かれたKubeCon + CloudNativeCon Japan 2026では、CNCFのCTOクリス・アニスチック(Chris Aniszczyk)が、CNCFのホストするプロジェクトが230以上、コントリビューターが191か国から30万人以上に達したと報告した[67]。
主要リリース
主なマイナーバージョンとその代表的な変更点を示す(網羅的な一覧ではない)。
| バージョン | 公開日 | 代表的な変更点 |
|---|---|---|
| 1.0 | 2015年7月21日 | 最初の安定版。CNCFの設立[28] |
| 1.1 | 2015年11月 | 水平ポッドオートスケーラー、Ingress(ベータ)、Job[29] |
| 1.3 | 2016年7月 | PetSet(後のStatefulSet)、minikube、複数クラスター連携[31] |
| 1.5 | 2016年12月 | Container Runtime Interface(CRI)アルファ版[32] |
| 1.10 | 2018年3月 | CSIベータ版、デバイスプラグイン[45] |
| 1.13 | 2018年12月 | CSI正式版、CoreDNSが既定のDNSに[46] |
| 1.14 | 2019年3月25日 | Windowsノード正式対応、Persistent Local Volumes正式版[48] |
| 1.19 | 2020年8月26日 | Ingress正式版、パッチ提供期間を1年に延長[54] |
| 1.20 | 2020年12月8日 | dockershim非推奨[56] |
| 1.22 | 2021年8月4日 | 年3回リリースへ移行後の最初の版[59] |
| 1.24 | 2022年5月3日 | dockershim削除[60] |
| 1.30 | 2024年4月17日 | コードネーム「Uwubernetes」[68] |
| 1.34 | 2025年8月27日 | Dynamic Resource Allocation(DRA)中核が正式版[64] |
| 1.35 | 2025年12月17日 | コードネーム「Timbernetes」[69] |
| 1.36 | 2026年4月22日 | コードネーム「ハル(Haru)」[66] |
| 1.37 | 2026年8月26日 | 67件の改良(16件が正式版へ)[14] |
リリースとサポート方針
Kubernetesのバージョンは「x.y.z」の形で表され、xがメジャー、yがマイナー、zがパッチのバージョンである[70]。2015年の1.0以降メジャーバージョンは1のまま維持されており、新機能はマイナーバージョン(1.20、1.21、……)の更新で追加される。
マイナーバージョンは2021年のバージョン1.22までは年4回(四半期ごと)、それ以降は年3回公開されている[13]。1回のリリースサイクルは約15週間で、当初の週で新機能の開発と取り込みを行い、終盤にコードフリーズ(変更の凍結)を置いて安定化する[71]。各マイナーバージョンには、不具合や脆弱性の修正だけを含むパッチバージョンが原則として月1回公開される[72]。
パッチの提供期間は、バージョン1.18以前は約9か月、1.19以降は約1年である[70][55]。正確には、コミュニティは各マイナーバージョンを約14か月間サポートし、最初の12か月を通常のサポート期間、残る2か月を重要な修正だけを行う保守期間としている[72]。プロジェクトが同時に保守するのは直近3つのマイナーバージョンであり、2026年9月時点では1.37・1.36・1.35がこれに当たる[70]。この方針の下では、利用者は少なくとも年1回程度はクラスターのバージョンを上げる必要がある。構成要素どうしのバージョン差についても方針が定められており、複数のkube-apiserverは互いに1マイナーバージョン以内、kubeletはkube-apiserverより最大3マイナーバージョン古いものまで許容される[73]。
| バージョン | 初版の公開日 | 保守終了予定 |
|---|---|---|
| 1.37 | 2026年8月26日 | 2027年10月28日 |
| 1.36 | 2026年4月22日 | 2027年6月28日 |
| 1.35 | 2025年12月17日[69] | 2027年2月28日 |
| 1.34 | 2025年8月27日 | 2026年10月27日 |
開発は、CNCFの下で分野ごとに置かれたSpecial Interest Group(SIG、分科会)が担い、新機能はKubernetes Enhancement Proposal(KEP)と呼ばれる提案文書を経て、アルファ(試験的)、ベータ、正式版(Stable、一般提供)の3段階で成熟度を上げていく[71][14]。たとえば2026年8月のバージョン1.37では、67件の改良のうち16件が正式版に、23件がベータに昇格し、27件がアルファとして新たに加わった[14]。
基本概念
Kubernetesでは、クラスター上で動かすものや、それらをつなぐ設定を「オブジェクト」として表現する。利用者は「このアプリケーションのコンテナを3つ動かしたい」「この名前で外部に公開したい」といった望ましい状態(desired state)をオブジェクトとしてAPIに登録し、Kubernetesが実際の状態をそこへ近づけ続ける[8]。この仕組みにより、アプリケーションのデプロイ、保守、スケールのメカニズムを、CPUやメモリ[74]、あるいはカスタムの指標[75]に基づいて実現できる。Kubernetesはさまざまなワークロードに対応できるよう、疎結合かつ拡張可能なシステムとして設計されており、その拡張性の大部分は、内部コンポーネントと外部の拡張機能の双方が同じKubernetes APIを通じて動作することで実現されている[76]。主なオブジェクトは以下のとおりである。
ポッド
Kubernetesでスケジューリング(どのノードで動かすかの決定)の基本単位となるのは、ポッド(Pod)である[77]。1つのポッドは1つ以上のコンテナから構成され、同じポッドに属するコンテナは必ず同じノード上に配置されるため、ストレージやネットワークを共有できる[76]。コンテナ単体ではなくポッドという一段高い抽象化を置くことで、主となるアプリケーションのコンテナに、ログ転送やプロキシなど補助的なコンテナ(サイドカー)を添えて一体として扱える。
各ポッドにはクラスター内で一意のIPアドレスが割り当てられる。ポッド内に複数のコンテナがある場合、それらは同じIPアドレスを共有し、互いにlocalhostで通信できるため、ポート番号の衝突を気にせずにアプリケーションを設計できる[78]。ただし、ポッドのIPアドレスは一時的なものであり、ポッドが再作成されると別のアドレスになる。そのためアプリケーション開発者は、ポッドのIPアドレスを直接使うのではなく、後述のサービスを通じて他のポッドにアクセスすることが推奨される[78]。
ポッドは、ローカルディスク上のディレクトリやネットワークストレージを「ボリューム」として定義し、内部のコンテナに公開できる[79]。ポッドはKubernetes APIで直接作ることもできるが、通常は後述のワークロードリソース(Deploymentなど)に管理を委ね、コントローラーが必要な数のポッドを作成・置換する[76][77]。ポッドは永続的な存在ではなく使い捨て(ephemeral)であることが前提で、ノードの故障や更新の際には別のノードで新しいポッドとして作り直される[77]。
ワークロードリソース
ポッドを直接1つずつ管理する代わりに、Kubernetesは用途別のワークロードリソースを提供する。これらはコントローラーによって管理され、指定した数や形でポッドを維持する[80]。
- DeploymentとReplicaSet - 状態を持たない(ステートレスな)アプリケーションの標準的な管理単位。ReplicaSetは同じ内容のポッドを指定した数だけ維持し、Deploymentはその上位でアプリケーションの新しいバージョンへの段階的な置き換え(ローリングアップデート)や巻き戻しを行う[80]。初期のKubernetesではReplication Controllerがこの役割を担っていた[81]。
- StatefulSet - データベースのように、個々のポッドが固有の名前と専用のストレージを持ち、起動や停止の順序が重要なアプリケーション向け[82]。2016年のバージョン1.3でPetSetとして導入された[31]。
- DaemonSet - ログ収集や監視エージェントのように、すべて(または特定)のノードにポッドを1つずつ配置する[83]。
- JobとCronJob - バッチ処理のように、完了したら終わる処理を実行する。Jobは処理が正常に完了するまでポッドを実行し、CronJobはそれをcron形式のスケジュールで定期的に起動する[83][29]。
サービス
サービス(Service)は、同じ役割を持つポッドの集まりに対して、変わらない1つの入口(仮想IPアドレスとDNS名)を与えるオブジェクトである[84]。どのポッドがサービスに属するかは、後述のラベルセレクターで定義する[76]。ポッドが再作成されてIPアドレスが変わっても、サービスの入口は変わらないため、他のアプリケーションはサービス名だけを知っていればよい。Kubernetesはサービスディスカバリー の手段として、環境変数を用いる方法とクラスター内DNSを用いる方法の2種類を提供している[84]。
サービスへの通信は、セレクターに一致するポッドの間で負荷分散される(ポッドが故障したノードから別のノードへ移っても、セレクターで動的に追従できる)[78]。サービスは既定ではクラスター内部にのみ公開されるが(ClusterIP型)、各ノードのポートを開ける方法(NodePort型)や、クラウド事業者のロードバランサーを自動で用意する方法(LoadBalancer型)によって、クラスターの外部に公開することもできる[84][85]。たとえば、バックエンド用のポッド群を1つのサービスとしてまとめ、複数のフロントエンド用ポッドからのリクエストを受ける、といった構成が典型的である。
IngressとGateway API
Ingressは、HTTPやHTTPSの通信をクラスター外部から受け取り、ホスト名やURLのパスに応じて内部のサービスへ振り分けるルールを定義するオブジェクトである[86]。Ingressのルールを実際に処理するのはIngressコントローラーと呼ばれる別のソフトウェア(NginxやHAProxy、各クラウドのロードバランサーなど)であり、Kubernetes本体には含まれない[86]。Ingress APIは2020年のバージョン1.19で正式版となった[55]。
Ingressは仕様が簡素で、ベンダーごとの拡張がアノテーション(注記)に依存していたため、その後継として設計されたのがGateway APIである。Gateway APIは、インフラ担当者が管理するGatewayClassやGatewayと、アプリケーション開発者が管理するHTTPRouteなどの経路定義を分け、役割に応じた権限分離とプロトコルごとの表現力を重視している[87]。2023年10月にバージョン1.0が正式版となった[62]。
ボリュームと永続ストレージ
コンテナ内のファイルシステムは既定では一時的なもので、コンテナが再起動すると内部のデータは失われる。ボリューム(Volume)はポッドに結び付いたストレージで、ポッドが生存している間はコンテナが再起動してもデータが保持され、同じポッド内のコンテナ間で共有もできる[77]。ボリュームはポッドの定義でコンテナ内の特定のマウントポイントに割り当てられ、同じボリュームを異なるコンテナのそれぞれ別の場所にマウントすることも可能である。
ポッドの寿命を超えてデータを残すためには、PersistentVolume(PV)とPersistentVolumeClaim(PVC)を使う。PVは管理者が用意するか動的に払い出されるクラスター上のストレージの実体(NFS、iSCSI、クラウド事業者のブロックストレージなど)であり、それを使う個々のポッドとは独立した寿命を持つ[88]。PVCは利用者側からの「この容量とアクセス方式のストレージが欲しい」という要求であり、ポッドがノードの計算資源を消費するのと同じように、PVCはPVを消費する[88]。管理者はStorageClassによって、性能や冗長性の異なる複数種類のストレージを、実装の詳細を利用者に見せることなく提供できる[88]。
ストレージ製品との接続は、当初はKubernetes本体にドライバーを組み込む形だったが、2018年のバージョン1.13で共通仕様Container Storage Interface(CSI)が正式版となり、以後はストレージベンダーが本体とは独立にCSIドライバーを提供する形が標準となった[46][45]。
ConfigMapとSecret
アプリケーションの設定値をコンテナイメージから切り離すために、ConfigMapとSecretというオブジェクトがある。ConfigMapは設定ファイルやパラメータなど機密でないデータを保持し、環境変数やファイルとしてコンテナに渡す[89]。Secretはパスワードや証明書、APIトークンなど機密性のあるデータを同様に渡すためのもので、ConfigMapと分けることで、アクセス権限の制御や保存時の暗号化を機密データだけに適用しやすくしている[90]。
ネームスペース
ネームスペース(Namespace、名前空間)は、1つのクラスターの中のリソースを重複のない区画に分ける仕組みで、多数のチームやプロジェクトが1つのクラスターを共用する場合を想定している[91]。オブジェクトの名前はネームスペース内で一意であればよく、開発・テスト・本番といった環境を分けたり、ネームスペース単位で権限や資源の上限(ResourceQuota)を設定したりできる[91]。CNCFの2024年の調査では、アプリケーションを分離する手段として回答組織の88%がネームスペースを使い、クラスターを分ける方法(65%)やラベルによる分離(31%)を上回っていた[18]。
ラベルとセレクター
Kubernetesは、ポッドやノードなどあらゆるAPIオブジェクトに対し、クライアント(利用者や内部コンポーネント)がラベルと呼ばれるキーと値の組を付けられるようにしている。それに対応して、ラベルセレクターはラベルに対するクエリーであり、一致するオブジェクトの集合を返す[76][92]。サービスを定義すると、トラフィックを送る先のポッドを選ぶためのラベルセレクターを指定できる。したがって、ポッドのラベルやサービスのセレクターを書き換えるだけで、どのポッドにトラフィックを送るかを制御でき、ブルー・グリーンデプロイやA/Bテストなどのデプロイ手法を実現できる。このようにサービスが使うリソースを動的に制御できることが、インフラ内での疎結合を実現している。
たとえば、あるアプリケーションのポッド群がtier(front-end、back-endなどの値)とrelease_track(canary、productionなどの値)というラベルを持つとき、back-endかつcanaryであるポッドをすべて指定するには、次のようなラベルセレクターが使える[93]。
tier=back-end AND release_track=canary
ラベルと似た仕組みとしてアノテーション(annotation)があり、これは選択には使わず、ツールや外部システムが参照する任意の付帯情報を保持する[92]。
フィールドセレクター
ラベルと同様に、フィールドセレクターもKubernetesの任意のリソースを選択可能にするものである。ラベルとは異なり、選択はユーザーが定義したカテゴリではなく、リソースにあらかじめ備わっている属性の値に基づいて行われる。metadata.nameやmetadata.namespaceは、すべてのKubernetesオブジェクトに存在するフィールドである。使用できる他のフィールドは、オブジェクトやリソースの種類によって異なる。
アーキテクチャ
Kubernetesクラスターは、クラスター全体の状態を管理するコントロールプレーン(control plane)と、コンテナを実際に実行する複数のノード(node)から構成される[12][94]。利用者やツールはコントロールプレーンのAPIに「あるべき状態」を登録し、コントロールプレーンがノードに指示を出してその状態を実現・維持する。コンテナはポッドという単位で各ノード上に配置される[12]。
コントロールプレーンの構成要素はそれぞれ独立したプロセスとして動作し、1台のマシンにまとめて置くことも、高可用構成のために複数台に分散して置くこともできる[94]。コントロールプレーンを載せるノードは初期には「マスター」(master)、コンテナを動かすノードは「ワーカー」あるいは「ミニオン」(minion)と呼ばれていたが、2020年にコミュニティが用語の見直しを行い、公式文書では管理側の構成要素全体を「コントロールプレーン」と呼ぶことに統一された[52][53]。
コントロールプレーン
コントロールプレーンは、ワークロードの配置やシステム全体の状態遷移を管理する中枢である。以下の構成要素からなる[12]。
kube-apiserver
kube-apiserverは、HTTP上のJSONでKubernetes APIを提供するサーバーで、Kubernetesの内部・外部に対する唯一の窓口となる[76][95]。RESTリクエストの認証・認可・検証を行い、APIオブジェクトの状態をetcdに保存・更新する。コマンドラインツールkubectlをはじめ、後述のコントローラーやkubeletなど他のすべての構成要素もこのAPIを通じて動作するため、利用者はAPIサーバーを介してクラスター全体のワークロードと設定を操作できる[96]。
etcd
etcdは、CoreOS社が開発した、軽量で永続的な分散キーバリューストアであり、クラスターの設定データと任意の時点におけるクラスター全体の状態を保存する[94]。Apache ZooKeeperと同様に、ネットワーク分断の際には可用性(Availability)より一貫性(Consistency)を優先する設計である(CAP定理を参照)。この一貫性は、正しいスケジューリングとサービスの動作にとって重要である。APIサーバーはetcdの監視(watch)機能を用いて設定やクラスター状態の変更を検知し、宣言された状態と実際の状態に差があれば修復に向かう。たとえば、あるポッドのインスタンスを3つ実行するようデプロイ時に指定するとその情報がetcdに保存され、実行中のインスタンスが2つしか見つからなければ、その差分に基づいて追加のポッドがスケジュールされる[94]。etcd自体もCNCFの卒業プロジェクトとして独立に開発されている[18]。
kube-scheduler
kube-schedulerは、まだノードに割り当てられていないポッドを検出し、資源の空き状況に基づいて実行するノードを選ぶ、差し替え可能な構成要素である[12]。各ノードの資源使用量を追跡し、ワークロードが利用可能な資源を超過しないようにする。そのためスケジューラーは、資源の要求量と空き、利用者が指定した制約、サービス品質、親和性・非親和性(特定のノードやポッドと同居させる・させない)、データの局所性といったポリシーを考慮する。本質的には、スケジューラーの役割は資源の「供給」をワークロードの「需要」に合わせることである[97]。
kube-controller-manager
コントローラーは、クラスターの実際の状態を望ましい状態へ近づけ続ける制御ループである[81]。たとえばReplicaSetを管理するコントローラーは、ポッドのレプリカ数がクラスター全体で指定した数になるよう作成や削除を行い、ノードが故障すれば代替のポッドを作る[81]。DaemonSetを扱うコントローラーは各ノードにポッドが1つずつ存在するようにし、Jobを扱うコントローラーはバッチ処理が完了するまでポッドを実行する[83]。各コントローラーが管理するポッド群は、定義に含まれるラベルセレクターによって特定される[93]。
kube-controller-managerは、こうしたKubernetes標準のコントローラー群をまとめて実行する1つのプロセスである[12]。コントローラーはAPIサーバーと通信し、管理対象のリソース(ポッド、サービスのエンドポイントなど)の作成・更新・削除を行う[95]。
cloud-controller-manager
cloud-controller-managerは、クラスターがパブリッククラウド上で動く場合に、ロードバランサーやノード(仮想マシン)の情報、経路設定など、クラウド事業者固有のAPIとのやり取りを担う任意の構成要素である[12]。クラウド固有の処理をこの構成要素に分離することで、Kubernetes本体は特定の事業者に依存しない形を保っている。
ノード
ノードは、コンテナ(ワークロード)が実際に配置される物理マシンまたは仮想マシンである。クラスター内のすべてのノードはコンテナランタイムを実行するとともに、コントロールプレーンと通信してポッドやネットワークの設定を行う以下の構成要素を実行する[12]。
kubelet
kubeletは各ノードで動作するエージェントで、そのノード上のコンテナが健全な状態にあることを保証する。コントロールプレーンの指示を受けて、コンテナランタイムに対してアプリケーションコンテナの起動・停止を指示し、それらをポッドとして組織する[76][98]。kubeletはポッドの状態を監視し、指定された状態から逸脱していれば同じノード上でポッドを再起動する。また、ノードの状態をハートビートとしてコントロールプレーンへ定期的に報告しており、既定では40秒間ノードと疎通できない場合にノードコントローラーがそのノードの状態を不明(Unknown)とみなし、そのノード上のポッドは別の健全なノードで新たに起動される[99]。kubeletには、ノード上のコンテナのCPU・メモリ・ファイル・ネットワークの使用量を収集するcAdvisor由来の機能が組み込まれており、収集した指標はオートスケーリングや監視ツールに利用される。
コンテナランタイム
コンテナランタイムは、ノード上でコンテナを実際に起動・停止するソフトウェアである[12]。Kubernetesは初期にはDockerのみを想定していたが、2016年のバージョン1.5でkubeletとランタイムの間の共通仕様Container Runtime Interface(CRI)が導入され、kubeletを再コンパイルせずにさまざまなランタイムを差し替えて使えるようになった[32][100]。CRIはgRPCに基づくプロトコルであり、公式ドキュメントが挙げる代表的なCRI対応ランタイムはcontainerd、CRI-O、Docker Engine(アダプターcri-dockerd経由)、Mirantis Container Runtimeである[101]。
containerdはDocker社がDocker Engineの中核部分を切り出してCNCFに寄贈したランタイムで、2018年のバージョン1.1でCRIにネイティブ対応した[44]。CRI-OはKubernetes専用に設計された軽量ランタイムで、2019年からCNCFがホストし、2023年に卒業プロジェクトとなった[50][102]。一方、Docker Engineを直接呼び出すためにkubeletに組み込まれていたdockershimは、バージョン1.20(2020年12月)で非推奨となり、1.24(2022年5月)で削除された[101][60]。この変更はノード上でコンテナを起こす部品の置き換えであり、Dockerで作成したOCI準拠のコンテナイメージは、どのランタイムでも引き続きそのまま動作する[58]。2016年に対応が追加されたCoreOS社のrktは2019年に開発を終了した[51]。
kube-proxy
kube-proxyは各ノードで動作するネットワークプロキシで、ノード上のパケット転送ルール(iptablesやIPVSなど)を維持することによってサービスの仮想IPアドレスを実装し、受信したトラフィックを宛先のポッドへ振り分ける[12][84][76]。一部のネットワークプラグインはkube-proxyの機能を自ら提供するため、公式ドキュメントではkube-proxyは任意の構成要素とされている[12]。
アドオン
アドオンは、クラスターの機能を実装するソフトウェアだが、Kubernetes本体の一部ではなく、他のアプリケーションと同じようにポッドやサービスとしてクラスター内で実行される[103]。代表的なものは次のとおりである。
- ネットワーク - ポッド間のネットワークは、Container Network Interface(CNI)仕様に従うプラグインが提供する。Calico、Cilium、Flannel、Canalなどがあり、たとえばCiliumはeBPFを用いたデータプレーンによってネットワーク、可観測性、セキュリティの機能を提供する[103]。ポッド間の通信を許可・遮断するNetworkPolicyも、対応するプラグインが実装する[103]。
- DNS - すべてのKubernetesクラスターはクラスター内DNSを持つことが求められる。クラスターDNSはサービスやポッドの名前を解決するDNSサーバーで、Kubernetesが起動したコンテナには自動的に名前解決先として設定される。2018年のバージョン1.13以降はCoreDNSが既定のDNSサーバーである[46]。
- ウェブUI(ダッシュボード) - クラスター上のアプリケーションやクラスター自体をブラウザーから管理・トラブルシューティングするための汎用のウェブインターフェースである[103]。
- メトリクスとロギング - 負荷に応じたスケーリングや性能監視には、コンテナの資源使用量を継続的に計測する仕組みが必要である。kubeletが収集する基本的な指標を集約するmetrics-serverや、時系列データベースとして指標を保存・検索するPrometheusなどが用いられる[47]。ログについては、ノードやポッドの停止でログが失われないよう、コンテナのログを中央のログ保存基盤に送るクラスターレベルロギングの仕組みをアドオンとして組み込むのが一般的である。
拡張性
Kubernetes APIは、利用者が独自のオブジェクト種別を追加できるように設計されている。CustomResourceDefinition(CRD)を登録すると、標準のポッドやサービスと同じAPIの流儀で扱える「カスタムリソース」が使えるようになる[104]。カスタムリソースと、それを監視して実際の処理を行う独自のコントローラーを組み合わせる設計はオペレーターパターンと呼ばれ、データベースやメッセージキューのような複雑なソフトウェアの導入・更新・バックアップといった運用手順を、Kubernetesの宣言的な流儀で自動化するために広く使われている[105]。クラウド事業者も、自社サービスをカスタムリソースとして定義できるコントローラー群(AWSのAWS Controllers for Kubernetesなど)を提供している[106]。
このほか、APIサーバーがオブジェクトを保存する前に外部プログラムへ検証や書き換えを依頼するアドミッションウェブフック(admission webhook)、独自のAPIサーバーを本体のAPIに合流させるAPI集約(aggregation)などの拡張点があり、前述のCNI、CSI、CRIといった各種インターフェースと合わせて、ネットワーク・ストレージ・ランタイムの実装をKubernetes本体から切り離している[104]。
セキュリティ
APIサーバーへのすべてのリクエストは、認証(誰か)、認可(何をしてよいか)、アドミッション制御(要求内容の検証)の順に処理される。認可の標準的な方式はロールベースアクセス制御(RBAC)で、組織内の個々のユーザーやサービスアカウントの役割(Role)に基づいて、どのネームスペースのどのリソースにどの操作を許すかを定める[107]。
ポッドの側では、特権コンテナの禁止やホスト資源への接触制限といった安全基準がPod Security Standardsとして定義されており、2022年のバージョン1.25で正式版となった組み込みのPod Security Admissionコントローラーがネームスペース単位でこれを強制する[108]。機密情報はSecretとして分離して扱い[90]、ポッド間の通信はNetworkPolicyで制限できる[103]。
オートスケーリング
Kubernetesには、負荷の変動に応じて自動的に規模を調整する複数の仕組みがある[109]。
- 水平ポッドオートスケーラー(HorizontalPodAutoscaler、HPA) - CPU使用率などの指標に基づいて、DeploymentやStatefulSetのポッド数を増減する[110]。2015年のバージョン1.1で導入された[29]。
- 垂直ポッドオートスケーラー(VerticalPodAutoscaler、VPA) - 過去の使用実績から、個々のコンテナに割り当てるCPU・メモリの量を調整する[109]。
- ノードのオートスケーリング - ポッドを配置しきれないときにノード(仮想マシン)を追加し、空きが増えたら減らす。Kubernetes SIG Autoscalingが管理する実装として、Cluster Autoscalerと、AWSが2021年に公開しその後CNCF傘下の同SIGへ移管したKarpenterの2つがある[111][63]。
- イベント駆動のオートスケーリング - メッセージキューの滞留数など外部のイベント数に基づいてポッドを増減するKEDA(Kubernetes Event-driven Autoscaling)は、2023年にCNCFの卒業プロジェクトとなった[109][112]。
ディストリビューションとマネージドサービス
Kubernetesはオープンソースのソフトウェアであり、ソースコードから自分で構築して運用することもできるが、実際には、Kubernetesを組み込んで製品化したソフトウェア(ディストリビューション)や、クラウド事業者がコントロールプレーンの運用を代行するマネージドサービスを通じて利用されることが多い。CNCFは、こうした製品がKubernetesのAPIに正しく従っていることを確認する「Certified Kubernetes」適合認証プログラムを2017年から運営しており[36]、認証を受けた製品・サービスは90を超える[113]。認証があることで、利用者はある製品向けに書いた定義ファイルを別の製品でもそのまま使えることを期待できる。
マネージドサービス
主要なパブリッククラウド事業者は、いずれもKubernetesのマネージドサービスを提供している。利用者はコントロールプレーンの構築・更新・冗長化を事業者に任せ、ノードとアプリケーションの管理に集中できる。
| 事業者 | サービス名 | 正式提供開始 | 備考 |
|---|---|---|---|
| Google Cloud | Google Kubernetes Engine(GKE) | 2015年8月[15] | 2014年11月にGoogle Container Engineとして発表[27]。2017年11月に現名称へ改称[37]。2021年にノードの管理まで自動化するAutopilotを追加[114] |
| Amazon Web Services | Amazon Elastic Kubernetes Service(EKS) | 2018年6月[17] | 2017年11月に発表[38]。2019年にサーバーレスでポッドを動かすAWS Fargate対応[115]、2024年にノード・ストレージ・ネットワークの運用を自動化するEKS Auto Modeを追加[116] |
| Microsoft Azure | Azure Kubernetes Service(AKS) | 2018年6月[16] | 2017年10月にプレビュー版を発表[35]。2025年に本番向け構成を自動で整えるAKS Automaticを追加[117] |
3社のサービスはいずれも、当初はコントロールプレーンだけを管理する形で始まり、その後ノードの選定や増減、更新までを事業者側が自動で行う「自動運用型」の提供形態(GKE Autopilot、EKS Auto Mode、AKS Automatic)を加えている[114][116][117]。このほかOracle Cloud、IBM Cloud、Alibaba Cloudをはじめ多くのクラウド事業者が同種のサービスを提供し、Certified Kubernetesの認証を受けている[113]。
AWSの取り組み
AWSは2017年8月にCNCFへプラチナメンバーとして加盟した[33]。同社は当時、CNCFの調査を引いて、Kubernetesのワークロードの63%がAWS上で動いていると説明しており、EKSの提供はこれら既存利用者のクラスター運用を引き受けることを目的としていた[39]。EKSのGA時点でAWSは、Kubernetesを運用する企業の57%がAWSを選んでいるとするCNCFの数値を挙げている[17]。
AWSはマネージドサービスに加えて、Kubernetes関連のオープンソースソフトウェアも公開している。2020年には、EKSで使っているKubernetesディストリビューション自体をAmazon EKS Distro(EKS-D)として公開し[118]、コンテナ実行に特化したオペレーティングシステムBottlerocketをオープンソースで公開した[119]。2021年には利用者自身のデータセンターにEKSと同じ構成のクラスターを構築するAmazon EKS Anywhereを正式提供し[120][121]、同年公開したノード自動増減ツールKarpenterは前述のとおりKubernetes SIG Autoscalingへ移管された[63]。AWSのサービスをカスタムリソースとして扱うAWS Controllers for Kubernetes(ACK)も2020年に公開している[106]。2025年7月には、AI・機械学習向けに1クラスターあたり10万ノードまでの対応を発表した[65]。
同種の取り組みは他社にもあり、Googleは2018年にオンプレミスのKubernetesクラスターをGoogle Cloudから統合管理するGKE On-Premを発表し[122]、2019年にはこれを発展させてオンプレミスや他社クラウドにまたがるプラットフォームAnthosを公開した[123]。マイクロソフトは2020年に、OpenShiftやRancherを含む他社環境のKubernetesクラスターをAzureから管理するAzure Arc enabled Kubernetesをプレビュー公開した[124]。
商用ディストリビューション
- OpenShift(Red Hat) - 2015年6月に公開されたOpenShift Enterprise 3以降、DockerコンテナとKubernetesを中核とするPaaS基盤として提供されている[125]。Red Hatは2018年にetcdの開発元CoreOSを買収し、その技術を取り込んだ[42]。コミュニティ版としてOKDがある。
- Rancher(SUSE) - 複数のKubernetesクラスターをまとめて管理するソフトウェア。開発元のRancher Labsは2019年に軽量ディストリビューションk3sを公開し[126]、2020年にSUSEが買収した[127]。
- VMware Tanzu(VMware) - 2019年に発表されたKubernetes関連製品群で[128]、2020年に仮想化基盤vSphereにKubernetesを組み込んだvSphere with Tanzuが発表された[129]。VMwareは2018年にKubernetes創始者らのHeptioを買収してこの分野に参入した[43]。
- Mirantis Kubernetes Engine(Mirantis) - Docker社のエンタープライズ向け製品群(Docker Enterprise)を2019年11月にMirantisが取得したもので、Mirantisは軽量ディストリビューションk0sも公開している[130][131]。
軽量版と開発環境
開発者が手元で試すための小型のKubernetesも複数ある。minikubeは2016年のバージョン1.3とともに登場した単一マシン向けの環境で[31]、Docker社のDocker Desktop(Windows・Mac版)は2018年からKubernetesを同梱している[132]。k3s(約40MBの単一バイナリ)[126]やk0s[131]は、エッジ機器や小規模環境向けに機能を絞った本番利用可能なディストリビューションである。
エコシステム
Kubernetesの周囲には、CNCFがホストするプロジェクトを中心に、パッケージ管理、デプロイ自動化、ネットワーク、監視、サーバーレス、機械学習などの分野で多数のツールが育っている。Kubernetes本体は最小限の機能に絞り、こうした周辺ツールが差し替え可能な形で機能を補うのが、このエコシステムの基本的な構造である。
パッケージ管理と構成管理
Helmは、Kubernetes上のアプリケーションを「チャート」と呼ぶひとまとまりの定義として配布・導入・更新するパッケージマネージャーである。2015年にDeis社(後にマイクロソフトが買収)で作られ、2016年にGoogle、Skippbox、Bitnamiのチームと合流してHelm 2となり、2020年4月にCNCFの10番目の卒業プロジェクトとなった[133]。CNCFの2024年の調査では、Kubernetes向けのパッケージマネージャーとして回答組織の75%がHelmを使っており、2023年の56%から増えていた[18]。Kustomizeは、共通のマニフェストに環境ごとの差分を重ねて最終的な定義を組み立てるツールで、コマンドラインツールkubectlに組み込まれている[134]。
デプロイの自動化
Gitリポジトリに置いた定義ファイルを「正」とし、クラスターの状態をそれに自動で一致させる運用手法はGitOpsと呼ばれる。Kubernetes向けの代表的な実装であるArgo(Argo CDなど)は2022年12月にCNCFの卒業プロジェクトとなった[135]。Infrastructure as CodeツールのTerraformなどによってクラスターそのものやクラウド資源を定義し、Kubernetes上のアプリケーションはGitOpsで管理する、という組み合わせも一般的である。
サービスメッシュ
多数のマイクロサービスの間の通信に、暗号化、認証、リトライ、トラフィックの分割、計測といった共通機能を一括して与える基盤をサービスメッシュと呼ぶ。Kubernetes上で動く代表的な実装として、Linkerd(2021年7月にCNCF卒業)[136]と、GoogleとIBMなどが開発したIstio(2023年7月にCNCF卒業)[137]がある。
監視とオブザーバビリティ
コンテナは短命で数が多く、ノードをまたいで移動するため、従来のサーバー単位の監視では追い切れない。このため、Kubernetesの運用では、指標(メトリクス)、ログ、分散トレースを集めてシステム内部の状態を推測するオブザーバビリティ(可観測性)の考え方が重視される。CNCFの卒業プロジェクトであるPrometheusは、Kubernetes APIからポッドやサービスを自動検出して指標を収集する監視・アラートシステムであり[47]、指標・ログ・トレースの収集方法を標準化するOpenTelemetryは2019年にCNCFで発足し、2026年5月に卒業プロジェクトとなった[138]。可視化にはGrafanaがよく組み合わせられる。
商用のオブザーバビリティサービスもKubernetes向けの連携機能を提供しており、調査会社ガートナーの「Magic Quadrant for Observability Platforms」2025年版・2026年版でリーダーに位置づけられたと各社が発表しているものには、Datadog[139]、Dynatrace[140]、New Relic[141]、Splunk[142]、Grafana Labs[143]などがある。これらのサービスは、ノードごとにエージェントをDaemonSetとして配置し、クラスター単位の情報はKubernetes APIから取得する構成をとることが多い[144]。
サーバーレスとイベント駆動
Kubernetesの上に、リクエストに応じてコンテナを起動し、使われないときは0個まで縮退させるサーバーレス基盤を構築するソフトウェアとして、Googleが開発し2021年12月にCNCFへ寄贈したKnativeがある。Knativeは2025年10月にCNCFの卒業プロジェクトとなった[145][146]。イベント数に基づくオートスケーリングを提供するKEDAは、2020年にCNCFのプロジェクトに採用され、2023年に卒業した[147][112]。
仮想マシンとWebAssembly
コンテナ以外のワークロードをKubernetesで管理する試みも進んでいる。KubeVirtはKubernetes上で従来型の仮想マシンをポッドと同じ流儀で管理するもので、2023年7月にバージョン1.0が公開された[148]。WebAssemblyで書かれたサーバーレスアプリケーションをKubernetes上で動かすSpinKubeは、2024年3月にCNCFへの寄贈が発表された[149]。
AI・機械学習
機械学習の学習・推論ジョブをKubernetes上で動かす基盤として、Googleが始めたKubeflowがある。Kubeflow 1.0は2020年3月に公開され、Jupyter Notebookによる開発から学習、デプロイまでを任意のKubernetes上に構築できる[150]。Kubernetes本体側でも、GPUなどのアクセラレータをポッドに割り当てるデバイスプラグイン(2018年)[45]、それをより柔軟にしたDynamic Resource Allocation(2025年に中核が正式版)[64]といった機能が整備されてきた。CNCFの2024年の調査では、回答組織の48%がまだAI・機械学習のワークロードをKubernetes上で動かしていなかったが、先行する組織はモデルの学習や推論、データ処理などに用いていた[18]。
認定資格
CNCFとLinux Foundationは、Kubernetesの技能を認定する資格試験を運営している[151]。クラスターの構築・運用を担う管理者向けのCertified Kubernetes Administrator(CKA)[152]、アプリケーション開発者向けのCertified Kubernetes Application Developer(CKAD)[153]、セキュリティ専門のCertified Kubernetes Security Specialist(CKS)[154]、入門レベルのKubernetes and Cloud Native Associate(KCNA)[155]などがあり、いずれもコマンド操作を伴う実技試験(KCNAは選択式)である。日本では2018年秋からCKAとCKADの日本語でのトレーニングと受験が可能になった[156]。
利用と普及
マイクロサービスとクラウドネイティブ
Kubernetesは、マイクロサービスアーキテクチャに基づくアプリケーションの実行基盤としてよく使われる。Kubernetesとその周辺ツールのエコシステムは、サービスの発見、負荷分散、段階的なデプロイ、故障時の自動復旧、スケーリングなど、マイクロサービスアーキテクチャが必要とする機能をひとそろい提供するためである(詳しくはマイクロサービスの項を参照)。コンテナとマイクロサービスを前提に、クラウドの伸縮性を活かして設計・運用する考え方は「クラウドネイティブ」と呼ばれ、CNCFはKubernetesをその中核技術と位置づけている[18]。
普及の理由
2018年初頭の時点で、Kubernetesはコンテナオーケストレーションにおいてデファクトスタンダードと呼べる存在になっていた。短期間でこうなった理由として、技術評論社の五味明子は次の3点を挙げている[157]。
- 定期的なメジャーアップデート - 3か月ごとにアップデートを繰り返し、エンタープライズからのフィードバックを反映してきたことで、本番稼働に耐えうるソフトウェアとして信頼を勝ち得た(リリース周期は2021年以降、年3回に変更されている[13])。
- Kubernetesの普及とCNCFの活性化がリンクしている - マイクロソフトがMicrosoft AzureでのKubernetesのサポートを発表して以降、オラクルやVMwareといった企業もCNCFに参加を表明し、Amazon Web Servicesも参加するなど、競合の垣根を越えて多くの企業がKubernetesへ参加したことで、コンテナオーケストレーションツールの中でのKubernetesの存在感が高まった。
- Dockerの限界 - コンテナ機能としては優秀なDockerであるが、オーケストレーション機能が十分でなく、Kubernetesをはじめとするオーケストレーションツールにより、高度な管理が出来るようになった。
2018年12月のKubeCon + CloudNativeCon North Americaの基調講演では、Kubernetesが期待に応え続ける理由として、Googleが10年以上コンテナを本番運用してきたBorgの経験に基づいていること、利用者の声を重視した改善、宣言的なAPIと自動化による自己修復、インフラを抽象化してどこでも動くこと、そして活発なコミュニティの5点が挙げられた[158]。加えて、CRI・CNI・CSIなどのインターフェースによってランタイム・ネットワーク・ストレージの実装を差し替えられる拡張性が、多様なベンダーの参加を可能にしている[8][100]。
普及の統計
CNCFは会員や利用者を対象とする年次調査を公表しており、2024年版は10回目にあたる[18]。2021年の調査でCNCFは、Kubernetesが「キャズムを越えて」主流の技術になったと評価し[159]、2023年の調査(有効回答988件)では、Kubernetesを本番環境で使う組織が66%、クラウドを利用する組織のうちKubernetesを使う予定がないのは15%にとどまった[159][18]。2024年の調査(回答750件)では本番利用が80%に上昇し、試験導入・評価中を含めると93%に達した。同調査では、CNCFの卒業プロジェクトのうちKubernetesを本番利用している回答者は85%で、Helm(77%)、Prometheus(73%)、etcd(70%)、containerd(62%)が続いた[18]。
監視SaaS事業者のDatadogは、自社顧客の利用データを集計したコンテナ利用実態の年次調査を2015年から公表している。数万組織の24億超のコンテナを対象に2023年9月時点で集計した2023年版では、Kubernetesを使う組織の過半数が水平ポッドオートスケーラー(HPA)を採用していること、Kubernetesワークロードの65%超が要求したCPU・メモリの半分未満しか使っていないこと、コンテナランタイムはcontainerdが53%と前年の23%から倍増したことが報告された[160][161][162]。同社は、この調査が自社顧客のデータに基づくことによる偏りがあり得ると注記している[161]。
日本国内については、調査会社IDC Japanが2019年に公表した調査で、コンテナを本番環境で使用している企業は9.2%にとどまる一方、コンテナを本番または検証段階で使う企業の45.5%がKubernetesを、19.8%がKubernetesを内包するRed Hat OpenShiftを使っており、同社は「Kubernetesがコンテナオーケストレーションのデファクトスタンダードになっている」と評価した[163]。2021年の同社調査では、国内企業のコンテナ本番採用率は17%、テストや検証段階は23%で、Kubernetesの利用形態ではコミュニティ版(32.0%)が最多だが、ベンダーディストリビューション(最多はRed Hat OpenShift)とクラウドのマネージドサービス(最多はAmazon EKS)の比率が高まっていた[164]。
日本での展開
Kubernetesの公式ドキュメントは日本語を含む複数の言語に翻訳されており、日本語版サイトが公開されている[165]。日本語の入門書は2018年ごろから相次いで刊行され、たとえばオーム社から『入門Kubernetes』が出版されている[3]。認定資格CKA・CKADは2018年秋から日本語での受験が可能になった[156]。
コミュニティ活動としては、定期的に勉強会を開くKubernetes Meetup Tokyo[166]や、クラウドネイティブ技術全般を扱うカンファレンスCloudNative Days[167]が続いている。CNCFの旗艦カンファレンスKubeCon + CloudNativeConは、2025年6月16日・17日に東京で日本初開催となり[168]、2026年7月には横浜で2回目が開かれた[67][169]。2026年の基調講演でCNCFは、日本のクラウドネイティブ関連の開発者を95万人と推計している[67]。
国内の利用例としては、NTTドコモが全国に展開する5Gの無線アクセスネットワークを、AWSのAmazon EKS Anywhereを用いたKubernetes基盤の上で運用すると2024年に発表した[170]。またNTTドコモビジネスは、札幌から福岡まで国内8か所のデータセンターに分散したGPUを、IOWNの光ネットワークで結んで単一のKubernetesクラスターとして運用し、KubeVirtによって複数の利用者に仮想マシンとして提供する実証基盤を構築している[171]。
関連項目
出典
- ↑ “First GitHub commit for Kubernetes”. github.com (2014年6月7日). 2017年3月1日時点のオリジナルよりアーカイブ。2018年6月5日閲覧。
- ↑ “Release 1.37.0” (2026年8月26日). 2026年8月27日閲覧。
- 1 2 “入門Kubernetes(クバネティス)”. オーム社. 2019年2月28日閲覧。
- ↑ Tenable (2017-07-20), How Do You Pronounce Kubernetes? And What Is It? 2018年5月26日閲覧。
- ↑ 阿久津良和 (2017年10月25日). “MS、KubernetesをサポートするAzure Container Serviceの改善を発表”. マイナビニュース. 2018年1月24日閲覧。
- 1 2 “What is Kubernetes?”. Kubernetes. 2017年4月1日時点のオリジナルよりアーカイブ。2017年3月31日閲覧。
- ↑ “kubernetes/kubernetes” (英語). GitHub. 2017年4月21日時点のオリジナルよりアーカイブ。2017年3月28日閲覧。
- 1 2 3 4 “概要”. Kubernetes. The Kubernetes Authors. 2026年9月6日閲覧。
- 1 2 3 “10 Years of Kubernetes” (英語). Kubernetes (2024年6月6日). 2026年9月6日閲覧。
- 1 2 新野淳一 (2015年7月23日). “Kubernetesが1.0に到達。今後は開発の主体を新団体「Cloud Native Computing Foundation」へ”. Publickey. 2026年9月6日閲覧。
- 1 2 3 Conway, Sarah. “Kubernetes Is First CNCF Project To Graduate” (html) (英語). Cloud Native Computing Foundation. 2018年10月29日時点のオリジナルよりアーカイブ。2018年12月3日閲覧。 “Compared to the 1.5 million projects on GitHub, Kubernetes is No. 9 for commits and No. 2 for authors/issues, second only to Linux.”
- 1 2 3 4 5 6 7 8 9 10 11 “Kubernetesのコンポーネント”. Kubernetes. The Kubernetes Authors. 2026年9月6日閲覧。
- 1 2 3 4 “Kubernetes Release Cadence Change: Here's What You Need To Know” (英語). Kubernetes (2021年7月20日). 2026年9月6日閲覧。
- 1 2 3 4 5 “Kubernetes v1.37: Garhwal” (英語). Kubernetes (2026年8月26日). 2026年9月6日閲覧。
- 1 2 “Google Container Engine is Generally Available” (英語). Google Cloud Platform Blog. Google (2015年8月26日). 2026年9月6日閲覧。
- 1 2 3 “Azure Kubernetes Service (AKS) GA – New regions, more features, increased productivity” (英語). Microsoft Azure Blog. Microsoft (2018年6月13日). 2026年9月6日閲覧。
- 1 2 3 4 “Amazon EKS – Now Generally Available” (英語). AWS News Blog. Amazon Web Services (2018年6月5日). 2026年9月6日閲覧。
- 1 2 3 4 5 6 7 8 9 “Cloud Native 2024: Approaching a Decade of Code, Cloud, and Change (CNCF Annual Survey 2024)” (PDF) (英語). Cloud Native Computing Foundation (2025年4月). 2026年9月6日閲覧。
- ↑ “What is the correct pronunciation of Kubernetes in English?”. kubernetes/kubernetes:Issues. GitHub. 2018年2月5日閲覧。
- ↑ “Kubernetes - New Testament Greek Lexicon - New American Standard”. New Testament Greek Lexicon. JupiterImages Co.. 2018年2月5日閲覧。
- ↑ “What is Kubernetes?”. Kubernetes. 2017年4月1日時点のオリジナルよりアーカイブ。2017年3月31日閲覧。
- 1 2 “Early Stage Startup Heptio Aims to Make Kubernetes Friendly”. 2016年12月6日閲覧.
- 1 2 Abhishek Verma; Luis Pedrosa; Madhukar R. Korupolu; David Oppenheimer; Eric Tune; John Wilkes (April 21–24, 2015). “Large-scale cluster management at Google with Borg”. Proceedings of the European Conference on Computer Systems (EuroSys). オリジナルの2017-07-27時点におけるアーカイブ。.
- 1 2 “Borg, Omega, and Kubernetes - ACM Queue”. queue.acm.org. 2016年7月9日時点のオリジナルよりアーカイブ。2016年6月27日閲覧。
- ↑ “Google Made Its Secret Blueprint Public to Boost Its Cloud” (英語). 2016年7月1日時点のオリジナルよりアーカイブ。2016年6月27日閲覧。
- ↑ “Google Open Sources Its Secret Weapon in Cloud Computing”. Wired. 2015年9月10日時点のオリジナルよりアーカイブ。2015年9月24日閲覧。
- 1 2 新野淳一 (2014年11月5日). “[速報]Google Container Engine発表。Dockerコンテナを実行しKubernetesで管理するクラウドサービス”. Publickey. 2026年9月6日閲覧。
- 1 2 3 “As Kubernetes Hits 1.0, Google Donates Technology To Newly Formed Cloud Native Computing Foundation”. TechCrunch. 2015年9月23日時点のオリジナルよりアーカイブ。2015年9月24日閲覧。
- 1 2 3 4 新野淳一 (2015年11月11日). “Kubernetes初のバージョンアップとなる「Kubernetes 1.1」リリース。性能向上、ポッド単位のオートスケール、ロードバランサー、バッチジョブ対応など”. Publickey. 2026年9月6日閲覧。
- ↑ 新野淳一 (2016年3月17日). “Kubernetesの開発主体がCloud Native Computing Foundationへ正式に移管”. Publickey. 2026年9月6日閲覧。
- 1 2 3 4 新野淳一 (2016年7月8日). “Kubernetes 1.3が登場。マルチクラウド対応、データベースのようなステートフルアプリも管理可能、ローカルテスト用にミニ版も登場”. Publickey. 2026年9月6日閲覧。
- 1 2 3 “Introducing Container Runtime Interface (CRI) in Kubernetes” (英語). Kubernetes (2016年12月19日). 2026年9月6日閲覧。
- 1 2 新野淳一 (2017年8月16日). “AWSがCloud Native Computing Foundationのプラチナメンバーとして加盟。AWSのコンテナサービスのノウハウをKubernetesに組み込むか?”. Publickey. 2026年9月6日閲覧。
- ↑ 新野淳一 (2017年10月18日). “[速報]DockerがKubernetesとの統合およびサポートを発表。DockerCon EU 2017”. Publickey. 2026年9月6日閲覧。
- 1 2 新野淳一 (2017年10月25日). “マネージドKubernetesの利用料を無料に。Kubernetes専用の新コンテナサービス「AKS」(Azure Container Service)、マイクロソフトが発表”. Publickey. 2026年9月6日閲覧。
- 1 2 新野淳一 (2017年10月23日). “Kubernetesへの正式対応を示す「Kubernetes適合認証プログラム」発表、認証Kubernetesロゴマークを表示可能に。Cloud Native Computing Foundation”. Publickey. 2026年9月6日閲覧。
- 1 2 新野淳一 (2017年11月20日). “Google Container Engineが「Google Kubernetes Engine」へ改名。略称はもちろん「GKE」のママ”. Publickey. 2026年9月6日閲覧。
- 1 2 新野淳一 (2017年11月30日). “[速報]Amazon EKS発表。Kubernetesのマネージドサービス。AWS re:Invent 2017”. Publickey. 2026年9月6日閲覧。
- 1 2 “Amazon Elastic Container Service for Kubernetes” (英語). AWS News Blog. Amazon Web Services (2017年11月29日). 2026年9月6日閲覧。
- ↑ 新野淳一 (2018年3月7日). “Kubernetesは十分成熟したソフトウェアに到達したとし、CNCFのインキュベーション段階からの卒業を発表”. Publickey. 2026年9月6日閲覧。
- ↑ 新野淳一 (2018年6月7日). “AWS上のKubernetesマネージドサービス「Amazon EKS」が正式版に”. Publickey. 2026年9月6日閲覧。
- 1 2 新野淳一 (2018年2月1日). “Red Hatがコンテナ専業ベンダのCoreOS買収を発表、コンテナプラットフォームやKubernetes関連など強化へ”. Publickey. 2026年9月6日閲覧。
- 1 2 新野淳一 (2018年11月7日). “VMware、Kubernetesのコンサルティングやトレーニングなどを提供する「Heptio」買収を発表。Kubernetesへの取り組みを強化”. Publickey. 2026年9月6日閲覧。
- 1 2 新野淳一 (2018年5月28日). “Kubernetes対応コンテナランタイム「containerd 1.1」正式リリース。CRIにネイティブ対応し、Dockerより軽量で高速な動作を実現”. Publickey. 2026年9月6日閲覧。
- 1 2 3 4 新野淳一 (2018年3月30日). “Kubernetes 1.10がリリース。コンテナストレージインターフェイスがβ版に、GPUなどをサポート可能にするデバイスプラグインも”. Publickey. 2026年9月6日閲覧。
- 1 2 3 4 新野淳一 (2018年12月7日). “Kubernetes 1.13リリース。Container Storage Interface仕様が正式版に、CoreDNSがデフォルトのDNSサーバへ”. Publickey. 2026年9月6日閲覧。
- 1 2 3 “Cloud Native Computing Foundation announces Prometheus graduation” (英語). Cloud Native Computing Foundation (2018年8月9日). 2026年9月6日閲覧。
- 1 2 “Kubernetes 1.14: Production-level support for Windows Nodes, Kubectl Updates, Persistent Local Volumes GA” (英語). Kubernetes (2019年3月25日). 2026年9月6日閲覧。
- ↑ 新野淳一 (2019年3月28日). “KubernetesがWindowsコンテナを正式サポート。サーバの内蔵ストレージを使うPersistent Local Volumesも正式版に。Kubernetes 1.14リリース”. Publickey. 2026年9月6日閲覧。
- 1 2 新野淳一 (2019年4月18日). “Kubernetesに最適化されたコンテナランタイム「CRI-O」の開発、Cloud Native Computing Foundationがホストすると発表”. Publickey. 2026年9月6日閲覧。
- 1 2 “CNCF archives the rkt project” (英語). Cloud Native Computing Foundation (2019年8月16日). 2026年9月6日閲覧。
- 1 2 “Recommendation: master → control plane (Kubernetes SIG Architecture naming recommendations 001)” (英語). GitHub. Kubernetes community. 2026年9月6日閲覧。
- 1 2 “KEP-2067: Rename the kubeadm "master" label and taint” (英語). GitHub. Kubernetes Enhancements. 2026年9月6日閲覧。
- 1 2 “Kubernetes 1.19: Accentuate the Paw-sitive” (英語). Kubernetes (2020年8月26日). 2026年9月6日閲覧。
- 1 2 3 新野淳一 (2020年9月3日). “Kubernetes 1.19正式版がリリース。Ingress APIが正式版に、サポート期間は9カ月を1年に延長”. Publickey. 2026年9月6日閲覧。
- 1 2 “Kubernetes 1.20: The Raddest Release” (英語). Kubernetes (2020年12月8日). 2026年9月6日閲覧。
- ↑ 新野淳一 (2020年12月11日). “Dockershimを非推奨とした「Kubernetes 1.20」が正式リリース。Graceful node Shutdown機能がアルファ版で登場など”. Publickey. 2026年9月6日閲覧。
- 1 2 “Don't Panic: Kubernetes and Docker” (英語). Kubernetes (2020年12月2日). 2026年9月6日閲覧。
- 1 2 “Kubernetes 1.22: Reaching New Peaks” (英語). Kubernetes (2021年8月4日). 2026年9月6日閲覧。
- 1 2 3 “Kubernetes 1.24: Stargazer” (英語). Kubernetes (2022年5月3日). 2026年9月6日閲覧。
- ↑ 新野淳一 (2022年5月10日). “ついにKubernetesからDockershimが正式に削除、Docker Engineのサポートが終了。今年最初のKuberenetes 1.24正式版がリリース”. Publickey. 2026年9月6日閲覧。
- 1 2 “Gateway API v1.0: GA Release” (英語). Kubernetes (2023年10月31日). 2026年9月6日閲覧。
- 1 2 3 “Karpenter graduates to beta” (英語). AWS Containers Blog. Amazon Web Services (2023年10月31日). 2026年9月6日閲覧。
- 1 2 3 “Kubernetes v1.34: Of Wind & Will (O' WaW)” (英語). Kubernetes (2025年8月27日). 2026年9月6日閲覧。
- 1 2 “Amazon EKS enables ultra scale AI/ML workloads with support for 100K nodes per cluster” (英語). AWS Containers Blog. Amazon Web Services (2025年7月16日). 2026年9月6日閲覧。
- 1 2 “Kubernetes v1.36: ハル (Haru)” (英語). Kubernetes (2026年4月22日). 2026年9月6日閲覧。
- 1 2 3 新野淳一 (2026年7月30日). “KubernetesはAIを動かすプラットフォームに。横浜でKubeCon+CloudNativeCon Japan 2026が開幕”. Publickey. 2026年9月6日閲覧。
- ↑ “Kubernetes v1.30: Uwubernetes” (英語). Kubernetes (2024年4月17日). 2026年9月6日閲覧。
- 1 2 “Kubernetes v1.35: Timbernetes (The World Tree Release)” (英語). Kubernetes (2025年12月17日). 2026年9月6日閲覧。
- 1 2 3 4 “Releases” (英語). Kubernetes. 2026年9月6日閲覧。
- 1 2 “Kubernetes Release Cycle” (英語). Kubernetes. 2026年9月6日閲覧。
- 1 2 “Patch Releases” (英語). Kubernetes. 2026年9月6日閲覧。
- ↑ “Version Skew Policy” (英語). Kubernetes. 2026年9月6日閲覧。
- ↑ “Autoscaling based on CPU/Memory in Kubernetes—Part II”. Powerupcloud Tech Blog. Medium (2017年4月13日). 2019年3月27日時点のオリジナルよりアーカイブ。2018年12月27日閲覧。
- ↑ “Configure Kubernetes Autoscaling With Custom Metrics”. Bitnami. BitRock (2018年11月15日). 2019年3月27日時点のオリジナルよりアーカイブ。2018年12月27日閲覧。
- 1 2 3 4 5 6 7 8 “An Introduction to Kubernetes”. DigitalOcean. 2015年10月1日時点のオリジナルよりアーカイブ。2015年9月24日閲覧。
- 1 2 3 4 “Pod”. Kubernetes. The Kubernetes Authors. 2026年9月6日閲覧。
- 1 2 3 Langemak, Jon (2015年2月11日). “Kubernetes 101 – Networking”. Das Blinken Lichten. 2015年10月25日時点のオリジナルよりアーカイブ。2015年11月2日閲覧。
- ↑ Strachan, James (2015年5月21日). “Kubernetes for Developers”. Medium (publishing platform). 2015年9月7日時点のオリジナルよりアーカイブ。2015年11月2日閲覧。
- 1 2 “Deployment”. Kubernetes. The Kubernetes Authors. 2026年9月6日閲覧。
- 1 2 3 “Overview of a Replication Controller”. Documentation. CoreOS. 2015年9月22日時点のオリジナルよりアーカイブ。2015年11月2日閲覧。
- ↑ “StatefulSet”. Kubernetes. The Kubernetes Authors. 2026年9月6日閲覧。
- 1 2 3 Sanders, Jake (2015年10月2日). “Kubernetes: Exciting Experimental Features”. Livewyer. 2015年10月20日時点のオリジナルよりアーカイブ。2015年11月2日閲覧。
- 1 2 3 4 “Service”. Kubernetes. The Kubernetes Authors. 2026年9月6日閲覧。
- ↑ Langemak, Jon (2015年2月15日). “Kubernetes 101 – External Access Into The Cluster”. Das Blinken Lichten. 2015年10月26日時点のオリジナルよりアーカイブ。2015年11月2日閲覧。
- 1 2 “Ingress”. Kubernetes. The Kubernetes Authors. 2026年9月6日閲覧。
- ↑ “Gateway API” (英語). Kubernetes. 2026年9月6日閲覧。
- 1 2 3 “永続ボリューム”. Kubernetes. The Kubernetes Authors. 2026年9月6日閲覧。
- ↑ “ConfigMap”. Kubernetes. The Kubernetes Authors. 2026年9月6日閲覧。
- 1 2 “Secret”. Kubernetes. The Kubernetes Authors. 2026年9月6日閲覧。
- 1 2 “Namespace(名前空間)”. Kubernetes. The Kubernetes Authors. 2026年9月6日閲覧。
- 1 2 “ラベル(Labels)とセレクター(Selectors)”. Kubernetes. The Kubernetes Authors. 2026年9月6日閲覧。
- 1 2 “Intro: Docker and Kubernetes training - Day 2”. Red Hat (2015年10月20日). 2015年10月29日時点のオリジナルよりアーカイブ。2015年11月2日閲覧。
- 1 2 3 4 “Kubernetes Infrastructure”. OpenShift Community Documentation. OpenShift. 2015年7月6日時点のオリジナルよりアーカイブ。2015年9月24日閲覧。
- 1 2 Marhubi, Kamal (2015年9月26日). “Kubernetes from the ground up: API server”. kamalmarhubi.com. 2015年10月29日時点のオリジナルよりアーカイブ。2015年11月2日閲覧。
- ↑ Ellingwood, Justin (2018年5月2日). “An Introduction to Kubernetes” (英語). DigitalOcean. 2018年7月5日時点のオリジナルよりアーカイブ。2018年7月20日閲覧。 “One of the most important master services is an API server. This is the main management point of the entire cluster as it allows a user to configure Kubernetes' workloads and organizational units. It is also responsible for making sure that the etcd store and the service details of deployed containers are in agreement. It acts as the bridge between various components to maintain cluster health and disseminate information and commands.”
- ↑ “The Three Pillars of Kubernetes Container Orchestration - Rancher Labs”. rancher.com (2017年5月18日). 2017年6月24日時点のオリジナルよりアーカイブ。2017年5月22日閲覧。
- ↑ Marhubi, Kamal (2015年8月27日). “What [.. is a Kubelet?]”. kamalmarhubi.com. 2015年11月13日時点のオリジナルよりアーカイブ。2015年11月2日閲覧。
- ↑ “ノード”. Kubernetes. The Kubernetes Authors. 2026年9月6日閲覧。
- 1 2 “コンテナランタイムインターフェース(CRI)”. Kubernetes. The Kubernetes Authors. 2026年9月6日閲覧。
- 1 2 “コンテナランタイム”. Kubernetes. The Kubernetes Authors. 2026年9月6日閲覧。
- ↑ 新野淳一 (2023年8月8日). “Kubernetesに最適化されたコンテナランタイム「cri-o」、十分成熟したプロジェクトとしてCNCFの卒業プロジェクトに”. Publickey. 2026年9月6日閲覧。
- 1 2 3 4 5 “アドオンのインストール”. Kubernetes. The Kubernetes Authors. 2026年9月6日閲覧。
- 1 2 “カスタムリソース”. Kubernetes. The Kubernetes Authors. 2026年9月6日閲覧。
- ↑ “オペレーターパターン”. Kubernetes. The Kubernetes Authors. 2026年9月6日閲覧。
- 1 2 新野淳一 (2020年8月24日). “「AWS Controllers for Kubernetes」(ACK)、AWSが公開。KubernetesからAWSのサービスを定義可能”. Publickey. 2026年9月6日閲覧。
- ↑ “RBAC認可を使用する”. Kubernetes. The Kubernetes Authors. 2026年9月6日閲覧。
- ↑ “Pod Security Admission” (英語). Kubernetes. 2026年9月6日閲覧。
- 1 2 3 “Autoscaling Workloads” (英語). Kubernetes. 2026年9月6日閲覧。
- ↑ “Horizontal Pod Autoscaling” (英語). Kubernetes. 2026年9月6日閲覧。
- ↑ “Node Autoscaling” (英語). Kubernetes. 2026年9月6日閲覧。
- 1 2 新野淳一 (2023年8月28日). “Kubernetes上でイベントドリブンなオートスケーリングを提供する「KEDA」、本番環境で使えるレベルに到達したとしてCNCFの卒業プロジェクトに”. Publickey. 2026年9月6日閲覧。
- 1 2 “Certified Kubernetes Software Conformance” (英語). Cloud Native Computing Foundation. 2026年9月6日閲覧。
- 1 2 新野淳一 (2021年3月2日). “Google、Kubernetesを自動運用してくれる「GKE Autopilot」正式リリース。ノードのプロビジョニング、マルチゾーン展開、スケーリングなど自動的に最適実行”. Publickey. 2026年9月6日閲覧。
- ↑ “Amazon EKS on AWS Fargate Now Generally Available” (英語). AWS News Blog. Amazon Web Services (2019年12月3日). 2026年9月6日閲覧。
- 1 2 “Streamline Kubernetes cluster management with new Amazon EKS Auto Mode” (英語). AWS News Blog. Amazon Web Services (2024年12月1日). 2026年9月6日閲覧。
- 1 2 新野淳一 (2025年10月2日). “マイクロソフト、ワンクリックで本番環境に対応したKubernetesクラスタを簡単にデプロイ、「Azure Kubernetes Service Automatic」正式リリース”. Publickey. 2026年9月6日閲覧。
- ↑ “Amazon EKS Distro: The Kubernetes Distribution Used by Amazon EKS” (英語). AWS News Blog. Amazon Web Services (2020年12月1日). 2026年9月6日閲覧。
- ↑ “Bottlerocket – Open Source OS for Container Hosting” (英語). AWS News Blog. Amazon Web Services (2020年3月10日). 2026年9月6日閲覧。
- ↑ “Amazon EKS Anywhere – Now Generally Available to Create and Manage Kubernetes Clusters on Premises” (英語). AWS News Blog. Amazon Web Services (2021年9月8日). 2026年9月6日閲覧。
- ↑ 新野淳一 (2021年9月10日). “Amazon EKS Anywhereが正式リリース。オンプレミスにAmazon EKSと同様のKubernetes環境を無料で構築可能”. Publickey. 2026年9月6日閲覧。
- ↑ 新野淳一 (2018年7月25日). “[速報]オンプレミスのKubernetesをGoogle Cloudで統合管理、「Google Kubernetes Engine on-Prem」発表。Google Cloud Next '18”. Publickey. 2026年9月6日閲覧。
- ↑ 新野淳一 (2019年4月10日). “[速報]Google、新サービス「Anthos」公開。Kubernetesをベースにオンプレミスやマルチクラウドを実現するプラットフォーム。Google Cloud Next '19”. Publickey. 2026年9月6日閲覧。
- ↑ 新野淳一 (2020年5月26日). “マイクロソフト、「 Azure Arc enabled Kubernetes」をプレビュー公開。OpenShift、Rancherなどとも統合可能に”. Publickey. 2026年9月6日閲覧。
- ↑ 新野淳一 (2015年6月26日). “DockerをコアにしたPaaS基盤ソフトウェア「OpenShift Enterprise 3」、Red Hatが正式リリース”. Publickey. 2026年9月6日閲覧。
- 1 2 新野淳一 (2019年3月1日). “Kubernetesをわずか40MBのシングルバイナリとして軽量かつシンプルにした新ディストリビューション「k3s」登場。Rancher Labsがオープンソースで公開”. Publickey. 2026年9月6日閲覧。
- ↑ 新野淳一 (2020年7月9日). “SUSEがRancher Labsの買収を発表。Rancherは引き続きマルチベンダサポートを維持”. Publickey. 2026年9月6日閲覧。
- ↑ 新野淳一 (2019年8月27日). “「VMware Tanzu」(箪笥、たんす)発表。Kubernetes対応ソフトウェアの開発支援ツールおよびサービス群。VMworld 2019 US”. Publickey. 2026年9月6日閲覧。
- ↑ 新野淳一 (2020年9月16日). “vSphereにKubernetesを統合した「vSphere with Tanzu」、VMwareが発表”. Publickey. 2026年9月6日閲覧。
- ↑ 新野淳一 (2019年11月18日). “Docker社、今後はDocker Desktopなどデベロッパー向けツールに注力。エンタープライズ向け製品群はMirantisへ売却と発表”. Publickey. 2026年9月6日閲覧。
- 1 2 新野淳一 (2020年11月17日). “軽量でインストールも簡単なシングルバイナリのKubernetesディストリビューション「k0s」、Mirantisがオープンソースでリリース。LinuxとWindowsに対応”. Publickey. 2026年9月6日閲覧。
- ↑ 新野淳一 (2018年7月27日). “Docker for Win/MacのKubernetes統合が正式版に。Stable Channelでリリース開始”. Publickey. 2026年9月6日閲覧。
- ↑ “Cloud Native Computing Foundation Announces Helm Graduation” (英語). Cloud Native Computing Foundation (2020年4月30日). 2026年9月6日閲覧。
- ↑ “Declarative Management of Kubernetes Objects Using Kustomize” (英語). Kubernetes. 2026年9月6日閲覧。
- ↑ “The Cloud Native Computing Foundation Announces Argo has Graduated” (英語). Cloud Native Computing Foundation (2022年12月6日). 2026年9月6日閲覧。
- ↑ “Cloud Native Computing Foundation Announces Linkerd Graduation” (英語). Cloud Native Computing Foundation (2021年7月28日). 2026年9月6日閲覧。
- ↑ “Cloud Native Computing Foundation Reaffirms Istio Maturity with Project Graduation” (英語). Cloud Native Computing Foundation (2023年7月12日). 2026年9月6日閲覧。
- ↑ “Cloud Native Computing Foundation Announces OpenTelemetry's Graduation, Solidifying Status as the De Facto Observability Standard” (英語). Cloud Native Computing Foundation (2026年5月21日). 2026年9月6日閲覧。
- ↑ “Datadog Named a Leader in the 2026 Gartner Magic Quadrant For Observability Platforms For Sixth Consecutive Year” (英語). Datadog (2026年7月15日). 2026年9月6日閲覧。
- ↑ “Dynatrace Named a Leader in the 2026 Gartner Magic Quadrant for Observability Platforms for the 16th Time” (英語). Dynatrace (2026年7月15日). 2026年9月6日閲覧。
- ↑ “New Relic Named a Leader in 2025 Gartner Magic Quadrant for Observability Platforms for the 13th Consecutive Time” (英語). New Relic (2025年7月10日). 2026年9月6日閲覧。
- ↑ “Splunk、ガートナー社による2025年オブザーバビリティプラットフォーム部門のマジック・クアドラントでリーダーの1社と評価”. Splunk (2025年8月18日). 2026年9月6日閲覧。
- ↑ “Grafana Labs、「2026年版 Gartner Magic Quadrant For Observability Platforms」でリーダーに選出”. PR TIMES (2026年7月29日). 2026年9月6日閲覧。
- ↑ Charly Fontaine (2018年10月18日). “Introducing the Datadog Cluster Agent” (英語). Datadog. 2026年9月6日閲覧。
- ↑ 新野淳一 (2021年12月2日). “Googleが「Knative」をCloud Native Computing Foundationに寄贈。Kubernetes上でサーバレス基盤を構築するソフトウェア”. Publickey. 2026年9月6日閲覧。
- ↑ 新野淳一 (2025年10月17日). “Kubernetes上にサーバレス基盤を構築できる「Knative」が十分成熟した段階になったとして、CNCFの卒業プロジェクトに”. Publickey. 2026年9月6日閲覧。
- ↑ 新野淳一 (2020年4月8日). “Kubernetes上でサーバレス環境を実現する「KEDA」がCNCFのプロジェクトに採用。サーバレスの標準化は進むか”. Publickey. 2026年9月6日閲覧。
- ↑ 新野淳一 (2023年7月14日). “「KubeVirt 1.0」正式リリース。Kubernetesで仮想マシンもコンテナも管理可能に”. Publickey. 2026年9月6日閲覧。
- ↑ 新野淳一 (2024年3月29日). “WebAssemblyによるサーバレスをKubernetes上で実現する「SpinKube」、CNCFへの寄贈を発表”. Publickey. 2026年9月6日閲覧。
- ↑ 新野淳一 (2020年3月4日). “「Kubeflow 1.0」正式版リリース。あらゆるKubernetes上にJupyter notebookなど機械学習の開発、トレーニング、デプロイ機能を構築”. Publickey. 2026年9月6日閲覧。
- ↑ “Cloud Native Certifications” (英語). Cloud Native Computing Foundation. 2026年9月6日閲覧。
- ↑ “Certified Kubernetes Administrator (CKA)” (英語). The Linux Foundation. 2026年9月6日閲覧。
- ↑ “Certified Kubernetes Application Developer (CKAD)” (英語). The Linux Foundation. 2026年9月6日閲覧。
- ↑ “Certified Kubernetes Security Specialist (CKS)” (英語). The Linux Foundation. 2026年9月6日閲覧。
- ↑ “Kubernetes and Cloud Native Associate (KCNA)” (英語). The Linux Foundation. 2026年9月6日閲覧。
- 1 2 新野淳一 (2018年6月21日). “国内でCNCF公認の「認定Kubernetes管理者」「認定Kubernetesアプリケーションデベロッパー」試験が今秋開始、日本語でトレーニングと受験が可能。クリエーションライン”. Publickey. 2026年9月6日閲覧。
- ↑ 五味明子 (2018年1月5日). ““コンテナネイティブ”の時代が本格到来 ―2018年のクラウドはKubernetesとGoogleに注目”. 技術評論社. 2018年1月24日閲覧。
- ↑ 新野淳一 (2018年12月17日). “Kubernetesが注目され続ける5つの理由。 KubeCon + CloudNativeCon North America 2018”. Publickey. 2026年9月6日閲覧。
- 1 2 “CNCF Annual Survey 2023” (英語). Cloud Native Computing Foundation (2024年4月9日). 2026年9月6日閲覧。
- ↑ “10 insights on real-world container use” (英語). Datadog (2023年11月2日). 2026年9月6日閲覧。
- 1 2 高橋正和 (2023年12月21日). “Datadog、10個の“気付き”をまとめたコンテナ利用実態調査レポート 2023年版を解説”. クラウド Watch(インプレス). 2026年9月6日閲覧。
- ↑ 日川佳三 (2023年12月21日). “コンテナの主用途はDBMSとWebサーバー、開発言語はNode.jsが最多─Datadog調査”. IT Leaders(インプレス). 2026年9月6日閲覧。
- ↑ 新野淳一 (2019年7月9日). “国内でDockerコンテナを本番利用しているのは9.2%。コンテナオーケストレーションツールはKubernetesがデファクト。IDC Japanの調査結果”. Publickey. 2026年9月6日閲覧。
- ↑ 新野淳一 (2021年4月22日). “国内企業はコンテナ型仮想化の本格的な普及期に。本番環境での採用率は17%、テストや検証段階は23%、合計40%以上が導入へ。IDC Japan”. Publickey. 2026年9月6日閲覧。
- ↑ “Kubernetes”. Kubernetes. The Kubernetes Authors. 2026年9月6日閲覧。
- ↑ “Kubernetes Meetup Tokyo”. connpass. 2026年9月6日閲覧。
- ↑ “CloudNative Days”. 2026年9月6日閲覧。
- ↑ “KubeCon + CloudNativeCon Japan 2025” (英語). The Linux Foundation. 2026年9月6日閲覧。
- ↑ “KubeCon + CloudNativeCon Japan” (英語). The Linux Foundation. 2026年9月6日閲覧。
- ↑ 新野淳一 (2024年2月27日). “NTTドコモ、全国展開する5Gの無線アクセスネットワークをAWSの「Amazon Elastic Kubernetes Service Anywhere」を用いて展開すると発表”. Publickey. 2026年9月6日閲覧。
- ↑ “NTT Docomo Business: Beyond the DC Walls: How NTT Docomo Business United 8 Data Centers Across 2,000 km into One GPU Cluster with KubeVirt” (英語). Cloud Native Computing Foundation (2026年7月30日). 2026年9月6日閲覧。
外部リンク
Kubernetes
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2021/03/19 02:38 UTC 版)
「Cloud Native Computing Foundation」の記事における「Kubernetes」の解説
Kubernetesはコンテナ化されたアプリケーションをクラスター環境で自動デプロイ・自動管理するオープンソースのフレームワークである。「Kubernetesは、さまざまなインフラストラクチャに関連する分散型のコンポーネントを管理するためのよりよい方法を提供することを目的としている。」 もともとGoogleで設計され、Cloud Native Computing Foundationを立ち上げるためのシード技術としてLinux Foundationに寄贈された。プロジェクトを支援する「大規模で多様性のある」コミュニティが、同様の目的を持った他の技術や古い技術よりも頑強な持続力をもたらしたと考えられている。2020年1月、CNCFはKubernetesに関連する関心、トレーニング、イベントへの参加、投資の大幅な成長を示す年次レポートを発表した。
※この「Kubernetes」の解説は、「Cloud Native Computing Foundation」の解説の一部です。
「Kubernetes」を含む「Cloud Native Computing Foundation」の記事については、「Cloud Native Computing Foundation」の概要を参照ください。
- kubernetesのページへのリンク