In der Beispiel-YAML finden Sie Informationen dazu, wie Sie einen Tanzu Kubernetes-Cluster (TanzuKubernetesCluster) mithilfe der v1alpha3-API mit benutzerdefinierten Netzwerkeinstellungen bereitstellen.

v1alpha3-Beispiel: TKC mit benutzerdefinierten Netzwerkeinstellungen

Das Netzwerk wird wie folgt angepasst. Weitere Informationen finden Sie in der Spezifikation der v1alpha3-API.
  • Anstelle der standardmäßigen Antrea-CNI wird die Calico-CNI verwendet.
  • Es werden nicht standardmäßige Subnetze für Pods und Dienste verwendet.
  • Ein Proxyserver und TLS-Zertifikate werden deklariert
apiVersion: run.tanzu.vmware.com/v1alpha3
kind: TanzuKubernetesCluster
metadata:
  name: tkc-custom-network
  namespace: tkg2-cluster-ns
spec:
  topology:
    controlPlane:
      replicas: 3
      vmClass: guaranteed-medium
      storageClass: tkg-storage-policy
      tkr:
        reference:
          name: v1.25.7---vmware.3-fips.1-tkg.1
    nodePools:
    - name: worker
      replicas: 3
      vmClass: guaranteed-medium
      storageClass: tkg-storage-policy
      tkr:
        reference:
          name: v1.25.7---vmware.3-fips.1-tkg.1
      volumes:
      - name: containerd
        mountPath: /var/lib/containerd
        capacity:
          storage: 50Gi
      - name: kubelet
        mountPath: /var/lib/kubelet
        capacity:
          storage: 50Gi
  settings:
    storage:
      defaultClass: tkg-storage-policy
    network:
      cni:
        name: calico
      services:
        cidrBlocks: ["172.16.0.0/16"]
      pods:
        cidrBlocks: ["192.168.0.0/16"]
      serviceDomain: cluster.local
      proxy:
        httpProxy: http://<user>:<pwd>@<ip>:<port>
        httpsProxy: http://<user>:<pwd>@<ip>:<port>
        noProxy: [10.246.0.0/16,192.168.144.0/20,192.168.128.0/20]
      trust:
        additionalTrustedCAs:
          - name: CompanyInternalCA-1
            data: LS0tLS1C...LS0tCg==
          - name: CompanyInternalCA-2
            data: MTLtMT1C...MT0tPg==

Überlegungen zum Anpassen des TKC-Pod-Netzwerks

Die Einstellung spec.settings.network.pods.cidrBlocks der Clusterspezifikation ist standardmäßig auf 192.168.0.0/16 festgelegt.

Im Fall einer Anpassung liegt die minimale CIDR-Blockgröße der Pods bei /24. Seien Sie jedoch vorsichtig, wenn Sie die pods.cidrBlocks-Subnetzmaske über /16 hinaus einschränken.

TKG weist jedem Clusterknoten ein /24-Subnetz zu, das aus pods.cidrBlocks abgeteilt wird. Diese Zuteilung wird vom Kubernetes Controller Manager > NodeIPAMController-Parameter mit der Bezeichnung NodeCIDRMaskSize bestimmt, der die Größe der Subnetzmaske für das Knoten-CIDR im Cluster festlegt. Die Subnetzmaske für den Standardknoten beträgt /24 für IPv4.

Da jeder Knoten in einem Cluster ein /24-Subnetz aus pods.cidrBlocks erhält, kann es zu einem Mangel an IP-Adressen kommen, wenn Sie eine Subnetzmaskengröße verwenden, die für den bereitzustellenden Cluster zu restriktiv ist.

Die folgenden Knotengrenzwerte gelten für einen Tanzu Kubernetes-Cluster, der entweder mit der Antrea- oder der Calico-CNI bereitgestellt wird.

/16 == max. 150 Knoten (pro ConfigMax)

/17 == max. 128 Knoten

/18 == max. 64 Knoten

/19 == max. 32 Knoten

/20 == max. 16 Knoten

/21 == max. 8 Knoten

/22 == max. 4 Knoten

/23 == max. 2 Knoten

/24 == max. 1 Knoten