Implementa cargas de trabajo

En esta página, se describen los pasos para implementar cargas de trabajo en el hardware conectado de Google Distributed Cloud y las limitaciones que debes cumplir cuando configures tus cargas de trabajo.

Antes de completar estos pasos, debes cumplir con los requisitos de instalación de Distributed Cloud Connected y solicitar el hardware de Distributed Cloud.

Cuando el hardware de Google Distributed Cloud conectado llega al destino que elegiste, ya está configurado con hardware, Google Cloudy algunos parámetros de configuración de red que especificaste cuando pediste Distributed Cloud conectado.

Los instaladores de Google completan la instalación física, y el administrador del sistema conecta Distributed Cloud connected a tu red local.

Después de que el hardware se conecta a tu red local, se comunica con Google Cloud para descargar actualizaciones de software y conectarse con tu proyectoGoogle Cloud . Luego, podrás aprovisionar grupos de nodos y, también, implementar cargas de trabajo en Distributed Cloud conectado.

Descripción general de implementación

Para implementar una carga de trabajo en tu hardware conectado de Distributed Cloud, completa los siguientes pasos:

  1. Opcional: Habilita la API de Distributed Cloud Edge Network.

  2. Opcional: Inicializa la configuración de red de tu zona conectada de Distributed Cloud.

  3. Opcional: Configura las redes de Distributed Cloud.

  4. Crea un clúster conectado de Distributed Cloud.

  5. Opcional: Habilita la compatibilidad con las claves de encriptación administradas por el cliente (CMEK) para el almacenamiento local si deseas realizar la integración con Cloud Key Management Service para habilitar la compatibilidad con las CMEK para los datos de tu carga de trabajo. Para obtener información sobre cómo Distributed Cloud Connected encripta los datos de las cargas de trabajo, consulta Seguridad del almacenamiento local.

  6. Crea un grupo de nodos. En este paso, asignarás nodos a un grupo de nodos y, de manera opcional, configurarás el grupo de nodos para que use Cloud KMS para encapsular y desencapsular la frase de contraseña de Linux Unified Key Setup (LUKS) para encriptar los datos de la carga de trabajo.

  7. Obtén credenciales para un clúster para probarlo.

  8. Otorga a los usuarios acceso al clúster asignándoles el rol de visualizador de contenedores de Edge (roles/edgecontainer.viewer) o el rol de administrador de contenedores de Edge (roles/edgecontainer.admin) en el proyecto.

  9. Asigna a los usuarios acceso detallado basado en roles a los recursos del clúster con RoleBinding y ClusterRoleBinding.

  10. Opcional: Habilita la compatibilidad con el entorno de ejecución de VM en Google Distributed Cloud para ejecutar cargas de trabajo en máquinas virtuales en Distributed Cloud conectado.

  11. Opcional: Habilita la compatibilidad con GPU para ejecutar cargas de trabajo basadas en GPU en Distributed Cloud conectado.

Implementa el balanceador de cargas de NGINX como un servicio

En el siguiente ejemplo, se ilustra cómo implementar el servidor NGINX y exponerlo como un servicio en un clúster conectado de Distributed Cloud:

  1. Crea un archivo YAML llamado nginx-deployment.yaml con el siguiente contenido:

    apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
labels:
  app: nginx
spec:
replicas: 1
selector:
  matchLabels:
     app: nginx
template:
  metadata:
     labels:
     app: nginx
  spec:
     containers:
     - name: nginx
     image: nginx:latest
     ports:
     - containerPort: 80

  2. Aplica el archivo YAML al clúster con el siguiente comando:

    kubectl apply -f nginx-deployment.yaml

  3. Crea un archivo YAML llamado nginx-service.yaml con el siguiente contenido:

    apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
type: LoadBalancer
selector:
  app: nginx
  ports:
     - protocol: TCP
       port: 8080
       targetPort: 80

  4. Aplica el archivo YAML al clúster con el siguiente comando:

    kubectl apply -f nginx-deployment.yaml

  5. Obtén la dirección IP externa asignada al servicio por el balanceador de cargas de MetalLB con el siguiente comando:

    kubectl get services

    El comando muestra un resultado similar al siguiente:

    NAME            TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)          AGE
nginx-service   LoadBalancer   10.51.195.25   10.100.68.104   8080:31966/TCP   11d

Configura los recursos de NodeSystemConfigUpdate

Configura un recurso de operador de función de red NodeSystemConfigUpdate para cada nodo del clúster de la siguiente manera.

  1. Enumera los nodos que se ejecutan en el grupo de nodos del clúster de destino con el siguiente comando:

    kubectl get nodes | grep -v master

    El comando muestra un resultado similar al siguiente:

    NAME                                 STATUS   ROLES       AGE     VERSION
pool-example-node-1-01-b2d82cc7      Ready    <none>      2d      v1.22.8-gke.200
pool-example-node-1-02-52ddvfc9      Ready    <none>      2d      v1.22.8-gke.200

    Registra los nombres de los nodos que se muestran y deriva sus nombres cortos. Por ejemplo, para el nodo pool-example-node-1-01-b2d82cc7, su nombre corto es node101.

  2. Para cada nodo que grabaste en el paso anterior, crea un archivo de recursos NodeSystemConfigUpdate dedicado con el siguiente contenido:

    apiVersion: networking.gke.io/v1
