用語集
Kubernetesとは
サーバー上でアプリケーションを動かす際、従来であれば物理的、あるいは仮想化されたサーバー上にアプリケーションを直接デプロイするのが一般的でした。しかし、最近ではアプリケーションを「コンテナ化」して動かす手法が普及しつつあります。その際、「コンテナ」や「Docker」という定番のキーワードに加えて、「Kubernetes」という名前を聞いたことのある人も多いのではないでしょうか。
本記事では、Kubernetesとはどのようなものか、概要について解説します。
本記事をご覧いただいた方向けに、おすすめの記事をまとめました。こちらもあわせてご確認ください。
コンテナとKubernetes
Kubernetes（クバネティス、クーバネティスなどと読む）とは、コンテナ化したアプリケーションの管理を行うオーケストレーションプラットフォームの一種です。Kubernetesとは、船の操舵手を表すギリシャ語ですが、名前が長く綴りにくいため、先頭のKと末尾のsの間に8つの文字があることから、K8sと略して表記することもあります。
そもそもコンテナとは、アプリケーションとその実行環境一式を「コンテナイメージ」という形でカプセル化し、独立した空間内で実行できるようにする技術です。アプリケーションごとに独立した空間を用意して動かすという発想は、1台のホストとなる物理サーバー上に複数の「仮想サーバー」を作成するのとよく似ています。しかし、仮想サーバーが物理サーバーのハードウエア一式を再現し、個々の仮想サーバー上で独立したOSが起動するのに対し、コンテナは単一のホストOS上で動作するプロセスをほかのプロセスから干渉されない空間に隔離する技術です。ホストOSから見れば単一のプロセスに過ぎないコンテナは、仮想サーバーに比べて消費リソースのオーバーヘッドが少なく、高いパフォーマンスを発揮できるというメリットがあります。
また、コンテナはアプリケーションをミドルウエアや共有ライブラリといった実行環境ごとイメージ内に収めているため、ポータビリティが非常に高いのも特長です。従来であれば、異なる環境にアプリケーションをデプロイすると、ミドルウエアや共有ライブラリのバージョンの違いなどにより、正しく動作しないといった問題が起こりがちでした。しかし、コンテナでは同じコンテナイメージをコピーすれば、環境を跨いでも同条件でアプリケーションを動かせるため、こうした問題が起こりません。また、開発環境の構築にかかる時間を短縮したり、アプリケーションのバージョンアップやロールバックを容易にします。
近年のソフトウエア開発現場では、次々に生まれてくる新しいニーズにマッチしたサービスを迅速に市場へ投入するため、「DevOps」の導入が進んでいます。ポータビリティが高く、高速にデプロイが可能なコンテナは、DevOpsにおける高速な開発～テスト～リリースのサイクルと非常に相性がよく、広く利用が進んでいます。
しかし、実際にコンテナを使ってサービスを運用しようとすると、仮想サーバー上に直接デプロイしていた頃にはなかったさまざまな問題が浮上してきます。
例えば、本番環境ではサービスの「可用性」を上げるため、複数のホストを使って冗長性を確保するのが基本です。しかし、複数のホストに分散したコンテナ同士をどのように通信させたらよいでしょうか。アプリケーションが複数のコンテナによって並列稼動している場合、複数のコンテナのログを一箇所に集約するよい方法とはなんでしょうか。コンテナは、アプリケーションのエラーによって異常終了してしまうこともあります。異常終了してしまったコンテナは、どうやって復旧したらよいでしょうか。
このように、コンテナによって構築されたシステムでは、従来の仮想マシンベースのシステムよりも考慮しなければならないことが多く存在します。結果として、システム運用の手順は従来よりも煩雑になり、運用にかかるコストも大きくなりがちです。これでは、せっかくコンテナを導入したメリットが活かせません。
Kubernetesはこうした問題を解決し、複数のホスト、複数のコンテナで構成されるシステムをうまく「オーケストレーション」してくれるプラットフォームです。もちろん世の中には、Kubernetes以外のコンテナオーケストレーションプラットフォームも存在します。しかし、2020年現在でデファクトスタンダードとなっているのがKubernetesなのです。
Kubernetesの機能
前述の通り、Kubernetesはコンテナ化されたアプリケーションをデプロイするためのプラットフォームです。システムを安定して継続的に稼動させるため、以下の機能を備えています。
Kubernetesは、複数のホストに対するコンテナのデプロイをサポートしています。前述の通り、可用性を高めるためには複数のホストを用意し、単一障害点（SPoF）をなくすのが基本です。そのため、複数のホスト対してコンテナをデプロイする機能は、プロダクション環境を構築する上で必須と言えるでしょう。
同一のコンテナを複数並列に起動し、その並列数を任意に変更できるスケーリング機能を備えています。仮にホストが複数台用意されていても、起動しているコンテナが1つだけでは、そこが新たな単一障害点（SPoF）となってしまいます。そのため、コンテナは複数起動し、並列化するのが定石です。また、当然ですが起動した複数のコンテナへのアクセスを適切にロードバランスし、負荷を分散する機能も備えています。
さらにコンテナの死活監視と自動復旧機能も備えています。起動中のコンテナに対して常にヘルスチェックを行い、異常が発生したコンテナは削除し、この削除によって減少したコンテナを補うため、新しいコンテナを自動で起動します。こうすることで、常に健全なコンテナ数が一定に保たれ、サービスを正常な状態で維持できます。
Kubernetesでは、宣言的にサービスを管理します。これはサービスがあるべき状態に到達するまでの手順を設定する（命令的）のではなく、サービスがあるべき状態そのものを宣言するという方式です。例えば、コンテナを3つ起動したい場合、命令的設定ではコンテナを3つ起動するためのコマンドを記述することになるでしょう。しかし、そのコマンドが正常に終了し、最終的に3つのコンテナが正しく起動するかどうかは保証されません。対して、宣言的設定では「このコンテナは3つ起動していること」という、最終的な状態そのものを設定します。Kubernetesはこの設定を解釈し、現在のコンテナ数が3つ未満ならば追加で起動し、逆にコンテナ数が多すぎるならば削除して、宣言された状態に収束するように自動的に調整を行ってくれます。
なぜKubernetesなのか？
DevOpsの活用で、開発～運用～フィードバックのサイクルは、かつてないほどに高速化しています。このような状況において、オンプレミス、仮想環境、クラウドと環境の違いを問わずにアプリケーションをデプロイできるコンテナの採用は、もはや必然と言ってもよいでしょう。
コンテナはオンプレミスや仮想マシンに比べて気軽に起動できる上、リソースの利用効率が非常に高い仕組みです。無秩序にコンテナを利用すると、結果としてホスト上には多数のコンテナが乱立し、その管理は煩雑化し続けることが予想されます。そのため、コンテナをよりうまく管理、運用できるプラットフォームは必要不可欠と言えるでしょう。Kubernetesを使えば、こうした煩雑になりがちな複数ノード、複数コンテナで構成されるシステムの、一元管理が可能になります。
Kubernetesでは、複数のコンテナを起動したい場合も希望する数を宣言するだけでよく、また柔軟にコンテナ数を調整できるため、冗長性とスケーラビリティを同時に確保できます。起動したコンテナは死活監視の対象となり、異常発生時には自動的に再起動が行われるため、可用性も高く保つことができます。
使用するコンテナイメージのバージョンを宣言するだけで、容易にアプリケーションのバージョンアップしたり、逆にロールバックすることもできます。また、この際に複数起動しているコンテナ群の一部分ずつを入れ替えていくことで、ダウンタイムなしのデプロイも可能となっています。
アプリケーションの開発者からするとメリットの大きいKubernetesですが、Kubernetesクラスター自体を運用するインフラ担当者の負担は決して無視できません。そのため、導入に踏み切れないというケースも少なくありませんでした。しかし、ここ数年でAWSのAmazon Elastic Kubernetes Service（EKS）やGCPのGoogle Kubernetes Engine（GKE）をはじめとする、Kubernetesのマネージドサービスが多くのクラウド事業者によって、提供されはじめました。クラウド上で管理しやすいKubernetes環境の登場により、Kubernetesはより広く利用されるようになってきています。
KubernetesはDevOpsやマイクロサービスとの親和性といった、DXを実現するための開発ニーズにあった特長を備えているため、今後は検証利用から実利用のフェーズに入る企業も増加していくと予想されています。
