A fines de mayo celebró una reunión en línea sobre el tema . Hablamos de contenedores, Kubernetes y orquestación en principio, criterios para elegir infraestructura y mucho más. Los participantes compartieron casos de su propia práctica.
Participantes:
- Evgeniy Potapov, director general de ITSumma. Más de la mitad de sus clientes ya se están mudando o quieren cambiarse a Kubernetes.
- Dmitry Stolyarov, director de tecnología de "Flant". Tiene más de 10 años de experiencia trabajando con sistemas de contenedores.
- Denis Remchukov (también conocido como Eric Oldmann), director de operaciones de argotech.io, ex-RAO UES. Prometió hablar de casos de la empresa “sangrienta”.
- Andrey Fedorovsky, director de tecnología de “News360.com”Después de que otro jugador comprara la empresa, es responsable de una serie de proyectos e infraestructura de ML e IA.
- Ivan Kruglov, ingeniero de sistemas, ex-Booking.com.La misma persona que hizo muchas cosas con Kubernetes con sus propias manos.
Temas:
- Ideas de los participantes sobre contenedores y orquestación (Docker, Kubernetes, etc.); lo que se intentó en la práctica o se analizó.
- Caso: La empresa lleva años elaborando un plan de desarrollo de infraestructuras. ¿Cómo se toma la decisión de construir (o migrar la infraestructura actual) a contenedores y Kuber o no?
- Problemas en el mundo nativo de la nube, lo que falta, imaginemos lo que pasará mañana.
Siguió una discusión interesante, las opiniones de los participantes fueron tan diferentes y provocaron tantos comentarios que quiero compartirlos con ustedes. Comer , y a continuación se muestra un resumen de la discusión.
¿Kubernetes ya es un estándar o un gran marketing?
“Llegamos a esto (Kubernetes. - Ed.) cuando nadie lo sabía todavía. Acudimos a él incluso cuando él no estaba allí. Lo queríamos antes" - Dmitri Stoliarov
Foto de Reddit.com
Hace 5 a 10 años había una gran cantidad de herramientas y no existía un estándar único. Cada seis meses aparecía un nuevo producto, o incluso más de uno. Primero Vagrant, luego Salt, Chef, Puppet,... “y reconstruyes tu infraestructura cada seis meses. Tienes cinco administradores que están constantemente ocupados reescribiendo configuraciones”, recuerda Andrey Fedorovsky. Él cree que Docker y Kubernetes han “desplazado” al resto. Docker se ha convertido en un estándar en los últimos cinco años y Kubernetes en los últimos dos. Y es bueno para la industria..
Dmitry Stolyarov y su equipo adoran a Kuber. Querían una herramienta así antes de que apareciera y acudieron a ella cuando nadie sabía de su existencia. Actualmente, por motivos de comodidad, no contratan a un cliente si entienden que no implementarán Kubernetes con él. Al mismo tiempo, según Dmitry, la empresa tiene "muchas historias de éxito gigantescas sobre la reconstrucción del terrible legado".
Kubernetes no es solo orquestación de contenedores, es un sistema de gestión de configuración con una API desarrollada, un componente de red, equilibrio L3 y controladores de ingreso, lo que hace que sea relativamente fácil administrar recursos, escalar y abstraer desde las capas inferiores de la infraestructura.
Lamentablemente, en nuestra vida tenemos que pagar por todo. Y este impuesto es elevado, sobre todo si hablamos de la transición a Kubernetes de una empresa con una infraestructura desarrollada, como cree Ivan Kruglov. Podía trabajar libremente tanto en una empresa con infraestructura tradicional como con Kuber. Lo principal es comprender las características de la empresa y del mercado. Pero, por ejemplo, para Evgeny Potapov, que generalizaría Kubernetes a cualquier herramienta de orquestación de contenedores, esa pregunta no surge.
Evgeniy hizo una analogía con la situación de la década de 1990, cuando apareció la programación orientada a objetos como una forma de programar aplicaciones complejas. En ese momento, el debate continuó y aparecieron nuevas herramientas para apoyar la programación orientada a objetos. Entonces surgieron los microservicios como una forma de alejarse del concepto monolítico. Esto, a su vez, condujo a la aparición de contenedores y herramientas de gestión de contenedores. "Creo que pronto llegaremos a un momento en el que no habrá dudas sobre si vale la pena escribir una pequeña aplicación de microservicio; por defecto, se escribirá como un microservicio", cree. Asimismo, Docker y Kubernetes eventualmente se convertirán en la solución estándar sin necesidad de elegir.
El problema de las bases de datos en estados sin estado.
Foto por
Hoy en día, existen muchas recetas para ejecutar bases de datos en Kubernetes. Incluso cómo separar la parte que funciona con el disco de E/S de, condicionalmente, la parte de aplicación de la base de datos. ¿Es posible que en el futuro las bases de datos cambien tanto que se entreguen en una caja, donde una parte se orquestará a través de Docker y Kubernetes, y en otra parte de la infraestructura, a través de un software separado, se proporcionará la parte de almacenamiento? ? ¿Cambiarán las bases como producto?
Esta descripción es similar a la gestión de colas, pero los requisitos de confiabilidad y sincronización de la información en las bases de datos tradicionales son mucho mayores, cree Andrey. La tasa de aciertos de caché en las bases de datos normales se mantiene en el 99%. Si un trabajador deja de funcionar, se inicia uno nuevo y el caché se "calienta" desde cero. Hasta que la caché se calienta, el trabajador trabaja lentamente, lo que significa que no se puede cargar con la carga del usuario. Si bien no hay carga de usuarios, el caché no se calienta. Es un círculo vicioso.
Dmitry no está de acuerdo fundamentalmente: los quórumes y la fragmentación resuelven el problema. Pero Andrey insiste en que la solución no es adecuada para todos. En algunas situaciones, el quórum es adecuado, pero supone una carga adicional para la red. Una base de datos NoSQL no es adecuada en todos los casos.
Los participantes de la reunión se dividieron en dos bandos.
Denis y Andrey argumentan que todo lo que se escribe en el disco (bases de datos, etc.) es imposible de hacer en el ecosistema actual de Kuber. Es imposible mantener la integridad y coherencia de los datos de producción en Kubernetes. Ésta es una característica fundamental. Solución: infraestructura híbrida.
Incluso las bases de datos modernas nativas de la nube, como MongoDB y Cassandra, o colas de mensajes como Kafka o RabbitMQ, requieren almacenes de datos persistentes fuera de Kubernetes.
Evgeniy objeta: "Las bases en Kubera son un daño casi ruso o casi empresarial, que se debe al hecho de que no hay adopción de la nube en Rusia". Las pequeñas o medianas empresas de Occidente son la Nube. Las bases de datos de Amazon RDS son más fáciles de usar que jugar con Kubernetes usted mismo. En Rusia utilizan Kuber “on-premise” y le transfieren bases cuando intentan deshacerse del zoológico.
Dmitry tampoco estuvo de acuerdo con la afirmación de que no se pueden mantener bases de datos en Kubernetes: “La base es diferente de la base. Y si impulsa una base de datos relacional gigante, bajo ninguna circunstancia. Si impulsas algo pequeño y nativo de la nube, que esté mentalmente preparado para una vida semiefímera, todo irá bien”. Dmitry también mencionó que las herramientas de administración de bases de datos no están listas ni para Docker ni para Kuber, por lo que surgen grandes dificultades.
Ivan, a su vez, está seguro de que incluso si nos abstraemos de los conceptos con estado y sin estado, el ecosistema de soluciones empresariales en Kubernetes aún no está listo. Con Kuber, es difícil cumplir los requisitos legislativos y reglamentarios. Por ejemplo, es imposible crear una solución de provisión de identidad donde se requieran garantías estrictas de identificación del servidor, hasta el hardware que se inserta en los servidores. Esta área se está desarrollando, pero aún no hay solución.
Los participantes no pudieron llegar a un acuerdo, por lo que no se sacarán conclusiones en esta parte. Pongamos un par de ejemplos prácticos.
Caso 1. Ciberseguridad de un “megaregulador” con bases fuera de Kubera
En el caso de un sistema de ciberseguridad desarrollado, el uso de contenedores y la orquestación permiten combatir ataques e intrusiones. Por ejemplo, en un megaregulador, Denis y su equipo implementaron una combinación de un orquestador con un servicio SIEM capacitado que analiza los registros en tiempo real y determina el proceso de un ataque, piratería o falla. En caso de un ataque, un intento de colocar algo, o en caso de una invasión de un virus ransomware, éste, a través del orquestador, recoge contenedores con aplicaciones más rápido de lo que se infectan o más rápido de lo que el atacante los ataca.
Caso 2. Migración parcial de las 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 maestro y toda una jerarquía de esclavos. Cuando Iván dejó la empresa, se lanzó un proyecto para transferir esclavos que pudieran ser "fusilados" con ciertos daños.
Además de la base principal, hay una instalación de Cassandra con orquestación escrita por ella misma, que fue escrita incluso antes de que Kuber entrara en la corriente principal. No hay problemas a este respecto, pero persiste en los SSD locales. El almacenamiento remoto, incluso dentro del mismo centro de datos, no se utiliza debido al problema de la alta latencia.
La tercera clase de bases de datos es el servicio de búsqueda de Booking.com, donde cada nodo de servicio es una base de datos. Los intentos de transferir el servicio de búsqueda a Kuber fracasaron porque cada nodo tiene entre 60 y 80 GB de almacenamiento local, lo que es difícil de "levantar" y "calentar".
Como resultado, el motor de búsqueda no fue transferido a Kubernetes e Ivan no cree que haya nuevos intentos en un futuro próximo. La base de datos MySQL se transfirió a la mitad: sólo los esclavos, que no temen que les “disparen”. Cassandra se ha adaptado perfectamente.
La selección de infraestructura como tarea sin solución general
Foto por
Digamos que tenemos una empresa nueva, o una empresa donde parte de la infraestructura está construida a la antigua usanza. Construye un plan de desarrollo de infraestructura durante años. ¿Cómo se toma la decisión de construir infraestructura en contenedores y Kuber o no?
Las empresas que luchan por los nanosegundos quedan excluidas del debate. Un conservadurismo saludable vale la pena en términos de confiabilidad, pero todavía hay empresas que deberían considerar nuevos enfoques.
Ivan: “Definitivamente iniciaría una empresa en la nube ahora, simplemente porque es más rápido”, aunque no necesariamente más barato. Con el desarrollo del capitalismo de riesgo, las startups no tienen grandes problemas con el dinero y la tarea principal es conquistar el mercado.
Iván opina que el desarrollo de la infraestructura actual es un criterio de selección. Si hubo una inversión importante en el pasado y funciona, entonces no tiene sentido rehacerla. Si la infraestructura no está desarrollada y hay problemas con las herramientas, la seguridad y el monitoreo, entonces tiene sentido considerar una infraestructura distribuida.
El impuesto habrá que pagarlo en cualquier caso, e Iván pagaría el que le permitiera pagar menos en el futuro. "Porque simplemente por el hecho de viajar en un tren en el que otros se mueven, viajaré mucho más lejos que si me sentara en otro tren en el que yo mismo tuviera que poner combustible.“dice Iván. Cuando la empresa es nueva y los requisitos de latencia son de decenas de milisegundos, Iván mirará hacia los "operadores" en los que hoy están "envueltas" las bases de datos clásicas. Generan una cadena de replicación, que se autoconmuta en caso de conmutación por error, etc.
Para una pequeña empresa con un par de servidores, Kubera no tiene sentido”, afirma Andrey. Pero si planea crecer a cientos de servidores o más, entonces necesita automatización y un sistema de gestión de recursos. El 90% de los casos vale la pena. Además, independientemente del nivel de carga y recursos. Tiene sentido para todos, desde las nuevas empresas hasta las grandes empresas con una audiencia de millones, mirar gradualmente hacia productos de orquestación de contenedores. “Sí, este es realmente el futuro”, está seguro Andrey.
Denis describió dos criterios principales: escalabilidad y estabilidad de operación. Seleccionará las herramientas que mejor se adapten a la tarea. “Podría ser un noname montado sobre tus rodillas y que tiene Nutanix Community Edition. Esta podría ser una segunda línea en forma de una aplicación en Kuber con una base de datos en el backend, que se replica y tiene parámetros RTO y RPO especificados" (objetivos de tiempo/punto de recuperación - aprox.).
Evgeniy identificó un posible problema con el personal. Por el momento, no hay muchos especialistas altamente calificados en el mercado que entiendan las "tripas". De hecho, si la tecnología elegida es antigua, entonces es difícil contratar a alguien que no sea gente de mediana edad que esté aburrida y cansada de la vida. Aunque otros participantes creen que se trata de una cuestión de formación del personal.
Si nos planteamos la cuestión de elegir: lanzar una pequeña empresa en la nube pública con bases de datos en Amazon RDS o "on premise" con bases de datos en Kubernetes, entonces, a pesar de algunas deficiencias, Amazon RDS se convirtió en la elección de los participantes.
Dado que la mayoría de los oyentes de la reunión no son de la empresa "sangrienta", entonces Las soluciones distribuidas son lo que debemos esforzarnos por lograr. Los sistemas de almacenamiento de datos deben ser distribuidos, confiables y generar una latencia medida en unidades de milisegundos, decenas como máximo.“, resumió Andrey.
Evaluación del uso de Kubernetes
El oyente Anton Zhbankov hizo una pregunta trampa a los apologistas de Kubernetes: ¿cómo seleccionaron y realizaron un estudio de viabilidad? ¿Por qué Kubernetes y no máquinas virtuales, por ejemplo?
Foto por
Dmitry e Ivan respondieron. En ambos casos, mediante prueba y error, se tomó una secuencia de decisiones, como resultado de las cuales ambos participantes llegaron a Kubernetes. Ahora las empresas están empezando a desarrollar software de forma independiente que tiene sentido transferir a Kuber. No estamos hablando de sistemas clásicos de terceros, como 1C. Kubernetes ayuda cuando los desarrolladores necesitan realizar lanzamientos rápidamente, con una mejora continua ininterrumpida.
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 en ocasiones provocaba el colapso del clúster. “En teoría, puedes terminarlo y sostenerlo con las manos, pero es tedioso. Y si hay una solución en el mercado que le permite trabajar desde el primer momento, estaremos encantados de implementarla. Y, como resultado, cambiamos”, dice Andrey.
Existen estándares para dicho análisis y cálculo, pero nadie puede decir qué tan precisos son en hardware real en funcionamiento. Para los cálculos también es importante comprender cada herramienta y ecosistema, pero esto no es posible.
lo que nos espera
Foto por
A medida que la tecnología evoluciona, aparecen piezas cada vez más dispares, y luego se produce una transición de fase, aparece un proveedor que ha matado suficiente dinero para que todo se junte en una sola herramienta.
¿Crees que llegará un momento en el que habrá una herramienta como Ubuntu para el mundo Linux? Quizás una única herramienta de orquestación y contenedorización incluya a Kuber. Facilitará la creación de nubes locales.
La respuesta la dio Ivan: "Google ahora está construyendo Anthos; esta es su oferta empaquetada que implementa la nube e incluye Kuber, Service Mesh, monitoreo, todo el hardware necesario para los microservicios locales". Estamos casi en el futuro".
Denis también mencionó Nutanix y VMWare con el producto vRealize Suite, que puede hacer frente a una tarea similar sin contenerización.
Dmitry compartió su opinión de que reducir el "dolor" y reducir los impuestos son dos áreas en las que podemos esperar mejoras.
Para resumir la discusión, destacamos los siguientes problemas de la infraestructura moderna:
- Tres participantes identificaron inmediatamente un problema con el estado.
- Varios problemas de soporte de seguridad, incluida la posibilidad de que Docker termine con múltiples versiones de Python, servidores de aplicaciones y componentes.
Gasto excesivo, que es mejor discutirlo en una reunión separada.
Un desafío de aprendizaje ya que la orquestación es un ecosistema complejo.
Un problema común en la industria es el mal uso de las herramientas.El resto de conclusiones dependen de ti. Todavía existe la sensación de que no es fácil que la combinación Docker+Kubernetes se convierta en una parte “central” del sistema. Por ejemplo, los sistemas operativos se instalan primero en el hardware, lo que no se puede decir de los contenedores y la orquestación. Quizás en el futuro los sistemas operativos y los contenedores se fusionen con el software de gestión de la nube.
Foto porMe gustaría aprovechar para saludar a mi madre y recordaros que tenemos un grupo en Facebook. , canal con publicaciones interesantes de varios blogs de tecnología. y mi canal , donde hablo sobre la gestión del desarrollo en empresas de productos.
Fuente: habr.com