Kubernetesって何?
先ほど、コンテナを利用してアプリケーションを本番運用するにあたって多くの課題があると述べました。それらの課題を上手に解決するために作られたのがKubernetesです。
Kubernetesの公式ドキュメントによると「Kubernetesは、コンテナ化されたアプリケーションの展開、スケーリング、また管理を自動化するためのオープンソースコンテナプラットフォーム」と説明されています。
Kubernetesの特徴
では先ほど説明したコンテナ本番運用の課題と照らし合わせながら、Kubernetesの特徴を挙げます。
-
コンテナの仕様や設定を個々に管理するのが大変
→マニフェストを利用することで各設定をコード化できる(Infrastructure As Code) -
冗長化のために複数台サーバーを利用してコンテナを起動したいとき、「どのサーバーに」「どのコンテナを起動するか」を決定することが難しい
→KubernetesのAPIでインフラレイヤが共通化・抽象化されており、サーバー固有の設定を知る必要がない -
障害発生時に、各コンテナの設定・障害復旧を実施/管理しなければいけない
→Reconciliation Loopによって障害から自動復旧するよう試みる
マニフェストを利用することで各設定をコード化できる(Insrastructure As Code)
Infrastructure As Codeという言葉を聞いたことがありますか? 簡単に説明すると、インフラや、その設定をコードに書き表すことで、インフラレイヤの再現性・保守性を高めようという考え方です。コードに書かれていればバージョン管理やレビューすることが簡単になります。Kubernetesではマニフェストと呼ばれる“リソースの仕様書”を利用することで、インフラレイヤをコードで書き表すことができます。
例えば以下のマニフェストの例をみてみましょう。
マニフェストの細かい説明は次回説明しますので、ここでは簡単にみていきます。このマニフェストではNGINXのコンテナを立ち上げるための設定を書いています。
Kubernetesではリソースを作成することでアプリケーションのデプロイや設定ができます。コンテナはPodというリソースを利用してデプロイします。 Podは複数コンテナをまとめた単位であり、このマニフェストにはPodというリソースを用いてnginxというコンテナを立ち上げるよう指定しています。
このようにしてコンテナの“仕様”を全てマニフェストに書き起こし、この“仕様”をもとにコンテナが起動されます。Kubernetesではコンテナを含めたインフラレイヤのほとんどをコード化することで、「コンテナの仕様や設定を個々に管理するのが大変」という課題を解消します。
KubernetesのAPIでインフラレイヤが共通化・抽象化されており、サーバー固有の設定を知る必要がない
先ほどのマニフェストを再度参照してほしいのですが、先ほどの“仕様”にはメモリのリクエストを「100メビバイト」としています。Kubernetesでは複数台のサーバーをデプロイ対象として扱うことができますが、ここではPodリソースをどのサーバーにデプロイするか指定する必要がありません。そのサーバーのOSが何なのか、メモリのリクエストを満たせるかどうかを気にする必要がない(抽象化されている)ことがKubernetesの便利な特徴の1つです。
また、マニフェストはKubernetesのAPIサーバーに送ることで、リソースを作成できます。Kubernetesでは全てのリソースがAPIサーバーを経由して作成されるため、APIサーバーのインターフェースによって共通化されています。このため、実際にコンテナを起動するサーバーの仕様が異なっていたとしても、共通のAPIを通じて同じようにコンテナの起動をおこなうことができます。
Reconciliation Loopによって障害から自動復旧するよう試みる
Reconciliation Loopとは、あらかじめマニフェストに定義しておいた設定(desired state)で稼働するよう動き続ける機能のことです。Kubernetesは常にリソースを監視し、“desired state”を満たすように動きつづけます。このReconciliation Loopを利用することで、Kubernetesは障害発生時にリソース単位でなるべく自動で復旧するよう試みます(うまくいかないこともたくさんあるので、障害発生に関してはまた別の回で詳しく説明します)。
また、このようにあらかじめ宣言しておいた設定通りに動くインフラを「宣言型」と言い、障害に強いとされています。
この対比として「命令型」のインフラがあげられます。
命令型のインフラは、インフラを構築するための手順を書いておき、実行する方法です。Ansibleなどが命令型インフラとなります。命令型では命令のどこまで実行したかを記憶しておかない限り、障害発生時には頭から手順を流し直す必要が出てきます。一方宣言型では「いつdesired stateに到達するか」は保証されないため、手順の実行と実行結果を随時受け取れる命令型の方がシンプルです。
Kubernetesの特徴と、そこから見えるKubernetesを利用するメリットは理解できたでしょうか? 今後の連載を通じてより詳しくKubernetesを利用するメリットについて説明します。まずはこの連載第1回を読んでいただいたということで、「ようこそ、Kubernetesの世界へ!」また次回お会いしましょう。
ぷちコラム:KubernetesとDockerの違いは?
「KubernetesとDockerの違いはなんでしょうか?」という質問をよく見かけます。確かにDocker ComposeやDockerのSwarm Modeなど、DockerにもKubernetesに近い機能はあります。しかし昨今複数のマシンを用いたコンテナ環境を構築する場合、Kubernetesを選択するケースが多いです。DockerとKubernetes、それぞれ得意な分野が違うため、両者を比較してどちらかを選択するということではなく、両方活用することが多いです。
少し詳しくみていきましょう。Docker社の開発するDockerは、docker build
を実行することでDockerイメージを作ることができ、更にDocker Hubを利用してDocker Imageを共有できます。共有したDocker Imageは各マシン上でdocker run
を実行することでコンテナを起動できます。
一方OSSであるKubernetesは、コンテナを運用するプラットフォームとして現在業界のデファクトスタンダードとなっており、非常に大きいエコシステムになっています。コミュニティも大きく、開発も非常に活発です。そのため機能拡張性に長け、さまざまなOSSがKubernetesに対応しています。
このため、Dockerの持つBuild、Share、Runのエコシステムを活用しつつ、それ以外の部分はKubernetesが担う、というケースが多いのではないでしょうか。