Cuestionario de ubicación de workloads de EKS Hybrid Nodes
Documento relacionado: Workload Placement
Preguntas de opción múltiple
1. ¿Cuál NO es un método usado para ubicar Pods en nodos específicos en Kubernetes?
A. nodeSelector B. Node Affinity C. Taints/Tolerations D. PodDisruptionBudget
Mostrar respuesta
Respuesta: D. PodDisruptionBudget
Explicación: PodDisruptionBudget (PDB) se usa para garantizar una disponibilidad mínima durante interrupciones voluntarias, no para la ubicación de Pods.
Métodos de ubicación de Pods:
- nodeSelector: Selección simple de nodos basada en labels
- Node Affinity: Selección compleja de nodos basada en reglas
- Taints/Tolerations: Restringen los nodos para aceptar solo Pods específicos
- Pod Affinity/Anti-Affinity: Definen relaciones de ubicación entre Pods
# nodeSelector example
spec:
nodeSelector:
location: onprem
# Node Affinity example
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: gpu
operator: In
values: ["nvidia-a100"]2. ¿Cuál es el comando correcto para establecer un Taint en Hybrid Nodes de modo que solo se ubiquen allí workloads de GPU?
A. kubectl label node hybrid-node-1 gpu=true B. kubectl taint node hybrid-node-1 dedicated=gpu:NoSchedule C. kubectl annotate node hybrid-node-1 gpu=nvidia D. kubectl cordon hybrid-node-1
Mostrar respuesta
Respuesta: B. kubectl taint node hybrid-node-1 dedicated=gpu:NoSchedule
Explicación: Los Taints restringen la programación solo a Pods que toleran el taint.
# Set Taint
kubectl taint node hybrid-node-1 dedicated=gpu:NoSchedule
# Verify Taint
kubectl describe node hybrid-node-1 | grep Taints# Toleration that allows the Taint
apiVersion: v1
kind: Pod
metadata:
name: gpu-workload
spec:
tolerations:
- key: "dedicated"
operator: "Equal"
value: "gpu"
effect: "NoSchedule"
containers:
- name: cuda-app
image: nvidia/cuda:12.0-runtime
resources:
limits:
nvidia.com/gpu: 1Tipos de efecto de Taint:
- NoSchedule: Impide la programación de nuevos Pods
- PreferNoSchedule: Evita la programación si es posible
- NoExecute: También desaloja Pods existentes
3. En una estrategia de cloud bursting, ¿qué método se usa para mover workloads a nodos de cloud cuando los recursos on-premises son insuficientes?
A. Eliminar y volver a crear Pods manualmente B. Usar preferredDuringSchedulingIgnoredDuringExecution de Node Affinity C. Ubicar todos los Pods en cloud D. Eliminar y volver a crear el cluster
Mostrar respuesta
Respuesta: B. Usar preferredDuringSchedulingIgnoredDuringExecution de Node Affinity
Explicación: Cloud bursting implementa una estrategia de preferencia on-premises y respaldo en cloud.
apiVersion: apps/v1
kind: Deployment
metadata:
name: burst-workload
spec:
replicas: 10
template:
spec:
affinity:
nodeAffinity:
# Prefer on-premises (not required)
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
preference:
matchExpressions:
- key: location
operator: In
values: ["onprem"]
- weight: 50
preference:
matchExpressions:
- key: location
operator: In
values: ["cloud"]
containers:
- name: app
image: myapp:v1Patrón de cloud bursting:
[On-premises capacity: 8 nodes] [Cloud capacity: Unlimited]
| Preferred | Fallback
Pods 1-8 placed -----------------> Pods 9+ overflow4. ¿Qué significa maxSkew al usar TopologySpreadConstraints para distribuir Pods uniformemente entre zonas?
A. Conteo mínimo de Pods B. Diferencia máxima en el conteo de Pods entre zonas C. Conteo total de Pods D. Máximo de Pods por nodo
Mostrar respuesta
Respuesta: B. Diferencia máxima en el conteo de Pods entre zonas
Explicación:maxSkew define el desequilibrio máximo en el conteo de Pods entre dominios de topología (por ejemplo, zonas).
apiVersion: apps/v1
kind: Deployment
metadata:
name: distributed-app
spec:
replicas: 6
template:
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app: distributed-appEjemplo de maxSkew=1:
Zone A: 2 Pods | Zone B: 2 Pods | Zone C: 2 Pods (Balanced)
Zone A: 3 Pods | Zone B: 2 Pods | Zone C: 2 Pods (Skew=1, Allowed)
Zone A: 4 Pods | Zone B: 2 Pods | Zone C: 2 Pods (Skew=2, Not Allowed)Opciones de whenUnsatisfiable:
- DoNotSchedule: Rechaza la programación si se infringe la restricción
- ScheduleAnyway: Programa incluso si se infringe la restricción (mejor esfuerzo)
5. ¿Cómo ubicas Pods en nodos donde residen los datos por consideraciones de localidad de datos?
A. Programación aleatoria B. Usar labels de nodo y nodeSelector para ubicación por proximidad a los datos C. Seleccionar siempre nodos de cloud D. Orden alfabético del nombre del Pod
Mostrar respuesta
Respuesta: B. Usar labels de nodo y nodeSelector para ubicación por proximidad a los datos
Explicación: Para la localidad de datos, etiqueta los nodos donde se almacenan los datos y ubica los Pods usando esos labels.
# Label nodes with data location
kubectl label node storage-node-1 data-location=primary-storage
kubectl label node storage-node-2 data-location=replica-storageapiVersion: apps/v1
kind: Deployment
metadata:
name: data-processor
spec:
template:
spec:
nodeSelector:
data-location: primary-storage
containers:
- name: processor
image: data-processor:v1
volumeMounts:
- name: local-data
mountPath: /data
volumes:
- name: local-data
hostPath:
path: /mnt/dataBeneficios de la localidad de datos:
- Minimiza la latencia de red
- Reduce los costos de transferencia de datos
- Mejora el rendimiento de procesamiento
6. ¿Por qué usar Pod Anti-Affinity para evitar que los Pods de la misma aplicación se ubiquen en el mismo nodo?
A. Ahorro de costos B. Alta disponibilidad y aislamiento de fallas C. Mejora de la velocidad de red D. Ahorro de almacenamiento
Mostrar respuesta
Respuesta: B. Alta disponibilidad y aislamiento de fallas
Explicación: Pod Anti-Affinity distribuye Pods de la misma aplicación entre distintos nodos para mantener la disponibilidad del servicio incluso durante fallas de un solo nodo.
apiVersion: apps/v1
kind: Deployment
metadata:
name: ha-webapp
spec:
replicas: 3
template:
metadata:
labels:
app: ha-webapp
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values: ["ha-webapp"]
topologyKey: kubernetes.io/hostname
containers:
- name: web
image: nginx:1.25Resultado:
Node 1: ha-webapp-pod-1
Node 2: ha-webapp-pod-2
Node 3: ha-webapp-pod-3
(Only 1 placed per node)Si un nodo falla, solo se ve afectado 1 Pod, y los 2 restantes continúan proporcionando servicio.