Administrar servicios de Google

Distributed Cloud conectado admite la implementación de varios servicios Google Cloud . Estas cargas de trabajo de servicio se ejecutan en contenedores de Kubernetes en tus clústeres de Distributed Cloud conectado.

Servicios admitidos Google Cloud

Distributed Cloud conectado admite la implementación de los siguientes Google Cloud servicios:

Tipo de servicio Incluido en los costos de GDC conectado Se factura por separado
Procesamiento Google Distributed Cloud solo de software
Entorno de ejecución de VM en Google Distributed Cloud		 Sistemas operativos invitados
(debes obtener tus propias licencias)
Almacenamiento Interfaz de almacenamiento de contenedores (CSI)
Almacenamiento híbrido		 Almacenamiento definido por software (SDS),
como Symcloud Storage
(debes obtener tus propias licencias)
Redes API de Edge Network
Compatibilidad con VLAN
Plug-ins de la interfaz de red personalizada (CNI) de GKE
Balanceador de cargas L4 incluido en GKE
 No aplicable
IA/AA Implementación de modelos de AutoML en contenedores No aplicable
Base de datos Ninguno AlloyDB Omni (versión preliminar)
Soluciones de bases de datos de terceros, como MongoDB
(debes obtener tus propias licencias)
Observabilidad Cloud Logging
Cloud Monitoring
API de Cloud Logging Registros y métricas de GDCc		 Prometheus para la observabilidad desconectada
Registros y métricas personalizados a nivel de la aplicación
Administración de la configuración Sincronizador de configuración
Usa paquetes de flota en Distributed Cloud conectado
Paquetes de flota (versión preliminar)		 No aplicable
Administración Panel de Google Kubernetes Engine en la Google Cloud consola
Puerta de enlace de conexión
La herramienta local kubectl
Actualizaciones de software de Distributed Cloud conectado		 No aplicable
Seguridad Integración de Cloud Key Management Service
Unidades de disco con encriptación automática (SED)
Workload Identity de la flota
Registro de auditoría 		No aplicable

Requisitos previos

Antes de que puedas implementar Google Cloud servicios en Distributed Cloud conectado, debes completar los requisitos previos que se indican en esta sección.

Obtén credenciales de clúster

Usa el siguiente comando para obtener las credenciales para acceder al clúster de destino:

 gcloud container hub memberships get-credentials CLUSTER_ID \
       --project="PROJECT_ID"

Reemplaza lo siguiente:

  • CLUSTER_ID: Es el nombre del clúster de destino.
  • PROJECT_ID: Es el ID del proyecto de destino. Google Cloud

Crea o selecciona un clúster

Si aún no lo hiciste, crea un clúster de Distributed Cloud conectado como se describe en Crea un clúster. Cuando crees el clúster, especifica al menos 8 direcciones IP virtuales (VIP). Los contenedores de Kubernetes que ejecutan tus cargas de trabajo deservicio usarán estas VIP Google Cloud .

Si usas un clúster existente, usa el siguiente comando para verificar que haya suficientes VIP disponibles en ese clúster:

 kubectl get cluster --all-namespaces -o jsonpath="{.items[0].spec.loadBalancer.addressPools}"

El comando muestra un resultado similar al siguiente:

[
  {
    "addresses": [
      "10.200.11.188-10.200.11.196"
    ],
    "name": "loadBalancerAddressPool-1"
  }
]

Si no hay suficientes VIP aprovisionadas en el clúster, aparece el siguiente error, en el que n es la cantidad requerida de VIP y m es la cantidad de VIP descubiertas en el clúster:

Cluster has less than n external IPs, got m.

Si recibes este error, debes borrar y volver a crear el clúster con una cantidad suficiente de VIP.

Configura el subdominio de Google Cloud servicio

Antes de implementar el primer Google Cloud servicio en una zona de Distributed Cloud conectado, tienes la opción de personalizar el subdominio en el que todos los Google Cloud servicios implementados en esa zona escucharán las conexiones. No puedes modificar este subdominio después de implementar al menos un servicio en esa zona de Distributed Cloud.

