Kubernetes
サーバークラスタ上でコンテナを管理するソフトウェア ウィキペディアから
Kubernetes（クバネティス[3]/クバネテス/クーべネティス[4][5]、K8sと略記される[6]）は、コンテナ化したアプリケーションのデプロイ、スケーリング、および管理を行うための、オープンソースのコンテナオーケストレーションシステムである[7]。元々Googleが設計したシステムであるが、現在はCloud Native Computing Foundationがメンテナンスを行っている。
 | |
| 作者 | |
|---|---|
| 開発元 | Cloud Native Computing Foundation |
| 初版 | 2014年6月7日[1] |
| 最新版 | |
| リポジトリ | https://github.com/kubernetes/kubernetes |
| プログラミング 言語 | Go |
| サポート状況 | 開発中 |
| 種別 | クラスター管理ソフトウェア・コンテナオーケストレーション |
| ライセンス | Apache License 2.0 |
| 公式サイト | kubernetes.io |
ホストのクラスターを横断してアプリケーションコンテナを自動デプロイ、スケーリング、操作するためのプラットフォームを提供することが目的とされている[6]。Google Kubernetes Engineをはじめ、多数のパブリッククラウドサービスプロバイダがKubernetesベースのPaaSやIaaSを提供しており、プラットフォーム提供サービスとしてKubernetesをデプロイすることができる。また、多くのソフトウェアベンダーも、ブランド化したKubernetesディストリビューションを提供している。
歴史
“Kubernetes”（希: κυβερνήτης、koo-ber-nay'-tace[8][9]、クベルネテス）は、ギリシャ語で航海長または水先案内人を意味し、サイバネティクス（人工頭脳学）の語源でもある[10]。Kubernetesは、当初Joe Beda、Brendan Burns、Craig McLuckieの3人によって開発が始まり[11]、すぐにBrian GrantやTim Hockinなど、他のGoogleのエンジニアも参加するようになり、2014年中ごろにGoogleから初めて発表された[12]。Kubernetesの開発や設計はGoogleのBorgシステムから強い影響を受けており[13][14]、Borgのトップコントリビュータの多くが開発に参加している。Google内でのKubernetesのもともとのコードネームはProject Sevenであり、スター・トレックのキャラクターで、優しいBorgである、セブン・オブ・ナインの名前に由来する[15]。Kubernetesのロゴの輪にある7つのスポークは、このコードネームに由来している。
Kubernetes v1.0は2015年7月21日にリリースされた[16]。Kubernetes v1.0のリリースと同時に、GoogleはLinux Foundationと共同でCloud Native Computing Foundation（CNCF）を設立し、Kubernetesを種となる技術として提供した。2018年3月6日には、KubernetesプロジェクトはGitHubにおけるコミット数で第9位に到達し、コントリビューター数とissue数では、Linuxカーネルプロジェクトに次いで第2位となった[17]。
コンセプト
要約
視点
Kubernetesは、いくつかのビルディングブロック（"primitives"）を定義している。このビルディングブロックのおかげで、アプリケーションのデプロイ、メンテナンス、スケールのメカニズムを、CPU、メモリ[18]、あるいはカスタムの指標[19]に基づいて正しく提供することが可能になっている。Kubernetesは、さまざまなワークロードに対応できるよう、疎結合かつ拡張可能なシステムとなっている。この拡張性の大部分は、Kubernete上で動作する拡張機能やコンテナだけでなく内部コンポーネントによっても使用されているKubernetes APIにより提供されている[20]。Kubernetesでは、コンピューティングとストレージのリソースを制御するため、リソースを以下のような「オブジェクト」として定義している。
ポッド
Kubernetesでは、スケジューリングの基本となる単位は、ポッドである[21]。コンテナ化されたコンポーネントをポッドとしてグループ化することで、1つ高いレベルの抽象化を与えている。1つのポッドは1つ以上のコンテナから構成され、同じポッドのコンテナは同じホストマシンにデプロイされるため、リソースの共有が保証される[20]。
Kubernetes内の各ポッドには、クラスタ内でユニークなPod IPアドレスが割り当てられる。これにより、アプリケーションはポートの衝突の危険を考える必要がない[22]。ポッド内では、すべてのコンテナがlocalhost上で互いに参照できる。しかし、あるポッド内のコンテナが、他のポッド内の他のコンテナを直接アドレスで参照する方法は存在せず、そのためには、必ずPod IPアドレスを利用しなければならない。しかし、アプリケーションの開発者はPod IP アドレスを決して使用するべきではない。なぜなら、他のポッドの機能にアクセスあるいは実行する時に利用するPod IPアドレスは一時的なものであり、参照しようとしている特定のポッドが再起動したりすると、そのPod IPアドレスは別のポッドに割り当てられてしまう可能性があるからである。その代りに、開発者は、特定のPod IPアドレスを持つ対象ポッドへのアクセスが可能な、サービスに対してアクセスしなければならない。
1つのポッドは、ローカルディスクのディレクトリあるいはネットワークディスクとして、1つのボリュームを定義し、ポッド内のコンテナに対して公開することができる[23]。ポッドの管理は、Kubernetes APIで手動で行ったり、コントローラに管理を委譲したりすることができる[20]。また、定義したボリュームは、ConfigMaps（設定の内容を、コンテナからファイルシステム上で参照可能にする機能）やSecrets（リモートのリソースに安全にアクセスするために必要な証明書を、認証されたコンテナのみでファイルシステム上で参照可能にする機能）など、Kubernetesのいくつかの機能の基礎となっている。
サービス
Kubernetesサービスはいくつかのポッドの集まりであり、1ティアまたはマルチティアのアプリケーションと協調して動作する。サービスを構成する複数のポッドは、ラベルセレクターを用いて定義される[20]。Kubernetesはサービスディスカバリーの手段として、環境変数を用いるモードと、Kubernetes DNSを用いるモードの2種類の方法を提供している[24]。サービスディスカバリは、静的なIPアドレスとDNS名を各サービスに束縛させ、そのIPアドレスのネットワークコネクションに対して、セレクターにマッチしたポッド間でラウンドロビン方式でのロードバランシングを行う（セレクターを用いるのは、障害によりポッドがあるマシンから別のマシンに移動したとしても動作するようにするためである）[22]。デフォルトでは、サービスはクラスタの内部にのみ公開されている（たとえば、バックエンド用のポッドは、ロードバランシングされた複数のフロントエンド用ポッドからのリクエストに対して、1つのサービスとしてグループ化されているかもしれない）が、サービスはクラスターの外部に公開することもできる（たとえば、外部のクライアントがフロントエンド用ポッドにアクセスする場合など）[25]。
ボリューム
Kubernetesコンテナ内のファイルシステムは、デフォルトでは一時ストレージを提供する。つまり、コンテナを再起動すると内部のデータが削除されてしまうため、重要なアプリケーションで利用するには制限がある。Kubernetesボリュームは永続的なストレージを提供するため、コンテナが再起動しても、ポッドが生存している間はデータが削除されない。このストレージは、同じポッド内のコンテナ同士で共有ディスク空間としても利用可能である。ボリュームは、ポッドの設定ファイル上で定義したコンテナ内の特定のマウントポイントとしてマウントされ、それ以外のボリュームにマウントしたり、他のボリュームとリンクすることができないようになっている。ただし、同じボリュームでも、異なるコンテナであれば、ファイルシステムツリー上の別の場所にマウントすることは可能である。
ネームスペース
Kubernetesは、リソースのパーティショニング機能を提供し、ネームスペース（名前空間）と呼ばれる重複のない部分に分割する。多数のチームやプロジェクトに渡る多数のユーザーの利用を想定している。これにより、開発、テスト、本番などの環境さえ完全に分離することができる。
オブジェクトの管理
Kubernetesは、オブジェクトの管理、選択、操作を可能にするメカニズムを提供している。
ラベルとセレクター
Kubernetesは、ポッドやノードなどのシステム上のあらゆるAPIオブジェクトに対して、クライアント（ユーザーや内部のコンポーネント）が「ラベル」と呼ばれるキーバリューペアを付加できるようにしている。それに対応して、「ラベルセレクター」はラベルに対してクエリーを実行し、一致するオブジェクトに解決する[20]。あるサービスを定義すると、サービスルーターやロードバランサーがトラフィックをルーティングするポッドインスタンスを選択するために使用する、ラベルセレクターを定義できるようになる。したがって、単にポッドのラベルやサービスのラベルセレクターを変更するだけで、どのポッドにトラフィックを送るかを制御することが可能になる。この方法により、ブルー・グリーンデプロイやABテストなど、さまざまなデプロイパタンを利用できる。このようなサービスが使用するリソースを動的にコントロールする機能のおかげで、インフラ内での疎結合が実現されている。
たとえば、あるアプリケーションのpodsがシステムtier（たとえば、front-end、back-endなどの値を持つ）とrelease_track（canaryやproductionなど）というラベルを持つとき、back-endかつcanaryであるノード全てを指定するには、以下のようなラベルセレクターが使える[26]。
tier=back-end AND release_track=canary
フィールドセレクター
ラベルと同様に、フィールドセレクターもKubernetesの任意のリソースを選択可能にするものである。ラベルとは異なり、選択は、ユーザーが定義したカテゴリではなく、リソースに予め付与される属性の値に基づいて行われる。metadata.nameやmetadata.namespaceは、すべてのKubernetesオブジェクトに存在するフィールドセレクターである。使用される他のセレクターは、オブジェクトやリソースのタイプによって異なる。
アーキテクチャ
要約
視点
Kubernetesは、マスター・スレーブアーキテクチャで構成される。Kubernetesのコンポーネントは、各ノードを管理するノード（node）と、コントロールプレーンであるマスター（master）の2つに分けられる[27][28]。
マスターがクラスターの管理を行い、コンテナ（実際にはPodと呼ばれる単位で管理される）は各ノード上にデプロイされる。マスターやノードを構成するコンポーネントは下記のようになっている[29]。
コントロールプレーン（マスター）
Kubernetesのマスターは、クラスターのメインとなるコントロールユニットである。ワークロードとシステム全体に渡る直接的な通信を管理する。Kubernetesコントロールプレーンは複数のさまざまなコンポーネントから構成されている。各コンポーネントは独立したプロセスとして実行され、1つのマスターノードでも、高可用クラスタをサポートするために複数のマスターノードで実行することも可能である[30]。各種コンポーネントには、次のようなものがある。
etcd
etcdは、CoreOSにより開発された、永続的な軽量な分散キーバリューストアである。クラスタの設定データを確実に保存し、任意の時点でのクラスタ全体の状態を保存する。Apache ZooKeeperと同様、etcdは、ネットワーク部分のイベントにおいて、可用性（Availability）よりも一貫性（Consistency）を重視するシステムである（CAP定理を参照）。この一貫性は、正しいスケジューリングとサービスのオペレーションにとって非常に重要である。Kubernetes APIサーバーは、etcdのwatch APIを用いて、クラスターや重要な設定の変更を監視したり、クラスタの状態にデプロイ時に宣言された状態との齟齬が生じた時、宣言された状態になるように修復する。一例として、もしデプロイ時に特定のポッドのインスタンス3つが実行している必要があると指定すると、この情報はetcdに保存される。もし、実行中のインスタンスが2つしか見つからなかった場合、この違いがetcdのデータと比較され、Kubernetesはこの情報を用いて、追加のポッドインスタンスを作成するスケジュールを立てる[30]。
API server
API serverはキーとなるコンポーネントであり、HTTP上のJSONを利用したKubernetes APIのサーバーである。Kubernetesに対する内部および外部向けのインターフェイスの両方を提供する[31][32]。API serverはRESTリクエストの処理と検証を行い、etcdに保存されたAPIオブジェクトの状態を更新する。したがって、Kubernetes APIを利用することで、クライアントはワーカーノード全体に渡るワークロードとコンテナの設定を行うことが可能になる[33]。
スケジューラー
schedulerはプラガブルなコンポーネントで、未スケジュールのポッド（schedulerが管理する基本エンティティ）をどのノードで実行するのかを、リソースの可用性に基づいて選択する役割を担う。schedulerは各ノード上でのリソースの使用量をトラッキングし、ワークロードが利用可能なリソースを超過しないことを保証する。この目的を達成するためには、schedulerは、リソースの要求量、リソースの可用性、その他のユーザーが提供する制約、そして、サービス品質、親和性・非親和性の要件、データの局所性などのポリシーのディレクティブを知っている必要がある。本質的には、schedulerの役割は、リソースの「供給」をワークロードの「需要」に合わせることであると言える[34]。
コントローラーマネージャー
controllerは、実際のクラスタの状態を期待されるクラスタの状態と一致するように駆動するループである[35]。これは、ポッド群を管理することで行われる。コントローラの1つには、replication controller（レプリケーションコントローラー）がある。このコントローラーは、ポッドのレプリカ数をクラスタ全体で指定した数になるようにレプリケーションとスケーリングを操作する。また、管理しているノードに障害が発生した場合には、代替のポッドの生成の操作も実行する[35]。Kubernetesシステムの一部である他のコントローラの1つには、DaemonSet Controller（デーモンセットコントローラー）がある。これは、1台のマシンでポッドが必ず1つのみ実行されるようにする。Job Controller（ジョブコントローラー）は、たとえばバッチジョブの一部として、ポッドをジョブが完了するまで実行させる[36]。コントローラーが管理するポッド群は、コントローラーの定義の一部である、ラベルセレクターを利用して特定する[37]。
Controller manager（コントローラーマネージャー）は、DaemonSet ControllerやReplication ControllerなどのKubernetesのコアとなるコントローラーを実行するプロセスである。コントローラーは、APIサーバーと通信することで、管理対象のリソース（ポッド、サービスエンドポイントなど）の作成、更新、削除を実行する[32]。
ノード（スレーブ）
ノード（ワーカーまたはMinionとも呼ばれる）は、コンテナ（ワークロード）が実際にデプロイされるマシンである。クラスタ内のすべてのノードはDockerなどのコンテナランタイムを実行する必要があり、コンテナのネットワーク設定のためにマスターと通信を行う、以下に説明するようなコンポーネントも実行する。
Kubelet
Kubeletは、各ノードの実行状態に対する責務を担い、ノード内のすべてのコンテナが健全な状態であることを保証する。コントロールプレーンの指示を受けて、アプリケーションコンテナ群をスタート、ストップ、管理し、ポッドとして組織する[31][38]。
Kubeletはポッドの状態を監視し、指定された状態から逸脱していることを検出すると、ポッドを同じノードに自動的に再デプロイする。ノードの状態は数秒ごとにハートビートメッセージとしてマスターに送信される。マスターがノードの障害を検知するとすぐに、Replication Controllerがこの状態を確認し、他の健全な状態にあるノードでポッドを新たに起動する[要出典]。
コンテナ
containerはポッドの中に置かれる。containerは最も低レベルなマイクロサービスであり、実行中のアプリケーション、ライブラリ、およびその依存関係が格納される。containerは外部IPアドレスを割り当てて世界に対して公開することもできる。Kubernetesは最初のバージョン以来Dockerコンテナをサポートしており、2016年7月には、rktコンテナエンジンが追加された[39]。
Kube-proxy
Kube-proxyはネットワークプロキシおよびロードバランサーの実装であり、サービスの抽象化やその他のネットワーク操作をサポートする[31]。トラフィックのルーティングを、受信したリクエストの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点が挙げられる[40]。
- 定期的なメジャーアップデート
- 3ヵ月ごとにアップデートを繰り返し、エンタープライズからのフィードバックを反映しており、本番稼働に耐えうるソフトウェアとして信頼を勝ち得た。
- Kubernetesの普及とCNCFの活性化がリンクしている
- マイクロソフトがMicrosoft AzureでのKubernetesのサポートを発表して以降、オラクルやVMwareといった企業もCNCFに参加を表明し、Amazon Web Servicesも参加するなど、競合の垣根を越えて多くの企業がKubernetesへ参加したことで、コンテナオーケストレーションツールの中でのKubernetesの存在感が高まった。
- Dockerの限界
- コンテナ機能としては優秀なDockerであるが、オーケストレーション機能が十分でなく、Kubernetesをはじめとするオーケストレーションツールにより、高度な管理が出来るようになった。
関連項目
出典
外部リンク
Wikiwand - on
Seamless Wikipedia browsing. On steroids.