Administrar servicios de Google

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

Servicios de Google Cloud compatibles

Distributed Cloud Connected admite la implementación de los siguientes servicios deGoogle Cloud :

Tipo de servicio Se incluye en los costos de GDC conectado Se factura por separado
Procesamiento Google Distributed Cloud solo con software
Entorno de ejecución de VM en Google Distributed Cloud
Sistemas operativos invitados
(debes obtener tus propias licencias)
Almacenamiento Almacenamiento sin procesar (volumen persistente)
Container Storage Interface (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
Complementos de la interfaz de red personalizada (CNI) de GKE
Balanceador de cargas de capa 4 incluido en GKE
No aplicable
AI/ML Implementa modelos de AutoML en contenedores No aplicable
Base de datos Ninguno AlloyDB Omni (vista previa)
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 configuración Config Sync
Paquetes de flota (versión preliminar)
No aplicable
Administración Panel de Google Kubernetes Engine en la Google Cloud consola
Connect Gateway
La kubectl herramienta local
Actualizaciones de software conectado de Distributed Cloud
No aplicable
Seguridad Integración de Cloud Key Management Service
Unidades de disco autoencriptadas (SED)
Identidad de cargas de trabajo de la flota
Registro de auditoría
No aplicable

Requisitos previos

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

Obtén credenciales de clúster

Usa el siguiente comando para obtener las credenciales de acceso 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 Google Cloud de destino.

Crea o selecciona un clúster

Si aún no lo hiciste, crea un clúster conectado de Distributed Cloud 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 de servicio de Google Cloud usarán estas VIP.

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 se aprovisionaron suficientes VIP en el clúster, aparecerá el siguiente error, en el que n es la cantidad requerida de VIP y m es la cantidad de VIP detectadas 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 del servicio Google Cloud

Antes de implementar el primer servicio Google Cloud en una zona conectada de Distributed Cloud, tienes la opción de personalizar el subdominio en el que todos los servicios Google Cloud implementados en esa zona escucharán las conexiones. No podrás 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 servicio de Google Cloud en tu clúster conectado de Distributed Cloud, sigue los pasos de implementación que se describen en la documentación de ese servicio.

Configura el servicio Google Cloud implementado

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

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

Cuando implementas un servicio de Google Cloud 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 que reenvíe las consultas de DNS del servicio 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?}
      
    • En el caso de 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 lo siguiente: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 el servicio Google Cloud implementado

Cuando implementas un servicio de Google Cloud en tu clúster conectado de Distributed Cloud, Distributed Cloud Connected 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 empresarial 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 connected 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. Son los siguientes:

  • trust-store-internal-only: Contiene las autoridades certificadoras (AC) para los servicios internos de Distributed Cloud conectado.
  • trust-store-root-ext: Contiene todas las AC del trust-store-root-ext, además de la AC que firmó el certificado autofirmado del servicioGoogle Cloud objetivo. Si necesitas que un Pod acceda al servicio Google Cloud de destino, debes instalar este paquete de confianza en él.
  • trust-store-user-ext: Contiene todas las entidades certificadoras de trust-store-root-ext, además de las que agregaste manualmente. Si necesitas que un Pod acceda tanto al servicio Google Cloud de destino como a los recursos internos que usan certificados firmados por las CA que agregaste de forma manual, debes instalar este paquete en el Pod.

Usa el siguiente comando para ver el ConfigMap de destino:

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

En el siguiente ejemplo de resultado, se 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 un servicio Google Cloud implementado para que confíe en tus propios certificados

Puedes crear un secreto de TLS en tu clúster conectado de Distributed Cloud 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 Google Cloudimplementado confíe en tus servicios internos de terceros para facilitar el intercambio de datos entre ellos.

Cuando aplicas este secreto a tu clúster, el servicio Google Cloud implementado confía en el certificado de CA almacenado en el archivo ca.crt al que se hace referencia en el secreto. 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 servicioGoogle Cloud implementado. En el siguiente ejemplo, se muestra una configuración para un proveedor de OpenID Connect:

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"

Si deseas obtener más información, consulta Configura GKE Identity Service para clústeres individuales.

Usa un Google Cloud servicio Google Cloud implementado

Consulta la documentación del servicio de Google Cloud implementado para obtener información sobre cómo configurarlo para que cumpla con los requisitos de tu empresa.

Cómo quitar un servicio Google Cloud implementado

Para quitar un servicio Google Cloud implementado de tu clúster conectado de Distributed Cloud, sigue los pasos que se indican en la documentación de ese servicio. Si completaste alguno de los pasos posteriores a la implementación opcionales 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 en el certificado autofirmado del servicio donde se haya establecido esa confianza.