{"id":34450,"date":"2019-10-31T21:58:24","date_gmt":"2019-10-31T18:58:24","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kubernetes-zahvatit-mir-kogda-i-kak\/"},"modified":"2019-10-31T21:58:24","modified_gmt":"2019-10-31T18:58:24","slug":"kubernetes-zahvatit-mir-kogda-i-kak","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/kubernetes-zahvatit-mir-kogda-i-kak","title":{"rendered":"O Kubernetes conquistar\u00e1 o mundo. Quando e como?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Na v\u00e9spera DevOpsConf<\/a><\/noindex> Vitaly Khabarov<\/b> fez uma entrevista com\u00a0Dmitry Stolyarov<\/b> (distol<\/a><\/noindex>), diretor t\u00e9cnico e cofundador da empresa \"Flant\". Vitaly perguntou a Dmitry sobre o que a \"Flant\" faz, sobre Kubernetes, o desenvolvimento do ecossistema, suporte. Discutiram por que precisamos do Kubernetes e se ele \u00e9 realmente necess\u00e1rio. Tamb\u00e9m falaram sobre microsservi\u00e7os, Amazon AWS, a abordagem \"Vou me sair bem\" no DevOps, o futuro do Kubernetes, por que, quando e como ele dominar\u00e1 o mundo, as perspectivas do DevOps e o que os engenheiros devem se preparar para o futuro pr\u00f3ximo com simplifica\u00e7\u00f5es e redes neurais.<\/p>\n

A grava\u00e7\u00e3o da entrevista<\/a><\/noindex> em forma de podcast pode ser ouvida no DevOps Deflope \u2014 o podcast em russo sobre DevOps, e abaixo est\u00e1 a vers\u00e3o escrita. <\/p>\n

\"O
\n
\nAqui e adiante, as perguntas s\u00e3o feitas por Vitaly Khabarov<\/a><\/noindex> um engenheiro da Express42.
\n<\/a><\/noindex><\/p>\n

Sobre a \"Flant\"<\/h2>\n

\n\u2014 Dima, ol\u00e1. Voc\u00ea \u00e9 o diretor t\u00e9cnico da \"Flant<\/a><\/noindex>\" e tamb\u00e9m seu fundador. Por favor, conte-nos o que a empresa faz e qual \u00e9 o seu papel nela?<\/b><\/p>\n

\"ODmitry<\/b>: Do lado de fora, parece que somos aqueles caras que v\u00e3o por a\u00ed instalando Kubernetes e fazendo algo com ele. Mas n\u00e3o \u00e9 assim. Come\u00e7amos como uma empresa que lida com Linux, mas j\u00e1 h\u00e1 muito tempo nossa principal atividade \u00e9 a manuten\u00e7\u00e3o de projetos de produ\u00e7\u00e3o e highload sob demanda. Normalmente, constru\u00edmos toda a infraestrutura do zero e depois gerenciamos isso por um longo tempo. Portanto, o principal trabalho que \"Flant\" realiza, pelo qual \u00e9 remunerada, \u00e9 assumir a responsabilidade e implementar a produ\u00e7\u00e3o sob demanda<\/b>.
\n

\n

\nEu, como diretor t\u00e9cnico e um dos cofundadores da empresa, estou constantemente pensando em como aumentar a disponibilidade da produ\u00e7\u00e3o, simplificar sua opera\u00e7\u00e3o, facilitar a vida dos administradores e tornar a vida dos desenvolvedores mais prazerosa.<\/p>\n

Sobre o Kubernetes<\/h2>\n

\n\u2014 Ultimamente, tenho visto muitas palestras da \"Flant\" e\u00a0de artigos<\/a><\/noindex> sobre Kubernetes. Como voc\u00eas chegaram at\u00e9 ele?<\/b><\/p>\n

Dmitry<\/b>: Eu j\u00e1 falei sobre isso muitas vezes, mas n\u00e3o me importo em repetir. Acredito que \u00e9 importante repetir esse t\u00f3pico, pois h\u00e1 confus\u00e3o entre causa e efeito.<\/p>\n

Precis\u00e1vamos muito de uma ferramenta. Enfrentamos uma s\u00e9rie de problemas, lutamos, superamos eles de v\u00e1rias maneiras e sentimos a necessidade de uma ferramenta. Experimentamos muitas op\u00e7\u00f5es diferentes, inventamos nossas pr\u00f3prias solu\u00e7\u00f5es e acumulamos experi\u00eancia. Gradualmente, chegamos ao ponto em que come\u00e7amos a usar o Docker quase assim que ele surgiu - por volta de 2013. Quando ele apareceu, j\u00e1 t\u00ednhamos muita experi\u00eancia com cont\u00eaineres e j\u00e1 hav\u00edamos escrito um an\u00e1logo ao \"Docker\" - algumas solu\u00e7\u00f5es improvisadas em Python. Com o surgimento do Docker, surgiu a possibilidade de descartar as improvisa\u00e7\u00f5es e usar uma solu\u00e7\u00e3o confi\u00e1vel e apoiada pela comunidade.<\/p>\n

A hist\u00f3ria com o Kubernetes \u00e9 semelhante. No momento em que come\u00e7ou a ganhar impulso - para n\u00f3s, isso \u00e9 a vers\u00e3o 1.2 - j\u00e1 t\u00ednhamos v\u00e1rias solu\u00e7\u00f5es improvisadas tanto em Shell como em Chef, que est\u00e1vamos tentando orquestrar com o Docker. Olhamos seriamente para o Rancher e v\u00e1rias outras solu\u00e7\u00f5es, mas ent\u00e3o apareceu o Kubernetes, que tinha tudo implementado exatamente como ter\u00edamos feito n\u00f3s ou at\u00e9 melhor. N\u00e3o h\u00e1 nada a reclamar.<\/p>\n

Sim, h\u00e1 algumas imperfei\u00e7\u00f5es aqui, algumas falhas ali \u2014 muitas pend\u00eancias, e a 1.2 \u00e9 realmente assustadora, mas... o Kubernetes \u00e9 como um edif\u00edcio em constru\u00e7\u00e3o \u2014 voc\u00ea olha para o projeto e percebe que ser\u00e1 incr\u00edvel. Se o edif\u00edcio j\u00e1 tem uma funda\u00e7\u00e3o e dois andares, voc\u00ea entende que \u00e9 melhor n\u00e3o se mudar ainda, mas com o software n\u00e3o h\u00e1 esses problemas \u2014 j\u00e1 pode ser utilizado.<\/p>\n

N\u00e3o tivemos um momento em que pensamos se usar\u00edamos o Kubernetes ou n\u00e3o. Est\u00e1vamos \u00e0 espera dele muito antes de ele aparecer, e est\u00e1vamos tentando criar nossos pr\u00f3prios an\u00e1logos.<\/p><\/blockquote>\n

<\/p>\n

Sobre o Kubernetes<\/h2>\n

\n\u2014 Voc\u00ea participa diretamente do desenvolvimento do pr\u00f3prio Kubernetes?<\/b><\/p>\n

Dmitry<\/b>: Moderadamente. Participamos mais do desenvolvimento do ecossistema. Enviamos uma quantidade de pull requests: para o Prometheus, para v\u00e1rios operadores, para o Helm \u2014 para o ecossistema. Infelizmente, n\u00e3o consigo acompanhar tudo o que fazemos e posso cometer erros, mas n\u00e3o temos nenhum pull request para o n\u00facleo.<\/p>\n

\u2014 Ao mesmo tempo, voc\u00eas desenvolvem muitas ferramentas em torno do Kubernetes?<\/b><\/p>\n

Dmitry<\/b>: A estrat\u00e9gia \u00e9 a seguinte: vamos e fazemos pull requests em tudo o que j\u00e1 existe. Se os pull requests n\u00e3o s\u00e3o aceitos, apenas os forkeamos para n\u00f3s mesmos e continuamos enquanto eles n\u00e3o forem aceitos com nossas vers\u00f5es. Depois, quando isso chega ao upstream, voltamos para a vers\u00e3o do upstream.<\/p>\n

Por exemplo, temos o operador Prometheus, com o qual alternamos para a vers\u00e3o upstream da nossa constru\u00e7\u00e3o cerca de 5 vezes, provavelmente. Precisamos de um recurso, enviamos um pull request, precisamos implement\u00e1-lo amanh\u00e3 e n\u00e3o queremos esperar que ele seja lan\u00e7ado na vers\u00e3o upstream. Portanto, montamos nossa pr\u00f3pria vers\u00e3o com o recurso que precisamos em todos os nossos clusters. Depois, isso \u00e9, por exemplo, incorporado ao upstream com as palavras: \"Pessoal, vamos fazer isso para um caso mais geral\", e n\u00f3s, ou algu\u00e9m, terminamos isso e, com o tempo, \u00e9 novamente mesclado.<\/p>\n

Tudo o que existe, tentamos desenvolver<\/b>. Muitos elementos que ainda n\u00e3o existem, ainda n\u00e3o foram inventados ou foram, mas n\u00e3o conseguiram ser implementados \u2014 n\u00f3s fazemos. E n\u00e3o porque gostamos do processo em si ou da constru\u00e7\u00e3o de bicicletas como um setor, mas simplesmente porque precisamos dessa ferramenta. Frequentemente, nos perguntam por que fizemos isso ou aquilo? A resposta \u00e9 simples \u2014 porque precis\u00e1vamos avan\u00e7ar, resolver um problema pr\u00e1tico, e resolvemos com essa ferramenta.<\/p>\n

O caminho sempre \u00e9 este: procuramos muito cuidadosamente e, se n\u00e3o encontramos nenhuma solu\u00e7\u00e3o, como fazer um tr\u00f3lei a partir de um p\u00e3o, ent\u00e3o fazemos nosso pr\u00f3prio p\u00e3o e nosso pr\u00f3prio tr\u00f3lei.<\/p><\/blockquote>\n

<\/p>\n

Ferramentas da Flant<\/h2>\n

\n\u2014 Sei que atualmente a Flant possui operadores addon, operadores shell, ferramentas dapp\/werf. Como entendo, isso \u00e9 a mesma ferramenta em diferentes encarna\u00e7\u00f5es. Tamb\u00e9m entendo que dentro da Flant h\u00e1 muitas outras ferramentas diferentes. \u00c9 verdade?<\/b><\/p>\n

Dmitry<\/b>: Temos muitas outras coisas no GitHub. Desde o que consigo me lembrar agora, temos o statusmap \u2014 um painel para Grafana que todo mundo adora. Ele \u00e9 mencionado praticamente em cada segundo artigo sobre monitoramento de Kubernetes no Medium. \u00c9 imposs\u00edvel descrever brevemente o que \u00e9 statusmap \u2014 precisa de um artigo separado, mas \u00e9 uma coisa muito \u00fatil para monitorar o status ao longo do tempo, j\u00e1 que, no Kubernetes, muitas vezes precisamos mostrar o status ao longo do tempo. Tamb\u00e9m temos o LogHouse \u2014 uma solu\u00e7\u00e3o baseada em ClickHouse e m\u00e1gica negra para coletar logs no Kubernetes.<\/p>\n

Muitas utilidades! E haver\u00e1 ainda mais, pois algumas solu\u00e7\u00f5es internas ser\u00e3o lan\u00e7adas este ano. Dentre as grandes, com base no operador addon, h\u00e1 uma s\u00e9rie de addons para Kubernetes, como instalar corretamente o sert manager \u2013 uma ferramenta para gerenciar certificados, como instalar Prometheus com muitos complementos \u2013 s\u00e3o cerca de vinte bin\u00e1rios diferentes que exportam dados e coletam informa\u00e7\u00f5es, com Prometheus oferecendo gr\u00e1ficos incr\u00edveis e alertas. Todos esses s\u00e3o addons para Kubernetes que podem ser instalados no cluster, transformando-o de simples em avan\u00e7ado, autom\u00e1tico, onde muitas quest\u00f5es j\u00e1 est\u00e3o resolvidas. Sim, estamos fazendo muitas coisas.<\/p>\n

Desenvolvimento do ecossistema<\/h2>\n

\n\u2014 Acredito que isso \u00e9 uma contribui\u00e7\u00e3o muito grande para o desenvolvimento desta ferramenta e seus m\u00e9todos de uso. Voc\u00ea pode estimar quem mais poderia fazer uma contribui\u00e7\u00e3o semelhante para o desenvolvimento do ecossistema?<\/b><\/p>\n

Dmitry<\/b>: Na R\u00fassia, dentre as empresas que atuam no nosso mercado \u2013 ningu\u00e9m chega nem perto.<\/b>. Claro, \u00e9 uma declara\u00e7\u00e3o ousada, pois h\u00e1 grandes players, como Mail e Yandex \u2013 eles tamb\u00e9m est\u00e3o fazendo algo com Kubernetes, mas mesmo eles n\u00e3o se comparam \u00e0 contribui\u00e7\u00e3o de empresas ao redor do mundo, que est\u00e3o fazendo muito mais do que n\u00f3s. \u00c9 dif\u00edcil comparar \"Flant\" com uma equipe de 80 pessoas e a Red Hat, que tem 300 engenheiros apenas para Kubernetes, se n\u00e3o me engano. \u00c9 complicado comparar. Temos em nosso departamento de P&D 6 pessoas, incluindo eu, que desenvolvem todas as nossas ferramentas. 6 pessoas contra 300 engenheiros da Red Hat \u2013 \u00e9 dif\u00edcil fazer essa compara\u00e7\u00e3o.<\/p>\n

\u2014 No entanto, quando mesmo essas 6 pessoas conseguem fazer algo realmente \u00fatil e transfer\u00edvel, ao se depararem com uma tarefa pr\u00e1tica e entregarem a solu\u00e7\u00e3o para a comunidade \u2013 \u00e9 um caso interessante. Entendo que em grandes empresas de tecnologia, onde h\u00e1 desenvolvimento pr\u00f3prio e uma equipe de suporte para Kubernetes, ferramentas semelhantes podem ser desenvolvidas. Isso serve de exemplo para eles, de que \u00e9 poss\u00edvel desenvolver e entregar \u00e0 comunidade, impulsionando todo o ecossistema que utiliza Kubernetes.<\/b><\/p>\n

Dmitry<\/b>: Provavelmente, essa \u00e9 uma caracter\u00edstica do integrador, sua particularidade. Temos muitos projetos e vemos muitas situa\u00e7\u00f5es diferentes. Para n\u00f3s, a principal forma de gerar valor agregado \u00e9 analisar esses casos, encontrar o que eles t\u00eam em comum e maximizar a redu\u00e7\u00e3o de custos para n\u00f3s. Estamos ativamente envolvidos nisso. \u00c9 dif\u00edcil falar sobre a R\u00fassia e o mundo, mas temos cerca de 40 engenheiros DevOps na empresa que trabalham com Kubernetes. N\u00e3o acredito que haja muitas empresas na R\u00fassia com um n\u00famero compar\u00e1vel de especialistas em Kubernetes, se \u00e9 que existem.<\/p>\n

Eu entendo tudo sobre o t\u00edtulo de DevOps Engineer, todos entendem e se acostumaram a chamar os engenheiros DevOps de engenheiros DevOps, n\u00e3o vamos discutir isso. Todos esses 40 engenheiros DevOps incr\u00edveis enfrentam problemas diariamente e os resolvem, n\u00f3s apenas analisamos essa experi\u00eancia e tentamos generalizar. Sabemos que se isso permanecer conosco, em um ou dois anos a ferramenta se tornar\u00e1 in\u00fatil, porque algo aparecer\u00e1 na comunidade. N\u00e3o faz sentido acumular essa experi\u00eancia internamente \u2014 \u00e9 apenas um desperd\u00edcio de esfor\u00e7o e tempo em dev\/null. Assim, n\u00e3o nos importamos em compartilhar. Temos o prazer de publicar tudo e entendemos que isso deve ser divulgado, promovido, para que as pessoas possam usar e adicionar suas experi\u00eancias \u2014 assim tudo cresce e vive. Ent\u00e3o, em dois anos, a ferramenta n\u00e3o ser\u00e1 jogada no lixo. N\u00e3o hesitamos em continuar investindo esfor\u00e7o, porque \u00e9 vis\u00edvel que algu\u00e9m est\u00e1 usando sua ferramenta, e em dois anos, todos j\u00e1 a utilizam.<\/p>\n

Essa \u00e9 parte da nossa grande estrat\u00e9gia com dapp\/werf.<\/b>. N\u00e3o lembro exatamente quando come\u00e7amos a faz\u00ea-lo, parece que foi h\u00e1 uns 3 anos. Inicialmente, era tudo em shell. Foi um super proof of concept, resolvemos algumas de nossas quest\u00f5es particulares \u2014 deu certo! Mas com shell havia problemas, n\u00e3o era poss\u00edvel escalar, programar em shell \u00e9 uma atividade complicada. T\u00ednhamos o h\u00e1bito de programar em Ruby, ent\u00e3o, refizemos algumas coisas em Ruby, desenvolvemos, desenvolvemos, e nos deparamos com o fato de que a comunidade, as pessoas, que n\u00e3o dizem 'queremos ou n\u00e3o queremos', torcem o nariz para Ruby, por mais engra\u00e7ado que pare\u00e7a. Percebemos que dever\u00edamos escrever tudo isso em Go, para simplesmente atender ao primeiro item da lista de verifica\u00e7\u00e3o: A ferramenta DevOps deve ser um bin\u00e1rio est\u00e1tico.<\/b>Se vai ser Go ou n\u00e3o, isso n\u00e3o \u00e9 t\u00e3o importante, mas preferimos um bin\u00e1rio est\u00e1tico escrito em Go.<\/p>\n

Despendemos esfor\u00e7os para reescrever o dapp em Go e o chamamos de werf. O dapp n\u00e3o \u00e9 mais suportado, n\u00e3o \u00e9 mais desenvolvido, funciona em uma vers\u00e3o antiga, mas existe um caminho de upgrade absoluto que pode ser seguido.<\/p>\n

Por que o dapp foi criado<\/h2>\n

\n\u2014 Voc\u00ea pode explicar brevemente por que o dapp foi criado e quais problemas ele resolve?<\/b><\/p>\n

Dmitry<\/b>: A primeira raz\u00e3o est\u00e1 na constru\u00e7\u00e3o. Inicialmente, tivemos grandes problemas com a constru\u00e7\u00e3o, quando o Docker n\u00e3o suportava multi-stage, e tivemos que implementar o multi-stage por conta pr\u00f3pria. Em seguida, tivemos uma s\u00e9rie de quest\u00f5es relacionadas \u00e0 limpeza da imagem. Todos que fazem CI\/CD enfrentam, mais cedo ou mais tarde, o problema de que h\u00e1 muitas imagens constru\u00eddas, e \u00e9 necess\u00e1rio limpar o que n\u00e3o \u00e9 necess\u00e1rio, mantendo o que \u00e9.<\/p>\n

A segunda raz\u00e3o est\u00e1 na implanta\u00e7\u00e3o. Sim, existe o Helm, mas ele resolve apenas parte das quest\u00f5es. Por mais engra\u00e7ado que pare\u00e7a, est\u00e1 escrito que \"Helm \u00e9 o Gerenciador de Pacotes para Kubernetes\". Exatamente isso, \"o\". Al\u00e9m disso, existem as palavras \"Gerenciador de Pacotes\" \u2014 qual \u00e9 a expectativa usual de um Gerenciador de Pacotes? Dizemos: \"Gerenciador de Pacotes \u2014 instale o pacote!\" e esperamos que ele nos diga: \"Pacote instalado\". <\/p>\n

\u00c9 interessante que dizemos: \"Helm, instale o pacote\", mas quando ele responde que instalou, descobrimos que ele apenas iniciou a instala\u00e7\u00e3o \u2014 informou ao Kubernetes: \"Inicie este item!\", mas se come\u00e7ou ou n\u00e3o, se est\u00e1 funcionando ou n\u00e3o, o Helm n\u00e3o resolve essa quest\u00e3o.<\/p>\n

Portanto, o Helm \u00e9 apenas um pr\u00e9-processador de texto que carrega dados no Kubernetes.<\/p><\/blockquote>\n

\nMas dentro de qualquer implanta\u00e7\u00e3o, queremos saber \u2014 o aplicativo foi implantado em produ\u00e7\u00e3o ou n\u00e3o? Implantado em produ\u00e7\u00e3o significa que o aplicativo foi lan\u00e7ado, uma nova vers\u00e3o foi implantada, e ela est\u00e1 l\u00e1, pelo menos n\u00e3o est\u00e1 falhando e responde corretamente. O Helm n\u00e3o resolve essa tarefa. Para resolver isso, \u00e9 necess\u00e1rio despender muito esfor\u00e7o, pois \u00e9 preciso dar uma ordem ao Kubernetes para implantar e acompanhar o que est\u00e1 acontecendo \u2014 se foi implantado ou n\u00e3o, se ocorreu a migra\u00e7\u00e3o. Al\u00e9m disso, h\u00e1 v\u00e1rias tarefas relacionadas \u00e0 implanta\u00e7\u00e3o, limpeza e constru\u00e7\u00e3o.<\/p>\n

Planos<\/h2>\n

\nAinda este ano vamos avan\u00e7ar com o desenvolvimento local. Queremos atingir o que antes era poss\u00edvel no Vagrant \u2014 digitar \u00abvagrant up\u00bb e ter nossas m\u00e1quinas virtuais prontas. Aspiramos chegar a um ponto onde, ao ter um projeto no Git, podemos escrever \u00abwerf up\u00bb e isso levanta uma c\u00f3pia local do projeto, implantada em um mini-Kub local, com todos os diret\u00f3rios conectados e prontos para desenvolvimento. Dependendo da linguagem de desenvolvimento, isso acontece de maneiras diferentes, mas, no entanto, a inten\u00e7\u00e3o \u00e9 permitir um desenvolvimento local eficiente com arquivos montados.<\/p>\n

O pr\u00f3ximo passo para n\u00f3s \u00e9 investir fortemente na conveni\u00eancia para os desenvolvedores.<\/b>. Para que, com uma \u00fanica ferramenta, possamos rapidamente levantar um projeto localmente, desenvolv\u00ea-lo, fazer push para o Git, e ele seja exatamente implantado no est\u00e1gio ou nos testes, dependendo dos pipelines, e ent\u00e3o, com a mesma ferramenta, ir para a produ\u00e7\u00e3o. Esta unidade, unifica\u00e7\u00e3o e reprodutibilidade da infraestrutura, do ambiente local at\u00e9 a produ\u00e7\u00e3o, \u00e9 um ponto muito importante para n\u00f3s. Mas isso ainda n\u00e3o est\u00e1 dispon\u00edvel no werf \u2014 estamos apenas planejando.<\/p>\n

Mas o caminho para o dapp\/werf sempre foi o mesmo que no in\u00edcio com o Kubernetes. Enfrentamos problemas, encontramos solu\u00e7\u00f5es alternativas \u2014 inventamos algumas solu\u00e7\u00f5es usando shell, ou qualquer coisa. Depois, tentamos de alguma forma simplificar, generalizar e consolidar essas solu\u00e7\u00f5es em bin\u00e1rios com os quais compartilhamos.<\/p>\n

H\u00e1 tamb\u00e9m outra perspectiva sobre toda essa hist\u00f3ria, com analogias. <\/p>\n

Kubernetes \u00e9 como um chassi de carro com motor. N\u00e3o h\u00e1 portas, janelas, r\u00e1dio, ou qualquer coisa \u2014 s\u00f3 a estrutura e o motor. E h\u00e1 o Helm \u2014 isso \u00e9 o volante. Legal ter o volante, mas precisamos de um pino de dire\u00e7\u00e3o, uma barra de dire\u00e7\u00e3o, transmiss\u00e3o e rodas, sem os quais n\u00e3o d\u00e1.<\/p><\/blockquote>\n

\nNo caso do werf \u2014 \u00e9 mais um componente para o Kubernetes. Apenas agora temos na vers\u00e3o alfa do werf, por exemplo, o Helm \u00e9 compilado internamente no werf, porque estamos cansados de fazer isso por conta pr\u00f3pria. H\u00e1 muitas raz\u00f5es para fazer isso e, em breve, vou explicar exatamente por que compilamos o Helm junto com o Tiller dentro do werf. na apresenta\u00e7\u00e3o na RIT++<\/a><\/noindex>.<\/p>\n

Atualmente, o werf \u00e9 um componente mais integrado. Recebemos um volante pronto, um pino de dire\u00e7\u00e3o \u2014 eu n\u00e3o sou muito bom com carros, mas \u00e9 um grande bloco que resolve um amplo espectro de tarefas. N\u00e3o precisamos ficar procurando no cat\u00e1logo, combinando uma pe\u00e7a com a outra, pensando em como fix\u00e1-las. Obtemos uma colheitadeira pronta, que resolve um grande conjunto de tarefas de imediato. Mas por dentro, \u00e9 composto pelos mesmos componentes open-source, tudo ainda utiliza Docker para a constru\u00e7\u00e3o, Helm para parte da funcionalidade, e h\u00e1 v\u00e1rias outras bibliotecas. \u00c9 uma ferramenta integrada para obter rapidamente e convenientemente um \u00f3timo CI\/CD de forma pr\u00e1tica.<\/p>\n

\u00c9 dif\u00edcil manter o Kubernetes?<\/h2>\n

\n\u2014 Voc\u00ea menciona a experi\u00eancia de que come\u00e7aram a usar o Kubernetes, que para voc\u00eas \u00e9 um quadro, um motor, e que \u00e9 poss\u00edvel adicionar muitas coisas diferentes: um corpo, um volante, instalar pedais, assentos. Surge a quest\u00e3o \u2014 qu\u00e3o dif\u00edcil \u00e9 para voc\u00eas manter o Kubernetes? Voc\u00eas t\u00eam uma experi\u00eancia rica, quanto tempo e recursos voc\u00eas precisam especificamente para a manuten\u00e7\u00e3o do Kubernetes em rela\u00e7\u00e3o ao resto?<\/b><\/p>\n

Dmitry<\/b>: Esta \u00e9 uma pergunta muito dif\u00edcil e, para responder, \u00e9 necess\u00e1rio entender o que significa manuten\u00e7\u00e3o e o que queremos do Kubernetes. Talvez voc\u00ea possa esclarecer?<\/p>\n

\u2014 Pelo que sei e como vejo, muitas equipes agora querem experimentar o Kubernetes. Todos est\u00e3o se envolvendo, instalando de maneira improvisada. Tenho a impress\u00e3o de que as pessoas nem sempre entendem a complexidade desse sistema.<\/b><\/p>\n

Dmitry<\/b>: \u00c9 verdade.<\/p>\n

\u2014 Qu\u00e3o dif\u00edcil \u00e9 simplesmente pegar e instalar o Kubernetes do zero, para que ele esteja pronto para produ\u00e7\u00e3o?<\/b><\/p>\n

Dmitry<\/b>: O que voc\u00ea acha, qu\u00e3o dif\u00edcil \u00e9 realizar uma cirurgia de cora\u00e7\u00e3o? Entendo, a pergunta \u00e9 embara\u00e7osa. Utilizar um bisturi e n\u00e3o cometer erros \u2014 isso n\u00e3o \u00e9 t\u00e3o complicado. Se voc\u00ea sabe onde cortar e onde coser, a pr\u00f3pria procedimento n\u00e3o \u00e9 dif\u00edcil. O complicado \u00e9 garantir que tudo funcione a cada vez.<\/p>\n

Instalar o Kubernetes e faz\u00ea-lo funcionar \u00e9 simples: plim! \u2014 foi instalado, h\u00e1 muitas formas de instala\u00e7\u00e3o. Mas o que acontecer\u00e1 quando surgirem problemas?<\/p><\/blockquote>\n

\nSempre surgem quest\u00f5es \u2014 o que ainda n\u00e3o consideramos? O que ainda n\u00e3o fizemos? Quais par\u00e2metros do n\u00facleo do Linux especificamos incorretamente? Meu Deus, n\u00f3s realmente os especificamos?! Quais componentes do Kubernetes instalamos e quais n\u00e3o? Surgem milhares de perguntas, e para respond\u00ea-las, \u00e9 necess\u00e1rio ter 15-20 anos de experi\u00eancia na ind\u00fastria.<\/p>\n

Eu tenho um exemplo recente sobre esse tema que pode esclarecer o problema \"\u00c9 dif\u00edcil suportar o Kubernetes?\". Faz algum tempo que consideramos seriamente a possibilidade de implementar o Cilium como rede no Kubernetes.<\/p>\n

Deixe-me explicar o que \u00e9 o Cilium. No Kubernetes, existem muitas implementa\u00e7\u00f5es diferentes do subsistema de rede, e uma delas \u00e9 muito interessante - o Cilium. Qual \u00e9 a sua ess\u00eancia? No n\u00facleo, surgiu a possibilidade de escrever hooks para o kernel, que de uma forma ou de outra interferem no subsistema de rede e em v\u00e1rios outros subsistemas, permitindo contornar grandes partes do kernel.<\/p>\n

Historicamente, o kernel Linux possui ip rout, netfilter, bridges e muitos outros componentes antigos que t\u00eam 15, 20 ou 30 anos. Em geral, eles funcionam bem, tudo \u00e9 \u00f3timo, mas agora temos muitos containers e isso parece uma torre de 15 tijolos empilhados um sobre o outro, e voc\u00ea est\u00e1 em cima dela equilibrando-se em uma perna - uma sensa\u00e7\u00e3o estranha. Este sistema se desenvolveu historicamente com muitas nuances, como um ap\u00eandice no organismo. Em algumas situa\u00e7\u00f5es, h\u00e1 problemas de performance, por exemplo.<\/p>\n

H\u00e1 um BPF incr\u00edvel e a possibilidade de escrever hooks para o kernel - os desenvolvedores escreveram seus pr\u00f3prios hooks para o kernel. O pacote chega ao kernel Linux, eles o retiram diretamente na entrada, processam como necess\u00e1rio sem bridges, sem TCP, sem stack IP - ou seja, contornando tudo que est\u00e1 escrito no kernel Linux e imediatamente o direcionam para o container.<\/p>\n

Qual foi o resultado? Um desempenho incr\u00edvel, recursos fant\u00e1sticos - simplesmente maravilhoso! Mas olhamos para isso e vemos que em cada m\u00e1quina h\u00e1 um programa que se conecta \u00e0 API do Kubernetes e, com os dados que recebe dessa API, gera c\u00f3digo C e compila bin\u00e1rios que s\u00e3o carregados no kernel para que esses hooks funcionem no espa\u00e7o do kernel.<\/p>\n

O que acontecer\u00e1 se algo der errado? N\u00e3o sabemos. Para entender isso, \u00e9 preciso ler todo esse c\u00f3digo e compreender toda a l\u00f3gica, e isso \u00e9 extremamente complicado. Mas, por outro lado, existem essas bridges, netfilters, ip rout - eu n\u00e3o li seu c\u00f3digo-fonte, e 40 engenheiros que trabalham em nossa empresa tamb\u00e9m n\u00e3o. Pode ser que apenas algumas pessoas entendam certas partes.<\/p>\n

E qual \u00e9 a diferen\u00e7a? Assim, existe o ip rout, o n\u00facleo do Linux, e h\u00e1 uma nova ferramenta - qual \u00e9 a diferen\u00e7a, n\u00e3o entendemos uma nem a outra. Mas temos medo de usar o novo - por qu\u00ea? Porque se a ferramenta tem 30 anos, ent\u00e3o ao longo de 30 anos todos os bugs foram descobertos, todos os erros foram cometidos e n\u00e3o \u00e9 necess\u00e1rio saber sobre todos - funciona como uma caixa preta e sempre funciona. Todos sabem qual chave de fenda usar em qual lugar, qual tcpdump iniciar em qual momento. Todos conhecem bem as ferramentas de diagn\u00f3stico e entendem como esse conjunto de componentes funciona no n\u00facleo do Linux - n\u00e3o como \u00e9 organizado, mas como us\u00e1-lo.<\/p>\n

Mas o incr\u00edvel Cilium n\u00e3o tem 30 anos, ele ainda n\u00e3o foi testado. O mesmo problema com o Kubernetes, c\u00f3pia. Tanto o Cilium \u00e9 instalado perfeitamente, quanto o Kubernetes \u00e9 instalado perfeitamente, mas, quando algo der errado na produ\u00e7\u00e3o, voc\u00ea conseguir\u00e1 entender rapidamente, em uma situa\u00e7\u00e3o cr\u00edtica, o que deu errado? <\/p>\n

Quando falamos se \u00e9 dif\u00edcil manter o Kubernetes - n\u00e3o, \u00e9 muito simples, e sim, \u00e9 incrivelmente complicado. O Kubernetes funciona perfeitamente por si s\u00f3, mas com bilh\u00f5es de nuances.<\/p><\/blockquote>\n

<\/p>\n

Sobre a abordagem 'Vou ter sorte'<\/h2>\n

\n\u2014 Existem empresas onde essas nuances quase garantidamente aparecer\u00e3o? Suponha que o Yandex de repente transfira todos os servi\u00e7os para o Kubernetes, l\u00e1 haver\u00e1 uma carga enorme.<\/b><\/p>\n

Dmitry<\/b>: N\u00e3o, essa conversa n\u00e3o \u00e9 sobre carga, mas sobre coisas simples. Por exemplo, temos o Kubernetes, implantamos uma aplica\u00e7\u00e3o l\u00e1. Como sabemos se ela est\u00e1 funcionando? N\u00e3o existe uma ferramenta pronta para entender se a aplica\u00e7\u00e3o n\u00e3o est\u00e1 falhando. N\u00e3o h\u00e1 um sistema pronto que envia alertas - precisamos configurar esses alertas e cada gr\u00e1fico. E n\u00f3s estamos atualizando o Kubernetes.<\/p>\n

Temos Ubuntu 16.04. Pode-se dizer que \u00e9 uma vers\u00e3o antiga, mas ainda estamos nela porque \u00e9 LTS. Ela possui systemd, cuja particularidade \u00e9 que n\u00e3o limpa os C-groups. O Kubernetes inicia pods, cria C-groups, depois exclui os pods, e assim acaba acontecendo \u2014 n\u00e3o me lembro dos detalhes, desculpe \u2014 que restam fatias do systemd. Isso leva a que, com o tempo, qualquer m\u00e1quina comece a apresentar lentid\u00e3o significativa. N\u00e3o \u00e9 nem uma quest\u00e3o de highload. Se pods constantes forem iniciados, por exemplo, se houver um Cron Job que gera continuamente pods, a m\u00e1quina com Ubuntu 16.04 come\u00e7ar\u00e1 a travar em uma semana. Haver\u00e1 sempre uma alta carga m\u00e9dia devido ao grande n\u00famero de C-groups criados. Este \u00e9 um problema que qualquer pessoa que simplesmente instalar Ubuntu 16 e rodar Kubernetes enfrentar\u00e1.<\/p>\n

Suponha que ele atualize de alguma forma o systemd ou outra coisa, mas no n\u00facleo do Linux at\u00e9 a vers\u00e3o 4.16 a situa\u00e7\u00e3o \u00e9 ainda mais engra\u00e7ada \u2014 ao remover C-groups, eles persistem no n\u00facleo e, na verdade, n\u00e3o s\u00e3o removidos. Portanto, ap\u00f3s um m\u00eas de uso desta m\u00e1quina, n\u00e3o ser\u00e1 poss\u00edvel olhar as estat\u00edsticas de mem\u00f3ria dos pods. N\u00f3s pegamos um arquivo, fazemos processamento nele e um arquivo leva 15 segundos porque o n\u00facleo demora muito para calcular internamente milh\u00f5es de C-groups que supostamente foram exclu\u00eddos, mas na verdade n\u00e3o \u2014 eles persistem.<\/p>\n

Ainda h\u00e1 muitos desses pequenos detalhes por aqui e ali. N\u00e3o \u00e9 uma quest\u00e3o que empresas gigantes podem ocasionalmente enfrentar sob grandes cargas \u2014 n\u00e3o, \u00e9 uma quest\u00e3o do dia a dia. As pessoas podem viver assim por meses \u2014 instalaram o Kubernetes, implementaram a aplica\u00e7\u00e3o \u2014 parece que funciona. Para muitos, isso est\u00e1 ok. Quanto ao fato de que em algum momento essa aplica\u00e7\u00e3o pode cair sem explica\u00e7\u00e3o, eles nem v\u00e3o saber, nenhum alerta chegar\u00e1, mas para eles isso \u00e9 normal. Antes viviam em m\u00e1quinas virtuais sem monitoramento, agora mudaram para o Kubernetes tamb\u00e9m sem monitoramento \u2014 qual \u00e9 a diferen\u00e7a?<\/p>\n

A quest\u00e3o \u00e9 que quando andamos sobre o gelo, nunca sabemos a sua espessura, a menos que tenhamos medido antes. Muitos andam e n\u00e3o se preocupam, porque j\u00e1 andaram anteriormente.<\/p>\n

Na minha vis\u00e3o, a nuance e a complexidade na opera\u00e7\u00e3o de qualquer sistema est\u00e1 em garantir que a espessura do gelo seja suficiente para resolver nossas tarefas. \u00c9 sobre isso.<\/p><\/blockquote>\n

\nNa tecnologia, parece que existem muitas abordagens do tipo \"Vou ter sorte\". Muitos instalam softwares e usam bibliotecas na esperan\u00e7a de que ter\u00e3o sorte. No geral, muitos t\u00eam sorte. Provavelmente \u00e9 por isso que isso funciona.<\/p>\n

\u2014 Na minha avalia\u00e7\u00e3o pessimista, parece que: quando os riscos s\u00e3o altos e o aplicativo precisa funcionar, \u00e9 necess\u00e1ria uma assist\u00eancia da \"Flant\", possivelmente da Red Hat, ou \u00e9 necess\u00e1rio ter uma equipe interna dedicada especificamente ao Kubernetes que esteja pronta para mant\u00ea-lo.<\/b><\/p>\n

Dmitry<\/b>: Objetivamente, \u00e9 assim. Envolver uma pequena equipe na jornada do Kubernetes envolve um certo n\u00edvel de riscos.<\/p>\n

Precisamos de containers?<\/h2>\n

\n\u2014 Voc\u00ea pode contar o qu\u00e3o difundido o Kubernetes \u00e9 na R\u00fassia?<\/b><\/p>\n

Dmitry<\/b>: Eu n\u00e3o tenho esses dados e n\u00e3o estou certo de que algu\u00e9m os tenha de fato. Dizemos: \"Kubernetes, Kubernetes\", mas h\u00e1 outro ponto de vista sobre essa quest\u00e3o. N\u00e3o sei o qu\u00e3o difundidos s\u00e3o os containers, mas conhe\u00e7o um n\u00famero de relat\u00f3rios na internet que indicam que 70% dos containers s\u00e3o orquestrados pelo Kubernetes. Essa foi uma fonte confi\u00e1vel com uma amostra bastante abrangente em todo o mundo.<\/p>\n

A pr\u00f3xima pergunta \u00e9: precisamos de containers?<\/b> Tenho a sensa\u00e7\u00e3o pessoal e, de maneira geral, a posi\u00e7\u00e3o da empresa \"Flant\" \u00e9 que o Kubernetes \u00e9 o padr\u00e3o de fato.<\/p>\n

Nada al\u00e9m do Kubernetes existir\u00e1.<\/p><\/blockquote>\n

\n\u00c9 um verdadeiro divisor de \u00e1guas na gest\u00e3o de infraestrutura. Absolutamente \u2014 chega de Ansible, Chef, m\u00e1quinas virtuais, Terraform. E n\u00e3o estou nem falando de m\u00e9todos antigos e arcaicos. Kubernetes \u00e9 um verdadeiro divisor de \u00e1guas<\/b>, e agora ser\u00e1 somente assim.<\/p>\n

\u00c9 claro que algumas pessoas levar\u00e3o alguns anos, enquanto outras levar\u00e3o d\u00e9cadas para perceber isso. N\u00e3o tenho d\u00favidas de que n\u00e3o haver\u00e1 nada al\u00e9m do Kubernetes e dessa nova abordagem: n\u00e3o estaremos mais tocando o sistema operacional, mas usando infraestrutura como c\u00f3digo<\/b>, mas n\u00e3o com c\u00f3digo, e sim com yml \u2014 infraestrutura descrita de forma declarativa. Tenho a sensa\u00e7\u00e3o de que assim ser\u00e1 para sempre.<\/p>\n

\u2014 Ou seja, as empresas que ainda n\u00e3o migraram para o Kubernetes definitivamente estar\u00e3o obrigadas a faz\u00ea-lo ou acabar\u00e3o esquecidas. Estou entendendo corretamente?<\/b><\/p>\n

Dmitry<\/b>: Isso tamb\u00e9m n\u00e3o est\u00e1 totalmente correto. Por exemplo, se temos a tarefa de iniciar um servidor DNS, ele pode ser executado no FreeBSD 4.10 e pode funcionar perfeitamente por 20 anos. Apenas funcionar e pronto. Talvez ao longo de 20 anos, algo precise ser atualizado uma vez. Se estamos falando sobre software que foi iniciado e realmente funciona por muitos anos sem atualiza\u00e7\u00f5es, sem altera\u00e7\u00f5es, ent\u00e3o, claro, n\u00e3o haver\u00e1 Kubernetes. Ele n\u00e3o \u00e9 necess\u00e1rio.<\/p>\n

Tudo que diz respeito a CI\/CD - em todos os lugares onde \u00e9 necess\u00e1rio Continuous Delivery, onde \u00e9 preciso atualizar vers\u00f5es, fazer altera\u00e7\u00f5es ativas, em todos os lugares onde \u00e9 necess\u00e1rio construir resili\u00eancia - apenas Kubernetes.<\/p><\/blockquote>\n

<\/p>\n

Sobre microsservi\u00e7os<\/h2>\n

\n\u2014 Aqui eu tenho um pequeno disson\u00e2ncia. Para trabalhar com Kubernetes, \u00e9 necess\u00e1rio suporte externo ou interno - esse \u00e9 o primeiro ponto. O segundo - quando estamos apenas come\u00e7ando o desenvolvimento, somos uma pequena startup, n\u00e3o temos nada ainda, desenvolver para Kubernetes ou mesmo para uma arquitetura de microsservi\u00e7os pode ser complicado e nem sempre justificado economicamente. Estou interessado na sua opini\u00e3o - startups devem come\u00e7ar imediatamente a escrever para Kubernetes desde o in\u00edcio ou ainda \u00e9 poss\u00edvel escrever um monolito e depois apenas migrar para Kubernetes?<\/b><\/p>\n

Dmitry<\/b>: \u00d3tima pergunta. Eu tenho uma palestra sobre microsservi\u00e7os \u00abMicrosservi\u00e7os: o tamanho importa\u00bb.<\/a><\/noindex> Eu j\u00e1 me deparei v\u00e1rias vezes com pessoas tentando pregar pregos com um microsc\u00f3pio. O pr\u00f3prio approach \u00e9 correto, n\u00f3s mesmos projetamos nosso software interno exatamente dessa maneira. Mas quando voc\u00ea faz isso, \u00e9 necess\u00e1rio entender claramente o que est\u00e1 fazendo. O que eu mais odeio em microsservi\u00e7os \u00e9 a palavra \u201cmicro\u201d. Historicamente, surgiram com essa palavra, e por algum motivo as pessoas pensam que micro \u00e9 muito pequeno, menor que um mil\u00edmetro, como um micr\u00f4metro. N\u00e3o \u00e9 assim.<\/p>\n

Por exemplo, h\u00e1 um monolito que est\u00e1 sendo escrito por 300 pessoas, e todos que participaram do desenvolvimento entendem que h\u00e1 problemas e que ele precisa ser quebrado em micro partes - cerca de 10, cada uma das quais \u00e9 escrita por pelo menos 30 pessoas. Isso \u00e9 importante, necess\u00e1rio e incr\u00edvel. Mas quando uma startup nos apresenta 3 jovens muito legais e talentosos que escreveram 60 microsservi\u00e7os de forma improvisada, eu sempre procuro por calmantes.<\/p>\n

Parece que j\u00e1 falamos sobre isso milhares de vezes \u2014 acabamos por obter um mon\u00f3lito distribu\u00eddo de alguma forma. Isso n\u00e3o \u00e9 economicamente vi\u00e1vel, \u00e9 extremamente complicado. Eu j\u00e1 vi isso tantas vezes que chega a doer, por isso continuo falando sobre o assunto.<\/p>\n

Voltando \u00e0 pergunta inicial, h\u00e1 um conflito entre o fato de que, por um lado, usar Kubernetes \u00e9 assustador, pois n\u00e3o est\u00e1 claro o que pode falhar ou n\u00e3o funcionar, e, por outro lado, \u00e9 evidente que tudo est\u00e1 indo nessa dire\u00e7\u00e3o e nada al\u00e9m do Kubernetes existir\u00e1. A resposta \u00e9: pesar o volume de benef\u00edcios que vem, a quantidade de tarefas que voc\u00ea pode resolver.<\/b>. Esse \u00e9 um lado da balan\u00e7a. Do outro lado est\u00e3o os riscos associados ao tempo de inatividade ou \u00e0 diminui\u00e7\u00e3o do tempo de resposta, do n\u00edvel de disponibilidade \u2014 \u00e0 diminui\u00e7\u00e3o dos indicadores de desempenho.<\/p>\n

A situa\u00e7\u00e3o \u00e9 a seguinte \u2014 ou nos movemos rapidamente, e o Kubernetes permite realizar muitas coisas muito mais r\u00e1pido e melhor, ou usamos solu\u00e7\u00f5es confi\u00e1veis, testadas pelo tempo, mas avan\u00e7amos muito mais devagar. Essa escolha deve ser feita por cada empresa. Pode-se considerar isso como um caminho na selva \u2014 quando voc\u00ea vai pela primeira vez, pode encontrar uma cobra, um tigre ou um texugo feroz, mas quando voc\u00ea j\u00e1 foi 10 vezes \u2014 voc\u00ea abriu a trilha, retirou os galhos e fica mais f\u00e1cil de passar. A cada vez, a trilha fica mais larga. Depois disso, j\u00e1 \u00e9 uma estrada pavimentada, e mais tarde, um belo boulevard.<\/p>\n

O Kubernetes n\u00e3o para no tempo. Novamente a quest\u00e3o: o Kubernetes, por um lado, s\u00e3o 4-5 bin\u00e1rios, e por outro \u2014 \u00e9 todo um ecossistema. \u00c9 o sistema operacional que temos nas m\u00e1quinas. O que \u00e9 isso? Ubuntu ou Curios? \u00c9 o n\u00facleo do Linux, uma por\u00e7\u00e3o de componentes adicionais. Todas essas coisas aqui jogaram uma cobra venenosa para fora da estrada, e l\u00e1 colocaram uma cerca. O Kubernetes est\u00e1 se desenvolvendo muito rapidamente e dinamicamente, e o volume de riscos, a quantidade de desconhecido diminui a cada m\u00eas e, consequentemente, essas balan\u00e7as se reequilibram.<\/p>\n

Respondendo \u00e0 pergunta sobre o que fazer um startup, eu diria: venha para a \"Flant\", pague 150 mil rublos e obtenha um servi\u00e7o f\u00e1cil de DevOps chave na m\u00e3o. Se voc\u00ea \u00e9 um pequeno startup com alguns desenvolvedores, isso funciona. Em vez de contratar seu pr\u00f3prio DevOps, que precisaria aprender a resolver seus problemas e receber um sal\u00e1rio durante esse tempo, voc\u00ea receber\u00e1 a solu\u00e7\u00e3o para todas as quest\u00f5es chave na m\u00e3o. Sim, existem algumas desvantagens. N\u00f3s, como prestadores de servi\u00e7os, n\u00e3o podemos estar t\u00e3o envolvidos e reagir rapidamente \u00e0s mudan\u00e7as. Mas, por outro lado, temos uma enorme quantidade de expertise e pr\u00e1ticas prontas. Garantimos que, em qualquer situa\u00e7\u00e3o, vamos resolver tudo rapidamente e levantar qualquer Kubernetes do inferno. <\/p>\n

Eu recomendo categoricamente a terceiriza\u00e7\u00e3o para startups e neg\u00f3cios j\u00e1 estabelecidos at\u00e9 o ponto em que voc\u00ea pode alocar uma equipe de 10 pessoas para opera\u00e7\u00f5es, porque, caso contr\u00e1rio, n\u00e3o h\u00e1 sentido. Faz todo o sentido terceirizar.<\/p><\/blockquote>\n

<\/p>\n

Sobre a Amazon e o Google<\/h2>\n

\n\u2014 Pode-se considerar a hospedagem como uma terceiriza\u00e7\u00e3o pela solu\u00e7\u00e3o da Amazon ou do Google?<\/b><\/p>\n

Dmitry<\/b>: Sim, com certeza, isso resolve algumas quest\u00f5es. Mas de novo, h\u00e1 nuances. Voc\u00ea ainda precisa entender como usar isso. Por exemplo, h\u00e1 mil detalhes no funcionamento da Amazon AWS: o Load Balancer precisa ser aquecido ou voc\u00ea precisa solicitar de antem\u00e3o, dizendo: \"pessoal, teremos tr\u00e1fego, aque\u00e7am nosso Load Balancer!\" Essas nuances precisam ser conhecidas.<\/p>\n

Quando voc\u00ea se dirige a pessoas que se especializam nisso, voc\u00ea obt\u00e9m quase todas as coisas padr\u00e3o atendidas. Temos atualmente 40 engenheiros, e at\u00e9 o final do ano, provavelmente teremos 60 \u2014 com certeza j\u00e1 enfrentamos todos esses problemas. Mesmo se em algum projeto voltarmos a nos deparar com esse problema, j\u00e1 perguntamos rapidamente uns aos outros e sabemos como resolver.<\/p>\n

Provavelmente, a resposta \u00e9 que, com certeza, uma solu\u00e7\u00e3o hospedada facilita uma parte disso. A quest\u00e3o \u00e9 se voc\u00ea est\u00e1 pronto para confiar nesses provedores de hospedagem e se eles resolver\u00e3o seus problemas. Amazon e Google t\u00eam uma boa reputa\u00e7\u00e3o. Para todos os nossos casos - com certeza. N\u00e3o temos mais experi\u00eancias positivas. Todos os outros clouds com os quais tentamos trabalhar criam muitos problemas - tanto Ager quanto tudo o que existe na R\u00fassia, e v\u00e1rias implementa\u00e7\u00f5es do OpenStack: Headster, Overage - tudo o que voc\u00ea quiser. Todos eles criam problemas que n\u00e3o queremos resolver.<\/p>\n

Portanto, a resposta \u00e9 sim, mas, na pr\u00e1tica, existem poucos servi\u00e7os hospedados maduros.<\/p>\n

Quem precisa do Kubernetes?<\/h2>\n

\n\u2014 Mas afinal, quem precisa do Kubernetes? Quem deve realmente migrar para o Kubernetes, quem \u00e9 o cliente t\u00edpico da \"Flante\" que vem especificamente em busca do Kubernetes?<\/b><\/p>\n

Dmitry<\/b>: A quest\u00e3o \u00e9 interessante, porque atualmente, com a onda do Kubernetes, muitos est\u00e3o chegando at\u00e9 n\u00f3s: \"Pessoal, sabemos que voc\u00eas trabalham com Kubernetes, fa\u00e7am para n\u00f3s!\". N\u00f3s respondemos: \"Senhores, n\u00e3o fazemos Kubernetes, n\u00f3s gerenciamos produ\u00e7\u00e3o e tudo que est\u00e1 relacionado a isso\". Porque implementar produ\u00e7\u00e3o sem configurar todo o CI\/CD e toda essa hist\u00f3ria \u00e9 simplesmente imposs\u00edvel no momento. Todos abandonaram o conceito de que temos desenvolvimento separado da opera\u00e7\u00e3o.<\/p>\n

Nossos clientes esperam coisas diferentes, mas todos aguardam por algum tipo de milagre, acreditando que t\u00eam certos problemas, e agora \u2014 voil\u00e0! \u2014 o Kubernetes os resolver\u00e1. As pessoas acreditam em milagres. Compreendem racionalmente que n\u00e3o haver\u00e1 um milagre, mas esperam com o cora\u00e7\u00e3o \u2014 e se o Kubernetes resolver tudo para n\u00f3s, j\u00e1 que falam tanto sobre isso! E se ele agora fosse o toque m\u00e1gico \u2014 e, puff! \u2014 tiv\u00e9ssemos 100% de uptime, todos os desenvolvedores poderiam fazer 50 lan\u00e7amentos de qualquer coisa na produ\u00e7\u00e3o e tudo funcionaria. Enfim, um milagre!<\/p>\n

Quando essas pessoas v\u00eam at\u00e9 n\u00f3s, dizemos: \"Desculpe, mas milagres n\u00e3o existem\". Para ser saud\u00e1vel, voc\u00ea precisa se alimentar bem e praticar esportes. Para ter uma produ\u00e7\u00e3o confi\u00e1vel, voc\u00ea deve constru\u00ed-la de forma robusta. Para ter um CI\/CD eficiente, ele deve ser elaborado corretamente. Isso requer muito trabalho.<\/p>\n

Respondendo \u00e0 pergunta de quem precisa do Kubernetes \u2014 o Kubernetes n\u00e3o \u00e9 necess\u00e1rio para ningu\u00e9m.<\/p><\/blockquote>\n

\nAlgumas pessoas t\u00eam a ideia err\u00f4nea de que precisam do Kubernetes. As pessoas querem profundamente parar de se preocupar, se envolver e se interessar por todos os problemas de infraestrutura e pelo lan\u00e7amento de seus aplicativos. Elas desejam que os aplicativos simplesmente funcionem e sejam implantados sem complica\u00e7\u00f5es. Para elas, o Kubernetes \u00e9 a esperan\u00e7a de que elas n\u00e3o ouvir\u00e3o mais hist\u00f3rias como \"estamos enfrentando dificuldades\" ou \"n\u00e3o conseguimos lan\u00e7ar\", ou qualquer outra coisa.<\/p>\n

Geralmente, um diretor t\u00e9cnico nos procura. Ele \u00e9 questionado sobre duas coisas: de um lado, funcionalidades, e do outro, estabilidade. N\u00f3s oferecemos assumir isso e resolver. A verdadeira deixa m\u00e1gica \u00e9 que voc\u00ea deixar\u00e1 de se preocupar com esses problemas e perder tempo. Voc\u00ea ter\u00e1 pessoas especializadas que cuidar\u00e3o dessa quest\u00e3o.<\/p>\n

A formula\u00e7\u00e3o de que precisamos do Kubernetes ou de algu\u00e9m \u00e9 errada.<\/p><\/blockquote>\n

\nO Kubernetes \u00e9 muito necess\u00e1rio para os administradores, porque \u00e9 um brinquedo muito interessante, com o qual podemos brincar e explorar. Vamos ser honestos \u2013 todos amam brinquedos. Todos n\u00f3s ainda somos crian\u00e7as em algum lugar, e quando vemos um novo brinquedo, queremos brincar com ele. Alguns j\u00e1 perderam esse interesse, especialmente na administra\u00e7\u00e3o, porque j\u00e1 brincaram o suficiente e est\u00e3o cansados, a ponto de n\u00e3o querer mais. Mas ningu\u00e9m perdeu completamente esse interesse. Por exemplo, se eu j\u00e1 estou cansado de brinquedos na \u00e1rea de administra\u00e7\u00e3o de sistemas e DevOps, eu ainda amo brinquedos e continuo comprando algumas novidades. As pessoas, de uma forma ou de outra, ainda querem algum tipo de brinquedo.<\/p>\n

N\u00e3o brinque com produ\u00e7\u00e3o. O que eu categoricamente n\u00e3o recomendo fazer e o que vejo atualmente em massa: \"Ah, um novo brinquedo!\" \u2013 todos correm para compr\u00e1-lo, compram e: \"Vamos lev\u00e1-lo para a escola agora e mostrar a todos os amigos\". N\u00e3o fa\u00e7a isso. Pe\u00e7o desculpas, meus filhos est\u00e3o crescendo, estou constantemente vendo algo neles, percebendo isso em mim e depois generalizando isso em rela\u00e7\u00e3o aos outros.<\/p>\n

Resposta final: voc\u00ea n\u00e3o precisa do Kubernetes. Voc\u00ea precisa resolver seus problemas.<\/p><\/blockquote>\n

\nVoc\u00ea pode alcan\u00e7ar que:<\/p>\n