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.

Implementar un recurso de Ops Manager

Puede implementar Ops Manager como un recurso en un contenedor de Kubernetes utilizando el Operador de Kubernetes.

Considerations

Se aplican las siguientes consideraciones:

Cifrado de conexiones

Cuando configura su implementación de Ops Manager, debe elegir si ejecutar las conexiones a través de HTTPS o HTTP.

El siguiente HTTPS procedimiento:

  • Establece conexiones cifradas con TLShacia/desde la aplicación Ops Manager.

  • Establece conexiones cifradas TLSentre los miembros del set de réplicas de la base de datos de la aplicación.

  • Requiere certificados válidos para el cifrado TLS.

El siguiente procedimiento HTTP:

  • No encripta las conexiones a o desde la aplicación Ops Manager.

  • No cifra las conexiones entre los miembros del set de réplicas de la base de datos de la aplicación.

  • Tiene menos requisitos para configurar.

Cuando se ejecuta sobre HTTPS, Ops Manager se ejecuta en el puerto 8443 por defecto.

Seleccione la pestaña adecuada según si desea cifrar sus conexiones de Ops Manager y la base de datos de la aplicación con TLS.

Requisitos previos

  • Completa los requisitos previos.

  • Lee las Consideraciones.

  • Crear un certificado TLS para el set de réplicasde la base de datos de la aplicación.

    Este certificado TLS requiere los siguientes atributos:

    Nombres DNS

    Asegúrate de añadir SANs o Nombres de sujeto para cada Pod que hostee un nodo del conjunto de réplicas de la base de datos de la aplicación. El SAN para cada pod debe usar el siguiente formato:

    <opsmgr-metadata.name>-db-<index>.<opsmgr-metadata.name>-db-svc.<namespace>.svc.cluster.local

    Usos clave

    Asegúrese de que los certificados TLS incluyan los siguientes usos de clave (5280):

    • "autenticación del servidor"

    • "autenticación de cliente"

Importante

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

Procedimiento

Este procedimiento se aplica a implementar una instancia de Ops Manager en un solo clúster de Kubernetes y a implementar Ops Manager en un clúster central en una implementación de varios clústeres. Si desea implementar varias instancias de Ops Manager en varios clústeres de Kubernetes, consulte Implementar recursos de Ops Manager en varios clústeres de Kubernetes.

Siga estos pasos para implementar el recurso Ops Manager para ejecutarse sobre HTTPS y asegurar la base de datos de la aplicación utilizando TLS.

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:

  • Establezca el context en el nombre del clúster central, como: 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 secretos para tus certificados.

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

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

  1. Una vez que tengas tus certificados TLS y tus claves privadas, ejecuta el siguiente comando para crear un secreto que almacene el certificado TLS de Ops Manager:

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

  2. Ejecuta el siguiente comando para crear un nuevo secreto que almacene el TLS certificado de la base de datos de la aplicación:

    kubectl create secret tls <prefix>-<metadata.name>-db-cert \  --cert=<appdb-tls-cert> \  --key=<appdb-tls-key>
3

Agregue certificados adicionales a los certificados personalizados de CA.

Si el certificado TLS de tu Ops Manager está firmado por una CA personalizada, el certificado CA también debe contener certificados adicionales que permitan que el Ops Manager daemon de copias de seguridad descargue binarios de MongoDB desde Internet. Para crear el (los) certificado(s) TLS, cree un ConfigMap para contener el certificado CA:

Importante

