スクーターに乗った女の子。 図 Freepik、ノマドのロゴより ハシコープ

Kubernetes は、コンテナ オーケストレーションにおける 300 ポンドのゴリラです。 世界最大級のコンテナ システムで動作しますが、高価です。

小規模チームの場合は特に費用がかかり、多くのサポート時間と急な学習曲線が必要になります。 これは XNUMX 人のチームにとってオーバーヘッドが大きすぎます。 そこで私たちは代替案を探し始めました - そして、 遊牧民.

なんでしょう

私たちのチームは、Go で書かれたメトリクスの API エンドポイント、Prometheus エクスポート、Logstash などのログ パーサー、および ゴラム、InfluxDB や Elasticsearch などのデータベースも同様です。 これらの各サービスは独自のコンテナーで実行されます。 すべてを実行し続けるためのシンプルなシステムが必要です。

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

• 多数のマシン上で一連のサービスを実行する。
• 実行中のサービスの概要。
• サービス間のリンク。
• サービスがダウンした場合は自動的に再起動します。
• 少人数のチームによるインフラメンテナンス。

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

• マシンの機能に基づいてタグ付けします (たとえば、負荷の高い I/O サービス用の高速ディスクを備えたマシンにタグ付けします)。
• オーケストレーターから独立してサービスを実行する機能 (たとえば、開発中)。
• 構成と秘密を共有するための共通の場所。
• メトリクスとログのエンドポイント。

Kubernetes が当社に適さない理由

Kubernetes を使用してプロトタイプを作成する際、私たちは、大きく依存しているロジックの複雑なレイヤーを追加していることに気づきました。

例として、Kubernetes は組み込みのサービス構成をサポートしています。 ConfigMap。 特に複数の構成ファイルをマージしたり、ポッドに追加のサービスを追加したりする場合は、すぐに混乱する可能性があります。 Kubernetes (または 舵 この場合)、外部構成を動的に実装して懸念事項を分離できます。 しかし、これにより、プロジェクトと Kubernetes の間に密接な隠れた結合が生じます。 ただし、Helm と ConfigMap は追加のオプションであるため、使用する必要はありません。 構成を Docker イメージにコピーするだけです。 ただし、この道をたどって不必要な抽象化を構築したくなり、後で後悔する可能性があります。

さらに、Kubernetes エコシステムは急速に進化しています。 ベスト プラクティスと最新のツールを常に最新の状態に保つには、多くの時間と労力がかかります。 Kubectl、minikube、kubeadm、helm、tiler、kops、oc - リストは数え切れないほどあります。 開始時にこれらのツールのすべてが必要なわけではありませんが、何が必要になるかわからないため、すべてを認識しておく必要があります。 このため、学習曲線は非常に急になります。

Kubernetes を使用する場合

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

Kubernetesには付属しています 素晴らしい機能これにより、大規模なコンテナ オーケストレーションがより管理しやすくなります。

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

問題は、これらすべての機能が本当に必要かどうかです。 抽象化だけに依存することはできません。 内部で何が起こっているのかを調べなければなりません.

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

電池は含まれていません

Nomad は、必要なものの 20% を提供するオーケストレーションの 80% です。 実行するのは展開の管理だけです。 Nomad はデプロイメントを処理し、エラーが発生した場合にはコンテナーを再起動します。それだけです。

Nomad の要点はその機能です 最小: きめ細かい権利管理がない、または 拡張ネットワークポリシー、これは特別に設計されています。 これらのコンポーネントは外部から提供されるか、まったく提供されません。

Nomad は使いやすさと実用性の間の完璧な妥協点を見つけたと思います。 小規模な独立したサービスに適しています。 さらに制御が必要な場合は、自分で値を設定するか、別のアプローチを使用する必要があります。 ノマドは ちょうど オーケストレーター。

Nomad の一番良いところは簡単なことです 置き換える。 ベンダーの機能はサービスを管理する他のシステムに簡単に統合できるため、ベンダーとのつながりは事実上ありません。 クラスター内のすべてのマシンで通常のバイナリと同じように実行されるだけです。

疎結合コンポーネントの Nomad エコシステム

Nomad の本当の強みはそのエコシステムです。 これは、次のような他の完全にオプションの製品と非常によく統合されます。 領事 (キーと値のストア) または ボールト (秘密の処理)。 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
}

ここでキーを読み取ります service/geo-api/log-verbosity Consul から取得し、作業中に環境変数に公開します。 LOG_LEVEL。 鍵もプレゼントします secret/geo-api-key として保管庫から API_KEY。 シンプルだけどパワフル！

Nomad はそのシンプルさにより、API を介して他のサービスと簡単に拡張できます。 たとえば、タスクのタグがサポートされています。 すべてのサービスにメトリクスをタグ付けします trv-metrics。 このようにして、Prometheus は Consul 経由でこれらのサービスを簡単に見つけ、定期的にエンドポイントをチェックできます。 /metrics 新しいデータの場合。 たとえば、ログに対しても次のように同じことができます。 ロキ.

拡張性の例は他にもたくさんあります。

• フックを使用して Jenkins ジョブを実行すると、サービス構成が変更されたときに Consul が Nomad ジョブの再デプロイメントを監視します。
• Ceph は、分散ファイル システムを Nomad に追加します。
• ファビオ 負荷分散のため。

これによりすべてが可能になります インフラを有機的に発展させる ベンダーとの特別なつながりはありません。

公正警告

完璧なシステムはありません。 最新の機能をすぐに実稼働環境に導入することはお勧めしません。 もちろんバグや不足している機能はありますが、それは Kubernetes にも当てはまります。

Kubernetes と比較すると、Nomad コミュニティはそれほど大きくありません。 Kubernetes にはすでに約 75 のコミットと 000 人のコントリビューターがいますが、Nomad には約 2000 のコミットと 14 人のコントリビューターがいます。 Nomad は Kubernetes の速度についていくのに苦労しますが、おそらくそうする必要はありません。 これはより特殊なシステムであり、コミュニティが小さいため、Kubernetes と比較してプル リクエストが注目され、受け入れられる可能性が高くなります。

サマリー

結論: 他の人がやっているからといって Kubernetes を使用しないでください。 要件を慎重に評価し、どのツールがより有益かを確認してください。

大規模なインフラストラクチャ上に大量の同種のサービスをデプロイすることを計画している場合は、Kubernetes が良い選択肢です。 複雑さと運用コストが増加することに注意してください。 一部のコストは、次のようなマネージド Kubernetes 環境を使用することで回避できます。 Google Kubernetes エンジン または アマゾンEKS.

保守が容易で拡張可能な信頼性の高いオーケストレーターを探しているだけなら、Nomad を試してみてはいかがでしょうか。 これでどれだけ遠くまで行けるか驚かれるかもしれません。

Kubernetes を自動車に例えると、Nomad はスクーターに相当します。 あるものが必要な場合もあれば、別のものが必要な場合もあります。 どちらにも存在する権利があります。

出所： habr.com