※本ブログは、米国時間3月31日に公開されたA10本社ブログの抄訳を基にしています

Kubernetes (K8s) とは、もともとGoogleによって開発されたコンテナオーケストレーションツールであり、パブリッククラウドやプライベートクラウド上にコンテナ化されたアプリケーションをデプロイするプラットフォームとして急速に採用が進んでいます。

DevOpsチームにとってK8sとは、様々なクラウド環境へアプリケーションをデプロイし、複雑なクラウドインフラストラクチャ基盤を抽象化し、彼らの業務に集中できるようにする共通プラットフォームです。一方で、組織は、顧客ニーズに対して最適なアプリケーションをクラウド上にデプロイできる柔軟性と、コストの最適化を同時に実現できるようになります。

しかし、この様々なクラウドにアプリケーションをデプロイできるという柔軟性は、一方でエンドユーザーに対して、信頼性の高い一貫したアクセス環境を提供しなければならないという課題を生みます。たとえば、アプリケーションをプライベートクラウドからパブリッククラウド (AWSやAzureなど) へ移行するときに、利用のしやすさや、パフォーマンス、信頼性、セキュリティをプライベートクラウドと同程度に確保するには、どのようにすれば良いのでしょうか。

エンドユーザーがアプリケーションを利用しやすくするため、K8sでは次のオプションがサポートされています。

NodePort：各ノードにポート番号が割り当てられ(NodePortと呼ばれます) 、エンドユーザーはノードのIPアドレスとポート番号を使ってアプリケーションにアクセスできます。このオプションでは、ノード間でトラフィックを分散させるためにロードバランサーを手動で設定する必要があります。

ロードバランサー：このオプションでは、NodePortと同様に各ノードにポート番号を割り当てますが、さらに外部のロードバランサーとも接続します。このオプションは基盤となるクラウドプロバイダーインフラとの連携が必要となり、一般的にこの種の連携オプションを持つパブリッククラウドプロバイダーで使用されます。ただし、この密な連携により、他のクラウドプロバイダーへアプリケーションを移行する際、難度が上がりエラーが発生しやすくなります。

Ingressコントローラー：K8sでは、クラスター内で実行されるアプリケーションへHTTPおよびHTTPSトラフィックをルーティングするIngressコントローラーを定義することができます。Ingressコントローラーは、外部ロードバランサーを不要にするものではありません。ロードバランサーの場合と同様に、各パブリッククラウドプロバイダーには独自のロードバランサーと連携して動作する独自のIngressコントローラーがあります。たとえば、AzureにおけるAKSの Application Gateway Ingress Controller (AGIC) は、Azure Application Gatewayと連携して動作するIngressコントローラーです。したがってこのオプションでも、ユーザーのアプリケーションアクセス環境は、クラウド環境に固有のものとなります。

上記オプションではいずれも、クラウド非依存のソリューションが提供されないのは明らかです。また、クラウドプロバイダーのカスタマイズされたロードバランサーまたはIngressコントローラーを使用すると短期的には迅速化かつ簡素化できますが、複数の異なるソリューションを処理する必要があるため、全体として管理が複雑になり、自動化が妨げられることになります。

したがって以下の特性を持つソリューションが望ましいと言えます。

クラウド非依存：パブリッククラウドとプライベートクラウドの両方で機能し、様々なフォームファクタ (仮想、物理、コンテナなど) をサポートすることで、利用する環境に最適な形態でデプロイできるものである必要があります。

ロードバランサーの動的設定：Podが新規作成/スケールアップ/スケールダウンされる際、K8sクラスター内で実行されているPodにトラフィックをルーティングできるよう、ロードバランサーを動的に設定できる必要があります。

自動化ツールのサポート：CI/CDパイプラインなどの既存のDevOpsプロセスに統合するための自動化ツールをサポートする必要があります。

一元化された可視性と分析：可視化と分析を一元的に行えるソリューションである必要があります。 これにより、事前予防的なトラブルシューティング、迅速な根本原因の分析が可能になり、アプリケーションの稼働時間を改善できます。

A10のソリューションがどのように役立つか

A10は、A10 Thunder® ADCとA10 Thunder Kubernetes Connector (TKC) により上記の特性を満たすソリューションを提供しています。

A10 Thunder ADC：仮想、物理、コンテナなどの複数のフォームファクタに対応しており、マルチクラウド環境とハイブリッドクラウド環境の両方にデプロイできます。 K8sクラスターの外部に配置され、クラスター内で実行されているアプリケーション宛のトラフィックを負荷分散します。 このように機能させるにはA10 Thunder ADCの設定が必要ですが、TKCによってその設定が行われます。

