A finais de maio mantivo unha reunión en liña sobre o tema . Falamos de contedores, Kubernetes e orquestración en principio, criterios para escoller infraestruturas e moito máis. Os participantes compartiron casos da súa propia práctica.
Participantes:
- Evgeniy Potapov, CEO de ITSumma. Máis da metade dos seus clientes xa se están mudando ou queren cambiar a Kubernetes.
- Dmitry Stolyarov, CTO "Flant". Ten máis de 10 anos de experiencia traballando con sistemas de contedores.
- Denis Remchukov (tamén coñecido como Eric Oldmann), COO argotech.io, ex-RAO UES. Prometeu falar de casos na empresa "sanguenta".
- Andrey Fedorovsky, CTO "News360.com"Despois de comprar a empresa por outro xogador, é responsable de varios proxectos e infraestruturas de ML e AI.
- Ivan Kruglov, enxeñeiro de sistemas, ex-Booking.com.A mesma persoa que fixo moito con Kubernetes coas súas propias mans.
Temas:
- Percepcións dos participantes sobre os contedores e a orquestración (Docker, Kubernetes, etc.); o que se tentou na práctica ou se analizou.
- Caso: a empresa está construíndo un plan de desenvolvemento de infraestruturas dende hai anos. Como se toma a decisión de construír (ou migrar a infraestrutura actual) aos contedores e Kuber ou non?
- Problemas no mundo nativo da nube, o que falta, imaxinemos o que pasará mañá.
Deu lugar a unha interesante discusión, as opinións dos participantes foron tan diferentes e provocaron tantos comentarios que quero compartilos con vós. Comer , e a continuación móstrase un resumo da discusión.
Kubernetes xa é un estándar ou un excelente marketing?
“Chegamos a ela (Kubernetes. - Ed.) cando aínda ninguén o sabía. Viñemos ata el aínda que non estaba alí. Queríao antes" - Dmitri Stolyarov
Foto de Reddit.com
Hai 5-10 anos había unha gran cantidade de ferramentas e non había un único estándar. Cada seis meses aparecía un novo produto, ou incluso máis dun. Primeiro Vagrant, despois Salt, Chef, Puppet,... “e reconstruídes a vosa infraestrutura cada seis meses. Tes cinco administradores que están constantemente ocupados reescribindo configuracións", lembra Andrey Fedorovsky. Cre que Docker e Kubernetes "desbordaron" o resto. Docker converteuse nun estándar nos últimos cinco anos, Kubernetes nos últimos dous anos. E iso é bo para a industria..
Dmitry Stolyarov e o seu equipo adoran Kuber. Querían tal ferramenta antes de que aparecese, e chegaron a ela cando ninguén o sabía. Actualmente, por razóns de comodidade, non asumen un cliente se entenden que non implementarán Kubernetes con el. Ao mesmo tempo, segundo Dmitry, a compañía ten "moitas xigantescas historias de éxito sobre a reconstrución do terrible legado".
Kubernetes non é só a orquestración de contedores, é un sistema de xestión de configuración cunha API desenvolvida, un compoñente de rede, equilibrio L3 e controladores de entrada, o que fai que sexa relativamente sinxelo xestionar os recursos, escalar e abstraer das capas inferiores da infraestrutura.
Desafortunadamente, na nosa vida temos que pagar por todo. E este imposto é grande, sobre todo se falamos da transición a Kubernetes dunha empresa cunha infraestrutura desenvolvida, como cre Ivan Kruglov. Podería traballar libremente tanto nunha empresa cunha infraestrutura tradicional como con Kuber. O principal é comprender as características da empresa e do mercado. Pero, por exemplo, para Evgeny Potapov, que xeneralizaría Kubernetes a calquera ferramenta de orquestración de contedores, tal pregunta non xorde.
Evgeniy fixo unha analoxía coa situación da década de 1990, cando a programación orientada a obxectos apareceu como unha forma de programar aplicacións complexas. Nese momento, o debate continuou e apareceron novas ferramentas para apoiar a POO. Entón xurdiron os microservizos como unha forma de afastarse do concepto monolítico. Isto, á súa vez, provocou a aparición de contedores e ferramentas de xestión de contedores. "Creo que en breve chegaremos a un momento no que non haberá dúbida de se paga a pena escribir unha pequena aplicación de microservizo, escribirase como microservizo por defecto", cre. Do mesmo xeito, Docker e Kubernetes acabarán por converterse na solución estándar sen necesidade de escoller.
O problema das bases de datos en apátridas
Foto por
Hoxe en día, hai moitas receitas para executar bases de datos en Kubernetes. Incluso como separar a parte que funciona co disco de E/S da, condicionalmente, a parte da aplicación da base de datos. É posible que nun futuro cambien tanto as bases de datos que se entreguen nunha caixa, onde unha parte estará orquestrada a través de Docker e Kubernetes, e noutra parte da infraestrutura, a través de software separado, se proporcionará a parte de almacenamento? ? Cambiarán as bases como produto?
Esta descrición é semellante á xestión de filas, pero os requisitos de fiabilidade e sincronización da información nas bases de datos tradicionais son moito máis altos, cre Andrey. O índice de acertos da caché nas bases de datos normais mantense no 99%. Se un traballador cae, lánzase un novo e a caché "quenta" desde cero. Ata que se quente a caché, o traballador traballa lentamente, o que significa que non se pode cargar coa carga do usuario. Mentres non hai carga de usuario, a caché non se quenta. É un círculo vicioso.
Dmitry fundamentalmente non está de acordo: os quórums e a fragmentación resolven o problema. Pero Andrey insiste en que a solución non é apta para todos. Nalgunhas situacións, o quórum é adecuado, pero supón unha carga adicional na rede. Unha base de datos NoSQL non é adecuada en todos os casos.
Os participantes do encontro dividíronse en dous campamentos.
Denis e Andrey argumentan que todo o que está escrito no disco - bases de datos e así por diante - é imposible de facer no ecosistema actual de Kuber. É imposible manter a integridade e a coherencia dos datos de produción en Kubernetes. Esta é unha característica fundamental. Solución: infraestrutura híbrida.
Incluso as bases de datos nativas na nube modernas como MongoDB e Cassandra, ou as colas de mensaxes como Kafka ou RabbitMQ, requiren almacéns de datos persistentes fóra de Kubernetes.
Evgeniy obxecta: "As bases en Kubera son unha lesión case rusa ou case empresarial, que está asociada ao feito de que non hai Adopción de nubes en Rusia". As pequenas ou medianas empresas de Occidente son Cloud. As bases de datos de Amazon RDS son máis fáciles de usar que xogar con Kubernetes. En Rusia usan Kuber "on-premise" e transfiren bases a el cando intentan desfacerse do zoolóxico.
Dmitry tamén non estaba de acordo coa afirmación de que non se poden manter bases de datos en Kubernetes: "Hai unha diferenza entre as bases de datos. E se empurras unha base de datos relacional xigante, baixo ningunha circunstancia. Se empurras algo pequeno e nativo da nube, que está mentalmente preparado para a vida semiefémera, todo estará ben". Dmitry tamén mencionou que as ferramentas de xestión de bases de datos non están preparadas nin para Docker nin para Kuber, polo que xorden grandes dificultades.
Ivan, pola súa banda, está seguro de que aínda que abstraéramos dos conceptos de estado e sen estado, o ecosistema de solucións empresariais en Kubernetes aínda non está preparado. Con Kuber, é difícil manter os requisitos lexislativos e regulamentarios. Por exemplo, é imposible facer unha solución de provisión de identidade onde se requiran estritas garantías de identificación do servidor, ata o hardware que se insire nos servidores. Esta área está a desenvolverse, pero aínda non hai solución.
Os participantes non puideron poñerse de acordo, polo que non se extraerán conclusións nesta parte. Poñamos un par de exemplos prácticos.
Caso 1. Ciberseguridade dun “mega-regulador” con bases fóra de Kubera
No caso dun sistema de ciberseguridade desenvolvido, o uso de contedores e orquestración permite loitar contra ataques e intrusións. Por exemplo, nun megaregulador, Denis e o seu equipo implementaron unha combinación dun orquestrador cun servizo SIEM adestrado que analiza os rexistros en tempo real e determina o proceso dun ataque, piratería ou fallo. En caso de ataque, intento de colocar algo ou en caso de invasión de virus ransomware, este, a través do orquestrator, recolle os contedores con aplicacións máis rápido do que se infectan ou máis rápido que o atacante.
Caso 2. Migración parcial das bases de datos de Booking.com a Kubernetes
En Booking.com, a base de datos principal é MySQL con replicación asíncrona: hai un mestre e toda unha xerarquía de escravos. Cando Ivan deixou a empresa, lanzouse un proxecto para transferir escravos que podían ser "disparados" con certo dano.
Ademais da base principal, hai unha instalación de Cassandra con orquestración autoescrita, que foi escrita mesmo antes de que Kuber entrase na corrente principal. Non hai problemas a este respecto, pero é persistente nos SSD locais. O almacenamento remoto, mesmo dentro do mesmo centro de datos, non se utiliza debido ao problema da alta latencia.
A terceira clase de bases de datos é o servizo de busca de Booking.com, onde cada nodo de servizo é unha base de datos. Os intentos de transferir o servizo de busca a Kuber fallaron porque cada nodo ten 60-80 GB de almacenamento local, que é difícil de "levantar" e "quecer".
Como resultado, o buscador non foi transferido a Kubernetes e Ivan non pensa que haxa novos intentos nun futuro próximo. A base de datos MySQL foi transferida á metade: só escravos, que non teñen medo de ser "disparados". Cassandra instalouse perfectamente.
Selección de infraestruturas como tarefa sen solución xeral
Foto por
Digamos que temos unha empresa nova, ou unha empresa na que parte da infraestrutura está construída á antiga. Constrúe un plan de desenvolvemento de infraestruturas durante anos. Como se toma a decisión de construír infraestrutura en contedores e Kuber ou non?
As empresas que loitan por nanosegundos quedan excluídas da discusión. O conservadurismo saudable dá froitos en termos de fiabilidade, pero aínda hai empresas que deberían considerar novos enfoques.
Ivan: "Definitivamente comezaría unha empresa na nube agora, simplemente porque é máis rápida", aínda que non necesariamente máis barata. Co desenvolvemento do capitalismo de risco, as startups non teñen grandes problemas co diñeiro, e a principal tarefa é conquistar o mercado.
Iván opina que o desenvolvemento da infraestrutura actual é un criterio de selección. Se houbo un investimento serio no pasado, e funciona, entón non ten sentido refacelo. Se a infraestrutura non está desenvolvida e hai problemas coas ferramentas, a seguridade e a vixilancia, entón ten sentido mirar unha infraestrutura distribuída.
Haberá que pagar o imposto en todo caso, e Iván pagaría o que lle permitise pagar menos no futuro. "Porque simplemente polo feito de que vou nun tren que outros están movendo, viaxarei moito máis lonxe que se me sento noutro tren, no que teño que poñer eu combustible.", di Iván. Cando a empresa é nova, e os requisitos de latencia son decenas de milisegundos, entón Ivan miraría cara aos "operadores" nos que as bases de datos clásicas están "envoltas" hoxe. Crean unha cadea de replicación, que se cambia por si mesma en caso de fallo, etc...
Para unha empresa pequena cun par de servidores, Kubera non ten sentido", di Andrey. Pero se planea crecer ata centos de servidores ou máis, entón necesita automatización e un sistema de xestión de recursos. O 90% dos casos paga a pena. Ademais, independentemente do nivel de carga e recursos. Ten sentido que todos, desde startups ata grandes empresas cunha audiencia de millóns de persoas, busquen gradualmente produtos de orquestración de contedores. "Si, este é realmente o futuro", está seguro Andrey.
Denis describiu dous criterios principais: escalabilidade e estabilidade de funcionamento. El seleccionará as ferramentas que sexan máis adecuadas para a tarefa. "Podería ser un nonname montado sobre os teus xeonllos, e ten a Nutanix Community Edition. Esta podería ser unha segunda liña en forma dunha aplicación en Kuber cunha base de datos no backend, que se replica e especifica os parámetros RTO e RPO" (obxectivos de tempo/punto de recuperación - aprox.).
Evgeniy identificou un posible problema co persoal. Polo momento, non hai moitos especialistas altamente cualificados no mercado que entendan as "coraxes". De feito, se a tecnoloxía escollida é antiga, entón é difícil contratar a alguén que non sexa persoas de mediana idade que estean aburridas e cansadas da vida. Aínda que outros participantes cren que se trata dunha cuestión de formación do persoal.
Se poñemos a cuestión da elección: lanzar unha pequena empresa na nube pública con bases de datos en Amazon RDS ou "on premise" con bases de datos en Kubernetes, entón, a pesar dalgunhas deficiencias, Amazon RDS converteuse na elección dos participantes.
Dado que a maioría dos oíntes do encontro non son da empresa "sanguenta", entón solucións distribuídas son o que debemos esforzarnos. Os sistemas de almacenamento de datos deben estar distribuídos, fiables e crear unha latencia medida en unidades de milisegundos, decenas como máximo.", resumiu Andrey.
Avaliación do uso de Kubernetes
O oínte Anton Zhbankov fixo unha pregunta trampa aos apologistas de Kubernetes: como seleccionou e realizou un estudo de viabilidade? Por que Kubernetes, por que non as máquinas virtuais, por exemplo?
Foto por
Dmitry e Iván responderon. En ambos os casos, por proba e erro, tomouse unha secuencia de decisións, como resultado da cal ambos os participantes chegaron a Kubernetes. Agora as empresas comezan a desenvolver de forma independente software que ten sentido transferilo a Kuber. Non estamos a falar de sistemas clásicos de terceiros, como 1C. Kubernetes axuda cando os desenvolvedores necesitan facer lanzamentos rapidamente, cunha mellora continua sen parar.
O equipo de Andrey intentou crear un clúster escalable baseado en máquinas virtuais. Os nós caeron como dominó, o que ás veces levou ao colapso do clúster. “Teoricamente, podes rematalo e apoialo coas mans, pero é tedioso. E se hai unha solución no mercado que che permita traballar fóra da caixa, entón estamos encantados de facelo. E como resultado cambiamos", di Andrey.
Existen estándares para tal análise e cálculo, pero ninguén pode dicir o que son precisos no hardware real en funcionamento. Para os cálculos, tamén é importante comprender cada ferramenta e ecosistema, pero isto non é posible.
O que nos agarda
Foto por
A medida que a tecnoloxía evoluciona, aparecen cada vez máis pezas dispares, e despois prodúcese unha transición de fase, aparece un vendedor que matou masa suficiente para que todo se xunte nunha única ferramenta.
Cres que chegará un momento no que haberá unha ferramenta como Ubuntu para o mundo Linux? Quizais unha única ferramenta de contenerización e orquestración inclúa Kuber. Facilitará a creación de nubes locais.
A resposta foi dada por Ivan: "Google está agora a construír Anthos - esta é a súa oferta empaquetada que desprega a nube e inclúe Kuber, Service Mesh, monitorización - todo o hardware que é necesario para os microservizos locais". Estamos case no futuro".
Denis tamén mencionou Nutanix e VMWare co produto vRealize Suite, que pode facer fronte a unha tarefa similar sen contener.
Dmitry compartiu a súa opinión de que reducir a "dor" e reducir os impostos son dúas áreas nas que podemos esperar melloras.
Para resumir a discusión, destacamos os seguintes problemas da infraestrutura moderna:
- Tres participantes identificaron inmediatamente un problema con stateful.
- Varios problemas de soporte de seguridade, incluíndo a posibilidade de que Docker acabe con varias versións de Python, servidores de aplicacións e compoñentes.
Gastos excesivos, que é mellor discutir nunha reunión separada.
Un reto de aprendizaxe xa que a orquestración é un ecosistema complexo.
Un problema común na industria é o mal uso das ferramentas.O resto das conclusións depende de ti. Aínda existe a sensación de que non é fácil que a combinación Docker+Kubernetes se converta nunha parte "central" do sistema. Por exemplo, os sistemas operativos instálanse primeiro no hardware, o que non se pode dicir sobre os contedores e a orquestración. Quizais no futuro, os sistemas operativos e os contedores se fusionen co software de xestión da nube.
Foto porGustaríame aproveitar para saudar a miña nai e lembrarvos que temos un grupo en Facebook , canle con publicacións interesantes de varios blogs tecnolóxicos. E a miña canle , onde falo da xestión do desenvolvemento nas empresas de produtos.
Fonte: www.habr.com