Se usó la API de Cloud Translation para traducir esta página.

Endurece el aislamiento de las cargas de trabajo con GKE Sandbox

Autopilot estándar

En esta página, se describe cómo usar GKE Sandbox para proteger el kernel del host en tus nodos cuando los contenedores del pod ejecutan un código desconocido o que no es de confianza, o necesitan un aislamiento extra del nodo. En esta página, se explica cómo habilitar GKE Sandbox y supervisar tus clústeres cuando se ejecuta GKE Sandbox.

Esta página está dirigida a los especialistas en seguridad que deben aislar sus cargas de trabajo para obtener protección adicional contra código desconocido o no confiable. Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que hacemos referencia en el contenido de Google Cloud , consulta Roles y tareas comunes de los usuarios de GKE.

Antes de leer esta página, asegúrate de conocer la descripción general de GKE Sandbox.

Habilita GKE Sandbox

GKE Sandbox está listo para usarse en clústeres de Autopilot que ejecutan la versión 1.27.4-gke.800 de GKE y versiones posteriores. Para comenzar a implementar cargas de trabajo de Autopilot en una zona de pruebas, ve a Trabaja con GKE Sandbox.

Para usar GKE Sandbox en clústeres nuevos o existentes de GKE Standard, debes habilitar GKE Sandbox de forma manual en el clúster.

Para obtener más información sobre las versiones de GPU, consulta Compatibilidad con modelos de GPU.

Antes de comenzar

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

Habilita la API de Google Kubernetes Engine.

Habilitar la API de Google Kubernetes Engine

Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta el comando gcloud components update para obtener la versión más reciente. Es posible que las versiones anteriores de gcloud CLI no admitan la ejecución de los comandos que se describen en este documento.
Nota: Para las instalaciones de gcloud CLI existentes, asegúrate de configurar la propiedad compute/region. Si usas principalmente clústeres zonales, configura compute/zone en su lugar. Cuando configuras una ubicación predeterminada, puedes evitar errores en gcloud CLI como el siguiente: One of [--zone, --region] must be supplied: Please specify location. Es posible que debas especificar la ubicación en ciertos comandos si la ubicación de tu clúster difiere de la predeterminada que estableciste.

Habilita GKE Sandbox en un clúster Standard nuevo

El grupo de nodos predeterminado, que se crea cuando creas un clúster nuevo, no puede usar GKE Sandbox si es el único grupo de nodos en el clúster, ya que las cargas de trabajo del sistema administradas por GKE deben ejecutarse por separado de las cargas de trabajo en zona de pruebas que no son de confianza. Para habilitar GKE Sandbox durante la creación del clúster, debes agregar al menos un grupo de nodos adicional al clúster.

Console

Para ver tus clústeres, visita el menú de Google Kubernetes Engine en laGoogle Cloud consola.

En la consola de Google Cloud , ve a la página Crea un clúster de Kubernetes.
Ir a Crea un clúster de Kubernetes
Opcional, pero recomendado: en el menú de navegación, en Clúster, haz clic en Funciones y selecciona las siguientes casillas de verificación para que se registren los mensajes de gVisor.
- Cloud Logging
- Cloud Monitoring
- Servicio administrado para Prometheus
Haz clic en Agregar grupo de nodos.
Desde el menú de navegación, en Grupos de nodos, expande el grupo de nodos nuevo y haz clic en Nodos.
Establece la siguiente configuración para el grupo de nodos:
1. En la lista desplegable Tipo de imagen, selecciona Container-Optimized OS con Containerd (cos_containerd). Este es el único tipo de imagen compatible con GKE Sandbox.
2. En Configuración de la máquina, selecciona una Serie y un Tipo de máquina.
3. De manera opcional, si ejecutas una versión de GKE compatible, selecciona un tipo de GPU o TPU. Debe ser uno de los siguientes tipos de GPU:
  - nvidia-gb200: NVIDIA GB200 NVL72 (versión preliminar)
  - nvidia-b200: NVIDIA B200 (180 GB) (versión preliminar)
  - nvidia-h200-141gb: NVIDIA H200 (141 GB) (versión preliminar)
  - nvidia-h100-mega-80gb: NVIDIA H100 Mega (80 GB)
  - nvidia-h100-80gb: NVIDIA H100 (80 GB)
  - nvidia-a100-80gb: NVIDIA A100 (80 GB)
  - nvidia-tesla-a100: NVIDIA A100 (40 GB)
  - nvidia-l4: NVIDIA L4
  - nvidia-tesla-t4: NVIDIA T4
  Para obtener más información, consulta Compatibilidad con modelos de GPU.
  
  o los siguientes tipos de TPU:
  - v4
  - v5e
  - v5p
  - v6e
