Phenquestions
¿Qué es Kubernetes?? Y cual es su arquitectura?
La contenerización ha cortado el cable entre los desarrolladores de software y el entorno de producción. No en el sentido de que no necesite un sistema de producción en absoluto, pero no tiene que preocuparse por la especificidad del entorno de producción.
Las aplicaciones ahora están empaquetadas con las dependencias que necesitan, en un contenedor liviano en lugar de una VM. Eso es genial! Sin embargo, no proporciona inmunidad contra fallas del sistema, fallas de red o fallas de disco. Por ejemplo, si el centro de datos, donde se ejecutan sus servidores, está en mantenimiento, su aplicación se desconectará.
Kubernetes entra en escena para resolver estos problemas. Toma la idea de contenedores y la extiende para que funcione en múltiples nodos de computación (que podrían ser una máquina virtual alojada en la nube o servidores bare metal). La idea es tener un sistema distribuido para que las aplicaciones en contenedores se ejecuten.
Por qué Kubernetes?
Ahora, ¿por qué necesitaría tener un entorno distribuido en primer lugar??
Por múltiples razones, la primera y más importante es la alta disponibilidad. Desea que su sitio web de comercio electrónico permanezca en línea las 24 horas del día, los 7 días de la semana, o perderá negocios, use Kubernetes para eso. El segundo es la escalabilidad, donde desea escalar 'horizontalmente'. Escalar aquí implica agregar más nodos de cómputo para darle a su aplicación en crecimiento más espacio para operar.
Diseño y Arquitectura
Como cualquier sistema distribuido, un clúster de Kubernetes tiene un nodo maestro y luego una gran cantidad de nodos trabajadores, que es donde se ejecutarían sus aplicaciones. 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 llevarse todo el clúster con él, por lo que Kubernetes le permite tener múltiples nodos maestros por el bien de la redundancia.
Una vista panorámica 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 monitorear y administrar recursos. La tarea más básica del nodo maestro es calendario la carga de trabajo de manera eficiente entre todos los nodos 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 trabajadores y mantiene una base de datos que almacena el estado de todo el clúster. Es un almacén de datos de valor clave, que también se puede ejecutar en un entorno distribuido en varios nodos maestros. El contenido de etcd proporciona todos los datos relevantes sobre todo el clúster. Un nodo trabajador miraría el contenido de etcd de vez en cuando para determinar cómo debería comportarse.
Controlador es la entidad que tomaría las instrucciones del servidor API (que cubriremos más adelante) y realizaría las acciones necesarias como la creación, eliminación y actualización de aplicaciones y paquetes.
La 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 eventualmente terminarían interactuando. Tanto la interfaz de usuario web como la CLI consumen esta API para interactuar con el clúster de Kubernetes.
El servidor API también es responsable de la comunicación entre los nodos trabajadores y varios componentes del nodo maestro como etcd.
El nodo principal nunca está expuesto al usuario final, ya que pondría en riesgo la seguridad de todo el clúster.
Nodos de Kubernetes
Una máquina (física o virtual) necesitaría algunos componentes importantes que, una vez instalados y configurados correctamente, pueden convertir ese servidor en un miembro de su clúster de Kubernetes.
Lo primero que necesitará es un tiempo de ejecución de contenedor, como Docker, instalado y ejecutándose en él. Se encargará de girar y gestionar los 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 el estado y el uso de los pods que se ejecutan en ese nodo.
Sin embargo, los contenedores son bastante limitados por sí mismos, por lo que Kubernetes tiene una mayor abstracción construida sobre una colección de contenedores, conocida como Vainas.
¿Por qué crear 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, le recomendamos que tenga dos contenedores, uno para que se ejecute la base de datos y otro para que se ejecute el servidor web. La combinación de estos componentes relacionados de una aplicación en un pod garantiza que, siempre que se escale horizontalmente, los dos contenedores interdependientes siempre coexistan en el mismo nodo y, por lo tanto, se comuniquen entre sí de forma rápida y sencilla.
Los pods son la unidad fundamental de implementación en Kubernetes. Cuando escala horizontalmente, agrega más pods al clúster. A cada pod se le asigna su propia dirección IP única dentro de la red interna del clúster.
Volver al nodo de Kubernetes
Ahora un nodo puede ejecutar varios pods y puede haber muchos de estos nodos. Todo esto está bien hasta que pienses en intentar comunicarte 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 pods con muchas direcciones IP??
No puedes y no tienes que hacerlo! Proxy de Kube es la última pieza del rompecabezas que permite a los operadores exponer ciertos pods a Internet. Por ejemplo, su front-end puede ser de acceso público y el proxy kube distribuiría el tráfico entre los distintos pods que son responsables de alojar el front-end. Sin embargo, su base de datos no necesita hacerse pública y kube-proxy solo permitiría la 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 en realidad sería ineficiente. Todo el galimatías 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 implementará sus aplicaciones para un uso comercial serio, vale la pena agregar Kubernetes. Puedes evitar que las cosas se vuelvan caóticas. Haga espacio para el mantenimiento sin tiempo de inactividad. Configure ingeniosas condiciones de prueba A / B y escale gradualmente sin gastar demasiado en la infraestructura por adelantado.