El Operador de Kubernetes exige que el certificado de su Ops Manager se llame mms-ca.crt en el ConfigMap.

  1. Obtenga toda la cadena de certificados TLS para MongoDB Ops Manager de downloads.mongodb.com. El siguiente comando openssl exporta el certificado de la cadena a su directorio de trabajo actual, en formato .crt:

    openssl s_client -showcerts -verify 2 \-connect downloads.mongodb.com:443 -servername downloads.mongodb.com < /dev/null \| awk '/BEGIN/,/END/{ if(/BEGIN/){a++}; out="cert"a".crt"; print >out}'

  2. Concatene el archivo de certificado de su CA para MongoDB Ops Manager con toda la cadena de certificados TLS de downloads.mongodb.com que obtuvo en el paso anterior:

    cat <custom_ca_cert.pem> cert2.crt cert3.crt cert4.crt  >> mms-ca.crt

    Nota

    • Reemplace el marcador de posición <custom_ca_cert.pem> con su archivo PEM de certificado CA personalizado.

    • No incluyas tu archivo cert1.crt, ya que es tu certificado de servidor de MongoDB que no deberías incluir.

  3. Cree el ConfigMap para el Ops Manager:

    kubectl create configmap om-http-cert-ca --from-file="mms-ca.crt"
4

Copia uno de los siguientes ejemplos de objetos de Kubernetes de Ops Manager objeto.

Cambia la configuración para que coincida con la configuración de tu Ops Manager y la base de datos de la aplicación.

Clúster único de Kubernetes:

---apiVersion: mongodb.com/v1kind: MongoDBOpsManagermetadata:  name: <myopsmanager>spec:  replicas: 1  version: <opsmanagerversion>  adminCredentials: <adminusercredentials> # Should match metadata.name                                           # in the Kubernetes secret                                           # for the admin user
  externalConnectivity:    type: LoadBalancer  security:      certsSecretPrefix: <prefix> # Required. Text to prefix                                   # the name of the secret that contains                                  # Ops Manager's TLS certificate.      tls:        ca: "om-http-cert-ca"  # Optional. Name of the ConfigMap file                               # containing the certificate authority that                               # signs the certificates used by the Ops                               # Manager custom resource.
  applicationDatabase:    topology: SingleCluster    members: 3    version: "8.0.0-ubi8"    security:      certsSecretPrefix: <prefix> # Required. Text to prefix to the                                   # name of the secret that contains the Application                                  # Database's TLS certificate. Name the secret                                   # <prefix>-<metadata.name>-db-cert.      tls:        ca: "appdb-ca" # Optional, unless enabling TLS for |mms|.                        # Name of the ConfigMap file                       # containing the certicate authority that                       # signs the certificates used by the                       # application database.
...

Multi-Kubernetes Cluster:

---apiVersion: mongodb.com/v1kind: MongoDBOpsManagermetadata:  name: <myopsmanager>spec:  replicas: 1  version: <opsmanagerversion>  adminCredentials: <adminusercredentials> # Should match metadata.name                                           # in the Kubernetes secret                                           # for the admin user
  externalConnectivity:    type: LoadBalancer  security:      certsSecretPrefix: <prefix> # Required. Text to prefix                                   # the name of the secret that contains                                  # Ops Manager's TLS certificate.      tls:        ca: "om-http-cert-ca"  # Optional. Name of the ConfigMap file                               # containing the certificate authority that                               # signs the certificates used by the Ops                               # Manager custom resource.
  applicationDatabase:    topology: MultiCluster    clusterSpecList:    - clusterName: cluster1.example.com      members: 4    - clusterName: cluster2.example.com      members: 3    - clusterName: cluster3.example.com      members: 2    version: "8.0.0-ubi8"    security:      certsSecretPrefix: <prefix> # Required. Text to prefix to the                                   # name of the secret that contains the Application                                  # Database's TLS certificate. Name the secret                                   # <prefix>-<metadata.name>-db-cert.      tls:        ca: "appdb-ca" # Optional, unless enabling TLS for |mms|.                        # Name of the ConfigMap file                       # containing the certicate authority that                       # signs the certificates used by the                       # application database.
...
5

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

6

Configura los ajustes específicos para tu implementación.

Clave
Tipo
Descripción
Ejemplo

string

Nombre para este Ops Manager de Kubernetes objeto.

Los nombres de recursos deben tener 44 caracteres o menos.

Consulta también metadata.name y la documentación de Kubernetes sobre nombres.

om

Número

Cantidad de instancias de Ops Manager para ejecutar en paralelo.

El valor mínimo válido es 1. Este campo se ignora si especificas MultiCluster en la configuración de spec.topology.

