diciembre 21, 2025
15 min de lectura

Preguntas para Entrevistas de Ingeniero DevOps Senior: Guía Completa

interview
career-advice
job-search
Preguntas para Entrevistas de Ingeniero DevOps Senior: Guía Completa
Milad Bonakdar

Milad Bonakdar

Autor

Domina conceptos avanzados de DevOps con preguntas de entrevista exhaustivas que abarcan Kubernetes, Terraform, arquitectura en la nube, GitOps, seguridad, prácticas SRE y alta disponibilidad para ingenieros DevOps senior.


Introducción

Se espera que los ingenieros sénior de DevOps diseñen infraestructuras escalables, implementen automatización avanzada, garanticen la seguridad y el cumplimiento, e impulsen la cultura DevOps en todas las organizaciones. Este rol exige una profunda experiencia en la orquestación de contenedores, la infraestructura como código, la arquitectura en la nube y la ingeniería de la fiabilidad del sitio (SRE).

Esta guía exhaustiva cubre las preguntas esenciales de la entrevista para los ingenieros sénior de DevOps, centrándose en conceptos avanzados, sistemas de producción y pensamiento estratégico. Cada pregunta incluye explicaciones detalladas y ejemplos prácticos.


Kubernetes Avanzado

1. Explique la arquitectura de Kubernetes y el rol de los componentes clave.

Respuesta: Kubernetes sigue una arquitectura maestro-trabajador:

Componentes del Plano de Control:

  • API Server: Frontend para el plano de control de Kubernetes, gestiona todas las peticiones REST
  • etcd: Almacén de clave-valor distribuido para el estado del clúster
  • Scheduler: Asigna pods a nodos basándose en los requisitos de recursos
  • Controller Manager: Ejecuta procesos de controlador (replicación, endpoints, etc.)
  • Cloud Controller Manager: Se integra con las APIs del proveedor de la nube

Componentes del Nodo:

  • kubelet: Agente que asegura que los contenedores se están ejecutando en pods
  • kube-proxy: Mantiene las reglas de red para la comunicación del pod
  • Container Runtime: Ejecuta contenedores (Docker, containerd, CRI-O)
Loading diagram...

Cómo funciona:

  1. El usuario envía la implementación a través de kubectl
  2. API Server valida y almacena en etcd
  3. Scheduler asigna pods a nodos
  4. kubelet en el nodo crea contenedores
  5. kube-proxy configura la red

Frecuencia: Muy Común Dificultad: Difícil


2. ¿Cómo se soluciona un pod atascado en CrashLoopBackOff?

Respuesta: Enfoque de depuración sistemático:

# 1. Comprobar el estado y los eventos del pod
kubectl describe pod <nombre-del-pod>
# Buscar: Errores de extracción de imágenes, límites de recursos, comprobaciones de salud fallidas

# 2. Comprobar los logs
kubectl logs <nombre-del-pod>
kubectl logs <nombre-del-pod> --previous  # Logs del contenedor anterior

# 3. Comprobar las restricciones de recursos
kubectl top pod <nombre-del-pod>
kubectl describe node <nombre-del-nodo>

# 4. Comprobar las sondas de liveness/readiness
kubectl get pod <nombre-del-pod> -o yaml | grep -A 10 livenessProbe

# 5. Ejecutar dentro del contenedor (si se mantiene activo brevemente)
kubectl exec -it <nombre-del-pod> -- /bin/sh

# 6. Comprobar la imagen
kubectl get pod <nombre-del-pod> -o jsonpath='{.spec.containers[*].image}'
docker pull <imagen>  # Probar localmente

# 7. Comprobar ConfigMaps/Secrets
kubectl get configmap
kubectl get secret

# 8. Revisar la especificación de la implementación/pod
kubectl get deployment <nombre-de-la-implementacion> -o yaml

Causas comunes:

  • La aplicación falla al inicio
  • Faltan variables de entorno
  • Configuración incorrecta de la sonda de liveness
  • Recursos insuficientes (OOMKilled)
  • Errores de extracción de imágenes
  • Faltan dependencias

Ejemplo de corrección:

# Aumentar los límites de recursos
resources:
  limits:
    memory: "512Mi"
    cpu: "500m"
  requests:
    memory: "256Mi"
    cpu: "250m"

# Ajustar el tiempo de la sonda
livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 30  # Dar tiempo a la app para que arranque
  periodSeconds: 10
  failureThreshold: 3

Frecuencia: Muy Común Dificultad: Media


3. Explique la red de Kubernetes: Services, Ingress y Network Policies.

