Setup
En esta sección encontrarás toda la información necesaria para poder identificar
la solución que mejor se adapta a tus necesidades.
Decidir dónde ejecutar Kubernetes depende principalmente de los recursos que
tengas disponibles, de las características del clúster y de cuánta flexibilidad
necesites.
Puedes ejecutar Kubernetes casi en cualquier lugar, desde su ordenador portátil
a máquinas virtuales en la nube o en un rack de servidores físicos on-premises.
Puedes configurar un clúster totalmente gestionado ejecutando un solo comando,
desplegar una solución parcialmente automatizada que te ofrezca un poco más de
control o directamente crear tu propio clúster de forma completamente manual
personalizando y controlando cada componente.
Soluciones para la máquina en local
Una solución para la máquina en local es la forma más sencilla de empezar a
utilizar Kubernetes. Puedes crear y probar clústeres de Kubernetes sin tener
que preocuparte por consumir recursos en el cloud ni disponer de conectividad.
Deberías elegir una solución de este tipo si buscas:
- Probar o empezar a aprender sobre Kubernetes.
- Desarrollar y testear clústeres localmente.
Soluciones gestionadas
Una solución gestionada es la forma más conveniente de crear y gestionar un
clúster de Kubernetes. El proveedor gestiona y opera los clústeres completamente
por lo que tú no has de preocuparte de nada.
Deberías elegir una solución de este tipo si:
- Quieres una solución totalmente gestionada.
- Quieres centrarte en desarrollar tus aplicaciones o servicios.
- No tienes un equipo dedicado de operaciones pero quieres alta disponibilidad.
- No tienes recursos para alojar y monitorizar sus clústeres.
Soluciones sobre IaaS en la nube
Un solución sobre IaaS en la nube permite crear clústeres Kubernetes con solo
unos pocos comandos, se encuentran en desarrollo activo, tienen el apoyo de la
comunidad y algunas de ellas forman parte del proyecto Kubernetes.
Se pueden desplegar en la infraestructura como servicio (IaaS) proporcionada por
los proveedores en la nube y ofrecen más flexibilidad que las soluciones
gestionadas, pero requieren más conocimientos para ponerlos en marcha y más
esfuerzo para operarlos.
Deberías elegir una solución de este tipo si:
- Necesitas más control que el permitido en las soluciones gestionadas.
- Quieres responsabilizarte de la operativa de los clústeres.
Soluciones sobre virtualización On-Premises
Una solución sobre virtualización sobre on-premises permite crear clústeres y
operarlos de forma segura en tú nube privada con solo unos pocos comandos.
Deberías elegir una solución de este tipo si:
- Quieres desplegar clústeres en su nube privada dentro de tú red.
- Tienes un equipo de operaciones para desplegar y operar el clúster.
- Tienes los recursos necesarios para ejecutar y monitorizar el clúster.
Soluciones personalizadas
Una solución personalizadas proporciona total libertad sobre los clústeres
pero requiere más conocimiento y experiencia.
1.1 - Compilando desde código fuente
Se puede o bien crear una release desde el código fuente o bien descargar una versión pre-built. Si no se pretende hacer un desarrollo de Kubernetes en sí mismo, se sugiere usar una version pre-built de la release actual, que se puede encontrar en Release Notes.
El código fuente de Kubernetes se puede descargar desde el repositorio kubernetes/kubernetes .
Compilar desde código fuente
Si simplemente estas compilando una release desde el código fuente, no es necesario hacer una configuración completa del entorno golang ya que toda la compilación se realiza desde un contenedor Docker.
Compilar es fácil.
git clone https://github.com/kubernetes/kubernetes.git
cd kubernetes
make release
Para más detalles sobre el proceso de compilación de una release, visita la carpeta kubernetes/kubernetes build
3.1 - Consideraciones para clústeres grandes
Un clúster es un conjunto de nodos (máquinas físicas
o virtuales) que ejecutan agentes de Kubernetes y que administra el
plano de control.
Kubernetes v1.37 admite clústeres de hasta 5.000 nodos. Más específicamente,
Kubernetes está diseñado para admitir configuraciones que cumplan todos los siguientes criterios:
- No más de 110 pods por nodo
- No más de 5.000 nodos
- No más de 150.000 pods en total
- No más de 300.000 contenedores en total
Puedes escalar tu clúster agregando o eliminando nodos. La forma de hacerlo depende
de cómo se haya desplegado tu clúster.
Cuotas de recursos del proveedor de la nube
Para evitar problemas con las cuotas del proveedor de la nube, al crear un clúster con muchos nodos,
considera lo siguiente:
- Solicitar un aumento de cuota para recursos de la nube como:
- Instancias de cómputo
- CPU
- Volúmenes de almacenamiento
- Direcciones IP en uso
- Conjuntos de reglas de filtrado de paquetes
- Número de balanceadores de carga
- Subredes de red
- Flujos de registros
- Controlar las acciones de escalado del clúster para iniciar nodos nuevos en lotes, con una pausa
entre lotes, porque algunos proveedores de la nube limitan la velocidad de creación de instancias nuevas.
Componentes del plano de control
Para un clúster grande, necesitas un plano de control con suficiente capacidad de cómputo y otros
recursos.
Normalmente ejecutarías una o dos instancias del plano de control por zona de fallo,
escalando primero esas instancias verticalmente y después horizontalmente cuando alcancen
el punto de rendimientos decrecientes del escalado vertical.
Debes ejecutar al menos una instancia por zona de fallo para proporcionar tolerancia a fallos. Los nodos
de Kubernetes no dirigen automáticamente el tráfico hacia los endpoints del plano de control que están
en la misma zona de fallo; sin embargo, tu proveedor de la nube puede tener sus propios mecanismos para hacerlo.
Por ejemplo, usando un balanceador de carga administrado, configuras el balanceador para que envíe el tráfico
que se origina en el kubelet y los Pods de la zona de fallo A únicamente
a los hosts del plano de control que también están en la zona A. Si un solo host o
endpoint del plano de control en la zona de fallo A se desconecta, eso significa que todo el tráfico del plano de control para
los nodos de la zona A es ahora enviado entre zonas. Ejecutar varios hosts del plano de control
en cada zona hace que este resultado sea menos probable.
Almacenamiento de etcd
Para mejorar el rendimiento de los clústeres grandes, puedes almacenar los objetos Event en una instancia
de etcd separada y dedicada.
Al crear un clúster, puedes (usando herramientas personalizadas):
- iniciar y configurar una instancia adicional de etcd
- configurar el servidor de API para que la use para almacenar eventos
Consulta Operar clústeres de etcd para Kubernetes y
Configurar un clúster de etcd de alta disponibilidad con kubeadm
para obtener detalles sobre cómo configurar y administrar etcd para un clúster grande.
Recursos de los addons
Los límites de recursos
de Kubernetes ayudan a minimizar el impacto de las fugas de memoria y otras situaciones en las que los pods y contenedores
pueden afectar a otros componentes. Estos límites de recursos se aplican a los recursos de los
addons del mismo modo que a las cargas de trabajo de las aplicaciones.
Por ejemplo, puedes establecer límites de CPU y memoria para un componente de registro:
...
containers:
- name: fluentd-cloud-logging
image: fluent/fluentd-kubernetes-daemonset:v1
resources:
limits:
cpu: 100m
memory: 200Mi
Los límites predeterminados de los addons normalmente se basan en datos recopilados a partir de la experiencia al ejecutar
cada addon en clústeres de Kubernetes pequeños o medianos. Al ejecutar addons en clústeres
grandes, a menudo consumen más recursos que los límites predeterminados.
Si se despliega un clúster grande sin ajustar estos valores, el addon
puede morir continuamente porque alcanza repetidamente el límite de memoria.
Como alternativa, el addon puede ejecutarse, pero con un rendimiento bajo debido a las restricciones
de la fracción de tiempo de CPU.
Para evitar problemas con los recursos de los addons del clúster, al crear un clúster con muchos nodos,
considera lo siguiente:
- Algunos addons escalan verticalmente: hay una réplica del addon para el clúster
o para toda una zona de fallo. Para estos addons, aumenta las solicitudes y los límites
a medida que escalas tu clúster.
- Muchos addons escalan horizontalmente: agregas capacidad ejecutando más pods; pero con
un clúster muy grande también puede ser necesario aumentar ligeramente los límites de CPU o memoria.
El Vertical Pod Autoscaler puede ejecutarse en modo recommender para proporcionar valores sugeridos
para las solicitudes y los límites.
- Algunos addons se ejecutan como una copia por nodo, controlados por un DaemonSet: por ejemplo, un agregador de registros a nivel de nodo. Al igual que
en el caso de los addons escalados horizontalmente, también puede ser necesario aumentar
ligeramente los límites de CPU o memoria.
Priorizar los componentes esenciales del clúster
Para garantizar que los componentes esenciales del clúster (como CoreDNS, metrics-server y otros addons críticos) se programen antes que otras cargas de trabajo y no sean desalojados por pods de menor prioridad, ejecútalos con una PriorityClass del sistema, como system-cluster-critical o system-node-critical.
¿Qué sigue?
VerticalPodAutoscaler es un recurso personalizado que puedes desplegar en tu clúster
para ayudarte a administrar las solicitudes y los límites de recursos de los pods.
Aprende más sobre Vertical Pod Autoscaler
y cómo puedes usarlo para escalar los componentes del clúster,
incluidos los addons esenciales para el clúster.
Lee sobre el escalado automático de nodos
El addon resizer
te ayuda a cambiar automáticamente el tamaño de los addons a medida que cambia la escala de tu clúster.