Container Service for Kubernetes Terway モードでの大規模クラスタの NetworkPolicy パフォーマンス最適化 - ACK

Terway を実行する大規模な ACK クラスターでは、各ノード上の Felix エージェントが NetworkPolicy ルールを取得するために Kubernetes API サーバーに直接接続します。この構成により、クラスター規模の拡大に伴い Kubernetes API サーバーの負荷が過剰になる可能性があります。本トピックでは、Typha を Kubernetes API サーバーと Felix の間にキャッシュレイヤーとして導入することでこのボトルネックを解消する方法、またはネットワークポリシーが不要になった場合に NetworkPolicy 機能を無効化する方法について説明します。

背景情報

Terway は Calico の Felix エージェントを活用して NetworkPolicy を実装しています。ノード数が 100 を超えるクラスターでは、各 Felix インスタンスが個別に Kubernetes API サーバーを監視し、ポリシーの更新を検知します。監視接続数はノード数に比例して増加するため、Kubernetes API サーバーの負荷はクラスター規模に応じて線形に増加します。

Typha は Kubernetes API サーバーとすべての Felix インスタンスの間に配置され、Kubernetes API サーバーへの直接監視接続数を削減するリピーターとして機能します。

対応方法を選択してください：

対応方法	適用条件
Typha のデプロイ	ネットワークポリシーが必要であり、クラスターのノード数が 100 を超える場合
NetworkPolicy の無効化	ネットワークポリシーが不要となり、関連するすべてのオーバーヘッドを排除したい場合

警告

NetworkPolicy 機能を無効化した後は、Pod 間の通信制御にネットワークポリシーを使用できなくなります。

前提条件

開始する前に、以下の条件を満たしていることを確認してください。

Terway プラグインがインストール済みで、ノード数が 100 を超える ACK クラスター。詳細については、「ACK マネージドクラスターの作成」をご参照ください。
kubectl クライアントが接続済みのクラスター用 kubeconfig ファイル。詳細については、「kubeconfig の取得および kubectl によるクラスターへの接続」をご参照ください。

Typha をリピーターとしてデプロイ

Typha は Kubernetes API サーバーと Felix エージェントの間でリピーターとして機能します。最低でも 3 個の Typha レプリカをデプロイし、ノード数が 200 増加するごとに 1 個のレプリカを追加してください。

ACK コンソールにログインします。
Terway を最新バージョンに更新します。詳細については、「コンポーネントの管理」をご参照ください。
Terway のモードによってコンポーネントが異なります。比較については、「Terway モードの比較」をご参照ください。

calico-typha.yaml という名前のファイルを作成し、以下の内容を追加します。{REGION-ID} をクラスターのリージョン ID に置き換えます。replicas を、ノード 200 台ごとに 1 つ、最低でも 3 つになるように設定します。クラスターで Kubernetes 1.21 よりも古いバージョンを実行している場合は、PodDisruptionBudget セクションで policy/v1 を policy/v1beta1 に変更します。

apiVersion: v1
kind: Service
metadata:
  name: calico-typha
  namespace: kube-system
  labels:
    k8s-app: calico-typha
spec:
  ports:
    - port: 5473
      protocol: TCP
      targetPort: calico-typha
      name: calico-typha
  selector:
    k8s-app: calico-typha

---

apiVersion: apps/v1
kind: Deployment
metadata:
  name: calico-typha
  namespace: kube-system
  labels:
    k8s-app: calico-typha