Respuesta: Capas de red de Kubernetes:

Services: Tipos de exposición de servicios:

# ClusterIP (solo interno)
apiVersion: v1
kind: Service
metadata:
  name: backend
spec:
  type: ClusterIP
  selector:
    app: backend
  ports:
    - port: 80
      targetPort: 8080

# NodePort (acceso externo a través de la IP del nodo)
spec:
  type: NodePort
  ports:
    - port: 80
      targetPort: 8080
      nodePort: 30080

# LoadBalancer (balanceador de carga en la nube)
spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 8080

Ingress: Enrutamiento HTTP/HTTPS:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /v1
        pathType: Prefix
        backend:
          service:
            name: api-v1
            port:
              number: 80
      - path: /v2
        pathType: Prefix
        backend:
          service:
            name: api-v2
            port:
              number: 80
  tls:
  - hosts:
    - api.example.com
    secretName: api-tls

Network Policies: Controlar la comunicación pod-a-pod:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: database
    ports:
    - protocol: TCP
      port: 5432

Frecuencia: Muy Común Dificultad: Difícil


4. ¿Cómo implementa el autoescalado en Kubernetes?

Respuesta: Múltiples estrategias de autoescalado:

Horizontal Pod Autoscaler (HPA):

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 50
        periodSeconds: 60
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
      - type: Percent
        value: 100
        periodSeconds: 15

Vertical Pod Autoscaler (VPA):

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: app-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app
  updatePolicy:
    updateMode: "Auto"  # or "Recreate", "Initial", "Off"
  resourcePolicy:
    containerPolicies:
    - containerName: app
      minAllowed:
        cpu: 100m
        memory: 128Mi
      maxAllowed:
        cpu: 2
        memory: 2Gi

Cluster Autoscaler: Ajusta automáticamente el tamaño del clúster basándose en los pods pendientes:

# Ejemplo de AWS
apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-autoscaler-config
data:
  min-nodes: "2"
  max-nodes: "10"
  scale-down-delay-after-add: "10m"
  scale-down-unneeded-time: "10m"

Frecuencia: Común Dificultad: Media


Terraform Avanzado

5. Explique la gestión del estado de Terraform y las mejores prácticas.

Respuesta: El estado de Terraform rastrea la infraestructura y es fundamental para las operaciones.

Configuración del Estado Remoto:

# backend.tf
terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-locks"
  }
}

Bloqueo de Estado:

# Tabla DynamoDB para el bloqueo de estado
resource "aws_dynamodb_table" "terraform_locks" {
  name         = "terraform-locks"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "LockID"

  attribute {
    name = "LockID"
    type = "S"
  }
}

Mejores Prácticas:

1. Nunca subas archivos de estado a Git

# .gitignore
*.tfstate
*.tfstate.*
.terraform/

2. Usa workspaces para entornos

terraform workspace new dev
terraform workspace new staging
terraform workspace new prod

terraform workspace select dev
terraform apply

3. Importa recursos existentes

# Importar una instancia EC2 existente
terraform import aws_instance.web i-1234567890abcdef0

# Verificar
terraform plan

4. Manipulación del estado (usar con cuidado)

# Listar los recursos en el estado
terraform state list

# Mostrar un recurso específico
terraform state show aws_instance.web

# Mover un recurso en el estado
terraform state mv aws_instance.old aws_instance.new

# Eliminar un recurso del estado (no lo borra)
terraform state rm aws_instance.web

5. Hacer una copia de seguridad del estado antes de grandes cambios

terraform state pull > backup.tfstate

Frecuencia: Muy Común Dificultad: Difícil


6. ¿Cómo estructura el código de Terraform para grandes proyectos?

Respuesta: Estructura modular para la mantenibilidad:

Estructura de Directorios:

terraform/
├── environments/
│   ├── dev/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   ├── terraform.tfvars
│   │   └── backend.tf
│   ├── staging/
│   └── prod/
├── modules/
│   ├── vpc/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   ├── outputs.tf
│   │   └── README.md
│   ├── eks/
│   ├── rds/
│   └── s3/
└── global/
    ├── iam/
    └── route53/

Ejemplo de Módulo:

# modules/vpc/main.tf
resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = merge(
    var.tags,
    {
      Name = "${var.environment}-vpc"
    }
  )
}

resource "aws_subnet" "private" {
  count             = length(var.private_subnet_cidrs)
  vpc_id            = aws_vpc.main.id
  cidr_block        = var.private_subnet_cidrs[count.index]
  availability_zone = var.availability_zones[count.index]

  tags = merge(
    var.tags,
    {
      Name = "${var.environment}-private-${count.index + 1}"
      Type = "private"
    }
  )
}

