Versión imprimible multipagina. Haga click aquí para imprimir.
Administración del Clúster
1 - Certificados
Para aprender a generar certificados para su clúster, consulte la documentación de Certificados.
2 - Redes del clúster
Las redes son una parte central de Kubernetes, pero puede resultar difícil entender con exactitud cómo se espera que funcionen. Hay 4 problemas de red
Las redes son una parte central de Kubernetes, pero puede resultar difícil entender con exactitud como se espera que funcionen. Hay 4 problemas de red
- Comunicaciones muy acopladas entre contenedores: esto lo resuelven los
Pods y las comunicaciones por
localhost. - Comunicaciones de Pod a Pod: este es el foco principal de este documento.
- Comunicaciones de Pod a Service: esto se cubre en Services.
- Comunicaciones del exterior hacia un Service: esto también lo cubren los Services.
Kubernetes trata de compartir máquinas entre aplicaciones. Por lo general, compartir una máquina exige que dos aplicaciones no intenten usar los mismos puertos. Coordinar los puertos entre varios desarrolladores es muy difícil a escala y expone a los usuarios a problemas del clúster que quedan fuera de su control.
La asignación dinámica de puertos complica mucho el sistema: cada aplicación tiene que tomar los puertos como flags, los servidores de API tienen que saber cómo insertar números de puerto dinámicos en los bloques de configuración, los Services tienen que saber cómo encontrarse, y así sucesivamente. En lugar de resolver todo eso, Kubernetes toma otro camino.
Para conocer el modelo de red de Kubernetes, consulta esta página.
Rangos de direcciones IP de Kubernetes
Los clústeres de Kubernetes tienen que asignar direcciones IP que no se solapen a los Pods, los Services y los nodos, a partir de un rango de direcciones disponibles configurado en estos componentes:
- El plugin de red se configura para asignar direcciones IP a los Pods.
- El kube-apiserver se configura para asignar direcciones IP a los Services.
- El kubelet o el cloud-controller-manager se configura para asignar direcciones IP a los nodos.
Tipos de red del clúster
Según las familias de IP configuradas, un clúster de Kubernetes puede clasificarse como:
- Solo IPv4: el plugin de red, el kube-apiserver y el kubelet o el cloud-controller-manager se configuran para asignar únicamente direcciones IPv4.
- Solo IPv6: el plugin de red, el kube-apiserver y el kubelet o el cloud-controller-manager se configuran para asignar únicamente direcciones IPv6.
- IPv4/IPv6 o IPv6/IPv4, en pila dual o dual-stack:
- El plugin de red se configura para asignar direcciones IPv4 e IPv6.
- El kube-apiserver se configura para asignar direcciones IPv4 e IPv6.
- El kubelet o el cloud-controller-manager se configura para asignar direcciones IPv4 e IPv6.
- Todos los componentes deben coincidir en la familia IP primaria configurada.
Los clústeres de Kubernetes solo tienen en cuenta las familias de direcciones IP presentes en los objetos Pods, Services y Nodes,
independientemente de las direcciones IP que tengan asignadas los objetos representados. Por ejemplo, un servidor o un pod puede tener varias
direcciones IP asignadas a sus interfaces, pero solo se tienen en cuenta las direcciones IP de node.status.addresses o pod.status.ips
al implementar el modelo de red de Kubernetes y definir el tipo de clúster.
¿Cómo se implementa el modelo de red de Kubernetes?
EL modelo de red es implementado por el motor de ejecución de contenedores en cada nodo. Los motores de ejecución más habituales usan plugins de la Container Network Interface (CNI) para gestionar las capacidades de red y seguridad. Hay muchos plugins CNI, de distintos proveedores. Algunos de ellos solo añaden capacidades basicas de agregar o quitar interfaces de red, mientras que otros ofrecen soluciones más elaboradas, como la integración con otros sistemas de orquestacion de contenedores, utilizando varios plugins CNI, funciones avanzadas de IPAM, etc.
En esta página hay una lista, no exhaustiva, de complementos de red compatibles con Kubernetes.
¿Qué sigue?
El diseño inicial del modelo de red y sus motivos se describen con más detalle en el documento de diseño de redes. Para planes futuros y algunas iniciativas en curso destinadas a mejorar las redes de Kubernetes, consulta los KEPs de SIG-Network.
3 - Proxies en Kubernetes
Esta página explica los proxies que se utilizan con Kubernetes.
Proxies
Existen varios proxies que puedes encontrar al usar Kubernetes:
El proxy de kubectl:
- se ejecuta en el escritorio de un usuario o en un Pod
- hace de intermediario entre una dirección localhost y el apiserver de Kubernetes
- la conexión del cliente al proxy usa HTTP
- la conexión del proxy al apiserver usa HTTPS
- localiza el apiserver
- añade cabeceras de autenticación
- es un bastión incorporado en el apiserver
- conecta a un usuario de fuera del clúster con las IPs del clúster, que de otro modo podrían no ser accesibles
- se ejecuta dentro de los procesos del apiserver
- la conexión del cliente al proxy usa HTTPS (o HTTP si el apiserver está configurado así)
- la conexión del proxy al destino puede usar HTTP o HTTPS, según lo que elija el proxy con la información disponible
- se puede usar para llegar a un nodo, un Pod o un Service
- hace balanceo de carga cuando se usa para llegar a un Service
El kube proxy:
- se ejecuta en cada nodo
- hace de proxy para UDP, TCP y SCTP
- no entiende HTTP
- proporciona balanceo de carga
- solo se usa para llegar a los servicios
Un proxy/balanceador de carga delante de uno o varios apiservers:
- su existencia e implementación varían de un clúster a otro (por ejemplo, nginx)
- se sitúa entre todos los clientes y uno o varios apiservers
- actúa como balanceador de carga si hay varios apiservers.
Balanceadores de carga en la nube para servicios externos:
- los proporcionan algunos proveedores de nube (por ejemplo, AWS ELB o Google Cloud Load Balancer)
- se crean automáticamente cuando el Service de Kubernetes es de tipo
LoadBalancer - por lo general solo admiten UDP y TCP
- la compatibilidad con SCTP depende de la implementación del balanceador de carga del proveedor de nube
- la implementación varía según el proveedor de nube.
Normalmente, los usuarios de Kubernetes solo necesitan preocuparse por los dos primeros tipos. Del resto suele encargarse el administrador del clúster, que se asegura de que estén configurados correctamente.
Solicitar redirecciones
Los proxies han reemplazado las capacidades de redirección. Las redirecciones están obsoletas.
4 - Instalación de Complementos (AddOns)
Los complementos amplían las funcionalidades de Kubernetes.
En esta página se listan algunos de los complementos disponibles con sus respectivos enlaces de instrucciones para su instalación y uso. La lista no pretende ser exhaustiva.
Redes y Política de Redes
- ACI (Cisco ACI) proporciona redes de contenedores integradas y seguridad de red.
- Antrea proporciona servicios de red y seguridad para Kubernetes, aprovechando Open vSwitch como plano de datos de red, opera en la capa 3/4. Antrea es un proyecto de la CNCF de nivel Sandbox.
- Calico es un proveedor de redes y políticas de red. Calico admite un conjunto flexible de opciones de red, para poder elegir la opción más eficiente para su situación, incluidas las redes superpuestas y no superpuestas, con o sin BGP (Border Gateway Protocol). Calico utiliza el mismo motor para aplicar las políticas de red para hosts, Pods, y (si se usa Istio y Envoy) aplicaciones en la capa de la malla de servicios.
- Canal Es la unión de Flannel y Calico, proporciona redes y políticas de redes.
- Cilium es una solución de red, observabilidad y seguridad con un plano de datos basado en eBPF. Cilium proporciona una red sencilla y plana en capa 3 con la capacidad de abarcar varios clústeres en un modo de enrutamiento nativo o de superposición/encapsulación, y puede aplicar políticas de red en L3-L7 utilizando un modelo de seguridad basado en identidad que está desacoplado del direccionamiento de red. Cilium puede actuar como sustituto de kube-proxy, también ofrece características adicionales de observabilidad y seguridad de manera opcional. Cilium es un proyecto de la CNCF de nivel Incubación.
- CNI-Genie permite a Kubernetes conectarse sin problemas a una selección de complementos de CNI, como Calico, Canal, Flannel o Weave. CNI-Genie es un proyecto de la CNCF de nivel Sandbox.
- Contiv proporciona redes configurables (L3 nativo mediante BGP,
con superposición mediante vxlan, L2 clásica y Cisco-SDN/ACI) para diversos casos de uso
y un vasto marco de políticas.
El proyecto Contiv es de código abierto. El instalador ofrece opciones de instalación basadas en kubeadm y no basadas en kubeadm. - Contrail, basada en Tungsten Fabric, es una plataforma de gestión de políticas y virtualización de redes multicloud de código abierto. Contrail y Tungsten Fabric se integran con sistemas de orquestación como Kubernetes, OpenShift, OpenStack y Mesos, y proporcionan modos de aislamiento para máquinas virtuales, contenedores/Pods y cargas de trabajo para bare metal.
- Flannel es un proveedor de red superpuesta que se puede usar con Kubernetes.
- Knitter es un complemento que soportar múltiples interfaces de red en un Pod de Kubernetes.
- Multus es un multicomplemento para soporte de múltiple redes en Kubernetes, que admite todos los complementos de CNI (ej. Calico, Cilium, Contiv, Flannel), además de SRIOV, DPDK, OVS-DPDK y cargas de trabajo basadas en VPP en Kubernetes.
- OVN-Kubernetes es un proveedor de red para Kubernetes basado en OVN (Open Virtual Network), es una implementación de red virtual que surgió del proyecto Open vSwitch (OVS). OVN-Kubernetes proporciona una implementación de red basada en la superposición para Kubernetes, incluyendo una implementación basada en OVS de balanceo de carga y política de red.
- Nodus es un complemento de controlador CNI basado en OVN para proveer Service function chaining(SFC) con base nativa para la nube.
- NSX-T Container Plug-in (NCP) proporciona integración entre VMware NSX-T y orquestadores de contenedores como Kubernetes, así como integración entre NSX-T y plataformas CaaS/PaaS basadas en contenedores como Pivotal Container Service (PKS) y OpenShift.
- Nuage es una plataforma SDN que proporciona redes basadas en políticas entre Kubernetes Pods y entornos no Kubernetes con visibilidad y supervisión de la seguridad.
- Romana es una solución de red de capa 3 para las redes de Pods que también son compatibles con la API de NetworkPolicy.
- Weave Net proporciona redes y políticas de red, funciona en ambos lados de una partición de red y no requiere una base de datos externa.
Detección de Servicios
- CoreDNS es un servidor de DNS flexible y extensible que
puede instalarse como DNS dentro del clúster para los Pods.
Visualización y Control
- Dashboard es un panel de control con una interfaz web para Kubernetes.
Infraestructura
- KubeVirt es un complemento para ejecutar máquinas virtuales en Kubernetes. Suele ejecutarse en clústeres de Bare metal.
- El detector de problemas de nodo se ejecuta en nodos Linux e informa de los problemas del sistema como Eventos o Condiciones de nodo.
Complementos Antiguos
Hay otros complementos documentados como obsoletos en el directorio cluster/addons.
Los que mejor mantenimiento tienen deben estar vinculados aquí. !PRs son bienvenidos!