Para agentes de IA: hay un índice de documentación disponible en https://www.mongodb.com/es/docs/llms.txt — versiones en markdown de todas las páginas están disponibles agregando .md a cualquier ruta URL.
Docs Menu
Docs Home
/ /
Implementar
Docs Home
/ /
Implementar recursos de la base de datos
/
Implementar
Docs Home
/
Gestión
/
Controladores para el Operador de Kubernetes
/
Implementar recursos de la base de datos
/
Implementar

Implementar un set de réplicas

Nota

En cualquier lugar de esta página donde diga Ops Manager, puedes sustituir Cloud Manager.

Importante

  • Puedes usar el Operador de Kubernetes para implementar recursos de MongoDB con Cloud Manager y con Ops Manager versión 6.0.x o posterior.

  • Puedes usar el Atlas Operator para implementar recursos de MongoDB en Atlas.

Advertencia

El operador de Kubernetes no es compatible con nodos árbitros.

Un set de réplicas es un grupo de implementaciones de MongoDB que mantienen el mismo conjunto de datos. Los sets de réplicas proporcionan redundancia y alta disponibilidad, y son la base de todas las implementaciones en producción.

Para obtener más información sobre los sets de réplicas, consulta la Introducción a la replicación en el manual de MongoDB.

Utiliza este procedimiento para implementar un nuevo set de réplicas que gestione Ops Manager. Después de la implementación, utiliza Ops Manager para administrar el set de réplicas, incluyendo operaciones como agregar, remover y reconfigurar nodos.

Considerations

Cuando se implementa el set de réplicas mediante el operador de Kubernetes, debe elegir si se desea cifrar las conexiones usando certificados TLS.

El siguiente procedimiento para TLS-Encrypted conexiones:

  • Establece conexiones cifradas TLSentre los hosts de MongoDB en el set de réplicas.

  • Establece conexiones cifradas mediante TLSentre aplicaciones cliente y implementaciones de MongoDB.

  • Requiere certificados válidos para el cifrado TLS.

El siguiente procedimiento para Non-Encrypted Connections:

  • No cifra las conexiones entre los hosts de MongoDB en el set de réplicas.

  • No cifra las conexiones entre las aplicaciones cliente y las implementaciones de MongoDB.

  • Tiene menos requisitos de configuración que una implementación con conexiones cifradas TLS.

Nota

No puedes asegurar una instancia autónoma de MongoDB en un clúster de Kubernetes.

Para configurar el cifrado <span class=\" \">TLS para un clúster fragmentado, consulta <a class=\" \" href=\"\">Implementar un clúster fragmentado.

Seleccione la pestaña apropiada dependiendo de si desea cifrar sus conexiones de set de réplicas con TLS.

Requisitos previos

Para implementar un set de réplicas utilizando un objeto, debe:

Nota

Para evitar almacenar secretos en implementaciones de Kubernetes de un solo clúster, puedes migrar todos los secretos a una herramienta de almacenamiento de secretos. Las implementaciones en múltiples clústeres de Kubernetes no admiten el almacenamiento de secretos en herramientas de almacenamiento de secretos, como HashiCorp Vault.

  • Genera un certificado TLS para cada uno de los siguientes componentes:

    • Tu set de réplicas. Asegúrese de agregar SANs para cada pod de Kubernetes que aloje un nodo de su set de réplicas al certificado.

      En su certificado TLS, el SAN para cada pod debe utilizar el siguiente formato:

      <pod-name>.<metadata.name>-svc.<namespace>.svc.cluster.local

      Importante

      Si utiliza un proveedor de servicios basado en ACME, como Let's Encrypt, para emitir certificados TLS, es posible que el proveedor le prohíba agregar los FQDNpredeterminados del Pod (*.svc.cluster.local) a los SANen el certificado.

      Para utilizar un certificado basado en ACME, debemos configurar el certificado para el recurso del set de réplicas. Para obtener más información, consulta el paso sobre certificados TLS basados en ACME en el procedimiento.

    • El MongoDB Agent de tu proyecto. Para el certificado del agente MongoDB, asegúrese de cumplir los siguientes requisitos:

      • El Nombre común en el certificado TLS no está vacío.

      • El conjunto de Organización y Unidad Organizacional en cada certificado TLS difiere del conjunto de Organización y Unidad Organizacional en el certificado TLS para los miembros del set de réplicas.

  • Debes tener el archivo del certificado CA y nombrarlo ca-pem.

  • Debes tener la clave que utilizaste para firmar tus certificados TLS.

