Saltar a contenido

Kubernetes

InteSys proporciona clústeres Kubernetes gestionados y consultoría experta en orquestación de contenedores. Nos encargamos del ciclo de vida del clúster, del escalado, la seguridad y las actualizaciones para que su equipo pueda concentrarse en desplegar aplicaciones.

Kubernetes Gestionado

Nuestro servicio Kubernetes gestionado se ejecuta sobre infraestructura InteSys Tier 3 con:

  • Alta disponibilidad — Plano de control multi-master distribuido entre zonas de disponibilidad
  • Actualizaciones automáticas — Actualizaciones de versión de Kubernetes con rolling updates sin downtime
  • Monitoreo integrado — Prometheus y Grafana preconfigurados para las métricas del clúster
  • Red privada — Nodos del clúster en VLANs aisladas con ingress controlado

Versiones Soportadas

Mantenemos las últimas tres versiones menores de Kubernetes. Versiones soportadas actualmente:

Versión Estado Fin de Soporte
1.31 Actual Activo
1.30 Soportada Activo
1.29 Soportada 2026-06

Estrategias de Despliegue

Deployments y Rolling Updates

El objeto Deployment estándar de Kubernetes gestiona los rolling updates automáticamente:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp
          image: registry.intesys.io/myapp:v1.2.0
          ports:
            - containerPort: 8000
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 500m
              memory: 512Mi

Siempre Defina Resource Requests y Limits

Los resource requests garantizan que su pod sea programado en un nodo con capacidad suficiente. Los limits impiden que un pod con comportamiento anómalo consuma todos los recursos del nodo y afecte a otras cargas de trabajo.

Health Probes

Kubernetes utiliza probes para determinar la salud del pod. Unos probes correctamente configurados son fundamentales para despliegues confiables.

Liveness Probe

Detecta si un pod está bloqueado y necesita ser reiniciado:

livenessProbe:
  httpGet:
    path: /health
    port: 8000
  initialDelaySeconds: 10
  periodSeconds: 15
  failureThreshold: 3

Readiness Probe

Determina si un pod está listo para recibir tráfico:

readinessProbe:
  httpGet:
    path: /ready
    port: 8000
  initialDelaySeconds: 5
  periodSeconds: 10
  failureThreshold: 2

Startup Probe

Para aplicaciones con inicialización lenta:

startupProbe:
  httpGet:
    path: /health
    port: 8000
  initialDelaySeconds: 0
  periodSeconds: 5
  failureThreshold: 30

Liveness vs Readiness

Un fallo del liveness probe reinicia el pod. Un fallo del readiness probe lo remueve del service pero lo mantiene en ejecución. Use readiness para dependencias (conectividad con la base de datos) y liveness para detectar deadlocks.

Horizontal Pod Autoscaler (HPA)

Escale pods automáticamente con base en CPU, memoria o métricas personalizadas:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80

Buenas Prácticas de Escalado

  • Defina minReplicas en al menos 2 para alta disponibilidad
  • Use PodDisruptionBudget para asegurar disponibilidad mínima durante eventos de escalado
  • Configure períodos de cooldown apropiados para evitar flapping
  • Monitoree el comportamiento del HPA con kubectl get hpa y dashboards de Grafana

Ingress y TLS

Exponga servicios externamente con ingress gestionado y TLS automático:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ingress
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  tls:
    - hosts:
        - app.example.com
      secretName: app-tls
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: myapp
                port:
                  number: 80

Buenas Prácticas de Seguridad

Práctica Implementación
Ejecutar como no-root securityContext.runAsNonRoot: true
Sistema de archivos de solo lectura securityContext.readOnlyRootFilesystem: true
Eliminar capabilities securityContext.capabilities.drop: ["ALL"]
Network policies Restrinja la comunicación entre pods
Escaneo de imágenes Escanee imágenes en CI antes del despliegue
RBAC Service accounts con privilegios mínimos

Próximos Pasos