1

string

Versión de Ops Manager que se instalará.

El formato debe ser X.Y.Z. Para ver las versiones disponibles de Ops Manager, consulta el registro de contenedores.

8.0.0

string

Nombre del secreto que creaste para el usuario admin de Ops Manager. Configure el secreto para usar el mismo namespace que el recurso del Ops Manager.

om-admin-secret

spec
.security
.certsSecretPrefix

string

Requerido.

Texto para anteponer al nombre del secreto que contiene los certificados TLS de los gestores de operaciones.

om-prod

spec
.security
.tls
.ca

string

Nombre del ConfigMap que creó para verificar los certificados TLS de Ops Manager TLS firmados con una CA personalizada. Este campo es obligatorio si ha firmado los certificados de TLS de su Ops Manager usando un CA personalizado.

om-http-cert-ca

spec
.externalConnectivity
.type

string

El servicio de Kubernetes ServiceType que expone Ops Manager fuera de Kubernetes. Excluye la configuración spec.externalConnectivity y sus anexos si no quieres que el operador de Kubernetes cree un servicio de Kubernetes para enrutar el tráfico externo a la aplicación Ops Manager.

LoadBalancer

spec
.applicationDatabase
.members

entero

Número de nodos del set de réplicas de la base de datos de la aplicación Ops Manager.

3

spec
.applicationDatabase
.version

string

Requerido.

Versión de MongoDB en la que debe ejecutarse la base de datos de la aplicación Ops Manager.

El formato debe ser X.Y.Z-ubi8 para la edición Enterprise y X.Y.Z para la Community edition. No añadas el sufijo de etiqueta -ubi8 a la imagen de la Community Edition porque el operador de Kubernetes añadirá automáticamente el sufijo de etiqueta.

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.

Para obtener los mejores resultados, utilice la última versión disponible de MongoDB Enterprise que sea compatible con su versión de Ops Manager.

spec
.applicationDatabase
.topology

string

Opcional.

El tipo de implementación de Kubernetes para la Base de Datos de la Aplicación. Si se omite, el valor por defecto es SingleCluster.

Si especifica MultiCluster, el operador de Kubernetes ignora los valores que configure para el campo spec.applicationDatabase.members, si se especifica. En su lugar, debe especificar el clusterSpecList e incluir en él el clusterName de cada Kubernetes clúster nodo seleccionado en el que desea implementar la base de datos de la aplicación, y el número de members (nodos de MongoDB) en cada clúster de Kubernetes.

No puedes convertir una instancia de MongoDB de instancia de un solo clúster de Ops Manager en una instancia de implementación de MongoDB de varios clústeres de Kubernetes modificando la topology y la clusterSpecList configuraciones en el CRD.

Consultar también el ejemplo de la especificación de recursos.

MultiCluster

spec
.applicationDatabase
.security
.certsSecretPrefix

string

Requerido.

Texto para anteponer al nombre del secreto que contiene los certificados TLS de la base de datos de la aplicación.

appdb-prod

spec
.applicationDatabase
.security
.tls
.ca

string

Nombre del ConfigMap que creaste para verificar los certificados TLS de la base de datos de la aplicación firmados usando un CA personalizado. Este campo es obligatorio si firmaste tus certificados TLS de la base de datos de la aplicación utilizando una CA personalizada.

ca

El operador de Kubernetes monta el CA que agrega mediante la configuración spec.applicationDatabase.security.tls.ca tanto en los pods de MongoDB Ops Manager como en los de la base de datos de la aplicación.

7

Opcional: configura la configuración de copia de seguridad.

Para configurar la copia de seguridad, debe habilitarla y luego:

Clave
Tipo
Descripción
Ejemplo

spec
.backup
.enabled

booleano

Indicador que muestra que la copia de seguridad está activada. Debe especificar spec.backup.enabled: true para configurar los ajustes de la base de datos principal, el almacenamiento de oplog y el almacenamiento de snapshot.

true

spec
.backup
.headDB

Colección

