Para obtener información sobre la versión, consulta las notas de la versión de Distributed Cloud connected.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Implementa cargas de trabajo

En esta página, se describen los pasos para implementar cargas de trabajo en tu hardware de Google Distributed Cloud conectado 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 conectado y pedir el hardware de Distributed Cloud.

Cuando el hardware de Google Distributed Cloud conectado llega al destino elegido , se preconfigura con hardware Google Cloud, y 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 conectado 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 Google Cloud proyecto. Luego, puedes aprovisionar grupos de nodos e implementar cargas de trabajo en Distributed Cloud conectado.

Descripción general de Deployment

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

Opcional: Habilita la API de Distributed Cloud Edge Network.
Opcional: Inicializa la configuración de red de tu zona conectada de Distributed Cloud.
Opcional: Configura las herramientas de redes de Distributed Cloud.
Crea un clúster conectado de Distributed Cloud.
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 CMEK para los datos de tu carga de trabajo. Para obtener información sobre cómo Distributed Cloud conectado encripta los datos de la carga de trabajo, consulta Seguridad del almacenamiento local.
Crea un grupo de nodos. En este paso, asignas nodos a un grupo de nodos y, de manera opcional, configuras el grupo de nodos para usar 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.
Obtén credenciales para un clúster para probarlo.
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.
Asigna a los usuarios acceso detallado basado en roles a los recursos del clúster mediante RoleBinding y ClusterRoleBinding.
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.
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 muestra cómo implementar el servidor NGINX y exponerlo como un servicio en un clúster conectado de Distributed Cloud:

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

Aplica el archivo YAML al clúster con el siguiente comando:
```
kubectl apply -f nginx-deployment.yaml
```

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

Aplica el archivo YAML al clúster con el siguiente comando:
```
kubectl apply -f nginx-deployment.yaml
```

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 `NodeSystemConfigUpdate`

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

Obtén una lista de 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 abreviados. Por ejemplo, para el nodo pool-example-node-1-01-b2d82cc7, su nombre abreviado es node101.

Para cada nodo que registraste 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.

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 sus reinicios.

Configura un Pod para el almacenamiento en caché de imágenes

Puedes configurar un Pod que se ejecuta 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 continúen 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 privadas, tu recurso ImagePullSecret debe ser de tipo kubernetes.io/dockerconfigjson.
Debes establecer la política de extracción del Pod en IfNotPresent para garantizar que siempre se use la copia almacenada en caché de la imagen de destino. Si no hay una copia almacenada en caché disponible de forma local, la imagen se extrae del repositorio.

En el siguiente ejemplo, se muestra 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 muestra 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 conectado aplica estas limitaciones en todas las cargas de trabajo que implementas en tu hardware de Distributed Cloud conectado.

Limitaciones de las cargas de trabajo de Linux

Distributed Cloud conectado 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 conectado no admite los siguientes espacios de nombres:

hostPID
hostIPC
hostNetwork

Restricciones de tipo de recurso

Distributed Cloud conectado no admite el tipo de recurso CertificateSigningRequest, que permite que un cliente solicite que se emita un certificado X.509, según una solicitud de firma.

Restricciones de contexto de seguridad

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

Restricciones de vinculación de Pods

Distributed Cloud conectado 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 `hostPath`

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

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

Restricciones de tipo de recurso `PersistentVolumeClaim`

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

csi
nfs
local

Restricciones de tipo de volumen

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

configMap
csi
downwardAPI
emptyDir
hostPath
nfs
persistentVolumeClaim
projected
secret

Restricciones de tolerancia de Pods

Distributed Cloud conectado no permite Pods creados por el usuario en nodos del plano de control. En particular, Distributed Cloud conectado 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

Distributed Cloud conectado no admite la suplantación de usuarios ni grupos.

Restricciones de espacio de nombres de administración

Distributed Cloud conectado 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 editar los 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 indica el ID del proyecto de destino Google Cloud .

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

Restricciones de webhook

Distributed Cloud conectado restringe los webhooks de la siguiente manera:

Cualquier webhook de mutación que crees excluye 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

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

Distributed Cloud conectado te permite especificar la clase de entorno de ejecución para un Pod en su configuración con el campo runtimeClassName. Esto anula la clase de entorno 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 esto en la configuración de tu Pod, el Pod usa 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 entorno de ejecución a nivel del Pod o del clúster, debes reiniciar los Pods afectados para que el cambio se efectúe.

