Notas de la versión 1.13.1 de Google Distributed Cloud aislado

28 de junio de 2024

Google Distributed Cloud (GDC) aislado 1.13.1 está disponible.
Consulta la descripción general del producto para obtener información sobre las funciones de Distributed Cloud.

Se actualizó la versión de la imagen de SO Ubuntu de Canonical a 20240515 para aplicar los parches de seguridad y las actualizaciones importantes más recientes. Para aprovechar las correcciones de errores y vulnerabilidades de seguridad, debes actualizar todos los nodos con cada versión. Se corrigieron las siguientes vulnerabilidades de seguridad:

Se actualizó la versión de la imagen de SO Rocky a 20240506 para aplicar los parches de seguridad y las actualizaciones importantes más recientes. Se corrigieron las siguientes vulnerabilidades de seguridad:

Se corrigieron las siguientes vulnerabilidades de seguridad de la imagen del contenedor:

Se corrigió una vulnerabilidad relacionada con las bases de datos que se ejecutan como contenedores en el clúster del sistema.

Facturación:

  • Se agregó la capacidad de habilitar la facturación para socios cuando se crea una organización, lo que permite que Google le cobre directamente al socio.

Administración de clústeres:

Direccionamiento IP personalizado:

  • Se agregó la capacidad de anular la dirección IP que se asigna a las organizaciones para habilitar las funciones de interconexión de Direct Connect (DX).

Servicio de base de datos:

  • Se agregó una actualización importante para mejorar la seguridad y la confiabilidad. Todas las cargas de trabajo de la base de datos ahora se ejecutan en el clúster de servicio. Esta actualización requiere la eliminación de las bases de datos existentes. Para proteger tus datos, asegúrate de exportar y borrar todos los clústeres de bases de datos existentes antes de la actualización. Consulta la documentación del servicio de bases de datos para obtener información sobre cómo importar y exportar datos.
  • Se agregó una función para que AlloyDB admita la alta disponibilidad (HA) en la misma zona.
  • Se agregó la capacidad de AlloyDB para admitir funciones de copia de seguridad, restablecimiento y recuperación de un momento determinado.
  • Se agregó la capacidad de AlloyDB para admitir funciones avanzadas de importación, exportación y migración de datos.

Expansión dinámica:

  • Agrega recursos adicionales de procesamiento y almacenamiento con la expansión dinámica sin necesidad de completar una nueva implementación. Las versiones de GDC anteriores a la 1.13.1 solo permitían agregar hardware en una reimplementación. Este tipo de expansión se conoce como expansión estática.

Harbor-as-a-Service:

  • Se agregó Harbor-as-a-Service (HaaS), que es un servicio completamente administrado que almacena y administra imágenes de contenedor con Harbor.

Tipos de máquinas:

Marketplace:

  • Se introdujo la configuración personalizable de los servicios del mercado.
  • Starburst Enterprise (BYOL) está disponible en el mercado aislado. Starburst Enterprise proporciona un motor de SQL de MPP distribuido, rápido y escalable para tu data lakehouse con federación de consultas a muchas otras fuentes de datos.

  • Prisma Cloud Compute Edition de Palo Alto Networks (BYOL) está disponible en el mercado aislado. Prisma Cloud Compute Edition de Palo Alto Networks ofrece protecciones modernas para aplicaciones distribuidas.

Implementaciones en varias zonas:

  • Se agregó la función multizona, que proporciona capacidades de alta disponibilidad y recuperación ante desastres como servicio similares a las de la nube para simplificar la administración de recursos en las zonas de GDC. Las capacidades de implementación en varias zonas están en versión preliminar.

Infraestructura de clave pública:

  • Cuando emitas certificados web, puedes configurar diferentes modos de PKI después de crear la organización. Los modos configurables incluyen Infra PKI Fully Managed, BYO-SubCA, BYO-Cert with ACME y BYO-Cert.

