Wikipedia

Kubernetes

サーバークラスタ上でコンテナを管理するソフトウェア

Kubernetes（クバネティス[2]/クバネテス/クーべネティス[3][4]、K8sと略記される[5]）は、コンテナ化したアプリケーションのデプロイ、スケーリング、および管理を行うための、オープンソースのコンテナオーケストレーションシステムである[6]。元々Googleが設計したシステムであるが、現在はCloud Native Computing Foundationがメンテナンスを行っている。

Kubernetes
作者 Google
開発元 Cloud Native Computing Foundation
初版 2014年6月7日 (10年前) (2014-06-07)[1]
リポジトリ https://github.com/kubernetes/kubernetes
プログラミング
言語		 Go
サポート状況 開発中
種別 クラスター管理ソフトウェア・コンテナオーケストレーション
ライセンス Apache License 2.0
公式サイト kubernetes.io
テンプレートを表示

ホストのクラスターを横断してアプリケーションコンテナを自動デプロイ、スケーリング、操作するためのプラットフォームを提供することが目的とされている[5]。Google Kubernetes Engineをはじめ、多数のパブリッククラウドサービスプロバイダがKubernetesベースのPaaSやIaaSを提供しており、プラットフォーム提供サービスとしてKubernetesをデプロイすることができる。また、多くのソフトウェアベンダーも、ブランド化したKubernetesディストリビューションを提供している。

歴史

編集
 
Google Cloud SummitでのGoogle Container Engineに関するトーク

“Kubernetes”（希: κυβερνήτης、koo-ber-nay'-tace[7][8]、クベルネテス）は、ギリシャ語で航海長または水先案内人を意味し、サイバネティクス（人工頭脳学）の語源でもある[9]。Kubernetesは、当初Joe Beda、Brendan Burns、Craig McLuckieの3人によって開発が始まり[10]、すぐにBrian GrantやTim Hockinなど、他のGoogleのエンジニアも参加するようになり、2014年中ごろにGoogleから初めて発表された[11]。Kubernetesの開発や設計はGoogleのBorgシステムから強い影響を受けており[12][13]、Borgのトップコントリビュータの多くが開発に参加している。Google内でのKubernetesのもともとのコードネームはProject Sevenであり、スター・トレックのキャラクターで、優しいBorgである、セブン・オブ・ナインの名前に由来する[14]。Kubernetesのロゴの輪にある7つのスポークは、このコードネームに由来している。

Kubernetes v1.0は2015年7月21日にリリースされた[15]。Kubernetes v1.0のリリースと同時に、GoogleはLinux Foundationと共同でCloud Native Computing Foundation（CNCF）を設立し、Kubernetesを種となる技術として提供した。2018年3月6日には、KubernetesプロジェクトはGitHubにおけるコミット数で第9位に到達し、コントリビューター数とissue数では、Linuxカーネルプロジェクトに次いで第2位となった[16]。

コンセプト

編集

Kubernetesは、いくつかのビルディングブロック（"primitives"）を定義している。このビルディングブロックのおかげで、アプリケーションのデプロイ、メンテナンス、スケールのメカニズムを、CPU、メモリ[17]、あるいはカスタムの指標[18]に基づいて正しく提供することが可能になっている。Kubernetesは、さまざまなワークロードに対応できるよう、疎結合かつ拡張可能なシステムとなっている。この拡張性の大部分は、Kubernete上で動作する拡張機能やコンテナだけでなく内部コンポーネントによっても使用されているKubernetes APIにより提供されている[19]。Kubernetesでは、コンピューティングとストレージのリソースを制御するため、リソースを以下のような「オブジェクト」として定義している。

ポッド

編集

Kubernetesでは、スケジューリングの基本となる単位は、ポッドである[20]。コンテナ化されたコンポーネントをポッドとしてグループ化することで、1つ高いレベルの抽象化を与えている。1つのポッドは1つ以上のコンテナから構成され、同じポッドのコンテナは同じホストマシンにデプロイされるため、リソースの共有が保証される[19]。

