En previsión Vitali Khabarov entrevistado Dmitri Stolyarov (), director técnico e cofundador da empresa Flant. Vitaly preguntou a Dmitry sobre o que fai Flant, sobre Kubernetes, desenvolvemento de ecosistemas, apoio. Discutimos por que é necesario Kubernetes e se é necesario. E tamén sobre os microservizos, Amazon AWS, o enfoque "terei sorte" para DevOps, o propio futuro de Kubernetes, por que, cando e como se apoderará do mundo, as perspectivas de DevOps e para que deben prepararse os enxeñeiros futuro brillante e próximo con simplificación e redes neuronais.
escoita como un podcast en DevOps Deflop, un podcast en ruso sobre DevOps, e a continuación está a versión de texto.
Aquí e abaixo fai preguntas enxeñeiro de Express42.
Sobre "Flant"
- Ola Dima. Vostede é o director técnico"" e tamén o seu fundador. Díganos que fai a empresa e que estás nela?
Dmitry: Desde fóra parece que somos os rapaces que andamos instalando Kubernetes para todos e facendo algo con el. Pero iso non é certo. Comezamos como unha empresa que se ocupa de Linux, pero dende hai moito tempo a nosa actividade principal foi o servizo de produción e proxectos de alta carga chave en man. Normalmente construímos toda a infraestrutura desde cero e logo somos responsables dela durante moito, moito tempo. Polo tanto, o principal traballo que fai "Flant", polo que recibe cartos, é asumindo a responsabilidade e implementando a produción chave en man.
Eu, como director técnico e un dos fundadores da empresa, paso todo o día e a noite intentando descubrir como aumentar a accesibilidade á produción, simplificar o seu funcionamento, facilitar a vida dos administradores e facer máis agradable a vida dos desenvolvedores. .
Sobre Kubernetes
— Ultimamente estiven vendo moitos informes de Flant e sobre Kubernetes. Como chegaches a iso?
Dmitry: Disto xa falei moitas veces, pero non me importa repetilo en absoluto. Creo que é correcto repetir este tema porque hai confusión entre causa e efecto.
Realmente necesitabamos unha ferramenta. Afrontamos moitos problemas, loitamos, superámolos con varias muletas e sentimos a necesidade dunha ferramenta. Pasamos por moitas opcións diferentes, construímos as nosas propias bicicletas e adquirimos experiencia. Pouco a pouco chegamos ao punto no que comezamos a usar Docker case tan pronto como apareceu, ao redor de 2013. No momento da súa aparición, xa tiñamos moita experiencia cos contedores, xa tiñamos escrito un análogo de "Docker": algunhas das nosas propias muletas en Python. Coa chegada de Docker, fíxose posible tirar as muletas e utilizar unha solución fiable e apoiada pola comunidade.
Con Kubernetes a historia é semellante. Cando comezou a coller impulso -para nós esta é a versión 1.2- xa tiñamos un montón de muletas tanto en Shell como en Chef, que de algún xeito tentamos orquestrar con Docker. Mirabamos seriamente cara a Rancher e outras varias solucións, pero entón apareceu Kubernetes, no que todo se implementa exactamente como o teriamos feito ou aínda mellor. Non hai nada que queixarse.
Si, hai algún tipo de imperfección aquí, hai algún tipo de imperfección alí - hai moitas imperfeccións, e 1.2 é xeralmente terrible, pero... Kubernetes é como un edificio en construción - miras o proxecto e entendes que vai estar chulo. Se o edificio agora ten unha base e dous pisos, entón entendes que é mellor non entrar aínda, pero non hai tales problemas co software: xa podes usalo.
Non tivemos un momento no que pensamos en usar Kubernetes ou non. Esperábao moito antes de que aparecese, e tentamos crear nós mesmos análogos.
Sobre Kubernetes
— Está directamente implicado no propio desenvolvemento de Kubernetes?
Dmitry: Mediocre. Pola contra, participamos no desenvolvemento do ecosistema. Enviamos un certo número de solicitudes de extracción: a Prometheus, a varios operadores, a Helm, ao ecosistema. Desafortunadamente, non son capaz de facer un seguimento de todo o que facemos e podería estar equivocado, pero non hai nin un só grupo de nós no núcleo.
— Ao mesmo tempo, desenvolves moitas das túas ferramentas en torno a Kubernetes?
Dmitry: A estratexia é esta: imos tirar peticións a todo o que xa existe. Se as solicitudes de extracción non se aceptan alí, simplemente as garrafamos nós mesmos e vivimos ata que sexan aceptadas coas nosas compilacións. Despois, cando chega ao río arriba, volvemos á versión ascendente.
Por exemplo, temos un operador Prometheus, co que cambiamos de ida e volta cara arriba do noso conxunto probablemente xa 5 veces. Necesitamos algún tipo de función, enviamos unha solicitude de extracción, necesitamos publicala mañá, pero non queremos esperar a que se publique. En consecuencia, montamos por nós mesmos, distribuímos o noso conxunto coa nosa función, que necesitamos por algún motivo, a todos os nosos clústeres. Despois, por exemplo, entrégannolo na augas arriba coas palabras: "Rapaces, imos facelo por un caso máis xeral", nós, ou outra persoa, remámolo, e co paso do tempo volve fusionarse.
Intentamos desenvolver todo o que existe. Moitos elementos que aínda non existen, que aínda non se inventaron, ou que se inventaron, pero que non tiveron tempo de implementar -estamos facendo. E non porque nos guste o proceso ou a construción de bicicletas como industria, senón simplemente porque necesitamos esta ferramenta. A pregunta adoita facerse, por que fixemos tal ou aquela cousa? A resposta é sinxela: si, porque tivemos que ir máis aló, resolver algún problema práctico, e resolvemos con esta tula.
O camiño é sempre así: buscamos con moito coidado e, se non atopamos ningunha solución sobre como facer un trolebús cunha barra de pan, facemos o noso propio pan e o noso propio trolebús.
Ferramentas Flanta
— Sei que Flant agora ten operadores de complementos, operadores de shell e ferramentas dapp/werf. Segundo entendo, este é o mesmo instrumento en diferentes encarnacións. Tamén entendo que hai moitas máis ferramentas diferentes dentro de Flaunt. É verdade?
Dmitry: Temos moito máis en GitHub. Polo que recordo agora, temos un mapa de estado: un panel para Grafana que todos atoparon. Menciónase en case cada segundo artigo sobre o seguimento de Kubernetes en Medium. É imposible explicar brevemente o que é un mapa de estado: necesita un artigo separado, pero é unha cousa moi útil para supervisar o estado ao longo do tempo, xa que en Kubernetes adoitamos mostrar o estado ao longo do tempo. Tamén temos LogHouse: isto é unha cousa baseada en ClickHouse e maxia negra para recoller rexistros en Kubernetes.
Moitas utilidades! E haberá aínda máis, porque este ano lanzaranse unha serie de solucións internas. Dos moi grandes baseados no operador de complementos, hai unha morea de complementos para Kubernetes, como instalar correctamente o xestor de sert - unha ferramenta para xestionar certificados, como instalar correctamente Prometheus cunha morea de accesorios - estes son uns vinte diferentes. binarios que exportan datos e recollen algo, a este Prometheus ten os gráficos e alertas máis sorprendentes. Todo isto é só unha morea de complementos para Kubernetes, que se instalan nun clúster, e pasa de simple a cool, sofisticado, automático, nos que xa se resolveron moitos problemas. Si, facemos moito.
Desenvolvemento do ecosistema
"Paréceme que esta é unha gran contribución ao desenvolvemento deste instrumento e dos seus métodos de uso". Podes estimar aproximadamente quen máis faría a mesma contribución ao desenvolvemento do ecosistema?
Dmitry: En Rusia, das empresas que operan no noso mercado, ninguén está nin preto. Por suposto, esta é unha declaración forte, porque hai actores importantes como Mail e Yandex; tamén están facendo algo con Kubernetes, pero aínda non se achegan á contribución de empresas de todo o mundo que fan moito máis ca nós. É difícil comparar Flant, que conta cun persoal de 80 persoas, e Red Hat, que conta só con 300 enxeñeiros por Kubernetes, se non me equivoco. É difícil comparar. No departamento de RnD temos 6 persoas, entre elas eu, que cortaron todas as nosas ferramentas. 6 persoas fronte a 300 enxeñeiros de Red Hat: é difícil comparar.
- Con todo, cando mesmo estas 6 persoas poden facer algo realmente útil e alienante, cando se enfrontan a un problema práctico e dan a solución á comunidade - un caso interesante. Entendo que nas grandes empresas tecnolóxicas, onde teñen o seu propio equipo de desenvolvemento e soporte de Kubernetes, en principio pódense desenvolver as mesmas ferramentas. Este é un exemplo para eles do que se pode desenvolver e dar á comunidade, dando impulso a toda a comunidade que utiliza Kubernetes.
Dmitry: Esta é probablemente unha característica do integrador, a súa peculiaridade. Temos moitos proxectos e vemos moitas situacións diferentes. Para nós, a principal forma de crear valor engadido é analizar estes casos, buscar puntos en común e facelos o máis económicos posible. Estamos traballando activamente nisto. É difícil para min falar de Rusia e do mundo, pero temos uns 40 enxeñeiros de DevOps na empresa que traballan en Kubernetes. Non creo que haxa moitas empresas en Rusia cun número comparable de especialistas que comprendan Kubernetes, se é que os hai.
Entendo todo sobre o título do traballo Enxeñeiro de DevOps, todo o mundo o entende todo e está afeito a chamar aos enxeñeiros de DevOps enxeñeiros de DevOps, non imos discutir isto. Todos estes 40 incribles enxeñeiros de DevOps afrontan e resolven problemas todos os días, só analizamos esta experiencia e tratamos de xeneralizar. Entendemos que se permanece dentro de nós, nun ano ou dous a ferramenta será inútil, porque nalgún lugar da comunidade aparecerá un Tula preparado. Non ten sentido acumular esta experiencia internamente: simplemente é drenar enerxía e tempo a dev/null. E non o sentimos nada. Publicamos todo con moito pracer e entendemos que hai que publicar, desenvolver, promocionar, promocionar, para que a xente o use e engada a súa experiencia; entón todo crece e vive. Despois de dous anos, o instrumento non vai ao lixo. Non é unha mágoa seguir botando forzas, porque está claro que alguén está a usar a túa ferramenta, e despois de dous anos todo o mundo está a empregala.
Isto é parte da nosa gran estratexia con dapp/werf. Non recordo cando empezamos a facelo, parece que hai 3 anos. Inicialmente, era xeralmente na cuncha. Foi unha súper proba de concepto, resolvemos algúns dos nosos problemas particulares: funcionou! Pero hai problemas co shell, é imposible amplialo máis, programar no shell é outra tarefa. Tiñamos o costume de escribir en Ruby, polo tanto, refacemos algo en Ruby, desenvolvemos, desenvolvemos, desenvolvemos e topámonos co feito de que a comunidade, a multitude que non di "queremos ou non queremos, ” volve o nariz a Ruby, que divertido é iso? Démonos conta de que deberiamos escribir todas estas cousas en Go só para cumprir o primeiro punto da lista de verificación: A ferramenta DevOps debería ser un binario estático. Ser Go ou non non é tan importante, pero é mellor un binario estático escrito en Go.
Gastamos a nosa enerxía, reescribimos o dapp en Go e chamámoslle werf. O Dapp xa non é compatible, non está desenvolvido, funcionando nalgunha versión máis recente, pero hai unha ruta de actualización absoluta ata a parte superior e podes seguilo.
Por que se creou a dapp?
— Podes dicirnos brevemente por que se creou a dapp, que problemas soluciona?
Dmitry: O primeiro motivo está na asemblea. Inicialmente, tivemos serios problemas coa compilación cando Docker non tiña capacidades de varias etapas, polo que fixemos varias etapas pola nosa conta. Despois tivemos moitos máis problemas coa limpeza da imaxe. Todos os que fan CI/CD, máis cedo que tarde, enfróntanse ao problema de que hai unha morea de imaxes recollidas, hai que limpar dalgún xeito o que non se necesita e deixar o que se necesita.
O segundo motivo é o despregamento. Si, existe Helm, pero só resolve algúns dos problemas. Curiosamente, está escrito que "Helm é o xestor de paquetes de Kubernetes". Exactamente o que "o". Tamén están as palabras "Xestor de paquetes": cal é a expectativa habitual dun xestor de paquetes? Dicimos: "Xestor de paquetes: instala o paquete!" e esperamos que nos diga: "O paquete foi entregado".
É interesante que digamos: "Helm, instala o paquete", e cando responde que o instalou, resulta que acaba de comezar a instalación - indicou a Kubernetes: "Lanza esta cousa!", e se comezou ou non. , funcione ou non, Helm non resolve este problema en absoluto.
Resulta que Helm é só un preprocesador de texto que carga datos en Kubernetes.
Pero como parte de calquera implantación, queremos saber se a aplicación foi lanzada para a produción ou non? Desenvolvido para prod significa que a aplicación moveuse alí, que se implantou a nova versión e, polo menos, non falla alí e responde correctamente. Helm non resolve este problema de ningún xeito. Para solucionalo, cómpre gastar moito esforzo, porque cómpre darlle a Kubernetes o comando para implementar e supervisar o que está a suceder alí, xa sexa implantado ou implementado. E tamén hai moitas tarefas relacionadas co despregamento, limpeza e montaxe.
Plans
Este ano comezaremos o desenvolvemento local. Queremos conseguir o que antes estaba en Vagrant: escribimos "vagrant up" e implantamos máquinas virtuais. Queremos chegar ao punto no que hai un proxecto en Git, escribimos "werf" alí e aparece unha copia local deste proxecto, despregada nun mini-Kub local, con todos os directorios convenientes para o desenvolvemento conectados. . Dependendo da linguaxe de desenvolvemento, isto faise de forma diferente, pero non obstante, para que o desenvolvemento local poida levarse a cabo convenientemente baixo ficheiros montados.
O seguinte paso para nós é investir en comodidade para os desenvolvedores. Para implementar rapidamente un proxecto localmente cunha única ferramenta, desenvólveo, empúxao a Git e tamén se implementará en fases ou probas, dependendo das canalizacións, e despois utilizará a mesma ferramenta para ir á produción. Esta unidade, unificación, reproducibilidade das infraestruturas desde o ámbito local ata as vendas é un punto moi importante para nós. Pero isto aínda non está en werf, só estamos planeando facelo.
Pero o camiño cara a dapp/werf sempre foi o mesmo que con Kubernetes ao principio. Atopámonos con problemas, resolvémolos con solucións alternativas: atopamos algunhas solucións para nós mesmos no shell, en calquera cousa. Despois tentaron endereitar dalgún xeito estas solucións, xeneralizalas e consolidalas en binarios neste caso, que simplemente compartimos.
Hai outra forma de ver toda esta historia, con analoxías.
Kubernetes é un bastidor de coche con motor. Non hai portas, vidro, radio, árbore de Nadal, nada de nada. Só o cadro e o motor. E hai Helm: este é o volante. Xenial: hai un volante, pero tamén necesitas un pasador de dirección, cremallera, caixa de cambios e rodas, e non podes prescindir deles.
No caso de werf, este é outro compoñente de Kubernetes. Só agora na versión alfa de werf, por exemplo, Helm está compilado dentro de werf, porque estamos fartos de facelo nós. Hai moitas razóns para facelo, vouche dicir en detalle por que compilamos todo o timón xunto co timón dentro do werf. .
Agora werf é un compoñente máis integrado. Temos un volante acabado, un pasador de dirección: non son moi bo para os coches, pero este é un bloque grande que xa resolve unha serie de problemas bastante ampla. Non necesitamos repasar nós mesmos o catálogo, seleccionar unha peza por outra, pensar en como atornillar. Temos unha combinada preparada que resolve un gran número de problemas á vez. Pero no seu interior está construído a partir dos mesmos compoñentes de código aberto, aínda usa Docker para a montaxe, Helm para algunhas das funcións e hai outras bibliotecas. Esta é unha ferramenta integrada para sacar CI/CD xenial da caixa de xeito rápido e cómodo.
É difícil manter Kubernetes?
— Falas da experiencia que comezaches a usar Kubernetes, este é un cadro para ti, un motor, e que podes colgar nel un montón de cousas diferentes: unha carrocería, un volante, pedais parafusos, asentos. Xorde a pregunta: que tan difícil é para ti o soporte de Kubernetes? Tes moita experiencia, canto tempo e recursos dedicas a dar soporte a Kubernetes illado de todo o demais?
Dmitry: Esta é unha pregunta moi difícil e para responder, necesitamos entender que é o soporte e que queremos de Kubernetes. Quizais poidas revelar?
— Polo que sei e vexo, agora moitos equipos queren probar Kubernetes. Todo o mundo apóiase a ela, pona de xeonllos. Teño a sensación de que a xente non sempre entende a complexidade deste sistema.
Dmitry: É así.
— Que difícil é levar e instalar Kubernetes desde cero para que estea listo para a produción?
Dmitry: Que difícil cres que é transplantar un corazón? Entendo que esta é unha pregunta comprometedora. Usar un bisturí e non cometer un erro non é tan difícil. Se che din onde cortar e onde coser, o procedemento en si non é complicado. É difícil garantir unha e outra vez que todo vai funcionar.
Instalar Kubernetes e facelo funcionar é sinxelo: ¡chick! — instalado, hai moitos métodos de instalación. Pero que pasa cando xorden problemas?
Sempre xorden preguntas: que aínda non tivemos en conta? Que aínda non fixemos? Que parámetros do núcleo de Linux se especificaron incorrectamente? Señor, ¡sequera os mencionamos?! Que compoñentes de Kubernetes entregamos e cales non? Xorden miles de preguntas e, para respondelas, cómpre pasar 15-20 anos nesta industria.
Teño un exemplo recente sobre este tema que pode revelar o significado do problema "É difícil manter Kubernetes?" Hai un tempo consideramos seriamente se deberíamos tentar implementar Cilium como unha rede en Kubernetes.
Déixame explicar o que é Cilium. Kubernetes ten moitas implementacións diferentes do subsistema de rede, e unha delas é moi xenial: Cilium. Cal é o seu significado? No núcleo, hai tempo que se podían escribir ganchos para o núcleo, que dunha ou outra forma invaden o subsistema de rede e outros subsistemas, e permiten evitar grandes anacos do núcleo.
O kernel de Linux ten historicamente unha ruta IP, un sobrefiltro, pontes e moitos compoñentes antigos diferentes que teñen 15, 20 ou 30 anos. En xeral, funcionan, todo é xenial, pero agora amontoaron recipientes e parece unha torre de 15 ladrillos uns encima dos outros, e estás sobre ela nunha perna: unha sensación estraña. Este sistema desenvolveuse historicamente con moitos matices, como o apéndice no corpo. Nalgunhas situacións hai problemas de rendemento, por exemplo.
Hai un BPF marabilloso e a capacidade de escribir ganchos para o núcleo: os mozos escribiron os seus propios ganchos para o núcleo. O paquete entra no núcleo de Linux, sácano directamente na entrada, procésano eles mesmos como debería sen pontes, sen TCP, sen unha pila de IP; saia ao recipiente.
Que pasou? Un rendemento moi xenial, funcións interesantes, simplemente xenial! Pero miramos isto e vemos que en cada máquina hai un programa que se conecta á API de Kubernetes e, en función dos datos que recibe desta API, xera código C e compila binarios que carga no núcleo para que funcionen estes ganchos. no espazo do núcleo.
Que pasa se algo sae mal? Non o sabemos. Para entendelo, cómpre ler todo este código, comprender toda a lóxica e é incrible o difícil que é. Pero, por outra banda, están estas pontes, filtros de rede, rout ip: non lin o seu código fonte, nin os 40 enxeñeiros que traballan na nosa empresa. Quizais só algúns entendan algunhas partes.
E cal é a diferenza? Resulta que hai IP rout, o núcleo de Linux e hai unha nova ferramenta: que diferenza fai, non entendemos nin un nin outro. Pero temos medo de usar algo novo - por que? Porque se a ferramenta ten 30 anos, en 30 anos atopáronse todos os erros, pisáronse todos os erros e non necesitas saber todo: funciona como unha caixa negra e sempre funciona. Todo o mundo sabe que desaparafusador de diagnóstico colocar en que lugar, que tcpdump executar en que momento. Todo o mundo coñece ben as utilidades de diagnóstico e entende como funciona este conxunto de compoñentes no núcleo de Linux, non como funciona, senón como usalo.
E o fantástico Cilium non ten 30 anos, aínda non envellece. Kubernetes ten o mesmo problema, copia. Que Cilium está instalado perfectamente, que Kubernetes está instalado perfectamente, pero cando algo sae mal na produción, é capaz de comprender rapidamente o que pasou mal nunha situación crítica?
Cando dicimos que é difícil manter Kubernetes - non, é moi sinxelo, e si, é incriblemente difícil. Kubernetes funciona moi ben por si só, pero con mil millóns de matices.
Sobre o enfoque "terei sorte".
— ¿Hai empresas onde estes matices están case garantidos? Supoñamos que Yandex transfire de súpeto todos os servizos a Kubernetes, alí haberá unha gran carga.
Dmitry: Non, esta non é unha conversa sobre a carga, senón sobre as cousas máis sinxelas. Por exemplo, temos Kubernetes, implantamos alí a aplicación. Como sabes que está funcionando? Simplemente non hai ningunha ferramenta preparada para entender que a aplicación non está fallando. Non hai un sistema preparado para enviar alertas; cómpre configurar estas alertas e cada programación. E estamos actualizando Kubernetes.
Teño Ubuntu 16.04. Podes dicir que esta é unha versión antiga, pero aínda estamos nela porque é LTS. Hai systemd, cuxo matiz é que non limpa os grupos C. Kubernetes lanza pods, crea grupos C, despois elimina pods e, dalgún xeito, resulta -non lembro os detalles, perdón- que quedan porcións systemd. Isto leva ao feito de que co paso do tempo, calquera coche comeza a diminuír fortemente. Esta non é nin sequera unha pregunta sobre a carga elevada. Se se lanzan pods permanentes, por exemplo, se hai un traballo Cron que xera constantemente pods, entón a máquina con Ubuntu 16.04 comezará a ralentizarse despois dunha semana. Haberá unha media de carga constantemente alta debido ao feito de que se crearon un grupo de grupos C. Este é o problema ao que se enfrontará calquera persoa que simplemente instale Ubuntu 16 e Kubernetes encima.
Digamos que dalgún xeito actualiza systemd ou outra cousa, pero no núcleo de Linux ata 4.16 é aínda máis divertido: cando eliminas grupos C, filtran no núcleo e non se eliminan. Polo tanto, despois dun mes de traballar nesta máquina, será imposible ver as estatísticas de memoria dos fogares. Sacamos un ficheiro, enrolámolo no programa e un ficheiro rola durante 15 segundos, porque o núcleo tarda moito en contar un millón de grupos C dentro de si mesmo, que parecen ser eliminados, pero non, están filtrando. .
Aínda hai moitas cousas tan pequenas aquí e alí. Este non é un problema ao que as empresas xigantes poidan enfrontarse ás veces con cargas moi pesadas; non, é unha cuestión de cousas cotiás. A xente pode vivir así durante meses -instalaron Kubernetes, implantaron a aplicación- parece que funciona. Para moitas persoas isto é normal. Nin sequera saberán que esta aplicación fallará por algún motivo, non recibirán unha alerta, pero para eles esta é a norma. Antes vivíamos en máquinas virtuais sen vixilancia, agora mudámonos a Kubernetes, tamén sen vixilancia, cal é a diferenza?
A cuestión é que cando camiñamos sobre xeo, nunca sabemos o seu grosor a non ser que o medimos con antelación. Moita xente anda e non se preocupe, porque xa andou antes.
Dende o meu punto de vista, o matiz e a complexidade de operar calquera sistema é garantir que o grosor do xeo sexa exactamente o suficiente para resolver os nosos problemas. Isto é do que estamos a falar.
En TI, paréceme, hai demasiados enfoques de "terei sorte". Moitas persoas instalan software e usan bibliotecas de software coa esperanza de ter sorte. En xeral, moitas persoas teñen sorte. Probablemente por iso funciona.
— A partir da miña valoración pesimista, vese así: cando os riscos son altos e a aplicación debe funcionar, entón é necesario o apoio de Flaunt, quizais de Red Hat, ou necesitas o teu propio equipo interno dedicado especificamente a Kubernetes, que está preparado. para tiralo.
Dmitry: Obxectivamente, isto é así. Entrar na historia de Kubernetes para un pequeno equipo por conta propia implica unha serie de riscos.
Necesitamos contedores?
— Podes dicirnos o difundido que está Kubernetes en Rusia?
Dmitry: Non teño estes datos, e non estou seguro de que ninguén os teña. Dicimos: "Kubernetes, Kubernetes", pero hai outra forma de ver este problema. Tampouco sei como de estendidos están os contedores, pero coñezo unha cifra de informes en Internet de que o 70% dos contedores están orquestrados por Kubernetes. Foi unha fonte fiable para unha mostra bastante grande en todo o mundo.
Entón outra pregunta: necesitamos contedores? O meu sentimento persoal e a posición xeral da empresa Flant é que Kubernetes é un estándar de facto.
Non haberá máis que Kubernetes.
Este é un cambio absoluto no campo da xestión de infraestruturas. Simplemente absoluto: iso é todo, non máis Ansible, Chef, máquinas virtuais, Terraform. Non falo dos vellos métodos de explotación colectiva. Kubernetes é un cambio absoluto, e agora só será así.
Está claro que para algúns levan un par de anos, e para outros un par de décadas, para darse conta disto. Non teño dúbida de que non haberá máis que Kubernetes e esta nova aparencia: xa non danamos o sistema operativo, senón que usamos infraestrutura como código, só que non con código, senón con yml - unha infraestrutura descrita declarativamente. Teño a sensación de que sempre será así.
— É dicir, aquelas empresas que aínda non cambiaron a Kubernetes cambiarán definitivamente a el ou permanecerán no esquecemento. Te entendín ben?
Dmitry: Isto tampouco é totalmente certo. Por exemplo, se temos a tarefa de executar un servidor DNS, entón pódese executar en FreeBSD 4.10 e pode funcionar perfectamente durante 20 anos. Só traballa e xa está. Quizais dentro de 20 anos teña que actualizar algo unha vez. Se estamos a falar de software no formato que lanzamos e que en realidade funciona durante moitos anos sen ningunha actualización, sen facer cambios, entón, por suposto, non haberá Kubernetes. Non é necesario alí.
Todo o relacionado con CI/CD: onde necesites a entrega continua, onde necesites actualizar versións, facer cambios activos, onde queiras crear tolerancia a fallos, só Kubernetes.
Sobre os microservizos
- Aquí teño unha lixeira disonancia. Para traballar con Kubernetes, necesitas soporte externo ou interno: este é o primeiro punto. En segundo lugar, cando estamos a comezar o desenvolvemento, somos unha pequena startup, aínda non temos nada, o desenvolvemento para Kubernetes ou a arquitectura de microservizos en xeral pode ser difícil e non sempre xustificado economicamente. Estou interesado na túa opinión: as startups teñen que comezar a escribir inmediatamente para Kubernetes desde cero, ou aínda poden escribir un monólito e despois só chegar a Kubernetes?
Dmitry: Pregunta xenial. Teño unha charla sobre microservizos Moitas veces atopeime con xente que intentaba martelar cravos cun microscopio. O enfoque en si é correcto; nós mesmos deseñamos o noso software interno deste xeito. Pero cando fas isto, debes comprender claramente o que estás facendo. A palabra que máis odio dos microservizos é "micro". Historicamente, esta palabra orixinouse alí, e por algunha razón a xente pensa que micro é moi pequeno, menos dun milímetro, como un micrómetro. Isto está mal.
Por exemplo, hai un monólito escrito por 300 persoas, e todos os que participaron no desenvolvemento entenden que hai problemas alí, e debe dividirse en micro-anacos: preto de 10 pezas, cada unha das cales está escrita por 30 persoas. nunha versión mínima. Isto é importante, necesario e legal. Pero cando nos chega unha startup, onde 3 rapaces moi chulos e talentosos escribiron 60 microservizos de xeonllos, cada vez que busco a Corvalol.
Paréceme que diso xa se falou miles de veces: obtivemos un monolito distribuído dunha forma ou outra. Isto non está xustificado economicamente, é moi difícil en xeral en todo. Acabo de ver isto tantas veces que me doe moito, así que sigo falando diso.
Á pregunta inicial, hai un conflito entre o feito de que, por unha banda, Kubernetes dá medo de usar, porque non está claro que pode romper alí ou non funciona, por outra banda, está claro que todo vai aí. e nada máis que Kubernetes existirá . Resposta - sopesa a cantidade de beneficios que vén, a cantidade de tarefas que podes resolver. Isto está nun lado da escala. Por outra banda, hai riscos asociados co tempo de inactividade ou cunha diminución do tempo de resposta, o nivel de dispoñibilidade, cunha diminución dos indicadores de rendemento.
Aquí está: ou nos movemos rapidamente e Kubernetes permítenos facer moitas cousas moito máis rápido e mellor, ou usamos solucións fiables e probadas no tempo, pero avanzamos moito máis lentamente. Esta é unha elección que toda empresa debe facer. Podes pensar nel como un camiño na selva: cando camiñas por primeira vez, podes atoparte cunha serpe, un tigre ou un teixugo tolo, e cando camiñas 10 veces, pisabas o camiño, eliminaches as ramas e andar máis doado. Cada vez o camiño vaise máis ancho. Despois é unha estrada asfaltada, e máis tarde un fermoso bulevar.
Kubernetes non se queda parado. Pregunta de novo: Kubernetes, por unha banda, son 4-5 binarios, por outra banda, é todo o ecosistema. Este é o sistema operativo que temos nas nosas máquinas. Que é isto? Ubuntu ou Curios? Este é o núcleo de Linux, unha morea de compoñentes adicionais. Todas estas cousas aquí, unha serpe velenosa foi lanzada fóra da estrada, alí levantouse un valado. Kubernetes está a desenvolverse de forma moi rápida e dinámica, e o volume de riscos, o volume de descoñecidos diminúe cada mes e, en consecuencia, estas escalas están a reequilibrarse.
Respondendo á pregunta sobre o que debería facer unha startup, diría: ven a Flaunt, paga 150 mil rublos e obtén un servizo sinxelo de DevOps chave en man. Se es unha pequena startup con poucos desenvolvedores, isto funciona. En lugar de contratar o teu propio DevOps, que terá que aprender a resolver os teus problemas e pagar un salario neste momento, obterás unha solución chave en man para todos os problemas. Si, hai algunhas desvantaxes. Nós, como subcontratistas, non podemos estar tan implicados e responder rapidamente aos cambios. Pero temos moita experiencia e prácticas preparadas. Garantimos que en calquera situación definitivamente o resolveremos rapidamente e levantaremos calquera Kubernetes de entre os mortos.
Recomendo encarecidamente externalizar a startups e empresas establecidas ata un tamaño no que se poida dedicar un equipo de 10 persoas ás operacións, porque se non, non serve de nada. Definitivamente ten sentido terceirizar isto.
Sobre Amazon e Google
— Pódese considerar un host dunha solución de Amazon ou Google como unha subcontratación?
Dmitry: Si, por suposto, isto resolve unha serie de problemas. Pero de novo hai matices. Aínda necesitas entender como usalo. Por exemplo, hai mil pequenas cousas no traballo de Amazon AWS: hai que quentar o Load Balancer ou debe escribirse unha solicitude de antemán que diga: "Chicos, recibiremos tráfico, quentar o Load Balancer para nós!" Cómpre coñecer estes matices.
Cando recorres a persoas especializadas nisto, pechan case todas as cousas típicas. Agora temos 40 enxeñeiros, a finais de ano probablemente haberá 60; definitivamente atopamos todas estas cousas. Aínda que volvamos a atopar este problema nalgún proxecto, preguntámonos rapidamente e sabemos como solucionalo.
Probablemente a resposta sexa: por suposto, unha historia aloxada facilita algunha parte. A pregunta é se estás preparado para confiar nestes hospedadores e se resolverán os teus problemas. Amazon e Google fixeron ben. Para todos os nosos casos - exactamente. Non temos máis experiencias positivas. Todas as outras nubes coas que tentamos traballar crean moitos problemas: Ager e todo o que hai en Rusia, e todo tipo de OpenStack en diferentes implementacións: Headster, Overage, o que queiras. Todos crean problemas que non queres resolver.
Polo tanto, a resposta é si, pero, de feito, non hai moitas solucións aloxadas maduras.
Quen necesita Kubernetes?
— E aínda así, quen necesita Kubernetes? Quen xa debería cambiar a Kubernetes, quen é o cliente típico de Flaunt que vén especificamente para Kubernetes?
Dmitry: Esta é unha pregunta interesante, porque agora mesmo, a raíz de Kubernetes, moitas persoas veñen a nós: "Rapaces, sabemos que estás facendo Kubernetes, faino por nós!" Contestámoslles: "Señores, nós non facemos Kubernetes, facemos prod e todo o relacionado con el". Porque actualmente é simplemente imposible facer un produto sen facer todo o CI/CD e toda esta historia. Todo o mundo afastouse da división que temos desenvolvemento por desenvolvemento, e despois explotación por explotación.
Os nosos clientes esperan cousas diferentes, pero todos esperan algún bo milagre de que teñan certos problemas, e agora, ¡hop! — Kubernetes resolveraos. A xente cre nos milagres. Nas súas mentes entenden que non haberá milagre, pero nas súas almas esperan: e se agora este Kubernetes nos soluciona todo, falan moito diso! De súpeto el agora - espirrar! - e unha bala de prata, espirra! — e temos un tempo de actividade do 100 %, todos os desenvolvedores poden lanzar 50 veces o que se poña en produción e non falla. En xeral, un milagre!
Cando estas persoas veñen a nós, dicimos: "Sentímolo, pero non hai tal cousa como un milagre". Para estar saudable, cómpre comer ben e facer exercicio. Para ter un produto fiable, hai que fabricalo de forma fiable. Para ter un CI/CD conveniente, cómpre facelo así. É moito traballo que hai que facer.
Respondendo á pregunta de quen necesita Kubernetes: ninguén necesita Kubernetes.
Algunhas persoas teñen a idea errónea de que necesitan Kubernetes. A xente necesita, ten unha necesidade profunda de deixar de pensar, estudar e interesarse por todos os problemas das infraestruturas e os problemas de execución das súas aplicacións. Queren que as aplicacións funcionen e se implementen. Para eles, Kubernetes é a esperanza de que deixen de escoitar a historia de que "estabamos deitados alí", ou "non podemos lanzar", ou outra cousa.
Adoita vir a nós o director técnico. Pregúntanlle dúas cousas: por un lado, darnos características, por outro, estabilidade. Suxerímosche que o asumas e que o fagas. A bala de prata, ou máis ben de prata, é que deixarás de pensar nestes problemas e perderás o tempo. Terás persoas especiais que pecharán este número.
A redacción de que nós ou calquera outra persoa necesitamos Kubernetes é incorrecta.
Os administradores realmente necesitan Kubernetes, porque é un xoguete moi interesante co que podes xogar e xogar. Sexamos honestos: a todo o mundo lle encantan os xoguetes. Todos somos nenos nalgún lugar, e cando vemos un novo, queremos xogalo. Para algúns, isto foi desalentado, por exemplo, na administración, porque xa xogaron abondo e xa están cansos ata o punto de que simplemente non queren. Pero isto non está completamente perdido para ninguén. Por exemplo, se estou canso dos xoguetes no campo da administración de sistemas e DevOps durante moito tempo, entón aínda me encantan os xoguetes, aínda compro algúns novos. Todas as persoas, dun xeito ou doutro, aínda queren algún tipo de xoguetes.
Non hai que xogar coa produción. O que eu recomendo categoricamente non facer e o que vexo agora en masa: "Oh, un xoguete novo!" — correron a mercalo, comprárono e: “Levámolo agora á escola e enseñámolo a todos os nosos amigos”. Non fagas isto. Pido desculpas, os meus fillos só están crecendo, constantemente vexo algo nos nenos, nótoo en min mesmo e despois xeneralizo aos demais.
A resposta final é: non necesitas Kubernetes. Necesitas resolver os teus problemas.
O que podes conseguir é:
- prod non cae;
- aínda que intente caer, sabémolo de antemán, e podemos poñerlle algo;
- podemos cambialo á velocidade á que o requira o noso negocio, e podemos facelo comodamente, non nos causa ningún problema.
Hai dúas necesidades reais: fiabilidade e dinamismo/flexibilidade de lanzamento. Todos os que estean realizando actualmente algún tipo de proxectos de TI, sen importar en que tipo de negocio - suave para facilitar o mundo, e que entendan isto, deben resolver estas necesidades. Kubernetes co enfoque correcto, coa comprensión adecuada e coa experiencia suficiente permíteche resolvelos.
Sobre sen servidor
— Se miras un pouco máis ao futuro, intentando resolver o problema da ausencia de dores de cabeza coa infraestrutura, coa velocidade de lanzamento e os cambios de aplicación, aparecen novas solucións, por exemplo, sen servidor. Sentes algún potencial nesta dirección e, digamos, un perigo para Kubernetes e solucións similares?
Dmitry: Aquí temos que facer unha observación de novo que eu non son un vidente que mira para adiante e di - será así! Aínda que eu só fixen o mesmo. Miro os meus pés e vexo alí unha morea de problemas, por exemplo, como funcionan os transistores nun ordenador. É divertido, non? Estamos atopando algúns erros na CPU.
Fai que sen servidor sexa bastante fiable, barato, eficiente e cómodo, resolvendo todos os problemas do ecosistema. Aquí estou de acordo con Elon Musk en que se necesita un segundo planeta para crear tolerancia ás fallas para a humanidade. Aínda que non sei o que di, entendo que eu non estou preparado para voar a Marte e que non vai pasar mañá.
Con servidor sen servidor está claramente claro que isto é algo ideoloxicamente correcto, como a tolerancia ás fallas para a humanidade: ter dous planetas é mellor que un. Pero como facelo agora? Enviar unha expedición non é un problema se concentras os teus esforzos nela. Enviar varias expedicións e instalar alí varios miles de persoas, creo que tamén é realista. Pero facer que sexa totalmente tolerante a fallas para que alí viva a metade da humanidade, paréceme agora imposible, sen ser considerado.
Con un a un sen servidor: a cousa está xenial, pero está lonxe dos problemas de 2019. Máis preto de 2030: vivamos para velo. Non teño dúbida de que viviremos, definitivamente viviremos (repetir antes de durmir), pero agora hai que resolver outros problemas. É como crer no pônei de conto de fadas Rainbow. Si, un par por cento dos casos resólvense, e resólvense perfectamente, pero subxectivamente, sen servidor é un arco da vella... Para min, este tema é demasiado distante e demasiado incomprensible. Non estou preparado para falar. En 2019, non podes escribir unha única aplicación sen servidor.
Como evolucionará Kubernetes
— A medida que avanzamos cara a este futuro distante potencialmente marabilloso, como cres que se desenvolverá Kubernetes e o ecosistema que o rodea?
Dmitry: Eu pensei moito nisto e teño unha resposta clara. O primeiro é con estado; despois de todo, sen estado é máis fácil de facer. Kubernetes inicialmente investiu máis nisto, todo comezou con el. Stateless funciona case perfectamente en Kubernetes, non hai nada de que queixarse. Aínda hai moitos problemas, ou mellor dito, matices. Todo alí xa funciona moi ben para nós, pero iso somos nós. Levará polo menos un par de anos máis para que isto funcione para todos. Este non é un indicador calculado, senón o meu sentimento da miña cabeza.
En resumo, Statefull debería -e desenvolverase- con moita forza, porque todas as nosas aplicacións almacenan o estado; non hai aplicacións sen estado. Esta é unha ilusión; sempre necesitas algún tipo de base de datos e algo máis. Statefull trata de endereitar todo o que é posible, corrixir todos os erros, mellorar todos os problemas aos que se enfrontan actualmente, chamémoslle adopción.
O nivel do descoñecido, o nivel de problemas sen resolver, o nivel de probabilidade de atopar algo descenderá significativamente. Esta é unha historia importante. E os operadores -todo o relacionado coa codificación da lóxica de administración, a lóxica de control para conseguir un servizo sinxelo: MySQL easy service, RabbitMQ easy service, Memcache easy service -, en xeral, todos estes compoñentes dos que temos que estar garantidos para traballar. a caixa. Isto só resolve a dor de que queremos unha base de datos, pero non queremos administrala, ou queremos Kubernetes, pero non queremos administrala.
Esta historia de desenvolvemento de operadores dunha forma ou outra será importante nos próximos anos.
Creo que a facilidade de uso debería aumentar moito: a caixa farase cada vez máis negra, máis e máis fiable, con cada vez máis botóns sinxelos.
Unha vez escoitei unha vella entrevista con Isaac Asimov dos anos 80 en YouTube en Saturday Night Live, un programa como Urgant, só interesante. Preguntáronlle polo futuro dos ordenadores. Dixo que o futuro está na sinxeleza, igual que a radio. O receptor de radio era orixinalmente unha cousa complexa. Para coller unha onda, había que xirar os botóns durante 15 minutos, xirar os pinchos e saber en xeral como funciona todo, comprender a física da transmisión de ondas de radio. Como resultado, só quedaba un botón na radio.
Agora en 2019 que radio? No coche, o receptor de radio atopa todas as ondas e os nomes das emisoras. A física do proceso non cambiou en 100 anos, pero a facilidade de uso si. Agora, e non só agora, xa en 1980, cando houbo unha entrevista con Azimov, todos usaban a radio e ninguén pensaba en como funcionaba. Sempre funcionou, iso é un feito.
Azimov dixo entón que pasaría o mesmo cos ordenadores. a facilidade de uso aumentará. Aínda que en 1980 tiveches que ser adestrado para premer botóns nun ordenador, ese non será o caso no futuro.
Teño a sensación de que con Kubernetes e coa infraestrutura tamén haberá un gran aumento da facilidade de uso. Isto, na miña opinión, é obvio: está na superficie.
Que facer cos enxeñeiros?
— Que pasará entón cos enxeñeiros e administradores de sistemas que admiten Kubernetes?
Dmitry: Que pasou co contador despois da chegada do 1C? Sobre o mesmo. Antes disto, contaban co papel, agora no programa. A produtividade do traballo aumentou en ordes de magnitude, pero o traballo en si non desapareceu. Se antes facían falta 10 enxeñeiros para enroscar unha lámpada, agora abondará cunha.
A cantidade de software e o número de tarefas, paréceme, agora está a crecer a un ritmo máis rápido do que aparecen novos DevOps e a eficiencia está a aumentar. Hai unha escaseza específica no mercado agora mesmo e durará moito tempo. Máis tarde, todo volverá a algún tipo de normalidade, na que a eficiencia do traballo aumentará, cada vez haberá máis sen servidores, unirase unha neurona a Kubernetes, que seleccionará todos os recursos exactamente segundo sexa necesario e, en xeral, fai todo por si mesmo, como debería: a persoa só se afasta e non interfira.
Pero alguén aínda terá que tomar decisións. Está claro que o nivel de cualificación e especialización desta persoa é superior. Hoxe en día, no departamento de contabilidade, non fai falta que 10 empregados leven libros para que non se cansen as mans. Simplemente non é necesario. Moitos documentos son dixitalizados e recoñecidos automaticamente polo sistema de xestión de documentos electrónicos. Un xefe de contabilidade intelixente é suficiente, xa con habilidades moito maiores, con bo entendemento.
En xeral, este é o camiño a seguir en todas as industrias. Cos coches pasa o mesmo: antes viña un coche cun mecánico e tres condutores. Hoxe en día, conducir un coche é un proceso sinxelo no que todos participamos todos os días. Ninguén pensa que un coche é algo complicado.
O DevOps ou a enxeñería de sistemas non desaparecerán: aumentará o traballo de alto nivel e a eficiencia.
— Tamén escoitei unha idea interesante de que o traballo realmente aumentará.
Dmitry: Por suposto, ao cen por cen! Porque a cantidade de software que escribimos está en constante crecemento. O número de problemas que resolvemos co software está en constante crecemento. A cantidade de traballo está crecendo. Agora o mercado de DevOps está terriblemente recalentado. Isto pódese ver nas expectativas salariais. En boa forma, sen entrar en detalles, debería haber xuvenís que queiran X, medios que queiran 1,5X e maiores que queiran 2X. E agora, se miras o mercado salarial de Moscow DevOps, un júnior quere de X a 3X e un senior quere de X a 3X.
Ninguén sabe canto custa. O nivel salarial mídese pola túa confianza: un manicomio completo, para ser honesto, un mercado terriblemente superenriquecido.
Por suposto, esta situación cambiará moi pronto - debería producirse algunha saturación. Este non é o caso do desenvolvemento de software - a pesar de que todos necesitan desenvolvedores e todos necesitan bos desenvolvedores, o mercado entende quen vale para que - a industria asentouse. Este non é o caso de DevOps nestes días.
— Polo que escoitei, concluín que o actual administrador do sistema non debería preocuparse demasiado, pero é hora de mellorar as súas habilidades e prepararse para o feito de que mañá haberá máis traballo, pero será máis cualificado.
Dmitry: cen por cen. En xeral, vivimos en 2019 e a regra de vida é esta: aprendizaxe ao longo da vida: aprendemos ao longo da nosa vida. Paréceme que agora todo o mundo xa sabe e sente isto, pero non abonda con sabelo: hai que facelo. Cada día debemos cambiar. Se non o facemos, tarde ou cedo deixarémonos á marxe da profesión.
Estea preparado para xiros bruscos de 180 graos. Non descarto unha situación na que algo cambie radicalmente, se invente algo novo: pasa. Hop! - e agora actuamos doutro xeito. É importante estar preparado para iso e non preocuparse. Pode suceder que mañá todo o que fago resulte innecesario: nada, estudei toda a vida e estou preparado para aprender outra cousa. Non é un problema. Non hai que ter medo á seguridade laboral, pero hai que estar preparado para aprender constantemente algo novo.
Desexos e un minuto de publicidade
- Tes algún desexo?
Dmitry: Si, teño varios desexos.
Primeiro e mercantil - subscribirse . Queridos lectores, vai a YouTube e subscríbete á nosa canle. Dentro dun mes aproximadamente comezaremos a expansión activa do servizo de vídeo, teremos moitos contidos educativos sobre Kubernetes, abertos e variados: desde cousas prácticas, ata laboratorios, pasando por cousas teóricas fundamentais profundas e como usar Kubernetes no nivel de principios e patróns.
O segundo desexo mercantil - ir a e poñer estrelas porque nos alimentamos delas. Se non nos das estrelas, non teremos nada para comer. É como o maná nun xogo de ordenador. Facemos algo, facemos, intentamos, alguén di que son bicicletas terribles, alguén que todo está completamente mal, pero seguimos e actuamos con absoluta honestidade. Vemos un problema, resolvemos e compartimos a nosa experiencia. Polo tanto, dános unha estrela, que non se afastará de ti, pero chegará a nós, porque nos alimentamos delas.
Terceiro desexo importante e xa non mercantil. deixa de crer nos contos de fadas. Sodes profesionais. DevOps é unha profesión moi seria e responsable. Deixa de xogar no lugar de traballo. Deixa que faga clic por ti e entenderás. Imaxina que chegas ao hospital e alí o médico está a experimentar contigo. Entendo que isto pode resultar ofensivo para alguén, pero o máis probable é que non se trate de ti, senón doutra persoa. Dille aos demais que paren tamén. Isto realmente arruina a vida de todos nós: moitos comezan a tratar as operacións, os administradores e os DevOps como tipos que romperon algo de novo. Isto foi "roto" a maioría das veces debido ao feito de que fomos xogar, e non miramos con fría conciencia de que así é, e así é.
Isto non significa que non debas experimentar. Necesitamos experimentar, facémolo nós mesmos. Para ser honesto, nós mesmos ás veces xogamos - isto, por suposto, é moi malo, pero nada humano é alleo para nós. Declaramos 2019 un ano de experimentos serios e ben pensados, e non de xogos en produción. Probablemente así.
- Moitas grazas!
Dmitry: Grazas, Vitaly, tanto polo tempo como pola entrevista. Queridos lectores, moitas grazas se de súpeto chegaches a este punto. Espero que vos trouxemos polo menos un par de reflexións.
Na entrevista, Dmitry tocou o tema do werf. Agora este é un coitelo suízo universal que resolve case todos os problemas. Pero non sempre foi así. Activado no festival Dmitry Stolyarov falarache sobre esta ferramenta en detalle. no informe haberá de todo: problemas e matices ocultos de Kubernetes, opcións para resolver estas dificultades e a implementación actual de werf en detalle. Únete a nós os días 27 e 28 de maio, crearemos as ferramentas perfectas.
Fonte: www.habr.com