Cómo optimizar Kubernetes en un servidor Linux: guía sencilla

Para optimizar Kubernetes en un servidor Linux, ajustar el sistema operativo (sysctl, cgroups, swap), usar un entorno de ejecución de contenedores moderno (containerd/CRI-O), configurar kubelet (reservas, desalojo, CPU/Administradores de topología), seleccione un CNI rápido (Cilium/Calico) y almacenamiento, ajuste el tamaño de las solicitudes/límites, optimice etcd y realice mediciones con monitoreo basado en SLO. Pasos y ejemplos a continuación.

Ejecutar Kubernetes es fácil; ejecutarlo de forma rápida y fiable en un servidor Linux requiere una optimización minuciosa. En esta guía, te mostraré cómo optimizar Kubernetes en servidores Linux con pasos prácticos y probados en producción que puedes aplicar hoy mismo, abarcando la optimización del kernel, la configuración de kubelet, las redes, el almacenamiento, la programación y el escalado automático.

Intención de búsqueda y lo que aprenderá

Este tutorial está dirigido a ingenieros de plataforma, DevOps y administradores de sistemas que buscan optimizar el rendimiento de Kubernetes en Linux. Recibirás una lista de verificación priorizada, la justificación de cada cambio y configuraciones fáciles de copiar y pegar. El lenguaje será accesible para principiantes, pero las técnicas reflejan la experiencia práctica en producción.

Requisitos previos y comprobaciones de referencia

• Núcleo de Linux 5.4+ (los kernels más nuevos ofrecen mejores cgroups, BPF y rendimiento de red).
• cgroups v1 o v2 compatibles con su versión de K8s y su entorno de ejecución (v2 es totalmente compatible con Kubernetes/containerd modernos).
• SSD/NVMe para etcd y almacenamiento de contenedores; XFS o ext4 formateados correctamente para overlayfs.
• Intercambio deshabilitado (a menos que configure NodeSwap explícitamente y comprenda las desventajas).
• Hora sincronizada a través de chrony/systemd-timesyncd y entropía disponible (rngd) para clústeres con uso intensivo de TLS.

Optimizar el sistema operativo Linux para Kubernetes

Ajuste recomendado de sysctl

Estas configuraciones de sysctl mejoran el seguimiento de las conexiones, el rendimiento de la red y los límites de recursos. Ajústelas a la escala de su carga de trabajo; realice pruebas antes del lanzamiento global.

# /etc/sysctl.d/99-kubernetes-tuning.conf
# Required for most CNIs using bridges
net.bridge.bridge-nf-call-iptables=1
net.bridge.bridge-nf-call-ip6tables=1

# Increase conntrack table size for high connection churn
net.netfilter.nf_conntrack_max=262144
net.netfilter.nf_conntrack_buckets=65536

# Socket buffers and backlog
net.core.rmem_max=134217728
net.core.wmem_max=134217728
net.core.somaxconn=4096
net.ipv4.tcp_max_syn_backlog=4096

# Ephemeral port range for bursty traffic
net.ipv4.ip_local_port_range=1024 65000

# ARP/Neighbor cache thresholds (large node counts)
net.ipv4.neigh.default.gc_thresh1=4096
net.ipv4.neigh.default.gc_thresh2=8192
net.ipv4.neigh.default.gc_thresh3=16384

# File watchers (fixes issues with dev tools/controllers)
fs.inotify.max_user_watches=1048576
fs.inotify.max_user_instances=1024

# Apply immediately
sudo modprobe br_netfilter
sudo sysctl --system

Deshabilitar el intercambio y alinear cgroups/systemd

• Deshabilitar Intercambiar para evitar memoria impredecible recuperar: sudo swapoff -a && sed -i '/ swap / s/^/#/' /etc/fstab.
• Utilice systemd como el controlador cgroup para kubelet y el tiempo de ejecución del contenedor para evitar la desviación en la contabilidad de recursos.

# Verify cgroup driver alignment
# containerd: SystemdCgroup = true (see next section)
# kubelet: KubeletConfiguration cgroupDriver: "systemd"

Sistema de archivos y almacenamiento de contenedores

• Utilice XFS con ftype=1 o ext4 con soporte d_type para overlayfs.
• Prefiera NVMe/SSD para almacenamiento en contenedores y etcd; montar con noatime.
• Habilite los umbrales de recolección de basura de imágenes en kubelet para evitar la presión del disco.

Elija y ajuste el tiempo de ejecución del contenedor