Importante

El operador de Kubernetes utiliza secretos de kubernetes.io/tls para almacenar certificados TLS y claves privadas para los recursos de Ops Manager y MongoDB. A partir de la versión 1.17.0 del operador de Kubernetes, este no admite archivos PEM concatenados almacenados como secretos opacos.

Para implementar un set de réplicas utilizando un objeto, debe:

Nota

Para evitar almacenar secretos en implementaciones de Kubernetes de un solo clúster, puedes migrar todos los secretos a una herramienta de almacenamiento de secretos. Las implementaciones en múltiples clústeres de Kubernetes no admiten el almacenamiento de secretos en herramientas de almacenamiento de secretos, como HashiCorp Vault.

Implementar un set de réplicas

1

Configura kubectl para que sea por defecto en tu namespace.

Si aún no lo ha hecho, ejecute el siguiente comando para ejecutar todos los comandos de kubectl en el namespace que creó.

Nota

Si estás implementando un recurso de Ops Manager en una implementación de MongoDB multidispositivo en clústeres de Kubernetes:

  • Defina context como el nombre del clúster operador, por ejemplo: kubectl config set context "$MDB_CENTRAL_CLUSTER_FULL_NAME".

  • Establece el --namespace en el mismo ámbito que utilizaste para tu implementación de MongoDB de clústeres multi-Kubernetes, como por ejemplo: kubectl config --namespace "mongodb".

kubectl config set-context $(kubectl config current-context) --namespace=<metadata.namespace>
2

Crea el secreto para el TLS certificado de tu set de réplicas.

Ejecuta este comando kubectl para crear un nuevo secreto que almacena el certificado del set de réplicas:

kubectl create secret tls <prefix>-<metadata.name>-cert \
  --cert=<replica-set-tls-cert> \
  --key=<replica-set-tls-key>

Nota

Debe anteponer sus secretos con <prefix>-<metadata.name>.

Por ejemplo, si llama a su despliegue my-deployment y establece el prefijo en mdb, debe nombrar el secreto TLS para las comunicaciones TLS del cliente como mdb-my-deployment-cert. Además, debe nombrar el secreto TLS para la autenticación interna del clúster (si está habilitada) como mdb-my-deployment-clusterfile.

Si está utilizando HashiCorp Vault como su herramienta de almacenamiento de secretos, puede Crear un secreto de Vault en su lugar.

Para conocer sus opciones para el almacenamiento de secretos, consulte Configurar almacenamiento de secretos.

3

Crea el secreto para el certificado TLS de su agente.

Ejecuta este comando kubectl para crear un nuevo secreto que almacene el certificado TLS del agente:

kubectl create secret tls <prefix>-<metadata.name>-agent-certs \
  --cert=<agent-tls-cert> \
  --key=<agent-tls-key>

Si está utilizando HashiCorp Vault como su herramienta de almacenamiento de secretos, puede Crear un secreto de Vault en su lugar.

4

Crea el ConfigMap para vincular tu CA con tu implementación.

Ejecuta este comando kubectl para vincular tu CA a tu set de réplicas y especificar el archivo de certificado CA.

Importante

El Operador de Kubernetes requiere que el certificado para el recurso MongoDB se llame ca-pem en el ConfigMap.

kubectl create configmap custom-ca --from-file=ca-pem=<your-custom-ca-file>
5

Copia el recurso de set de réplicas de muestra.

Cambia los ajustes de este archivo YAML para que coincidan con la configuración de set de réplicas deseada.

1---
2apiVersion: mongodb.com/v1
3kind: MongoDB
4metadata:
5  name: <my-replica-set>
6spec:
7  members: 3
8  version: "8.0.0"
9  opsManager:
10    configMapRef:
11           # Must match metadata.name in ConfigMap file
12      name: <configMap.metadata.name>
13  credentials: <mycredentials>
14  type: ReplicaSet
15  persistent: true
16...
16  security:
17    tls:
18      ca: <custom-ca>
19    certsSecretPrefix: <prefix>
20...
6

Pega el ejemplo copiado para crear un nuevo set de réplicas recurso.