spec:
  replicas: 3  # ノード数 200 台ごとに 1 レプリカ（最低 3）
  revisionHistoryLimit: 2
  selector:
    matchLabels:
      k8s-app: calico-typha
  template:
    metadata:
      labels:
        k8s-app: calico-typha
      annotations:
        cluster-autoscaler.kubernetes.io/safe-to-evict: 'true'
    spec:
      nodeSelector:
        kubernetes.io/os: linux
      hostNetwork: true
      tolerations:
        - operator: Exists
      serviceAccountName: terway
      priorityClassName: system-cluster-critical
      containers:
      - image: registry-vpc.{REGION-ID}.aliyuncs.com/acs/typha:v3.20.2
        name: calico-typha
        ports:
        - containerPort: 5473
          name: calico-typha
          protocol: TCP
        env:
          - name: TYPHA_LOGSEVERITYSCREEN
            value: "info"
          - name: TYPHA_LOGFILEPATH
            value: "none"      # Kubernetes 環境ではファイルログを無効化（不要）
          - name: TYPHA_LOGSEVERITYSYS
            value: "none"      # Kubernetes 環境では syslog を無効化（不要）
          - name: TYPHA_CONNECTIONREBALANCINGMODE
            value: "kubernetes"  # Felix 接続の再バランス調整を Kubernetes API で監視
          - name: TYPHA_DATASTORETYPE
            value: "kubernetes"
          - name: TYPHA_HEALTHENABLED
            value: "true"
        livenessProbe:
          httpGet:
            path: /liveness
            port: 9098
            host: localhost
          periodSeconds: 30
          initialDelaySeconds: 30
        readinessProbe:
          httpGet:
            path: /readiness
            port: 9098
            host: localhost
          periodSeconds: 10

---

apiVersion: policy/v1  # Kubernetes < 1.21 の場合は policy/v1beta1 を使用
kind: PodDisruptionBudget
metadata:
  name: calico-typha
  namespace: kube-system
  labels:
    k8s-app: calico-typha
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      k8s-app: calico-typha

---

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: bgppeers.crd.projectcalico.org
spec:
  scope: Cluster
  group: crd.projectcalico.org
  versions:
  - name: v1
    served: true
    storage: true
    schema:
      openAPIV3Schema:
        type: object
        properties:
          apiVersion:
            type: string
  names:
    kind: BGPPeer
    plural: bgppeers
    singular: bgppeer

マニフェストを適用します。
```
kubectl apply -f calico-typha.yaml
```

Typha のすべての Pod が正常に実行中であることを確認します。

kubectl get pods -l k8s-app=calico-typha -n kube-system

続行する前に、すべての Pod の [READY] 列に 1/1 が、[STATUS] 列に Running が表示されている必要があります。出力は次のようになります。

NAME                            READY   STATUS    RESTARTS   AGE
calico-typha-66498ddfbd-2pzsr   1/1     Running   0          69s
calico-typha-66498ddfbd-lrtzw   1/1     Running   0          50s
calico-typha-66498ddfbd-scckd   1/1     Running   0          62s

Felix の接続先を Typha にルーティングするよう Terway を設定します。
```
kubectl edit cm eni-config -n kube-system
```
eni_conf ブロック内で、以下のフィールドを追加または更新します。
```
  felix_relay_service: calico-typha
  disable_network_policy: "false"  # キーが存在しない場合はこの行を省略
```

変更を反映させるために Terway を再起動します。

kubectl get pod -n kube-system | grep terway | awk '{print $1}' | xargs kubectl delete -n kube-system pod

期待される出力例は以下のとおりです。

pod "terway-eniip-8hmz7" deleted
pod "terway-eniip-dclfn" deleted
pod "terway-eniip-rmctm" deleted
...

NetworkPolicy 機能の無効化

ネットワークポリシーが不要となった場合は、NetworkPolicy 機能を無効化することで、Kubernetes API サーバーに対する Felix 関連のすべての負荷を除去できます。

警告

NetworkPolicy 機能を無効化した後は、Pod 間の通信制御にネットワークポリシーを使用できなくなります。

Terway の ConfigMap を編集し、disable_network_policy を "true" に設定します。
```
kubectl edit cm -n kube-system eni-config
```
以下のフィールドを追加または更新します。
```
disable_network_policy: "true"
```

変更を反映させるために Terway を再起動します。

kubectl get pod -n kube-system | grep terway | awk '{print $1}' | xargs kubectl delete -n kube-system pod

期待される出力例は以下のとおりです。

pod "terway-eniip-8hmz7" deleted
pod "terway-eniip-dclfn" deleted
pod "terway-eniip-rmctm" deleted
...

結果の検証

Typha をデプロイした後、NetworkPolicy プロキシは Typha コンポーネントを利用するようになり、Kubernetes API サーバーの負荷が軽減されます。Server Load Balancer (SLB) インスタンスに分散されるトラフィックをモニターすることで、Kubernetes API サーバーの負荷低減状況を確認できます。