En el menú de navegación, debajo del nombre del grupo de nodos que configuras, haz clic en Seguridad y selecciona la casilla de verificación Habilitar zona de pruebas con gVisor.
Continúa configurando el clúster y los grupos de nodos como lo necesites.
Haz clic en Crear.

gcloud

GKE Sandbox no se puede habilitar para el grupo de nodos predeterminado y no es posible crear grupos de nodos adicionales al mismo tiempo que creas un clúster nuevo con el comando gcloud. En su lugar, crea tu clúster como lo harías en condiciones normales. Aunque es opcional, se recomienda que habilites Logging and Monitoring para que se registren los mensajes de gVisor.

Luego, usa el comando gcloud container node-pools create y establece la marca -- sandbox en type=gvisor. El tipo de imagen del nodo debe ser cos_containerd para GKE Sandbox.

gcloud container node-pools create NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --node-version=NODE_VERSION \
  --machine-type=MACHINE_TYPE \
  --image-type=cos_containerd \
  --sandbox type=gvisor

Reemplaza las siguientes variables:

NODE_POOL_NAME: es el nombre de tu grupo de nodos nuevo.
CLUSTER_NAME: El nombre de tu clúster.
NODE_VERSION: Es la versión que se usará para el grupo de nodos.
MACHINE_TYPE: Es el tipo de máquina que se usará para los nodos.

Para crear un grupo de nodos de GPU con GKE Sandbox, ejecuta el siguiente comando:

gcloud container node-pools create NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --node-version=NODE_VERSION \
  --machine-type=MACHINE_TYPE \
  --accelerator=type=GPU_TYPE,gpu-driver-version=DRIVER_VERSION \
  --image-type=cos_containerd \
  --sandbox type=gvisor

Reemplaza lo siguiente:

GPU_TYPE: un tipo de GPU compatible. Para obtener más información, consulta GKE Sandbox.
MACHINE_TYPE: una máquina que coincide con el tipo de GPU solicitado. Para obtener más detalles, consulta Requisitos de GPU de Google Kubernetes Engine.
DRIVER_VERSION: Es la versión del controlador NVIDIA que se instalará. Puede ser una de las siguientes:
- default: Instala la versión predeterminada del controlador para tu versión de GKE.
- latest: Instala la última versión del controlador disponible para tu versión de GKE. Disponible solo para los nodos que usan Container-Optimized OS.

Para crear un grupo de nodo TPU con GKE Sandbox, ejecuta el siguiente comando:

gcloud container node-pools create NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --node-version=NODE_VERSION \
  --num-nodes=NUM_NODES \
  --tpu-topology=TPU_TOPOLOGY \
  --machine-type=MACHINE_TYPE \
  --image-type=cos_containerd \
  --sandbox type=gvisor

MACHINE_TYPE: un tipo de TPU compatible. Para obtener más información, consulta GKE Sandbox.

Habilita GKE Sandbox en un clúster Standard existente

Puedes habilitar GKE Sandbox en un clúster Standard existente si agregas un grupo de nodos nuevo y habilitas la característica para este.

Console

Para crear un grupo de nodos nuevo con GKE Sandbox habilitado, sigue estos pasos:

Ve a la página de Google Kubernetes Engine en la consola de Google Cloud .

