コンテナ クラウドではどのような展開方法を採用すべきでしょうか?

週末に出席した技術セミナーでは、コンテナ クラウド プラットフォーム コンポーネント、ミドルウェア、マイクロサービスなどの展開について言及されました。仮想マシン、物理マシン、コンテナのどれを使用してデプロイする方がよいでしょうか?この問題については前回の記事で少し説明しました。標準的な答えはないかもしれません。人によって意見は異なります。諺にあるように、戦争の状態は一定ではなく、水の形も一定ではない。具体的なビジネス環境、ビジネスニーズ、技術要件などに基づいて適切なソリューションを選択する必要があります。ただし、コンテナ クラウド テスト、UAT、および本番環境にどのようなデプロイメント アーキテクチャと方法を採用するかについても検討しています。ここで私たちの考えを共有し、皆様のお役に立てれば幸いです。

[[228661]]

1. 完全にコンテナ化されたデプロイメントですか?

現在、ほぼすべてのコンテナ クラウド ベンダーは、コンテナ クラウドの交換と PoC 中にすべてのコンポーネントをコンテナ化する必要があることを強調しています。このインストールと展開方法は比較的簡単で、ワンクリック展開とコンテナ クラウド プラットフォームの構築に 30 分しかかかりません。しかし、PoC テストでは、コンテナ リソースの割り当て、Kubernetes マルチ クラスタの展開、制御ノードの高可用性の展開、イメージ リポジトリの配置と展開、ミドルウェアと異なる環境の展開と配置など、いくつかの問題も見つかりました。また、コンテナ クラウド プラットフォーム コンテナに異常があることもわかりました。新しいコンテナが作成された一方で古いコンテナが残ったため、多くの役に立たないコンテナがリソースを占有し、理解が困難になりました。これはプラットフォーム自体の実装の問題ではありますが、設計時にいくつかの問題が考慮されていなかったことは明らかです。

2. 環境管理

完全にコンテナ化されたデプロイメントの利点は、一貫性のある環境を迅速に構築できることであり、これは DevOps を実装する上で重要な側面でもあります。したがって、開発およびテスト環境での完全なコンテナ化された展開に問題はありません。これらの環境要件は急速に変化するため、開発およびテスト環境の従来のメンテナンスには多くの時間と人手が必要になります。コンテナ化されたアプローチを使用すると、開発およびテスト環境ドメインを迅速に構築して、サービス テストを完了できます。主に機能テストを完了します。パフォーマンス テストが必要な場合は、UAT 環境で実行することをお勧めします。 UAT 環境と運用環境では、一貫したソフトウェア、ハードウェア、および展開アーキテクチャが維持されます。集中ログ、監視、サービス登録と検出、サービス ゲートウェイなどのコンポーネントなど、UAT および実稼働環境のコンテナ クラウドの基本コンポーネントは、仮想マシンまたは物理マシンに展開することをお勧めします。このような導入の目的は、一方ではコンテナ クラウドの軽量な特性をより有効に活用することであり、他方ではセキュリティや運用保守管理などの考慮に基づいています。

私たちは常に、複雑な問題は簡単な方法で解決すべきだと言ってきました。コンテナクラウドインフラストラクチャをベースに、エンタープライズレベルのサービスプラットフォームを構築したいと考えています。企業は 1 つのログ システムと 1 つの監視システムを維持するだけでよく、毎回構築を繰り返す必要はありません。これらのコンポーネントは比較的固定されており、頻繁に変更する必要がなく、データは絶対に安全である必要があります。通常、集中型のログ記録システムや監視システムなどはクラスターに展開する必要があり、1 台のマシンと 1 つのインスタンスではニーズを満たすことができません。したがって、開発環境とテスト環境の目的は、コンテナの迅速な構築機能を活用することですが、UAT 環境と本番環境は安定して安全な状態を維持する必要があります。コンテナ クラウドを導入すると、環境管理と環境展開の面で大きな変化がもたらされます。

各環境は独立していますが、イメージ リポジトリを介して接続されており、イメージは各環境を接続する標準の成果物です。

3. 画像リポジトリ

コンテナ クラウド プラットフォーム上のイメージ リポジトリを見つけるにはどうすればよいですか? DevOps においてどのような価値が生まれるのでしょうか?これは、コンテナ クラウド プラットフォームの導入を検討する際に考慮してきた問題です。以前の議論では、イメージ リポジトリを開発とテストと本番環境の間の媒体として考える必要があると述べました。開発とテストは両方ともイメージ リポジトリで終了し、実稼働はイメージ リポジトリで開始されます。標準的な成果物として、環境間でイメージが配信されます。イメージ リポジトリは、イメージ セキュリティ チェックなどのメカニズムを通じてイメージのセキュリティを確保します。つまり、DevOps の継続的インテグレーションはイメージ リポジトリで停止し、イメージ リポジトリがデプロイメントと運用の開始点となります。