Kubernetes内の各ポッドには、クラスタ内でユニークなPod IPアドレスが割り当てられる。これにより、アプリケーションはポートの衝突の危険を考える必要がない[21]。ポッド内では、すべてのコンテナがlocalhost上で互いに参照できる。しかし、あるポッド内のコンテナが、他のポッド内の他のコンテナを直接アドレスで参照する方法は存在せず、そのためには、必ずPod IPアドレスを利用しなければならない。しかし、アプリケーションの開発者はPod IP アドレスを決して使用するべきではない。なぜなら、他のポッドの機能にアクセスあるいは実行する時に利用するPod IPアドレスは一時的なものであり、参照しようとしている特定のポッドが再起動したりすると、そのPod IPアドレスは別のポッドに割り当てられてしまう可能性があるからである。その代りに、開発者は、特定のPod IPアドレスを持つ対象ポッドへのアクセスが可能な、サービスに対してアクセスしなければならない。

1つのポッドは、ローカルディスクのディレクトリあるいはネットワークディスクとして、1つのボリュームを定義し、ポッド内のコンテナに対して公開することができる[22]。ポッドの管理は、Kubernetes APIで手動で行ったり、コントローラに管理を委譲したりすることができる[19]。また、定義したボリュームは、ConfigMaps（設定の内容を、コンテナからファイルシステム上で参照可能にする機能）やSecrets（リモートのリソースに安全にアクセスするために必要な証明書を、認証されたコンテナのみでファイルシステム上で参照可能にする機能）など、Kubernetesのいくつかの機能の基礎となっている。

サービス

編集
 
Kubernetesクラスタ内で、サービスがPodネットワークと通信する方法を簡略的に表した図

Kubernetesサービスはいくつかのポッドの集まりであり、1ティアまたはマルチティアのアプリケーションと協調して動作する。サービスを構成する複数のポッドは、ラベルセレクターを用いて定義される[19]。Kubernetesはサービスディスカバリーの手段として、環境変数を用いるモードと、Kubernetes DNSを用いるモードの2種類の方法を提供している[23]。サービスディスカバリは、静的なIPアドレスとDNS名を各サービスに束縛させ、そのIPアドレスのネットワークコネクションに対して、セレクターにマッチしたポッド間でラウンドロビン方式でのロードバランシングを行う（セレクターを用いるのは、障害によりポッドがあるマシンから別のマシンに移動したとしても動作するようにするためである）[21]。デフォルトでは、サービスはクラスタの内部にのみ公開されている（たとえば、バックエンド用のポッドは、ロードバランシングされた複数のフロントエンド用ポッドからのリクエストに対して、1つのサービスとしてグループ化されているかもしれない）が、サービスはクラスターの外部に公開することもできる（たとえば、外部のクライアントがフロントエンド用ポッドにアクセスする場合など）[24]。

ボリューム

編集

Kubernetesコンテナ内のファイルシステムは、デフォルトでは一時ストレージを提供する。つまり、コンテナを再起動すると内部のデータが削除されてしまうため、重要なアプリケーションで利用するには制限がある。Kubernetesボリュームは永続的なストレージを提供するため、コンテナが再起動しても、ポッドが生存している間はデータが削除されない。このストレージは、同じポッド内のコンテナ同士で共有ディスク空間としても利用可能である。ボリュームは、ポッドの設定ファイル上で定義したコンテナ内の特定のマウントポイントとしてマウントされ、それ以外のボリュームにマウントしたり、他のボリュームとリンクすることができないようになっている。ただし、同じボリュームでも、異なるコンテナであれば、ファイルシステムツリー上の別の場所にマウントすることは可能である。

ネームスペース

編集

Kubernetesは、リソースのパーティショニング機能を提供し、ネームスペース（名前空間）と呼ばれる重複のない部分に分割する。多数のチームやプロジェクトに渡る多数のユーザーの利用を想定している。これにより、開発、テスト、本番などの環境さえ完全に分離することができる。