kind: NodeSystemConfigUpdate
metadata:
name: nodesystemconfigupdate-NODE_SHORT_NAME
namespace: nf-operator
spec:
kubeletConfig:
  cpuManagerPolicy: Static
  topologyManagerPolicy: SingleNumaNode
nodeName: NODE_NAME
osConfig:
  hugePagesConfig:
     ONE_GB: 2
     TWO_MB: 0
  isolatedCpusPerSocket:
     "0": 40
     "1": 40
sysctls:
  nodeLevel:
     net.core.rmem_max: "8388608"
     net.core.wmem_max: "8388608"

    Reemplaza lo siguiente:

    • NODE_NAME: Es el nombre completo del nodo de destino. Por ejemplo, pool-example-node-1-01-b2d82cc7.
    • NODE_SHORT_NAME: Es el nombre abreviado del nodo de destino derivado de su nombre completo. Por ejemplo, node101

    Asigna a cada archivo el nombre node-system-config-update-NODE_SHORT_NAME.yaml.

  3. Aplica cada uno de los archivos de recursos NodeSystemConfigUpdate al clúster con el siguiente comando:

    kubectl apply -f node-system-config-update-NODE_SHORT_NAME.yaml

    Reemplaza NODE_SHORT_NAME por el nombre abreviado del nodo de destino correspondiente.

    Cuando aplicas los recursos al clúster, se reinicia cada nodo afectado, lo que puede demorar hasta 30 minutos.

    1. Supervisa el estado de los nodos afectados hasta que todos se reinicien correctamente:
    kubectl get nodes | grep -v master

    El estado de cada nodo pasa de not-ready a ready a medida que se completan los reinicios.

Cómo configurar un Pod para el almacenamiento en caché de imágenes

Puedes configurar un Pod que se ejecute en un clúster conectado de Distributed Cloud para almacenar en caché su imagen. El Pod comienza a usar la imagen almacenada en caché después de que se extrae del repositorio por primera vez. Si el nodo que aloja el Pod se queda sin almacenamiento, no se almacenan en caché las imágenes nuevas y se borra la caché de imágenes existente para garantizar que tus cargas de trabajo sigan ejecutándose sin interrupciones.

La configuración de tu Pod debe cumplir con los siguientes requisitos previos:

  • Debes establecer la etiqueta gdce.baremetal.cluster.gke.io/cache-image: true en el Pod.
  • Si usas un repositorio de imágenes privado, tu recurso ImagePullSecret debe ser del tipo kubernetes.io/dockerconfigjson.
  • Debes establecer la política de extracción del Pod en IfNotPresent para asegurarte de que siempre se use la copia almacenada en caché de la imagen de destino. Si no hay una copia en caché disponible de forma local, la imagen se extrae del repositorio.

En el siguiente ejemplo, se ilustra una configuración de Pod con el almacenamiento en caché habilitado:

apiVersion: v1
kind: Pod
metadata:
  name: cached-image-pod
  labels:
    gdce.baremetal.cluster.gke.io/cache-image: "true"
spec:
  containers:
    - name: my-container
      image: your-private-image-repo/your-image:tag
      imagePullPolicy: IfNotPresent
  imagePullSecrets:
    - name: my-image-secret  # If using a private registry

En el siguiente ejemplo, se ilustra una configuración de Deployment con el almacenamiento en caché habilitado:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cached-image-deployment
spec:
  template:
    metadata:
      labels:
        gdce.baremetal.cluster.gke.io/cache-image: "true"
    spec:
      containers:
        - name: my-container
          image: your-private-image-repo/your-image:tag
          imagePullPolicy: IfNotPresent
      imagePullSecrets:
        - name: my-image-secret  # If using a private registry

Limitaciones para las cargas de trabajo de Distributed Cloud

Cuando configures tus cargas de trabajo conectadas de Distributed Cloud, debes cumplir con las limitaciones que se describen en esta sección. Distributed Cloud connected aplica estas limitaciones en todas las cargas de trabajo que implementas en tu hardware de Distributed Cloud connected.

Limitaciones de las cargas de trabajo de Linux

Distributed Cloud Connected solo admite las siguientes capacidades de Linux para las cargas de trabajo:

  • AUDIT_READ
  • AUDIT_WRITE
  • CHOWN
  • DAC_OVERRIDE
  • FOWNER
  • FSETID
  • IPC_LOCK
  • IPC_OWNER
  • KILL
  • MKNOD
  • NET_ADMIN
  • NET_BIND_SERVICE
  • NET_RAW
  • SETFCAP
  • SETGID
  • SETPCAP
  • SETUID
  • SYS_CHROOT
  • SYS_NICE
  • SYS_PACCT
  • SYS_PTRACE
  • SYS_RESOURCE
  • SYS_TIME