イメージリポジトリをコンテナにデプロイする必要がありますか?実際、私たちの意見ではこれはそれほど重要ではありません。まず、イメージリポジトリは基本的なコンポーネントであり、頻繁に変更する必要がないため、実際には安定したデプロイメントに適しています。さらに、パブリック イメージとプライベート イメージには大量のディスク領域が必要になるため、IO 容量が要因になります。イメージ リポジトリは、イメージの配布センターとして使用できます。これは、環境間または異なるクラスター間の媒体と呼べるものです。この観点から、イメージ リポジトリは、コンテナ クラウド プラットフォームのイメージ配信サービスとイメージ管理サービスのみを提供する独立した部分と見なすことができます。独立して展開でき、コンテナ クラウド プラットフォームに依存しません。物理マシンまたは仮想マシンへの展開がより適切な場合があります。もちろんコンテナ上での展開も可能です。

イメージ リポジトリの高可用性展開は考慮すべき事項であり、これは多くのコンテナ クラウド ベンダーが推進している重要な機能でもあります。十分なリソースがある場合でも、イメージ リポジトリに高可用性を展開することをお勧めします。結局のところ、これにより追加の保護層が提供され、予期しないイベントが軽減されます。ただし、高可用性ノードが多ければ多いほど良いです。通常は、プライマリノードとバックアップノードで十分です。高可用性を導入しなくても通常はそれほど多くの問題は発生しません。データが失われず、すぐに回復される限り、大きな影響はありません。

4. クラスターの展開

理論上、Kubernetes は数万のノードを管理できますが、現実には常に大きなギャップがあります。テストでは、ノード数が 500 を超えると Kubernetes クラスターがタイムアウトすることが示されています。Kube マスター ノードを追加しても、問題は実際には解決されません。したがって、各 Kubernetes クラスター内のノードの数は制限されます。 500 程度になると、最適化策を検討したり、業務ラインごとにクラスターを展開したりする必要があります。

通常、当社のような従来の企業では、ノードの数がすぐに 500 を超えることはなく、単一のクラスターで一定期間の需要を満たすことができます。ノードの数が増えると、Kube マスター ノードの数も増やす必要があります。実際、当初は、マスターノードがダウンしても業務アプリケーションの正常な動作に影響がないことを確実にできるKubernetesであれば、Kubernetesクラスターの管理が中断する期間を許容できると考えていたため、マスターノードの高可用性については考慮していませんでした。ただし、ノード数の増加により、マスターノードの高可用性の導入が必要になる場合があり、そうしないと、kubectl の正常な動作をサポートできなくなる可能性があります。ノードの数が増えると、マスターノードの数も増やす必要があります。ただし、マスター ノードの数が 10 を超えると、何らかの問題が発生するため、通常は 3、5、または 7 個のマスター ノードが適しており、数百のノードをサポートします。

そのため、初期段階では、シンプルなアプローチを使用して物事を簡素化し、大きなものを小さくし、ビジネスラインに基づいたマルチクラスター展開方法を採用することができます。これにより、各クラスターのノード数が 500 を超えないことが保証されます。制限を超える場合は、新しいクラスターを作成して分割することを検討してください。しかし、場合によっては、非常に大きなクラスターが必要になることがあります。現時点では、Mesos のほうがより良い解決策かもしれません。 「Kubernetes を 2500 ノードにスケーリングする」という記事から、Kubernetes では多くの最適化対策が必要になる可能性があることがわかります。まだそれほど多くのクラスターが存在するには程遠く、テストする条件も整っていないため、実現可能かどうかはわかりません。潜在的な問題があるかどうかはわかりませんし、メーカーはこの分野での経験があまりないようです。したがって、可能であれば、大規模なクラスターを複数の小さなクラスターに分割し、それらを事業ラインまたは地域ごとに分割することが実行可能な解決策となるはずです。

5. 制御ノード

制御ノードはマスターノードと呼ばれます。これはクラスターの脳と中枢神経系であり、クラスター全体の動作を制御および指示します。制御ノードが利用できない場合、クラスター全体が麻痺します。当初は、高可用性制御ノードを導入するために、これほど多くのリソースを占有する必要があるかどうかを検討しました。当社としては、制御ノードが時間内に復旧できる限り、一定期間利用できなくても許容できます。デプロイメントは常に発生するわけではありません。展開されたビジネス サービスが正常に実行され、ビジネスに影響が及ばない限り、制御ノードが一時的に利用できなくなっても大きな影響はありません。そのため、当初は高可用性の展開を考慮せずに、制御ノードの展開のみを検討しました。これも、ESB の運用と保守に関する当社の経験に基づいています。 ESB 制御および監視ノードの障害はビジネス サービスに影響を与えないため、ESB 制御および監視ノードをデバッグして復元する時間は十分にあります。ただし、Kubernetes は、ノードの数が増えると、制御ノードの高可用性展開を実現するために、より多くの制御ノードを展開する必要がある場合があるという点で ESB とは異なります。