TKC：TKCはK8sクラスター内でコンテナとして実行され、Podが新規作成/スケールアップ/スケールダウンされる際、A10 Thunder ADCを自動設定します。

TKCは入力情報としてIngress Resourceファイルを受け取ります。このファイルには、ユーザーリクエストをリッスンする際の仮想IP (VIP)、プロトコル (httpなど)、ポート番号 (80など)、トラフィックを転送するノード一覧を含むサービスグループの名前など、A10 Thunder ADCに設定するSLB (Server Load Balancing) パラメーターが含まれています。

Ingress Resourceファイルでは、A10 Thunder ADCでSLB設定が行われるK8sクラスター内のサービスも指定されます。TKCは該当するPodが新規作成/スケールアップ/スケールダウンされることで生じるサービスの変更をK8s APIサーバー (kube-apiserver) を用いて監視し、これらPodが実行されているノードを追跡します。次に、A10 Thunder ADCに対してaXAPI (REST API) コールを行い、これらノードをサービスグループのメンバーとして自動的に設定します。

これにより、新しいサービスがK8sクラスター内にデプロイされるときにA10 Thunder ADCの設定手順を大幅に簡素化し、自動化することができます。またIngress Resourceファイルを使ってSLB設定パラメーターを指定できるため、設定コマンドの学習に時間を費やす必要がなくなり、DevOpsエンジニアの学習時間が短縮されます。

Podへのトラフィック送信に関して、A10のソリューションは2つの主要動作モードをサポートします。

ノードレベルでの負荷分散：A10 Thunder ADCはアプリケーションの各ノードに割り当てられたNodePortにトラフィックを送信します。トラフィックがノードに到達すると、K8sクラスターによって内部的に負荷分散され、Pod宛に送信されます。この方法において、負荷分散はPodレベルではなくノードレベルで機能します。つまり、1つのノードに10個のPodがあり、別のノードに20個のPodがある場合、2つのノード間ではトラフィックを均等に分散 (ラウンドロビンによる負荷分散を想定) できますが、Podレベルでは不均等なトラフィック分散となります。

Podレベルでの負荷分散：今後のリリースでは、TKCがA10 Thunder ADCをプログラミングし、K8sクラスターの内部負荷分散メカニズムをバイパスさせてPodにトラフィックを直接送信できるようになります。これは、各ノード上のPodネットワークを宛先とするIP-in-IP tunnelを使用して実現されます。このモードでは、負荷分散はPodレベルで実行されるため、Pod間でバランスの取れたトラフィック分散が保証されます (ラウンドロビンによる負荷分散を想定)。ただし、このオプションではK8sクラスターで使用されるContainer Network Interface (CNI) プラグイン (Calico CNIプラグインなど) がPodサブネットのアドバタイズをサポートしている必要があります。

TKCによるA10 Thunder ADCの自動設定の他に、A10のソリューションには以下の利点もあります。

自動化ツールのサポート：A10のソリューションはTerraformやAnsibleなどの自動化ツールをサポートすることで、既存のDevOpsプロセスと簡単に統合できます。

L4/L7の負荷分散のサポート：A10のソリューションを使用すると、要件に応じてL4とL7の両方の負荷分散を柔軟に実行できます。これは、L7 (HTTP / HTTPS) ルーティングのみをサポートするIngress コントローラーソリューションとは異なる点です。

高性能トラフィック管理：A10 Thunder ADCは、ヘッダーの書き換え、帯域またはアプリケーションレートの制限、セキュリティポリシーのためのTLS暗号スイートなど、エンタープライズレベルのトラフィック管理ポリシーを提供します。

一元化されたポリシー：すべてのアプリケーショントラフィックがA10 Thunder ADCを通過するため、セキュリティや一般的なビジネスの要件に関連するポリシーの適用・施行のための中心点として提供されます。

一元化された分析：A10 Harmony Controller®とともに導入すると、DevOps / NetOpsチームは一元化されたトラフィック分析が得られ、トラブルシューティングをより容易かつ迅速に実施し、より安定した稼働時間と顧客満足度を実現できます。 A10のソリューションは、Prometheus / Grafanaなどのオープンソース監視ツールもサポートしているため、継続して活用することができます。

柔軟なライセンス：ソフトウェアサブスクリプションモデルであるFlexPoolを使用すると、ビジネスやアプリケーションのニーズ変化に応じて複数サイトに容量を分散して割り当てることができ、柔軟性を得られます。

利用を開始するには

TKCの動作デモを確認するには、A10ウェビナーのK8sの高度なアプリケーションアクセス (Advanced Application Access for Kubernetes、英語) を参照してください。

TKCを実際に利用するには、DockerリポジトリからTKCイメージをダウンロードし、TKC設定ガイドに概説されている手順に従ってください。