# modules/vpc/variables.tf
variable "vpc_cidr" {
  description = "Bloque CIDR para VPC"
  type        = string
}

variable "environment" {
  description = "Nombre del entorno"
  type        = string
}

variable "private_subnet_cidrs" {
  description = "Bloques CIDR para subredes privadas"
  type        = list(string)
}

variable "availability_zones" {
  description = "Zonas de disponibilidad"
  type        = list(string)
}

variable "tags" {
  description = "Tags comunes"
  type        = map(string)
  default     = {}
}

# modules/vpc/outputs.tf
output "vpc_id" {
  value = aws_vpc.main.id
}

output "private_subnet_ids" {
  value = aws_subnet.private[*].id
}

Usando Módulos:

# environments/prod/main.tf
module "vpc" {
  source = "../../modules/vpc"

  vpc_cidr             = "10.0.0.0/16"
  environment          = "prod"
  private_subnet_cidrs = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  availability_zones   = ["us-east-1a", "us-east-1b", "us-east-1c"]

  tags = {
    Project   = "MyApp"
    ManagedBy = "Terraform"
  }
}

module "eks" {
  source = "../../modules/eks"

  cluster_name    = "prod-cluster"
  vpc_id          = module.vpc.vpc_id
  subnet_ids      = module.vpc.private_subnet_ids
  node_group_size = 3
}

Frecuencia: Común Dificultad: Difícil


Arquitectura en la Nube

7. Diseñe una arquitectura multi-región de alta disponibilidad en AWS.

Respuesta: Arquitectura multi-región para alta disponibilidad:

Loading diagram...

Componentes Clave:

1. DNS y Gestión del Tráfico:

# Route 53 con comprobaciones de salud
resource "aws_route53_health_check" "primary" {
  fqdn              = "api.example.com"
  port              = 443
  type              = "HTTPS"
  resource_path     = "/health"
  failure_threshold = 3
  request_interval  = 30
}

resource "aws_route53_record" "api" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "api.example.com"
  type    = "A"

  failover_routing_policy {
    type = "PRIMARY"
  }

  set_identifier = "primary"
  health_check_id = aws_route53_health_check.primary.id

  alias {
    name                   = aws_lb.primary.dns_name
    zone_id                = aws_lb.primary.zone_id
    evaluate_target_health = true
  }
}

2. Replicación de la Base de Datos:

# RDS con réplica de lectura entre regiones
resource "aws_db_instance" "primary" {
  identifier           = "prod-db-primary"
  engine               = "postgres"
  instance_class       = "db.r5.xlarge"
  multi_az             = true
  backup_retention_period = 7

  provider = aws.us-east-1
}

resource "aws_db_instance" "replica" {
  identifier             = "prod-db-replica"
  replicate_source_db    = aws_db_instance.primary.arn
  instance_class         = "db.r5.xlarge"
  auto_minor_version_upgrade = false

  provider = aws.us-west-2
}

3. Replicación de Datos:

# Replicación S3 entre regiones
resource "aws_s3_bucket_replication_configuration" "replication" {
  bucket = aws_s3_bucket.source.id
  role   = aws_iam_role.replication.arn

  rule {
    id     = "replicate-all"
    status = "Enabled"

    destination {
      bucket        = aws_s3_bucket.destination.arn
      storage_class = "STANDARD"
    }
  }
}

Principios de Diseño:

  • Configuración activa-activa o activa-pasiva
  • Failover automatizado con comprobaciones de salud
  • Replicación de datos con mínimo retardo
  • Implementación consistente entre regiones
  • Monitorización y alertas para ambas regiones

Frecuencia: Común Dificultad: Difícil


GitOps & CI/CD

8. Explique GitOps y cómo implementarlo con ArgoCD.

Respuesta: GitOps utiliza Git como la única fuente de verdad para la infraestructura y las aplicaciones declarativas.

Principios:

  1. Configuración declarativa en Git
  2. Sincronización automatizada
  3. Control de versiones para todos los cambios
  4. Reconciliación continua

Implementación de ArgoCD:

# Manifiesto de la aplicación
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/org/app-manifests
    targetRevision: main
    path: k8s/overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
      allowEmpty: false
    syncOptions:
    - CreateNamespace=true
    retry:
      limit: 5
      backoff:
        duration: 5s
        factor: 2
        maxDuration: 3m

Estructura de Directorios:

