El archivo YAML de NCP contiene información para configurar, instalar y ejecutar todos los componentes de NCP.
- Definiciones de RBAC.
- Varias CRD (CustomResourceDefinitions).
- ConfigMap con ncp.ini dedicado a NCP. Algunas opciones de configuración recomendadas ya están configuradas.
- Implementación de NCP.
- ConfigMap con ncp.ini dedicado a nsx-node-agent. Algunas opciones de configuración recomendadas ya están configuradas.
- DaemonSet nsx-node-agent, incluidos nsx-node-agent, nsx-kube-proxy y nsx-ovs.
- DaemonSet nsx-ncp-bootstrap
Los módulos de kernel OpenvSwitch y CNI de NSX se instalan automáticamente mediante initContainers nsx-ncp-bootstrap. Los demonios de espacio de usuario OpenvSwitch se ejecutan en el contenedor de nsx-ovs en cada nodo.
Actualizar las especificaciones de implementación de NCP
- Nivel de registro y directorio de registro.
- IP de servidor de API de Kubernetes, ruta de certificado y ruta de acceso de token de cliente. De forma predeterminada, se utiliza el servidor de API ClusterIP de la variable de entorno, y el certificado y el token se montan automáticamente desde ServiceAccount. Por lo general, no es necesario realizar ningún cambio.
- Nombre del clúster de Kubernetes.
- IP y credenciales de NSX Manager.
- Opciones de recursos de NSX, como overlay_tz, top_tier_router, container_ip_blocks, external_ip_blocks, etc.
De forma predeterminada, se usan la VIP y el puerto del servicio de Kubernetes, el token ServiceAccount y ca_file para el acceso a la API de Kubernetes. No se requiere ningún cambio aquí, pero se deben rellenar algunas opciones de NSX API de ncp.ini.
- Especifique la opción nsx_api_managers. Puede ser una lista separada por comas de especificaciones de URO o direcciones IP de NSX Manager que cumplan con RFC3896. Por ejemplo,
nsx_api_managers = 192.168.1.181, 192.168.1.182, 192.168.1.183
- Especifique las opciones nsx_api_user y nsx_api_password con el nombre de usuario y la contraseña, respectivamente, si configura NCP para que se conecte a NSX mediante la autenticación básica. Este método de autenticación no se recomienda porque es menos seguro. Estas opciones se ignoran si NCP está configurado para autenticarse con certificados de cliente. Estas opciones no aparecen en el archivo YAML de NCP. Debe agregarlos manualmente.
- Especifique las opciones nsx_api_cert_file y nsx_api_private_key_file para la autenticación con NSX. La opción nsx_api_cert_file es la ruta completa a un archivo de certificado de cliente en formato PEM. El contenido de este archivo debe ser similar al siguiente:
-----BEGIN CERTIFICATE----- <certificate_data_base64_encoded> -----END CERTIFICATE-----
La opción nsx_api_private_key_file es la ruta completa a un archivo de clave privada cliente en formato PEM. El contenido de este archivo debe ser similar al siguiente:-----BEGIN PRIVATE KEY----- <private_key_data_base64_encoded> -----END PRIVATE KEY-----
Mediante el uso de la autenticación de certificados de cliente, NCP puede utilizar su identidad principal para crear objetos de NSX. Esto significa que solo una identidad con el mismo nombre podrá modificar o eliminar los objetos. Evita que los objetos de NSX creados por NCP se modifiquen o se eliminen por error. Tenga en cuenta que un administrador puede modificar o eliminar cualquier objeto. Si el objeto se crea con el nombre de una identidad principal, aparecerá una advertencia que lo indique.
- (Opcional) Especifique la opción ca_file. El valor debe ser un archivo de paquete de CA que se usa para verificar el certificado del servidor de NSX Manager. Si no se establece, se usarán las CA raíz del sistema. Si especifica una dirección IP para nsx_api_managers, especifique un archivo de CA. Si especifica tres direcciones IP para nsx_api_managers, puede especificar uno o tres archivos de CA. Si especifica un archivo de CA, se utilizará para los tres administradores. Si especifica tres archivos de CA, cada uno se utilizará para la dirección IP correspondiente en nsx_api_managers. Por ejemplo,
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
- (Opcional) Especifique la opción insecure. Si se establece en el valor True, no se verificará el certificado del servidor de NSX Manager. El valor predeterminado es False.
- Agregue volúmenes secretos a la especificación de pod de NCP o quite la marca de comentario de los volúmenes secretos de ejemplo.
- Agregue montajes de volúmenes a la especificación de contenedor de NCP o quite la marca de comentario de los montajes de volumen de ejemplo.
- Actualice ncp.ini en ConfigMap para establecer la ruta del archivo de certificado que apunta al archivo en el volumen montado.
Si no tiene una topología de nivel 1 compartida, debe establecer la opción edge_cluster en el identificador del clúster de Edge para que NCP cree una puerta de enlace o un enrutador de nivel 1 para el servicio de equilibrador de carga. Para encontrar el identificador de clúster de Edge, vaya a , seleccione la pestaña Clústeres de Edge y haga clic en el nombre del clúster de Edge.
HA (alta disponibilidad) está habilitada de forma predeterminada. En un entorno de producción, se recomienda no deshabilitar HA.
Nota: De forma predeterminada, kube-scheduler no programará pods en el nodo principal. En el archivo YAML de NCP, se agrega una tolerancia para permitir que el pod de NCP se ejecute en el nodo principal.
El parámetro lb_segment_subnet en ncp.ini se utiliza para el acceso automático al servicio ClusterIP. El valor predeterminado es 169.254.131.0/24. NCP usará la penúltima dirección IP de esta subred como la IP de SNAT. Por ejemplo, si se configura lb_segment_subnet con el valor 169.254.100.0/24, NCP usará 169.254.100.254 como la IP de SNAT. En un nodo de trabajo Windows, debe configurar lb_segment_subnet con un valor que no sea 169.254.131.0/24. No podrá cambiar lb_segment_subnet después de crear el clúster.
Configurar SNAT
ncp/no_snat: True
[coe] enable_snat = False
Nota: No se puede actualizar una anotación SNAT de espacio de nombres existente. Si realiza una acción de este tipo, la topología del espacio de nombres entrará en un estado incoherente porque es posible que quede una regla SNAT obsoleta. Para solucionar un estado incoherente, debe volver a crear el espacio de nombres.
[nsx_v3] configure_t0_redistribution = True
Si configure_t0_redistribution se configura como True, NCP agregará una entrada de mapa de rutas deny en la regla de redistribución para evitar que el enrutador de nivel 0 anuncie las subredes internas del clúster a los vecinos BGP. Se utiliza principalmente para clústeres de vSphere with Kubernetes. Si no crea un mapa de rutas para la regla de redistribución, NCP creará un mapa de rutas utilizando su identidad principal y lo aplicará a la regla. Si desea modificar este mapa de rutas, deberá reemplazarlo con un nuevo mapa de rutas, copiar las entradas del mapa de rutas creado por NCP y agregar nuevas entradas. Debe administrar cualquier posible conflicto entre las nuevas entradas y las entradas creadas por NCP. Si solo se anula la asignación de un mapa de rutas creado por NCP sin crear uno nuevo para la regla de redistribución, NCP volverá a aplicar el mapa de rutas existente a la regla de redistribución cuando se reinicie NCP.
Configurar la coincidencia de firewall para reglas 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
Actualizar las especificaciones del DaemonSet nsx-node-agent
- Nivel de registro y directorio de registro.
- IP de servidor de API de Kubernetes, ruta de certificado y ruta de acceso de token de cliente. De forma predeterminada, se utiliza el servidor de API ClusterIP de la variable de entorno, y el certificado y el token se montan automáticamente desde ServiceAccount. Por lo general, no es necesario realizar ningún cambio.
- Puerto de vínculo superior de OpenvSwitch. Por ejemplo: ovs_uplink_port=eth1
- El valor de MTU para CNI.
Para establecer el valor de MTU para CNI, modifique el parámetro mtu en ConfigMap de nsx-node-agent y reinicie los pods nsx-ncp-bootstrap. Esta acción actualizará la MTU del pod en cada nodo. También debe actualizar la MTU del nodo según corresponda. Un error de coincidencia entre el nodo y la MTU del pod puede causar problemas en la comunicación nodo-pod, lo que afecta a, por ejemplo, los sondeos de disponibilidad y la ejecución de TCP.
El DaemonSet nsx-ncp-bootstrap instala los módulos de kernel de CNI y OVS en el nodo. A continuación, se cierran los demonios de OVS en el nodo, para que el contenedor nsx-ovs posterior pueda ejecutar demonios de OVS dentro de un contenedor del docker. Si CNI no está instalado, todos los nodos de Kubernetes tienen el estado "No listo". Se tolera en el DaemonSet de arranque para permitir que se ejecute en nodos con el estado "No listo". Después de instalar el complemento CNI, los nodos deben tener el estado "Listo".
Si no utiliza el módulo kernel de NSX OVS, debe actualizar el parámetro de volumen host-original-ovs-db con la ruta correcta en la que se haya configurado la base de datos de OpenvSwitch durante la compilación del módulo kernel de OVS. Por ejemplo, si especifica --sysconfdir=/var/lib, establezca host-original-ovs-db como /var/lib/openvswitch. Asegúrese de utilizar la ruta de la base de datos de OVS y no un vínculo simbólico que redirija a ella.
Si utiliza el módulo kernel de NSX OVS, debe establecer use_nsx_ovs_kernel_module = True y quitar la marca de comentario de las líneas sobre los volúmenes que se van a montar:
# 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
Si tiene pensado especificar un hostPort para un pod, establezca enable_hostport_snat como True en la sección [k8s] del ConfigMap nsx-node-agent-config. En el mismo ConfigMap, use_ncp_portmap debe establecerse en False (el valor predeterminado) si instala un complemento CNI. Si no instala ningún complemento CNI y desea utilizar portmap desde la imagen de NCP, establezca use_ncp_portmap en 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 administra las interfaces de red de contenedor. Interactúa con el complemento CNI y el servidor de la API de Kubernetes.
- nsx-kube-proxy implementa la abstracción del servicio de Kubernetes traduciendo las direcciones IP del clúster a las IP de pods. Implementa la misma funcionalidad que el de la secuencia ascendente kube-proxy, pero no es mutuamente exclusiva.
- nsx-ovs ejecuta los demonios del espacio de usuario de OpenvSwitch. También creará automáticamente el puente de OVS y moverá la dirección IP y las rutas de datos de node-if a br-int. Debe agregar ovs_uplink_port=ethX en ncp.ini para que pueda usar ethX como el vínculo superior de puente de OVS.
Si los nodos de trabajado usan Ubuntu, ncp-ubuntu.yaml asume que el módulo de kernel AppArmor está habilitado; de lo contrario, Kubelet no ejecutará el DaemonSet nsx-node-agent, ya que está configurado con la opción AppArmor. Para Ubuntu y SUSE, está habilitado de forma predeterminada. Para comprobar si el módulo está habilitado, compruebe el archivo /sys/module/apparmor/parameters/enabled.
- Elimine la opción AppArmor:
annotations: # The following line needs to be removed container.apparmor.security.beta.kubernetes.io/nsx-node-agent: localhost/node-agent-apparmor - Habilite el modo privilegiado para los contenedores nsx-node-agent y nsx-kube-proxy
securityContext: # The following line needs to be appended privileged: true
Nota: Si se ejecuta kubelet en un contenedor que usa la imagen hyperkube, kubelet siempre notifica que AppArmor está deshabilitado, independientemente del estado real. Se deben realizar los mismos cambios anteriores y aplicarlos al archivo YAML.
Actualizar el nombre del espacio de nombres
En el archivo YAML, todos los objetos con espacio de nombres, como ServiceAccount, ConfigMap, Deployment, se crean en el espacio de nombres nsx-system. Si utiliza un espacio de nombres diferente, reemplace todas las instancias de nsx-system.
Habilitar copia de seguridad y restauración
NCP admite la función de copia de seguridad y restauración en NSX. Los recursos admitidos son Espacio de nombres, Pod y Servicio.
Nota: NCP debe configurarse en el modo de directiva.
[k8s] enable_restore = True
nsxcli > get ncp-restore status NCP restore status is INITIAL
El estado puede ser INITIAL, RUNNING o SUCCESS. INITIAL significa que la función de copia de seguridad/restauración está lista, pero no se está ejecutando ninguna restauración. RUNNING significa que el proceso de restauración se está ejecutando en NCP. SUCCESS significa que UNA restauración se completó correctamente. Si se produce un error durante una restauración, NCP se reiniciará automáticamente y volverá a intentarlo. Si el estado es RUNNING durante mucho tiempo, compruebe si hay mensajes de error en el registro de NCP.
