¿Qué es Kubernetes??

¿Qué es Kubernetes?? Y cual es su arquitectura?

La contenedores ha reducido el cable entre los desarrolladores de software y el entorno de producción. No en el sentido de que no necesita un sistema de producción, pero no tiene que preocuparse por la especificidad del entorno de producción.

Las aplicaciones ahora están inclinadas con las dependencias que necesitan, en un contenedor liviano en lugar de una VM. Eso es genial! Sin embargo, no proporciona inmunidad a las fallas del sistema, falla de la red o fallas en el disco. Por ejemplo, si el centro de datos, donde se ejecutan sus servidores, está en mantenimiento, su aplicación se desconectará.

Kubernetes entra en una imagen para resolver estos problemas. Toma la idea de los contenedores y la extiende para que funcione en múltiples nodos de cómputo (que podrían ser una máquina virtual alojada en la nube o servidores de metal desnudo). La idea es tener un sistema distribuido para que se ejecute aplicaciones contenedoras en.

Por qué Kubernetes?

Ahora, ¿por qué necesitarías tener un entorno distribuido en primer lugar??

Por múltiples razones, en primer lugar es de alta disponibilidad. Desea que su sitio web de comercio electrónico se mantenga en línea 24/7, o perderá negocios, usará Kubernetes para eso. El segundo es la escalabilidad, donde quieres escalar 'fuera'. La ampliación aquí implica agregar más nodos de cómputo para darle a su aplicación creciente más espacio para las piernas para operar.

Diseño y arquitectura

Al igual que cualquier sistema distribuido, un clúster Kubernetes tiene un nodo maestro y luego muchos nodos de trabajadores, que es donde sus aplicaciones se ejecutarían realmente. El maestro es responsable de programar tareas, administrar cargas de trabajo y agregar de forma segura nuevos nodos al clúster.

Ahora, por supuesto, el nodo maestro en sí puede fallar y llevar todo el clúster, por lo que Kubernetes en realidad le permite tener múltiples nodos maestros por la redundancia.

La vista de un pájaro de una implementación típica de Kubernetes

Maestro de Kubernetes

El maestro de Kubernetes es con lo que el equipo de DevOps interactúa y usa para aprovisionar nuevos nodos, implementar nuevas aplicaciones y monitoreo y gestión de recursos. La tarea más básica del nodo maestro es cronograma La carga de trabajo de manera eficiente entre todos los nodos de los trabajadores para maximizar la utilización de recursos, mejorar el rendimiento y seguir varias políticas elegidas por el equipo de DevOps para su carga de trabajo particular.

Otro componente importante es el etcd que es un demonio que realiza un seguimiento de los nodos de los trabajadores y mantiene una base de datos que almacena todo el estado del clúster. Es un almacén de datos de valor clave, que también se puede ejecutar en un entorno distribuido en múltiples nodos maestros. El contenido de ETCD proporciona todos los datos relevantes sobre todo el clúster. Un nodo de trabajadores analizaría el contenido de ETCD de vez en cuando para determinar cómo debe comportarse.

Controlador es la entidad que tomaría instrucciones del servidor API (que cubriremos más adelante) y realizaremos las acciones necesarias como creación, eliminación y actualización de aplicaciones y paquetes.

El Servidor API Expone la API de Kubernetes, que utiliza cargas útiles JSON a través de HTTPS, para comunicarse con la interfaz de usuario con la que los equipos de desarrolladores o el personal de DevOps finalmente terminarían interactuando. Tanto la interfaz de usuario web como la CLI consumen esta API para interactuar con el clúster Kubernetes.

El servidor API también es responsable de la comunicación entre los nodos de los trabajadores y varios componentes del nodo maestro como ETCD.

El nodo maestro nunca está expuesto al usuario final, ya que arriesgaría la seguridad de todo el clúster.

Nodos Kubernetes

Una máquina (física o virtual) necesitaría algunos componentes importantes que una vez instalados y configurados correctamente puedan convertir ese servidor en un miembro de su clúster Kubernetes.

Lo primero que necesitará es un tiempo de ejecución de contenedores, como Docker, instalado y ejecutado en él. Será responsable de girar y administrar contenedores, obviamente.

Junto con el tiempo de ejecución de Docker, también necesitamos el Kubelet demonio. Se comunica con los nodos maestros, a través del servidor API y consulta el ETCD, y devuelve información sobre la salud y el uso sobre las cápsulas que se ejecutan en ese nodo.

Sin embargo, los contenedores están bastante limitados por sí mismos, por lo que Kubernetes tiene una mayor abstracción construida sobre una colección de contenedores, conocido como Vaina.

¿Por qué se te ocurren vainas??

Docker tiene una política de ejecutar una aplicación por contenedor. A menudo descrito como el "Un proceso por contenedor" política. Esto significa que si necesita un sitio de WordPress, se le recomienda que tenga dos contenedores uno para que la base de datos se ejecute y otra para que el servidor web se ejecute en. Bundling tales componentes relacionados de una aplicación en una cápsula asegura que cada vez que se escala, los dos contenedores interdependientes siempre coexisten en el mismo nodo y, por lo tanto, se hablan de manera rápida y fácil.

Las vainas son la unidad fundamental de implementación en Kubernetes. Cuando se escala, agrega más vainas al clúster. Cada POD recibe su propia dirección IP única dentro de la red interna del clúster.

Volver al nodo Kubernetes

Ahora un nodo puede ejecutar múltiples vainas y puede haber muchos nodos de este tipo. Todo esto está bien hasta que piense en tratar de comunicarse con el mundo externo. Si tiene un servicio simple basado en la web, ¿cómo señalaría su nombre de dominio a esta colección de vainas con muchas direcciones IP??

No puedes y no tienes que hacerlo! Kube-proxy es la pieza final del rompecabezas que permite a los operadores exponer ciertos vainas a Internet. Por ejemplo, su front-end se puede hacer públicamente accesible y el Kube-Proxy distribuiría el tráfico entre todos los diversos pods responsables de alojar la parte delantera. Sin embargo, su base de datos no necesita hacerse pública y Kube-Proxy permitiría solo una comunicación interna para tales cargas de trabajo relacionadas con el back-end.

¿Necesitas todo esto??

Si recién está comenzando como aficionado o estudiante, usar kubernetes para una aplicación simple sería realmente ineficiente. Todo el rigmarole consumiría más recursos que su aplicación real y agregaría más confusión para un solo individuo.

Sin embargo, si va a trabajar con un equipo grande e implementa sus aplicaciones para un uso comercial serio, Kubernetes vale la pena. Puedes evitar que las cosas se vuelvan caóticas. Dejar espacio para el mantenimiento sin ningún tiempo de inactividad. Configurar las condiciones de prueba A/B ingeniosas y escalar gradualmente sin gastar demasiado en la infraestructura por adelantado.