コンテナプラットフォームのエンタープライズ活用における良いところ ～ Kubernetes編 ～

TIS株式会社の斎藤辰徳と申します。技術施策チームに所属し、現在はDockerやKubernetesをはじめとしたコンテナ技術の社内外技術啓蒙や、案件適用推進活動をしています。

今回のブログではSIerの視点から見た、Kubernetesのエンタープライズ活用における良いところをご紹介いたします。

そもそもコンテナの良いところは？

従来のエンタープライズシステムでは、仮想マシンを管理の最小単位とすることが一般的です。VMware社のVMware vSphereに代表される「仮想化基盤」が導入されているケースがほとんどと言った方がわかりやすいでしょうか。これを一転して、コンテナを最小単位とすることには以下の「良いところ」があります。

起動が速い

コンテナにはOSのカーネルレイヤが含まれていません。このためコンテナは、起動時にカーネルをロードすることがなく、非常に高速に立ち上がります。OSが入っているだけのイメージで仮想マシンとコンテナの起動速度を比較すると、仮想マシンでは起動に数十秒の時間を要しますが、コンテナだと1秒かからない程の違いがあります。

仮想マシンでは再プロビジョニングに時間がかかりすぎ、これまであきらめていたインフラを含むCI/CDも、コンテナではこれだけ起動速度が速いため、現実的になってきます。

イメージの可搬性が高い

OSのカーネルレイヤが含まれていないことと、起動するプロセスのために必要最小限のデータしか含まれていないことから、コンテナの元となるコンテナイメージは非常に軽量です。CentOSの仮想マシンイメージが約1GBの大きさがあるのに対し、同OSのコンテナイメージは100MB未満と1/10未満の大きさです。

ここまでイメージが軽いと、検証環境で正しく動作することが担保されたコンテナイメージを、本番環境にそのまま移動することも簡単です。従来は仮想マシンイメージが重すぎるため、このような大胆なことはできず、検証で利用したものと同一の手順書を用いて同一の仮想マシンを再現することが一般的でした。手順書のミスや作業ミスに苛まれることも少なくありませんでしたが、コンテナを活用すると、そのようなミスからも解放されるでしょう。

リソースの利用効率が良い

コンテナは仮想マシンよりもリソース利用効率が良く、一つの物理マシンに仮想マシンよりも多くのコンテナを載せることができます。これはOSのカーネルレイヤが消費するCPU、メモリ、ストレージリソースをコンテナは持たなくて済むためです。

Dockerのもつ課題

そんなコンテナですが、コンテナ技術といって多くの方がまず思い浮かべるのは「Docker」かと思います。Dockerだけでエンタープライズで活用できるシステムを作れればよいのですが、現実にはそううまくはいきません。例えば、以下のような課題をDocker単体での運用は抱えています。

可用性

Dockerが稼働するサーバー(以後、Dockerホスト)がダウンしてしまうと、当然その上で稼働するコンテナもダウンしてしまいます。高可用なサービスを提供するためには、Dockerホストがダウンしたら、その上で稼働するコンテナを正常稼働している別のDockerホストで自動的に起動しなおす必要があります。

監視

内部プログラムの例外発行によって、コンテナが停止してしまったり、意図しない動作をする状態になることは起こりえます。そんな時のためにコンテナの正常稼働を監視して、異常な状態になったらコンテナを自動的に再起動しなおす機能が必要です。

負荷分散

コンテナは一時的なリソースとして起動します。コンテナのIPアドレスもその例にもれず、動的なIPアドレスが振られます。したがって、アクセスするには手動でコンテナのIPアドレスを調べる必要があります。このためコンテナのIPアドレスを追跡し、リクエストを転送してくれる固定IPや固定の名前などのエンドポイントが必要です。なお、こうしたエンドポイントが提供されるならば、複数の同じ役割をもつコンテナに対して、アクセスを分散する機能もあるとなお良しです。

また、サービスへの予測困難なアクセス過多などによって、特定コンテナへの負荷がかかることはシステムによっては十分起こりえます。そうした時、機会損失を回避するために、コンテナを自動でスケールアウト・スケールインできる必要もあります。

大量のコンテナ管理

