スクーターの女の子。 freepikのイラスト、 HashiCorpによるNomadロゴ

Kubernetesは、コンテナオーケストレーション用の300 kgのゴリラです。 世界最大のコンテナシステムで動作しますが、高価です。

サポートと急な学習曲線に多くの時間を費やさなければならない小さなチームにとっては特に高価です。 4人のチームにとって、これはオーバーヘッドが大きすぎます。 だから私たちは代替手段を探し始めました-そしてノマドに恋をしました。

何が欲しい

私たちのチームは、パフォーマンスを監視および分析するための多くの典型的なサービスをサポートしています：Goで記述されたメトリックのAPIエンドポイント、Prometheusのエクスポート、LogstashやGollumなどのログパーサー、InfluxDBやElasticsearchなどのデータベース。 これらの各サービスは、独自のコンテナで実行されます。 このすべてを運用し続けるには、シンプルなシステムが必要です。

コンテナオーケストレーションの要件のリストから始めました。

• 多くのマシンで一連のサービスを起動します。
  
• 実行中のサービスの概要。
  
• サービス間の通信。
  
• サービスがクラッシュした場合の自動再起動。
  
• 小さなチームによるインフラストラクチャのメンテナンス。

さらに、次のことも便利ですが、必須ではありません。

• 能力に応じてマシンをマークします（たとえば、重いI / Oサービス用に高速ディスクでマシンをマークします）。
  
• オーケストラに関係なくサービスを開始する機能（開発中など）。
  
• 構成と秘密を共有する一般的な場所。
  
• メトリックとログのエンドポイント。

Kubernetesが私たちに合わない理由

Kubernetesでプロトタイプを作成するとき、無条件に依存するロジックのより複雑なレイヤーを追加し始めたことに気付きました。

例として、KubernetesはConfigMapsを介して組み込みのサービス構成をサポートします。 特に複数の構成ファイルをマージしたり、ポッドに追加のサービスを追加したりすると、すぐに混乱する可能性があります。 Kubernetes（またはこの場合はhelm ）を使用すると、関心を分離するために動的に外部構成を実装できます。 しかし、これにより、プロジェクトとKubernetesの間の強固な秘密のつながりが生まれます。 ただし、HelmとConfigMapsは追加オプションであるため、使用する必要はありません。 構成をDockerイメージに単純にコピーできます。 それにもかかわらず、このルートに進んで不要な抽象化を構築することは魅力的であり、後で後悔することができます。

さらに、Kubernetesエコシステムは急速に成長しています。 ベストプラクティスと最新のツールを最新の状態に保つには、多くの時間とエネルギーが必要です。 Kubectl、minikube、kubeadm、helm、tiller、kops、oc-リストは延々と続く。 作業の開始時には、これらのツールのすべてが必要というわけではありませんが、必要なものがわからないため、すべてに注意する必要があります。 このため、学習曲線はかなり急です。

Kubernetesを使用する場合

当社では、多くがKubernetesを使用しており、Kubernetesに非常に満足しています。 これらのインスタンスは、十分なサポートリソースがあるGoogleまたはAmazonによって管理されます。

Kubernetesには、管理しやすく大規模なコンテナオーケストレーションを実現する素晴らしい機能が備わっています 。

• 詳細な権利管理 。
  
• カスタムコントローラーは、クラスターにロジックを追加します。 これらは、Kubernetes APIと通信するプログラムです。
  
• オートスケーリング ！ Kubernetesは、手動での介入を必要とせずに、サービスメトリックを使用してオンデマンドでサービスをスケーリングできます。

問題は、これらすべての機能が本当に必要かどうかです。 抽象化だけに頼ることはできません。 ボンネットの下で何が起こっているかを知る必要があります 。

私たちのチームは（メインインフラストラクチャとの密接な接続により）ほとんどのサービスをリモートで提供しているため、独自のKubernetesクラスターを作成したくありませんでした。 サービスを提供したかっただけです。

電池は含まれていません

