Kubernetesをマルチクラウドやハイブリッドクラウド環境に適用する場合は、次の点に注意してください。

競争で優位に立つために、組織は常に、運用効率と経済効率を最大化しながら、スピードと俊敏性をもってイノベーションを推進しようと努めています。このため、同社はかなり前からアプリケーションをマルチクラウドおよびハイブリッドクラウド環境に移行してきました。

当初、これらのアプリケーションは、元のモノリシック アーキテクチャを維持しながら、「リフト アンド シフト」アプローチを使用してクラウドに移行されました。ただし、このようなモノリシック アプリケーションでは、弾力性や分散コンピューティングなど、クラウドが提供する利点を十分に活用できず、保守や拡張も困難です。

そのため、次の進化のステップとして、組織は既存のモノリシック アプリケーションを再構築したり、新しいコンテナ化されたアプリケーションを開発したりし始めています。

ただし、コンテナ化されたアプリケーションのデプロイと管理は複雑な作業であり、ここで Kubernetes が役立ちます。Kubernetes (K8s とも呼ばれる) は、もともと Google によって開発されたコンテナ オーケストレーション ツールであり、パブリック クラウドとプライベート クラウドでコンテナ化されたアプリケーションをデプロイするためのプラットフォームとして急速に選ばれるようになりました。

K8s を使用することで、組織はこれらのコンテナ化されたアプリケーションをパブリック クラウドとプライベート クラウドに最初に導入して管理できるようになります。しかし、Kubernetes アプリケーションへの安全で信頼性の高いアクセスを確保するための制御を維持しながら、エンドユーザーが Kubernetes アプリケーションをシンプルかつ自動的に外部からアクセスできるようにするなどのその後のステップで苦労しました。

その主な理由は、これらのアプリケーションのフロントエンドとして使用され、エンドユーザーがアクセスできるようにする従来のロードバランサーがモノリシック アプリケーションを念頭に設計されていたため、Kubernetes アプリケーションをアジャイルにデプロイする方式に対応できないことです。

これらのロード バランサは、アプリケーションのネットワーク リソースがネットワーク チームとセキュリティ チームによって手動で構成され、数日または数週間かかる可能性のあるプロセスを経て、ロード バランサ上で手動で構成される展開プロセス用に設計されています。このプロセスは明らかに Kubernetes アプリケーションのデプロイメント プロセスとの同期には適していないため、デプロイメント プロセス全体のボトルネックになります。

この問題をさらに悪化させているのは、マルチクラウドおよびハイブリッドクラウド環境にアプリケーションを展開する場合、各パブリッククラウドプロバイダーが独自のカスタムロードバランサーと管理システムを持っていることです。

たとえば、AWS には独自の Elastic Load Balancing ソリューションがありますが、これは Microsoft の Azure Load Balancer とは異なります。これにより、アプリケーションの展開を自動化するタスクがより複雑になり、時間がかかります。また、各ロード バランサには独自の独立した構成と操作があるため、異なるクラウド環境にわたって一貫したポリシー セットを適用するタスクでエラーが発生しやすくなります。

それで、解決策は何でしょうか?

Kubernetes アプリケーションの導入に対応するには、導入および拡張されるアプリケーションをロードバランサーが動的に管理できるようにするアクセス ソリューションが必要です。

これを実現する 1 つの方法は、イングレス コントローラーまたはコネクタ プロキシをデプロイして、外部ロード バランサーを Kubernetes アプリケーションに接続することです。このコネクタは、これらのアプリケーションのライフサイクルを監視し、その情報を使用してロード バランサーを自動的に更新し、トラフィックをアプリケーションにルーティングします。これにより、新しいサービスが K8s クラスターにデプロイされるときに外部ロードバランサーを構成するプロセスが大幅に簡素化および自動化され、手動構成プロセスに関連する遅延が排除されます。

外部ロードバランサーの動的かつ自動的な構成をサポートすることに加えて、ソリューションには理想的には次の特性が必要です。

• クラウドに依存しない: 上記のプロセスは単一のクラウドに展開されたときに機能しますが、マルチクラウドおよびハイブリッド クラウド環境で実際に機能させるには、ソリューションが物理、仮想、コンテナーなどのさまざまなフォーム ファクターで利用可能であり、パブリック クラウドとプライベート クラウドの両方に展開できる必要があります。さまざまなクラウド環境で一貫して機能するソリューションがあれば、アプリケーションがどのクラウドで実行されているかに関係なく、一貫したポリシー セットを適用してアプリケーションにアクセスできるようになるという関連するメリットも得られます。これにより、より安全な展開が実現し、あるクラウド展開から別のクラウド展開に構成を移植するときに発生する可能性のあるエラーを回避できます。
• 自動化ツールのサポート: ソリューションは、アプリケーションの展開と日常の運用プロセス全体を自動化できるように、Terraform、Ansible、Helm などの自動化ツールをサポートする必要があります。
• 柔軟なライセンス モデル: ソリューションは、変化するビジネスおよびアプリケーションのニーズに適応するために複数のサイト間で容量を割り当てて割り当てることで組織がコストを最適化できるようにするソフトウェア サブスクリプション モデルを提供する必要があります。
• 一元化された可視性と分析: 最後に、ソリューションは一元化された可視性と分析を提供する必要があります。これにより、プロアクティブなトラブルシューティングと迅速な根本原因分析が可能になり、アプリケーションの稼働時間が向上し、エンドユーザーの満足度が確保されます。

アプリケーションをコンテナ化されたアプリケーションとしてマルチクラウドおよびハイブリッド クラウド環境に移行すると、柔軟性や運用効率の向上など、多くの利点が得られます。ただし、従来のロード バランサはモノリシック アプリケーションを管理するために構築されており、コンテナ化されたアプリケーションの展開を妨げ、クラウド展開のメリットを十分に享受できない可能性があります。

さらに、クラウド固有のロードバランサーを使用すると、ハイブリッド クラウド インフラストラクチャの管理が複雑になります。外部ロードバランサーに接続するイングレス コントローラーまたはコネクタ プロキシをデプロイすることで、IT チームは、K8s クラスター内に新しいサービスをデプロイするときに、外部ロードバランサーを構成するプロセスをより効果的に簡素化および自動化できます。

オリジナルリンク: https://thenewstack.io/kubernetes-applications-for-multicloud-hybrid-cloud-environs/