Abre tu editor de texto preferido y pega la especificación del objeto en un nuevo archivo de texto.

7

Cambia la configuración a tus valores preferidos.

Clave
Tipo
Descripción
Ejemplo

metadata.name

string

Etiqueta para este set de réplicas de Kubernetes objeto.

Los nombres de recursos deben tener 44 caracteres o menos.

Para aprender más, consulta metadata.name y la documentación de Kubernetes sobre nombres.

myproject

spec.members

entero

Número de nodos del set de réplicas.

3

spec.version

string

Versión de MongoDB que este set de réplicas debería ejecutar.

El formato debe ser X.Y.Z para la Community Edition y X.Y.Z-ent para la edición Enterprise.

IMPORTANTE: Asegúrate de elegir una versión compatible del servidor MongoDB. Las versiones compatibles varían según la imagen base que utiliza el recurso de la base de datos MongoDB.

Para obtener más información sobre el versionado de MongoDB, consulta versionado de MongoDB en el manual de MongoDB.

8.0.0

spec
.opsManager
.configMapRef
.name

string

Nombre del ConfigMap con la configuración de conexión de Ops Manager. La spec.cloudManager.configMapRef.name configuración es un alias para esta configuración y puede usarse en su lugar.

Este valor debe existir en el mismo espacio de nombres que el recurso que quieres crear.

IMPORTANTE: El operador de Kubernetes rastrea cualquier cambio en el ConfigMap y reconcilia el estado del recurso MongoDB.

<myconfigmap>

spec.credentials

string

Nombre del secreto que creaste como Ops Manager API credenciales de autenticación para que el operador de Kubernetes pueda comunicarse con Ops Manager.

El objeto Ops Manager Kubernetes Secret que contiene las credenciales debe existir en el mismo espacio de nombres que el recurso que desea crear.

IMPORTANTE: El operador de Kubernetes rastrea cualquier cambio realizado en el Secreto y reconcilia el estado del recurso MongoDB.

<mycredentials>

spec.type

string

Tipo de recurso MongoDB que se va a crear.

ReplicaSet

spec.persistent

string

Opcional.

Indicador que especifica si este MongoDB recurso debe usar volúmenes persistentes para el almacenamiento. Los volúmenes persistentes no se eliminan cuando el MongoDB recurso se detiene o se reinicia.

Si este valor es true, entonces spec.podSpec.persistence.single se establece en su valor por defecto de 16Gi.

Para cambiar la configuración de tu claim de volumen persistente, configura las siguientes colecciones para cumplir con los requisitos de tu implementación:

ADVERTENCIA: Otorgue a sus contenedores permiso para escribir en su Volumen Persistente. El Operador de Kubernetes fsGroup = 2000 runAsUser = 2000establece, y runAsNonRoot = true en. El securityContext Operador de Kubernetes establece fsgroup igual a runAsUser para que el volumen sea escribible para un usuario que ejecuta el proceso principal en el contenedor. Para obtener más información, consulte Configurar un Contexto de Seguridad para un Pod o Contenedor y la discusión relacionada en la documentación de Kubernetes. Si la redistribución del recurso no soluciona los problemas con su Volumen Persistente, comuníquese con el Soporte de MongoDB.

Si no utiliza volúmenes persistentes, los gráficos Disk Usage y Disk IOPS no se pueden mostrar ni en Processes la pestaña de la Deployment página ni en la Metrics página al revisar los datos de esta implementación.

true

8

Configura los ajustes de TLS para tu set de réplicas recurso usando una autoridad certificadora personalizada (CA).

Para habilitar TLS en su implementación, configure los siguientes ajustes en su objeto de Kubernetes:

Clave
Tipo
Necesidad
Descripción
Ejemplo

spec.security
.tls.ca

string

Requerido

Agrega el nombre del ConfigMap que almacena la CA personalizada que usaste para firmar los certificados TLS de tu implementación.

<custom-ca>

spec.security
.certsSecretPrefix

string

Requerido

Agrega el <prefix> del nombre secreto que contiene los certificados TLS de tu implementación de MongoDB.

Por ejemplo, si llama a su despliegue my-deployment y establece el prefijo en mdb, debe nombrar el secreto TLS para las comunicaciones TLS del cliente como mdb-my-deployment-cert. Además, debe nombrar el secreto TLS para la autenticación interna del clúster (si está habilitada) como mdb-my-deployment-clusterfile.