Ir a Google Kubernetes Engine
Haz clic en el nombre del clúster que deseas modificar.
Haz clic en Agregar grupo de nodos.
Configura la página de detalles del grupo de nodos como según la selección.
En el menú de navegación, haz clic en Nodos y establece la siguiente configuración:
1. En la lista desplegable Tipo de imagen, selecciona Container-Optimized OS con Containerd (cos_containerd). Este es el único tipo de imagen compatible con GKE Sandbox.
2. En Configuración de la máquina, selecciona una Serie y un Tipo de máquina.
3. De manera opcional, si ejecutas una versión de GKE compatible, selecciona un tipo de GPU o TPU. Debe ser uno de los siguientes tipos de GPU
  - nvidia-gb200: NVIDIA GB200 NVL72 (versión preliminar)
  - nvidia-b200: NVIDIA B200 (180 GB) (versión preliminar)
  - nvidia-h200-141gb: NVIDIA H200 (141 GB) (versión preliminar)
  - nvidia-h100-mega-80gb: NVIDIA H100 Mega (80 GB)
  - nvidia-h100-80gb: NVIDIA H100 (80 GB)
  - nvidia-a100-80gb: NVIDIA A100 (80 GB)
  - nvidia-tesla-a100: NVIDIA A100 (40 GB)
  - nvidia-l4: NVIDIA L4
  - nvidia-tesla-t4: NVIDIA T4
  Para obtener más información, consulta Compatibilidad con modelos de GPU.
  
  o los siguientes tipos de TPU:
  - v4
  - v5e
  - v5p
  - v6e
En el menú de navegación, haz clic en Seguridad y selecciona la casilla de verificación Habilitar zona de pruebas con gVisor.
Haz clic en Crear.

gcloud

Para crear un grupo de nodos nuevo con GKE Sandbox habilitado, usa un comando como el siguiente:

gcloud container node-pools create NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --machine-type=MACHINE_TYPE \
  --image-type=cos_containerd \
  --sandbox type=gvisor

El tipo de imagen del nodo debe ser cos_containerd para GKE Sandbox.

Para crear un grupo de nodos de GPU con GKE Sandbox, ejecuta el siguiente comando:

gcloud container node-pools create NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --node-version=NODE_VERSION \
  --machine-type=MACHINE_TYPE \
  --accelerator=type=GPU_TYPE,gpu-driver-version=DRIVER_VERSION \
  --image-type=cos_containerd \
  --sandbox type=gvisor

Reemplaza lo siguiente:

GPU_TYPE: un tipo de GPU compatible. Para obtener más información, consulta GKE Sandbox.
MACHINE_TYPE: una máquina que coincide con el tipo de GPU solicitado. Para obtener más detalles, consulta Requisitos de GPU de Google Kubernetes Engine.
DRIVER_VERSION: Es la versión del controlador NVIDIA que se instalará. Puede ser una de las siguientes:
- default: Instala la versión predeterminada del controlador para tu versión de GKE.
- latest: Instala la última versión del controlador disponible para tu versión de GKE. Disponible solo para los nodos que usan Container-Optimized OS.

Para crear un grupo de nodo TPU con GKE Sandbox, ejecuta el siguiente comando:

gcloud container node-pools create NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --node-version=NODE_VERSION \
  --num-nodes=NUM_NODES \
  --tpu-topology=TPU_TOPOLOGY \
  --machine-type=MACHINE_TYPE \
  --image-type=cos_containerd \
  --sandbox type=gvisor

MACHINE_TYPE: un tipo de TPU compatible. Para obtener más información, consulta GKE Sandbox.

Opcional: Habilita la supervisión y el registro

Es opcional, pero se recomienda que habilites Cloud Logging y Cloud Monitoring en el clúster para que se registren los mensajes de gVisor. Estos servicios están habilitados de forma predeterminada para los clústeres nuevos.

Puedes usar la consola de Google Cloud para habilitar estas funciones en un clúster existente.

Ve a la página de Google Kubernetes Engine en la consola de Google Cloud .

Ir a Google Kubernetes Engine
Haz clic en el nombre del clúster que deseas modificar.
En Funciones, en el campo Cloud Logging, haz clic en Editar Cloud Logging.
Selecciona la casilla de verificación Habilitar Cloud Logging.
Haz clic en Guardar cambios.
Repite los mismos pasos para los campos de Cloud Monitoring y Managed Service para Prometheus para habilitar esas funciones.

Usa GKE Sandbox en Autopilot y Standard