Una colección de configuraciones para la base de datos principal. Para obtener descripciones de la configuración individual en la colección, consulta spec.backup.headDB.

spec
.backup
.opLogStores
.name

string

Nombre del almacén de oplog.

oplog1

spec
.backup
.s3OpLogStores
.name

string

Nombre del S3 almacenar de oplog.

my-s3-oplog-store

spec
.backup
.opLogStores
.mongodbResourceRef
.name

string

Nombre del recurso MongoDB o del recurso MongoDBMultiCluster para el almacén oplog. El metadata.name del recurso debe coincidir con este nombre.

my-oplog-db

spec
.backup
.s3OpLogStores
.mongodbResourceRef
.name

string

Nombre del recurso MongoDB o del recurso MongoDBMultiCluster para el almacenar oplog S3. El metadata.name del recurso debe coincidir con este nombre.

my-s3-oplog-db

También debe configurar un almacenamiento de snapshot S3 o un almacenamiento en bloques.

Si despliegas tanto un almacenamiento de snapshot S3 como un almacenamiento en bloques, Ops Manager elegirá uno al azar para usarlo como copia de seguridad.

Para configurar un almacenamiento de snapshot, configura las siguientes opciones:

Clave
Tipo
Descripción
Ejemplo

spec
.backup
.s3Stores
.name

string

Nombre del S3 almacenamiento de snapshot.

s3store1

spec
.backup
.s3Stores
.s3SecretRef
.name

string

Nombre del secreto que contiene los campos accessKey y secretKey. El daemon de copias de seguridad Service utiliza los valores de estos campos como credenciales para acceder al cubo S3 o S3compatible.

my-s3-credentials

spec
.backup
.s3Stores
.s3BucketEndpoint

string

URL del bucket S3 o S3-compatible que almacena las instantáneas de copia de seguridad de la base de datos.

s3.us-east-1.amazonaws.com

spec
.backup
.s3Stores
.s3BucketName

string

Nombre del bucket S3 o S3-compatible que almacena las snapshot de copia de seguridad de la base de datos.

my-bucket

Para configurar un almacenamiento en bloques, configure los siguientes ajustes:

Clave
Tipo
Descripción
Ejemplo

spec
.backup
.blockStores
.name

string

Nombre del almacenamiento en bloques.

blockStore1

spec
.backup
.blockStores
.mongodbResourceRef
.name

string

Nombre del recurso de MongoDB que creas para el almacenamiento en bloques. Debe implementar este recurso de base de datos en el mismo namespace que el recurso de Ops Manager.

my-mongodb-blockstore

8

Opcional: configure cualquier ajuste adicional para una copia de seguridad de Ops Manager.

Agrega cualquier configuración opcional para copias de seguridad que quieras aplicar a tu implementación en el archivo de especificaciones de objeto. Por ejemplo, para cada tipo de almacén de copias de seguridad y para los procesos de daemon de copias de seguridad de Ops Manager, puedes asignar etiquetas para asociar almacenes de copias de seguridad concretos o procesos de daemon de copias de seguridad con Proyectos específicos. Utilice spec.backup.[*].assignmentLabels elementos de los recursos de OpsManager.

9

Opcional: Configure cualquier ajuste adicional para una implementación de Ops Manager.

Agrega cualquier configuración opcional que desees aplicar a tu implementación en el Archivo de Especificación de objetos.

10

Guarde este archivo con una extensión de archivo .yaml.

11

Crea tu instancia de Ops Manager.

Ejecute el siguiente comando kubectl en el nombre de archivo de la definición de recurso de Ops Manager:

kubectl apply -f <opsmgr-resource>.yaml

Nota

Si va a desplegar un recurso Ops Manager en una implementación de MongoDB en varios clústeres de Kubernetes, ejecute:

kubectl apply \  --context "$MDB_CENTRAL_CLUSTER_FULL_NAME" \  --namespace "mongodb"   -f https://raw.githubusercontent.com/mongodb/mongodb-kubernetes/1.4.0/public/samples/ops-manager/ops-manager-external.yaml
12

