固定 IP アドレスを使用する Tanzu Kubernetes サービスロードバランサの例

固定 IP アドレスを使用するように LoadBalancer タイプの Kubernetes サービスを構成できます。この機能を実装する場合は、コンポーネントの最小要件、セキュリティに関する重要な考慮事項、およびクラスタのセキュリティ強化に関するガイダンスに注意してください。

最小要件

次の要件を満たす Tanzu Kubernetes クラスタでは、LoadBalancer タイプの Kubernetes サービスに固定 IP アドレスを指定することができます。


コンポーネント	最小要件	詳細情報
vCenter Server と ESXi	vSphere 7.0 Update 2	リリースノートを参照してください。
スーパーバイザークラスタ	`v1.19.1+vmware.2-vsc0.0.8-17610687`	vSphere 名前空間の更新の実行によるスーパーバイザークラスタの更新を参照してください。
ロードバランサ	NSX-T Data Center v3.1 または NSX Advanced 20.1.x	リリースノートを参照してください。
Tanzu Kubernetes リリース	最新の Tanzu Kubernetes リリースの 1 つ。	更新のための Tanzu Kubernetes クラスタ互換性の確認を参照してください。

LoadBalancer タイプのサービスにおける固定 IP アドレスの使用

通常、LoadBalancer タイプの Kubernetes サービスを定義すると、ロードバランサによって IP アドレスが一時的に割り当てられます。Tanzu Kubernetes サービスロードバランサの例を参照してください。

ロードバランサの固定 IP アドレスを指定することもできます。サービスの作成時に、割り当てられた固定 IP アドレスを使用してロードバランサのインスタンスがプロビジョニングされます。

次のサービスの例では、固定 IP アドレスを使用してサポート対象のロードバランサを構成する方法を示します。サービス仕様に loadBalancerIP パラメータと IP アドレス値を含めます。この例では、IP アドレスは 10.11.12.49 です。

kind: Service
apiVersion: v1
metadata:
  name: load-balancer-service-with-static-ip
spec:
  selector:
    app: hello-world
    tier: frontend
  ports:
  - protocol: "TCP"
    port: 80
    targetPort: 80
  type: LoadBalancer
  loadBalancerIP: 10.11.12.49

NSX Advanced Load Balancer の場合は、ロードバランサのインストール時に構成された IP アドレス管理プール内の IP アドレスを使用します。サービスが作成され、固定 IP アドレスが割り当てられると、ロードバランサは割り当て済みとマークし、一時的な IP アドレスと同じように IP アドレスのライフサイクルを管理します。つまり、サービスが削除されると、IP アドレスは割り当て解除され、再割り当てが可能になります。

NSX-T ロードバランサの場合は、2 つのオプションがあります。デフォルトのメカニズムは、NSX Advanced Load Balancer と同じように、ロードバランサのインストール時に構成された IP アドレスプールから取得された IP アドレスを使用します。固定 IP アドレスが割り当てられると、ロードバランサは自動的に割り当て済みとマークし、そのライフサイクルを管理します。

NSX-T の 2 番目のオプションでは、固定 IP アドレスを手動で事前に割り当てます。この場合、ロードバランサに割り当てられた外部ロードバランサの IP アドレスプールに含まれない、フローティング IP アドレスプールから取得された IP アドレスを使用します。この場合は、NSX Manager を使用して、IP アドレスの割り当てとライフサイクルを手動で管理します。

セキュリティに関する重要な検討事項とセキュリティ強化要件

この機能を使用する場合は、セキュリティ上の問題が発生する可能性を認識しておく必要があります。開発者が Service.status.loadBalancerIP 値にパッチを適用できる場合、その開発者は、パッチが適用された IP アドレス宛てのクラスタ内のトラフィックをハイジャックできる可能性があります。特に、この機能が実装されているクラスタで、patch 権限を持つ Role または ClusterRole がサービスまたはユーザーアカウントにバインドされている場合は、そのアカウント所有者が自身の認証情報を使用して kubectl コマンドを発行し、ロードバランサに割り当てられた固定 IP アドレスを変更できます。

ロードバランササービスに固定 IP アドレスを割り当てた場合に生じる可能性のあるセキュリティ面の影響を回避するには、この機能を実装している各クラスタのセキュリティを強化する必要があります。これを行うには、開発者に対して定義した Role または ClusterRole で、apiGroups:"" および resources: services/status の verb として patch を禁止する必要があります。ロールスニペットの例は、この機能を実装する際の禁止項目を示しています。

パッチ適用の禁止

- apiGroups:
  - ""
  resources:
  - services/status
  verbs:
  - patch

開発者にパッチ権限が付与されているかどうかを確認するには、次のコマンドをそのユーザーとして実行します。

kubectl --kubeconfig <KUBECONFIG> auth can-i patch service/status

このコマンドによって yes が返された場合、そのユーザーにはパッチ権限が付与されています。詳細については、Kubernetes のドキュメントのChecking API Accessを参照してください。

開発者にクラスタへのアクセス権を付与する方法については、開発者に対する Tanzu Kubernetes クラスタへのアクセス権の付与を参照してください。カスタマイズ可能なサンプルのロールテンプレートの例については、ポッドセキュリティポリシーのロールの例を参照してください。クラスタへのアクセスを制限する方法の例については、https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-example を参照してください。