En los clústeres de Autopilot y en los clústeres Standard con GKE Sandbox habilitado, debes solicitar un entorno de zona de pruebas para un pod a través de la especificación de RuntimeClass de gvisor en la especificación del pod.

Para los clústeres Autopilot, asegúrate de ejecutar la versión 1.27.4-gke.800 de GKE o una posterior.

Ejecuta una aplicación en una zona de pruebas

Para hacer que una Deployment se ejecute en un nodo con GKE Sandbox habilitado, establece su spec.template.spec.runtimeClassName en gvisor, como se muestra en el siguiente ejemplo:

# httpd.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpd
  labels:
    app: httpd
spec:
  replicas: 1
  selector:
    matchLabels:
      app: httpd
  template:
    metadata:
      labels:
        app: httpd
    spec:
      runtimeClassName: gvisor
      containers:
      - name: httpd
        image: httpd

Crea el Deployment:

kubectl apply -f httpd.yaml

El Pod se implementa en un nodo con GKE Sandbox habilitado. Para verificar la implementación, busca el nodo en el que se implementa el Pod:

kubectl get pods

El resultado es similar a este:

NAME                    READY   STATUS    RESTARTS   AGE
httpd-db5899bc9-dk7lk   1/1     Running   0          24s

Busca el nombre del Pod en el resultado y, luego, verifica el valor de RuntimeClass:

kubectl get pods POD_NAME -o jsonpath='{.spec.runtimeClassName}'

El resultado es gvisor.

También puedes enumerar los objetos RuntimeClass de cada Pod y buscar los que están configurados como gvisor:

kubectl get pods -o jsonpath=$'{range .items[*]}{.metadata.name}: {.spec.runtimeClassName}\n{end}'

Esta es la salida:

POD_NAME: gvisor

Este método para verificar que el pod se ejecute en una zona de pruebas es confiable, ya que no depende de ningún dato dentro de la zona de pruebas. Todo lo que se informe desde la zona de pruebas no es confiable, ya que podría ser defectuoso o malicioso.

Ejecuta un Pod con aceleradores en GKE Sandbox

Para ejecutar una carga de trabajo de GPU o TPU en GKE Sandbox, agrega el campo runtimeClassName: gvisor a tu manifiesto, como en los siguientes ejemplos:

Manifiesto de ejemplo para Pods de GPU de modo Standard:

apiVersion: v1
kind: Pod
metadata:
  name: my-gpu-pod
spec:
  runtimeClassName: gvisor
  containers:
  - name: my-gpu-container
    image: nvidia/samples:vectoradd-cuda10.2
    resources:
      limits:
        nvidia.com/gpu: 1

Manifiesto de ejemplo para Pods de GPU del modo Autopilot:

apiVersion: v1
kind: Pod
metadata:
  name: my-gpu-pod
spec:
  runtimeClassName: gvisor
  nodeSelector:
    cloud.google.com/gke-gpu-driver-version: "latest"
    cloud.google.com/gke-accelerator: nvidia-tesla-t4
  containers:
  - name: my-gpu-container
    image: nvidia/samples:vectoradd-cuda10.2
    resources:
      limits:
        nvidia.com/gpu: 1

Manifiesto de ejemplo para Pods de TPU en modo Standard o Autopilot:

apiVersion: v1
kind: Pod
metadata:
  name: my-tpu-pod
spec:
  runtimeClassName: gvisor
  nodeSelector:
    cloud.google.com/gke-tpu-accelerator: tpu-v5-lite-podslice
    cloud.google.com/gke-tpu-topology: 1x1
  containers:
  - name: my-tpu-container
    image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest
    command:
      - bash
      - -c
      - |
        python -c 'import jax; print("TPU cores:", jax.device_count())'
    resources:
      limits:
        google.com/tpu: 1
      requests:
        google.com/tpu: 1

Puedes ejecutar cualquier Pod de acelerador de modo Autopilot o Standard que cumpla con los requisitos de versión y tipo de acelerador en GKE Sandbox. Para ello, agrega el campo runtimeClassName: gvisor al manifiesto. Para ejecutar Pods de GPU en GKE, consulta lo siguiente:

