「Kubernetes」と「Nomad」、どう使い分けるとよいのか：コンテナ実行基盤「Nomad」をKubernetesと比較検証（終）
コンテナオーケストレーションツールとして知られる「Kubernetes」とHashiCorpが提供する「Nomad」を比較検証する本連載。最終回はKubernetesとNomadの選定指標について解説します。
本連載第1回から第3回までKubernetesとNomadの概要を解説してきました。
最終回となる本記事では、KubernetesとNomadの提供サービスを機能ごとに比較し、KubernetesやNomadを選定するための指標を筆者の視点で紹介します。
クラスタ構築
Kubernetesにはクラスタ構築用のツールが用意されているので、簡単にクラスタを構築できます。またマネージドサービスを利用すれば、より簡潔な手順でクラスタを構築することが可能です。
Nomadはシングルバイナリで提供されているので、コンポーネントを選定してインストールする観点での煩雑さはありません。しかし、ワークロードごとに必要な機能次第では、コンポーネントをインストールするために以下の準備が必要です。
- Consul
- Vault
- Driverランタイム
- Community Driver
またNomadはdevモードで動かし、HashiCorp Learnで提供されているプラクティスを簡単に実行できます。それ故にクラスタ構築も簡単そうなイメージがありますが、実際は容易でなく、上に挙げたコンポーネントの準備に加え、次の作業も必要です。
- TLS通信のための認証局や証明書のインストール
- VaultのBackend Storage（複数オプションがある）と初期化
- Consul DNSを利用するための準備（iptablesなど）
- Vaultトークン設定
- ACL（Access Control List）設定
いずれのプロダクトも、CNI（Container Network Interface）のためのネットワーク設定が必要です。
以上のように、エコシステムとして見てみるとKubernetesが複雑でNomadよりもクラスタ構築は大変かもしれませんが、マネージドサービスやツールの存在がKubernetesでのクラスタ構築を容易にしています。
アクセスコントロール
Kubernetesには認証、認可、リクエストを制御する機能があり、それぞれのオプションが豊富です。さらに、カスタムコントローラーやWebhookを実装することで振る舞いをカスタマイズすることも可能です。
Nomadはトークン認証でポリシーベース認可のACLを利用できます。PolicyはRuleごとに設定が可能です。RuleはNamespaceやNomadオブジェクトごとに定義されており、任意のCapabilityをRuleに設定することでさらに細かく制御できます。
またNomadのトークンとポリシー管理をVaultにオフロードすることも可能です。
構築するシステムの要件に合わせてカスタムアクセスコントロールを組み込む場合は、Kubernetesが便利です。
ネットワーク
アプリケーション間の通信に必要なネットワークを管理するコンセプトはどちらも似ており、いずれのプロダクトもホストネットワークを利用できます。
またアプリケーションはLinux Network Namespaceを利用してVethを構成できます。これによりIP管理、DNS管理、ルート制御を意識することなく、アプリケーションをデプロイ可能です。
KubernetesでPod間通信を実現するためにはkube-proxyを利用します。プロキシ方法は次の3つが用意されています。
NomadはService間通信を実現するためにiptablesを利用します。いずれのプロダクトもCNIをサポートしており、ネットワーク管理にCNIを利用できます。
ストレージ
永続的なデータはマウントしたボリュームに保存できます。CSI（Container Storage Interface）を利用することで、透過的にストレージデバイスを構築、削除でき、コピーやバックアップの機能も利用できます。
KubernetesはCSIをサポートしており、さまざまな種類のストレージを利用できます。
NomadでもCSIを利用できますが、まだβリリースにとどまります。将来的にはKubernetesと同様に、多種多様なストレージを利用可能になるでしょう。
クラウドリソース
Kubernetesには、クラウドリソースを管理するためにクラウドコントローラーマネジャーが用意されています。各社のクラウドリソースをKubernetesのオブジェクトとして抽象的に扱うためのコントロールプレーンです。この機能により、クラウドリソースを透過的に制御できるようになります。
一方でNomadには、現状このような機能は用意されていないので、ロードバランサーなどのリソースは別の方法で構成する必要があります。
シークレット
Kubernetesには、コア機能としてシークレット管理が含まれています。シークレットオブジェクトはプレーンなテキストで表現されるため、セキュアに保つための運用を設計する必要があります。
NomadはVaultをインテグレーションすることでシークレット管理機能をプラグインします。シークレット管理にはVaultを利用しますが、NomadではVaultのシークレット管理機能を利用可能です。
ワークロードのデプロイ
Kubernetesのワークロードは、yamlかjsonのマニフェストをAPIに渡すことでデプロイされます。ksonnet（開発終了）やkustomizeでマニフェストをテンプレート化することでワークロードを自動化できます。またマニフェストをパッケージングして提供するHelmのおかげでアプリケーションのデプロイが非常に簡単になりました。
Nomadのワークロードは、jsonのjobspecをAPIに渡すことでデプロイされます。jobspecのファイルをCLI（Command-Line Interface）に渡す場合はHCL（HashiCorp Configuration Language）で表現します。バージョン1.0からはHCL2をサポートしています。
またLevantを利用することでjobspecをテンプレート化できます。現状は、Helmのようにスタンダードなjobspecパッケージマネジャーは存在しません。HashiCorp Discussで問い合わせたところ、jobspecのパッケージ化に関してはNomadチームが検討予定のようです。
Nomadはコンテナ以外のワークロードをサポートしているため、既存のワークロードをマイクロサービス化するポテンシャルが高いといえます。
マルチクラスタ管理
Kubernetesはオプションが限られていますが、マルチクラスタ管理を実現できます。現状はAnthosのようなマネージドサービスを利用して運用する方法が現実的なソリューションではないかと思います。
Nomadのアーキテクチャにはマルチクラスタ管理が含まれています。任意のリージョンにクラスタを分けて管理可能です。
サービスメッシュ
Kubernetesにはサービスメッシュを実現するオプションが多数存在しています。機能、パフォーマンスおよび運用の観点から利用するソリューションを検討する必要があります。NomadはConsul Connectを利用することで、サービスメッシュの機能を実現できます。
コスト
プロダクト
Kubernetesは有料ディストリビューションやマネージドサービスを利用しなければ、製品に対するコストはかかりません。NomadはOSS（オープンソースソフトウェア）版が提供されているので、これを利用する場合は製品に対するコストはかかりません。
運用
いずれのプロダクトも高い専門性を持ったチームを編成して、構築運用のためにコストをかける必要があります。
サポート
Kubernetesで有料ディストリビューションを利用している場合は、ディストリビューションごとに対応するサポートを受けることができます。マネージドサービスなら提供しているクラウドプロバイダーのサポートを受けることができます。
NomadではEnterprise Cloud Supportが利用できます。サポートを受けたい製品とTierを選択して契約を締結すればサポートを受けることができます。
まとめ
Kubernetesは多数のコンポーネントを管理して、コンテナオーケストレーションのためのクラスタ管理、スケジューリング、サービスディスカバリ、モニタリング、シークレット管理、アクセスコントロールなどさまざまな機能を提供します。
Nomadはワークロードを実行するためのクラスタ管理、スケジューリングに特化しており、コンテナ以外のワークロードをサポートしています。サービスディスカバリとサービスメッシュはConsul、シークレット管理はValutをインテグレーションすることで実現できます。
Kubernetesのワークロードを開発するためにk3s、minikube、kindなど最小構成のKubernetesクラスタを構築する方法が多数提供されています。しかし、これらの環境で開発したワークロードを、運用するフルバージョンのKubernetesにマイグレーションする際には、構築方法やオペレーションの差分を吸収する必要があるかもしれません。
Nomadなら、devモードで開発したワークロードをシームレスに本番環境に適用することができます。
Kubernetesのドキュメントによると、1クラスタが管理できるノードは5000まで、コンテナは30万までという制限があります。マルチクラスタ環境を実現する方法は存在していますが、まだ成熟していないことに加えて専門スキルが必要です。
Nomadは1クラスタで1万を超えるノードを管理でき、The Two Million Container Challengeにおいては200万コンテナのデプロイに成功しています。Multi-Cluster Federationがアーキテクチャに組み込まれているため、マルチクラスタ環境を構築することは難しくありません。
コンテナオーケストレーションのためにKubernetesの導入を検討しているチームは、次のことを考慮する場合、Nomadの導入を検討してよいかもしれません。
- コンテナ以外のワークロードを利用する
- 可用性のためにマルチクラスタが必要
- オンプレミスを利用する、あるいはオンプレミスとクラウドのハイブリッド環境が必要
- 5000ノードを超える超大規模なクラスタが必要
- Helmを利用する必要がない
- Kubernetesの拡張機能が必要ない
- マネージドサービスを利用できない
- 複数のKubernetesディストリビューションを検証する予算がない
- 複数のサービスメッシュソリューションを検証する予算がない
- Kubernetesの運用経験がない、あるいは習熟度が低い
- Vault、Consulの運用経験がある、あるいは習熟度が高い
最後に、大企業がどのようにNomadとKubernetesを活用しているか、興味深い指標が公式に掲載されていたので紹介します。
本連載が、読者の皆さまが実現したい環境を手に入れるための参考になれば幸いです。
筆者紹介
守永宏明
grasys R&D Lead Engineer
組み込み系IT企業、金融関係のオンライントレードシステム開発企業を経て、ソーシャルゲーム開発・運営会社へ入社。ゲームプログラマ、開発推進メンバーとして経験を積み、2015年2月にgrasysへ参画。Google Cloudでのさまざまなインフラ環境の構築／運用、監視プログラムの設計／開発経験を持つ。最近は社内システムの選定／インテグレーション、全体効率化などにフォーカスした活動を続けている。
Google Cloud / AWS / Azureを中心に技術情報を発信中
Copyright © ITmedia, Inc. All Rights Reserved.