コンテナの良いところを最大限生かすためには、一つのコンテナで一つのプロセスを起動することが大切です。しかし、このポリシーに従うと必然的に一つのサービスを稼働させるのに必要なコンテナ数は膨大な数になってきます。よってサービスを構成するコンテナを一括で起動・停止したり、コンテナ同士の連携を行う機能が必要になります。

Kubernetesの良いところ

Kubernetesは、Dockerホスト達をクラスタリングし、実用的なコンテナアプリの運用基盤を作れるOSSです。コンテナオーケストレータと呼ばれる製品の事実上のデファクトスタンダードとして認知されています。Kubernetesは先に述べましたDocker単体での運用課題を解決し、エンタープライズ利用においても遜色ない機能を保有しています。具体的には以下のような機能を持っています。

ReplicaSetによるオートヒーリング

Kubernetesはコンテナが異常停止したとき、またDockerホストのダウンによって、その上に載っているコンテナも停止してしまったときに、正常なDockerホスト上でコンテナを再び起動する機能を持っています。これはKubernetesのReplicaSetというリソースによって実現されています。

LivenessとReadinessによる監視

KubernetesにはLivenessとReadinessという機能があり、前者はコンテナが正常稼働していることを監視、後者はコンテナがサービスを提供できる状態であることを監視します。特定のURLにHTTPアクセスができるかどうかを見たり、特定のTCPポートに対して接続できるかどうかを見たり、指定したシェルスクリプトを実行して正常終了するかどうかを見たりすることで監視を行います。

ServiceとHorizontalPodAutoscalerによる負荷分散

動的に割り振られるコンテナのIPを追跡し、コンテナにアクセスするためのエンドポイントとして機能するServiceというリソースがKubernetesでは作成可能です。Serviceを作成すると固定のIPとDNS名が割り当てられ、これらにアクセスすると背後に配置されたコンテナにリクエストが到達するという仕組みになっています。Serviceの背後には複数のコンテナを配置可能で、その場合Serviceはロードバランサとしても振る舞い、コンテナの負荷分散を実現することができます。

さらにServiceの背後にあるコンテナの数を負荷に応じて増減できれば、システムの拡張と縮退を完全に自動化できます。Kubernetesにはこれを実現するためのリソースHorizontalPodAutoscalerを作成できます。

Manifestファイルによる大量のコンテナ管理

Kubernetesのコンテナを含む全てのリソースは、Manifestファイルと呼ばれるテキストファイルにそのあるべき状態を記述しておくことで、作成・削除・変更を一括で行うことができます。これにより、コンテナを一つずつコマンドで起動または削除したり、コンテナ間の連携を一つずつ設定したりといった煩雑な管理作業から解放されます。

その他にジョブ機能やセキュリティー機能も

Kubernetesにはこれ以外にもコンテナでジョブを実行するJob、CronJobといったリソースや、ユーザやグループに対し、特定のKubernetesリソースのみにアクセスを制限するRoleやRolebindingといったリソースもあります。Kubernetesはジョブ管理や主に機密性に焦点をおいたセキュリティーに対しても考慮がなされています。

まとめ ～ Kubernetesは万能か？！ ～

Kubernetesを活用することで、コンテナアプリの本番運用基盤を作り上げることができます。エンタープライズにおいても可用性、監視、性能、運用性、ジョブ管理やセキュリティーについて考慮がなされているので、実用的な基盤として運用できるかと思います。

しかしながらKubernetesが万能な製品かというと、そうではありません。例えば、Kubernetes単体にはログ収集・管理機能はありません。またリッチなメトリクス取得機能や可視化機能もありません。これらの対応には、サードパーティー製の製品を利用する必要があります。さらに重要なこととして、Kubernetes単体ではPaaS基盤として活用するには力不足だということがあります。実際、Kubernetesにはアプリケーションのソースコードから当該アプリケーションの稼働するコンテナイメージをビルドする機能はありません。PaaS基盤として利用するのであればこれは最低限必要な機能でしょう。

KubernetesをPaaS基盤としても利用可能な形に昇華させた、Red Hat社のOpenShiftというプラットフォームもありますが、このプラットフォームについてはまたの機会にお話ししたいと思います。

関連リンク

コンテナプラットフォームのエンタープライズ活用における良いところ
～ OpenShift編 ～
コンテナプラットフォームのエンタープライズ活用における良いところ
～ Docker EE編 ～