Para ejecutar Pods de TPU en GKE, consulta lo siguiente:

Los tipos de GPU compatibles con Autopilot son los siguientes:

nvidia-gb200: NVIDIA GB200 NVL72 (versión preliminar)
nvidia-b200: NVIDIA B200 (180 GB) (versión preliminar)
nvidia-h200-141gb: NVIDIA H200 (141 GB) (versión preliminar)
nvidia-h100-mega-80gb: NVIDIA H100 Mega (80 GB)
nvidia-h100-80gb: NVIDIA H100 (80 GB)
nvidia-a100-80gb: NVIDIA A100 (80 GB)
nvidia-tesla-a100: NVIDIA A100 (40 GB)
nvidia-l4: NVIDIA L4
nvidia-tesla-t4: NVIDIA T4

Para obtener más información, consulta Compatibilidad con modelos de GPU.

Ejecuta un Pod regular junto con Pods de zona de pruebas

Los pasos de esta sección se aplican a las cargas de trabajo del modo estándar. No es necesario ejecutar Pods regulares junto con los Pods de la zona de pruebas en el modo Autopilot, ya que el modelo de precios de Autopilot elimina la necesidad de optimizar de forma manual la cantidad de Pods programada en los nodos.

Después de habilitar GKE Sandbox en un grupo de nodos, puedes ejecutar aplicaciones confiables en esos nodos sin usar una zona de pruebas a través de tolerancias y taints de nodo. Estos pods se denominan “pods regulares” para distinguirlos de los pods de zona de pruebas.

Los Pods regulares, al igual que los Pods de zona de pruebas, no pueden acceder a otros servicios deGoogle Cloud ni a los metadatos del clúster. Esta prevención es parte de la configuración del nodo. Si tus Pods normales o Pods de zona de pruebas requieren acceso a los servicios deGoogle Cloud , usa la federación de identidades para cargas de trabajo para GKE.

GKE Sandbox agrega la siguiente etiqueta y taint a los nodos que pueden ejecutar pods de zona de pruebas:

labels:
  sandbox.gke.io/runtime: gvisor

taints:
- effect: NoSchedule
  key: sandbox.gke.io/runtime
  value: gvisor

Además de cualquier configuración de tolerancia y afinidad de nodo en tu manifiesto de pod, GKE Sandbox aplica la siguiente tolerancia y afinidad de nodo a todos los pods con RuntimeClass establecido en gvisor:

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: sandbox.gke.io/runtime
          operator: In
          values:
          - gvisor

tolerations:
  - effect: NoSchedule
    key: sandbox.gke.io/runtime
    operator: Equal
    value: gvisor

Para programar un pod regular en un nodo con GKE Sandbox habilitado, aplica de forma manual la tolerancia y la afinidad de nodos descritas antes en el manifiesto de tu pod.

Si el pod puede ejecutarse en nodos con GKE Sandbox habilitado, agrega la tolerancia.
Si tu pod debe ejecutarse en nodos con GKE Sandbox habilitado, agrega la tolerancia y la afinidad de nodo.

Por ejemplo, con el siguiente manifiesto se modifica el manifiesto usado en Ejecuta una aplicación en una zona de pruebas para que se ejecute como un pod regular en un nodo con pods de zona de pruebas, para esto, se quita la runtimeClass y se agrega el taint y la tolerancia descritos antes.

# httpd-no-sandbox.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpd-no-sandbox
  labels:
    app: httpd
spec:
  replicas: 1
  selector:
    matchLabels:
      app: httpd
  template:
    metadata:
      labels:
        app: httpd
    spec:
      containers:
      - name: httpd
        image: httpd
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: sandbox.gke.io/runtime
                operator: In
                values:
                - gvisor
      tolerations:
        - effect: NoSchedule
          key: sandbox.gke.io/runtime
          operator: Equal
          value: gvisor

Primero, verifica que el objeto Deployment no se ejecute en una zona de pruebas:

kubectl get pods -o jsonpath=$'{range .items[*]}{.metadata.name}: {.spec.runtimeClassName}\n{end}'

El resultado es similar a lo siguiente:

httpd-db5899bc9-dk7lk: gvisor
httpd-no-sandbox-5bf87996c6-cfmmd:

