このリリースでは、Consul の多くの機能が強化され、Consul on Kubernetes CNI プラグインやクラスター ピアリング ベータ版などの新機能も追加されています。

2日前、HashiCorpはConsul 1.13を正式にリリースしました。このバージョンは、組織が運用上の複雑さを軽減し、大規模環境でConsulを効率的に実行し、サービスメッシュをアプリケーションワークフローに安全に統合する上で、新たな大きな前進となります。

Consul 1.13 の新機能には、Consul on Kubernetes CNI プラグイン、Envoy トラブルシューティング用の CLI 機能強化、終端ゲートウェイの機能強化、クラスター ピアリング (ベータ版) が含まれます。

Kubernetes CNI プラグインの Consul

デフォルトでは、Consul on Kubernetes は init コンテナ​consul-connect-inject-init​を挿入します。このコンテナはサイドカープロキシを設定することで透過プロキシトラフィックのリダイレクトを設定し、アプリケーションが変更を加えることなくメッシュ内で容易に通信できるようにします。透過プロキシを設定するためにポッドに init コンテナをデプロイするには、 ​CAP_NET_ADMIN​ Linux 機能を持つコンテナをデプロイするのに十分な Kubernetes RBAC 権限がポッドに必要です。しかし、このようなエスカレートされた権限でデプロイするようにポッドを構成することは、セキュリティ基準が非常に厳しい組織にとっては問題があり、メッシュ導入の障害となります。

Consulリリース1.13の一部として、Kubernetes版Consulは、ポッドライフサイクルのネットワークセットアップフェーズでトラフィックリダイレクト設定を処理するためのチェーン​CAP_NET_ADMIN​ （コンテナネットワークインターフェース）プラグインを配布します。これにより、initコンテナを使用してトラフィックリダイレクトルールを適用する必要がなくなり、サービスメッシュへのワークロードのデプロイ時に権限付与の必要がなくなります。CNIプラグインはconsul-k8s ^[1] 0.48.0でリリースされる予定で、Consul 1.13でサポートされます。

Kubernetes CLI 上の Consul による Envoy トラブルシューティングの強化

サービスメッシュにおけるトラフィック管理の問題を診断する際、ユーザーは多くの場合、Envoyプロキシ構成を利用して、メッシュへのアプリケーションのデプロイ時に発生する構成上の問題を迅速に特定し解決します。Consul on Kubernetesでは、 ​consul-k8s proxy list​と​consul-k8s proxy read <pod name>​ 。

