Kubernetes

Kubernetes (クーバネティス)

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

概要

Kubernetesの主な目的は、ホストのクラスターを横断してアプリケーションコンテナを自動的にデプロイ、スケーリング、操作するためのプラットフォームを提供することです。これにより、開発者はインフラの複雑さを気にせず、アプリケーションの開発に集中できます。

多くのパブリッククラウドサービスプロバイダが、Google Kubernetes Engine (GKE) をはじめとするKubernetesベースのPaaSやIaaSを提供しており、プラットフォーム提供サービスとしてKubernetesをデプロイすることができます。また、多くのソフトウェアベンダーも、自社ブランドのKubernetesディストリビューションを提供しています。

歴史

"Kubernetes"（希: κυβερνήτης、koo-ber-nay'-tace、クベルネテス）は、ギリシャ語で航海長または水先案内人を意味し、サイバネティクス（人工頭脳学）の語源でもあります。この名前は、システムが複雑なアプリケーションのデプロイと管理を「操舵する」というコンセプトを反映しています。

Kubernetesは、当初Joe Beda、Brendan Burns、Craig McLuckieの3人によって開発が始まり、すぐにBrian GrantやTim Hockinなど、他のGoogleのエンジニアも参加しました。2014年中ごろにGoogleから初めて発表されました。Kubernetesの開発や設計はGoogleのBorgシステムから強い影響を受けており、Borgのトップコントリビュータの多くが開発に参加しています。Google内でのKubernetesのもともとのコードネームはProject Sevenであり、スター・トレックのキャラクター、セブン・オブ・ナインの名前に由来します。Kubernetesのロゴの輪にある7つのスポークは、このコードネームに由来しています。

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

コンセプト

Kubernetesは、アプリケーションのデプロイ、メンテナンス、スケールのメカニズムを、CPU、メモリ、あるいはカスタムの指標に基づいて正しく提供するための、いくつかの基本的なビルディングブロック（"primitives"）を定義しています。このシステムは疎結合かつ拡張可能であり、さまざまなワークロードに対応できます。拡張性の大部分は、Kubernetes APIによって提供されており、このAPIは内部コンポーネントだけでなく、Kubernetes上で動作する拡張機能やコンテナによっても利用されます。

オブジェクト

Kubernetesでは、コンピューティングとストレージのリソースを制御するため、リソースを以下のような「オブジェクト」として定義しています。

ポッド (Pod)

Kubernetesにおけるスケジューリングの基本単位はポッドです。コンテナ化されたコンポーネントをポッドとしてグループ化することで、より高いレベルの抽象化が実現されます。1つのポッドは1つ以上のコンテナから構成され、同じポッド内のコンテナは同じホストマシンにデプロイされるため、リソースの共有が保証されます。各ポッドには、クラスタ内でユニークなPod IPアドレスが割り当てられます。

アプリケーションはポートの衝突を気にする必要がなく、ポッド内のすべてのコンテナはlocalhost上で互いに参照できます。しかし、ポッド間のコンテナは直接参照できず、サービスを介する必要があります。開発者は、Pod IPアドレスを直接使用するのではなく、サービスを通じてポッドにアクセスすべきです。なぜなら、Pod IPアドレスは一時的なものであり、ポッドが再起動すると変更される可能性があるからです。

ポッドは、ローカルディスクまたはネットワークディスクとしてボリュームを定義し、ポッド内のコンテナに公開できます。ポッドの管理は、Kubernetes APIで手動で行ったり、コントローラに管理を委譲したりすることができます。また、定義したボリュームは、ConfigMaps（設定をファイルシステム上で参照可能にする機能）やSecrets（認証情報を安全に管理する機能）など、Kubernetesのさまざまな機能の基礎となっています。

サービス (Service)

Kubernetesサービスは、複数のポッドの集まりであり、1ティアまたはマルチティアのアプリケーションと連携して動作します。サービスを構成するポッドは、ラベルセレクターを用いて定義されます。Kubernetesは、環境変数またはKubernetes DNSを用いることでサービスディスカバリーを提供します。サービスディスカバリは、静的なIPアドレスとDNS名を各サービスに束縛させ、そのIPアドレスへのネットワークコネクションに対して、セレクターにマッチしたポッド間でラウンドロビン方式でのロードバランシングを行います。

デフォルトでは、サービスはクラスタ内部にのみ公開されますが、外部に公開することも可能です。

ボリューム (Volume)

Kubernetesコンテナ内のファイルシステムは、デフォルトでは一時ストレージを提供します。つまり、コンテナを再起動するとデータが削除されます。Kubernetesボリュームは永続的なストレージを提供するため、コンテナが再起動しても、ポッドが生存している間はデータが削除されません。ボリュームは、ポッド内のコンテナ間で共有ディスクスペースとしても利用可能です。

