Kubernetes

出典: フリー百科事典『ウィキペディア(Wikipedia)』
ナビゲーションに移動 検索に移動
Kubernetes
Kubernetes logo.svg
作者 Google
開発元 Cloud Native Computing Foundation
初版 2014年6月7日(4年前) (2014-06-07[1]
最新版 1.13[2] / 2018年12月3日(2か月前) (2018-12-03
リポジトリ github.com/kubernetes/kubernetes
プログラミング言語 Go
使用エンジン Docker
サポート状況 開発中
種別 クラスター管理ソフトウェア・コンテナオーケストレーション
ライセンス Apache License 2.0
公式サイト kubernetes.io
テンプレートを表示

Kubernetesクバネティス/クバネテス[3][4][5]、よくK8sと略記される)[6]は、コンテナ化したアプリケーションのデプロイ、スケーリング、および管理を行うための、オープンソースのコンテナオーケストレーションシステムである[7]。元々Googleが設計したシステムであるが、現在はCloud Native Computing Foundation英語版がメンテナンスを行っている。Kubernetesの目的は、「ホストのクラスターを横断してアプリケーションコンテナを自動デプロイ、スケーリング、操作するためのプラットフォーム」を提供することとされている[6]。リリース時より、Dockerを含む多数のコンテナツールと連携して動作する[8]。多数のパブリッククラウドサービスプロバイダがKubernetesベースのPaaSIaaSを提供しており、プラットフォーム提供サービスとしてKubernetesをデプロイすることができる。また、多くのソフトウェアベンダーも、ブランド化したKubernetesディストリビューションを提供している。

歴史[編集]

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

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

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

Kubernetesにおけるオブジェクト[編集]

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

ポッド(pod)[編集]

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

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

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

サービス(service)[編集]

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

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

ボリューム(volume)[編集]

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

ネームスペース(namespace)[編集]

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

Kubernetesのオブジェクトの管理[編集]

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

ラベルとセレクター(label and selector)[編集]

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

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

tier=back-end AND release_track=canary

フィールドセレクター(field selector)[編集]

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

アーキテクチャ[編集]

Kubernetesのアーキテクチャ図

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

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

Kubernetesコントロールプレーン(マスター)[編集]

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

etcd[編集]

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

API server[編集]

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

Scheduler(スケジューラー)[編集]

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

Controller manager(コントローラーマネージャー)[編集]

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

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

Kubernetesノード(スレーブ)[編集]

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

Kubelet[編集]

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

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

Container(コンテナ)[編集]

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

Kube-proxy[編集]

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

cAdvisor[編集]

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

普及の理由[編集]

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

  • 定期的なメジャーアップデート
    3ヵ月ごとにアップデートを繰り返し、エンタープライズからのフィードバックを反映しており、本番稼働に耐えうるソフトウェアとして信頼を勝ち得た。
  • Kubernetesの普及とCNCFの活性化がリンクしている
    マイクロソフトがKubernetesのサポートを発表して以降、オラクルVMwareといった企業もCNCFに参加を表明し、GoogleやMicrosoft Azureとは競合関係にあるAmazon Web Servicesも参加している。このため、「Kubernetesがデファクトスタンダード」という認識がより強まった。
  • Docker社の凋落
    コンテナエンジンとしてのDockerを開発してきたDocker社であるが、その存在感が薄れてきている。

出典[編集]

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

外部リンク[編集]