Usa el siguiente comando para ver la configuración del subdominio:

kubectl -n dns-system get celldns cell-dns -o yaml

El comando muestra un resultado similar al siguiente:

apiVersion: system.private.gdc.goog/v1alpha1
kind: CellDNS
metadata:
  name: cell-dns
  namespace: dns-system
spec:
  delegatedSubdomain: private.goog

Usa el siguiente comando para modificar la configuración del subdominio:

kubectl -n dns-system edit celldns cell-dns

Implementa un Google Cloud servicio en Distributed Cloud conectado

Para implementar un Google Cloud servicio en tu clúster de Distributed Cloud conectado, sigue los pasos de implementación que se describen en la documentación de ese servicio.

Configura elservicio implementado Google Cloud

En esta sección, se describen los pasos de configuración posteriores a la implementación que puedes completar según tus requisitos comerciales.

Reenvía consultas de DNS del DNS interno al DNS del clúster

Cuando implementas un Google Cloud servicio en tu clúster de Distributed Cloud conectado, se implementa un servidor DNS dedicado para ese servicio en el clúster. Te recomendamos que reenvíes las consultas de DNS para el subdominio del servicio al servidor DNS recién creado en el clúster.

  1. Usa los siguientes comandos para obtener el subdominio del clúster:

    CLUSTER_SUBDOMAIN=$(kubectl get configmap -n \
    $(kubectl get clusters -A -o jsonpath="{.items[0].metadata.namespace}") \
    dns-prefix -o jsonpath="{.data.dnsPrefix}")
DELEGATED_SUBDOMAIN=$(kubectl get celldns -n dns-system cell-dns -o \
  jsonpath="{.spec.delegatedSubdomain}")
CLUSTER_FQDN="${CLUSTER_SUBDOMAIN?}.${DELEGATED_SUBDOMAIN?}"
echo "${CLUSTER_FQDN?}"

    El último comando muestra un resultado similar al siguiente:

    my-zone.google.private.goog

  2. Usa el siguiente comando para obtener la VIP del servidor DNS en el clúster:

    DNS_EXT_IP=$(k -n dns-system get service gpc-coredns-external-tcp -o "jsonpath={.status.loadBalancer.ingress[0].ip}")

  3. Configura tu servidor DNS interno para reenviar las consultas de DNS para elservicio Google Cloud implementado a la VIP que obtuviste en el paso anterior. Por ejemplo:

    • Para dnsmasq, agrega lo siguiente a /etc/dnsmasq.conf:

      server=/${CLUSTER_FQDN?}/${DNS_EXT_IP?}

    • Para CoreDNS, agrega lo siguiente al Corefile:

      ${CLUSTER_FQDN?}:53 {
  errors
  cache 30
  forward . ${DNS_EXT_IP?} {
    max_concurrent 1000
  }
}

Prueba la resolución de DNS

Usa el siguiente comando dig para probar la resolución de dominio adecuada. Presta especial atención a la ANSWER SECTION:

 dig "ais-core.${CLUSTER_FQDN?}"

El comando muestra un resultado similar al siguiente:

...
;; ANSWER SECTION:
ais-core.my-zone.google.private.goog. 300 IN A 10.200.0.0
...

Recupera el certificado autofirmado para elservicio implementado Google Cloud

Cuando implementas un Google Cloud servicio en tu clúster de Distributed Cloud conectado, Distributed Cloud conectado emite un certificado autofirmado que luego usa para encriptar el tráfico de red de ese servicio. Te recomendamos que recuperes este certificado y configures tu entorno comercial para que confíe en él.

Para obtener este certificado en formato codificado en PEM, usa el siguiente comando:

 kubectl get secret -n cert-manager-cluster-resources web-ca-cert -o jsonpath="{.data.ca\.crt}" | base64 -d