containerd y CRI-O son las opciones más rápidas para Kubernetes. Docker funciona mediante reemplazos de Dockershim, pero añade una capa adicional. Para la mayoría de los clústeres, containerd equilibra el rendimiento, las características y la compatibilidad con el ecosistema.

Configuración óptima de containerd

# /etc/containerd/config.toml (key excerpts)
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
  SystemdCgroup = true

[plugins."io.containerd.grpc.v1.cri"]
  sandbox_image = "registry.k8s.io/pause:3.9"

[plugins."io.containerd.grpc.v1.cri".registry]
  # Optional: private mirror/cache to speed image pulls
  [plugins."io.containerd.grpc.v1.cri".registry.mirrors."your-mirror.local"]
    endpoint = ["https://your-mirror.local"]

Reinicie containerd después de los cambios y extraiga previamente las imágenes base para implementaciones sensibles a la latencia.

Configuración a nivel de nodo y Kubelet

Mejores prácticas de configuración de Kubelet

# /var/lib/kubelet/config.yaml (key excerpts)
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cgroupDriver: systemd
evictionHard:
  "memory.available": "200Mi"
  "nodefs.available": "10%"
  "imagefs.available": "10%"
kubeReserved:
  cpu: "500m"
  memory: "1Gi"
  ephemeral-storage: "2Gi"
systemReserved:
  cpu: "250m"
  memory: "512Mi"
  ephemeral-storage: "1Gi"
imageGCHighThresholdPercent: 80
imageGCLowThresholdPercent: 60
maxPods: 110
cpuManagerPolicy: "static"           # For CPU pinning of Guaranteed pods
topologyManagerPolicy: "restricted"  # Align CPU/memory/PCIe on NUMA nodes

Usar Flujo de Aire QoS para aplicaciones críticas en cuanto a latencia: configurar CPU y la memoria solicitudes = límitesPara cargas de trabajo generales, establezca solicitudes realistas y evite valores muy bajos. CPU límites para reducir la limitación de velocidad.

Rendimiento de red: CNI, kube-proxy y MTU

Selección y ajuste de CNI

• Cilio (eBPF): Excelente rendimiento, reemplazo de kube-proxy, observabilidad avanzada.
• Calicó: Maduro, rico en políticas, buen rendimiento con IPVS; compatible con el plano de datos eBPF.
• Franela: Superposición simple, ideal para grupos pequeños, pero no la más rápida.

Ajusta la MTU a tu red. Para superposiciones VXLAN, a menudo es necesario reducir la MTU (por ejemplo, a 1450) para evitar la fragmentación. Habilita el modo IPVS de kube-proxy o utiliza la alternativa de Cilium para un mejor equilibrio de carga del servicio.

# kube-proxy in IPVS mode (excerpt for kubeadm-managed clusters)
apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: "ipvs"
ipvs:
  scheduler: "rr"

Optimización de almacenamiento y volumen

• Utilice controladores CSI Optimizado para su plataforma (EBS, Ceph, Longhorn, OpenEBS, PV locales).
• Prefiero NVMe para etcd y cargas de trabajo de alto nivel de E/S; evite el almacenamiento conectado a la red para etcd.
• Ajustar el sistema de archivos (XFS con reflink/ftype correcto, ext4 con modo de registro ordenado, noatime).
• PVC de tamaño adecuado y use LecturaEscrituraOnce siempre que sea posible para mantener la coherencia y el rendimiento.

Programación de carga de trabajo y gestión de recursos

Solicitudes, límites y clases de QoS

• Solicitudes Programar la unidad y planificar la capacidad; establecerlas en promedios realistas.
• Límites proteger los nodos, pero estricto CPU Los límites pueden provocar una limitación de CFS. Para los servicios de rendimiento, considere no CPU límite o uno superior.
• Calidad de servicio garantizada para servicios sensibles a la latencia (establecer solicitudes = límites).

Topología y conocimiento de NUMA

• Activar CPU Manager (estático) y Gerente de topología (restringido/nodo numa único) para una latencia consistente en servidores de múltiples sockets.
• Usar nodoAfinidad, podAntiAfinidad, y Restricciones de propagación de topología para reducir la contención y los puntos conflictivos.

Escalado automático que realmente funciona

El escalado automático es una garantía de rendimiento. Úselo para ajustar la capacidad a la demanda y evitar la sobrecarga de los nodos.

# Horizontal Pod Autoscaler example (CPU-based)
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 3
  maxReplicas: 30
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60

• HPA para réplicas basadas en CPU/memoria/métricas personalizadas.
• VPA para solicitudes de ajuste de tamaño (ejecutar en modo de recomendación por seguridad en aplicaciones críticas).
• Escalador automático de clúster Para agregar o eliminar nodos (o herramientas nativas del proveedor). Asegúrese de que su proveedor de nube o grupo de nodos se integre correctamente.

