「Kubernetes」の版間の差分
→歴史: 誤訳の修正: パイロット → 水先案内人。日本語音:クベルネテス。+サイバネティックス |
|||
(14人の利用者による、間の19版が非表示) | |||
13行目: | 13行目: | ||
| プログラミング言語 = [[Go (プログラミング言語)|Go]] |
| プログラミング言語 = [[Go (プログラミング言語)|Go]] |
||
| 対応OS = |
| 対応OS = |
||
| エンジン = |
| エンジン = |
||
| 対応プラットフォーム = |
| 対応プラットフォーム = |
||
| サイズ = |
| サイズ = |
||
22行目: | 22行目: | ||
| 公式サイト = [https://kubernetes.io/ kubernetes.io] |
| 公式サイト = [https://kubernetes.io/ kubernetes.io] |
||
}} |
}} |
||
'''Kubernetes'''('''クバネティス<ref>{{Cite web |
'''Kubernetes'''('''クバネティス<ref>{{Cite web|和書|url=https://www.ohmsha.co.jp/book/9784873118406/ |title=入門Kubernetes(クバネティス) |accessdate=2019-02-28 |publisher=[[オーム社]]}}</ref>/クバネテス/クーべネティス<ref>{{Citation|title=How Do You Pronounce Kubernetes? And What Is It?|last=Tenable|date=2017-07-20|url=https://www.youtube.com/watch?v=uMA7qqXIXBk|accessdate=2018-05-26}}</ref>{{R|阿久津}}'''、'''K8s'''と[[ヌメロニム|略記]]される<ref name=":2">{{Cite web|url=https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/|title=What is Kubernetes?|access-date=2017-03-31|website=Kubernetes}}</ref>)は、コンテナ化したアプリケーションの[[ソフトウェアデプロイメント|デプロイ]]、スケーリング、および管理を行うための、[[オープンソース]]のコンテナ[[オーケストレーション (コンピュータ)|オーケストレーション]]システムである<ref>{{Cite web|url=https://github.com/kubernetes/kubernetes/|title=kubernetes/kubernetes|access-date=2017-03-28|website=GitHub|language=en|archiveurl=https://web.archive.org/web/20170421035413/https://github.com/kubernetes/kubernetes|archivedate=2017-04-21|deadurl=no|df=}}</ref>。元々[[Google]]が設計したシステムであるが、現在は[[Cloud Native Computing Foundation]]がメンテナンスを行っている。Kubernetesの目的は、「ホストの[[コンピュータ・クラスター|クラスター]]を横断してアプリケーションコンテナを自動デプロイ、スケーリング、操作するためのプラットフォーム」を提供することとされている<ref name=":2" />。Google自身が提供する[[Google Cloud Platform|Google Kubernetes Engine]]をはじめ、多数のパブリック[[クラウドコンピューティング|クラウドサービス]]プロバイダがKubernetesベースの[[Platform as a Service|PaaS]]や[[Infrastructure as a Service|IaaS]]を提供しており、プラットフォーム提供サービスとしてKubernetesをデプロイすることができる。また、多くのソフトウェアベンダーも、ブランド化したKubernetesディストリビューションを提供している。 |
||
== 歴史 == |
== 歴史 == |
||
[[File: |
[[File:Kubernetes talk at Google Cloud Summit.jpg|リンク=[[:en:File:Kubernetes talk at Google Cloud Summit.jpg]]|サムネイル|Google Cloud SummitでのGoogle Container Engineに関するトーク]]“Kubernetes”({{lang-el-short|[[wiktionary:κυβερνήτης|κυβερνήτης]]}}、koo-ber-nay'-tace<ref name="Pronounce by repository master">{{Cite web|url=https://github.com/kubernetes/kubernetes/issues/44308#issuecomment-293331817|title=What is the correct pronunciation of Kubernetes in English?|accessdate=2018-02-05|work=kubernetes/kubernetes:Issues|publisher=[[GitHub]]}}</ref><ref name="Pronounce as Greek word">{{Cite web|url=https://www.biblestudytools.com/lexicons/greek/nas/kubernetes.html|title=Kubernetes - New Testament Greek Lexicon - New American Standard|accessdate=2018-02-05|work=New Testament Greek Lexicon|publisher=JupiterImages Co.}}</ref>、クベル'''ネ'''テス)は、ギリシャ語で[[航海士|航海長]]または[[水先案内人]]を意味し、[[サイバネティックス|サイバネティクス]](人工頭脳学)の語源でもある<ref name=":22">{{Cite web|url=https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/|title=What is Kubernetes?|access-date=2017-03-31|website=Kubernetes}}</ref>。Kubernetesは、当初Joe Beda、Brendan Burns、Craig McLuckieの3人によって開発が始まり<ref>{{Cite web|url=https://www.wired.com/2015/06/google-kubernetes-says-future-cloud-computing/|title=Google Made Its Secret Blueprint Public to Boost Its Cloud|access-date=2016-06-27|language=en-US|archiveurl=https://web.archive.org/web/20160701040235/http://www.wired.com/2015/06/google-kubernetes-says-future-cloud-computing/|archivedate=2016-07-01|deadurl=no|df=}}</ref>、すぐにBrian GrantやTim Hockinなど、他のGoogleのエンジニアも参加するようになり、2014年中ごろにGoogleから初めて発表された<ref>{{cite web|url=https://www.wired.com/2014/06/google-kubernetes/|title=Google Open Sources Its Secret Weapon in Cloud Computing|accessdate=24 September 2015|website=Wired|archiveurl=https://web.archive.org/web/20150910171929/http://www.wired.com/2014/06/google-kubernetes|archivedate=10 September 2015|deadurl=no|df=}}</ref>。Kubernetesの開発や設計はGoogleのBorgシステムから強い影響を受けており<ref>{{cite journal|date=April 21–24, 2015|title=Large-scale cluster management at Google with Borg|url=https://research.google.com/pubs/pub43438.html|journal=Proceedings of the European Conference on Computer Systems (EuroSys)|author1=Abhishek Verma|author2=Luis Pedrosa|author3=Madhukar R. Korupolu|author4=David Oppenheimer|author5=Eric Tune|author6=John Wilkes|deadurl=no|archiveurl=https://web.archive.org/web/20170727090712/https://research.google.com/pubs/pub43438.html|archivedate=2017-07-27|df=}}</ref><ref>{{Cite web|url=http://queue.acm.org/detail.cfm?id=2898444|title=Borg, Omega, and Kubernetes - ACM Queue|access-date=2016-06-27|website=queue.acm.org|archiveurl=https://web.archive.org/web/20160709023750/http://queue.acm.org/detail.cfm?id=2898444|archivedate=2016-07-09|deadurl=no|df=}}</ref>、Borgのトップコントリビュータの多くが開発に参加している。Google内でのKubernetesのもともとのコードネームはProject [[セブン・オブ・ナイン|Seven]]であり、[[スタートレック|スター・トレック]]のキャラクターで、優しい[[ボーグ|Borg]]である、[[セブン・オブ・ナイン]]の名前に由来する<ref>{{Cite news|title=Early Stage Startup Heptio Aims to Make Kubernetes Friendly|url=http://www.eweek.com/cloud/early-stage-startup-heptio-aims-to-make-kubernetes-friendly.html|access-date=2016-12-06}}</ref>。Kubernetesのロゴの輪にある7つのスポークは、このコードネームに由来している。 |
||
Kubernetes v1.0は2015年7月21日にリリースされた<ref>{{cite web|url=https://techcrunch.com/2015/07/21/as-kubernetes-hits-1-0-google-donates-technology-to-newly-formed-cloud-native-computing-foundation-with-ibm-intel-twitter-and-others/|title=As Kubernetes Hits 1.0, Google Donates Technology To Newly Formed Cloud Native Computing Foundation|accessdate=24 September 2015|website=TechCrunch|archiveurl=https://web.archive.org/web/20150923060338/http://techcrunch.com/2015/07/21/as-kubernetes-hits-1-0-google-donates-technology-to-newly-formed-cloud-native-computing-foundation-with-ibm-intel-twitter-and-others/|archivedate=23 September 2015|deadurl=no|df=}}</ref>。Kubernetes v1.0のリリースと同時に、Googleは[[:en:Linux_Foundation|Linux Foundation]]と共同で[[:en:Linux_Foundation#Cloud_Native_Computing_Foundation|Cloud Native Computing Foundation]](CNCF)を設立し、Kubernetesを種となる技術として提供した。2018年3月6日には、KubernetesプロジェクトはGitHubにおけるコミット数で第9位に到達し、コントリビューター数とissue数では、[[Linuxカーネル]]プロジェクトに次いで第2位となった<ref>{{cite web|url=https://www.cncf.io/blog/2018/03/06/kubernetes-first-cncf-project-graduate/|title=Kubernetes Is First CNCF Project To Graduate|access-date=3 December 2018|last=Conway|first=Sarah|format=html|website=[[Cloud Native Computing Foundation]]|quote=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.|language=en|deadurl=no|archive-url=https://web.archive.org/web/20181029081848/https://www.cncf.io/blog/2018/03/06/kubernetes-first-cncf-project-graduate/|archive-date=29 October 2018}}</ref>。 |
Kubernetes v1.0は2015年7月21日にリリースされた<ref>{{cite web|url=https://techcrunch.com/2015/07/21/as-kubernetes-hits-1-0-google-donates-technology-to-newly-formed-cloud-native-computing-foundation-with-ibm-intel-twitter-and-others/|title=As Kubernetes Hits 1.0, Google Donates Technology To Newly Formed Cloud Native Computing Foundation|accessdate=24 September 2015|website=TechCrunch|archiveurl=https://web.archive.org/web/20150923060338/http://techcrunch.com/2015/07/21/as-kubernetes-hits-1-0-google-donates-technology-to-newly-formed-cloud-native-computing-foundation-with-ibm-intel-twitter-and-others/|archivedate=23 September 2015|deadurl=no|df=}}</ref>。Kubernetes v1.0のリリースと同時に、Googleは[[:en:Linux_Foundation|Linux Foundation]]と共同で[[:en:Linux_Foundation#Cloud_Native_Computing_Foundation|Cloud Native Computing Foundation]](CNCF)を設立し、Kubernetesを種となる技術として提供した。2018年3月6日には、KubernetesプロジェクトはGitHubにおけるコミット数で第9位に到達し、コントリビューター数とissue数では、[[Linuxカーネル]]プロジェクトに次いで第2位となった<ref>{{cite web|url=https://www.cncf.io/blog/2018/03/06/kubernetes-first-cncf-project-graduate/|title=Kubernetes Is First CNCF Project To Graduate|access-date=3 December 2018|last=Conway|first=Sarah|format=html|website=[[Cloud Native Computing Foundation]]|quote=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.|language=en|deadurl=no|archive-url=https://web.archive.org/web/20181029081848/https://www.cncf.io/blog/2018/03/06/kubernetes-first-cncf-project-graduate/|archive-date=29 October 2018}}</ref>。 |
||
== コンセプト == |
|||
== Kubernetesにおけるオブジェクト == |
|||
Kubernetesは、いくつかのビルディングブロック("primitives")を定義している。このビルディングブロックのおかげで、アプリケーションのデプロイ、メンテナンス、スケールのメカニズムを、CPU、メモリ<ref>{{cite web|url=https://blog.powerupcloud.com/autoscaling-based-on-cpu-memory-in-kubernetes-part-ii-fe2e495bddd4|title=Autoscaling based on CPU/Memory in Kubernetes—Part II|accessdate=27 December 2018|date=13 April 2017|website=Powerupcloud Tech Blog|publisher=Medium|last1=Sharma|first1=Priyanka}}</ref>、あるいはカスタムの指標<ref>{{cite web|url=https://docs.bitnami.com/kubernetes/how-to/configure-autoscaling-custom-metrics/|title=Configure Kubernetes Autoscaling With Custom Metrics|accessdate=27 December 2018|date=15 November 2018|website=Bitnami|publisher=BitRock}}</ref>に基づいて正しく提供することが可能になっている。Kubernetesは、さまざまなワークロードに対応できるよう、[[疎結合]]かつ拡張可能なシステムとなっている。この拡張性の大部分は、Kubernete上で動作する拡張機能やコンテナだけでなく内部コンポーネントによっても使用されているKubernetes APIにより提供されている<ref name="do-intro2">{{cite web|url=https://www.digitalocean.com/community/tutorials/an-introduction-to-kubernetes|title=An Introduction to Kubernetes|accessdate=24 September 2015|website=DigitalOcean|archiveurl=https://web.archive.org/web/20151001183617/https://www.digitalocean.com/community/tutorials/an-introduction-to-kubernetes|archivedate=1 October 2015|deadurl=no|df=}}</ref>。Kubernetesでは、コンピューティングとストレージのリソースを制御するため、リソースを以下のような「オブジェクト」として定義している。 |
Kubernetesは、いくつかのビルディングブロック("primitives")を定義している。このビルディングブロックのおかげで、アプリケーションのデプロイ、メンテナンス、スケールのメカニズムを、CPU、メモリ<ref>{{cite web|url=https://blog.powerupcloud.com/autoscaling-based-on-cpu-memory-in-kubernetes-part-ii-fe2e495bddd4|title=Autoscaling based on CPU/Memory in Kubernetes—Part II|accessdate=27 December 2018|date=13 April 2017|website=Powerupcloud Tech Blog|publisher=Medium|last1=Sharma|first1=Priyanka}}</ref>、あるいはカスタムの指標<ref>{{cite web|url=https://docs.bitnami.com/kubernetes/how-to/configure-autoscaling-custom-metrics/|title=Configure Kubernetes Autoscaling With Custom Metrics|accessdate=27 December 2018|date=15 November 2018|website=Bitnami|publisher=BitRock}}</ref>に基づいて正しく提供することが可能になっている。Kubernetesは、さまざまなワークロードに対応できるよう、[[疎結合]]かつ拡張可能なシステムとなっている。この拡張性の大部分は、Kubernete上で動作する拡張機能やコンテナだけでなく内部コンポーネントによっても使用されているKubernetes APIにより提供されている<ref name="do-intro2">{{cite web|url=https://www.digitalocean.com/community/tutorials/an-introduction-to-kubernetes|title=An Introduction to Kubernetes|accessdate=24 September 2015|website=DigitalOcean|archiveurl=https://web.archive.org/web/20151001183617/https://www.digitalocean.com/community/tutorials/an-introduction-to-kubernetes|archivedate=1 October 2015|deadurl=no|df=}}</ref>。Kubernetesでは、コンピューティングとストレージのリソースを制御するため、リソースを以下のような「オブジェクト」として定義している。 |
||
=== ポッド |
=== ポッド === |
||
Kubernetesでは、スケジューリングの基本となる単位は、'''ポッド'''である<ref>https://kubernetes.io/docs/concepts/workloads/pods/pod/</ref>。コンテナ化されたコンポーネントをポッドとしてグループ化することで、1つ高いレベルの抽象化を与えている。1つのポッドは1つ以上のコンテナから構成され、同じポッドのコンテナは同じホストマシンにデプロイされるため、リソースの共有が保証される<ref name="do-intro2" />。 |
Kubernetesでは、スケジューリングの基本となる単位は、'''ポッド'''である<ref>https://kubernetes.io/docs/concepts/workloads/pods/pod/</ref>。コンテナ化されたコンポーネントをポッドとしてグループ化することで、1つ高いレベルの抽象化を与えている。1つのポッドは1つ以上のコンテナから構成され、同じポッドのコンテナは同じホストマシンにデプロイされるため、リソースの共有が保証される<ref name="do-intro2" />。 |
||
39行目: | 39行目: | ||
1つのポッドは、ローカルディスクのディレクトリあるいはネットワークディスクとして、1つのボリュームを定義し、ポッド内のコンテナに対して公開することができる<ref name="kubernetes-for-developers">{{cite web|url=https://medium.com/fabric8-io/kubernetes-for-developers-2a9c7202fcd3#.b6u76jxar|title=Kubernetes for Developers|accessdate=2015-11-02|last=Strachan|first=James|date=2015-05-21|work=[[Medium (publishing platform)]]|archiveurl=https://web.archive.org/web/20150907030556/https://medium.com/fabric8-io/kubernetes-for-developers-2a9c7202fcd3#.b6u76jxar|archivedate=2015-09-07|deadurl=no|df=}}</ref>。ポッドの管理は、Kubernetes [[Application Programming Interface|API]]で手動で行ったり、コントローラに管理を委譲したりすることができる<ref name="do-intro2" />。また、定義したボリュームは、ConfigMaps(設定の内容を、コンテナからファイルシステム上で参照可能にする機能)やSecrets(リモートのリソースに安全にアクセスするために必要な証明書を、認証されたコンテナのみでファイルシステム上で参照可能にする機能)など、Kubernetesのいくつかの機能の基礎となっている。 |
1つのポッドは、ローカルディスクのディレクトリあるいはネットワークディスクとして、1つのボリュームを定義し、ポッド内のコンテナに対して公開することができる<ref name="kubernetes-for-developers">{{cite web|url=https://medium.com/fabric8-io/kubernetes-for-developers-2a9c7202fcd3#.b6u76jxar|title=Kubernetes for Developers|accessdate=2015-11-02|last=Strachan|first=James|date=2015-05-21|work=[[Medium (publishing platform)]]|archiveurl=https://web.archive.org/web/20150907030556/https://medium.com/fabric8-io/kubernetes-for-developers-2a9c7202fcd3#.b6u76jxar|archivedate=2015-09-07|deadurl=no|df=}}</ref>。ポッドの管理は、Kubernetes [[Application Programming Interface|API]]で手動で行ったり、コントローラに管理を委譲したりすることができる<ref name="do-intro2" />。また、定義したボリュームは、ConfigMaps(設定の内容を、コンテナからファイルシステム上で参照可能にする機能)やSecrets(リモートのリソースに安全にアクセスするために必要な証明書を、認証されたコンテナのみでファイルシステム上で参照可能にする機能)など、Kubernetesのいくつかの機能の基礎となっている。 |
||
=== サービス |
=== サービス === |
||
[[File:Pod-networking.png|サムネイル|700x700ピクセル|Kubernetesクラスタ内で、サービスがPodネットワークと通信する方法を簡略的に表した図]] |
[[File:Pod-networking.png|サムネイル|700x700ピクセル|Kubernetesクラスタ内で、サービスがPodネットワークと通信する方法を簡略的に表した図]] |
||
Kubernetesサービスはいくつかのポッドの集まりであり、1ティアまたは[[多層アーキテクチャ|マルチティア]]のアプリケーションと協調して動作する。サービスを構成する複数のポッドは、ラベルセレクターを用いて定義される<ref name="do-intro2" />。Kubernetesは{{仮リンク|サービスディスカバリー|en|Service_discovery}}の手段として、環境変数を用いるモードと、Kubernetes DNSを用いるモードの2種類の方法を提供している<ref>https://kubernetes.io/docs/concepts/services-networking/service/#discovering-services</ref>。サービスディスカバリは、静的なIPアドレスと[[Domain Name System|DNS名]]を各サービスに束縛させ、そのIPアドレスのネットワークコネクションに対して、セレクターにマッチしたポッド間で[[DNSラウンドロビン|ラウンドロビン]]方式でのロードバランシングを行う(セレクターを用いるのは、障害によりポッドがあるマシンから別のマシンに移動したとしても動作するようにするためである)<ref name="kubernetes-101-networking" />。デフォルトでは、サービスはクラスタの内部にのみ公開されている(たとえば、[[フロントエンド|バックエンド]]用のポッドは、ロードバランシングされた複数のフロントエンド用ポッドからのリクエストに対して、1つのサービスとしてグループ化されているかもしれない)が、サービスはクラスターの外部に公開することもできる(たとえば、外部のクライアントがフロントエンド用ポッドにアクセスする場合など)<ref name="kubernetes-101-external-access">{{cite web|url=http://www.dasblinkenlichten.com/kubernetes-101-external-access-into-the-cluster/|title=Kubernetes 101 – External Access Into The Cluster|accessdate=2015-11-02|last=Langemak|first=Jon|date=2015-02-15|work=Das Blinken Lichten|archiveurl=https://web.archive.org/web/20151026035212/http://www.dasblinkenlichten.com/kubernetes-101-external-access-into-the-cluster/|archivedate=2015-10-26|deadurl=no|df=}}</ref>。 |
Kubernetesサービスはいくつかのポッドの集まりであり、1ティアまたは[[多層アーキテクチャ|マルチティア]]のアプリケーションと協調して動作する。サービスを構成する複数のポッドは、ラベルセレクターを用いて定義される<ref name="do-intro2" />。Kubernetesは{{仮リンク|サービスディスカバリー|en|Service_discovery}}の手段として、環境変数を用いるモードと、Kubernetes DNSを用いるモードの2種類の方法を提供している<ref>https://kubernetes.io/docs/concepts/services-networking/service/#discovering-services</ref>。サービスディスカバリは、静的なIPアドレスと[[Domain Name System|DNS名]]を各サービスに束縛させ、そのIPアドレスのネットワークコネクションに対して、セレクターにマッチしたポッド間で[[DNSラウンドロビン|ラウンドロビン]]方式でのロードバランシングを行う(セレクターを用いるのは、障害によりポッドがあるマシンから別のマシンに移動したとしても動作するようにするためである)<ref name="kubernetes-101-networking" />。デフォルトでは、サービスはクラスタの内部にのみ公開されている(たとえば、[[フロントエンド|バックエンド]]用のポッドは、ロードバランシングされた複数のフロントエンド用ポッドからのリクエストに対して、1つのサービスとしてグループ化されているかもしれない)が、サービスはクラスターの外部に公開することもできる(たとえば、外部のクライアントがフロントエンド用ポッドにアクセスする場合など)<ref name="kubernetes-101-external-access">{{cite web|url=http://www.dasblinkenlichten.com/kubernetes-101-external-access-into-the-cluster/|title=Kubernetes 101 – External Access Into The Cluster|accessdate=2015-11-02|last=Langemak|first=Jon|date=2015-02-15|work=Das Blinken Lichten|archiveurl=https://web.archive.org/web/20151026035212/http://www.dasblinkenlichten.com/kubernetes-101-external-access-into-the-cluster/|archivedate=2015-10-26|deadurl=no|df=}}</ref>。 |
||
=== ボリューム |
=== ボリューム === |
||
Kubernetesコンテナ内のファイルシステムは、デフォルトでは一時ストレージを提供する。つまり、コンテナを再起動すると内部のデータが削除されてしまうため、重要なアプリケーションで利用するには制限がある。 |
Kubernetesコンテナ内のファイルシステムは、デフォルトでは一時ストレージを提供する。つまり、コンテナを再起動すると内部のデータが削除されてしまうため、重要なアプリケーションで利用するには制限がある。Kubernetesボリュームは永続的なストレージを提供するため、コンテナが再起動しても、ポッドが生存している間はデータが削除されない。このストレージは、同じポッド内のコンテナ同士で共有ディスク空間としても利用可能である。ボリュームは、ポッドの設定ファイル上で定義したコンテナ内の特定のマウントポイントとしてマウントされ、それ以外のボリュームにマウントしたり、他のボリュームとリンクすることができないようになっている。ただし、同じボリュームでも、異なるコンテナであれば、ファイルシステムツリー上の別の場所にマウントすることは可能である。 |
||
=== ネームスペース |
=== ネームスペース === |
||
Kubernetesは、リソースのパーティショニング機能を提供し、ネームスペース(名前空間)と呼ばれる重複のない部分に分割する。多数のチームやプロジェクトに渡る多数のユーザーの利用を想定している。これにより、開発、テスト、本番などの環境さえ完全に分離することができる。 |
Kubernetesは、リソースのパーティショニング機能を提供し、ネームスペース(名前空間)と呼ばれる重複のない部分に分割する。多数のチームやプロジェクトに渡る多数のユーザーの利用を想定している。これにより、開発、テスト、本番などの環境さえ完全に分離することができる。 |
||
== |
== オブジェクトの管理 == |
||
Kubernetesは、オブジェクトの管理、選択、操作を可能にするメカニズムを提供している。 |
Kubernetesは、オブジェクトの管理、選択、操作を可能にするメカニズムを提供している。 |
||
=== ラベルとセレクター |
=== ラベルとセレクター === |
||
Kubernetesは、ポッドや[[Kubernetes#Kubernetesノード(スレーブ)|ノード]]などのシステム上のあらゆるAPIオブジェクトに対して、クライアント(ユーザーや内部のコンポーネント)が「ラベル」と呼ばれるキーバリューペアを付加できるようにしている。それに対応して、「ラベルセレクター」はラベルに対してクエリーを実行し、一致するオブジェクトに解決する<ref name="do-intro2" />。あるサービスを定義すると、サービスルーターやロードバランサーがトラフィックをルーティングするポッドインスタンスを選択するために使用する、ラベルセレクターを定義できるようになる。したがって、単にポッドのラベルやサービスのラベルセレクターを変更するだけで、どのポッドにトラフィックを送るかを制御することが可能になる。この方法により、{{仮リンク|ブルー・グリーンデプロイ|en|blue-green deployments}}や[[A/Bテスト|ABテスト]]など、さまざまなデプロイパタンを利用できる。このようなサービスが使用するリソースを動的にコントロールする機能のおかげで、インフラ内での疎結合が実現されている。 |
Kubernetesは、ポッドや[[Kubernetes#Kubernetesノード(スレーブ)|ノード]]などのシステム上のあらゆるAPIオブジェクトに対して、クライアント(ユーザーや内部のコンポーネント)が「ラベル」と呼ばれるキーバリューペアを付加できるようにしている。それに対応して、「ラベルセレクター」はラベルに対してクエリーを実行し、一致するオブジェクトに解決する<ref name="do-intro2" />。あるサービスを定義すると、サービスルーターやロードバランサーがトラフィックをルーティングするポッドインスタンスを選択するために使用する、ラベルセレクターを定義できるようになる。したがって、単にポッドのラベルやサービスのラベルセレクターを変更するだけで、どのポッドにトラフィックを送るかを制御することが可能になる。この方法により、{{仮リンク|ブルー・グリーンデプロイ|en|blue-green deployments}}や[[A/Bテスト|ABテスト]]など、さまざまなデプロイパタンを利用できる。このようなサービスが使用するリソースを動的にコントロールする機能のおかげで、インフラ内での疎結合が実現されている。 |
||
たとえば、あるアプリケーションのpodsがシステム<code>tier</code>(たとえば、<code>front-end</code>、<code>back-end</code>などの値を持つ)と<code>release_track</code>(<code>[[:en:Feature_toggle#Canary_release|canary]]</code>や<code>production</code>など)というラベルを持つとき、<code>back-end</code>かつ<code>canary</code>であるノード全てを指定するには、以下のようなラベルセレクターが使える<ref name="redhat-docker-and-kubernetes-training-labels-examples">{{cite web|url=http://christianposta.com/slides/docker/generated/day2.html#/label-examples|title=Intro: Docker and Kubernetes training - Day 2|accessdate=2015-11-02|date=2015-10-20|publisher=[[Red Hat]]|archiveurl=https://web.archive.org/web/20151029210659/http://christianposta.com/slides/docker/generated/day2.html#/label-examples|archivedate=2015-10-29|deadurl=no|df=}}</ref>。<blockquote><code>tier=back-end AND release_track=canary</code></blockquote> |
たとえば、あるアプリケーションのpodsがシステム<code>tier</code>(たとえば、<code>front-end</code>、<code>back-end</code>などの値を持つ)と<code>release_track</code>(<code>[[:en:Feature_toggle#Canary_release|canary]]</code>や<code>production</code>など)というラベルを持つとき、<code>back-end</code>かつ<code>canary</code>であるノード全てを指定するには、以下のようなラベルセレクターが使える<ref name="redhat-docker-and-kubernetes-training-labels-examples">{{cite web|url=http://christianposta.com/slides/docker/generated/day2.html#/label-examples|title=Intro: Docker and Kubernetes training - Day 2|accessdate=2015-11-02|date=2015-10-20|publisher=[[Red Hat]]|archiveurl=https://web.archive.org/web/20151029210659/http://christianposta.com/slides/docker/generated/day2.html#/label-examples|archivedate=2015-10-29|deadurl=no|df=}}</ref>。<blockquote><code>tier=back-end AND release_track=canary</code></blockquote> |
||
=== フィールドセレクター |
=== フィールドセレクター === |
||
ラベルと同様に、フィールドセレクターもKubernetesの任意のリソースを選択可能にするものである。ラベルとは異なり、選択は、ユーザーが定義したカテゴリではなく、リソースに予め付与される属性の値に基づいて行われる。<code>metadata.name</code>や<code>metadata.namespace</code>は、すべてのKubernetesオブジェクトに存在するフィールドセレクターである。使用される他のセレクターは、オブジェクトやリソースのタイプによって異なる。 |
ラベルと同様に、フィールドセレクターもKubernetesの任意のリソースを選択可能にするものである。ラベルとは異なり、選択は、ユーザーが定義したカテゴリではなく、リソースに予め付与される属性の値に基づいて行われる。<code>metadata.name</code>や<code>metadata.namespace</code>は、すべてのKubernetesオブジェクトに存在するフィールドセレクターである。使用される他のセレクターは、オブジェクトやリソースのタイプによって異なる。 |
||
72行目: | 72行目: | ||
}}</ref>。 |
}}</ref>。 |
||
=== |
=== コントロールプレーン(マスター) === |
||
Kubernetesのマスターは、クラスターのメインとなるコントロールユニットである。ワークロードとシステム全体に渡る直接的な通信を管理する。Kubernetesコントロールプレーンは複数のさまざまなコンポーネントから構成されている。各コンポーネントは独立したプロセスとして実行され、1つのマスターノードでも、{{仮リンク|高可用クラスタ|en|High-availability cluster}}をサポートするために複数のマスターノードで実行することも可能である<ref name=":02">{{cite web|url=https://docs.openshift.org/latest/architecture/infrastructure_components/kubernetes_infrastructure.html|title=Kubernetes Infrastructure|accessdate=24 September 2015|website=OpenShift Community Documentation|publisher=OpenShift|archiveurl=https://web.archive.org/web/20150706121423/https://docs.openshift.org/latest/architecture/infrastructure_components/kubernetes_infrastructure.html|archivedate=6 July 2015|deadurl=no|df=}}</ref>。各種コンポーネントには、次のようなものがある。 |
Kubernetesのマスターは、クラスターのメインとなるコントロールユニットである。ワークロードとシステム全体に渡る直接的な通信を管理する。Kubernetesコントロールプレーンは複数のさまざまなコンポーネントから構成されている。各コンポーネントは独立したプロセスとして実行され、1つのマスターノードでも、{{仮リンク|高可用クラスタ|en|High-availability cluster}}をサポートするために複数のマスターノードで実行することも可能である<ref name=":02">{{cite web|url=https://docs.openshift.org/latest/architecture/infrastructure_components/kubernetes_infrastructure.html|title=Kubernetes Infrastructure|accessdate=24 September 2015|website=OpenShift Community Documentation|publisher=OpenShift|archiveurl=https://web.archive.org/web/20150706121423/https://docs.openshift.org/latest/architecture/infrastructure_components/kubernetes_infrastructure.html|archivedate=6 July 2015|deadurl=no|df=}}</ref>。各種コンポーネントには、次のようなものがある。 |
||
==== etcd ==== |
==== etcd ==== |
||
'''etcd''' |
'''etcd'''は、{{仮リンク|Container Linux by CoreOS|en|Container Linux by CoreOS|label=CoreOS}}により開発された、永続的な軽量な分散キーバリューストアである。クラスタの設定データを確実に保存し、任意の時点でのクラスタ全体の状態を保存する。[[Apache ZooKeeper]]と同様、etcdは、ネットワーク部分のイベントにおいて、可用性(Availability)よりも一貫性(Consistency)を重視するシステムである([[CAP定理]]を参照)。この一貫性は、正しいスケジューリングとサービスのオペレーションにとって非常に重要である。Kubernetes APIサーバーは、etcdのwatch APIを用いて、クラスターや重要な設定の変更を監視したり、クラスタの状態にデプロイ時に宣言された状態との齟齬が生じた時、宣言された状態になるように修復する。一例として、もしデプロイ時に特定のポッドのインスタンス3つが実行している必要があると指定すると、この情報はetcdに保存される。もし、実行中のインスタンスが2つしか見つからなかった場合、この違いがetcdのデータと比較され、Kubernetesはこの情報を用いて、追加のポッドインスタンスを作成するスケジュールを立てる<ref name=":02" />。 |
||
==== API server ==== |
==== API server ==== |
||
API serverはキーとなるコンポーネントであり、[[Hypertext Transfer Protocol|HTTP]]上の[[JSON]]を利用したKubernetes [[Application Programming Interface|API]]のサーバーである。Kubernetesに対する内部および外部向けのインターフェイスの両方を提供する<ref name="do-intro3">{{cite web|url=https://www.digitalocean.com/community/tutorials/an-introduction-to-kubernetes|title=An Introduction to Kubernetes|accessdate=24 September 2015|website=DigitalOcean|archiveurl=https://web.archive.org/web/20151001183617/https://www.digitalocean.com/community/tutorials/an-introduction-to-kubernetes|archivedate=1 October 2015|deadurl=no|df=}}</ref><ref name=":1">{{Cite web|url=http://kamalmarhubi.com/blog/2015/09/06/kubernetes-from-the-ground-up-the-api-server/|title=Kubernetes from the ground up: API server|access-date=2015-11-02|last=Marhubi|first=Kamal|date=2015-09-26|website=|publisher=kamalmarhubi.com|archiveurl=https://web.archive.org/web/20151029131948/http://kamalmarhubi.com/blog/2015/09/06/kubernetes-from-the-ground-up-the-api-server/|archivedate=2015-10-29|deadurl=no|df=}}</ref>。API serverは[[Representational State Transfer|REST]]リクエストの処理と検証を行い、{{仮リンク|etcd|en|etcd}}に保存されたAPIオブジェクトの状態を更新する。したがって、Kubernetes APIを利用することで、クライアントはワーカーノード全体に渡るワークロードとコンテナの設定を行うことが可能になる<ref>{{cite web|url=https://www.digitalocean.com/community/tutorials/an-introduction-to-kubernetes|title=An Introduction to Kubernetes|access-date=20 July 2018|last=Ellingwood|first=Justin|date=2 May 2018|website=[[DigitalOcean]]|quote=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.|language=en|archive-url=https://web.archive.org/web/20180705232851/https://www.digitalocean.com/community/tutorials/an-introduction-to-kubernetes|archive-date=5 July 2018}}</ref>。 |
API serverはキーとなるコンポーネントであり、[[Hypertext Transfer Protocol|HTTP]]上の[[JSON]]を利用したKubernetes [[Application Programming Interface|API]]のサーバーである。Kubernetesに対する内部および外部向けのインターフェイスの両方を提供する<ref name="do-intro3">{{cite web|url=https://www.digitalocean.com/community/tutorials/an-introduction-to-kubernetes|title=An Introduction to Kubernetes|accessdate=24 September 2015|website=DigitalOcean|archiveurl=https://web.archive.org/web/20151001183617/https://www.digitalocean.com/community/tutorials/an-introduction-to-kubernetes|archivedate=1 October 2015|deadurl=no|df=}}</ref><ref name=":1">{{Cite web|url=http://kamalmarhubi.com/blog/2015/09/06/kubernetes-from-the-ground-up-the-api-server/|title=Kubernetes from the ground up: API server|access-date=2015-11-02|last=Marhubi|first=Kamal|date=2015-09-26|website=|publisher=kamalmarhubi.com|archiveurl=https://web.archive.org/web/20151029131948/http://kamalmarhubi.com/blog/2015/09/06/kubernetes-from-the-ground-up-the-api-server/|archivedate=2015-10-29|deadurl=no|df=}}</ref>。API serverは[[Representational State Transfer|REST]]リクエストの処理と検証を行い、{{仮リンク|etcd|en|etcd}}に保存されたAPIオブジェクトの状態を更新する。したがって、Kubernetes APIを利用することで、クライアントはワーカーノード全体に渡るワークロードとコンテナの設定を行うことが可能になる<ref>{{cite web|url=https://www.digitalocean.com/community/tutorials/an-introduction-to-kubernetes|title=An Introduction to Kubernetes|access-date=20 July 2018|last=Ellingwood|first=Justin|date=2 May 2018|website=[[DigitalOcean]]|quote=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.|language=en|archive-url=https://web.archive.org/web/20180705232851/https://www.digitalocean.com/community/tutorials/an-introduction-to-kubernetes|archive-date=5 July 2018}}</ref>。 |
||
==== |
==== スケジューラー ==== |
||
schedulerはプラガブルなコンポーネントで、未スケジュールのポッド(schedulerが管理する基本エンティティ)をどのノードで実行するのかを、リソースの可用性に基づいて選択する役割を担う。schedulerは各ノード上でのリソースの使用量をトラッキングし、ワークロードが利用可能なリソースを超過しないことを保証する。この目的を達成するためには、schedulerは、リソースの要求量、リソースの可用性、その他のユーザーが提供する制約、そして、サービス品質、親和性・非親和性の要件、データの局所性などのポリシーのディレクティブを知っている必要がある。本質的には、schedulerの役割は、リソースの「供給」をワークロードの「需要」に合わせることであると言える<ref>{{cite web|url=http://rancher.com/three-pillars-kubernetes-container-orchestration/|title=The Three Pillars of Kubernetes Container Orchestration - Rancher Labs|accessdate=22 May 2017|date=18 May 2017|website=rancher.com|archiveurl=https://web.archive.org/web/20170624022635/http://rancher.com/three-pillars-kubernetes-container-orchestration/|archivedate=24 June 2017|deadurl=no|df=}}</ref>。 |
schedulerはプラガブルなコンポーネントで、未スケジュールのポッド(schedulerが管理する基本エンティティ)をどのノードで実行するのかを、リソースの可用性に基づいて選択する役割を担う。schedulerは各ノード上でのリソースの使用量をトラッキングし、ワークロードが利用可能なリソースを超過しないことを保証する。この目的を達成するためには、schedulerは、リソースの要求量、リソースの可用性、その他のユーザーが提供する制約、そして、サービス品質、親和性・非親和性の要件、データの局所性などのポリシーのディレクティブを知っている必要がある。本質的には、schedulerの役割は、リソースの「供給」をワークロードの「需要」に合わせることであると言える<ref>{{cite web|url=http://rancher.com/three-pillars-kubernetes-container-orchestration/|title=The Three Pillars of Kubernetes Container Orchestration - Rancher Labs|accessdate=22 May 2017|date=18 May 2017|website=rancher.com|archiveurl=https://web.archive.org/web/20170624022635/http://rancher.com/three-pillars-kubernetes-container-orchestration/|archivedate=24 June 2017|deadurl=no|df=}}</ref>。 |
||
==== |
==== コントローラーマネージャー ==== |
||
controllerは、実際のクラスタの状態を期待されるクラスタの状態と一致するように駆動するループである<ref name="coreos-replication-controller">{{cite web|url=https://coreos.com/kubernetes/docs/latest/replication-controller.html|title=Overview of a Replication Controller|accessdate=2015-11-02|work=Documentation|publisher=[[CoreOS]]|archiveurl=https://web.archive.org/web/20150922010433/https://coreos.com/kubernetes/docs/latest/replication-controller.html|archivedate=2015-09-22|deadurl=no|df=}}</ref>。これは、ポッド群を管理することで行われる。コントローラの1つには、'''replication controller'''(レプリケーションコントローラー)がある。このコントローラーは、ポッドのレプリカ数をクラスタ全体で指定した数になるようにレプリケーションとスケーリングを操作する。また、管理しているノードに障害が発生した場合には、代替のポッドの生成の操作も実行する<ref name="coreos-replication-controller" />。Kubernetesシステムの一部である他のコントローラの1つには、'''DaemonSet Controller'''(デーモンセットコントローラー)がある。これは、1台のマシンでポッドが必ず1つのみ実行されるようにする。'''Job Controller'''(ジョブコントローラー)は、たとえばバッチジョブの一部として、ポッドをジョブが完了するまで実行させる<ref name="exciting-experimental-features">{{cite web|url=http://www.livewyer.com/blog/2015/10/02/kubernetes-exciting-experimental-features|title=Kubernetes: Exciting Experimental Features|accessdate=2015-11-02|last=Sanders|first=Jake|date=2015-10-02|work=Livewyer|archiveurl=https://web.archive.org/web/20151020071601/http://www.livewyer.com/blog/2015/10/02/kubernetes-exciting-experimental-features|archivedate=2015-10-20|deadurl=no|df=}}</ref>。コントローラーが管理するポッド群は、コントローラーの定義の一部である、ラベルセレクターを利用して特定する<ref name="redhat-docker-and-kubernetes-training-labels-examples2">{{cite web|url=http://christianposta.com/slides/docker/generated/day2.html#/label-examples|title=Intro: Docker and Kubernetes training - Day 2|accessdate=2015-11-02|date=2015-10-20|publisher=[[Red Hat]]|archiveurl=https://web.archive.org/web/20151029210659/http://christianposta.com/slides/docker/generated/day2.html#/label-examples|archivedate=2015-10-29|deadurl=no|df=}}</ref>。 |
controllerは、実際のクラスタの状態を期待されるクラスタの状態と一致するように駆動するループである<ref name="coreos-replication-controller">{{cite web|url=https://coreos.com/kubernetes/docs/latest/replication-controller.html|title=Overview of a Replication Controller|accessdate=2015-11-02|work=Documentation|publisher=[[CoreOS]]|archiveurl=https://web.archive.org/web/20150922010433/https://coreos.com/kubernetes/docs/latest/replication-controller.html|archivedate=2015-09-22|deadurl=no|df=}}</ref>。これは、ポッド群を管理することで行われる。コントローラの1つには、'''replication controller'''(レプリケーションコントローラー)がある。このコントローラーは、ポッドのレプリカ数をクラスタ全体で指定した数になるようにレプリケーションとスケーリングを操作する。また、管理しているノードに障害が発生した場合には、代替のポッドの生成の操作も実行する<ref name="coreos-replication-controller" />。Kubernetesシステムの一部である他のコントローラの1つには、'''DaemonSet Controller'''(デーモンセットコントローラー)がある。これは、1台のマシンでポッドが必ず1つのみ実行されるようにする。'''Job Controller'''(ジョブコントローラー)は、たとえばバッチジョブの一部として、ポッドをジョブが完了するまで実行させる<ref name="exciting-experimental-features">{{cite web|url=http://www.livewyer.com/blog/2015/10/02/kubernetes-exciting-experimental-features|title=Kubernetes: Exciting Experimental Features|accessdate=2015-11-02|last=Sanders|first=Jake|date=2015-10-02|work=Livewyer|archiveurl=https://web.archive.org/web/20151020071601/http://www.livewyer.com/blog/2015/10/02/kubernetes-exciting-experimental-features|archivedate=2015-10-20|deadurl=no|df=}}</ref>。コントローラーが管理するポッド群は、コントローラーの定義の一部である、ラベルセレクターを利用して特定する<ref name="redhat-docker-and-kubernetes-training-labels-examples2">{{cite web|url=http://christianposta.com/slides/docker/generated/day2.html#/label-examples|title=Intro: Docker and Kubernetes training - Day 2|accessdate=2015-11-02|date=2015-10-20|publisher=[[Red Hat]]|archiveurl=https://web.archive.org/web/20151029210659/http://christianposta.com/slides/docker/generated/day2.html#/label-examples|archivedate=2015-10-29|deadurl=no|df=}}</ref>。 |
||
Controller manager(コントローラーマネージャー)は、DaemonSet ControllerやReplication ControllerなどのKubernetesのコアとなるコントローラーを実行するプロセスである。コントローラーは、APIサーバーと通信することで、管理対象のリソース(ポッド、サービスエンドポイントなど)の作成、更新、削除を実行する<ref name=":1" />。 |
Controller manager(コントローラーマネージャー)は、DaemonSet ControllerやReplication ControllerなどのKubernetesのコアとなるコントローラーを実行するプロセスである。コントローラーは、APIサーバーと通信することで、管理対象のリソース(ポッド、サービスエンドポイントなど)の作成、更新、削除を実行する<ref name=":1" />。 |
||
=== |
=== ノード(スレーブ) === |
||
ノード(ワーカーまたはMinionとも呼ばれる)は、コンテナ(ワークロード)が実際にデプロイされるマシンである。クラスタ内のすべてのノードは[[Docker]]などのコンテナ[[ランタイムシステム|ランタイム]]を実行する必要があり、コンテナのネットワーク設定のためにマスターと通信を行う、以下に説明するようなコンポーネントも実行する。 |
ノード(ワーカーまたはMinionとも呼ばれる)は、コンテナ(ワークロード)が実際にデプロイされるマシンである。クラスタ内のすべてのノードは[[Docker]]などのコンテナ[[ランタイムシステム|ランタイム]]を実行する必要があり、コンテナのネットワーク設定のためにマスターと通信を行う、以下に説明するようなコンポーネントも実行する。 |
||
97行目: | 97行目: | ||
Kubeletはポッドの状態を監視し、指定された状態から逸脱していることを検出すると、ポッドを同じノードに自動的に再デプロイする。ノードの状態は数秒ごとにハートビートメッセージとしてマスターに送信される。マスターがノードの障害を検知するとすぐに、Replication Controllerがこの状態を確認し、他の健全な状態にあるノードでポッドを新たに起動する{{citation needed|date=October 2016}}。 |
Kubeletはポッドの状態を監視し、指定された状態から逸脱していることを検出すると、ポッドを同じノードに自動的に再デプロイする。ノードの状態は数秒ごとにハートビートメッセージとしてマスターに送信される。マスターがノードの障害を検知するとすぐに、Replication Controllerがこの状態を確認し、他の健全な状態にあるノードでポッドを新たに起動する{{citation needed|date=October 2016}}。 |
||
==== |
==== コンテナ ==== |
||
containerはポッドの中に置かれる。containerは最も低レベルなマイクロサービスであり、実行中のアプリケーション、ライブラリ、およびその依存関係が格納される。containerは外部IPアドレスを割り当てて世界に対して公開することもできる。Kubernetesは最初のバージョン以来Dockerコンテナをサポートしており、2016年7月には、[[rkt]]コンテナエンジンが追加された<ref>https://kubernetes.io/blog/2016/07/rktnetes-brings-rkt-container-engine-to-kubernetes/</ref>。 |
containerはポッドの中に置かれる。containerは最も低レベルなマイクロサービスであり、実行中のアプリケーション、ライブラリ、およびその依存関係が格納される。containerは外部IPアドレスを割り当てて世界に対して公開することもできる。Kubernetesは最初のバージョン以来Dockerコンテナをサポートしており、2016年7月には、[[rkt]]コンテナエンジンが追加された<ref>https://kubernetes.io/blog/2016/07/rktnetes-brings-rkt-container-engine-to-kubernetes/</ref>。 |
||
133行目: | 133行目: | ||
{{脚注ヘルプ}} |
{{脚注ヘルプ}} |
||
{{Reflist|refs= |
{{Reflist|refs= |
||
<ref name="阿久津">{{ |
<ref name="阿久津">{{Cite web|和書|url=https://news.mynavi.jp/techplus/article/20171025-a084/|date=2017-10-25|title=MS、KubernetesをサポートするAzure Container Serviceの改善を発表|author=阿久津良和|publisher=[[マイナビニュース]]|accessdate=2018-01-24}}</ref> |
||
<ref name="五味">{{ |
<ref name="五味">{{Cite web|和書|url=http://gihyo.jp/admin/column/newyear/2018/container-and-cloud|date=2018-01-05|title=“コンテナネイティブ”の時代が本格到来 ―2018年のクラウドはKubernetesとGoogleに注目|author=五味明子|publisher=[[技術評論社]]|accessdate=2018-01-24}}</ref> |
||
}} |
}} |
||
140行目: | 140行目: | ||
* {{Official website|https://kubernetes.io/ja/}} |
* {{Official website|https://kubernetes.io/ja/}} |
||
* {{GitHub|https://github.com/kubernetes/kubernetes|GitHub上のソースコード}} |
* {{GitHub|https://github.com/kubernetes/kubernetes|GitHub上のソースコード}} |
||
*[https://circleci.com/ja/blog/what-is-kubernetes/ Kubernetesとは? - CircleCI] |
|||
{{Normdaten}} |
|||
[[Category:クラウドコンピューティング]] |
[[Category:クラウドコンピューティング]] |
||
[[Category:オープンソースソフトウェア]] |
[[Category:オープンソースソフトウェア]] |
2024年4月17日 (水) 22:11時点における最新版
![]() | |
作者 | |
---|---|
開発元 | Cloud Native Computing Foundation |
初版 | 2014年6月7日[1] |
リポジトリ | https://github.com/kubernetes/kubernetes |
プログラミング 言語 | Go |
サポート状況 | 開発中 |
種別 | クラスター管理ソフトウェア・コンテナオーケストレーション |
ライセンス | Apache License 2.0 |
公式サイト | kubernetes.io |
Kubernetes(クバネティス[2]/クバネテス/クーべネティス[3][4]、K8sと略記される[5])は、コンテナ化したアプリケーションのデプロイ、スケーリング、および管理を行うための、オープンソースのコンテナオーケストレーションシステムである[6]。元々Googleが設計したシステムであるが、現在はCloud Native Computing Foundationがメンテナンスを行っている。Kubernetesの目的は、「ホストのクラスターを横断してアプリケーションコンテナを自動デプロイ、スケーリング、操作するためのプラットフォーム」を提供することとされている[5]。Google自身が提供するGoogle Kubernetes Engineをはじめ、多数のパブリッククラウドサービスプロバイダがKubernetesベースのPaaSやIaaSを提供しており、プラットフォーム提供サービスとしてKubernetesをデプロイすることができる。また、多くのソフトウェアベンダーも、ブランド化したKubernetesディストリビューションを提供している。
歴史
[編集]![](http://upload.wikimedia.org/wikipedia/commons/thumb/0/03/Kubernetes_talk_at_Google_Cloud_Summit.jpg/220px-Kubernetes_talk_at_Google_Cloud_Summit.jpg)
“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のいくつかの機能の基礎となっている。
サービス
[編集]![](http://upload.wikimedia.org/wikipedia/commons/thumb/6/63/Pod-networking.png/700px-Pod-networking.png)
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オブジェクトに存在するフィールドセレクターである。使用される他のセレクターは、オブジェクトやリソースのタイプによって異なる。
アーキテクチャ
[編集]![](http://upload.wikimedia.org/wikipedia/commons/thumb/b/be/Kubernetes.png/660px-Kubernetes.png)
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をはじめとするオーケストレーションツールにより、高度な管理が出来るようになった。
出典
[編集]- ^ “First GitHub commit for Kubernetes”. github.com (2014年6月7日). 2017年3月1日時点のオリジナルよりアーカイブ。2018年6月5日閲覧。
- ^ “入門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日閲覧。
- ^ a b “What is Kubernetes?”. Kubernetes. 2017年3月31日閲覧。
- ^ “kubernetes/kubernetes” (英語). GitHub. 2017年4月21日時点のオリジナルよりアーカイブ。2017年3月28日閲覧。
- ^ “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年3月31日閲覧。
- ^ “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. 10 September 2015時点のオリジナルよりアーカイブ。24 September 2015閲覧。
- ^ 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時点におけるアーカイブ。 .
- ^ “Borg, Omega, and Kubernetes - ACM Queue”. queue.acm.org. 2016年7月9日時点のオリジナルよりアーカイブ。2016年6月27日閲覧。
- ^ “Early Stage Startup Heptio Aims to Make Kubernetes Friendly” 2016年12月6日閲覧。
- ^ “As Kubernetes Hits 1.0, Google Donates Technology To Newly Formed Cloud Native Computing Foundation”. TechCrunch. 23 September 2015時点のオリジナルよりアーカイブ。24 September 2015閲覧。
- ^ 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.”
- ^ “Autoscaling based on CPU/Memory in Kubernetes—Part II”. Powerupcloud Tech Blog. Medium (13 April 2017). 27 December 2018閲覧。
- ^ “Configure Kubernetes Autoscaling With Custom Metrics”. Bitnami. BitRock (15 November 2018). 27 December 2018閲覧。
- ^ a b c d e “An Introduction to Kubernetes”. DigitalOcean. 1 October 2015時点のオリジナルよりアーカイブ。24 September 2015閲覧。
- ^ https://kubernetes.io/docs/concepts/workloads/pods/pod/
- ^ a b 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日閲覧。
- ^ https://kubernetes.io/docs/concepts/services-networking/service/#discovering-services
- ^ Langemak, Jon (2015年2月15日). “Kubernetes 101 – External Access Into The Cluster”. Das Blinken Lichten. 2015年10月26日時点のオリジナルよりアーカイブ。2015年11月2日閲覧。
- ^ “Intro: Docker and Kubernetes training - Day 2”. Red Hat (2015年10月20日). 2015年10月29日時点のオリジナルよりアーカイブ。2015年11月2日閲覧。
- ^ “An Introduction to Kubernetes”. DigitalOcean. 1 October 2015時点のオリジナルよりアーカイブ。24 September 2015閲覧。
- ^ “Kubernetes Infrastructure”. OpenShift Community Documentation. OpenShift. 6 July 2015時点のオリジナルよりアーカイブ。24 September 2015閲覧。
- ^ “Kubernetes Components”. Documentation - Concepts. kubernetes.io. 2018年2月5日閲覧。
- ^ a b “Kubernetes Infrastructure”. OpenShift Community Documentation. OpenShift. 6 July 2015時点のオリジナルよりアーカイブ。24 September 2015閲覧。
- ^ a b c “An Introduction to Kubernetes”. DigitalOcean. 1 October 2015時点のオリジナルよりアーカイブ。24 September 2015閲覧。
- ^ a b Marhubi, Kamal (2015年9月26日). “Kubernetes from the ground up: API server”. kamalmarhubi.com. 2015年10月29日時点のオリジナルよりアーカイブ。2015年11月2日閲覧。
- ^ 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.”
- ^ “The Three Pillars of Kubernetes Container Orchestration - Rancher Labs”. rancher.com (18 May 2017). 24 June 2017時点のオリジナルよりアーカイブ。22 May 2017閲覧。
- ^ a b “Overview of a Replication Controller”. Documentation. CoreOS. 2015年9月22日時点のオリジナルよりアーカイブ。2015年11月2日閲覧。
- ^ Sanders, Jake (2015年10月2日). “Kubernetes: Exciting Experimental Features”. Livewyer. 2015年10月20日時点のオリジナルよりアーカイブ。2015年11月2日閲覧。
- ^ “Intro: Docker and Kubernetes training - Day 2”. Red Hat (2015年10月20日). 2015年10月29日時点のオリジナルよりアーカイブ。2015年11月2日閲覧。
- ^ Marhubi, Kamal (2015年8月27日). “What [.. is a Kubelet?]”. kamalmarhubi.com. 2015年11月13日時点のオリジナルよりアーカイブ。2015年11月2日閲覧。
- ^ https://kubernetes.io/blog/2016/07/rktnetes-brings-rkt-container-engine-to-kubernetes/
- ^ 五味明子 (2018年1月5日). ““コンテナネイティブ”の時代が本格到来 ―2018年のクラウドはKubernetesとGoogleに注目”. 技術評論社. 2018年1月24日閲覧。