オブジェクトの管理

編集

Kubernetesは、オブジェクトの管理、選択、操作を可能にするメカニズムを提供している。

ラベルとセレクター

編集

Kubernetesは、ポッドやノードなどのシステム上のあらゆるAPIオブジェクトに対して、クライアント（ユーザーや内部のコンポーネント）が「ラベル」と呼ばれるキーバリューペアを付加できるようにしている。それに対応して、「ラベルセレクター」はラベルに対してクエリーを実行し、一致するオブジェクトに解決する[19]。あるサービスを定義すると、サービスルーターやロードバランサーがトラフィックをルーティングするポッドインスタンスを選択するために使用する、ラベルセレクターを定義できるようになる。したがって、単にポッドのラベルやサービスのラベルセレクターを変更するだけで、どのポッドにトラフィックを送るかを制御することが可能になる。この方法により、ブルー・グリーンデプロイ（英語版）やABテストなど、さまざまなデプロイパタンを利用できる。このようなサービスが使用するリソースを動的にコントロールする機能のおかげで、インフラ内での疎結合が実現されている。

たとえば、あるアプリケーションのpodsがシステムtier（たとえば、front-end、back-endなどの値を持つ）とrelease_track（canaryやproductionなど）というラベルを持つとき、back-endかつcanaryであるノード全てを指定するには、以下のようなラベルセレクターが使える[25]。

tier=back-end AND release_track=canary

フィールドセレクター

編集

ラベルと同様に、フィールドセレクターもKubernetesの任意のリソースを選択可能にするものである。ラベルとは異なり、選択は、ユーザーが定義したカテゴリではなく、リソースに予め付与される属性の値に基づいて行われる。metadata.nameやmetadata.namespaceは、すべてのKubernetesオブジェクトに存在するフィールドセレクターである。使用される他のセレクターは、オブジェクトやリソースのタイプによって異なる。

アーキテクチャ

編集
 
Kubernetesのアーキテクチャ図

Kubernetesは、マスター・スレーブアーキテクチャで構成される。Kubernetesのコンポーネントは、各ノードを管理するノード（node）と、コントロールプレーンであるマスター（master）の2つに分けられる[26][27]。

マスターがクラスターの管理を行い、コンテナ（実際にはPodと呼ばれる単位で管理される）は各ノード上にデプロイされる。マスターやノードを構成するコンポーネントは下記のようになっている[28]。

コントロールプレーン（マスター）

編集

Kubernetesのマスターは、クラスターのメインとなるコントロールユニットである。ワークロードとシステム全体に渡る直接的な通信を管理する。Kubernetesコントロールプレーンは複数のさまざまなコンポーネントから構成されている。各コンポーネントは独立したプロセスとして実行され、1つのマスターノードでも、高可用クラスタ（英語版）をサポートするために複数のマスターノードで実行することも可能である[29]。各種コンポーネントには、次のようなものがある。

etcd

編集

etcdは、CoreOS（英語版）により開発された、永続的な軽量な分散キーバリューストアである。クラスタの設定データを確実に保存し、任意の時点でのクラスタ全体の状態を保存する。Apache ZooKeeperと同様、etcdは、ネットワーク部分のイベントにおいて、可用性（Availability）よりも一貫性（Consistency）を重視するシステムである（CAP定理を参照）。この一貫性は、正しいスケジューリングとサービスのオペレーションにとって非常に重要である。Kubernetes APIサーバーは、etcdのwatch APIを用いて、クラスターや重要な設定の変更を監視したり、クラスタの状態にデプロイ時に宣言された状態との齟齬が生じた時、宣言された状態になるように修復する。一例として、もしデプロイ時に特定のポッドのインスタンス3つが実行している必要があると指定すると、この情報はetcdに保存される。もし、実行中のインスタンスが2つしか見つからなかった場合、この違いがetcdのデータと比較され、Kubernetesはこの情報を用いて、追加のポッドインスタンスを作成するスケジュールを立てる[29]。