ネームスペース (Namespace)

Kubernetesは、リソースのパーティショニング機能を提供し、ネームスペースと呼ばれる論理的な領域に分割します。これにより、開発、テスト、本番などの環境を分離することができます。

オブジェクトの管理

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

ラベルとセレクター (Label & Selector)

Kubernetesでは、ポッドやノードなどのあらゆるAPIオブジェクトに対して、「ラベル」と呼ばれるキーバリューペアを付加できます。ラベルセレクターは、ラベルに基づいてオブジェクトをクエリし、一致するオブジェクトに解決します。ラベルセレクターを利用することで、サービスのトラフィックをルーティングするポッドを動的に制御できます。

フィールドセレクター (Field Selector)

フィールドセレクターは、リソースに予め付与された属性の値に基づいてオブジェクトを選択します。

アーキテクチャ

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

コントロールプレーン (マスター)

マスターは、クラスターのメインとなるコントロールユニットで、ワークロードとシステム全体に渡る直接的な通信を管理します。Kubernetesコントロールプレーンは、etcd、APIサーバー、スケジューラー、コントローラーマネージャーなど、複数のコンポーネントから構成されています。

etcd

etcdは、永続的な軽量分散キーバリューストアであり、クラスターの設定データを確実に保存します。Apache ZooKeeperと同様に、可用性よりも一貫性を重視するシステムです。Kubernetes APIサーバーは、etcdのwatch APIを用いてクラスターや設定の変更を監視し、宣言された状態との齟齬が生じた場合に修復します。

APIサーバー (API Server)

APIサーバーは、Kubernetes APIのサーバーであり、内部および外部向けのインターフェースを提供します。RESTリクエストを処理・検証し、etcdに保存されたAPIオブジェクトの状態を更新します。これにより、クライアントはワークロードやコンテナの設定を行うことが可能になります。

スケジューラー (Scheduler)

スケジューラーは、未スケジュールのポッドをどのノードで実行するかを、リソースの可用性に基づいて選択する役割を担います。各ノードのリソース使用量を追跡し、ワークロードが利用可能なリソースを超過しないことを保証します。

コントローラーマネージャー (Controller Manager)

コントローラーマネージャーは、DaemonSet ControllerやReplication ControllerなどのKubernetesのコアコントローラーを実行するプロセスです。これらのコントローラーは、APIサーバーと通信して、管理対象のリソースの作成、更新、削除を行います。

ノード (スレーブ)

ノードは、コンテナ（ワークロード）が実際にデプロイされるマシンです。各ノードは、Dockerなどのコンテナランタイムと、Kubernetesのコンポーネント（Kubelet、Kube-proxy、cAdvisor）を実行します。

Kubelet

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

コンテナ (Container)

コンテナはポッドの中に配置されます。コンテナは、アプリケーション、ライブラリ、およびその依存関係が格納されたマイクロサービスの単位です。

Kube-proxy

Kube-proxyは、ネットワークプロキシおよびロードバランサーの実装であり、サービスの抽象化やその他のネットワーク操作をサポートします。

cAdvisor

cAdvisorは、各ノードのコンテナのリソース使用量と性能を監視・収集するエージェントです。

アドオン

アドオンは、クラスタ内で他のアプリケーションと同じ方法で実行される、Kubernetesクラスタの機能を実装したものです。

DNS

すべてのKubernetesクラスタには、クラスタDNSが必要です。これは、KubernetesサービスのDNSレコードを保持するDNSサーバーの一種です。

ウェブUI

Kubernetesクラスタを管理するためのウェブベースのUIです。クラスタ上で実行中のアプリケーションやクラスタ自体のトラブルシューティングに利用できます。

コンテナのリソースモニター

コンテナのメトリクスを記録し、表示するためのツールです。Prometheusなどがよく利用されます。

クラスタレベルでのロギング

コンテナのログを中央のログストアに格納し、検索・閲覧するための機能です。

マイクロサービス

Kubernetesは、マイクロサービスベースのアプリケーションを実装するためのプラットフォームとして広く利用されています。

普及の理由

Kubernetesが短期間でデファクトスタンダードとなった理由には、以下のような点があります。

定期的なメジャーアップデート: 3ヵ月ごとにアップデートを繰り返し、フィードバックを反映することで信頼性を獲得しました。
CNCFの活性化: マイクロソフト、オラクル、VMware、Amazon Web Servicesなど、多くの企業がCNCFに参加し、Kubernetesへのコミットメントを示しました。
Dockerの限界: コンテナ機能に優れるDockerですが、オーケストレーション機能が不足しており、Kubernetesなどのオーケストレーションツールが必要とされました。

関連項目

Docker

外部リンク

公式ウェブサイト
GitHub上のソースコード - GitHub
* Kubernetesとは？ - CircleCI

もう一度検索