app-manifests/
├── base/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── kustomization.yaml
└── overlays/
    ├── dev/
    │   ├── kustomization.yaml
    │   └── patches/
    ├── staging/
    └── production/
        ├── kustomization.yaml
        ├── replicas.yaml
        └── resources.yaml

Kustomization:

# overlays/production/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

bases:
- ../../base

replicas:
- name: myapp
  count: 5

resources:
- ingress.yaml

patches:
- path: resources.yaml
  target:
    kind: Deployment
    name: myapp

Beneficios:

  • Git como registro de auditoría
  • Rollbacks fáciles (git revert)
  • Estado deseado declarativo
  • Detección automatizada de la desviación
  • Gestión multi-clúster

Frecuencia: Común Dificultad: Media


Seguridad & Cumplimiento

9. ¿Cómo implementa las mejores prácticas de seguridad en Kubernetes?

Respuesta: Enfoque de seguridad multi-capa:

1. Pod Security Standards:

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

2. RBAC (Control de Acceso Basado en Roles):

# Rol para desarrolladores
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: developer
rules:
- apiGroups: ["", "apps"]
  resources: ["pods", "deployments", "services"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["pods/log"]
  verbs: ["get"]

# RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-binding
  namespace: production
subjects:
- kind: Group
  name: developers
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer
  apiGroup: rbac.authorization.k8s.io

3. Network Policies:

# Denegar por defecto todo el ingreso
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress

4. Gestión de Secretos:

# External Secrets Operator
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: app-secrets
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: SecretStore
  target:
    name: app-secrets
    creationPolicy: Owner
  data:
  - secretKey: database-password
    remoteRef:
      key: prod/database
      property: password

5. Security Context:

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 2000
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    image: myapp:1.0
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
        - ALL
    volumeMounts:
    - name: tmp
      mountPath: /tmp
  volumes:
  - name: tmp
    emptyDir: {}

6. Image Scanning:

# Controlador de admisión con OPA
apiVersion: v1
kind: ConfigMap
metadata:
  name: opa-policy
data:
  policy.rego: |
    package kubernetes.admission
    
    deny[msg] {
      input.request.kind.kind == "Pod"
      image := input.request.object.spec.containers[_].image
      not startswith(image, "registry.company.com/")
      msg := sprintf("La imagen %v no es de un registro aprobado", [image])
    }

Frecuencia: Muy Común Dificultad: Difícil


Observabilidad & SRE

10. Diseñe una pila de observabilidad integral.

Respuesta: Tres pilares de la observabilidad: Métricas, Logs, Trazas

Arquitectura:

Loading diagram...

1. Métricas (Prometheus + Grafana):

# ServiceMonitor para métricas de la app
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: app-metrics
spec:
  selector:
    matchLabels:
      app: myapp
  endpoints:
  - port: metrics
    interval: 30s
    path: /metrics

2. Logging (Loki):

# Configuración de Promtail para la recolección de logs
apiVersion: v1
kind: ConfigMap
metadata:
  name: promtail-config
data:
  promtail.yaml: |
    server:
      http_listen_port: 9080
    
    clients:
      - url: http://loki:3100/loki/api/v1/push
    
    scrape_configs:
      - job_name: kubernetes-pods
        kubernetes_sd_configs:
          - role: pod
        relabel_configs:
          - source_labels: [__meta_kubernetes_pod_label_app]
            target_label: app
          - source_labels: [__meta_kubernetes_namespace]
            target_label: namespace

3. Tracing (Jaeger):

# Instrumentación de la aplicación
from opentelemetry import trace
from opentelemetry.exporter.jaeger.thrift import JaegerExporter
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor

# Configurar el tracing
trace.set_tracer_provider(TracerProvider())
jaeger_exporter = JaegerExporter(
    agent_host_name="jaeger-agent",
    agent_port=6831,
)
trace.get_tracer_provider().add_span_processor(
    BatchSpanProcessor(jaeger_exporter)
)

tracer = trace.get_tracer(__name__)

# Usar en el código
with tracer.start_as_current_span("process_request"):
    # Tu código aquí
    pass

4. Reglas de Alerta:

# PrometheusRule
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: app-alerts
spec:
  groups:
  - name: app
    interval: 30s
    rules:
    - alert: HighErrorRate
      expr: |
        sum(rate(http_requests_total{status=~"5.."}[5m]))
        /
        sum(rate(http_requests_total[5m]))
        > 0.05
      for: 5m
      labels:
        severity: critical
      annotations:
        summary: "Tasa de error alta detectada"
        description: "La tasa de error es {{ $value | humanizePercentage }}"
    
    - alert: HighLatency
      expr: |
        histogram_quantile(0.95,
          rate(http_request_duration_seconds_bucket[5m])
        ) > 1
      for: 10m
      labels:
        severity: warning
      annotations:
        summary: "Latencia alta detectada"

5. Monitorización de SLO:

# Definición de SLO
apiVersion: sloth.slok.dev/v1
kind: PrometheusServiceLevel
metadata:
  name: api-availability
spec:
  service: "api"
  labels:
    team: "platform"
  slos:
    - name: "requests-availability"
      objective: 99.9
      description: "Las peticiones a la API deberían tener éxito"
      sli:
        events:
          errorQuery: sum(rate(http_requests_total{status=~"5.."}[{{.window}}]))
          totalQuery: sum(rate(http_requests_total[{{.window}}]))
      alerting:
        pageAlert:
          labels:
            severity: critical
        ticketAlert:
          labels:
            severity: warning

Frecuencia: Común Dificultad: Difícil


Disaster Recovery

11. ¿Cómo implementa la recuperación ante desastres para un clúster de Kubernetes?

Respuesta: Estrategia integral de DR:

1. Estrategia de Backup:

# Planificación de backup de Velero
apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: daily-backup
  namespace: velero
spec:
  schedule: "0 2 * * *"  # 2 AM diario
  template:
    includedNamespaces:
    - production
    - staging
    excludedResources:
    - events
    - events.events.k8s.io
    storageLocation: aws-s3
    volumeSnapshotLocations:
    - aws-ebs
    ttl: 720h  # 30 días

2. Backup de etcd:

#!/bin/bash
# Script automatizado de backup de etcd

ETCDCTL_API=3 etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save /backup/etcd-snapshot-$(date +%Y%m%d-%H%M%S).db

# Subir a S3
aws s3 cp /backup/etcd-snapshot-*.db s3://etcd-backups/

# Limpiar backups antiguos
find /backup -name "etcd-snapshot-*.db" -mtime +7 -delete

3. Procedimiento de Restauración:

# Restaurar etcd desde la snapshot
ETCDCTL_API=3 etcdctl snapshot restore snapshot.db \
  --data-dir=/var/lib/etcd-restore \
  --initial-cluster=etcd-0=https://10.0.1.10:2380 \
  --initial-advertise-peer-urls=https://10.0.1.10:2380

# Restaurar la aplicación con Velero
velero restore create --from-backup daily-backup-20231125
velero restore describe <nombre-de-la-restauracion>

4. Failover Multi-Región:

# Terraform para configuración multi-región
module "primary_cluster" {
  source = "./modules/eks"
  region = "us-east-1"
  # ... configuración
}

module "dr_cluster" {
  source = "./modules/eks"
  region = "us-west-2"
  # ... configuración
}

# Comprobación de salud y failover de Route 53
resource "aws_route53_health_check" "primary" {
  fqdn              = module.primary_cluster.endpoint
  port              = 443
  type              = "HTTPS"
  resource_path     = "/healthz"
  failure_threshold = 3
}

5. Objetivos RTO/RPO:

  • RTO (Recovery Time Objective): < 1 hora
  • RPO (Recovery Point Objective): < 15 minutos
  • Simulacros de DR regulares (mensuales)
  • Runbooks documentados
  • Failover automatizado donde sea posible

Frecuencia: Común Dificultad: Difícil


Service Mesh

12. Explique la arquitectura de service mesh y cuándo usarla.

Respuesta: Un service mesh proporciona una capa de infraestructura para la comunicación servicio-a-servicio.

Componentes Centrales:

Loading diagram...

Implementación de Istio:

# Virtual Service para el enrutamiento del tráfico
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 80
    - destination:
        host: reviews
        subset: v2
      weight: 20

# Destination Rule
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  trafficPolicy:
    loadBalancer:
Newsletter subscription

Consejos de carrera semanales que realmente funcionan

Recibe las últimas ideas directamente en tu bandeja de entrada

Crea un Currículum que Te Contrate 60% Más Rápido

En minutos, crea un currículum personalizado y compatible con ATS que ha demostrado conseguir 6 veces más entrevistas.

Crea un mejor currículum

Compartir esta publicación

Supera la Tasa de Rechazo del 75% de los ATS

3 de cada 4 currículums nunca llegan a un ojo humano. Nuestra optimización de palabras clave aumenta tu tasa de aprobación hasta en un 80%, asegurando que los reclutadores realmente vean tu potencial.