Distributed Cloud conectado genera varios paquetes de confianza en todo el clúster. Estos paquetes de confianza se almacenan como ConfigMaps en cada espacio de nombres del clúster. que son las siguientes:

  • trust-store-internal-only. Contiene autoridades certificadoras (AC) para los servicios internos de Distributed Cloud conectado.
  • trust-store-root-ext. Contiene todas las AC en trust-store-root-ext, además de la AC que firmó el certificado autofirmado del servicio de destino Google Cloud . Activa este paquete de confianza en un pod si necesitas que ese pod acceda alservicio de destino Google Cloud .
  • trust-store-user-ext. Contiene todas las AC en trust-store-root-ext, además de las AC que agregaste de forma manual. Activa este paquete en un pod si necesitas que ese pod acceda alservicio de destino y a cualquier recurso interno que use certificados firmados por las AC que agregaste de forma manual. Google Cloud

Usa el siguiente comando para ver el ConfigMap de destino:

 kubectl -n default get configmap trust-store-user-root-ext -o yaml

El siguiente resultado de ejemplo muestra un recurso ConfigMap trust-store-user-root-ext típico:

apiVersion: v1
binaryData:
  ca.jks: WW91IGFyZSBhd2Vzb21lIQo=
data:
  ca.crt: |-
    -----BEGIN CERTIFICATE-----
    WW91IGFyZSBncmVhdCEK
    -----END CERTIFICATE-----
    -----BEGIN CERTIFICATE-----
    WW91IGFyZSBmYW50YXN0aWMhCg==
    -----END CERTIFICATE-----
kind: ConfigMap
metadata:
  labels:
    trust.cert-manager.io/bundle: trust-store-user-root-ext
  name: trust-store-user-root-ext
  namespace: default

Configura unservicio implementado para que confíe en tus propios certificados Google Cloud

Puedes crear un secreto de TLS en tu clúster de Distributed Cloud conectado y anotarlo con la anotación security.private.gdc.goog/bundles=trust-store-user-root-ext en el espacio de nombres cert-manager-cluster-resources. Esto permite que tu servicio implementado Google Cloud confíe en tus servicios internos de terceros para facilitar el intercambio de datos entre ellos.

Cuando aplicas este Secret a tu clúster, el servicio implementado confía en el certificado de la AC almacenado en el ca.crt archivo al que se hace referencia en el Secret. Google Cloud Por ejemplo:

apiVersion: v1
data:
  ca.crt: base64EncodedCaCert
  tls.crt: base64EncodedCert
  tls.key: base64EncodedKey
kind: Secret
metadata:
  annotations:
    security.private.gdc.goog/bundles: trust-store-user-root-ext
  name: my-corporate-cert
  namespace: cert-manager-cluster-resources
type: kubernetes.io/tls

Configura un proveedor de autenticación

Puedes configurar un proveedor de autenticación para facilitar el acceso a través de la interfaz de usuario del servicio implementado Google Cloud . En el siguiente ejemplo, se muestra una configuración para un OpenID Connect proveedor:

apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
  name: default
  namespace: kube-public
spec:
  authentication:
  - name: "google-oidc"
    oidc:
      clientID: "my-supersecret-client-id.apps.googleusercontent.com"
      clientSecret: "my-supersecret-secret"
      issuerURI: "https://accounts.google.com"
      scopes: "email"
      userClaim: "email"
  name: "default"

Para obtener más información, consulta Configura el Servicio de identidad de GKE para clústeres individuales.

Usa unservicio implementado Google Cloud

Consulta la documentación del Google Cloud servicio implementado para obtener información sobre cómo configurarlo para cumplir con tus requisitos comerciales.

Quita unservicio implementado Google Cloud

Para quitar unservicio implementado de tu clúster de Distributed Cloud conectado, sigue los pasos que se indican en la documentación de ese servicio. Google Cloud Si completaste alguno de los pasos opcionales posteriores a la implementación que se describen en esta página, también haz lo siguiente:

  • Inhabilita el reenvío de DNS al subdominio del servicio en tu DNS interno.
  • Inhabilita la confianza para el certificado autofirmado del servicio donde se haya establecido esa confianza.