Clase de entorno de ejecución `gvisor`

Si especificas la clase de entorno de ejecución gvisor, el Pod cambia 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.

Configura la integración de los Controles del servicio de VPC

Completa los pasos de esta sección para configurar la integración de la API de Distributed Cloud Edge Container con los Controles del servicio de VPC. Para obtener más información, consulta lo siguiente:

Especifica la prioridad del entorno de ejecución para un Pod

Distributed Cloud conectado te permite especificar una clase de prioridad para un Pod en su configuración con el campo priorityClassName. Este campo acepta el nombre de un recurso PriorityClass que especifica la prioridad de destino. Por ejemplo:

kind: PriorityClass
metadata:
  name: high-priority-class
value: 5100000
globalDefault: false
description: "High priority class for user workloads."

Especifica el nombre de la clase de prioridad en la configuración de tu Pod, como se muestra en el siguiente ejemplo:

apiVersion: v1
kind: Pod
metadata:
  name: myPod
spec:
  priorityClassName: high-priority-class
  containers:
  - name: myPod
    image: myPodImage 
  restartPolicy: OnFailure

Si especificas una clase de prioridad, se anula la prioridad predeterminada del Pod de 0. Para las cargas de trabajo críticas, establece su prioridad en un valor entre 5000001 y 1000000000. Distributed Cloud conectado quita automáticamente las cargas de trabajo de menor prioridad.

Reglas de salida obligatorias

Debes configurar las reglas de salida que se describen en esta sección para integrar la API de Distributed Cloud Edge Container con los Controles del servicio de VPC. Para obtener información sobre la sintaxis de las reglas de salida, consulta la referencia de las reglas de salida.

Acceso a la zona de la máquina y al Google Cloud proyecto

Esta regla permite que la identidad que realiza la llamada acceda a la zona de la máquina y al Google Cloud proyecto cuando realiza llamadas con la API de Distributed Cloud Edge Container. Esta regla se aplica cuando la máquina y el clúster no residen en el mismo Google Cloud proyecto y elproyecto de la máquina está fuera del perímetro. Google Cloud Esta regla es obligatoria si restringiste la API de Distributed Cloud Edge Container dentro del perímetro con los Controles del servicio de VPC.

El siguiente es un ejemplo de una configuración egressFrom para esta regla en formato JSON:

egressFrom:
  identityType: ANY_SERVICE_ACCOUNT
  sources:
    - accessLevel: "*"

El siguiente es un ejemplo de una configuración egressTo para esta regla:

egressTo:
 resources:
 - "projects/280968151686"
 operations:
   - serviceName: "edgecontainer.googleapis.com"
     methodSelectors:
       - method: "*"

Reglas de entrada obligatorias

Debes configurar las reglas de entrada que se describen en esta sección para integrar la API de Distributed Cloud Edge Container con los Controles del servicio de VPC. Para obtener información sobre la sintaxis de las reglas de entrada, consulta la referencia de las reglas de entrada.

Acceso a la API de Distributed Cloud Edge Container

Esta regla permite que identidades específicas accedan a la API de Distributed Cloud Edge Container y que interactúen con ella. Debes configurar esta regla si restringiste la API de Distributed Cloud Edge Container dentro del perímetro con los Controles del servicio de VPC y la identidad que llama a la API de Distributed Cloud Edge Container está fuera del perímetro.

El siguiente es un ejemplo de una configuración ingressFrom para esta regla:

ingressFrom:
   sources:
     - accessLevel: '*'
   identities:
     - serviceAccount:testuser@kubernetesedge-e2e-testing.iam.gserviceaccount.com

El siguiente es un ejemplo de una configuración ingressTo para esta regla:

ingressTo:
 resources:
 - "*"
 operations:
   - serviceName: "edgecontainer.googleapis.com"
     methodSelectors:
       - method: "*"

Acceso a la API de Connect y a la API del servicio de token de seguridad

Esta regla permite que las cargas de trabajo accedan a la API de Connect y a la API del servicio de token de seguridad. Debes configurar esta regla si restringiste el acceso a la API de Connect y a la API del servicio de token de seguridad dentro del perímetro con los Controles del servicio de VPC. Para obtener información sobre cómo configurar políticas de acceso a nivel de la dirección IP, consulta Dirección IP.