API server

編集

API serverはキーとなるコンポーネントであり、HTTP上のJSONを利用したKubernetes APIのサーバーである。Kubernetesに対する内部および外部向けのインターフェイスの両方を提供する[30][31]。API serverはRESTリクエストの処理と検証を行い、etcd（英語版）に保存されたAPIオブジェクトの状態を更新する。したがって、Kubernetes APIを利用することで、クライアントはワーカーノード全体に渡るワークロードとコンテナの設定を行うことが可能になる[32]。

スケジューラー

編集

schedulerはプラガブルなコンポーネントで、未スケジュールのポッド（schedulerが管理する基本エンティティ）をどのノードで実行するのかを、リソースの可用性に基づいて選択する役割を担う。schedulerは各ノード上でのリソースの使用量をトラッキングし、ワークロードが利用可能なリソースを超過しないことを保証する。この目的を達成するためには、schedulerは、リソースの要求量、リソースの可用性、その他のユーザーが提供する制約、そして、サービス品質、親和性・非親和性の要件、データの局所性などのポリシーのディレクティブを知っている必要がある。本質的には、schedulerの役割は、リソースの「供給」をワークロードの「需要」に合わせることであると言える[33]。

コントローラーマネージャー

編集

controllerは、実際のクラスタの状態を期待されるクラスタの状態と一致するように駆動するループである[34]。これは、ポッド群を管理することで行われる。コントローラの1つには、replication controller（レプリケーションコントローラー）がある。このコントローラーは、ポッドのレプリカ数をクラスタ全体で指定した数になるようにレプリケーションとスケーリングを操作する。また、管理しているノードに障害が発生した場合には、代替のポッドの生成の操作も実行する[34]。Kubernetesシステムの一部である他のコントローラの1つには、DaemonSet Controller（デーモンセットコントローラー）がある。これは、1台のマシンでポッドが必ず1つのみ実行されるようにする。Job Controller（ジョブコントローラー）は、たとえばバッチジョブの一部として、ポッドをジョブが完了するまで実行させる[35]。コントローラーが管理するポッド群は、コントローラーの定義の一部である、ラベルセレクターを利用して特定する[36]。

Controller manager（コントローラーマネージャー）は、DaemonSet ControllerやReplication ControllerなどのKubernetesのコアとなるコントローラーを実行するプロセスである。コントローラーは、APIサーバーと通信することで、管理対象のリソース（ポッド、サービスエンドポイントなど）の作成、更新、削除を実行する[31]。

ノード（スレーブ）

編集

ノード（ワーカーまたはMinionとも呼ばれる）は、コンテナ（ワークロード）が実際にデプロイされるマシンである。クラスタ内のすべてのノードはDockerなどのコンテナランタイムを実行する必要があり、コンテナのネットワーク設定のためにマスターと通信を行う、以下に説明するようなコンポーネントも実行する。

Kubelet

編集

Kubeletは、各ノードの実行状態に対する責務を担い、ノード内のすべてのコンテナが健全な状態であることを保証する。コントロールプレーンの指示を受けて、アプリケーションコンテナ群をスタート、ストップ、管理し、ポッドとして組織する[30][37]。

Kubeletはポッドの状態を監視し、指定された状態から逸脱していることを検出すると、ポッドを同じノードに自動的に再デプロイする。ノードの状態は数秒ごとにハートビートメッセージとしてマスターに送信される。マスターがノードの障害を検知するとすぐに、Replication Controllerがこの状態を確認し、他の健全な状態にあるノードでポッドを新たに起動する[要出典]。

コンテナ

編集