Almacenamiento de objetos:

  • Se agregó un campo Spec.location de bucket para especificar la zona en la que se encuentran sus objetos. Durante la creación del bucket, si no se proporciona ningún valor, el campo se propagará automáticamente con el nombre de la zona en la que se crea el bucket. Los buckets existentes tienen su campo propagado automáticamente con el nombre de la zona en la que residen.

Máquinas virtuales (VM):

Vertex AI:

VPN:

Artifact Registry:

  • Cuando se crea el clúster de administrador raíz, la operación puede fallar si hay una lista larga de servidores durante el inicio.

Copia de seguridad y restablecimiento:

  • Se produce un error al intentar restablecer una copia de seguridad en un clúster de usuario con restricciones de cuota.

Facturación:

  • Las métricas de facturación no se emiten correctamente a Cortex debido a la falta de MetricsProxySidecar.

Almacenamiento en bloque:

  • Los pods del launcher de la máquina virtual no pueden asignar volúmenes.
  • Las fallas relacionadas con el almacenamiento pueden hacer que el sistema sea inutilizable.
  • Los volúmenes persistentes se crean con un tamaño incorrecto.
  • Cuando se desactiva una organización, es posible que haya un problema para borrar un StorageVirtualMachine.
  • Los secretos y los certificados no se limpian después de desactivar una organización.
  • Se puede producir un error de conciliación de eliminación en StorageVirtualMachine.
  • Los trabajos de Ansible se bloquean durante la actualización del metal desnudo.

Administración de clústeres:

  • El trabajo machine-init falla durante el aprovisionamiento del clúster.
  • Falla la conexión de un pod de base de datos que se ejecuta en el clúster de servicio a un bucket de almacenamiento de objetos en el clúster de administrador de la organización.
  • Falla la comprobación previa.
  • Es posible que los clústeres de usuarios, cuando se vuelven a crear, se queden atascados en el proceso de conciliación.

Servicio de base de datos:

  • En el caso de las bases de datos orientadas al usuario, el aprovisionamiento inicial, el cambio de tamaño o la habilitación de la alta disponibilidad en un clúster de base de datos existente tardan hasta 40 minutos más que antes, y el rendimiento es de dos a tres veces más lento que antes.
  • La clonación del servicio de base de datos no funciona para un clúster con una cuota de almacenamiento limitada debido a un problema con la copia de seguridad y el restablecimiento.
  • La aplicación de IOPS podría afectar el rendimiento del almacenamiento.

DNS:

  • Las DNSSEC se deben desactivar de forma explícita en resolved.conf.

Puerto:

  • Borrar instancias de Harbor no borra los duplicados de registros asociados. Es posible que el grupo de nodos esté atascado en un estado de Provisioning.

Módulo de seguridad de hardware:

  • Las licencias de prueba desactivadas aún se pueden detectar en CipherTrust Manager, lo que activa advertencias de vencimiento falsas.
  • Una pérdida de descriptor de archivos provoca un error ServicesNotStarted.

Infraestructura como código (IaC):

  • La creación excesiva de tokens de GitLab corre el riesgo de llenar las bases de datos de GitLab.

Key Management Service (KMS):

  • Cuando el uso de memoria de kms-rootkey-controller supera el límite de 600Mi, el controlador ingresa en un estado CrashLoopBackOff debido a un estado OOMKilled.

Registro:

  • El registrador de auditoría del almacenamiento de objetos no puede resolver el host DNS.

Supervisión:

  • Los paneles no muestran las métricas de Vertex AI.
  • El Pod mon-cortex tiene un error de conciliación.
  • El Pod metrics-server-exporter del clúster del sistema se encuentra en un bucle de fallas.
  • El ConfigMap mon-prober-backend-prometheus-config se restablece para no incluir trabajos de sondeo, y se activa la alerta MON-A0001.
  • Después de configurar el servicio de Monitoring para que envíe alertas, se crean automáticamente varias alertas duplicadas.
  • El objeto ObservabilityPipeline muestra registros de Reconciler error que debes ignorar.