devDb

9

Opcional: Configura certificados ACME basados en TLS para tu recurso de set de réplicas.

Si utiliza un proveedor de servicios basado en ACME, como Let's Encrypt, para emitir certificados TLS, es posible que el proveedor le prohíba agregar los FQDNpredeterminados del Pod (*.svc.cluster.local) a los SANen el certificado.

Para configurar un certificado que no contenga los FQDNdel pod:

  1. Emitir el certificado para un dominio externo. Para obtener más información, consulte la documentación de Let's Encrypt o la documentación de su proveedor.

  2. Asegúrate de que tu certificado contenga todos los nombres de host que planeas implementar en el set de réplicas. Alternativamente, puedes emitir un certificado comodín para *.<externalDomain>.

  3. Para usar un certificado que contenga solo dominios externos para tu implementación del set de réplicas, deberás cambiar el hostname por defecto que usa el set de réplicas:

    • Si prefiere configurar el nombre de host al crear su clúster de Kubernetes, cambie el dominio predeterminado de cluster.local al dominio externo al crear o recrear su clúster de Kubernetes. Luego, configure este dominio en su recurso de MongoDB mediante la spec.clusterDomain configuración.

    • De lo contrario, cree su implementación de MongoDB con la siguiente configuración en su objeto de Kubernetes:

Clave
Tipo
Necesidad
Descripción

spec.externalAccess
.externalDomain

string

Requerido

Un dominio externo utilizado para exponer externamente su implementación de set de réplicas.

De forma predeterminada, cada miembro del conjunto de réplicas utiliza el FQDN del Pod de Kubernetes (*.svc.cluster.local) como nombre de host predeterminado. Sin embargo, si agrega un dominio externo a esta configuración, el conjunto de réplicas utilizará un nombre de host que sea un subdominio del dominio especificado. Este nombre de host utiliza el siguiente formato:

<replica-set-name>-<pod-idx>.<externalDomain>

Por ejemplo:

replica-set-1.example.com

Después de implementar el conjunto de réplicas con esta configuración, el operador de Kubernetes utiliza el nombre de host con el dominio externo para sobrescribir el processes[n].hostname campo en la configuración de automatización de Ops Manager. Luego, el agente de MongoDB utiliza este nombre de host para conectarse mongod a.

Para especificar otros nombres de host para conectarse al set de réplicas, puede utilizar el ajuste spec.connectivity.replicaSetHorizons. Sin embargo, las siguientes conexiones aún utilizan el nombre de host con el dominio externo:

  • El agente de MongoDB al que mongod conectarse.

  • mongod para conectarse a otras mongod instancias.

ADVERTENCIA: Especificar este campo cambia la forma en que Ops Manager registra mongod los procesos. No puede cambiar el valor de este campo ni de ningún otro processes[n].hostname campo en la configuración de automatización de Ops Manager para una implementación de conjunto de réplicas en ejecución.

spec.externalAccess
.externalService.spec

Colección

Opcional

Configuración para el ServiceSpec.

Al configurar el ajuste spec.externalAccess, el operador de Kubernetes crea automáticamente un servicio de balanceador de carga externo con valores por defecto. Puedes anular ciertos valores o agregar nuevos valores dependiendo de tus necesidades. Por ejemplo, si tiene la intención de crear servicios NodePort y no necesita un balanceador de cargas, debe configurar las anulaciones en su especificación de Kubernetes:

externalAccess:
  externalService:
    annotations:
      # cloud-specific annotations for the service
    spec:
      type: NodePort # default is LoadBalancer
      # you can specify other spec overrides if necessary

Para obtener más información sobre la especificación Kubernetes, consulta ServiceSpec en la documentación de Kubernetes.

spec.externalAccess
.externalService.annotations

Colección

Opcional

Pares clave-valor que le permiten agregar configuraciones específicas del proveedor de nube a todos los clústeres de su implementación. Para obtener más información, consulte anotaciones y la documentación de su proveedor de nube de Kubernetes.

Puedes especificar valores de marcador de posición para personalizar tus anotaciones. Para obtener más información, consulta spec.externalAccess.externalService.annotations.

10

Agrega cualquier configuración adicional aceptada para un set de réplicas implementación.

También puede añadir cualquiera de los siguientes ajustes opcionales al archivo de especificaciones del objeto para el set de réplicas implementación:

