複数のKubernetesクラスターに対するポリシーベースルーティング
複数のKubernetesクラスターの負荷分散に単一のNetScalerを使用する場合、NetScaler Ingress Controllerは静的ルートを介してNetScalerにPod CIDRネットワークを追加します。これらのルートは、Kubernetes PodとNetScaler間のネットワーク接続を確立します。ただし、Pod CIDRが重複すると、ルートの競合が発生する可能性があります。NetScalerは、このようなシナリオでのネットワーク競合に対処するために、ポリシーベースルーティング (PBR) をサポートしています。PBRでは、指定した基準に基づいてルーティング決定が行われます。通常、NetScaler VPXまたはNetScaler MPXが選択されたパケットを送信するネクストホップが指定されます。GSLB Kubernetes環境では、各KubernetesクラスターまたはNetScaler Ingress Controller用にサブネットIPアドレス (SNIP) を予約することでPBRが実装されます。ネットプロファイルを使用すると、SNIPは同じNetScaler Ingress Controllerによって作成されたすべてのサービスグループにバインドされます。同じクラスターに属するサービスグループから生成されるすべてのトラフィックについて、送信元IPアドレスは同じSNIPになります。
次のサンプルとポロジでは、NetScaler MPXまたはNetScaler VPXを使用して負荷分散される2つのKubernetesクラスターに対してPBRが構成されています。
PBR構成(/en-us/netscaler-k8s-ingress-controller/media/pbr.png)
NetScaler Ingress Controllerを使用したPBRの構成
PBRを構成するには、Kubernetesクラスターごとに1つ以上のSNIPが必要です。NSIC Helmインストールコマンドの
nsSNIPSパラメーターを使用してSNIP値を指定できます。
Helmインストールコマンドで次の
values.ymlファイルを使用して、NetScaler Ingress Controllerを展開し、PBRを構成します。
nsIP: <NS_IP>
license:
accept: yes
adcCredentialSecret: <secret>
nodeWatch: True
clusterName: <name of cluster>
nsSNIPS: '["1.2.3.4", "5.6.7.8"]'
NetScaler Ingress Controller展開後のNetScalerでのPBR構成の検証
この検証例では、NetScaler Ingress Controllerがデプロイされた2ノードのKubernetesクラスターと、2つのSNIPを持つ次のConfigMapを使用します。
NetScaler Ingress ControllerがNetScalerに次の構成を追加することを確認できます。
-
すべてのNS_SNIPのIPセットが追加されているかどうかを確認するには、次のコマンドを実行します:
show ipset k8s-pbr_ipset。イメージ(https://user-images.githubusercontent.com/46886297/117246342-19519a00-ae5a-11eb-8e65-70944c24ef51.png) -
ネットプロファイルが追加され、
SrcIPがIPsetに設定されます。
-
NetScaler Ingress Controllerによって追加されたサービスグループにネットプロファイルセットが含まれているかどうかを確認するには、
show servicegroupを実行します。
-
PBRが追加されているかを確認するには、次のコマンドを実行します:
shpbr。
ここで:-
PBRの数は、（SNIPの数）
*（Kubernetesノードの数）に相当します。この場合、4つ（2*2）のPBRが追加されます。 -
PBRの
srcIPは、ConfigMapによってNetScaler Ingress Controllerに提供されるNS_SNIPSです。destIPは、KubernetesノードのCNIオーバーレイサブネット範囲です。 -
NextHopはKubernetesノードのIPアドレスです。
-
-
NetScaler Ingress Controllerのログを使用して、構成を検証することもできます。
NetScalerノードコントローラーを使用してPBRを構成する
複数のKubernetesクラスターに対して、NetScalerノードコントローラーを使用してPBRを構成できます。ネットワーキングにNetScalerノードコントローラーを使用し、単一のNetScalerで複数のKubernetesクラスターの負荷分散を行う場合、VXLANトンネルインターフェースのIPアドレスにパケットを転送するために追加された静的ルートが、ルーティングの競合を引き起こす可能性があります。PBRをサポートするには、NetScalerノードコントローラーがNetScaler Ingress Controllerと連携して、ネットプロファイルをサービスグループにバインドする必要があります。
NetScalerノードコントローラーを使用してPBRを構成するには、次の手順を実行します。
-
NetScalerノードコントローラーの起動時に、
CLUSTER_NAMEを環境変数として指定します。この変数を指定すると、それがマルチクラスター展開であり、NetScalerノBRが静的ルートではなくPBRを構成することを示します。例:helm install nsnc netscaler/netscaler-node-controller --set license.accept=yes,nsIP=<NSIP>,vtepIP=<NetScaler SNIP>,vxlan.id=<VXLAN ID>,vxlan.port=<VXLAN PORT>,network=<IP-address-range-for-VTEP-overlay>,adcCredentialSecret=<Secret-for-NetScaler-credentials>,cniType=<CNI-overlay-name>,clusterName=<cluster-name> -
NetScaler Ingress Controllerを展開する際、
CLUSTER_NAMEを環境変数として提供します。この値はノードコントローラーで提供された値と同じである必要があり、nsncPbr=True引数を使用してPBRを有効にし、NetScalerでPBRを設定します。
注記:
-
NetScalerノードコントローラーとNetScaler Ingress Controllerのデプロイファイルで
CLUSTER_NAMEに提供される値は、同じKubernetesクラスターにデプロイされている場合、一致する必要があります。 -
CLUSTER_NAMEは、ネットプロファイルエンティティを作成し、それをNetScaler VPXまたはNetScaler MPX上のサービスグループにバインドする際に使用されます。
NetScalerノードコントローラーのデプロイ後にNetScalerでのPBR構成を検証する
この検証例では、NetScalerノードコントローラーとNetScaler Ingress Controllerがデプロイされた2ノードのKubernetesクラスターを使用します。
NetScalerノードコントローラーによってNetScalerに以下の構成が追加されていることを確認できます。
-
次のコマンドを実行します:
show netprofile。ネットプロファイルが追加され、srcIPの値は、NetScalerとKubernetesノード間のVXLANトンネルネットワークを作成する際にノードコントローラーによって追加されたSNIPに設定されます。
-
次のコマンドを実行します:
shservicegroup。NetScaler Ingress Controllerは、ネットプロファイルを作成するサービスグループにバインドします。
-
次のコマンドを実行します:
show pbr。NetScalerノードコントローラーはPBRを追加します。
ここでは、:
-
PBRの数はKubernetesノードの数と同じです。この場合、2つのPBRが追加されます。
-
PBRの
srcIPは、トンネルネットワークでNetScalerノードコントローラーによって追加されたSNIPです。destIPは、KubernetesノードのCNIオーバーレイサブネット範囲です。NextHopは、KubernetesノードのVXLANトンネルインターフェースのIPアドレスです。
注:
NetScalerノードコントローラーは、静的ルートの代わりにPBRを追加します。VXLANとブリッジテーブルの残りの設定は同じままです。詳細については、NetScalerノードコントローラーの構成を参照してください。