Docs Menu
Docs Home
/ /
Implementar
Docs Home
/ /
Implementar recursos de la base de datos
/
Implementar
Docs Home
/
Gestión
/
Operador de Kubernetes (obsoleto)
/
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

  • Puede utilizar el operador de Kubernetes para implementar recursos de MongoDB con Cloud Manager y con Ops Manager versión 6.0.x o posterior.

  • Puede utilizar el operador Atlas para implementar recursos de MongoDB en Atlas.

Advertencia

El operador de Kubernetes no admite nodos árbitros.

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

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

Utilice este procedimiento para implementar un nuevo conjunto de réplicas administrado por Ops Manager. Tras la implementación, utilice Ops Manager para administrar el conjunto de réplicas, incluyendo operaciones como agregar, eliminar y reconfigurar miembros.

Considerations

Cuando implementa su conjunto de réplicas a través del operador de Kubernetes, debe elegir si desea cifrar las conexiones mediante Certificados TLS.

El siguiente procedimiento para TLS-Encrypted conexiones:

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

  • Establece conexiones cifradas con TLSentre las aplicaciones cliente y las 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 MongoDB en el conjunto 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 con TLS.

Nota

No es posible proteger una instancia independiente de MongoDB en un clúster de Kubernetes.

Para configurar el cifrado TLS para un clúster fragmentado, consulte Implementar un clúster fragmentado.

Seleccione la pestaña adecuada dependiendo de si desea cifrar las conexiones de su set de réplicas con TLS.

Requisitos previos

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

Nota

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

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

    • Tu set de réplicas. Asegúrate de añadir SANs para cada pod de Kubernetes que hostee un nodo de tu set de réplicas al certificado.

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

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

      Importante

      Si está utilizando 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 SANen el certificado.

      Para usar un certificado basado en ACME, debe configurarlo para el recurso del conjunto de réplicas. Para obtener más información, consulte el paso sobre certificados TLS basados ​​en ACME en el procedimiento.

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

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

      • La organización y la unidad organizativa combinadas en cada certificado TLS difieren de la organización y la unidad organizativa en el certificado TLS de los miembros de su conjunto de réplicas.

  • Debe tener el archivo de certificado CA y ca-pem nombrarlo.

  • Debe tener la clave que utilizó para firmar sus certificados TLS.

Importante

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

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

Nota

Para evitar almacenar secretos en implementaciones de Kubernetes de un solo clúster, puede migrar todos los secretos a una herramienta de almacenamiento de secretos. Las implementaciones en varios 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

Configure para kubectl que el valor predeterminado sea su espacio de nombres.

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

Nota

Si está implementando un recurso de Ops Manager en una implementación de MongoDB de un clúster de Kubernetes múltiple:

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

  • Establezca --namespace en el mismo ámbito que utilizó para su implementación de MongoDB en un clúster de Kubernetes múltiple, como porkubectl config --namespace "mongodb" ejemplo:.

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

Cree el secreto para el certificado TLS de su conjunto de réplicas.

Ejecute este kubectl comando para crear un nuevo secreto que almacene el certificado del conjunto de réplicas:

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

Nota

Debes anteponer a tus secretos el prefijo <prefix>-<metadata.name>.

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

Si utilizas HashiCorp Vault como tu herramienta de almacenamiento secreto, puedes crear un secreto de Vault en su lugar.

Para conocer más sobre sus opciones de almacenamiento secreto,consulte Configurar almacenamiento secreto.

3

Crea el secreto para el certificado TLS de tu agente.

Ejecute este kubectl comando 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 utilizas HashiCorp Vault como tu herramienta de almacenamiento secreto, puedes crear un secreto de Vault en su lugar.

4

Cree el ConfigMap para vincular su CA con su implementación.

Ejecute este kubectl comando para vincular su CA a su conjunto de réplicas y especificar el archivo de certificado de CA.

Importante

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

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

Copie el recurso del conjunto de réplicas de muestra.

Cambie la configuración de este archivo YAML para que coincida con la configuración del conjunto 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

Pegue el ejemplo copiado para crear un nuevo recurso de conjunto de réplicas.

Abra su editor de texto preferido y pegue la especificación del objeto en un nuevo archivo de texto.

7

Cambie la configuración a sus valores preferidos.

Clave
Tipo
Descripción
Ejemplo

metadata.name

string

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

Los nombres de recursos deben tener 44 caracteres o menos.

Para obtener más información, consulte y la documentación de Kubernetes metadata.name sobre nombres.

myproject

spec.members

entero

Número de miembros del conjunto de réplicas.

3

spec.version

string

Versión de MongoDB que este conjunto de réplicas debe ejecutar.

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

IMPORTANTE: Asegúrese de elegir una versión compatible de MongoDB Server. Las versiones compatibles varían según la imagen base que utilice el recurso de 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. El parámetro es un alias de este parámetro y puede utilizarse en su spec.cloudManager.configMapRef.name 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 creó como credenciales de autenticación de API de Ops Manager para que el operador de Kubernetes se comunique con Ops Manager.

