È possibile personalizzare la configurazione di TKG Service per i cluster TKG di cui è stato eseguito il provisioning utilizzando l'API v1alpha3, tra cui l'interfaccia CNI (Container Network Interface), il server proxy e i certificati TLS.
Informazioni sulla personalizzazione di TkgServiceConfiguration
È possibile configurare le impostazioni globali per i cluster Tanzu Kubernetes modificando TkgServiceConfiguration. Questa configurazione consente di impostare l'interfaccia CNI predefinita, aggiungere un server proxy globale e aggiungere uno o più certificati TLS attendibili.
Attenzione: La personalizzazione di
TkgServiceConfiguration è un'operazione globale. Le modifiche apportate all'oggetto
TkgServiceConfiguration vengono applicate a tutti i cluster TKG con provisioning eseguito da tale servizio. Se viene avviato un aggiornamento in sequenza, manualmente o tramite upgrade, i cluster vengono aggiornati in base alla specifica del servizio modificata.
Nota: La personalizzazione di
TkgServiceConfiguration si applica ai cluster
Tanzu Kubernetes il cui provisioning è stato eseguito con l'API v1alpha3. Non si applica invece ai cluster di cui è stato eseguito il provisioning con l'API v1beta1.
Specifica TkgServiceConfiguration
La specifica
TkgServiceConfiguration fornisce campi per la configurazione dell'istanza di
Tanzu Kubernetes Grid.
Importante: Per essere valido, il nome di una chiave deve essere composto solo da caratteri alfanumerici, un trattino (ad esempio
key-name), un carattere di sottolineatura (ad esempio
KEY_NAME) o un punto (ad esempio
key.name). Nel nome di una chiave non è possibile utilizzare uno spazio.
Il codice YAML che segue elenca e descrive i campi configurabili per ciascuno dei parametri della specifica
TkgServiceConfiguration.
apiVersion: run.tanzu.vmware.com/v1alpha3
kind: TkgServiceConfiguration
#valid config key must consist of alphanumeric characters, '-', '_' or '.'
metadata:
name: tkg-service-configuration-spec
spec:
#defaultCNI is the default CNI for all Tanzu Kubernetes
#clusters to use unless overridden on a per-cluster basis
#supported values are antrea, calico, antrea-nsx-routed
#defaults to antrea
defaultCNI: string
#proxy configures a proxy server to be used inside all
#clusters provisioned by this TKGS instance
#if implemented all fields are required
#if omitted no proxy is configured
proxy:
#httpProxy is the proxy URI for HTTP connections
#to endpionts outside the clusters
#takes the form http://<user>:<pwd>@<ip>:<port>
httpProxy: string
#httpsProxy is the proxy URI for HTTPS connections
#to endpoints outside the clusters
#takes the frorm http://<user>:<pwd>@<ip>:<port>
httpsProxy: string
#noProxy is the list of destination domain names, domains,
#IP addresses, and other network CIDRs to exclude from proxying
#must include from Workload Network: [Namespace Netowrk, Ingress, Egress]
noProxy: [string]
#trust configures additional trusted certificates
#for the clusters provisioned by this TKGS instance
#if omitted no additional certificate is configured
trust:
#additionalTrustedCAs are additional trusted certificates
#can be additional CAs or end certificates
additionalTrustedCAs:
#name is the name of the additional trusted certificate
#must match the name used in the filename
- name: string
#data holds the contents of the additional trusted cert
#PEM Public Certificate data encoded as a base64 string
data: string
#defaultNodeDrainTimeout is the total amount of time the
#controller spends draining a node; default is undefined
#which is the value of 0, meaning the node is drained
#without any time limitations; note that `nodeDrainTimeout`
#is different from `kubectl drain --timeout`
defaultNodeDrainTimeout: time
Figura 1. Valori noProxy obbligatori
Nota: Se in
TkgServiceConfiguration è configurato un proxy globale, le informazioni di tale proxy vengono propagate al manifesto del cluster dopo la distribuzione iniziale del cluster. La configurazione del proxy globale viene aggiunta al manifesto del cluster solo se non sono presenti campi di configurazione del proxy durante la creazione del cluster. In altre parole, la configurazione per cluster ha la precedenza e sovrascriverà la configurazione di un proxy globale.
Specifica TkgServiceConfiguration di esempio
Il codice YAML che segue elenca e descrive i campi configurabili per ciascuno dei parametri della specifica TkgServiceConfiguration.
apiVersion: run.tanzu.vmware.com/v1alpha3
kind: TkgServiceConfiguration
metadata:
name: tkgserviceconfiguration_example
spec:
defaultCNI: calico
proxy:
#supported format is `http://<user>:<pwd>@<ip>:<port>`
httpProxy: http://admin:[email protected]:80
httpsProxy: http://admin:[email protected]:80
#noProxy vaulues are from Workload Network: [Namespace Network, Ingress, Egress]
noProxy: [10.246.0.0/16,192.168.144.0/20,192.168.128.0/20]
trust:
additionalTrustedCAs:
#name is the name of the public cert
- name: CompanyInternalCA-1
#data is base64-encoded string of a PEM encoded public cert
data: LS0tLS1C...LS0tCg==
#where "..." is the middle section of the long base64 string
- name: CompanyInternalCA-2
data: MTLtMT1C...MT0tPg==
defaultNodeDrainTimeout: 0
Modifica di TkgServiceConfiguration
Fare riferimento alla procedura seguente per modificare la specifica
TkgServiceConfiguration.
Il sistema apre la specifica tkg-service-configuration nell'editor di testo predefinito definito dalla variabile di ambiente KUBE_EDITOR o EDITOR.
Modificare TkgServiceConfiguration in base alle proprie esigenze.
Per applicare le modifiche, salvare il file nell'editor di testo. Per annullare, chiudere l'editor senza salvare.
Quando si salva la modifica nell'editor di testo, kubectl aggiorna la specifica del servizio tkg-service-configuration.
Verificare che la specifica TkgServiceConfiguration venga aggiornata.
kubectl get tkgserviceconfigurations
Propagazione delle modifiche della configurazione globale ai cluster esistenti
Le impostazioni specificate a livello globale in TkgServiceConfiguration potrebbero non essere propagate automaticamente ai cluster esistenti. Ad esempio, se si apportano modifiche alle impostazioni di proxy o di trust in TkgServiceConfiguration, tali modifiche non influiranno sui cluster per cui è già stato eseguito il provisioning.
Per propagare manualmente una modifica globale a un cluster esistente, è necessario applicare una patch al cluster di Tanzu Kubernetes per fare in modo che il cluster erediti le modifiche apportate a TkgServiceConfiguration.
