← Volver al listado de tecnologías ← Índice de K3s

Capitulo 20: Tips de Produccion

Por: Artiko
k3skubernetesproduccionbackupautoscaling

Capitulo 20: Tips de Produccion

< Volver al Indice del Tutorial

Backup y Restore de etcd

Los backups son la red de seguridad de tu cluster. Sin ellos, una falla catastrofica significa reconstruir todo desde cero.

Crear Snapshots

# Snapshot manual
k3s etcd-snapshot save --name backup-pre-actualizacion

# Listar snapshots existentes
k3s etcd-snapshot list

Por defecto, K3s crea snapshots automaticos cada 12 horas y retiene los ultimos 5. Puedes configurar esto:

# En /etc/rancher/k3s/config.yaml
etcd-snapshot-schedule-cron: "0 */6 * * *"  # Cada 6 horas
etcd-snapshot-retention: 10                  # Retener 10 snapshots
etcd-snapshot-dir: /mnt/backups/etcd         # Directorio personalizado

Restaurar desde Snapshot

# Detener K3s
sudo systemctl stop k3s

# Restaurar (resetea el cluster al estado del snapshot)
k3s server --cluster-reset \
  --cluster-reset-restore-path=/var/lib/rancher/k3s/server/db/snapshots/NOMBRE-SNAPSHOT

# Reiniciar K3s
sudo systemctl start k3s

En un cluster HA, despues de restaurar en un server, los demas servers deben unirse nuevamente.

Actualizaciones de K3s

Actualizacion Manual

# Verificar version actual
k3s --version

# Actualizar (reinstalar con la nueva version)
curl -sfL https://get.k3s.io | sh -

# Para una version especifica
curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION=v1.30.0+k3s1 sh -

Actualiza primero los servers, luego los agents. En clusters HA, actualiza un server a la vez.

System Upgrade Controller

Para actualizaciones automaticas y controladas, usa el system-upgrade-controller de Rancher:

# Instalar el controlador
kubectl apply -f https://github.com/rancher/system-upgrade-controller/releases/latest/download/system-upgrade-controller.yaml

Crear planes de actualizacion:

apiVersion: upgrade.cattle.io/v1
kind: Plan
metadata:
  name: server-plan
  namespace: system-upgrade
spec:
  concurrency: 1
  cordon: true
  nodeSelector:
    matchExpressions:
      - key: node-role.kubernetes.io/control-plane
        operator: Exists
  serviceAccountName: system-upgrade
  upgrade:
    image: rancher/k3s-upgrade
  channel: https://update.k3s.io/v1-release/channels/stable
---
apiVersion: upgrade.cattle.io/v1
kind: Plan
metadata:
  name: agent-plan
  namespace: system-upgrade
spec:
  concurrency: 2
  cordon: true
  nodeSelector:
    matchExpressions:
      - key: node-role.kubernetes.io/control-plane
        operator: DoesNotExist
  prepare:
    args: ["prepare", "server-plan"]
    image: rancher/k3s-upgrade
  serviceAccountName: system-upgrade
  upgrade:
    image: rancher/k3s-upgrade
  channel: https://update.k3s.io/v1-release/channels/stable

El agent-plan espera a que el server-plan termine antes de actualizar los agents.

Resource Limits y Requests

Siempre define resources en tus pods. Sin limits, un pod puede consumir todos los recursos del nodo y afectar a los demas.

containers:
  - name: app
    image: mi-app:1.0
    resources:
      requests:
        cpu: 100m
        memory: 128Mi
      limits:
        cpu: 500m
        memory: 512Mi

LimitRange por Namespace

Aplica defaults automaticamente a pods que no definen resources:

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
  namespace: produccion
spec:
  limits:
    - default:
        cpu: 500m
        memory: 256Mi
      defaultRequest:
        cpu: 100m
        memory: 128Mi
      type: Container

ResourceQuota por Namespace

Limita el consumo total de un namespace:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: quota
  namespace: staging
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi
    pods: "20"

Horizontal Pod Autoscaler (HPA)

Escala automaticamente el numero de replicas basandose en metricas de CPU o memoria.

Prerequisito: Metrics Server

K3s incluye metrics-server por defecto. Verifica que funciona:

kubectl top nodes
kubectl top pods

Crear HPA

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-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

Cuando el uso promedio de CPU supera 70% o memoria supera 80%, HPA crea mas replicas. Cuando baja, las reduce.

Liveness y Readiness Probes

Liveness Probe

Detecta si el contenedor esta colgado. Si falla, Kubernetes reinicia el pod:

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 15
  periodSeconds: 10
  failureThreshold: 3

Readiness Probe

Detecta si el pod esta listo para recibir trafico. Si falla, el pod se remueve del Service:

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5
  failureThreshold: 3

Siempre usa ambas probes. Sin readiness probe, el trafico llega a pods que aun estan arrancando. Sin liveness probe, pods colgados siguen recibiendo trafico.

Pod Disruption Budgets

Garantizan disponibilidad durante actualizaciones y mantenimiento de nodos:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web-app-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: web-app

Con minAvailable: 2, Kubernetes no permite drenar un nodo si eso dejaria menos de 2 replicas de web-app corriendo. Esto previene downtime durante rolling updates del cluster.

Registry Privado

Para pull de imagenes desde registries privados, configura K3s con /etc/rancher/k3s/registries.yaml:

mirrors:
  docker.io:
    endpoint:
      - "https://mi-mirror.ejemplo.com"
  mi-registry.ejemplo.com:
    endpoint:
      - "https://mi-registry.ejemplo.com"

configs:
  "mi-registry.ejemplo.com":
    auth:
      username: usuario
      password: password
    tls:
      insecure_skip_verify: false

Reinicia K3s despues de modificar este archivo:

sudo systemctl restart k3s

Los agents tambien necesitan este archivo si descargan imagenes directamente.

Checklist de Produccion

Antes de considerar tu cluster listo para produccion, verifica cada punto:

Infraestructura

Monitoring y Observabilidad

Seguridad

Aplicaciones

Operaciones

Esta checklist no es exhaustiva pero cubre los fundamentos. Cada entorno tiene requisitos adicionales segun su contexto.

< Volver al Indice del Tutorial

← Volver al listado de tecnologías ← Índice de K3s