El festival RIT 2018 en Skolkovo fue grande y muy diverso. El desarrollo móvil, backend, frontend, DevOps, gestión de proyectos e incluso psicología son temas para todos los gustos y en un horario ocupado desde la mañana hasta la noche. Los temas se dividen en pistas separadas, las pistas están vinculadas a los pasillos. Si solo le interesan los informes especializados, puede instalarse en la habitación correcta. La sala principal, sin embargo, fue utilizada según lo necesitado por los oradores de diversos temas.
En general, me iluminé con el conocimiento de DevOps, y después de compartir mis impresiones de la conferencia con mis colegas, formé una breve lista de informes que recordaba. Pasaron varios meses y todavía recuerdo bien de qué estaban hablando.
Entonces, 3 informes técnicos que recordé en RIT 2018.
Monitoreo y Kubernetes
Las herramientas de monitoreo utilizadas ahora no son tan compatibles con las aplicaciones de arquitectura de microservicios. Mientras más dinámica haya en el sistema, más difícil será configurar el monitoreo para él. El monitoreo conveniente para sistemas de clúster como Kubernetes, que llevan la dinámica al extremismo, generalmente no es una tarea trivial. Por qué Dmitry Stolyarov, director técnico de Flant, habla sobre los motivos de esta complejidad y su impacto en la misión principal de monitoreo.
Los sistemas de monitoreo tradicionales dependen del trabajo con servidores estáticos, que se agregan y eliminan de la infraestructura de la aplicación de manera relativamente rara. En Kubernetes, la creación y eliminación de entornos de hogar y aplicaciones de servicio ocurre cada segundo, por lo que los procedimientos de descubrimiento automático existentes simplemente no pueden hacer frente a este volumen.
El número de entornos en sí también está en las decenas y cientos. En consecuencia, la cantidad de telemetría transmitida aumenta en la misma cantidad. Y ella todavía necesita ser almacenada en algún lugar.
Otro problema es la colisión de los mundos físico y virtual: el consumo de recursos por parte de las aplicaciones en Kubernetes es bastante efímero y se refleja en términos de restricciones en los hogares. Pero el consumo de recursos de pod ya tiene un efecto físico específico en las capacidades de servidor disponibles. Al mirar los gráficos, siempre debe considerar desde qué punto de vista mira los recursos. En la práctica, pocas personas están interesadas en cápsulas individuales. De interés es el consumo de recursos por parte de la aplicación en su conjunto, y esto ya requiere una agrupación flexible de módulos de telemetría de acuerdo con algunos criterios definidos por los usuarios.
¡Y necesita aumentar el esquema resultante varias veces para los entornos de desarrollo / puesta en escena / producción generalizados!
El informe se recomienda a cualquiera que tenga que admitir el clúster kubernetes.
Enlace a la presentación.
Devops de desarrollo de cajas
Fue extremadamente interesante para nosotros escuchar el informe de Maxim Lapshin, en el que compartió la rara experiencia de utilizar prácticas deficientes en el desarrollo de productos en caja. Un producto en caja es un software tradicional que se instala y ejecuta en las capacidades del usuario.
Erlyvideo está desarrollando un servidor de transmisión de video, somos un servidor de configuración de servicios de Internet. Nuestros problemas son en muchos aspectos similares a los que causaron la transformación DevOps de ErOlvideo.
Maxim comienza el informe con una respuesta a la pregunta más importante: "¿Para qué sirve todo esto?" Los mismos factores que impulsan la introducción de la cultura DevOps en el desarrollo de servicios también están presentes en las industrias donde se está desarrollando un desarrollo más tradicional. Y la influencia de estos factores en los productos en caja probablemente será más dramática que cuando se trabaja en un servicio. Por ejemplo, cuantas menos versiones, mayor será el volumen de cambios que se implementarán. Si está implementando un nuevo servicio, puede asegurarse o simplemente convencerse de que es seguro. Pero si lanza una distribución de productos con una gran cantidad de cambios, no es suficiente para convencerse de la seguridad de la actualización, también tendrá que convencer a sus usuarios de su seguridad. Pequeños pero frecuentes trozos de cambio vienen al rescate aquí. Y este es solo uno de los problemas.
El informe profundiza en esta y muchas otras razones para usar la entrega continua, establecer paralelos y enfatizar las diferencias con el trabajo generalmente más simple en modo CI / CD con servicios.
¿Cómo es esto posible? En el informe, Maxim describe el conjunto de prácticas utilizadas en Erlyvideo para hacer que la entrega continua del flujo de cambios sea real. Muchos enfoques serán útiles tal cual, algo requerirá adaptación a las realidades de nuestro trabajo. Pero, en cualquier caso, esta maravillosa historia de éxito puede inspirar a repensar sus problemas y encontrar soluciones en una variedad de prácticas de DevOps.
El informe será muy interesante para todos los que trabajan en distribuciones de productos.
Enlace a la presentación.
Bases de red de Kubernetes
La omnipresente guía de inicio rápido, el curso intensivo y los tutoriales "Cómo comenzar con kubernetes" hacen que sea relativamente fácil subirse a este automóvil, implementar un clúster e implementar la aplicación. Dada la increíble popularidad de este tema, muchos lo hacen. Pero no olvide que, en esencia, Kubernetes es un sistema bastante complejo, cuyo mantenimiento requiere un conocimiento específico. En Ingram Micro Cloud, este conocimiento era necesario cuando la siguiente aplicación repentinamente no estaba disponible en la red. A partir de la investigación de este incidente, comenzó el fascinante viaje de Alexander Khayorov a través del subsistema de red.
El informe nos presenta los elementos cada vez más complejos de la pila de red de Kubernetes, explicando cómo el enrutamiento grande y complejo está formado por bloques elementales. Resulta especialmente interesante cuando Alexander habla sobre por qué se hace esto, y no de otra manera, modelando otras opciones de implementación hipotéticas.
Este es realmente el alfabeto de Kubernetes que la mayoría de los usuarios encontrarán. Yo mismo hice las preguntas "¿por qué nodePort?" y "¿por qué no veo la IP de mi servicio en la interfaz?"
Interesante e informativo.
Enlace a la presentación.