Rastree el estado de su instancia de Ops Manager.

Para comprobar el estado de tu recurso Ops Manager, ejecuta el siguiente comando:

kubectl get om -o yaml -w

El comando devuelve una salida similar a la siguiente en el campo status mientras se implementa el recurso:

status: applicationDatabase:  lastTransition: "2022-04-01T09:49:22Z"  message: AppDB Statefulset is not ready yet  phase: Pending  type: ""  version: "" backup:  phase: "" opsManager:  phase: ""

El Operador de Kubernetes concilia los recursos en el siguiente orden:

  1. base de datos de la aplicación.

  2. Ops Manager.

  3. copia de seguridad.

El operador de Kubernetes no reconcilia un recurso hasta que el anterior entre en la fase Running.

Cuando el recurso de Ops Manager completa la fase Pending, el comando devuelve una salida similar a la siguiente en el campo status si habilitaste la Copia de seguridad:

status: applicationDatabase:     lastTransition: "2022-04-01T09:50:20Z"     members: 3     phase: Running     type: ReplicaSet     version: "8.0.0-ubi8"  backup:   lastTransition: "2022-04-01T09:57:42Z"   message: The MongoDB object <namespace>/<oplogresourcename>     doesn't exist   phase: Pending   opsManager:     lastTransition: "2023-04-01T09:57:40Z"     phase: Running     replicas: 1     url: https://om-svc.cloudqa.svc.cluster.local:8443     version: "8.0.0"

La copia de seguridad permanece en un estado Pending hasta que configures las bases de datos del respaldo.

Tip

El campo status.opsManager.url indica la URL de conexión del recurso. Mediante esta URL, puedes acceder a Ops Manager desde dentro del clúster de Kubernetes o crear un proyecto utilizando un ConfigMap.

Tras completar la fase Pending del recurso, el comando devuelve una salida similar a la siguiente bajo el campo status:

status:  applicationDatabase:     lastTransition: "2022-12-06T18:23:22Z"     members: 3     phase: Running     type: ReplicaSet     version: "8.0.0-ubi8"   opsManager:     lastTransition: "2022-12-06T18:23:26Z"     message: The MongoDB object namespace/oplogdbname doesn't exist     phase: Pending     url: https://om-svc.dev.svc.cluster.local:8443     version: ""

La copia de seguridad permanece en un estado Pending hasta que configures las bases de datos del respaldo.

Tip

El campo status.opsManager.url indica la URL de conexión del recurso. Mediante esta URL, puedes acceder a Ops Manager desde dentro del clúster de Kubernetes o crear un proyecto utilizando un ConfigMap.

13

Acceder a la aplicación Ops Manager.

Los pasos que tomes varían según cómo estés dirigiendo el tráfico a la aplicación de Ops Manager en Kubernetes. Si configuraste el operador de Kubernetes para que cree un servicio de Kubernetes para ti, o creaste un servicio de Kubernetes manualmente, utiliza uno de los siguientes métodos para acceder a la aplicación Ops Manager:

Servicio de balanceo de carga:

  1. Query a su proveedor de nube para obtener el FQDN del servicio de balanceador de carga. Consulta la documentación de tu proveedor de nube para obtener detalles.

  2. Abre una ventana del navegador y navega hasta la aplicación Ops Manager usando el FQDN y el número de puerto de tu servicio de balanceador de carga.

    https://ops.example.com:8443

  3. Iniciar sesión en Ops Manager usando las credenciales de usuario administrador.

Servicio NodePort:

  1. Configura las reglas de tu cortafuegos para permitir el acceso desde Internet al spec.externalConnectivity.port en el host donde se ejecuta tu clúster de Kubernetes.

  2. Abre una ventana del navegador y navega hasta la aplicación MongoDB Ops Manager usando el FQDN y el spec.externalConnectivity.port.

    https://ops.example.com:30036

  3. Iniciar sesión en Ops Manager usando las credenciales de usuario administrador.

Para aprender a acceder a la aplicación Ops Manager mediante un servicio de terceros, consulta la documentación correspondiente a tu solución.