Nomadはオーケストレーションの20％で、必要なものの80％を提供します。 彼がしているのは、展開の管理だけです。 ノマドは展開を管理し、エラーが発生した場合にコンテナを再起動します...それだけです。

Nomadのポイントは最小限であるということです。詳細な権利管理や高度なネットワークポリシーは特別に考案されていません。 これらのコンポーネントは、提供されるかまったく提供されません。

ノマドは使いやすさと実用性の完璧な妥協案を見つけたと思います。 小規模な独立したサービスに適しています。 さらに制御が必要な場合は、自分で調整するか、別のアプローチを使用する必要があります。 ノマドは単なるオーケストラです。

Nomadの最大の利点は、交換が簡単なことです。 ベンダーの機能はサービスを管理する他のシステムに簡単に統合できるため、ベンダーへの拘束力はほとんどありません。 クラスタ内のすべてのマシンで通常のバイナリのように動作します、それだけです！

疎結合コンポーネントの遊牧生態系

エコシステムにおけるNomadの真の力。 Consul （key-value storage）やVault （secrets processing）などの他の（完全にオプションの）製品と非常によく統合されます。 Nomadファイル内には、これらのサービスからデータを抽出するためのセクションがあります。

template { data = <<EOH LOG_LEVEL="{{key "service/geo-api/log-verbosity"}}" API_KEY="{{with secret "secret/geo-api-key"}}{{.Data.value}}{{end}}" EOH destination = "secrets/file.env" env = true } 

ここで、Consulからキーservice/geo-api/log-verbosityを読み取り、その過程で環境変数LOG_LEVELそれを表します。 また、Vaultのsecret/geo-api-keyをAPI_KEYとしてAPI_KEYます。 シンプルだが強力！

Nomadはシンプルであるため、APIを介して他のサービスを介して簡単に拡張できます。 たとえば、タスクのタグがサポートされています。 trv-metricsタグを使用して、すべてのサービスにメトリックをタグ付けします。 したがって、PrometheusはConsulを介してこれらのサービスを簡単に見つけ、定期的に新しいデータのエンドポイント/metricsをチェックします。 同じことが、たとえばLokiを使用してログに行うことができます。

拡張性には他にも多くの例があります。

• Jenkinsジョブをフックで実行すると、Consulはサービス構成が変更されたときにNomadジョブの再展開を追跡します。
  
• Cephは、Nomadに分散ファイルシステムを追加します。
  
• 負荷分散のためのfabio 。

このすべてにより、ベンダーに特別なバインドをすることなく、インフラストラクチャを有機的に開発できます。

正直な警告

完璧なシステムはありません。 最新の機能をすぐに運用環境に導入することはお勧めしません。 もちろん、バグや欠落している機能はありますが、Kubernetesについても同じことが言えます。

Kubernetesと比較して、Nomadコミュニティはそれほど大きくありません。 Kubernetesにはすでに約75,000のコミットと2,000の貢献者がいますが、Nomadには約14,000のコミットと300の貢献者がいます。 ノマドは、Kubernetesの速度についていくのが難しくなりますが、おそらくこれは必要ありません！ これはより特化されたシステムであり、コミュニティが小さいということは、プルリクエストがKubernetesよりも注目されて受け入れられる可能性が高いことも意味します。

まとめ

結論：Kubernetesは誰もが使用するという理由だけで使用しないでください。 要件を慎重に評価し、どのツールがより収益性が高いかを確認してください。

大規模なインフラストラクチャに大量の同種のサービスを展開する予定がある場合は、Kubernetesが適しています。 追加された複雑さとメンテナンスコストを覚えておいてください。 Google Kubernetes EngineやAmazon EKSなどのKubernetes管理環境を使用すると、コストの一部を回避できます。

サポートが簡単で拡張可能な信頼できるオーケストレーターを探しているだけなら、Nomadを試してみませんか？ これがあなたをどこまで導くのか疑問に思うかもしれません。

Kubernetesを車と比較すると、Nomadはスクーターになります。 時にはあなたはそれを必要とし、時には別のものを必要とします。 両方とも存在する権利があります。