A finales de mayo se llevó a cabo un meetup en línea sobre . Hablamos sobre contenedores, Kubernetes y la orquestación en general, sobre los criterios para elegir la infraestructura y mucho más. Los participantes compartieron casos de su propia práctica.
Participantes:
- Evgeny Potapov, CEO de «ITSumma». Más de la mitad de sus clientes ya están migrando o quieren migrar a Kubernetes.
- Dmitry Stolyarov, CTO de «Flant». Tiene más de 10 años de experiencia en sistemas de contenedores.
- Denis Remchukov (alias Eric Oldmann), COO de argotech.io, ex-RAO EES. Prometió hablar sobre casos en el ‘sanguinario’ enterprise.
- Andrei Fedorovsky, CTO de «News360.com»Tras la compra de la empresa por parte de otro jugador, es responsable de varios proyectos de ML y AI y de la infraestructura.
- Ivan Kruglov, ingeniero de sistemas, ex-Booking.com.Esa misma persona que ha hecho mucho con Kubernetes por sí misma.
Temas:
- Perspectivas de los participantes sobre contenedores y orquestación (Docker, Kubernetes y otros); lo que han probado en la práctica o analizado.
- Caso: La empresa está construyendo un plan de desarrollo de infraestructura a varios años. ¿Cómo se toma la decisión de construir (o trasladar la actual) infraestructura basada en contenedores y Kubernetes o no?
- Problemas en el mundo del cloud-native, qué falta, vamos a imaginar qué pasará mañana.
Se generó una discusión interesante, las opiniones de los participantes resultaron tan diferentes y provocaron tantos comentarios que nos gustaría compartirlos con ustedes. Hay , y a continuación, un resumen de la discusión.
¿Kubernetes es ya un estándar o una excelente estrategia de marketing?
«Nosotros llegamos a él (Kubernetes. — N. del R.) cuando aún nadie sabía de él. Llegamos a él incluso antes de que existiera. Lo queríamos mucho antes» — Dmitry Stolyarov
Foto de Reddit.com
Hace 5-10 años existía una gran cantidad de herramientas y no había un estándar único. Cada seis meses aparecía un nuevo producto, a veces más de uno. Primero Vagrant, luego Salt, Chef, Puppet,… «y cada seis meses reconstruyes tu infraestructura. Tienes cinco administradores que están constantemente ocupados en reescribir los configs» — recuerda Andrei Fedorovsky. Él considera que Docker y Kubernetes «han aplastado» a los demás. Docker se convirtió en el estándar en los últimos cinco años, Kubernetes — en los últimos dos años. Y eso es bueno para la industria..
Dmitri Stolyarov y su equipo aman Kubernetes. Quisieron esta herramienta antes de que existiera y llegaron a ella cuando aún nadie la conocía. En este momento, por razones de conveniencia, no aceptan clientes si entienden que no implementarán Kubernetes. Sin embargo, según Dmitri, la compañía tiene "numerosas historias de éxito gigantescas en la transformación de un legado espantoso".
Kubernetes no es solo orquestación de contenedores, es un sistema de gestión de configuración con una API avanzada, un componente de trabajo de red, balanceo de carga L3 y controladores Ingress, que permite gestionar recursos de manera relativamente sencilla, escalar y abstraerse de las capas inferiores de infraestructura.
Desafortunadamente, en nuestra vida hay que pagar por todo. Y este impuesto es alto, especialmente al hablar de la transición a Kubernetes para empresas con infraestructuras avanzadas, según Ivan Kruglov. Él podría trabajar con facilidad tanto en una empresa con infraestructura tradicional como con Kubernetes. Lo principal es comprender las características de la empresa y del mercado. Pero, por ejemplo, para Evgeny Potapov, que resumiría Kubernetes como cualquier herramienta de orquestación de contenedores, este tema no se plantea.
Evgeny hizo una analogía con la situación en la década de 1990, cuando surgió la programación orientada a objetos como forma de programar aplicaciones complejas. En ese momento, los debates no cesaban y surgían nuevas herramientas que apoyaban la POO. Luego vinieron los microservicios como una forma de alejarse de la concepción monolítica. Esto, a su vez, condujo a la aparición de contenedores y herramientas para gestionarlos. "Creo que pronto llegaremos al punto donde no se planteará la cuestión de si se debe escribir una pequeña aplicación de forma microservicio; se hará por defecto como microservicio", dice él. De manera similar, Docker y Kubernetes se convertirán con el tiempo en la solución estándar sin necesidad de elección.
El problema de las bases es stateless
Foto de
Hoy en día hay muchas recetas para ejecutar bases de datos en Kubernetes. Incluso, cómo separar la parte que trabaja con disco I/O de, por así decirlo, la parte de la aplicación de la base. ¿Es posible que en el futuro las bases de datos cambien tanto que se suministren en un paquete donde una parte se gestione a través de Docker y Kubernetes, mientras que la otra parte, a través de software separado, proporcione la parte de almacenamiento? ¿Cambiarán las bases como producto?
Esta descripción se asemeja a la gestión de colas, pero las demandas de fiabilidad y sincronización de la información en las bases de datos tradicionales son mucho más altas, opina Andrey. La tasa de aciertos de caché en las bases normales se mantiene alrededor del 99%. Si un worker falla, se inicia uno nuevo, y la caché se 'calienta' desde cero. Mientras la caché no esté caliente, el worker trabaja lento, lo que significa que no se puede cargar con la carga de usuarios. Mientras no hay carga de usuarios, la caché no se calienta. Este es un círculo vicioso.
Dmitry no está de acuerdo en absoluto: los quorums y el sharding resuelven el problema. Pero Andrey insiste en que la solución no es adecuada para todos. En algunas situaciones, un quorum puede ser apropiado, pero esto genera una carga adicional en la red. La base de datos NoSQL no es adecuada en todos los casos.
Los participantes del meetup se dividieron en dos grupos.
Denis y Andrey afirman que todo lo que se escribe en disco — bases de datos y demás — es imposible en el ecosistema actual de Kubernetes. No es posible mantener la integridad y consistencia de los datos productivos en Kubernetes. Esta es una característica fundamental. Solución: infraestructura híbrida.
Incluso las bases de datos cloud native modernas, como MongoDB y Cassandra, o los sistemas de mensajería, como Kafka o RabbitMQ, requieren almacenamiento persistente fuera de Kubernetes.
Evgeny objeta: "Las bases en Kubernetes son una herencia traumática en torno a Rusia o alrededor de la empresa, relacionada con la falta de adopción de la nube en Rusia". Las pequeñas o medianas empresas en Occidente ya están en la nube. Utilizar bases de datos Amazon RDS es más fácil que lidiar con Kubernetes por su cuenta. En Rusia, se utiliza Kubernetes 'on-premise' y se trasladan las bases a él cuando intentan deshacerse del zoológico.
Dmitry también no estuvo de acuerdo con la afirmación de que no se pueden mantener bases de datos en Kubernetes: "Cada base es diferente. Y si intentas meter una gigantesca base de datos relacional — no, en ningún caso. Si intentas meter algo pequeño y cloud native, que esté moralmente preparado para una vida semi-efímera, todo irá bien." Dmitry también mencionó que las herramientas de gestión de bases no están preparadas ni para Docker ni para Kubernetes, por lo que surgen grandes complicaciones.
Iván, por su parte, está convencido de que, incluso si se abstrae del concepto de stateful y stateless, el ecosistema de soluciones empresariales en Kubernetes aún no está listo. Es difícil cumplir con los requisitos de las entidades legislativas y regulatorias con Kubernetes. Por ejemplo, no es posible crear una solución de provisión de identidad que requiera estrictas garantías de identificación del servidor, hasta el hardware que se inserta en los servidores. Este campo está en desarrollo, pero todavía no hay soluciones.
Los participantes no lograron llegar a un acuerdo, por lo que no habrá conclusiones en esta parte. Mejor presentaremos un par de ejemplos prácticos.
Caso 1. Ciberseguridad del 'megaregulador' con bases de datos fuera de Kubernetes.
En el caso de un sistema de ciberseguridad avanzado, el uso de contenedores y orquestación permite defenderse de ataques e intrusiones. Por ejemplo, en un megaregulador, Denis y su equipo implementaron una combinación de orquestador con un servicio SIEM entrenado, que analiza registros en tiempo real y determina el proceso de ataque, intrusión o fallo. En caso de ataque, intento de introducir algo, o durante una infección por virus de rescate, él, a través del orquestador, despliega contenedores con aplicaciones más rápido de lo que se infectan o más rápido de lo que es atacado por un intruso.
Caso 2. La migración parcial de bases de datos de Booking.com a Kubernetes.
En Booking.com, la base de datos principal es MySQL con replicación asíncrona — hay un master y toda una jerarquía de esclavos. En el momento en que Iván dejó la empresa, se había iniciado un proyecto para trasladar los esclavos, que se pueden 'desconectar' con cierto daño.
Además de la base de datos principal, hay una instalación de Cassandra con orquestación propia, desarrollada antes de que Kubernetes saliera al mainstream. No hay problemas en este sentido, pero tiene almacenamiento persistente en SSD locales. Almacenamientos remotos, incluso dentro de un mismo centro de datos, no se utilizan debido a problemas de alta latencia.
La tercera clase de bases de datos es el servicio de búsqueda de Booking.com, donde cada nodo del servicio es una base de datos. Los intentos de trasladar el servicio de búsqueda a Kubernetes no tuvieron éxito, ya que cada nodo tiene entre 60 y 80 GB de almacenamiento local, que es difícil de 'activar' y 'calentar'.
Como resultado, el motor de búsqueda no fue trasladado a Kubernetes, e Iván no cree que haya nuevos intentos en un futuro cercano. La base de datos MySQL fue trasladada a medias: solo los esclavos, que no es un gran riesgo 'desconectar'. Cassandra 'se ha asentado' muy bien.
La elección de la infraestructura como un reto sin solución única
Foto de
Supongamos que tenemos una nueva empresa, o una empresa donde parte de la infraestructura se ha construido de forma anticuada. En ella se está desarrollando un plan de desarrollo de infraestructura a varios años. ¿Cómo se toma la decisión de construir la infraestructura sobre contenedores y Kubernetes o no?
Las empresas que luchan por nanosegundos están excluidas de la discusión. Un saludable conservadurismo se paga por razones de fiabilidad, pero aun así, hay empresas que deberían considerar nuevos enfoques.
Iván: "Sin duda, ahora comenzaría una empresa en la nube, simplemente porque es más rápido", aunque no necesariamente más barato. Con el desarrollo del capital de riesgo, las startups no tienen problemas de dinero, y la tarea principal es conquistar el mercado.
Iván sostiene que el desarrollo de la infraestructura actual es un criterio de elección. Si en el pasado se hicieron inversiones significativas, y eso está funcionando, entonces no tiene sentido rehacerlo. Pero si la infraestructura no está desarrollada y hay problemas con las herramientas, la seguridad y el monitoreo, entonces vale la pena considerar una infraestructura distribuida.
Habrá que pagar impuestos de todos modos, y Iván pagaría aquel que le permitiera pagar menos en el futuro. "Porque simplemente por el hecho de que viajo en un tren que es movido por otros, llegaré mucho más lejos que si subo a otro tren en el que tengo que poner la gasolina yo mismo." —dice Iván. Cuando una empresa es nueva y los requisitos de latencia son de decenas de milisegundos, Iván miraría hacia los "operadores", donde hoy se "envuelven" las bases de datos clásicas. Ellos establecen una cadena de replicación que se conmutará automáticamente en caso de failover, etc.
Para una pequeña empresa con un par de servidores en Kubernetes no tiene sentido, —afirma Andrei. Pero si planea crecer hasta cien servidores y más, entonces se necesita automatización y un sistema de gestión de recursos. El 90% de los casos justifican los gastos. Y esto, independientemente del nivel de carga y recursos. A todos, desde startups hasta grandes empresas con millones de audiencia, les convendría ir mirando gradualmente los productos para la orquestación de contenedores. "Sí, definitivamente es el futuro", —está convencido Andrei.
Denis destacó dos criterios principales — escalabilidad y resiliencia operativa. Él elegirá las herramientas que mejor se adapten a esta tarea. «Puede ser un desconocido ensamblado a mano, corriendo Nutanix Community Edition. Puede ser una segunda línea en forma de aplicación en Kuber con una base de datos en el backend, que se replica y tiene parámetros RTO y RPO establecidos» (objetivos de tiempo/punto de recuperación — ejemplo).
Evgeny señaló un posible problema con el personal. Actualmente, no hay muchos especialistas de alta calidad que entiendan "los entresijos". De hecho, si la tecnología elegida es antigua, es difícil contratar a alguien que no sean personas mayores aburridas y cansadas de la vida. Sin embargo, otros participantes creen que este es un problema de formación de personal.
Si se plantea la cuestión de elegir: lanzar una pequeña empresa en Public Cloud con bases en Amazon RDS o 'on premise' con bases en Kubernetes, a pesar de algunas desventajas, la elección de los participantes fue Amazon RDS.
Dado que la mayoría de los oyentes del meetup no proviene del "sangre" del enterprise, las soluciones distribuidas son a lo que debemos aspirar. Los sistemas de almacenamiento de datos deben ser distribuidos, fiables y generar latencias medibles en unidades de milisegundos, como máximo decenas., — resumió Andrey.
Evaluación del uso de Kubernetes
El oyente Anton Zhbankov hizo una pregunta trampa a los apologistas de Kubernetes: ¿cómo eligieron y realizaron el análisis técnico-económico? ¿Por qué Kubernetes, por qué no máquinas virtuales, por ejemplo?
Foto de
A esto respondieron Dmitry e Ivan. En ambos casos, mediante prueba y error, se hizo una secuencia de decisiones, como resultado de la cual ambos participantes llegaron a Kubernetes. Ahora el negocio comienza a desarrollar por sí mismo software que tiene sentido trasladar a Kuber. No se trata de sistemas externos clásicos, como 1C. Kubernetes ayuda cuando los desarrolladores necesitan realizar lanzamientos de manera rápida, durante la mejora continua sin interrupciones.
El equipo de Andrey intentó crear un clúster escalable basado en máquinas virtuales. Los nodos caían como fichas de dominó, lo que a veces provocaba la caída del clúster. «Teóricamente se podría terminar y mantener manualmente, pero es tedioso. Y si en el mercado hay una solución que permite trabajar fuera de la caja, entonces nos dirigimos a ella con gusto. Y así lo hicimos al final.», — cuenta Andrey.
Existen estándares para tal análisis y cálculo, pero nadie dirá cuán válidos son en hardware real en operación. Para los cálculos, también es importante entender cada herramienta y ecosistema, pero esto es imposible.
Qué nos espera
Foto de
A medida que las tecnologías avanzan, surgen más piezas dispares y luego ocurre una transición de fase, surge un proveedor que ha acumulado suficiente 'capital' para unir todo en una única herramienta.
¿No les parece que llegará un momento en que habrá una herramienta que se volverá lo que Ubuntu es para el mundo de Linux? Es posible que una herramienta unificada de contenedorización y orquestación incorpore también Kubernetes. Con ello, será fácil construir nubes on-premise.
La respuesta la dio Ivan: 'Google está construyendo Anthos en este momento, que es su oferta de paquete que despliega la nube e incluye Kubernetes, Service Mesh, monitoreo, toda la infraestructura necesaria para microservicios en on-premise. Estamos casi en el futuro.'
Denis también mencionó a Nutanix y VMware con su producto vRealize Suite, que pueden abordar esta tarea sin contenedorización.
Dmitry compartió la opinión de que reducir el 'dolor' y disminuir la carga impositiva son dos áreas donde se deben esperar mejoras.
Resumiendo la discusión, destacamos los siguientes problemas de la infraestructura moderna
- Tres participantes identificaron un problema con los stateful.
- Diversos problemas de soporte de seguridad, incluida la posibilidad de que varias versiones de Python, servidores de aplicaciones y componentes terminen en Docker.
El desperdicio, sobre el cual sería mejor realizar un mitap separado.
El problema del aprendizaje, ya que la orquestación es un ecosistema complejo.
Un problema general de la industria es el uso de herramientas para propósitos no destinados.Las demás conclusiones las dejaremos a usted. Aún queda la sensación de que la combinación Docker+Kubernetes tiene dificultades para convertirse en la parte 'central' del sistema. Por ejemplo, los sistemas operativos se instalan en el hardware primero, lo que no se puede decir de los contenedores y la orquestación. Quizás en el futuro se integren los sistemas operativos y los contenedores con el software de gestión de la nube.
Foto deAprovecho la ocasión para saludar a mamá y recordar que tenemos un grupo en Facebook , canal con publicaciones interesantes de diferentes blogs tecnológicos. Y mi canal , donde hablo sobre la gestión del desarrollo en empresas de productos.
Fuente: habr.com
