コンテナの強い相棒「コンテナオーケストレーションツール」を知る

世の中ではコンテナが流行り、コンテナオーケストレーションツールが必要とされています。それはなぜなのでしょうか。

 

ここでは、コンテナの持つ「素早い起動」「リソース消費が少ない」などのメリットを仮想マシンと比較することで解き明かし、さらにビジネスユースでは欠かせないコンテナオーケストレーションツール、中でも事実上の標準となっているKubernetesを解説することで、その理由に迫ります。

仮想マシンとコンテナ

従来のサーバー仮想化では、ホストOS上に仮想的なサーバーを作り、その中にOS（一般的に仮想マシン内にインストールするOSのことをゲストOSと呼びます）をインストールして、その上でアプリケーションを実行します。

 

当然ながらアプリケーションの実行にはCPUやメモリー、ストレージリソースを必要とします。仮想マシンもホストOSから見ればアプリケーションの１つになるため、仮想マシンの実行にもCPUやメモリー、ストレージリソースを必要とします。つまり、仮想マシンでアプリケーションを動かすにはオーバーヘッド＝無駄が大きいのです。

 

 

 

 

一方、コンテナを使えば、無駄を排除してアプリケーションを実行できます。コンテナはホストとは隔離した領域を作って、その中でアプリケーションを実行します。アプリケーションの実行に必要なリソースはホストOSと共有するので、余計なCPU、メモリー、ストレージなどを消費せずに実行できます。リソースに余裕があれば仮想マシンで動かす場合と比べて、さらに多くのアプリケーションを実行できます。

コンテナオーケストレーションとは？

コンテナは非常に便利なアプリケーションの実行環境です。手軽さや利便性も相まって、アプリケーション開発時の実行環境で使われたり、最近はDevOps環境のツールの一つとして使われたり、国内でも本番環境でのコンテナの利用も増えてきたようです。

コンテナを導入している顧客の多くは、1ホストあたり最大1000個のコンテナを動かすのが一般的と言われています。コンテナが1ホストに対して少数であれば従来どおりの運用で構いませんが、コンテナが増えれば増えるほど人手による管理は現実的ではありません。

 

開発環境で使うだけであればまだしも、本番環境でコンテナを使うとなると様々な検討すべき課題が存在します。

例えばアプリケーション実行の継続性を担保するために、複数のサーバーでからなるクラスターを組む必要が出てきます。さらに複数のサーバー上で稼働するコンテナを一括で管理する方法を検討したり、負荷分散、スケーリング性、耐障害性なども考慮の必要があるかもしれません。

 

このように、本番環境でコンテナを利用するには様々な課題があります。これらの課題を解決するのがいわゆる「オーケストレーションツール」です。2017年頃はDocker SwarmやCloud Foundry、Mesosphere DC/OSなどいくつかの選択肢がありましたが、オープンソースであることや設計の良さもあって、Docker社のDockerやAmazon、Google、Microsoft、IBMなど、様々なベンダーがKubernetesをサポートするなど、2017年から2019年にかけた現在ではKubernetesが事実上の標準になっています。

「Kubernetes」の概要

KubernetesはもともとはGoogleの社内システムで使われていたソフトウェアがベースとなっています。現在コードはCloud Native Computer Foundation（CNCF）に寄贈され、様々な開発者の手によってオープンソースによる開発が行われています。

 

Kubernetesはコンテナを中心とした、コンピュート、ネットワーク、ストレージインフラストラクチャーのオーケストレーションをするためのツールです。Kubernetesの設計には拡張性、可用性、耐障害性などが含まれていますので、前の項で説明した課題の多くを解決できます。

「Kubernetes」のメリット

Kubernetesには様々な利点が存在しますが、代表的なものを挙げると次のようなものがあります。

高い拡張性

要求する機能に合わせて、環境を構成できます。例えば、初期は少ない台数のサーバ―でKubernetesを動かし、コンテナの数が増えてサーバーリソースが逼迫してきたら新しいサーバーを横に並べればスケール可能です。また、Kubernetesは機能を後からでも追加したり、不要になった機能を削除したりと、着脱が可能ですので、予算に応じてシステムをつくることができます。

Kubernetesは様々なコンテナランタイム（CRI）やネットワークインターフェイス（CNI)に対応しており、要件になったコンポーネントを選択できます。コンテナランタイムとしてはDockerやcontainerd、CRI-Oなどといった様々なコンテナエンジンの中から要件になったものを選択できます。一番古くからサポートされており、実績があるのはDockerです。ネットワークインターフェイスとしてはFlannel、Calico、Canal、OVNなどの中から要件になったものを選択できます。標準的に使われるのはFlannelでしょう。

 

※サポートしているコンテナーランタイム、ネットワークインターフェイスの導入方法については次の公式ドキュメントをご確認ください。

◆コンテナーランタイム
https://kubernetes.io/docs/setup/production-environment/container-runtimes/
◆ネットワークインターフェイス
https://kubernetes.io/docs/concepts/cluster-administration/addons/

スケジューリングと負荷分散

特に指定せずにコンテナを起動すると、Kubernetesのコントローラーがリソースの空き具合に応じて適切なノードに振り分けてアプリケーションを実行します。

 

また、アプリケーションを小規模で動かし、必要に応じて複数のノードへスケーリングしたり、ユーザーからのアクセスを振り分けることで負荷分散するといったことも可能です。

耐障害性～自動修復機能～

実行中のアプリケーションコンテナに接続できない場合や正常にアプリケーションが実行されていない場合に、自動的にアプリケーションの復旧（自動複製、再起動、再配置など）が試みられます。アプリケーションで発生した軽微な問題は、自動復旧できる可能性があります。

「Kubernetes」とCI/CD

Kubernetesはコンテナのオーケストレーションを行ってくれるので、CIやCDのインフラとしても役立ちます。例えばGitLab 8以降のバージョンでは、CI/CD機能が実装されており、継続的インテグレ―ション、デリバリー、デプロイといったDevOpsの基盤として利用することができます。

GitLab CI/CD機能はデフォルトで有効化されており、GitLab Runnerというものを別途用意することでGitLab上で開発しているアプリケーションに対して、CI/CDを実行する機能をプラスすることができます。GitLab Runnerは定義したテストの実行環境やアプリケーションのデプロイ先として利用できますが、GitLab Runnerを利用するためのエンジンの部分は別途用意する必要があります。

例えばDockerコンテナーをCI/CDで活用したい場合は、GitLab RunnerのホストにDockerをインストールしなければなりません。GitLab Runnerのセットアップは簡単ではあるものの手作業が必要になりますし、管理するのも大変です。

最近のバージョンのGitLabにはKubernetes連携の機能が追加されました。これにより、GitLabにKubernetesを関連付けするだけでKubernetesをCI/CDのインフラとして利用することができるようになっています。

今回はコンテナのメリットと、コンテナーオーケストレーション、また、最近採用例が増えているKubernetesについて、概要と導入のメリットについて解説しました。もし、Kubernetesを試してみたくなった方はお試しするためのセットアップ手順と実際に使ってみるための記事を用意しましたのでご覧ください。

 

「Kubernetes」を体験してみよう

 

 

（日本仮想化技術株式会社　技術部／遠山 洋平）

 

※記載されている会社名、製品名、サービス名は各社の商標または登録商標です。