11 buenas prácticas para que tu clúster de producción tenga un comienzo exitoso
Los contenedores se han convertido en la norma para la creación de aplicaciones nativas de la nube, y Kubernetes, comúnmente conocido como K8s, es sin duda la tecnología de orquestación de contenedores más buscada.
Sin embargo, que sea popular no significa que sea fácil de usar. El sistema Kubernetes es complicado y requiere una curva de aprendizaje pronunciada para empezar a gestionar los contenedores. Aunque algunas de las siguientes buenas prácticas de Kubernetes y sugerencias pueden no ser apropiadas para tu entorno, las que sí lo son pueden ayudarte a utilizar Kubernetes de forma más eficaz y rápida.
Este post profundizará en las 11 buenas prácticas de Kubernetes para sacar el máximo partido a tu clúster de producción.
Utiliza siempre la última versión
Empezamos con un recordatorio amistoso: mantén la versión de Kubernetes actualizada. Además de introducir nuevas características y funcionalidades, las nuevas versiones vienen con correcciones y parches para remediar los problemas de vulnerabilidad y seguridad en el clúster de producción. Consideramos que esta es una de las ventajas más destacadas de mantener tu entorno K8s actualizado.
Sin embargo, el equipo de producción debe estudiar y probar a fondo todas las nuevas características antes de actualizar, así como aquellas características o funcionalidades obsoletas para evitar perder la compatibilidad con las aplicaciones que se ejecutan en el clúster. Actualizar la versión sin analizarla y probarla en un entorno seguro podría dificultar los tiempos de producción.
Crea un firewall
Puede que esta práctica recomendada no te sorprenda, ya que tener un firewall delante de tu clúster de Kubernetes parece ser una práctica establecida, pero hay muchos desarrolladores que no prestan atención a esto.
Así que aquí va otro recordatorio amistoso: crea un firewall para el servidor API. Un firewall protegerá tu entorno en K8s para evitar que los atacantes envíen solicitudes de conexión al servidor API desde Internet. Las direcciones IP deben estar en una white list y los puertos abiertos deben estar restringidos mediante el uso de reglas de firewall de puertos.
Utiliza un flujo de trabajo de GitOps
Un flujo de trabajo con base en Git es el método a seguir para un despliegue exitoso en Kubernetes. Este flujo de trabajo impulsa la automatización mediante el uso de pipelines CI/CD, que mejora la productividad al aumentar la eficiencia y la velocidad de despliegue de las aplicaciones.
Sin embargo, hay que tener en cuenta que el git debe ser la única fuente para toda la automatización que centralizará la gestión de todo el clúster de producción. Otra opción es elegir una plataforma de entrega de infraestructura dedicada, como Argo CD, una herramienta GitOps y de entrega continua declarativa para Kubernetes.
¿Tienes dudas sobre las metodologías GitOps? Nosotros podemos ayudarte.
Audita los logs
Audita los logs con regularidad para identificar vulnerabilidades o amenazas en tu clúster. Además, es esencial mantener una capa de logging centralizada para tus contenedores.
Por otro lado, la auditoría de los logs te dirá cuántos recursos se están consumiendo por tarea en el control plane y capturará los latidos de los eventos clave. Es fundamental vigilar los componentes del control plane de Kubernetes para limitar el uso de recursos. El control plane es el corazón de K8s y depende de estas piezas para mantener la funcionalidad del sistema y garantizar un funcionamiento correcto. El control plane está conformado por la API de Kubernetes, kubelet, etcd, controller-manager, kube-proxy y kube-dns.
Utiliza namespaces
Kubernetes viene con tres namespaces por defecto: default,kube-public y kube-system. Los namespaces son fundamentales para estructurar tu clúster de Kubernetes y mantenerlo seguro frente a otros equipos que operan en el mismo clúster. Necesitas namespaces distintos para cada equipo si tu clúster de Kubernetes tiene un tamaño considerable (cientos de nodos) y muchos equipos o aplicaciones trabajando en él. A veces, se crean entornos diferentes y se designan a cada equipo para optimizar costos.
Por ejemplo, se deberían designar varios namespaces para los equipos de desarrollo, pruebas y producción. Al hacer esto, el desarrollador que sólo tiene acceso al namespace de desarrollo no podrá actualizar nada en el namespace de producción accidentalmente. Existe la posibilidad de que los compañeros de equipo, con la mejor de las intenciones, los sobrescriban involuntariamente si no se realiza esta separación.
Solicitudes y límites de recursos
Los límites de recursos definen el máximo de recursos que puede utilizar un contenedor, mientras que las solicitudes de recursos definen el mínimo. Los pods de un clúster pueden utilizar más recursos de los necesarios si no hay solicitudes o restricciones de recursos.
El programador podría ser incapaz de organizar pods adicionales si el pod empieza a utilizar más CPU o memoria en el nodo, y el propio nodo podría incluso fallar. Es habitual especificar la CPU en milicores tanto para las solicitudes como para las limitaciones. Los megabytes o mebibytes se utilizan para medir la memoria.
Utiliza labels/tags
Un clúster de Kubernetes está formado por múltiples componentes, que incluyen a los servicios, los pods, los contenedores, las redes, etc. Gestionar todos estos recursos y saber cómo se relacionan entre sí en un clúster supone un desafío, por lo que las etiquetas son útiles en esta situación. Los recursos de tu clúster se organizan mediante pares clave-valor llamadas etiquetas en Kubernetes.
Imaginemos, por ejemplo, que se ejecutan dos instancias del mismo tipo de programa: a pesar de tener nombres idénticos, equipos distintos utilizan cada una de las aplicaciones (por ejemplo, desarrollo y pruebas). Puedes ayudar a tus equipos a diferenciar entre las aplicaciones comparables si se crea un tag que utilice el nombre de tu equipo para mostrar la propiedad.
RBAC
Tu clúster de Kubernetes es vulnerable a ataques informáticos, como cualquier sistema y, para obtener acceso, los hackers suelen buscar puntos débiles en el sistema. Por lo tanto, mantener la seguridad de tu clúster Kubernetes debe ser una prioridad absoluta. Para esto, se debe verificar que su entorno en Kubernetes esté utilizando un RBAC (o Role-Based Access Control en inglés) como primer paso.
Cada usuario de tu clúster y cada cuenta de servicio que se ejecute en tu clúster tiene que tener un rol asignado. Los permisos múltiples se encuentran en estos roles de RBAC que puede una cuenta de usuario o servicio puede utilizar. Varios usuarios pueden tener el mismo cargo, y cada rol puede tener varios permisos.
Seguimiento de las políticas de red
Las políticas de red se utilizan para limitar el tráfico entre los objetos del clúster de K8s. Por defecto, todos los contenedores tienen capacidades de comunicación de red, lo que plantea un problema de seguridad si los hackers pueden acceder a un contenedor y utilizarlo para moverse entre los objetos del clúster.Al igual que los grupos de seguridad en las plataformas en la nube limitan el acceso a los recursos, las políticas de red pueden gobernar el tráfico a nivel de IP y puerto. Normalmente, todo el tráfico debe ser denegado automáticamente, y se deben implementar reglas para permitir el tráfico necesario.
¿Se están monitoreando los puntos vitales de seguridad de tu aplicación?
Utiliza las readiness and liveness probes
Las readiness and liveness probes funcionan como los exámenes de salud. Antes de permitir que la carga se dirija a un pod específico, una readiness probe verifica que el pod está activo y operativo. Las solicitudes se retienen de tu servicio si el pod no está disponible hasta que la sonda confirme que el pod está disponible.
Una liveness probe confirma la existencia de la aplicación: hace un ping al pod para intentar obtener una respuesta antes de comprobar su estado. Si no ocurre nada, la aplicación no está activa en el pod. Si la comprobación no tiene éxito, la sonda de vivacidad crea un nuevo pod y ejecuta la aplicación en él.
Services meshes
Puedes añadir una capa de infraestructura dedicada a tus aplicaciones denominada malla de servicios. Sin añadirlas a tu código, te permite agregar de forma transparente características como la observabilidad, la gestión del tráfico y la seguridad. La frase en inglés «service mesh» se refiere al software que se emplea para llevar a cabo este patrón y al dominio de seguridad o de red que resulta de su aplicación.
La comprensión y la gestión del despliegue de servicios distribuidos puede resultar más difícil a medida que aumenta su tamaño y complejidad, como en un sistema basado en Kubernetes. Tus requisitos pueden incluir la medición, la supervisión, la distribución del tráfico, la recuperación de fallos y el service discovery. Además, una service mesh suele ocuparse de necesidades operativas más complejas, como la autenticación de extremo a extremo, la restricción de velocidad, el control de acceso, el cifrado y los despliegues canary.
La capacidad de comunicación entre servicios es lo que da lugar a las aplicaciones distribuidas. A medida que aumenta el número de servicios, el enrutamiento de la comunicación dentro y entre los clusters de aplicaciones se vuelve más difícil.
Estas buenas prácticas de Kubernetes son solo una diminuta muestra de todas las que están disponibles para hacer de Kubernetes una tecnología más sencilla y beneficiosa para el desarrollo de aplicaciones. Como dijimos en la introducción, Kubernetes requiere una curva de aprendizaje pronunciada para poder empezar.
Incluso con un número cada vez mayor de herramientas y servicios para acelerar los procedimientos, los equipos de desarrollo pueden sentirse abrumados con las numerosas tareas necesarias en el desarrollo de aplicaciones modernas. Pero si empiezas con estos consejos, estarás bien encaminado para adoptar Kubernetes y avanzar en tus iniciativas de desarrollo de aplicaciones complejas.
LinkedIn: https://www.linkedin.com/company/dinocloud
Twitter: https://twitter.com/dinocloud_
Instagram: @dinocloud_
Youtube: https://www.youtube.com/c/DinoCloudConsulting