El Deployment httpd que se creó antes se ejecuta en una zona de pruebas, porque su runtimeClass es gvisor. La implementación httpd-no-sandbox no tiene valor para runtimeClass, por lo que no está en ejecución en una zona de pruebas.

A continuación, comprueba que la implementación sin zona de pruebas se ejecute en un nodo con GKE Sandbox a través de la ejecución del siguiente comando:

kubectl get pod -o jsonpath=$'{range .items[*]}{.metadata.name}: {.spec.nodeName}\n{end}'

El nombre del grupo de nodos está incorporado en el valor de nodeName. Verifica que el pod se ejecute en un nodo de un grupo de nodos con GKE Sandbox habilitado.

Verifica la protección de metadatos

Para validar la afirmación de que los metadatos están protegidos de los nodos que pueden ejecutar pods de zona de pruebas, puedes realizar una prueba:

Crea una implementación de zona de pruebas del siguiente manifiesto con kubectl apply -f. Usa la imagen fedora, que incluye el comando curl. El pod ejecuta el comando /bin/sleep para garantizar que la implementación se ejecute durante 10,000 segundos.

# sandbox-metadata-test.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: fedora
  labels:
    app: fedora
spec:
  replicas: 1
  selector:
    matchLabels:
      app: fedora
  template:
    metadata:
      labels:
        app: fedora
    spec:
      runtimeClassName: gvisor
      containers:
      - name: fedora
        image: fedora
        command: ["/bin/sleep","10000"]

Obtén el nombre del pod con kubectl get pods y, luego, usa kubectl exec para conectarte al pod de manera interactiva.
```
kubectl exec -it POD_NAME /bin/sh
```
Estás conectado a un contenedor que se ejecuta en el pod, en una sesión /bin/sh.
Dentro de la sesión interactiva, intenta acceder a una URL que muestre metadatos de clúster:
```
curl -s "http://169.254.169.254/computeMetadata/v1/instance/attributes/kube-env" -H "Metadata-Flavor: Google"
```
El comando se cuelga y, por último, se agota el tiempo de espera, porque los paquetes se descartan en silencio.
Presiona Ctrl+C para terminar el comando curl y escribe exit para desconectarte del pod.
Quita la línea RuntimeClass del manifiesto YAML y vuelve a implementar el pod con kubectl apply -f FILENAME. El pod de zona de pruebas se termina y se vuelve a crear en un nodo sin GKE Sandbox.
Obtén el nombre de pod nuevo, conéctate a él con kubectl exec y vuelve a ejecutar el comando curl. Esta vez, se muestran resultados. Este resultado de ejemplo está truncado.
```
ALLOCATE_NODE_CIDRS: "true"
API_SERVER_TEST_LOG_LEVEL: --v=3
AUTOSCALER_ENV_VARS: kube_reserved=cpu=60m,memory=960Mi,ephemeral-storage=41Gi;...
...
```
Escribe exit para desconectarte del pod.
Quita la implementación:
```
kubectl delete deployment fedora
```

Inhabilita GKE Sandbox

No puedes inhabilitar GKE Sandbox en clústeres de GKE Autopilot ni en grupos de nodos de GKE Standard. Si quieres dejar de usar GKE Sandbox, borra el grupo de nodos.

¿Qué sigue?

Obtén más información sobre cómo administrar grupos de nodos.
Lee la descripción general de seguridad.

Endurece el aislamiento de las cargas de trabajo con GKE Sandbox Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

Habilita GKE Sandbox

Antes de comenzar

Habilita GKE Sandbox en un clúster Standard nuevo

Console

gcloud

Habilita GKE Sandbox en un clúster Standard existente

Console

gcloud

Opcional: Habilita la supervisión y el registro

Usa GKE Sandbox en Autopilot y Standard

Ejecuta una aplicación en una zona de pruebas

Ejecuta un Pod con aceleradores en GKE Sandbox

Ejecuta un Pod regular junto con Pods de zona de pruebas

Verifica la protección de metadatos

Inhabilita GKE Sandbox

¿Qué sigue?

Endurece el aislamiento de las cargas de trabajo con GKE Sandbox