Advertencia

Debe configurar si su clúster spec.clusterDomain de Kubernetes tiene un dominio predeterminado distinto del cluster.local predeterminado. Si no utiliza el dominio predeterminado ni configura la spec.clusterDomain opción, es posible que el operador de Kubernetes no funcione como se espera.

11

Guarda este archivo de configuración del conjunto de réplicas con la extensión .yaml.

12

Inicie su set de réplicas.

En cualquier directorio, ejecuta el siguiente comando de Kubernetes para crear tu set de réplicas:

kubectl apply -f <replica-set-conf>.yaml
13

Rastree el estado de la implementación de su set de réplicas.

Para verificar el estado de su MongoDB recurso, utilice el siguiente comando:

kubectl get mdb <resource-name> -o yaml -w

Con la bandera -w (observar) activada, cuando la configuración cambia, la salida se actualiza inmediatamente hasta que la fase de estado alcanza el estado Running. Para obtener más información sobre el estado de implementación de recursos, consulta Solucionar problemas con el operador de Kubernetes.

Después de cifrar tu recurso de base de datos con TLS, puedes proteger lo siguiente:

Renovar los certificados TLS para un set de réplicas

Renueva sus certificados TLS periódicamente utilizando el siguiente procedimiento:

1
Configura kubectl para que sea por defecto en tu namespace.

Si aún no lo ha hecho, ejecute el siguiente comando para ejecutar todos los comandos de kubectl en el namespace que creó.

Nota

Si estás implementando un recurso de Ops Manager en una implementación de MongoDB multidispositivo en clústeres de Kubernetes:

  • Defina context como el nombre del clúster operador, por ejemplo: kubectl config set context "$MDB_CENTRAL_CLUSTER_FULL_NAME".

  • Establece el --namespace en el mismo ámbito que utilizaste para tu implementación de MongoDB de clústeres multi-Kubernetes, como por ejemplo: kubectl config --namespace "mongodb".

kubectl config set-context $(kubectl config current-context) --namespace=<metadata.namespace>
2
Renueva el secreto de tus certificados TLS.

Ejecuta este comando kubectl para renovar un secreto existente que almacena los certificados del set de réplicas:

kubectl create secret tls <prefix>-<metadata.name>-cert \
  --cert=<replica-set-tls-cert> \
  --key=<replica-set-tls-key> \
  --dry-run=client \
   -o yaml |
kubectl apply -f -
1

Configura kubectl para que sea por defecto en tu namespace.

Si aún no lo ha hecho, ejecute el siguiente comando para ejecutar todos los comandos de kubectl en el namespace que creó.

Nota

Si estás implementando un recurso de Ops Manager en una implementación de MongoDB multidispositivo en clústeres de Kubernetes:

  • Defina context como el nombre del clúster operador, por ejemplo: kubectl config set context "$MDB_CENTRAL_CLUSTER_FULL_NAME".

  • Establece el --namespace en el mismo ámbito que utilizaste para tu implementación de MongoDB de clústeres multi-Kubernetes, como por ejemplo: kubectl config --namespace "mongodb".

kubectl config set-context $(kubectl config current-context) --namespace=<metadata.namespace>
2

Copia el recurso de set de réplicas de muestra.

Cambia los ajustes de este archivo YAML para que coincidan con la configuración de set de réplicas deseada.

1---
2apiVersion: mongodb.com/v1
3kind: MongoDB
4metadata:
5  name: <my-replica-set>
6spec:
7  members: 3
8  version: "8.0.0"
9  opsManager:
10    configMapRef:
11           # Must match metadata.name in ConfigMap file
12      name: <configMap.metadata.name>
13  credentials: <mycredentials>
14  type: ReplicaSet
15  persistent: true
16...
3

Pega el ejemplo copiado para crear un nuevo set de réplicas recurso.

Abre tu editor de texto preferido y pega la especificación del objeto en un nuevo archivo de texto.

4

Cambia la configuración a tus valores preferidos.

Clave
Tipo
Descripción
Ejemplo

metadata.name

string

Etiqueta para este set de réplicas de Kubernetes objeto.

Los nombres de recursos deben tener 44 caracteres o menos.

Para aprender más, consulta metadata.name y la documentación de Kubernetes sobre nombres.

myproject

spec.members