Kubernetes コントロール ノードには、kube-apiserver、kube-controller、kube-scheduler、etcd などの複数のコンポーネントがあります。これらのコンポーネントは個別にデプロイされていますか、それとも 1 つのノードにデプロイされていますか?クラスター ノードの数が増えると、これも考慮する必要がある問題になる可能性があります。 Etcd は個別に展開する必要があり、さまざまなシナリオに応じて適切なディスクを選択する必要があります。異なる etcd クラスターを使用するかどうかも考慮する必要があります。たとえば、構成センターが etcd を使用する場合、プラットフォームと同じ etcd を共有するか、新しい etcd を作成するかは、具体的なノード数やその他の条件に基づいて決定する必要があります。 「Kubernetes を 2500 ノードにスケーリングする」という記事から、etcd はシリアル I/O を使用するため、I/O 間の遅延が重複することがわかります。ノード数が 500 を超えると、遅延が大幅に増加し、Kubectl 操作がタイムアウトする原因になります。そのため、etcd がローカル SSD ディスクに切り替えられた後、etcd はようやく正常になりました。さらに、Kubernetes イベントは別の etcd クラスターに保存することもできるため、イベントに対する操作はメインの etcd クラスターの通常の操作に影響を与えません。しかし、これにより、リソースへの投資が増加し、管理も複雑になります。

6. 基本的なコンポーネントの展開

私たちはこのことについて何度も議論してきました。コンテナ クラウド プラットフォームを構築するには、Kubernetes だけでは不十分です。ビジネス アプリケーション全体をサポートするには、多くの基本コンポーネントも必要です。たとえば、ログ記録、監視、構成、登録検出、サービス ゲートウェイなどのコンポーネント。これらのコンポーネントをコンテナにデプロイするか、仮想マシンまたは物理マシンにデプロイするかは避けられない問題です。

初期のノードとサービスの数が少ない場合は、基本コンポーネントのコンテナ化されたデプロイメントが適切な選択肢となる可能性があります。実際、開発およびテスト環境について述べたように、目的は高速かつ俊敏であることであるため、ボリュームは大きくなりません。ノード数が増加し、サービスの量が増えると、Kubernetes コンポーネント自体がボトルネックに遭遇するだけでなく、サービス ガバナンスやサービス管理などのプラットフォーム ベースのコンポーネントでも同じ問題に遭遇することになります。

7. ミドルウェアの展開

コンテナ クラウドを構築する重要な理由の 1 つは、クラウド ミドルウェアの機能を活用したいと考えていることです。ミドルウェア サービスがなければ、これらのサービスを構築するには多大な労力がかかりますが、幸いなことに、コンテナ クラウドにデプロイできるミドルウェアはすでに多数存在します。しかし、「量」の問題もあります。容量が大きい場合も対応できますか？コンテナ化されていないリソースよりも、サポートするために複数のリソースが必要になりますか?運用や保守に何らかの困難が生じるでしょうか?例えば、ある証券会社では 20 を超える Kafka クラスターがあり、メモリ構成は一般的に 64G で、SSD ハードドライブと RAID 5 冗長性を使用しています。このような構成はコンテナ クラウド プラットフォームには明らかに適していないため、仮想マシンまたは物理マシンに展開する必要があります。

開発環境とテスト環境では、引き続きコンテナ化された環境を使用することをお勧めします。運用時には、実際の状況やビジネス シナリオに基づいて適切な展開方法を選択します。データベースなどはあまり適していない可能性があります。サポートされており、デプロイも可能ですが、運用・保守、セキュリティ、コンポーネントの安定性などの観点から、コンテナ化されていないデプロイの方が適切な場合があります。

8. マイクロサービス/ビジネスサービスのデプロイメント

マイクロサービスはコンテナ上にデプロイする必要があります。目的は、コンテナの軽量、分離、標準化、および弾力性という特性を活用することです。マイクロサービス/ビジネス サービスは継続的に改善および更新する必要があることが多いため、開発の俊敏性だけでなく、サービス ライフ サイクル全体が十分に俊敏である必要があります。実際、この点から、コンテナ化されたデプロイメントは、頻繁に変更される軽量コンポーネントに適していることもわかります。基本的にあまり変更されないかさばるコンポーネントは、コンテナにデプロイしてもコンテナの利点を発揮できない可能性があります。コンテナを仮想マシンとして使用するのは、少し余計です。実際、多くの企業がコンテナ クラウドの採用と実装の第一歩として、インターネット アプリケーション シナリオをコンテナ クラウド上に展開することを選択するのは、おそらくこれらの理由によるものと思われます。偉大な心は同じように考えるようです。

また、コンテナ化された形式でデプロイする場合、各イメージが数百メガバイト、さらにはギガバイトと非常に大きくなる可能性があり、これは従来の ESB サービス デプロイのリソース要件とは大きく異なることも説明しました。コンテナ化により分離性が向上しますが、各コンテナでリソースが重複します。たとえば、Java アプリケーションの場合、通常は 1 台のマシンに 1 つの JDK をインストールするだけで、多数の Java アプリケーションを実行できます。しかし、コンテナの場合、各コンテナに JDK が必要なので、各イメージに JDK をパッケージ化する必要があり、ネットワーク転送、ストレージ、および実行時のリソースが節約されないようです。

参考文献

1.https://blog.openai.com/scaling-kubernetes-to-2500-nodes/?utm_source=digg