14

Crea credenciales para el operador de Kubernetes.

Para configurar las credenciales, debes crear una organización en Ops Manager, generar claves programáticas de API y crear un secreto. Estas actividades siguen los prerrequisitos y el procedimiento en la página Crear credenciales para el operador de Kubernetes.

15

Crea un proyecto usando un ConfigMap.

Para crear un Proyecto, sigue los requisitos previos y el procedimiento en la página Crear un Proyecto por cada implementación de MongoDB mediante un ConfigMap.

Configura los siguientes campos en tu ConfigMap del proyecto:

  • Establece data.baseUrl en el ConfigMap a la URL de la Aplicación Ops Manager. Para encontrar esta URL, se debe invocar el siguiente comando:

    kubectl get om -o yaml -w

    El comando devuelve la URL de la Aplicación de Ops Manager en el campo status.opsManager.url, similar al siguiente ejemplo:

    status:   applicationDatabase:     lastTransition: "2022-12-06T18:23:22Z"     members: 3     phase: Running     type: ReplicaSet     version: "8.0.0-ubi8"   opsManager:     lastTransition: "2022-12-06T18:23:26Z"     message: The MongoDB object namespace/oplogdbname doesn't exist     phase: Pending     url: https://om-svc.dev.svc.cluster.local:8443     version: ""

    Importante

    Si implementas Ops Manager con el operador de Kubernetes y Ops Manager va a gestionar los recursos de la base de datos MongoDB implementados fuera del clúster de Kubernetes donde se implementa, debes establecer data.baseUrl con el mismo valor de la configuración spec.configuration.mms.centralUrl en la especificación de recursos de Ops Manager.

    Para obtener más información, consulta Gestión de implementaciones externas de MongoDB.

  • Establezca data.sslMMSCAConfigMap en el nombre de su ConfigMap que contiene el certificado CA raíz utilizado para firmar el certificado del host de MongoDB Ops Manager. El operador de Kubernetes requiere que nombre el certificado mms-ca.crt de este recurso de MongoDB Ops Manager en el ConfigMap.

16

Implementa recursos de bases de datos MongoDB para completar la configuración de copia de seguridad.

De forma predeterminada, Ops Manager habilita copia de seguridad. Crea un recurso de base de datos de MongoDB para los almacenes de oplog y de almacenamientos de snapshot para completar la configuración.

  1. Despliegue un recurso de base de datos MongoDB para el almacén oplog en el mismo namespace que el recurso Ops Manager.

    Nota

    Cree esta base de datos como un conjunto de réplicasde tres nodos.

    Haz coincidir el metadata.name del recurso con el spec.backup.opLogStores.mongodbResourceRef.name que especificaste en la definición de tu recurso en el administrador de operaciones (Ops Manager).

  2. Implementar un recurso de base de datos de MongoDB para el almacenamiento de snapshot S3 en el mismo namespace que el recurso Ops Manager.

    Nota

    Cree el almacenamiento de snapshot S3 como un set de réplicas.

    Coincide el metadata.name del recurso con el spec.backup.s3Stores.mongodbResourceRef.name que especificaste en tu definición de recurso de Ops Manager.

17

Confirma que el recurso de Ops Manager esté en funcionamiento.

Para comprobar el estado de tu recurso Ops Manager, ejecuta el siguiente comando:

kubectl get om -o yaml -w

Cuando Ops Manager se está ejecutando, el comando devuelve un resultado similar al siguiente, bajo el campo status:

status:  applicationDatabase:    lastTransition: "2022-12-06T17:46:15Z"    members: 3    phase: Running    type: ReplicaSet    version: "8.0.0-ubi8"  opsManager:    lastTransition: "2022-12-06T17:46:32Z"    phase: Running    replicas: 1    url: https://om-backup-svc.dev.svc.cluster.local:8443    version: "8.0.0"

Consulte Solucionar problemas del operador de Kubernetes para obtener información sobre los estados de implementación de recursos.

Califique esta página

En esta página