servidores virtuales<\/a>, utilizamos Ansible, en el que los configs estaban en un mismo repositorio. Sin embargo, para la mayor\u00eda de los desarrolladores, trabajar con esto era algo m\u00e1s complicado. Aqu\u00ed, el volumen de configs y c\u00f3digo que necesitas agregar para desplegar el servicio se volvi\u00f3 mucho menor. Adem\u00e1s, para DevOps es muy f\u00e1cil corregirlo o cambiarlo. En casos de migraciones, por ejemplo, a una nueva versi\u00f3n de Nomad, pueden tomar y actualizar masivamente todos los archivos operativos que est\u00e1n en el mismo lugar.<\/li>\n<\/ol>\n\nPero tambi\u00e9n nos enfrentamos a algunas desventajas: <\/p>\n
Result\u00f3 que no pudimos lograr un despliegue sin interrupciones <\/b>en el caso de Nomad. Al lanzar contenedores desde diferentes condiciones, pod\u00eda suceder que se est\u00e9n ejecutando, y Nomad lo percibiera como un contenedor listo para aceptar tr\u00e1fico. Esto ocurr\u00eda incluso antes de que la aplicaci\u00f3n dentro de \u00e9l hubiera tenido tiempo de iniciarse. Por esta raz\u00f3n, el sistema comenzaba a emitir errores 500 durante un corto per\u00edodo de tiempo, porque el tr\u00e1fico empezaba a dirigirse a un contenedor que a\u00fan no estaba listo para aceptarlo. <\/p>\n
Nos encontramos con algunos errores<\/b>. El error m\u00e1s significativo es que Nomad no maneja muy bien un cl\u00faster grande si tiene muchos sistemas y contenedores. Cuando desea sacar uno de los servidores que forman parte del cl\u00faster Nomad para mantenimiento, hay una probabilidad bastante alta de que el cl\u00faster no funcione bien y se desmorone. Parte de los contenedores puede, por ejemplo, caer y no volver a levantarse, lo que le costar\u00e1 muy caro si todos sus sistemas de producci\u00f3n est\u00e1n en ese cl\u00faster gestionado por Nomad. <\/p>\n
Por eso decidimos pensar en a d\u00f3nde ir a continuaci\u00f3n. En ese momento comprendimos mucho mejor lo que quer\u00edamos lograr. Espec\u00edficamente: queremos fiabilidad, un poco m\u00e1s de funciones de las que ofrece Nomad y un sistema m\u00e1s maduro y estable. <\/p>\n
En este sentido, nuestra elecci\u00f3n recay\u00f3 en Kubernetes como la plataforma m\u00e1s popular para implementar cl\u00fasteres. Especialmente considerando que el tama\u00f1o y la cantidad de nuestros contenedores eran bastante grandes. Para estos fines, Kubernetes parec\u00eda ser el sistema m\u00e1s adecuado entre los que pod\u00edamos explorar. <\/p>\n
Transici\u00f3n a Kubernetes<\/h1>\n \nVoy a contar un poco sobre cu\u00e1les son los conceptos b\u00e1sicos de Kubernetes y en qu\u00e9 se diferencian de Nomad. <\/p>\n
Pod<\/b> \u2014 es un grupo de uno o varios contenedores que siempre se ejecutan juntos. Y funcionan como si estuvieran siempre estrictamente en una sola m\u00e1quina virtual. Se pueden comunicar entre s\u00ed a trav\u00e9s de la direcci\u00f3n IP 127.0.0.1 en diferentes puertos. <\/p>\n
Supongamos que tiene una aplicaci\u00f3n PHP que consiste en nginx y php-fpm: un esquema cl\u00e1sico. Es probable que desee que tanto los contenedores de nginx como de php-fpm est\u00e9n siempre juntos. Kubernetes permite lograr esto describi\u00e9ndolos como un pod com\u00fan. Esto era exactamente lo que no pod\u00edamos lograr con Nomad.<\/p>\n
El segundo concepto es deployment<\/b>. El hecho es que un pod por s\u00ed solo es una entidad ef\u00edmera, se inicia y desaparece. Ya sea que quiera eliminar todos sus contenedores anteriores y luego iniciar de inmediato nuevas versiones o si desea implementarlos gradualmente, es precisamente para este proceso que se encarga el concepto de deployment. Describe c\u00f3mo implementa sus pods, en qu\u00e9 cantidad y c\u00f3mo actualizarlos. <\/p>\n
El tercer concepto es el servicio<\/b>. Su servicio es, de hecho, su sistema, que recibe cierto tr\u00e1fico y luego lo dirige a uno o varios pods que corresponden a su servicio. Es decir, permite que todo el tr\u00e1fico entrante a un servicio con un nombre espec\u00edfico se env\u00ede a esos pods en particular. Y al mismo tiempo, le proporciona balanceo de carga. Esto significa que puede ejecutar dos pods de su aplicaci\u00f3n y todo el tr\u00e1fico entrante se equilibrar\u00e1 uniformemente entre los pods relacionados con ese servicio.<\/p>\n
Y el cuarto concepto principal es Ingress<\/b>. Es un servicio que se ejecuta en un cl\u00faster de Kubernetes. Act\u00faa como un balanceador de carga externo que recibe todas las solicitudes. Gracias a la API de Kubernetes, Ingress puede determinar a d\u00f3nde enviar esas solicitudes. Adem\u00e1s, lo hace de manera muy flexible. Puede especificar que todas las solicitudes a este host y a esta URL se env\u00edan a este servicio. Y esas solicitudes que llegan a este host y a otra URL se env\u00edan a otro servicio. <\/p>\n
Lo m\u00e1s genial desde la perspectiva de quien desarrolla la aplicaci\u00f3n es que puede gestionar todo esto de manera independiente. Al configurar Ingress, puede enviar todo el tr\u00e1fico que llega a una API espec\u00edfica a contenedores separados, escritos, por ejemplo, en Go. Y este tr\u00e1fico, que llega al mismo dominio, pero a otra URL, se env\u00eda a contenedores escritos en PHP, donde hay mucha l\u00f3gica, pero no son muy r\u00e1pidos.<\/p>\n
Si comparamos todos estos conceptos con Nomad, se puede decir que los primeros tres conceptos constituyen el Servicio en conjunto. Y el \u00faltimo concepto no existe en Nomad. En su lugar, utilizamos un balanceador de carga externo: puede ser haproxy, nginx, nginx+ y as\u00ed sucesivamente. En el caso de Kubernetes, no necesita introducir este concepto adicional por separado. Sin embargo, al observar Ingress internamente, se trata ya sea de nginx, haproxy o traefik, pero incorporado en Kubernetes. <\/p>\n
Todos los conceptos que he descrito son, en esencia, recursos que existen dentro del cl\u00faster de Kubernetes. Para describirlos en kubectl, se utiliza el formato yaml, que es m\u00e1s legible y familiar que los archivos HCL en el caso de Nomad. Pero estructuralmente describen lo mismo en el caso, por ejemplo, de un pod. Dicen: quiero desplegar ciertos pods all\u00ed, con estas im\u00e1genes, en esta cantidad. <\/p>\n
Conceptos Clave en Helm<\/h1>\n \nHelm es un gestor de paquetes<\/b> para Kubernetes. Es muy similar a c\u00f3mo funcionan los gestores de paquetes en los lenguajes de programaci\u00f3n. Te permiten almacenar un servicio que consiste, por ejemplo, en un deployment de nginx, un deployment de php-fpm, una configuraci\u00f3n para Ingress, configmaps (que es una entidad que te permite establecer env y otros par\u00e1metros para tu sistema) en forma de lo que se conoce como charts. Mientras tanto, Helm funciona sobre Kubernetes<\/b>. Es decir, no es un sistema independiente, sino simplemente otro servicio que se ejecuta dentro de la esfera. Te interact\u00faas con \u00e9l a trav\u00e9s de su API mediante un comando de consola. Su conveniencia y atractivo radican en que, incluso si helm falla o lo eliminas del cl\u00faster, tus servicios no desaparecer\u00e1n, ya que helm sirve esencialmente solo para iniciar el sistema. La operatividad y estado de los servicios son considerados por Kubernetes. <\/p>\n
Tambi\u00e9n entendimos que la plantillizaci\u00f3n<\/b>, que antes ten\u00edamos que hacer manualmente mediante la implementaci\u00f3n de jinja en nuestras configuraciones, es una de las principales capacidades de helm. Todas las configuraciones que creas para tus sistemas se almacenan en helm como plantillas, que son un poco similares a jinja, pero que, en realidad, utilizan la plantillizaci\u00f3n del lenguaje Go, en el que est\u00e1 escrito helm, al igual que Kubernetes. <\/p>\n
Helm nos agrega algunos conceptos adicionales. <\/p>\n
Gr\u00e1fico<\/b> \u2014 es la descripci\u00f3n de tu servicio. En otros gestores de paquetes se le llamar\u00eda paquete, bundle o algo similar. Aqu\u00ed se llama chart. <\/p>\n
Values <\/b>\u2013 son las variables que deseas utilizar para construir tus configuraciones a partir de las plantillas. <\/p>\n
Release<\/b>Cada vez que un servicio se despliega usando helm, recibe una versi\u00f3n incremental del lanzamiento. Helm recuerda cu\u00e1l era la configuraci\u00f3n del servicio en el lanzamiento anterior, en el antepen\u00faltimo y as\u00ed sucesivamente. Por lo tanto, si es necesario revertir, basta con ejecutar el comando helm callback, especificando la versi\u00f3n anterior del lanzamiento. Incluso si en el momento de la reversi\u00f3n la configuraci\u00f3n correspondiente no est\u00e1 disponible en su repositorio, helm a\u00fan recuerda cu\u00e1l era y revertir\u00e1 su sistema al estado en que se encontraba en el lanzamiento anterior. <\/p>\n
En el caso de que estemos utilizando helm, las configuraciones normales para Kubernetes tambi\u00e9n se convierten en plantillas, en las que es posible usar variables, funciones y aplicar operadores condicionales. De esta forma, puede construir la configuraci\u00f3n de su servicio en funci\u00f3n del entorno.<\/p>\n
A pesar de que en los propios archivos de configuraci\u00f3n no almacenamos datos realmente sensibles, como contrase\u00f1as de bases de datos, las cuales se guardan como secretos en Kubernetes, a\u00fan as\u00ed hay cosas espec\u00edficas a las que no queremos dar acceso a todos. Por lo tanto, el acceso al repositorio 'deploy' es m\u00e1s restringido, mientras que el repositorio 'helm' contiene simplemente la descripci\u00f3n del servicio. Por esta raz\u00f3n, se puede otorgar acceso de manera segura a un p\u00fablico m\u00e1s amplio. <\/p>\n
Dado que tenemos no solo producci\u00f3n sino tambi\u00e9n otros entornos, gracias a esta separaci\u00f3n podemos reutilizar nuestros gr\u00e1ficos de helm para desplegar servicios no solo en producci\u00f3n, sino tambi\u00e9n, por ejemplo, en entornos de QA. Incluso para desplegarlos localmente, usando Minikube<\/i> \u2014 es una herramienta para el lanzamiento local de Kubernetes. <\/p>\n
Dentro de cada repositorio hemos mantenido una separaci\u00f3n en directorios individuales para cada servicio. Es decir, dentro de cada directorio se encuentran las plantillas que pertenecen a la carta correspondiente y que describen los recursos que deben ser desplegados para poner en marcha nuestro sistema. En el repositorio 'deploy' hemos dejado \u00fanicamente los entornos. En este caso, no utilizamos la templating con jinja, porque helm proporciona templating por s\u00ed mismo, siendo esta una de sus principales funciones. <\/p>\n
Hemos dejado un script para el despliegue \u2013 deploy.sh, que simplifica y estandariza el lanzamiento para el despliegue con helm. Por lo tanto, para cualquiera que desee desplegar, la interfaz de despliegue se ve exactamente igual a como era en el caso del despliegue a trav\u00e9s de Nomad. El mismo deploy.sh, el nombre de tu servicio y a d\u00f3nde deseas desplegarlo. Esto provoca que dentro se active helm. A su vez, re\u00fane las configuraciones de las plantillas, inserta los archivos de valores necesarios y luego despliega, envi\u00e1ndolos a Kubernetes. <\/p>\n
Conclusiones<\/h1>\n \nEl servicio de Kubernetes parece m\u00e1s complejo que Nomad. <\/p>\n
Al hacer la transici\u00f3n, notamos que Kubernetes tiene todas las capacidades de Nomad, que utilizamos anteriormente, y adem\u00e1s agrega muchas nuevas. Se puede extender a trav\u00e9s de plugins, y en realidad a trav\u00e9s de tipos de recursos personalizados. Es decir, no solo tienes la opci\u00f3n de utilizar algo que viene en Kubernetes por defecto, sino que puedes crear tu propio recurso y servicio que leer\u00e1 su recurso. Esto ofrece oportunidades adicionales para ampliar tu sistema sin necesidad de reinstalar Kubernetes y sin requerir cambios. <\/p>\n
Un ejemplo de este tipo de uso es Prometheus, que se ejecuta dentro de nuestro cl\u00faster de Kubernetes. Para que comience a recopilar m\u00e9tricas de un servicio en particular, necesitamos agregar un tipo de recurso adicional en la descripci\u00f3n del servicio, llamado monitor de servicio. Prometheus, al poder leer un tipo de recursos personalizados cuando se ejecuta en Kubernetes, comienza autom\u00e1ticamente a recopilar m\u00e9tricas del nuevo sistema. Esto resulta bastante conveniente. <\/p>\n
El primer despliegue que hicimos en Kubernetes fue en marzo de 2018. Y durante este tiempo, nunca hemos tenido problemas con \u00e9l. Funciona de manera bastante estable sin errores significativos. Adem\u00e1s, podemos extenderlo a\u00fan m\u00e1s. Hasta la fecha, tenemos suficientes capacidades disponibles en \u00e9l, y nos gusta mucho el ritmo de desarrollo de Kubernetes. Actualmente, hay m\u00e1s de 3000 contenedores en Kubernetes. El cl\u00faster ocupa varios nodos. Aun as\u00ed, es manejable, estable y muy controlable.habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u041f\u0430\u0432\u0435\u043b \u0410\u0433\u0430\u043b\u0435\u0446\u043a\u0438\u0439. \u042f \u0440\u0430\u0431\u043e\u0442\u0430\u044e \u0442\u0438\u043c\u043b\u0438\u0434\u043e\u043c \u0432 \u043a\u043e\u043c\u0430\u043d\u0434\u0435, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0435\u0442 \u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0438 Lamoda. \u0412 2018 \u0433\u043e\u0434\u0443 \u044f \u0432\u044b\u0441\u0442\u0443\u043f\u0430\u043b \u043d\u0430 \u043a\u043e\u043d\u0444\u0435\u0440\u0435\u043d\u0446\u0438\u0438 HighLoad++, \u0430 \u0441\u0435\u0433\u043e\u0434\u043d\u044f \u0445\u043e\u0447\u0443 \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u0442\u044c \u0440\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u0443 \u0441\u0432\u043e\u0435\u0433\u043e \u0434\u043e\u043a\u043b\u0430\u0434\u0430. \u041c\u043e\u044f \u0442\u0435\u043c\u0430 \u043f\u043e\u0441\u0432\u044f\u0449\u0435\u043d\u0430 \u043e\u043f\u044b\u0442\u0443 \u043d\u0430\u0448\u0435\u0439 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u043f\u043e \u0434\u0435\u043f\u043b\u043e\u044e \u0441\u0438\u0441\u0442\u0435\u043c \u0438 \u0441\u0435\u0440\u0432\u0438\u0441\u043e\u0432 \u0432 \u0440\u0430\u0437\u043d\u044b\u0435 \u0441\u0440\u0435\u0434\u044b. \u041d\u0430\u0447\u0438\u043d\u0430\u044f \u043e\u0442 \u043d\u0430\u0448\u0438\u0445 \u0434\u043e\u0438\u0441\u0442\u043e\u0440\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u0432\u0440\u0435\u043c\u0435\u043d, \u043a\u043e\u0433\u0434\u0430 \u043c\u044b \u0434\u0435\u043f\u043b\u043e\u0438\u043b\u0438 \u0432\u0441\u0435 \u0441\u0438\u0441\u0442\u0435\u043c\u044b […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":25343,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-33654","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Reproducir](\"https:\/\/img.youtube.com\/vi\/oqrb7dWECSo\/hqdefault.jpg\")
\r\n