Usa el plugin kubectl mongodb para:
Antes de comenzar, instale el plugin de kubectl MongoDB.
El kubectl mongodb plugin tiene los siguientes subcomandos:
subcomando configurar
El subcomando kubectl mongodb multicluster setup configura la implementación inicial de MongoDB en múltiples clústeres Kubernetes. Realiza las siguientes acciones:
Crea un ConfigMap por defecto llamado
mongodb-kubernetes-operator-member-listque contiene todos los nodos clústeres de la implementación multi-Kubernetes de MongoDB. Este nombre está codificado y no puedes cambiarlo. Ver Problemas conocidos.Crea ServiceAccounts, Roles, ClusterRoles, RoleBindings y ClusterRoleBindings en el clúster central y cada clúster nodo.
Aplica los permisos correctos para las cuentas de servicio.
Utiliza la configuración anterior para crear tu implementación MongoDB multi-clúster de Kubernetes.
Opciones de subcomando de configuración
El subcomando setup del plugin kubectl mongodb tiene las siguientes opciones:
Opción | Tipo de dato | Descripción |
|---|---|---|
| string | Requerido. Clúster central en el que se implementará el operador de Kubernetes, como: |
| string | Obligatorio. Namespace donde se implementará el operador de Kubernetes, como: |
| booleano | opcional. Bandera que indica si se deben borrar todos los recursos creados previamente, excepto los espacios de nombres. El valor por defecto es |
| booleano | Opcional. Indicador que indica si se deben crear ClusterRole y ClusterRoleBindings para clúster de nodos. El valor es por defecto |
| booleano | opcional. Indicador que señala si se deben crear secretos para las cuentas de servicios en el servidor API de Kubernetes. El valor por defecto es |
| booleano | Opcional. Marca que indica si se deben instalar las cuentas de servicio y los roles necesarios para ejecutar cargas de trabajo de MongoDB en los clústeres nodos. El valor es por defecto |
| booleano | opcional. Señal que indica si las cuentas de servicio que crea el plugin |
| string | Obligatorio. Lista separada por comas que contiene clústeres nodos, como: |
| string | Opcional. Ruta a un paquete de CA codificado en PEM que el operador de Kubernetes utiliza para llegar al servidor de API de Kubernetes de un clúster de nodos, en el |
| string | Obligatorio. Espacio de nombres al que se implementarán los recursos del clúster nodo, como: |
| string | opcional. Nombre de la cuenta de servicio que el Operador de Kubernetes debe usar para comunicarse con los clústeres nodos. El valor por defecto es |
Para ver un ejemplo completo del uso del subcomando kubectl mongodb plugin setup, consulta el inicio rápido de múltiples clústeres de Kubernetes.
Recuperar subcomando
El subcomando kubectl mongodb multicluster puede recuperar automáticamente una topología de clúster fallida en algunos casos. En otros casos, debe recuperarse manualmente de una falla. Para obtener más información, consulta Recuperación ante Desastres.
opciones del subcomando recover
El subcomando recover del plugin kubectl mongodb tiene las siguientes opciones:
Opción | Tipo de dato | Descripción |
|---|---|---|
| string | Requerido. Clúster central en el que se implementará el operador de Kubernetes, como: |
| string | Obligatorio. Namespace donde se implementará el operador de Kubernetes, como: |
| booleano | opcional. Bandera que indica si se deben borrar todos los recursos creados previamente, excepto los espacios de nombres. El valor por defecto es |
| booleano | Opcional. Indicador que indica si se deben crear ClusterRole y ClusterRoleBindings para clúster de nodos. El valor es por defecto |
| string | Opcional. Ruta a un paquete de CA codificado en PEM que el operador de Kubernetes utiliza para llegar al servidor de API de Kubernetes de un clúster de nodos, en el |
Para un ejemplo completo del uso del subcomando kubectl mongodb plugin recover, consulta el procedimiento manual de recuperación ante desastres.
Paquetes de CA personalizados para clústeres de nodos
Por defecto, el plugin kubectl mongodb lee la CA de cada clúster de nodo del secreto de token de cuenta de servicio de ese clúster y lo guarda en el secreto mongodb-enterprise-operator-multi-cluster-kubeconfig generado. En algunos casos, es posible que desee proporcionar un paquete de CA personalizado, por ejemplo: cuando la ruta de red desde el operador de Kubernetes a un clúster de nodos servidor de API de Kubernetes finaliza TLS en otro lugar, como en un proxy o balanceador de carga que presenta su propio certificado. Utilice la opción member-cluster-ca para proporcionar un paquete de CA personalizado.
El siguiente comando suministra un paquete de CA para dos de los tres clústeres de nodos:
kubectl mongodb multicluster setup \ --central-cluster="operator-cluster" \ --member-clusters="cluster-1,cluster-2,cluster-3" \ --member-cluster-namespace=mongodb \ --central-cluster-namespace=mongodb \ --member-cluster-ca cluster-1=/path/to/cluster-1-ca.pem \ --member-cluster-ca cluster-2=/path/to/cluster-2-ca.pemEn el ejemplo anterior, cluster-3 mantiene la CA de su secreto de token de cuenta de servicio.
Requisitos del paquete de CA
El plugin kubectl mongodb copia el contenido del archivo en el secreto de KubeConfig sin modificación, por lo que solo se deben pasar certificados. Cada archivo debe cumplir con los siguientes requisitos:
Contiene al menos un certificado codificado en PEM.
No contiene ninguna llave privada. Un paquete que exporta un terminador TLS podría colocar la llave del servidor junto a su certificado. El plugin rechaza dicho paquete con el error
found a private key (<block type> block), pass certificates only.
El plugin también devuelve un error si pasa un par <member-cluster-name>=<path-to-pem-file> mal formado, nombra un clúster de nodos que member-clusters no enumera o nombra el mismo clúster de nodos más de una vez.
Ejecuciones repetidas
Ambos subcomandos setup y recover regeneran todo el secreto de KubeConfig. Si omite un clúster de nodo de member-cluster-ca en un ejecutar posterior, ese clúster vuelve a la CA de su secreto de token de cuenta de servicio. Para conservar una CA personalizada, cada vez que ejecute cualquiera de los subcomandos, asegúrese de volver a pasar la opción member-cluster-ca para cada clúster de nodos que la requiera.
Cuando un subcomando reemplaza una CA que no coincide con el secreto de token de cuenta de servicio del clúster de nodos, el plugin imprime una advertencia similar a la siguiente:
Warning: replacing the CA for member cluster cluster-1, which does not match its ServiceAccount token secret. Pass --member-cluster-ca cluster-1=<path-to-pem-file> to keep a custom CA.La advertencia es consultiva. El subcomando aún se completa y guarda el nuevo secreto de KubeConfig.