entero

Número de nodos del set de réplicas.

3

spec.version

string

Versión de MongoDB que este set de réplicas debería ejecutar.

El formato debe ser X.Y.Z para la Community Edition y X.Y.Z-ent para la edición Enterprise.

IMPORTANTE: Asegúrate de elegir una versión compatible del servidor MongoDB. Las versiones compatibles varían según la imagen base que utiliza el recurso de la base de datos MongoDB.

Para obtener más información sobre el versionado de MongoDB, consulta versionado de MongoDB en el manual de MongoDB.

8.0.0

spec
.opsManager
.configMapRef
.name

string

Nombre del ConfigMap con la configuración de conexión de Ops Manager. La spec.cloudManager.configMapRef.name configuración es un alias para esta configuración y puede usarse en su lugar.

Este valor debe existir en el mismo espacio de nombres que el recurso que quieres crear.

IMPORTANTE: El operador de Kubernetes rastrea cualquier cambio en el ConfigMap y reconcilia el estado del recurso MongoDB.

<myconfigmap>

spec.credentials

string

Nombre del secreto que creaste como Ops Manager API credenciales de autenticación para que el operador de Kubernetes pueda comunicarse con Ops Manager.

El objeto Ops Manager Kubernetes Secret que contiene las credenciales debe existir en el mismo espacio de nombres que el recurso que desea crear.

IMPORTANTE: El operador de Kubernetes rastrea cualquier cambio realizado en el Secreto y reconcilia el estado del recurso MongoDB.

<mycredentials>

spec.type

string

Tipo de recurso MongoDB que se va a crear.

ReplicaSet

spec.persistent

string

Opcional.

Indicador que especifica si este MongoDB recurso debe usar volúmenes persistentes para el almacenamiento. Los volúmenes persistentes no se eliminan cuando el MongoDB recurso se detiene o se reinicia.

Si este valor es true, entonces spec.podSpec.persistence.single se establece en su valor por defecto de 16Gi.

Para cambiar la configuración de tu claim de volumen persistente, configura las siguientes colecciones para cumplir con los requisitos de tu implementación:

ADVERTENCIA: Otorgue a sus contenedores permiso para escribir en su Volumen Persistente. El Operador de Kubernetes fsGroup = 2000 runAsUser = 2000establece, y runAsNonRoot = true en. El securityContext Operador de Kubernetes establece fsgroup igual a runAsUser para que el volumen sea escribible para un usuario que ejecuta el proceso principal en el contenedor. Para obtener más información, consulte Configurar un Contexto de Seguridad para un Pod o Contenedor y la discusión relacionada en la documentación de Kubernetes. Si la redistribución del recurso no soluciona los problemas con su Volumen Persistente, comuníquese con el Soporte de MongoDB.

Si no utiliza volúmenes persistentes, los gráficos Disk Usage y Disk IOPS no se pueden mostrar ni en Processes la pestaña de la Deployment página ni en la Metrics página al revisar los datos de esta implementación.

true

5

Agrega cualquier configuración adicional aceptada para un set de réplicas implementación.

También puede añadir cualquiera de los siguientes ajustes opcionales al archivo de especificaciones del objeto para el set de réplicas implementación:

Advertencia

Debe configurar si su clúster spec.clusterDomain de Kubernetes tiene un dominio predeterminado distinto del cluster.local predeterminado. Si no utiliza el dominio predeterminado ni configura la spec.clusterDomain opción, es posible que el operador de Kubernetes no funcione como se espera.

6

Guarda este archivo de configuración del conjunto de réplicas con la extensión .yaml.

7

Inicie su set de réplicas.

En cualquier directorio, ejecuta el siguiente comando de Kubernetes para crear tu set de réplicas:

kubectl apply -f <replica-set-conf>.yaml
8

Rastree el estado de la implementación de su set de réplicas.

Para verificar el estado de su MongoDB recurso, utilice el siguiente comando:

kubectl get mdb <resource-name> -o yaml -w

Con la bandera -w (observar) activada, cuando la configuración cambia, la salida se actualiza inmediatamente hasta que la fase de estado alcanza el estado Running. Para obtener más información sobre el estado de implementación de recursos, consulta Solucionar problemas con el operador de Kubernetes.

Volver
Instancia autónoma
Next
Clúster fragmentado
Califique esta página

En esta página