😋 😸 🥘 コンテナ：「マジックフレームワーク」を検索し、Kubernetesがその理由になった理由 🐔 👮 ➿

私たちLaterでは、通信事業者向けの請求書を作成しています。 Habréのブログでは、システムの機能とその開発の詳細（フォールトトレランスの確保など）だけでなく、インフラストラクチャ全体の操作に関する資料も公開しています。 Haleby.seのプロジェクトエンジニアは、Dockerコンテナを調整するツールとしてKubernetesテクノロジーを選択する理由を説明するブログ投稿を書きました。この記事の主な考えをご紹介します。

背景

プロジェクトエンジニアリングチームは、当初、各サービスにJenkinsの継続的デリバリー手法を使用していました。これにより、各コミットで統合テストを実行し、アーティファクトとDockerイメージを生成して、テストサーバーに展開できました。 1回クリックするだけで、任意のイメージを「戦闘」サーバーに展開できます。スキームは次のようになりました。

JohnおよびDoeというセルには、特定のノードにデプロイされたDockerコンテナーのセットが含まれています。さらに、 Ansibleはプロビジョニングに使用されます。その結果、新しいクラウドサーバーを作成して、正しいバージョンのDocker / Docker-Composeをインストールし、ファイアウォールルールを構成し、1つのコマンドで他の設定を実行できます。 Dockerコンテナで実行されている各サービスには、障害が発生した場合にサービスを「発生」させるウォッチドッグスクリプトがあります。ただし、この構成では問題が発生する可能性があります。

Doeサーバーが1晩で「燃え尽きる」（または短期的な重大な障害が発生する）場合、プロジェクトの技術チームはシステムを稼働状態に戻すために深夜に立ち上がる必要があります。 Doeにインストールされたサービスは、Johnなどの別のサーバーに自動的に移動しません。そのため、しばらくの間、システムが動作しなくなります。

他の問題もあります-コンテナの最大数の同じノード上の場所、ネットワーク検出（サービス検出）、「アップロード」更新、ログデータの集約。これらすべてに何らかの形で対処する必要がありました。

必要なのは、魔法のオーケストレーションフレームワークで、これを使用して、クラスターのノード間でコンテナーを分散できます。単一のノードと同じように多くのノードで作業できるようにする必要がありました。この魔法のフレームワークでは、「クラスター内のそのようなDockerコンテナーの3つのコピーを展開し、すべてが機能することを確認する」ことができる必要がありました。素晴らしい計画！残った唯一のことは、そのようなフレームワークを見つけることでした。

ウィッシュリスト

テクノロジーは非常に急速に開発されているため、非常に中程度の基準を満たす場合でも、一定期間存続し維持されるような方法でツールを選択する必要があります。 Halebyのエンジニアは、「夢のフレームワーク」で既に使用したdocker-composeのようなものを使用したいと考えています。これにより、多くの再構成と構成作業が不要になります。

さらに、フレームワークのシンプルさと、制御が困難なマジック機能が多すぎないことがプラスになります。ある種のモジュラーソリューションは完璧で、必要に応じて一部の部品を交換する可能性が残ります。オープンライセンスもプラスになります。この場合、プロジェクトの進行状況を追跡し、活発なコミュニティが存在することを確認するのは簡単です。

さらに、Halebyチームのメンバーは、同時に複数のクラウド内のコンテナーを操作するためのサポートと、ネットワーク検出機能の存在を希望しています。また、エンジニアはセットアップに多くの時間を費やすことを望まなかったため、サービスモデルとしてフレームワークを使用することをお勧めします。

フレームワークの選択

市場で利用可能なオプションの分析により、いくつかの候補フレームワークを選択することが可能になりました。それらの中で：

AWS ECS

AWS ECS Container Serviceは、Amazon EC2インスタンスクラスター内のDockerコンテナーを開始、停止、操作できる、非常にスケーラブルで高速なコンテナー管理ツールです。このクラウドでプロジェクトがすでに機能している場合、このオプションを考慮しないのは奇妙です。ただし、HalebyはAmazonで機能しなかったため、会社のエンジニアにとってこの移行は最良のソリューションではないように思われました。

さらに、システムにはネットワーク検出機能が組み込まれていないことが判明しました。これは重要な要件の1つでした。また、AWS ECSの場合、1つのノードの1つのポートを使用して多くのコンテナーを起動することはできません。

Docker swarm

Docker Swarmは、Dockerのネイティブクラスタリングツールです。 SwarmはDocker APIを使用しているため、Dockerデーモンと連携できるツールは、それを使用してスケーリングできます。 Halebyはdocker-composeを使用しているため、後者のオプションは非常に魅力的でした。さらに、使い慣れたテクノロジのネイティブツールを使用することで、チームは何か新しいことを学ぶ必要がなくなりました。

しかし、すべてがそれほどバラ色ではありませんでした。 Swarmはネットワーク検出のために複数のエンジンをサポートしているという事実にもかかわらず、実行可能な統合を設定することは簡単な作業ではありません。さらに、Swarmはマネージドサービスではないため、プロジェクトチームの計画に元々含まれていなかった作業を自分で構成および保守する必要があります。

さらに、コンテナを自動的に更新することもできません。これを行うには、たとえば、コンテナのさまざまなグループのロードバランサーとしてNginxを構成する必要があります。また、インターネット上の多くのエンジニアがSwarmのパフォーマンスについて疑問を表明しました。たとえばGoogle社員などです。

メソスフェアDCOS