Ajuste del plano de control y etcd

• Especial etcd en NVMe local dedicado con baja latencia; evitar discos remotos/en red.
• Ejecute de 3 a 5 miembros etcd; más no siempre es mejor debido a la latencia del quórum.
• Establezca límites de recursos etcd adecuados; monitoree la latencia fsync de WAL y aplique actualizaciones periódicas. desfragmentación.
• Ubique los componentes del plano de control en nodos de tamaño adecuado; fije con pines. CPU/memoria si hay vecinos ruidosos.

Observabilidad y optimización basada en SLO

• Métrica: Prometheus + kube-state-metrics; monitorizar la latencia del planificador, las solicitudes del servidor API, la latencia de confirmación de etcd, contenedor CPU estrangulamiento, segundos estrangulados y señales de presión de nodo.
• Registros: Utilice fluent-bit (liviano) y habilite la rotación de registros para los registros JSON en contenedor.
• Rastreo: OpenTelemetry para visibilidad de la ruta de solicitud; invaluable para identificar problemas de red vs CPU cuellos de botella.
• Cuadros de mando: Defina SLO por servicio (latencia p95, presupuesto de error) y optimice solo lo que los impacta.

Victorias rápidas y cuellos de botella comunes

• Cambiar kube-proxy a IPVS vea la sección Cilio eBPF plano de datos.
• Alineación cgroupDriver=systemd tanto para kubelet como para containerd.
• Tamaño correcto solicitudes y eliminar las normas excesivamente estrictas CPU límites Si se observa estrangulamiento.
• Aumentar nf_conntrack_max para microservicios con gran cantidad de conexiones.
• Más Bajo MTU sobre superposiciones para evitar la fragmentación.
• Activar CPUGestor de topología para cargas de trabajo sensibles a la latencia.
• Usar NVMe para etcd y almacenamiento de contenedores; establecer umbrales de GC de imágenes.

Configuraciones de seguridad que también mejoran el rendimiento

• Usar segundo y AppArmor para reducir la superficie de ataque del kernel y la variabilidad de la sobrecarga de las llamadas al sistema.
• Elimine las capacidades innecesarias de Linux (por ejemplo, elimine NET_RAW) para limitar el riesgo y reducir la sobrecarga del manejo de paquetes en algunos casos.
• Ejecute imágenes mínimas y sin distribución para reducir la superficie de ataque y los tiempos de inicio.

Ejemplo: Poniéndolo todo junto

Para un nuevo grupo de nodos que maneja API orientadas al usuario con alta rotación de conexiones:

• Kernel/sysctl: aplique la configuración anterior, asegúrese nf_conntrack_max=262144, carga br_netfilter.
• Tiempo de ejecución: containerd con SystemdCgroup=true, espejo de registro habilitado.
• Kubelet: CPU Administrador estático, Administrador de topología restringido, umbrales de desalojo y GC de imágenes establecidos, reservas aplicadas.
• CNI: Cilium con reemplazo de kube-proxy eBPF, MTU ajustado a 1450.
• Cargas de trabajo: QoS garantizada para pods de puerta de enlace, objetivo HPA del 60 %. CPUEn CPU límite para servicios de alto rendimiento, solo solicitudes.
• Observabilidad: Prometheus alerta sobre latencia de API, uso de conntrack, CPU estrangulamiento y presión del disco.

Preguntas frecuentes: Optimización de Kubernetes en Linux

Lista de verificación final

• Linux optimizado: sysctl aplicado, swap desactivado, cgroup/systemd alineado.
• containerd/CRI-O configurado; espejo de registro y rotación de registros habilitados.
• Reservas de kubelet, desalojo, GC de imágenes, CPUTopología manageconjunto rs.
• CNI rápido (Cilium/Calico), MTU correcto; kube-proxy en reemplazo de IPVS o eBPF.
• Almacenamiento en contenedores y etcd respaldado por NVMe; controlador CSI optimizado.
• Solicitudes/límites establecidos para QoS; HPA/VPA y escalador automático de clúster instalados.
• Observabilidad con Prometheus y alertas sobre métricas clave de latencia y presión.

Sigue esta hoja de ruta y ejecutarás un clúster de Kubernetes en Linux más rápido, predecible y fácil de escalar. Si prefieres ayuda experta, YouStableLos ingenieros pueden diseñar, evaluar y manage un completo Pila de Kubernetes optimizada y adaptada a sus cargas de trabajo.