Le fichier YAML NCP contient des informations pour configurer, installer et exécuter tous les composants NCP.
- Définitions RBAC.
- Divers CRD (CustomResourceDefinitions).
- ConfigMap contenant ncp.ini dédié à NCP. Certaines options de configuration recommandées sont déjà définies.
- Déploiement NCP.
- ConfigMap contenant ncp.ini dédié à nsx-node-agent. Certaines options de configuration recommandées sont déjà définies.
- DaemonSet ssx-node-agent, y compris nsx-node-agent, nsx-kube-proxy et nsx-ovs.
- DaemonSet nsx-ncp-bootstrap
Les modules de noyau CNI et OpenvSwitch de NSX sont installés automatiquement par nsx-ncp-bootstrap initContainers. Les démons d'espace utilisateur OpenvSwitch sont en cours d'exécution dans le conteneur nsxy-ovs sur chaque nœud.
Mettre à jour les spécifications de déploiement NCP
- Niveau de journal et répertoire des journaux.
- Adresse IP du serveur d'API Kubernetes, chemin d'accès de certificat et chemin d'accès du jeton client. Par défaut, le serveur d'API ClusterIP de la variable d'environnement est utilisé et le certificat et le jeton sont automatiquement montés à partir de ServiceAccount. En général, aucune modification n'est requise.
- Nom du cluster Kubernetes.
- Adresse IP et informations d'identification NSX Manager.
- Options de ressources NSX telles que overlay_tz, top_tier_router, container_ip_blocks, external_ip_blocks, etc.
Par défaut, l'adresse IP virtuelle/le port du service Kubernetes et le ca_file et jeton ServiceAccount sont utilisés pour l'accès aux API Kubernetes. Aucune modification n'est requise ici, mais vous devez renseigner certaines options de NSX API de ncp.ini.
- Spécifiez l'option nsx_api_managers. Il peut s'agir d'une liste séparée par des virgules d'adresses IP NSX Manager ou de spécifications d'URL conformes à RFC3896. Par exemple,
nsx_api_managers = 192.168.1.181, 192.168.1.182, 192.168.1.183
- Spécifiez les options nsx_api_user et nsx_api_password avec le nom d'utilisateur et le mot de passe, respectivement, si vous configurez NCP pour qu'il se connecte à NSX-T à l'aide de l'authentification de base. Cette méthode d'authentification n'est pas recommandée, car elle est moins sécurisée. Ces options sont ignorées si NCP est configuré pour s'authentifier à l'aide de certificats clients. Ces options n'apparaissent pas dans le fichier YAML NCP. Vous devez les ajouter manuellement.
- Spécifiez les options nsx_api_cert_file et nsx_api_private_key_file pour l'authentification avec NSX-T. L'option nsx_api_cert_file est le chemin d'accès complet à un fichier de certificat client au format PEM. Le contenu de ce fichier devrait ressembler à ce qui suit :
-----BEGIN CERTIFICATE----- <certificate_data_base64_encoded> -----END CERTIFICATE-----
L'option nsx_api_private_key_file est le chemin d'accès complet vers un fichier de clé privée client au format PEM. Le contenu de ce fichier devrait ressembler à ce qui suit :-----BEGIN PRIVATE KEY----- <private_key_data_base64_encoded> -----END PRIVATE KEY-----
À l'aide de l'authentification par certificat client, NCP peut utiliser son identité principale pour créer des objets NSX-T. Cela signifie que seule une identité avec le même nom d'identité peut modifier ou supprimer les objets. Elle empêche les objets NSX-T créés par NCP d'être modifiés ou supprimés par erreur. Notez qu'un administrateur peut modifier ou supprimer n'importe quel objet. Si l'objet a été créé avec une identité principale, un avertissement indique cette information.
- (Facultatif) Spécifiez l'option ca_file. La valeur doit être un fichier de bundle d'autorité de certification à utiliser pour la vérification du certificat du serveur NSX Manager. Si aucune valeur n'est définie, les autorités de certification racines du système seront utilisées. Si vous spécifiez une adresse IP pour nsx_api_managers, spécifiez un fichier d'autorité de certification. Si vous spécifiez trois adresses IP pour nsx_api_managers, vous pouvez spécifier un ou trois fichiers d'autorité de certification. Si vous spécifiez un fichier d'autorité de certification, il sera utilisé pour les trois gestionnaires. Si vous spécifiez trois fichiers d'autorité de certification, chacun sera utilisé pour l'adresse IP correspondante dans nsx_api_managers. Par exemple,
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
- (Facultatif) Spécifiez l'option insecure. Si cette valeur est définie sur Vrai, le certificat du serveur NSX Manager n'est pas vérifié. La valeur par défaut est Faux.
- Ajoutez des volumes secrets à la spécification de l'espace NCP ou supprimez les commentaires des exemples de volumes secrets.
- Ajoutez des montages de volume à la spécification de conteneur NCP ou annulez le commentaire des exemples de montages de volume.
- Mettez à jour ncp.ini dans le ConfigMap pour définir le chemin d'accès au fichier de certificat pointant vers le fichier dans le volume monté.
Si vous ne disposez pas d'une topologie de niveau 1 partagée, vous devez définir l'option edge_cluster sur l'identifiant du cluster Edge afin que NCP crée une passerelle ou un routeur de niveau 1 pour le service LoadBalancer. Vous pouvez trouver l'identifiant du cluster Edge en accédant à , en sélectionnant l'onglet Clusters Edge et en cliquant sur le nom du cluster Edge.
HA (haute disponibilité) est activée par défaut. Dans un environnement de production, il est recommandé de ne pas désactiver HA.
Remarque : Kube-Scheduler par défaut ne planifie pas les espaces sur le nœud maître. Dans le fichier YAML NCP, une tolérance est ajoutée pour autoriser l'exécution de l'espace NCP sur le nœud maître.
Configurer SNAT
ncp/no_snat: True
[coe] enable_snat = False
Remarque : la mise à jour d'une annotation SNAT d'espace de noms existante n'est pas prise en charge. Si vous effectuez ce type d'action, la topologie de l'espace de noms sera dans un état incohérent, car une règle SNAT périmée peut rester. Pour effectuer une récupération à partir d'un état incohérent, vous devez recréer l'espace de noms.
[nsx_v3] configure_t0_redistribution = True
Si configure_t0_redistribution est défini sur True, NCP ajoute une entrée de carte de route deny dans la règle de redistribution pour empêcher le routeur de niveau 0 d'annoncer les sous-réseaux internes du cluster aux voisins BGP. Cela est principalement utilisé pour les clusters vSphere with Kubernetes. Si vous ne créez pas de carte de route pour la règle de redistribution, NCP créera une carte de route à l'aide de son identité de principal et l'appliquera dans la règle. Si vous souhaitez modifier cette carte de route, vous devez la remplacer par une nouvelle carte de route, copier les entrées de la carte de route créée par NCP et ajouter de nouvelles entrées. Vous devez gérer les conflits potentiels entre les nouvelles entrées et les entrées créées par NCP. Si vous annulez simplement la carte de route créée par NCP sans créer de carte de route pour la règle de redistribution, NCP appliquera à nouveau la carte de route créée précédemment à la règle de redistribution lors du redémarrage de NCP.
Mettre à jour les spécifications DaemonSet de nsx-node-agent
- Niveau de journal et répertoire des journaux.
- Adresse IP du serveur d'API Kubernetes, chemin d'accès de certificat et chemin d'accès du jeton client. Par défaut, le ClusterIP du serveur d'API de la variable d'environnement est utilisé, et le certificat et le jeton sont automatiquement montés à partir de ServiceAccount. En général, aucune modification n'est requise.
- Port de liaison montante OpenvSwitch. Par exemple : ovs_uplink_port=eth1
- Valeur MTU pour CNI.
Pour définir la valeur MTU pour CNI, modifiez le paramètre mtu dans le ConfigMap nsx-node-agent et redémarrez les espaces nsx-ncp-bootstrap. Cela mettra à jour le MTU de l'espace sur chaque nœud. Vous devez également mettre à jour le MTU du nœud en conséquence. Une incompatibilité entre le nœud et le MTU de l'espace peut entraîner des problèmes de communication de l'espace de nœud, affectant, par exemple, des sondes de réactivité et de disponibilité TCP.
Le DaemonSet nsx-ncp-bootstrap installe les modules de noyau CNI et OVS sur le nœud. Il arrête ensuite les démons OVS sur le nœud, afin que le conteneur nsx-ovs plus récent puisse exécuter des démons OVS dans un conteneur Docker. Lorsque CNI n'est pas installé, tous les nœuds Kubernetes sont dans l'état « non prêt ». Il existe une tolérance sur le DaemonSet de démarrage pour lui permettre de s'exécuter sur les nœuds « non prêt ». Après l'installation du plug-in CNI, les nœuds doivent devenir « prêts ».
Si vous n'utilisez pas un module de noyau OVS NSX, vous devez mettre à jour le paramètre de volume host-original-ovs-db avec le chemin d'accès correct dans lequel la base de données OpenvSwitch est configurée au cours de la compilation du module de noyau OVS. Par exemple, si vous spécifiez --sysconfdir=/var/lib, définissez host-original-ovs-db sur /var/lib/openvswitch. Assurez-vous d'utiliser le chemin de la base de données OVS réelle et non un lien symbolique pointant vers elle.
Si vous utilisez le module de noyau OVS NSX, vous devez définir use_nsx_ovs_kernel_module = True et supprimer les commentaires des lignes sur les volumes à monter :
# 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
À partir de NCP 3.1.1, hostPort est pris en charge. Si vous envisagez de spécifier hostPort pour un espace, définissez enable_hostport_snat sur True dans la section [k8s] dans le ConfigMap nsx-node-agent-config. Dans le même ConfigMap, use_ncp_portmap doit être défini sur False (valeur par défaut) si vous installez un plug-in CNI. Si vous n'installez pas de plug-in CNI et que vous souhaitez utiliser portmap depuis l'image NCP, définissez use_ncp_portmap sur 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 gère les interfaces réseau de conteneur. Il interagit avec le plug-in CNI et le serveur d'API Kubernetes.
- nsx-kube-proxy met en œuvre l'abstraction du service Kubernetes en convertissant les adresses IP du cluster en adresses IP d'espace. Il met en œuvre la même fonctionnalité que le flux en amont kube-proxy, mais ne s'y exclut pas mutuellement.
- nsx-ovs exécute les démons d'espace utilisateur OpenvSwitch. Il crée également le pont OVS automatiquement et déplace l'adresse IP et les routes de node-if vers br-int. Vous devez ajouter ovs_uplink_port=ethX dans le ncp.ini afin qu'il puisse utiliser ethX en tant que liaison montante de pont OVS.
Si les nœuds travailleurs utilisent Ubuntu, le ncp-ubuntu.yaml suppose que le module de noyau AppArmor est activé, sinon Kubelet refusera d'exécuter le DaemonSet nsx-node-agent, car il est configuré avec l'option AppArmor. Pour Ubuntu et SUSE, il est activé par défaut. Pour vérifier si le module est activé, consultez le fichier /sys/module/apparmor/parameter/enable.
- Supprimez l'option AppArmor :
annotations: # The following line needs to be removed container.apparmor.security.beta.kubernetes.io/nsx-node-agent: localhost/node-agent-apparmor - Activer le mode privilégié pour les conteneurs nsx-node-agent et nsx-kube-proxy
securityContext: # The following line needs to be appended privileged: true
Notez que si kubelet est exécuté à l'intérieur d'un conteneur qui utilise l'image hyperkube, kubelet signale toujours AppArmor comme étant désactivé, quel que soit l'état réel. Les mêmes modifications ci-dessus doivent être apportées et appliquées au fichier YAML.
Mettre à jour le nom de l'espace de noms
Dans le fichier YAML, tous les objets d'espace de noms tels que ServiceAccount, ConfigMap, Deployment sont créés sous l'espace de noms nsx-system. Si vous utilisez un espace de noms différent, remplacez toutes les instances de nsx-system.