AWSでDCOS（データセンターオペレーティングシステム）を設定して作業を開始した後、Mesosphereは適切なオプションのようです。便利なインターフェイスを使用すると、実行中のサービス、プロセッサの負荷、メモリ消費など、クラスターに関するすべての情報を取得できます。 DCOSは、どのクラウドでも、一度に複数のクラウドで動作できます。 Mesosは、大規模なクラスターで機能することが実証されているツールです。 DCOSでは、コンテナーだけでなく、Rubyなどの個々のアプリケーションも実行でき、シンプルなdcos installコマンドを使用して重要なサービスをインストールできます（これはデータセンターのapt-getに似ています）。

さらに、このツールを使用すると、複数のクラスターを同時に操作できます。同じシステム内でMarathon、Kubernetes、Docker、Swarmを実行できます。

ただし、長所とともに、このオプションには欠点もありました。たとえば、複数のクラウドでの作業のサポートは、Mesosphere DCOSのエンタープライズバージョンにのみ存在しますが、このバージョンの価格はサイトに記載されておらず、リクエストに応答する人はいません。

また、当時のドキュメント（2015年10月/ 11月）には、システムを中断することなく新しいクラスターに移動する方法に関する情報が含まれていませんでした-これは管理されたサービスでもないため、移動中に問題が発生する可能性があることを理解することが重要です。

腫瘍

プロジェクトチームはそれを「開発および運用のためのDockerプラットフォーム」と説明し、「あらゆるクラウドでアプリケーションを構築、展開、管理する」というスローガンが聞こえます。インターフェイスは次のようになります。

DCOSほど壮観ではないように思えるかもしれませんが、それでもTutumにはコマンドラインサポートがありますが、システムは単純なマウスクリックでほとんどの必要な操作を実行できます。システムの操作を開始するには、クラスターの各ノードにTutumエージェントをインストールする必要があります。その後、管理パネルにノードが表示され始めます。興味深い点-Tutumは、いくつかのサービスまたはコンテナーからのスタック広告フォーマットを使用します。これは、docker-composeに似ています。そのため、Dockerに精通している専門家はさらに簡単に始めることができます。

さらに、TutumはFlockerクラスターへの統合を通じてボリュームをサポートします。特定のコンテナが「強制終了」されたテストは正常に合格しました-それらは同じ状態で（時には異なるノードで）再作成されました。別のプラスは、コンテナ間のリンクを作成する機能でした-その助けを借りて、特定のコンテナをグループに関連付けることができます。

負荷分散には、仮想ホストをサポートするHAProxyが使用されるため、HAProxyインスタンスごとに複数のサービスをホストできます。サービスのデプロイもさまざまな方法で実行でき、クラスター全体のDockerを数回クリックするだけで更新できます。将来、DockerはTutumサービスを購入したため、将来はエコシステムに完全に統合されます。

ただし、最適なフレームワークの検索時に、Tutumはベータテスト中です。それにもかかわらず、このオプションに対する主な議論は、テスト中にエンジニアが特別にノードに完全にアクセスできないようにした場合のインシデントでした-CPUを100％ロードすると、SSH経由でマシンに接続することさえできず、そのコンテナは別のノードに転送されませんでした。 Tutumテクニカルサポートは、この問題に精通していると述べていますが、まだ修正されていません。さらに検索する必要がありました。

クベルネテス

Kubernetesチームは、プロジェクトを「Linuxコンテナのクラスタを単一システムとして管理して、開発を高速化し、運用を簡素化する」ツールとして説明しています。これはGoogleがサポートするオープンプロジェクトであり、Red Hat、Microsoft、SaltStack、Docker、CoreOS、Mesosphere、IBMなど、他の多くの企業が開発に関与しています。

Kubernetesの優れている点は、クラスターの構築と操作に関するGoogleの10年の経験をすべて無料で組み合わせていることです。 Kubernetesは、独自のハードウェア上で、またはAWSなどの特別なフォーメーションテンプレートもあるクラウドプロバイダーの能力上で実行できます。

さらに、GoogleはGoogle Container Engineと呼ばれる管理されたバージョンのKubernetesを提供しています。インターフェイスの欠陥により、Tutumの場合ほど簡単に作業を開始することはできませんが、ユーザーがシステムを理解した後は、その操作が簡単になります。

エンジニアチームは多くのテストを実施しました。その間に、更新の更新プロセスでノードが「強制終了」され、コンテナがランダムに破壊され、その数が宣言された最大バーを超えました。常にすべてが問題なく実行されたわけではありませんが、いずれの場合も、特定の検索の後、状況を修正する方法を見つけることができました。

Kubernetesのもう1つの重要な利点は、中断することなくクラスター全体をアップグレードできることです。また、ネットワーク検出が機能していることもテストで確認されました。目的のサービスの名前（ http://my-service ）をアドレスバーに入力するだけで、Kubernetesは目的のコンテナへの接続を作成します。 Kubernetesは、コンポーネントを組み合わせることができるモジュラーシステムです。

フレームワークには欠点もあります-Google Container Engineを使用する場合、システムは1つのデータセンターに制限されます。彼に何かが起こった場合、良いことは何も起こりません。たとえば、ロードバランサーを使用して複数のクラスターを整理するなど、あらゆる状況から抜け出すことができますが、すぐに使用できるソリューションはありません。ただし、新しいバージョンのUbernetesフレームワークの新しいバージョンでは、複数のデータセンターでの作業のサポートが計画されています。さらに、Kubernetesはyaml形式を使用するため、docker-composeファイルの変換が必要になります。さらに、このプロジェクトは同じMesosほど開発されていないため、多数のノードで作業できます。

おわりに

市場で利用可能なオプションを調査した後、HalebyチームはKubernetesに決着しました。Kubernetesは、問題を解決するのに最適なツールであるとエンジニアに思われました。同時に、他の考慮されたサービスも良い面に現れましたが、彼らには欠点があり、この場合は受け入れられないことが判明しました。

コンテナ：「マジックフレームワーク」を検索し、Kubernetesがその理由になった理由

背景