El objeto secreto de Kubernetes de Ops Manager 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 a crear.

ReplicaSet

spec.persistent

string

Opcional.

Indicador que indica si este MongoDB recurso debe usar volúmenes persistentes para el almacenamiento. Los volúmenes persistentes no se eliminan al MongoDB detener o reiniciar el recurso.

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

Para cambiar la configuración de sus reclamaciones de volumen persistente, configure las siguientes colecciones para cumplir con sus requisitos de implementación:

ADVERTENCIA: Otorgue a sus contenedores permiso para escribir en su volumen persistente. El operador de Kubernetes fsGroup = 2000 establece, runAsUser = 2000 y runAsNonRoot = true en. El securityContext operador de Kubernetes establece fsgroup igual a runAsUser para que el volumen pueda ser escrito por 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 información relacionada en la documentación de Kubernetes. Si volver a implementar el recurso no soluciona los problemas con su volumen persistente, póngase en contacto con el soporte técnico de MongoDB.

Si no utiliza volúmenes persistentes, los gráficos Disk Usage y Disk IOPS no se podrán 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

Configure los ajustes de TLS para su recurso de conjunto de réplicas utilizando una autoridad de certificación (CA) personalizada.

Para habilitar TLS en su implementación, configure las siguientes opciones en su objeto de Kubernetes:

Clave
Tipo
Necesidad
Descripción
Ejemplo
spec.security
.tls.ca

string

Requerido

Agregue el nombre de ConfigMap que almacena la CA personalizada que utilizó para firmar los certificados TLS de su implementación.

<custom-ca>

spec.security
.certsSecretPrefix

string

Requerido

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

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

devDb

9

Opcional: configure certificados TLS basados en ACME para su recurso de conjunto de réplicas.

Si está utilizando 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 las SANen el certificado.

Para configurar un certificado que no contenga los FQDNdel pod:

  1. Emita el certificado para un dominio externo. Para más información, consulte la documentación de Let's Encrypt o la 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 utilizar un certificado que contenga solo dominios externos para la implementación de su conjunto de réplicas, debe cambiar el nombre de host predeterminado utilizado por el conjunto 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 con la spec.clusterDomain configuración.

    • De lo contrario, cree su implementación de MongoDB con las siguientes configuraciones configuradas en su objeto de Kubernetes:

Clave
Tipo
Necesidad
Descripción
spec.externalAccess
.externalDomain

string

Requerido

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

De forma predeterminada, cada miembro del conjunto de réplicas usa el FQDN del pod de Kubernetes*.svc.cluster.local () como nombre de host predeterminado. Sin embargo, si se agrega un dominio externo a esta configuración, el conjunto de réplicas usa un nombre de host que es un subdominio del dominio especificado. Este nombre de host tiene 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 usa el nombre de host con el dominio externo para anular el processes[n].hostname campo en la configuración de automatización de Ops Manager. A continuación, el agente de MongoDB usa este nombre de host para conectarse mongod a.

Para especificar otros nombres de host para conectarse al conjunto de réplicas, puede usar la configuración. Sin embargo, las siguientes conexiones aún usan el nombre de host con el dominio spec.connectivity.replicaSetHorizons externo:

  • El agente de MongoDB se conecta a mongod.

  • mongod para conectarse a otras mongod instancias.

ADVERTENCIA: Al especificar este campo, se modifica la forma en que Ops Manager registra mongod los procesos. Solo se puede especificar este campo para nuevas implementaciones de conjuntos de réplicas a partir de la versión del operador de Kubernetes.1.19 No se puede cambiar el valor de este campo ni de ningún processes[n].hostname campo en la configuración de automatización de Ops Manager para una implementación de conjuntos de réplicas en ejecución.

spec.externalAccess
.externalService.spec

Colección

Opcional

Configuración para ServiceSpec.

Al configurar el parámetro, el operador de Kubernetes crea automáticamente spec.externalAccess un servicio de balanceador de carga externo con valores predeterminados. Puede anular ciertos valores o añadir nuevos según sus necesidades. Por ejemplo, si desea crear servicios NodePort y no necesita un balanceador de carga, 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 de Kubernetes, consulte ServiceSpec en la documentación de Kubernetes.

spec.externalAccess
.externalService.annotations

Colección

Opcional

Pares clave-valor que permiten agregar opciones de configuración específicas del proveedor de nube a todos los clústeres de la implementación. Para obtener más información,consulte las 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,spec.externalAccess.externalService.annotations consulta.

10

Agregue cualquier configuración adicional aceptada para una implementación de un conjunto de réplicas.

También puede agregar cualquiera de las siguientes configuraciones opcionales al archivo de especificación de objeto para una implementación de un conjunto de réplicas:

Advertencia

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

11

Guarde este archivo de configuración del conjunto de réplicas con una .yaml extensión.

