技術的な実装と運用に向けた GTP-C エグレス管理ポリシーのカスタムリソースについて詳述します。主要なワークフロー、要件、および期待される結果に焦点を当てます。
セッションレベルのメッセージ
apiVersion: lbs.cisco.com/v1alpha1
kind: EgressManagementPolicy
metadata:
name: <gtpc-sess-emp-name>
spec:
egressIPs:
- <gtpc-service-IP>
egressMode: bpf
egressPort:
stateful:
- podName: <gtpc-sess-0-name>
portRanges:
- <port-range11...port-range1n>
- podName: <gtpc-sess-1-name>
portRanges:
- <port-range21...port-range2n>
- podName: <gtpc-sess-2-name>
portRanges:
- <port-range31...port-range3n>
- podName: <gtpc-sess-3-name>
portRanges:
- <port-range41...port-range4n>
- podName: <gtpc-sess-4-name>
portRanges:
- <port-range51...port-range5n>
protocol: GTPC
target:
selectors:
matchLabels:
<label-key1>: <label-value1>
<label-key2>: <label-value2>
ノードレベルのメッセージ
GTP-C Echo Request および Response メッセージの場合、送信元ポートと宛て先ポートの両方が通常 2123 に設定されます。アプリケーションがこれらのメッセージに異なる送信元ポート範囲を使用する場合、前述のセッションレベルの EMP CR と同じ方法で、ノードレベルの通信に対して EMP CR を構成できます。
制限事項：
-
ULB はフラグメント化された IPv4 パケットまたは IPv6 拡張ヘッダーチェーンを明示的に処理しません。
-
このリリースでは、ローリングアップグレードとダウングレードはサポートされていません。
-
このリリースでは、GTPv1-C メッセージ処理はサポートされません。
-
Pod やノードの再起動などのレジリエンシイベントからのリカバリは、このリリースではサポートされていません。