{"id":83787,"date":"2020-06-03T07:42:26","date_gmt":"2020-06-03T05:42:26","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/devoxx-uk-kubernetes-v-prodakshene-blue-green-deployment-avtomasshtabirovanie-i-avtomatizacziya-razvertyvaniya-chast-2"},"modified":"2020-06-03T07:42:26","modified_gmt":"2020-06-03T05:42:26","slug":"devoxx-uk-kubernetes-v-prodakshene-blue-green-deployment-avtomasshtabirovanie-i-avtomatizacziya-razvertyvaniya-chast-2","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/devoxx-uk-kubernetes-v-prodakshene-blue-green-deployment-avtomasshtabirovanie-i-avtomatizacziya-razvertyvaniya-chast-2","title":{"rendered":"DEVOXX UK. Kubernetes en producci\u00f3n: Despliegue Blue\/Green, autoescalado y automatizaci\u00f3n del despliegue. Parte 2.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Kubernetes es una excelente herramienta para ejecutar contenedores Docker en un entorno de producci\u00f3n clusterizado. Sin embargo, existen tareas que Kubernetes no puede resolver. Con implementaciones frecuentes en el entorno laboral, necesitamos un despliegue autom\u00e1tico Blue\/Green completamente integrado, para evitar tiempos de inactividad en este proceso, donde tambi\u00e9n es necesario manejar solicitudes HTTP externas y gestionar la carga de SSL. Esto requiere integraci\u00f3n con un balanceador de carga, como ha-proxy. Otra tarea es el escalado semi-autom\u00e1tico del propio cl\u00faster de Kubernetes mientras trabaja en un entorno de nube, por ejemplo, reduciendo parcialmente el tama\u00f1o del cl\u00faster por la noche.<\/p>\n

Aunque Kubernetes no posee estas funciones directamente 'de serie', proporciona una API que se puede utilizar para abordar tales tareas. Se han desarrollado herramientas para el despliegue Blue\/Green automatizado y el escalado del cl\u00faster de Kubernetes en el marco del proyecto Cloud RTI, el cual fue creado sobre bases open-source.<\/p>\n

En este art\u00edculo, la transcripci\u00f3n del video, se describe c\u00f3mo configurar Kubernetes junto con otros componentes de c\u00f3digo abierto para obtener un entorno listo para producci\u00f3n que recibe el c\u00f3digo de un commit de git sin tiempos de inactividad en producci\u00f3n.<\/p>\n

\"DEVOXX<\/a><\/noindex><\/p>\n

DEVOXX UK. Kubernetes en producci\u00f3n: Despliegue Blue\/Green, escalado autom\u00e1tico y automatizaci\u00f3n de despliegue. Parte 1.<\/a><\/noindex><\/p>\n

Entonces, una vez que ha accedido a sus aplicaciones desde el mundo externo, puede proceder a la configuraci\u00f3n completa de la automatizaci\u00f3n, es decir, llevarla a un punto en el que se pueda ejecutar un commit de git y asegurarse de que ese commit finaliza en producci\u00f3n. Es evidente que, al implementar estos pasos y realizar el despliegue, no queremos enfrentar tiempos de inactividad. Por lo tanto, toda automatizaci\u00f3n en Kubernetes comienza con la API. <\/p>\n

\"DEVOXX
\n
\nKubernetes no es una herramienta que se pueda utilizar productivamente 'directamente de la caja'. Por supuesto, puede hacerlo, usar kubectl y dem\u00e1s, pero a\u00fan as\u00ed, la API es lo m\u00e1s interesante y \u00fatil de esta plataforma. Usando la API como un conjunto de funciones, puede acceder a pr\u00e1cticamente todo lo que desee hacer en Kubernetes. El propio kubectl tambi\u00e9n utiliza la REST API. <\/p>\n

Este es un REST, as\u00ed que puedes usar cualquier lenguaje y herramienta para interactuar con esta API, pero las bibliotecas de usuario facilitar\u00e1n mucho tu vida. Mi equipo ha escrito 2 de estas bibliotecas: una para Java \/ OSGi y otra para Go. La segunda se utiliza con menos frecuencia, pero de todos modos, tienes estas herramientas \u00fatiles a tu disposici\u00f3n. Son un proyecto open-source parcialmente licenciado. Hay muchas bibliotecas de este tipo para diferentes lenguajes, as\u00ed que puedes elegir las m\u00e1s adecuadas. <\/p>\n

\"DEVOXX
\n
\nAs\u00ed que, antes de comenzar con la automatizaci\u00f3n del despliegue, es necesario asegurarse de que este proceso no sufra ning\u00fan tiempo de inactividad. Por ejemplo, nuestro equipo realiza el despliegue de producci\u00f3n a media jornada, cuando la gente usa las aplicaciones al m\u00e1ximo, por lo que es muy importante evitar retrasos en este proceso. Para evitar los tiempos de inactividad, se utilizan 2 m\u00e9todos: el despliegue blue\/green o las actualizaciones progresivas. En este \u00faltimo caso, si tienes 5 r\u00e9plicas de la aplicaci\u00f3n en funcionamiento, se actualizan secuencialmente una tras otra. Este m\u00e9todo funciona muy bien, pero no es adecuado si en el proceso de despliegue tienes distintas versiones de la aplicaci\u00f3n en ejecuci\u00f3n. En ese caso, puedes actualizar la interfaz de usuario mientras el backend sigue funcionando con la versi\u00f3n anterior, lo que interrumpir\u00e1 el funcionamiento de la aplicaci\u00f3n. Por lo tanto, desde el punto de vista de la programaci\u00f3n, trabajar en tales condiciones es bastante complicado. <\/p>\n

Esa es una de las razones por las que preferimos utilizar el despliegue blue\/green para la automatizaci\u00f3n del despliegue de nuestras aplicaciones. Con este m\u00e9todo, debes asegurarte de que en un momento dado, solo una versi\u00f3n de la aplicaci\u00f3n est\u00e9 activa. <\/p>\n

El mecanismo de despliegue blue\/green funciona de la siguiente manera. Recibimos el tr\u00e1fico para nuestras aplicaciones a trav\u00e9s de ha-proxy, que redirige a las r\u00e9plicas en funcionamiento de la aplicaci\u00f3n de la misma versi\u00f3n. <\/p>\n

Cuando se realiza un nuevo despliegue, utilizamos Deployer, al que se le proporcionan los nuevos componentes, y \u00e9l lleva a cabo el despliegue de la nueva versi\u00f3n. El despliegue de una nueva versi\u00f3n de la aplicaci\u00f3n significa que se 'levantan' un nuevo conjunto de r\u00e9plicas, y luego estas r\u00e9plicas de la nueva versi\u00f3n se inician en un nuevo pod separado. Sin embargo, ha-proxy no sabe nada de ellas y, por el momento, no dirige ninguna carga de trabajo hacia ellas.<\/p>\n

Por lo tanto, en primer lugar, es necesario realizar una verificaci\u00f3n de la funcionalidad de las nuevas versiones mediante health checking, para asegurarse de que las r\u00e9plicas est\u00e9n listas para manejar la carga.<\/p>\n

\"DEVOXX
\n
\nTodos los componentes del despliegue deben soportar alg\u00fan tipo de health check. Esto puede ser una verificaci\u00f3n HTTP sencilla, donde se recibe un c\u00f3digo con estado 200, o una verificaci\u00f3n m\u00e1s profunda, en la que se comprueba la conexi\u00f3n de las r\u00e9plicas con la base de datos y otros servicios, la resistencia de las conexiones en el entorno din\u00e1mico, y si todo se inicia y funciona correctamente. Este proceso puede ser bastante complicado. <\/p>\n

\"DEVOXX
\n
\nUna vez que el sistema verifique la funcionalidad de todas las r\u00e9plicas actualizadas, Deployer actualizar\u00e1 la configuraci\u00f3n y pasar\u00e1 el confd correcto, que reconfigurar\u00e1 ha-proxy. <\/p>\n

\"DEVOXX
\n
\nSolo despu\u00e9s de eso, el tr\u00e1fico se dirigir\u00e1 al pod con las r\u00e9plicas de la nueva versi\u00f3n y el antiguo pod desaparecer\u00e1. <\/p>\n

\"DEVOXX
\n
\nEste mecanismo no es exclusivo de Kubernetes. El concepto de Blue\/green deployment ha existido durante bastante tiempo, y siempre ha utilizado un balanceador de carga. Primero, se dirige todo el tr\u00e1fico a la versi\u00f3n antigua de la aplicaci\u00f3n y, despu\u00e9s de la actualizaci\u00f3n, se redirige completamente a la nueva versi\u00f3n. Este principio se utiliza no solo en Kubernetes.<\/p>\n

Ahora les presentar\u00e9 un nuevo componente de despliegue: Deployer, que realiza la verificaci\u00f3n de funcionalidad, reconfigura el proxy, etc. Este es un concepto que no se relaciona con el mundo exterior y existe dentro de Kubernetes. Les mostrar\u00e9 c\u00f3mo se puede crear su propio concepto de Deployer utilizando herramientas open-source. <\/p>\n

Entonces, lo primero que hace Deployer es crear un controlador de replicaci\u00f3n RC utilizando la API de Kubernetes. Esta API crea pods y servicios para futuros despliegues, es decir, crea un cl\u00faster completamente nuevo para nuestras aplicaciones. Una vez que el RC asegura que las r\u00e9plicas han iniciado, realizar\u00e1 una verificaci\u00f3n de su funcionamiento, el Health check. Para esto, Deployer utiliza el comando GET \/health. Este comando inicia los componentes de verificaci\u00f3n correspondientes y comprueba todos los elementos que garantizan el funcionamiento del cl\u00faster. <\/p>\n

\"DEVOXX
\n
\nDespu\u00e9s de que todos los pods informen sobre su \"salud\", Deployer crea un nuevo elemento de configuraci\u00f3n: un almacenamiento distribuido etcd, que se utiliza dentro de Kubernetes, incluyendo el almacenamiento de la configuraci\u00f3n del equilibrador de carga. Escribimos los datos en etcd, y una peque\u00f1a herramienta llamada confd monitorea etcd en busca de nuevos datos. <\/p>\n

Si detecta cambios en la configuraci\u00f3n original, genera un nuevo archivo de configuraci\u00f3n y lo pasa a ha-proxy. En este caso, ha-proxy se reinicia sin perder ninguna conexi\u00f3n y dirige la carga a los nuevos services, que aseguran el funcionamiento de la nueva versi\u00f3n de nuestras aplicaciones. <\/p>\n

\"DEVOXX
\n
\nComo pueden ver, a pesar de la abundancia de componentes, aqu\u00ed no hay nada complicado. Solo necesitan prestar un poco m\u00e1s de atenci\u00f3n a la API y a etcd. Quiero hablarles sobre un desplegador de c\u00f3digo abierto que nosotros mismos utilizamos: Amdatu Kubernetes Deployer.<\/p>\n

\"DEVOXX
\n
\nEs una herramienta para orquestar despliegues en Kubernetes, que tiene las siguientes funciones: <\/p>\n