Bootstrap multizona:

  • No hay roles específicos para el bootstrapping de implementaciones en varias zonas.
  • El recurso Bootstrap que se crea es incompatible con la lógica que lo procesa.
  • No se crea un recurso obligatorio durante el inicio, lo que provoca que los componentes que dependen de este recurso no funcionen correctamente.

Redes:

  • No se puede acceder al nodo.
  • Hay problemas de conectividad con las instancias del servicio de bases de datos.
  • No se asigna un PodCIDR a los nodos, aunque se cree un ClusterCIDRConfig.
  • Un nodo de VM tiene una hora imprecisa o desfasada.
  • Las direcciones IP de intercambio de tráfico de la sesión de interconexión de EVPN multizona que se generan son incorrectas.
  • No se puede acceder al nodo en la red de datos.

Almacenamiento de objetos:

  • Es posible que no se pueda borrar una organización.

Sistema operativo:

  • En situaciones excepcionales, los Pods se bloquean en el estado init en un nodo específico.
  • El trabajo de bm-system-machine-preflight-check Ansible para un nodo de metal desnudo o de VM falla con Either ip_tables or nf_tables kernel module must be loaded.

Infraestructura de Operations Suite (OI):

  • Para Hardware 3.0, ya no es necesario iniciar Smart Storage Administration (SSA).

Seguridad perimetral:

  • El clúster del sistema de la organización se bloquea durante el arranque de la organización.
  • El firewall de PANW AddressGroups no se actualiza con los cambios de OCITcidr-claim, lo que genera dominios iac.gdch.domain.example que no se pueden resolver.

Seguridad de la plataforma:

  • Cuando el modo de SubCA de PKI BYO genera una nueva solicitud de firma de certificado (CSR) mientras se sube un certificado firmado previamente a la SubCA, el reconciliador no verifica si la nueva CSR coincide con el certificado firmado anterior y marca el recurso personalizado (CR) cert-manager CertificateRequest como Ready. Esto ocurre durante la renovación del certificado de la SubCA o la rotación manual.
  • Un problema conocido en cert-manager provoca que no se emitan correctamente los certificados de PKI externos (BYO) con el entorno de administración de certificados automático (ACME).

Servidores físicos:

  • El servidor está atascado en el estado provisioning.
  • El inicio del servidor falla debido a problemas de POST en el servidor HPE.
  • El servidor está atascado en el estado de aprovisionamiento.

Resource Manager:

  • El estado de un proyecto no se muestra en la consola de GDC.

Actualizar:

  • Los trabajos bm-system y otros que ejecutan el playbook de Ansible están atascados en gathering facts.
  • No se puede acceder a la IP de administración de un servidor durante la actualización.
  • La actualización falla en el subcomponente iac-zoneselection-global.

Vertex AI:

  • El MonitoringTarget muestra un estado Not Ready cuando se crean clústeres de usuarios, lo que hace que las APIs previamente entrenadas muestren continuamente un estado Enabling en la interfaz de usuario.
  • El pod y el servicio de frontend de Translation no se inicializan porque la clave del clúster del sistema de ODS está desactualizada.

Máquinas virtuales:

  • La importación de imágenes de BYO falla para las imágenes qcow2 y sin procesar.
  • Falla el aprovisionamiento de un disco a partir de una imagen personalizada.
  • La actualización del almacenamiento de objetos muestra un error durante la verificación previa o posterior al vuelo.

Facturación:

  • Se solucionó un problema por el que el trabajo del generador de facturas no podía crear un recurso personalizado de factura debido al nombre no válido GDCH_INTERNAL.

Redes:

  • Se corrigió un problema por el que fallaba la actualización debido a una generación incorrecta del recurso personalizado hairpinlink.
  • En la instalación de la red, se muestran errores de pista falsa del tipo "Se produjo un error al obtener la velocidad del puerto".

Administrador de complementos:

Actualización de versión:

  • La versión de imagen basada en Debian se actualizó a bookworm-v1.0.1-gke.1.

Infraestructura de Operations Suite (OI):

  • La cuenta de OI Marvin, que se usa para la administración de la configuración en el entorno de infraestructura de OI, tiene un período de vencimiento de 60 días.