class-basedのTKGクラスターのAntreaのパラメータを変更する

小ネタ。
TKGのクラスタ内のCSI,CNI等のcore packagesと呼ばれるパッケージはView and Update Auto-Managed Package Configurationに記載されている方法でクラスタ構築後に変更できる。
ただし、class-basedのクラスタに対しては公式ドキュメントに変更方法が記載されていない。
今回はAntreaを題材に設定変更してみる。

Antreaの設定箇所

過去にWorkload Clusterをデプロイした人は、class-basedで使うyamlを見ることが出来ると思う。
中を覗いてみると、設定用のk8sリソースが存在することが分かる。

$ grep ^kind  ~/.config/tanzu/tkg/clusterconfigs/workload.yaml  | sort | uniq
kind: Cluster
kind: ClusterBootstrap
kind: Secret
kind: VSphereCPIConfig　　★これ
kind: VSphereCSIConfig　　★これ

では、Antreaはどれで設定されているかと言うと、リソースとしてはAntreaConfigというリソースになるが、デフォルトでは設定はyamlには入っていない。

$ kubectl api-resources |grep cni.tanzu.vmware.com/v1alpha1
antreaconfigs                     antreaconf   cni.tanzu.vmware.com/v1alpha1             true         AntreaConfig
calicoconfigs                     calicoconf   cni.tanzu.vmware.com/v1alpha1             true         CalicoConfig

ただし、クラスタ構築後はManagement Clusterから確認できる。

$ kubectl get antreaconf
NAME                                 TRAFFICENCAPMODE   DEFAULTMTU   ANTREAPROXY   ANTREAPOLICY   SECRETREF
hogeeee-sof2-harbor-antrea-package   encap                           true          true           hogeeee-sof2-harbor-antrea-data-values

これを書き換えることで、デプロイ後のAntreaの設定を書き換えられる。

Antreaの設定変更

現状の設定はAntreaConfigを見ると確認できる。

$ kubectl get antreaconf -o yaml hogeeee-sof2-harbor-antrea-package
：（省略）
spec:
  antrea:
    config:
      defaultMTU: ""
      disableTXChecksumOffload: false
      disableUdpTunnelOffload: false
      dnsServerOverride: ""
      enableBridgingMode: false
      enableUsageReporting: false
      featureGates:
        AntreaIPAM: false
        AntreaPolicy: true
        AntreaProxy: true
        AntreaTraceflow: true
        Egress: true
        EndpointSlice: true
        FlowExporter: false
：（省略）

この値はWorkload Clusterに伝搬されて、Workload Cluster内の<クラスタ名>-antrea-data-valuesというSecretに保存される。

$ kubectl get secret -n tkg-system hogeeee-sof2-harbor-antrea-data-values -o jsonpath={.data."values\.yaml"} | base64 -d
infraProvider: vsphere
antrea:
    config:
        serviceCIDR: 100.64.0.0/13
        trafficEncapMode: encap
：（省略）

この値はManagement Clusterのkapp-controllerのリコンサイル対象であるため、これ自体を修正しても元に戻される。
しかし、AntreaConfigを修正した場合はAntreaConfigはリコンサイル対象ではないため元に戻されない。
試しにEgressを無効化してみる。Management Clusterに再度切り替えて、以下のpatchで書き換える。

kubectl patch antreaconf imurata-sof2-harbor-antrea-package --type merge -p '{"spec": {"antrea": {"config": {"featureGates": {"Egress": false}}}}}' -n default

patchを実行後、Workload Clusterに切り替えてSecretを確認すると値が書き換わっている事が分かる。

$ k get secret -n tkg-system imurata-sof2-harbor-antrea-data-values -o jsonpath={.data."values\.yaml"} | base64 -d | grep -i egress
            Egress: false

Podを再起動してログを見ると、Egressが有効になっていないことが分かる。

$ kubectl delete pod -n kube-system antrea-controller-78f5476469-h8mk4
pod "antrea-controller-78f5476469-h8mk4" deleted
$ kubectl logs -n kube-system antrea-controller-78f5476469-8rzrb |grep -i egress
$

なお、同じような感じでMTUも変更することが出来る。

kubectl patch antreaconf mycluster-antrea-package --type merge -p '{"spec": {"antrea": {"config": {"defaultMTU": "9000"}}}}' -n default 

ただし、これを実施すると、AntreaのAgent Podが以下のエラーを出力する。

I0724 07:58:58.273975       1 log_file.go:93] Set log file max size to 104857600
F0724 07:58:58.286357       1 main.go:47] Failed to complete: yaml: unmarshal errors:
  line 25: cannot unmarshal !!str `9000` into int
goroutine 1 [running]:
k8s.io/klog/v2.stacks(0x1)
	/tmp/gopath/pkg/mod/k8s.io/klog/v2@v2.60.1/klog.go:860 +0x89
k8s.io/klog/v2.(*loggingT).output(0x3db05a0, 0x3, 0x0, 0xc000428150, 0x1, {0x30d8a7a?, 0x1?}, 0x3db11a0?, 0x0)

確認したところ、AntreaConfigではMTUの値はStringを要求するのに対し、Agent Pod側ではIntegerを期待していて、型が合わずにエラーとなっている模様（要はバグ）。
なので、MTUを変更したい人は修正されるまで待つしかなさそうだ（もしくはリコンサイルしているpkgi等をpaused:trueで止めて手動でConfigMapのantrea-configを修正する。）