containerはポッドの中に置かれる。containerは最も低レベルなマイクロサービスであり、実行中のアプリケーション、ライブラリ、およびその依存関係が格納される。containerは外部IPアドレスを割り当てて世界に対して公開することもできる。Kubernetesは最初のバージョン以来Dockerコンテナをサポートしており、2016年7月には、rktコンテナエンジンが追加された[38]。

Kube-proxy

編集

Kube-proxyはネットワークプロキシおよびロードバランサーの実装であり、サービスの抽象化やその他のネットワーク操作をサポートする[30]。トラフィックのルーティングを、受信したリクエストのIPアドレスとポート番号を元に、適切なコンテナにルーティングする責務を担う。

cAdvisor

編集

cAdvisorは、各ノード上にあるコンテナのCPU、メモリ、ファイル、ネットワーク使用量といった、リソースの使用量と性能の指標を監視・収集するエージェントである。

アドオン

編集

アドオンは、クラスタ内で他のアプリケーションと同じ方法で実行される。すなわち、同じようにポッドとサービスとして実装されるが、Kubernetesクラスタの機能を実装しているという点に違いがある。ポッド群は、DeploymentsやReplicationControllersなどによって管理されることもある。多数のアドオンが存在し、その数は増え続けている。以下に、重要なアドオンの種類の一部を挙げる。

  • DNS: すべてのKubernetesクラスタはクラスタDNSを保つ必要があり、これは必須の機能となっている。クラスタDNSはDNSサーバーの一種で、自分の環境内にある他のDNSサーバーに加えて、KubernetesサービスのDNSレコードを保持する。Kubernetesが起動したコンテナには、DNSの検索対象サーバーとして、このDNSサーバーが自動的に追加される。
  • ウェブUI: これは一般の目的に使用されるKubernetesクラスタに対するウェブベースのUIである。クラスタ上で実行中のアプリケーションやクラスタ自体の管理やトラブルシューティングに利用できる。
  • コンテナのリソースモニター: 信頼性の高いアプリケーションランタイムを提供し、ワークロードに応じてスケールアップ・ダウンを可能にするためには、継続的かつ実際的なワークロード性能のモニタリングが必要とされる。コンテナのリソースモニターを使用すれば、中央のデータベースにコンテナのメトリクスを記録することができ、また、このデータを閲覧するためのUIも提供される。cAdvisorは、スレーブノード上のコンポーネントの1つであり、一部の指標の計測機能はすでに提供している。完全な指標パイプラインを提供するものとしては、Prometheusなどがあり、これを利用することで、ほとんどのモニタリング要求が満たされる。
  • クラスタレベルでのロギング: ログは独立したストレージに格納され、ノード・ポッド・コンテナとは異なる独立のライフサイクルを持つ。そうでなければ、ノードやポッドの障害によりイベントデータが失われてしまう可能性がある。こうした機能はクラスタレベルロギングと呼ばれ、コンテナのログを中央のログストアに格納し、検索・閲覧インターフェイスを提供する責務を持つ。Kubernetes自体がログデータを保存するネイティブのストレージ手段を提供しているが、多数存在する既存のログサービスをKubernetesクラスタに統合するためのアドオンも存在する。

マイクロサービス

編集

Kubernetesはマイクロサービスをベースとしたアプリケーションの実装方法としてよく使用されている。というのも、Kubernetesとその周辺ツールによるエコシステムは、マイクロサービスアーキテクチャが重視している重要な概念に必要な機能のすべてを提供しているためである。これに関して詳しくは、マイクロサービスの項目を参照。

普及の理由

編集