` ​consul-k8s proxy list​コマンドは、Consul 管理の Envoy によってプロキシされているすべてのポッドのリストを表示します。ポッドは​Type​とともにリストされ、タイプによってプロキシがサイドカーなのか、Consul でデプロイされたゲートウェイの一部なのかが決まります。

名前空間: すべての名前空間

名前空間名タイプ
領事 consul-ingress-gateway-6fb5544485-br6fl イングレスゲートウェイ
領事 consul-ingress-gateway-6fb5544485-m54sp イングレスゲートウェイ
デフォルトのバックエンド-658b679b45-d5xlb サイドカー
デフォルトクライアント-767ccfc8f9-6f6gx サイドカー
デフォルトクライアント-767ccfc8f9-f8nsn サイドカー
デフォルトクライアント-767ccfc8f9-ggrtx サイドカー
デフォルトのフロントエンド-676564547c-v2mfq サイドカー

​consul-k8s proxy read <pod name>​コマンドを使用すると、特定のポッドで実行されている任意の Envoy インスタンスの設定を調べることができます。デフォルトでは、このコマンドは、Envoy プロキシによって設定されている利用可能な Envoy クラスター、リスナー、エンドポイント、ルート、およびシークレットの一覧を以下のように表示します。

名前空間のデフォルトの backend-658b679b45-d5xlb のEnvoy 構成:

 = = > クラスター (5)
名前 FQDN エンドポイント タイプ 最終更新
ローカルエージェント ローカルエージェント192 .168.79.187:8502 静的2022 -05 -13T04 :22:39.553Z
クライアント client.default.dc1.internal.bc3815c2-1a0f-f3ff-a2e9-20d791f08d00.consul 192 .168.18.110:20000, 192 .168.52.101:20000, 192 .168.65.131:20000 EDS 2022-08-10T12 : 30 : 32.326Z
フロントエンド frontend.default.dc1.internal.bc3815c2-1a0f-f3ff-a2e9-20d791f08d00.consul 192 .168.63.120:20000 EDS 2022 -08 -10T12 :30:32.233Z
 local_app local_app 127.0.0.1:8080 静的2022-05-13T04 : 22 :39.655Z
元の宛先 元の宛先 ORIGINAL_DST 2022 -05 -13T04 :22:39.743Z


 = = > エンドポイント (6)
アドレス:ポート クラスタ ウェイト ステータス
192 .168.79.187:8502 local_agent 1 .00 [32分正常[0分
192 .168.18.110:20000 client.default.dc1.internal.bc3815c2-1a0f-f3ff-a2e9-20d791f08d00.consul 1 .00 [32分正常[0分
192 .168.52.101:20000 client.default.dc1.internal.bc3815c2-1a0f-f3ff-a2e9-20d791f08d00.consul 1 .00 [32分正常[0分
192 .168.65.131:20000 client.default.dc1.internal.bc3815c2-1a0f-f3ff-a2e9-20d791f08d00.consul 1 .00 [32分正常[0分
192 .168.63.120:20000 frontend.default.dc1.internal.bc3815c2-1a0f-f3ff-a2e9-20d791f08d00.consul 1 .00 [32分正常[0分
127 .0.0.1:8080 local_app 1 .00 [32分正常[0分

= = > リスナー (2)
名前 アドレス:ポート 方向 フィルターチェーン 一致フィルター 最終更新
public_listener 192 .168.69.179:20000 受信 任意の * から local_app/ 2022 -08 -10T12 :30:47.142Z
 outbound_listener 127 .0.0.1:15001 アウトバウンド10 .100.134.173/32, 240 .0.0.3/32 から client.default.dc1.internal.bc3815c2-1a0f-f3ff-a2e9-20d791f08d00.consul へ2022 -07 -18T15 :31:03.246Z
 10 .100.31.2/ 32、240 .0.0.5/32 を frontend.default.dc1.internal.bc3815c2-1a0f-f3ff-a2e9-20d791f08d00.consul へ
任意の宛先

ルート( 1 )
名前 宛先クラスター 最終更新
パブリックリスナー local_app/ 2022 -08 -10T12 :30:47.141Z

 == >秘密 (0)
名前 タイプ 最終更新日

終端ゲートウェイの機能強化

ユーザーは、終端ゲートウェイを介してすべての外部宛先（Consulに登録されているサービスと登録されていないサービス）へのルートを接続できるようにしたいと考えています。目標は、メッシュから出るトラフィックに既知の出口ポイントを確立し、定義されたアクセスポリシーに従って接続を承認し、トラフィックがサービスメッシュから出る前にセキュリティ要件を満たしていることを確認することです。バージョン1.13では、Consulの終端ゲートウェイが拡張され、透過プロキシを使用して外部サービスと通信できるようになりました。

Consul 1.13より前のバージョンでは、下流サービスは、静的に設定された上流サービス^[2]を介してサービスを公開するか、透過プロキシを使用してConsulが割り当てた仮想サービスホスト名^[3]を使用してサービスに接続することにより、終端ゲートウェイを介して外部サービスにアクセスできました。場合によっては、サービスメッシュ内のアドレスではなく、実際のホスト名（例： www.example.com ^[4] ）を使用して外部サービスと通信することが必要または望ましい場合があります。

Consul 1.13 では、管理者が下流のサービスからアクセスできる許可された外部ホスト名または IP アドレスのリストを作成できるようにすることで、外部サービスとのシームレスな通信が可能になり、これらの接続が、送信トラフィックの中央出口ポイント サービス メッシュとして機能する終端ゲートウェイに集約されます。

クラスタピアリング（ベータ版）

大企業では、プラットフォームチーム^[5]の役割は、組織全体に標準的なネットワークソリューションを提供することです。これらのチームは通常、クラウドプロバイダーやランタイムプラットフォームについては既に独自の選択を行っていますが、プラットフォームチームは依然としてチーム間の安全な接続を実現する必要があります。これを実現するには、組織はどこでも利用できるConsulのような共有ネットワーク技術を必要とします。Consulはバージョン1.13で​cluster peering​という新機能を追加し、チーム間の接続機能を強化しました。

クラスタピアリング前

Consulの現在のフェデレーションモデルは、すべてのConsulデータセンター^[6] （クラスタとも呼ばれる）が共通の管理制御によって管理されるという考え方に基づいています。セキュリティキー、ポリシー、アップグレードアクティビティはフェデレーション全体で調整されることが想定されています。メッシュ構成とサービスIDもグローバルであるため、サービス固有の構成、ルーティング、インテント^[7]は、すべてのデータセンターにわたって単一の情報源を持つ同じチームによって管理されることが想定されています。

このモデルでは、データセンター間のフルメッシュネットワーク接続に加え、リモートデータセンターへの比較的安定した接続も必要です。これがお客様のインフラストラクチャ管理スタイルに合致する場合、WANフェデレーションは比較的シンプルなソリューションを提供します。最小限の設定で、各サービスはすべてのデータセンターにわたる他のすべてのサービスに接続できます。

公共管理の境界

WAN フェデレーションの利点は次のとおりです。

• 共有キー
• コーディネーションのアップグレード
• 静的プライマリデータセンター

しかし、多くの組織では、異なるネットワーク境界にまたがる独立したチームによって管理されている環境にConsulを導入しています。これらのチームは通常、運用上の自律性を維持しながら、フェデレーション内の他のクラスタで定義された構成と競合することなく、ニーズに応じたサービスメッシュ構成を定義しつつ、一部のクラスタ（すべてではない）とのサービス接続を確立する必要があります。これは、WANフェデレーションモデルのいくつかの制限を浮き彫りにしています。

• メインデータセンターへの接続によって異なります。
• 連合全体のリソースは同じであると想定します。
• 複雑な中心放射状トポロジをサポートするのは困難です。

クラスタピアを使用する

管理境界を分離する

クラスタピアリングにより、各クラスタは自律的に動作し、独自のキー、ディレクトリ、アクセス制御リスト（ACL）情報を保持します。プライマリデータセンターという概念はありません。

クラスタ管理者は、接続する必要があるクラスタと明示的に関係（「ピア」）を確立します。ピアクラスタは、他のピアに明示的に公開されているサービスに関するカタログ情報を自動的に交換します。

クラスターピア

Consul 1.13 のオープンソース バージョンでは、クラスター ピアリングにより、オペレーターはネットワーク トポロジやチームの所有権に関係なく、Consul データ センター間で安全なサービス接続を確立できるようになります。

クラスタピアリングは、チーム、クラスタ、ネットワーク境界のあらゆる組み合わせにわたってサービスを接続できる柔軟性を提供します。そのメリットは次のとおりです。

• きめ細かな接続
• 最小限の結合
• 運用の自主性
• 中心放射状のピア関係をサポートする

クラスター ピアリングにより、ユーザーは相互 TLS によって提供されるセキュリティと独立したサービス メッシュ間の自律性を維持しながら、内部および外部の組織の境界を越えてアプリケーションを安全に接続できます。

Consul Enterprise のクラスタピアリング

管理パーティションは、 Consul 1.11 ^[8]で導入されたエンタープライズ機能です。これにより、複数のチームが単一の共有Consulコントロールプレーンを使用して、本番環境サービスを開発、テスト、実行するためのマルチテナンシーが向上します。管理パーティション^[9]により、プラットフォームチームは共有サーバーを運用し、複数のアプリケーションチームやクラスタをサポートできます。ただし、Consul 1.11 の管理パーティションは、単一リージョン内の同一サーバー上のパーティション間の接続のみをサポートします。

クラスタピアリングにより、パーティション所有者は同じConsulデータセンター内または異なるリージョンにあるクラスタまたはパーティションとピアリング関係を確立できるようになりました。ピアリングは、同じConsulサーバーを共有する場合でも、他のチームに属するパーティションとは独立して機能します。

Consul Enterprise のクラスタピアリング

クラスター ピアリングは Consul の魅力的な新機能であり、オペレーターが組織の境界を越えてサービスを接続する際に柔軟性を高めることができます。

クラスタ ピアツーピアは、WAN フェデレーションを直ちに置き換えるものではありません。長期的には、クラスタ ピアツーピアが WAN フェデレーションと同等の機能をすべて提供できるようになるまでには、追加機能が必要になります。既に WAN フェデレーションをご利用の場合は、既存のクラスタをクラスタ ピアツーピアに直ちに移行する必要はありません。

次のステップ

HashiCorp Consulの目標は、あらゆるアプリケーションを検出し、安全に接続するための、エンタープライズ対応の一貫性のあるコントロールプレーンを提供することです。詳細については、 Consulのドキュメント^[10]をご覧ください。Consul 1.13を使い始めるには、リリースページから適切なオペレーティングシステムのバイナリをダウンロードするか、Kubernetes用のConsul 1.13をサポートする最新のHelm Chartパッケージ^[11]をインストールしてください。

参考文献

[1]consul-k8s: https://github.com/bashicorp/consul-k8s/releases

[2] 静的アップストリーム構成: https://www.consul.io/docs/connect/registration/service-registration#upstream-configuration-reference

[3] 仮想サービスホスト名: https://www.consul.io/docs/discovery/dns#service-virtual-ip-lookups

[4]www.example.com: https://www.hashicorp.com/blog/www.example.com

[5] プラットフォームチーム: https://www.hashicorp.com/cloud-operating-model

[6] Consulデータセンター: https://www.consul.io/docs/install/glossary#datacenter

[7] インテンション: https://learn.hashicorp.com/tutorials/consul/service-mesh-application-aware-intentions?in=consul/developer-mesh

[8]Consul 1.11: https://www.hashicorp.com/blog/announceing-hashicorp-consul-1-11

[9]管理パーティション: https://www.hashicorp.com/blog/achieving-multi-tenancy-with-consul-administrative-partitions

[10] Consulドキュメント: https://www.consul.io/docs

[11] Helm Chartパッケージ: https://github.com/hashicorp/consul-k8s/releases