Kubernetes(クバネティス)はコンテナ化したアプリケーションのデプロイ、スケーリング、および管理・自動化を行うための、オープンソースのコンテナオーケストレーションシステムです。
本記事では、Kubernetesの基本的な概要を説明します。
Kubernetesは、コンテナの運用管理と自動化を目的に作られたOSS(オープンソースソフトウェア)です。ギリシャ語で操舵手やパイロットを意味しており、クバネティス、クーベネティスと発音します。略語で「K8S」と書くこともあります。
Kubernetesの操作対象はコンテナです。コンテナは1台のサーバ上でホストOSの一つとして動作します。
従来のアプリケーション環境構築には仮想マシンの利用が一般的でした。しかし、仮想マシンは環境上にOSのインストールが必要なためにファイルサイズが大きく、立ち上げに時間がかかります。一方コンテナはホストOSの環境を利用して、アプリケーション環境に必要な仮想環境を構築します。そのためコンテナは仮想マシンに比べて環境構築が高速です。さらにコンテナのファイル自体は非常に軽量で再配布が容易になります。
コンテナの代表的なツールはDockerです。2013年にOSSプロジェクトとして公開され、現在まで数多くの企業で採用されています。
利用者はサーバ上にDockerのダウンロードが必要です。設定ファイルはyaml形式で書かれており、その記述に従ってDockerレジストリから関連ファイルがダウンロードされます。Dockerはそのファイルを利用して、ホストOSからメモリ・プロセスの確保を行い、仮想環境を提供します。
運用するコンテナの数が増えたり、マルチホストでサービス提供を行う場合、コンテナの監視やデプロイが煩雑化します。この課題解決手法としてコンテナオーケストレーションと呼ばれる技術が注目を集めています。Kubernetesはそのツールのデファクトスタンダードとして利用されているのです。
Kubernetesはリリースの自動化、障害時の自己回復、CPUの利用制限といった機能を持ちます。またKubernetesを通じて、各ホストに対するスケジューリングやスケーリングなどを設定できます。コンテナ管理者はKubernetesを導入、事前に必要な設定をしておくことで、管理の効率化・自動化を実現できるのです。
Kubernetesは元々Googleの社内プロジェクトです。そのためGoogleの仮想サーバオーケストレーションツールBorgの影響を強く受けています。2014年に初版が一般公開された後、2015年7月にv1.0がリリースされます。
当時、Docker公式のSwarm、CoreOS社のfleetなど、コンテナオーケストレーションツールの選択肢が乱立していました。これらは特定の企業のツールです。一方でKubernetesはGoogleとLinux Foundationが設立したCloud Native Computing Foundationにファーストプロジェクトとして寄贈され、OSSとして運営されます。その結果、Kubernetesはユーザコミュニティの拡大に成功します。そしてAzureやAWSといった主要プロバイダーでも採用されるツールとして、デファクトスタンダードの地位を確立したのです。
Kubernetesの構成はマスター・スレーブアーキテクチャです。マスター・スレーブアーキテクチャは複数の機器動作で説明されます。機器の操作を司るマスター機、マスター機に制御・操作されるスレーブ。2つの役割がアーキテクチャの構成要素です。Kubernetesではマスターをコントロールプレーン、スレーブをノードが担います。
Kubernetesが提供するサービスの全体像はクラスタです。クラスタを構成するコンポーネントはコントロールプレーン、ノード、アドオンの3つに分類されます。クラスタ内ではコントロールプレーンがノードの管理を行います。またクラスタを利用するためには、アドオンに含まれる技術が必要です。
コントロールプレーンはクラスタ全体のプロセス管理や通信を行います。コントロールプレーンは複数同時に運用可能で、高可用性もサポートしています。主なコンポーネントは4つです。
etcd
etcdは永続的なキーバリューストアです。クラスタの設定データや、任意の時点におけるクラスタ全体の状態を保持します。KubernetesのAPIサーバはetcdのwatch APIを用いてクラスタの設定に関する変更監視や、自己修復などを行います。
APIサーバ
APIサーバはコントロールプレーンのフロントエンドです。Kubernetesの内外に関わらずインターフェースの提供を行います。その実態はHTTP上のJSONリクエストであり、REST形式でノードや関連サービスの制御命令を行います。
スケジューラ
Kubernetes上のスケジューリングの最小単位はポッドと呼ばれます。ポッドはノード内で複数展開が可能で、ポッド内のコンテナはlocalhost上で互いに参照可能です。スケジューラはノード上で未実行のポッド監視を行い、実行するノードを選択します。その決定はポッドのリソース要求量や有効期限など、複数の要素を比較して行われます。
コントローラマネージャ
コントローラマネージャは複数のコントローラプロセスを管理・実行します。コントローラの種類はノードの監視、Pod数の制御、エンドポイントの実行などさまざまです。
ノードはコンテナがデプロイされるマシンです。クラスタ内に複数存在しており、ポッドの管理やコンテナの実行環境を提供します。
Kubelet
Kubeletはノード内のポッドが健全な状態を保証する役割です。コントロールプレーンの指示により1つ以上のコンテナの開始・停止を管理してポッドを構成します。ポッドの状態が正常状態から逸脱していると、それを検知して同一のノード内に再デプロイを行います。
Kube-proxy
Kube-proxyはネットワークプロキシとロードバランサとしての役割です。トラフィックのルーティングや、ポッド外からのリクエストを適切なコンテナにルーティングします。
コンテナランタイム
コンテナランタイムはDockerをはじめとしたコンテナの実行を担当するソフトウェアです。
クラスタ利用に必要な最小のアドオンはDNSです。DNSはクラスタ内のDNSサーバとしての役割を持ちます。アドオンとしてはほかに汎用WebUIであるダッシュボードや、コンテナリソース監視といった機能が含まれます。アドオンは現在も増え続けており、ネットワークやセキュリティに関するさまざまな機能が利用可能です。
Kubernetesはコンテナオーケストレーションツールとして多くの特徴を持ちます。ここでは5つの主要な機能について紹介します。
サービスディスカバリはポッドに内部IPアドレスと単一のDNS名を与え、クラスタDNSに登録します。Kubernetesではポッドの再移動が発生し、その度にポッドのIPアドレスが変更されます。そのためクラスタ内の通信ではDNSの仕組みを用いることで、同じ名前のポッドとIPアドレスの紐付けを行うのです。またサービスディスカバリはロードバランサ(負荷分散)としての機能も持ちます。
事前に設定したルールや、現在のアプリケーションアクセス数から自動的に、アプリケーションのスケールアップ・スケールダウンを行います。
Kubernetesはポッドの作成と削除を柔軟に行います。一方でポッドはディスク領域に展開されているため、データは永続化されていません。ポッドのデータ永続化は2つの方法で実現できます。ノードのディスク領域、外部ストレージ、いずれかにポッドのデータをマウントします。
クラスタ内のノードで障害が発生すると、それを検知して正常動作するノードで自動的にコンテナをデプロイします。
Kubernetesではポッドインスタンスを新しいインスタンスで段階的にアップデートを行います。このようなローリングアップデートによりダウンタイム無しでのアプリケーションアップデートが実現します。
Kubernetesはアプリケーションのデプロイ・メンテナンスなど、コンピューティングとストレージのリソース制御を行います。このリソースはKubernetes内でオブジェクトと呼ばれる単位で定義されています。
前述したように、ポッドはKubernetesのスケジューリングの最小単位です。その実態はグループ化された1つ以上のコンテナです。ポッドには必ずIPアドレスが割り振られます。Kubernetesのデプロイモデルは、一般的には1ポッド1コンテナの関係です。
サービスは複数のポッドの集合体です。Kubernetesのサービスディスカバリ手段は、環境変数とDNSの2つです。
サービスがあることで、ポッド間で連携するアプリケーションは、接続を常に維持できます。例えば連携する2つのポッド上のアプリケーションについて、片方のポッドがデプロイにより再作成されたとします。このような場合でも、サービスディスカバリがあることで、新規作成されたポッドのIPアドレスをもう一つのポッドが自動的に再発見するのです。
Kubernetesにおけるボリュームは永続的なストレージとして、ポッドと疎結合なリソースとして提供されています。Volumeはプラグインを用いて外部ストレージを用いることも可能です。
Kubernetesで作成されたクラスタを複数人で共同利用したい場合、namespaceを用いることでクラスタリソースを分割できます。この機能により同一クラスタ内で、開発・テスト・本番環境の分離も実現できます。
世の中としてコンテナが広く普及しています。またマイクロサービスのように複数のアプリケーションを組み合わせる構成も増加傾向です。このような流れにおいてKubernetesはさまざまなシーンで活用がされています。
マイクロサービスは、独立した小規模のアプリケーションを連携して一つのサービスとして提供するアーキテクチャです。単一のアプリケーションを拡張させるモノリシックのアーキテクチャと比較されます。複数のアプリケーションのデプロイや監視を自動的に行えるコンテナオーケストレーションは、マイクロサービスと非常に相性のいい技術です。Kubernetesを利用しない場合、開発者はマイクロサービス間の接続やデプロイの設定を個別に行います。一方Kubernetesでは複数のポッド(コンテナ)をサービスとして扱い、接続やデプロイを自動化できます。
OSSであるKubernetesはクラウド・オンプレミスの環境に依存することなく利用できます。またKubernetesは同一の物理サーバ上で、仮想マシンや単一のコンテナとの共存も可能です。オンプレミス環境の場合、Kubernetesのアップデートや管理に注意が必要です。
Kubernetesをより便利に使う上では、監視やトラフィック制御など、専用ツールの活用がオススメです。
Istio
Istioはマイクロサービスにおける通信トラフィック制御のツールです。アプリケーションの新バージョンリリース時にトラフィックを新旧のバージョンに振り分けたり、実行環境とテスト環境にトラフィックを振り分けたりできます。またアクセス集中時には、一部のトラフィックに意図的に遅延を発生させます。このような機能により、マイクロサービス間の通信安定化を実現しているのです。
Helm
HelmはKubernetes向けのパッケージマネージャです。「チャート」と呼ばれる設定ファイル群に、Kubernetesの全てのマニフェストを記述します。この記載をもとにしてHelmはパッケージのインストールを行います。また一度Helmでデプロイされたリソースは、容易にロールバックやアンインストールが可能です。
Prometheus
PrometheusはCNCFが運営するOSSのメトリクス監視ツールです。Kubernetesではクラスタの監視に用いられます。そのまま利用する場合は、設定項目も多いためカスタマイズされたパッケージの利用が一般的です。
コンテナオーケストレーションツールのデファクトスタンダードとして、Kubernetesは今後も数多くの企業・サービスでの利用が見込まれます。クラウドの普及でシステム規模や構成が拡大の一途をたどる中、運用・管理は開発者にとって喫緊の課題です。柔軟かつ安定的なサービス運用を実現する上でも、Kubernetesの技術理解・活用を開発者は求められます。
標準化されたアプリケーション実行環境を手軽に利用できるサービスです。リリースプロセスを自動化し、開発者自身がセルフサービスで実行環境を準備できるようになります。
条件に該当するページがございません