Il file YAML di NCP contiene informazioni per configurare, installare ed eseguire tutti i componenti di NCP.
- Definizioni del controllo degli accessi basato sui ruoli.
- Vari CRD (CustomResourceDefinitions).
- ConfigMap contenente il file ncp.ini dedicato a NCP. Alcune opzioni di configurazione consigliate sono già impostate.
- Distribuzione di NCP.
- ConfigMap contenente il file ncp.ini dedicato a nsx-node-agent. Alcune opzioni di configurazione consigliate sono già impostate.
- <x-node-agent DaemonSet, inclusi nsx-node-agent, nsx-kube-proxy, e nsx-ovs.
- DaemonSet nsx-ncp-bootstrap
I moduli del kernel CNI e OpenvSwitch di NSX vengono installati automaticamente da initContainer nsx-ncp-bootstrap. I daemon degli spazi utente OpenvSwitch sono in esecuzione nel container nsx-ovs in ogni nodo.
Aggiornamento delle specifiche di distribuzione di NCP
- Livello di registrazione e directory dei registri.
- IP del server dell'API Kubernetes, percorso del certificato e percorso del token client. Per impostazione predefinita, viene utilizzato il valore ClusterIP del server API della variabile di ambiente e il certificato e il token vengono montati automaticamente da ServiceAccount. In genere non è necessaria alcuna modifica.
- Nome cluster Kubernetes.
- IP e credenziali di NSX Manager.
- Opzioni di risorse NSX come overlay_tz, top_tier_router, container_ip_blocks, external_ip_blocks e così via.
Per impostazione predefinita, per l'accesso all'API Kubernetes vengono utilizzati il VIP/la porta e il token ServiceAccount del servizio Kubernetes, nonché ca_file. In questo caso non è necessaria alcuna modifica. ma è necessario compilare alcune opzioni di NSX API di ncp.ini.
- Specificare l'opzione nsx_api_managers. Può essere un elenco di indirizzi IP o specifiche di URL di NSX Manager separati da virgola conformi a RFC3896. Ad esempio
nsx_api_managers = 192.168.1.181, 192.168.1.182, 192.168.1.183
- Se si configura NCP per la connessione a NSX-T tramite l'autenticazione di base, specificare le opzioni nsx_api_user e nsx_api_password con il nome utente e la password rispettivamente. Questo metodo di autenticazione non è consigliato perché è meno sicuro. Queste opzioni vengono ignorate se NCP è configurato per l'autenticazione tramite certificati client. Queste opzioni non vengono visualizzate nel file YAML di NCP. È necessario aggiungerle manualmente.
- Specificare le opzioni nsx_api_cert_file e nsx_api_private_key_file per l'autenticazione con NSX-T. L'opzione nsx_api_cert_file è il percorso completo di un file di certificato client in formato PEM. Il contenuto di questo file dovrebbe essere simile al seguente:
-----BEGIN CERTIFICATE----- <certificate_data_base64_encoded> -----END CERTIFICATE-----
L'opzione nsx_api_private_key_file è il percorso completo di un file di chiave privata client in formato PEM. Il contenuto di questo file dovrebbe essere simile al seguente:-----BEGIN PRIVATE KEY----- <private_key_data_base64_encoded> -----END PRIVATE KEY-----
Utilizzando l'autenticazione del certificato client, NCP può usare l'identità dell'entità per creare oggetti di NSX-T. Ciò significa che solo un'identità con lo stesso nome di identità può modificare o eliminare gli oggetti. In questo modo si impedisce la modifica o l'eliminazione accidentale degli oggetti di NSX-T creati da NCP. Si noti che un amministratore può modificare o eliminare qualsiasi oggetto. Se l'oggetto è stato creato con un'identità entità, viene visualizzato un avviso con queste informazioni.
- (Facoltativo) Specificare l'opzione ca_file. Il valore deve essere un file di bundle dell'autorità di certificazione (CA) da utilizzare nella verifica del certificato del server di NSX Manager. Se non è impostato, verranno utilizzate le CA root del sistema. Se si specifica un indirizzo IP per nsx_api_managers, specificare un file CA. se si specificano tre indirizzi IP per nsx_api_managers, è possibile specificare uno o tre file CA. Se si specifica un file CA, verrà utilizzato per tutti e tre i gestori. Se si specificano tre file CA, ciascuno verrà utilizzato per l'indirizzo IP corrispondente in nsx_api_managers. Ad esempio
nsx_api_managers = 192.168.1.181,192.168.1.182,192.168.1.183 ca_file = ca_file_for_all_mgrs or nsx_api_managers = 192.168.1.181,192.168.1.182,192.168.1.183 ca_file = ca_file_for_mgr1,ca_file_for_mgr2,ca_file_for_mgr3
- (Facoltativo) Specificare l'opzione insecure. Se è impostata su True, il certificato del server di NSX Manager non viene verificato. Il valore predefinito è False.
- Aggiungere volumi del segreto alle specifiche del pod NCP o rimuovere il commento dai volumi del segreto di esempio.
- Aggiungere montaggi del volume alle specifiche del container NCP o rimuovere i commenti dai montaggi del volume di esempio.
- Aggiornare ncp.ini in ConfigMap per impostare il percorso del file del certificato che punta al file nel volume montato.
Se non si dispone di una topologia di livello 1 condivisa, è necessario impostare l'opzione edge_cluster sull'ID del cluster Edge in modo che NCP crei un gateway o un router di livello 1 per il servizio di bilanciamento del carico. È possibile individuare l'ID del cluster Edge passando a , selezionando la scheda Cluster Edge e facendo clic sul nome del cluster Edge.
L'alta disponibilità (HA) è abilitata per impostazione predefinita. In un ambiente di produzione è consigliabile non disabilitare l'alta disponibilità.
Nota: per impostazione predefinita, kube-scheduler non pianifica i pod nel nodo master. Nel file YAML di NCP viene aggiunta una tolleranza per consentire l'esecuzione del pod NCP nel nodo master.
Configurazione di SNAT
ncp/no_snat: True
[coe] enable_snat = False
Nota: l'aggiornamento di un'annotazione SNAT dello spazio dei nomi esistente non è supportato. Se si esegue tale azione, lo stato della topologia per lo spazio dei nomi sarà incoerente perché potrebbe rimanere una regola SNAT obsoleta. Per il ripristino dallo stato incoerente, è necessario ricreare lo spazio dei nomi.
[nsx_v3] configure_t0_redistribution = True
Se l'opzione configure_t0_redistribution è impostata su True, NCP aggiungerà una voce della mappa di routing deny nella regola di ridistribuzione per impedire che il router di livello 0 annunci le subnet interne del cluster ai router adiacenti BGP. Questa opzione viene utilizzata principalmente per i cluster di vSphere with Kubernetes. Se non si crea una mappa di routing per la regola di ridistribuzione, NCP creerà una mappa di routing utilizzando la sua identità entità e la applicherà alla regola. Se si desidera modificare questa mappa di routing, è necessario sostituirla con una nuova mappa di routing, copiare le voci della mappa di routing creata da NCP e aggiungere nuove voci. È necessario gestire eventuali conflitti tra le nuove voci e le voci create da NCP. Se si annulla semplicemente l'impostazione della mappa di routing creata da NCP senza creare una nuova mappa di routing per la regola di ridistribuzione, NCP applicherà nuovamente la mappa di routing creata in precedenza alla regola di ridistribuzione quando verrà riavviato.
Configurazione della corrispondenza del firewall per le regole NAT
[nsx_v3] # This parameter indicate how firewall is applied to a traffic packet. # Firewall can be bypassed, or be applied to external/internal address of # NAT rule # Choices: MATCH_EXTERNAL_ADDRESS MATCH_INTERNAL_ADDRESS BYPASS #natfirewallmatch = MATCH_INTERNAL_ADDRESS
Aggiornamento delle specifiche del DaemonSet nsx-node-agent
- Livello di registrazione e directory dei registri.
- IP del server dell'API Kubernetes, percorso del certificato e percorso del token client. Per impostazione predefinita, viene utilizzato il valore ClusterIP del server API della variabile di ambiente e il certificato e il token vengono montati automaticamente da ServiceAccount. In genere non è necessaria alcuna modifica.
- Porta di uplink OpenvSwitch. Ad esempio: ovs_uplink_port=eth1
- Valore MTU per CNI.
Per impostare il valore MTU per CNI, modificare il parametro mtu in ConfigMap di nsx-node-agent e riavviare i pod nsx-ncp-bootstrap. Il valore MTU del pod verrà aggiornato in ogni nodo. È inoltre necessario aggiornare il valore MTU del nodo di conseguenza. La mancata corrispondenza tra il valore MTU del nodo e del pod può causare problemi di comunicazione tra il nodo e il pod influendo ad esempio sui probe di attività e di idoneità di TCP.
Il DaemonSet nsx-ncp-bootstrap installa i moduli kernel CNI e OVS nel nodo. Arresta quindi i daemon OVS nel nodo, in modo che in seguito il container nsx-ovs possa eseguire i daemon OVS in un container Docker. Quando CNI non è installato, lo stato di tutti i nodi Kubernetes è "Non pronto". Nel DaemonSet di bootstrap è presente una tolleranza per consentire l'esecuzione nei nodi con stato "Non pronto". Dopo l'installazione del plug-in CNI, lo stato dei nodi diventa "Pronto".
Se non si utilizza il modulo kernel OVS di NSX, è necessario aggiornare il parametro di volume host-original-ovs-db con il percorso corretto della posizione in cui si trova il database OpenvSwitch durante la compilazione del modulo kernel OVS. Ad esempio, se si specifica --sysconfdir=/var/lib, impostare host-original-ovs-db su /var/lib/openvswitch. Assicurarsi di utilizzare il percorso del database OVS effettivo e non un link simbolico che punta a tale database.
Se si utilizza il modulo kernel OVS di NSX, è necessario impostare use_nsx_ovs_kernel_module = True e rimuovere i commenti dalle righe sui volumi da montare:
# Uncomment these mounts if installing NSX-OVS kernel module # # mount host lib modules to install OVS kernel module if needed # - name: host-modules # mountPath: /lib/modules # # mount openvswitch database # - name: host-config-openvswitch # mountPath: /etc/openvswitch # - name: dir-tmp-usr-ovs-kmod-backup # # we move the usr kmod files to this dir temporarily before # # installing new OVS kmod and/or backing up existing OVS kmod backup # mountPath: /tmp/nsx_usr_ovs_kmod_backup # # mount linux headers for compiling OVS kmod # - name: host-usr-src # mountPath: /usr/src ... # Uncomment these volumes if installing NSX-OVS kernel module # - name: host-modules # hostPath: # path: /lib/modules # - name: host-config-openvswitch # hostPath: # path: /etc/openvswitch # - name: dir-tmp-usr-ovs-kmod-backup # hostPath: # path: /tmp/nsx_usr_ovs_kmod_backup # - name: host-usr-src # hostPath: # path: /usr/src
Se si intende specificare hostPort per un pod, impostare enable_hostport_snat su True nella sezione [k8s] di ConfigMap di nsx-node-agent-config. Nella stessa ConfigMap, use_ncp_portmap deve essere impostato su False (il valore predefinito) se si installa un plug-in CNI. Se non si installa un plug-in CNI e si desidera utilizzare portmap dell'immagine NCP, impostare use_ncp_portmap su True.
ingress:
- from:
- namespaceSelector:
matchLabels:
project: test
- podSelector:
matchLabels:
app: tea
- ipBlock:
cidr: 172.10.0.3/32
- ipBlock:
cidr: 172.10.0.2/32
...
- nsx-node-agent gestisce le interfacce di rete dei container. Interagisce con il plug-in CNI e il server dell'API di Kubernetes.
- nsx-kube-proxy implementa l'astrazione del servizio Kubernetes convertendo gli IP dei cluster in IP dei pod. Implementa la stessa funzionalità di kube-proxy upstream, ma non si escludono a vicenda.
- nsx-ovs esegue i daemon dello spazio utente OpenvSwitch. Crea anche il bridge OVS automaticamente e sposta l'indirizzo IP e le route nuovamente da node-if a br-int. È necessario aggiungere ovs_uplink_port=ethX in ncp.ini in modo che possa utilizzare ethX come uplink del bridge OVS.
Se i nodi worker utilizzano Ubuntu, ncp-ubuntu.yaml presuppone che il modulo kernel AppArmor sia abilitato. In caso contrario, Kubelet rifiuterà di eseguire il DaemonSet nsx-node-agent perché è configurato con l'opzione AppArmor. Per Ubuntu e SUSE, è abilitato per impostazione predefinita. Per verificare se il modulo è abilitato, controllare il file /sys/module/apparmor/parameters/enabled.
- Rimuovere l'opzione AppArmor:
annotations: # The following line needs to be removed container.apparmor.security.beta.kubernetes.io/nsx-node-agent: localhost/node-agent-apparmor - Abilitare la modalità privilegiata per entrambi i container nsx-node-agent e nsx-kube-proxy:
securityContext: # The following line needs to be appended privileged: true
Nota: se kubelet viene eseguito in un container che utilizza l'immagine hyperkube, kubelet segnalerà sempre che AppArmor è disabilitato indipendentemente dallo stato effettivo. Le stesse modifiche indicate sopra devono essere apportate e applicate al file YAML.
Aggiornamento del nome dello spazio dei nomi
Nel file YAML tutti gli oggetti con spazio dei nomi come ServiceAccount, ConfigMap e Deployment vengono creati sotto lo spazio dei nomi nsx-system. Se si utilizza uno spazio dei nomi diverso, sostituire tutte le istanze di nsx-system.
Abilitazione di backup e ripristino
NCP supporta la funzionalità di backup e ripristino in NSX-T. Le risorse supportate sono spazio dei nomi, pod e servizio.
Nota: NCP deve essere configurato in modalità Criterio.
[k8s] enable_restore = True
nsxcli > get ncp-restore status NCP restore status is INITIAL
Lo stato può essere INITIAL, RUNNING o SUCCESS. INITIAL significa che la funzionalità di backup/ripristino è pronta, ma non è in esecuzione alcun ripristino. RUNNING significa che il processo di ripristino è in esecuzione in NCP. SUCCESS significa che un ripristino è stato completato correttamente. Se si verifica un errore durante un ripristino, NCP verrà riavviato automaticamente e verrà eseguito un nuovo tentativo. Se lo stato è RUNNING per un lungo periodo di tempo, verificare la presenza di eventuali messaggi di errore nel registro di NCP.