2018年初頭の時点で、Kubernetesはコンテナオーケストレーションにおいてデファクトスタンダードと呼べる存在になっているが、短期間でこうなった理由には、以下の3点が挙げられる[39]。

  • 定期的なメジャーアップデート
    3ヵ月ごとにアップデートを繰り返し、エンタープライズからのフィードバックを反映しており、本番稼働に耐えうるソフトウェアとして信頼を勝ち得た。
  • Kubernetesの普及とCNCFの活性化がリンクしている
    マイクロソフトがMicrosoft AzureでのKubernetesのサポートを発表して以降、オラクルやVMwareといった企業もCNCFに参加を表明し、Amazon Web Servicesも参加するなど、競合の垣根を越えて多くの企業がKubernetesへ参加したことで、コンテナオーケストレーションツールの中でのKubernetesの存在感が高まった。
  • Dockerの限界
    コンテナ機能としては優秀なDockerであるが、オーケストレーション機能が十分でなく、Kubernetesをはじめとするオーケストレーションツールにより、高度な管理が出来るようになった。

関連項目

編集

出典

編集
[脚注の使い方]
  1. ^ “First GitHub commit for Kubernetes”. github.com (2014年6月7日). 2017年3月1日時点のオリジナルよりアーカイブ。2018年6月5日閲覧。
  2. ^ “入門Kubernetes（クバネティス）”. オーム社. 2019年2月28日閲覧。
  3. ^ Tenable (2017-07-20), How Do You Pronounce Kubernetes? And What Is It?, https://www.youtube.com/watch?v=uMA7qqXIXBk 2018年5月26日閲覧。 
  4. ^ 阿久津良和 (2017年10月25日). “MS、KubernetesをサポートするAzure Container Serviceの改善を発表”. マイナビニュース. 2018年1月24日閲覧。
  5. ^ a b “What is Kubernetes?”. Kubernetes. 2017年3月31日閲覧。
  6. ^ “kubernetes/kubernetes” (英語). GitHub. 2017年4月21日時点のオリジナルよりアーカイブ。2017年3月28日閲覧。
  7. ^ “What is the correct pronunciation of Kubernetes in English?”. kubernetes/kubernetes:Issues. GitHub. 2018年2月5日閲覧。
  8. ^ “Kubernetes - New Testament Greek Lexicon - New American Standard”. New Testament Greek Lexicon. JupiterImages Co.. 2018年2月5日閲覧。
  9. ^ “What is Kubernetes?”. Kubernetes. 2017年3月31日閲覧。
  10. ^ “Google Made Its Secret Blueprint Public to Boost Its Cloud” (英語). 2016年7月1日時点のオリジナルよりアーカイブ。2016年6月27日閲覧。
  11. ^ “Google Open Sources Its Secret Weapon in Cloud Computing”. Wired. 10 September 2015時点のオリジナルよりアーカイブ。24 September 2015閲覧。
  12. ^ 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時点におけるアーカイブ。. https://research.google.com/pubs/pub43438.html. 
  13. ^ “Borg, Omega, and Kubernetes - ACM Queue”. queue.acm.org. 2016年7月9日時点のオリジナルよりアーカイブ。2016年6月27日閲覧。
  14. ^ “Early Stage Startup Heptio Aims to Make Kubernetes Friendly”. http://www.eweek.com/cloud/early-stage-startup-heptio-aims-to-make-kubernetes-friendly.html 2016年12月6日閲覧。 
  15. ^ “As Kubernetes Hits 1.0, Google Donates Technology To Newly Formed Cloud Native Computing Foundation”. TechCrunch. 23 September 2015時点のオリジナルよりアーカイブ。24 September 2015閲覧。
  16. ^ Conway, Sarah. “Kubernetes Is First CNCF Project To Graduate” (html) (英語). Cloud Native Computing Foundation. 29 October 2018時点のオリジナルよりアーカイブ。3 December 2018閲覧。 “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.”
  17. ^ “Autoscaling based on CPU/Memory in Kubernetes—Part II”. Powerupcloud Tech Blog. Medium (13 April 2017). 27 December 2018閲覧。
  18. ^ “Configure Kubernetes Autoscaling With Custom Metrics”. Bitnami. BitRock (15 November 2018). 27 December 2018閲覧。
  19. ^ a b c d e “An Introduction to Kubernetes”. DigitalOcean. 1 October 2015時点のオリジナルよりアーカイブ。24 September 2015閲覧。
  20. ^ https://kubernetes.io/docs/concepts/workloads/pods/pod/
  21. ^ a b Langemak, Jon (2015年2月11日). “Kubernetes 101 – Networking”. Das Blinken Lichten. 2015年10月25日時点のオリジナルよりアーカイブ。2015年11月2日閲覧。
  22. ^ Strachan, James (2015年5月21日). “Kubernetes for Developers”. Medium (publishing platform). 2015年9月7日時点のオリジナルよりアーカイブ。2015年11月2日閲覧。
  23. ^ https://kubernetes.io/docs/concepts/services-networking/service/#discovering-services
  24. ^ Langemak, Jon (2015年2月15日). “Kubernetes 101 – External Access Into The Cluster”. Das Blinken Lichten. 2015年10月26日時点のオリジナルよりアーカイブ。2015年11月2日閲覧。
  25. ^ “Intro: Docker and Kubernetes training - Day 2”. Red Hat (2015年10月20日). 2015年10月29日時点のオリジナルよりアーカイブ。2015年11月2日閲覧。
  26. ^ “An Introduction to Kubernetes”. DigitalOcean. 1 October 2015時点のオリジナルよりアーカイブ。24 September 2015閲覧。
  27. ^ “Kubernetes Infrastructure”. OpenShift Community Documentation. OpenShift. 6 July 2015時点のオリジナルよりアーカイブ。24 September 2015閲覧。
  28. ^ “Kubernetes Components”. Documentation - Concepts. kubernetes.io. 2018年2月5日閲覧。
  29. ^ a b “Kubernetes Infrastructure”. OpenShift Community Documentation. OpenShift. 6 July 2015時点のオリジナルよりアーカイブ。24 September 2015閲覧。
  30. ^ a b c “An Introduction to Kubernetes”. DigitalOcean. 1 October 2015時点のオリジナルよりアーカイブ。24 September 2015閲覧。
  31. ^ a b Marhubi, Kamal (2015年9月26日). “Kubernetes from the ground up: API server”. kamalmarhubi.com. 2015年10月29日時点のオリジナルよりアーカイブ。2015年11月2日閲覧。
  32. ^ Ellingwood, Justin (2 May 2018). “An Introduction to Kubernetes” (英語). DigitalOcean. 5 July 2018時点のオリジナルよりアーカイブ。20 July 2018閲覧。 “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.”
  33. ^ “The Three Pillars of Kubernetes Container Orchestration - Rancher Labs”. rancher.com (18 May 2017). 24 June 2017時点のオリジナルよりアーカイブ。22 May 2017閲覧。
  34. ^ a b “Overview of a Replication Controller”. Documentation. CoreOS. 2015年9月22日時点のオリジナルよりアーカイブ。2015年11月2日閲覧。
  35. ^ Sanders, Jake (2015年10月2日). “Kubernetes: Exciting Experimental Features”. Livewyer. 2015年10月20日時点のオリジナルよりアーカイブ。2015年11月2日閲覧。
  36. ^ “Intro: Docker and Kubernetes training - Day 2”. Red Hat (2015年10月20日). 2015年10月29日時点のオリジナルよりアーカイブ。2015年11月2日閲覧。
  37. ^ Marhubi, Kamal (2015年8月27日). “What [.. is a Kubelet?]”. kamalmarhubi.com. 2015年11月13日時点のオリジナルよりアーカイブ。2015年11月2日閲覧。
  38. ^ https://kubernetes.io/blog/2016/07/rktnetes-brings-rkt-container-engine-to-kubernetes/
  39. ^ 五味明子 (2018年1月5日). ““コンテナネイティブ”の時代が本格到来 ―2018年のクラウドはKubernetesとGoogleに注目”. 技術評論社. 2018年1月24日閲覧。

外部リンク

編集
「https://ja.wiki.x.io/w/index.php?title=Kubernetes&oldid=101682200」から取得