12

Inicie la implementación de su conjunto de réplicas.

En cualquier directorio, invoque el siguiente comando de Kubernetes para crear su conjunto de réplicas:

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

Realice un seguimiento del estado de la implementación de su conjunto de réplicas.

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

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

Con el -w indicador (observación) activado, cuando la configuración cambia, la salida se actualiza inmediatamente hasta que la fase de estado alcanza el Running estado. Para obtener más información sobre los estados de implementación de recursos, consulte Solucionar problemas del operador de Kubernetes.

Después de cifrar su recurso de base de datos con TLS, puede proteger lo siguiente:

Renovar certificados TLS para un conjunto de réplicas

Renueve sus certificados TLS periódicamente mediante el siguiente procedimiento:

1

Configure para kubectl que el valor predeterminado sea su espacio de nombres.

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

Nota

Si está implementando un recurso de Ops Manager en una implementación de MongoDB de un clúster de Kubernetes múltiple:

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

  • Establezca --namespace en el mismo ámbito que utilizó para su implementación de MongoDB en un clúster de Kubernetes múltiple, como porkubectl config --namespace "mongodb" ejemplo:.

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

Renueva el secreto para tus certificados TLS.

Ejecute este kubectl comando para renovar un secreto existente que almacena los certificados del conjunto 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

Configure para kubectl que el valor predeterminado sea su espacio de nombres.

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

Nota

Si está implementando un recurso de Ops Manager en una implementación de MongoDB de un clúster de Kubernetes múltiple:

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

  • Establezca --namespace en el mismo ámbito que utilizó para su implementación de MongoDB en un clúster de Kubernetes múltiple, como porkubectl config --namespace "mongodb" ejemplo:.

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

Copie el recurso del conjunto de réplicas de muestra.

Cambie la configuración de este archivo YAML para que coincida con la configuración del conjunto 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

Pegue el ejemplo copiado para crear un nuevo recurso de conjunto de réplicas.

Abra su editor de texto preferido y pegue la especificación del objeto en un nuevo archivo de texto.

4

Cambie la configuración a sus valores preferidos.

Clave
Tipo
Descripción
Ejemplo

metadata.name

string

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

Los nombres de recursos deben tener 44 caracteres o menos.

Para obtener más información, consulte y la documentación de Kubernetes metadata.name sobre nombres.

myproject

spec.members

entero

Número de miembros del conjunto de réplicas.

3

spec.version

string

Versión de MongoDB que este conjunto de réplicas debe ejecutar.

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

IMPORTANTE: Asegúrese de elegir una versión compatible de MongoDB Server. Las versiones compatibles varían según la imagen base que utilice el recurso de 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. El parámetro es un alias de este parámetro y puede utilizarse en su spec.cloudManager.configMapRef.name 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 creó como credenciales de autenticación de API de Ops Manager para que el operador de Kubernetes se comunique con Ops Manager.

El objeto secreto de Kubernetes de Ops Manager 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 a crear.

ReplicaSet

spec.persistent

string

Opcional.

Indicador que indica si este MongoDB recurso debe usar volúmenes persistentes para el almacenamiento. Los volúmenes persistentes no se eliminan al MongoDB detener o reiniciar el recurso.

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

Para cambiar la configuración de sus reclamaciones de volumen persistente, configure las siguientes colecciones para cumplir con sus requisitos de implementación:

ADVERTENCIA: Otorgue a sus contenedores permiso para escribir en su volumen persistente. El operador de Kubernetes fsGroup = 2000 establece, runAsUser = 2000 y runAsNonRoot = true en. El securityContext operador de Kubernetes establece fsgroup igual a runAsUser para que el volumen pueda ser escrito por 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 información relacionada en la documentación de Kubernetes. Si volver a implementar el recurso no soluciona los problemas con su volumen persistente, póngase en contacto con el soporte técnico de MongoDB.

Si no utiliza volúmenes persistentes, los gráficos Disk Usage y Disk IOPS no se podrán 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

Agregue cualquier configuración adicional aceptada para una implementación de un conjunto de réplicas.

También puede agregar cualquiera de las siguientes configuraciones opcionales al archivo de especificación de objeto para una implementación de un conjunto de réplicas:

Advertencia

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

6

Guarde este archivo de configuración del conjunto de réplicas con una .yaml extensión.

7

Inicie la implementación de su conjunto de réplicas.

En cualquier directorio, invoque el siguiente comando de Kubernetes para crear su conjunto de réplicas:

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

Realice un seguimiento del estado de la implementación de su conjunto de réplicas.

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

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

Con el -w indicador (observación) activado, cuando la configuración cambia, la salida se actualiza inmediatamente hasta que la fase de estado alcanza el Running estado. Para obtener más información sobre los estados de implementación de recursos, consulte Solucionar problemas del operador de Kubernetes.

Volver

Instancia independiente

Next

Clúster fragmentado

En esta página