Restricciones de espacio de nombres

Distributed Cloud Connected no admite los siguientes espacios de nombres:

  • hostPID
  • hostIPC
  • hostNetwork

Restricciones de tipo de recurso

Distributed Cloud Connected no admite el tipo de recurso CertificateSigningRequest, que permite que un cliente solicite que se emita un certificado X.509 en función de una solicitud de firma.

Restricciones de contexto de seguridad

Distributed Cloud Connected no admite el contexto de seguridad del modo privilegiado.

Restricciones de vinculación de Pod

Distributed Cloud Connected no admite la vinculación de Pods a puertos de host en el espacio de nombres HostNetwork. Además, el espacio de nombres HostNetwork no está disponible.

Restricciones de volumen de hostPath

Distributed Cloud Connected solo permite los siguientes volúmenes de hostPath con acceso de lectura y escritura:

  • /dev/hugepages
  • /dev/infiniband
  • /dev/vfio
  • /dev/char
  • /sys/devices

Restricciones del tipo de recurso PersistentVolumeClaim

Distributed Cloud Connected solo permite los siguientes tipos de recursos PersistentVolumeClaim:

  • csi
  • nfs
  • local

Restricciones de tipo de volumen

Distributed Cloud Connected solo permite los siguientes tipos de volúmenes:

  • configMap
  • csi
  • downwardAPI
  • emptyDir
  • hostPath
  • nfs
  • persistentVolumeClaim
  • projected
  • secret

Restricciones de tolerancia de Pods

Distributed Cloud Connected no permite Pods creados por el usuario en los nodos del plano de control. Específicamente, Distributed Cloud Connected no permite programar Pods que tengan las siguientes claves de tolerancia:

  • ""
  • node-role.kubernetes.io/master
  • node-role.kubernetes.io/control-plane

Restricciones de suplantación de identidad

Distributed Cloud Connected no admite la suplantación de usuarios o grupos.

Restricciones del espacio de nombres de administración

Distributed Cloud Connected no permite el acceso a los siguientes espacios de nombres:

  • ai-system
  • ai-speech-system
  • ai-ocr-system
  • ai-translation-system
  • anthos-identity-service
  • cert-manager
  • dataproc-system
  • dataproc-PROJECT_ID
  • dns-system
  • g-istio-system
  • gke-connect
  • gke-managed-metrics-server
  • gke-operators
  • g-ospf-servicecontrol-system
  • g-ospf-system
  • g-pspf-system
  • gke-system
  • gpc-backup-system
  • iam-system
  • kube-node-lease
  • kube-public
  • kube-system, con la excepción de borrar ippools.whereabouts.cni.cncf.io
  • metallb-system, con la excepción de la edición de recursos configMap para establecer rangos de direcciones IP de balanceo de cargas
  • nf-operator
  • oclcm-system
  • prediction
  • rm-system
  • robinio
  • saas-system
  • vm-system

PROJECT_ID denota el ID del proyecto Google Cloud de destino.

Evita usar cualquier espacio de nombres con el prefijo g- en su nombre. Por lo general, estos espacios de nombres son espacios de nombres reservados que utiliza Distributed Cloud Connected.

Restricciones de webhook

Distributed Cloud conectado restringe los webhooks de la siguiente manera:

  • Cualquier webhook de mutación que crees excluirá automáticamente el espacio de nombres kube-system.
  • Los webhooks de mutación están inhabilitados para los siguientes tipos de recursos:
    • nodes
    • persistentvolumes
    • certificatesigningrequests
    • tokenreviews

Restricciones de prioridad de Pod

Distributed Cloud Connected requiere que establezcas la prioridad de tus Pods de carga de trabajo en un valor inferior a 500000000.

Configura la clase de tiempo de ejecución para un Pod

Distributed Cloud Connected te permite especificar la clase de tiempo de ejecución para un Pod en su configuración con el campo runtimeClassName. Esto anula la clase de tiempo de ejecución predeterminada especificada a nivel del clúster. Las clases de entorno de ejecución disponibles son runc y gvisor. Por ejemplo:

apiVersion: v1
kind: Pod
metadata:
  name: myPod
spec:
  runtimeClassName: gvisor
  containers:
  - name: myPod
    image: myPodImage 
  restartPolicy: OnFailure

Si omites este campo en la configuración del Pod, este usará la clase especificada a nivel del clúster. La clase de entorno de ejecución predeterminada a nivel del clúster es runc, a menos que configures una clase de entorno de ejecución predeterminada con el parámetro --default-container-runtime, como se describe en Crea y administra clústeres.

Si cambias la clase de tiempo de ejecución a nivel del Pod o del clúster, debes reiniciar los Pods afectados para que el cambio se aplique.

Clase de tiempo de ejecución gvisor

Si especificas la clase de entorno de ejecución gvisor, el Pod cambiará al entorno de ejecución seguro de Open Container Initiative (OCI) basado en gVisor. gVisor es una solución de zona de pruebas que introduce un aislamiento sólido entre la carga de trabajo y su host.

¿Qué sigue?