TransitGateway¶

TransitGatewayは、複数のVpcを1つのハブに集めて相互接続するリソースです。

VpcPeeringが2つのVpcを直接つなぐのに対して、TransitGatewayでは各VpcをTransitGatewayAttachmentでハブに接続し、どのVpcからどのVpcへ通すかをTransitGatewayRouteTableで決めます。

specに設定項目はありません。TransitGateway自体は、ルートテーブルとアタッチメントをまとめる管理単位です。

default route table¶

TransitGatewayを作成すると、同じ名前のTransitGatewayRouteTableが自動的に作成され、status.defaultRouteTableに記録されます。Vpcのメインルートテーブルと同じ考え方です。

ルートテーブルを分ける必要が無ければ、すべてのアタッチメントのspec.associationとspec.propagationsにこのルートテーブルを指定してください。接続したVpcが互いに到達できる構成になります。

RouteTableとの連携¶

Vpc内のPodをTransitGateway経由で他のVpcへ出すには、対象VpcのRouteTableにvia.type: transitGatewayのルートを追加し、via.transitGatewayでTransitGateway名を参照します。

このルートのdstは、複数のSubnetをまとめたスーパーネットでも構いません。実際の宛先解決は、そのVpcのアタッチメントがassociationしているTransitGatewayRouteTableの中で行われます。

詳しくはRouteTableを参照してください。

Serviceのバックエンドの制約¶

ClusterIP宛の通信は、バックエンドPodがTransitGateway経由でつながる他のVpcにいると届きません。バックエンドがServiceの所属Vpcの中にある場合と、VpcPeeringでつないだVpcにある場合だけ到達することができます。RouteTableはReady=Trueのままなので、Podから届かないことでしか気付けません。

データプレーンは宛先をバックエンドのIPに書き換えた後、もう一度ルートを引き直します。この2回目の解決はvia.type: transitGatewayのルートを扱いません。TransitGatewayの転送はTransitGatewayRouteTableをもう1段引く必要があり、BPFプログラムのスタック上限に収まらないためです。

SecurityGroupの制約¶

VpcPeeringと同じく、SecurityGroupのsecurityGroupRefは同じVpcのSecurityGroupしか参照できません。TransitGateway経由で届く他VpcのPodからの通信を許可するには、cidrのルールを書いてください。

status¶

status.defaultRouteTableは、このTransitGatewayが自動的に作成したTransitGatewayRouteTableの名前です。

status.conditionsのReadyは、default route tableが作成され、利用できる状態になったことを表します。Ready=Trueになるまでは、このTransitGatewayを参照するRouteTableのルートも有効になりません。

削除¶

TransitGatewayAttachmentが残っている間、またはこのTransitGatewayをvia.transitGatewayで参照するRouteTableが残っている間は削除できません。default route tableはTransitGatewayの削除に合わせて削除されます。