Kubernetes vai dominar o mundo. Quando e como?

Na véspera do DevOpsConf, Vitaliy Khabarov entrevistou Dmitry Stolyarov ( distol ), diretor técnico e cofundador da Flant. Vitaly perguntou a Dmitry sobre o que Flant está fazendo, sobre Kubernetes, desenvolvimento de ecossistemas, suporte. Discutimos por que o Kubernetes é necessário e se é necessário. E também sobre microsserviços, Amazon AWS, a abordagem "Tenho sorte" no DevOps, o futuro do Kubernetes, por que, quando e como ele irá dominar o mundo, as perspectivas do DevOps e o que os engenheiros devem preparar no futuro brilhante e simplificado com redes neurais.

Ouça a entrevista original como um podcast no DevOps Deflop, um podcast em russo sobre o DevOps e, abaixo, uma versão em texto.



A seguir, Vitaliy Khabarov recebe perguntas de um engenheiro da Express42.

Sobre Flant

- Dima, oi. Você é o diretor técnico da Flant e também seu fundador. Diga-me, por favor, o que a empresa está fazendo e você está nela?

Dmitry : Do lado de fora, parece que somos os caras que colocam Kubernetes em todos e fazem algo com ele. Mas isso não é verdade. Começamos como uma empresa que lida com Linux, mas por muito tempo nossa atividade principal foi atender projetos de produção e carga pesada. Geralmente construímos toda a infraestrutura do zero e somos responsáveis ​​por ela por um longo tempo. Portanto, o principal trabalho que Flant realiza, pelo qual recebe dinheiro, é assumir a responsabilidade e implementar a produção turnkey .


Como diretor técnico e um dos fundadores da empresa, trabalho o tempo todo para pensar em maneiras de aumentar a disponibilidade de produção, simplificar sua operação, facilitar a vida dos administradores e tornar a vida mais agradável para os desenvolvedores.

Sobre o Kubernetes

- A última vez em "Flanta", eu vi muitos relatórios e artigos sobre o Kubernetes. Como você veio a ele?

Dmitry : Eu já falei sobre isso muitas vezes, mas não sinto muito repeti-lo. Eu acredito que é correto repetir este tópico, porque há confusão entre causa e efeito.

Nós realmente precisamos de uma ferramenta. Enfrentamos muitos problemas, lutamos, superamos com muletas diferentes e sentimos a necessidade de um instrumento. Peneirou muitas opções diferentes, construiu suas bicicletas e ganhou experiência. Gradualmente, chegamos ao ponto em que começamos a usar o Docker quase assim que apareceu - por volta de 2013. No momento de sua aparição, já tínhamos muita experiência com contêineres, já escrevíamos um análogo de "Docker" - algumas de nossas muletas em Python. Com o advento do Docker, as muletas podem ser descartadas e usadas por uma solução confiável e apoiada pela comunidade.

Com Kubernetes, a história é semelhante. Quando ele começou a ganhar impulso - para nós, essa é a versão 1.2 - já tínhamos muitas muletas no Shell e no Chef, que de alguma forma tentamos orquestrar o Docker. Nós olhamos seriamente para o Rancher e várias outras soluções, mas então o Kubernetes apareceu, em que tudo é implementado exatamente como deveríamos ou até melhor. Não há o que reclamar.

Sim, há algum tipo de imperfeição, existe algum tipo de imperfeição - existem muitas imperfeições e o 1.2 geralmente é horrível, mas ... Kubernetes é como um prédio em construção - você olha o projeto e entende que será legal. Se o prédio agora tem uma fundação e dois andares, você entende que é melhor não preencher ainda, mas não existem problemas com o software - você já pode usá-lo.

Não tivemos o momento em que pensamos usar o Kubernetes ou não. Estávamos esperando por ele muito antes de ele aparecer e tentamos fazer análogos nós mesmos.

Perto de Kubernetes

- Você participa diretamente do desenvolvimento do próprio Kubernetes?

Dmitry : Medíocre. É mais provável que participemos do desenvolvimento do ecossistema. Enviamos uma certa quantidade de solicitações de recebimento: para Prometheus, para todos os tipos de operadores, para Helm, para o ecossistema. Infelizmente, não sou capaz de acompanhar tudo o que fazemos e posso estar enganado, mas não existe um único pool do nosso núcleo.

- Você desenvolve muitas das suas ferramentas em torno do Kubernetes?

Dmitry : A estratégia é esta: nós vamos e puxamos em tudo o que já está lá. Se solicitações pull não forem aceitas lá, simplesmente as forçamos por nós mesmos e viveremos até que sejam aceitas com nossas compilações. Então, quando chega à montante, retornamos à versão upstream.

Por exemplo, temos um operador Prometheus com o qual já mudamos para a montante de nossa montagem 5 vezes, provavelmente. Precisamos de algum recurso, enviamos uma solicitação de recebimento, precisamos lançá-lo amanhã e não queremos esperar até que ele seja lançado no upstream. Dessa forma, coletamos para nós mesmos, reunimos nossa montagem com nosso recurso, que por algum motivo precisamos, para todos os nossos clusters. Então, por exemplo, eles nos envolvem com as palavras: "Gente, vamos fazer isso para um caso mais geral", nós, ou outra pessoa, concluiremos isso e, eventualmente, nos uniremos novamente.

Tudo o que existe, estamos tentando desenvolver . Muitos elementos que ainda não estão lá ainda não foram inventados ou foram inventados, mas ainda não foram implementados - estamos fazendo isso. E não porque gostamos do próprio processo ou da construção de bicicletas como uma indústria, mas simplesmente porque precisamos dessa ferramenta. Eles costumam fazer a pergunta: por que fizemos isso ou aquilo? A resposta é simples - porque tivemos que ir além, resolver algum problema prático e resolvemos com esta ferramenta.

O caminho é sempre o seguinte: olhamos com muito cuidado e, se não encontrarmos uma solução, como fazer um bonde com pão, então fazemos nosso próprio pão e nosso próprio bonde.

Ferramentas Flant

“Eu sei que o Flant agora tem operadores de complementos, operadores de shell, ferramentas dapp / werf. Pelo que entendi, esta é a mesma ferramenta em diferentes encarnações. Também entendo que existem muito mais ferramentas diferentes dentro do Flant. É isso mesmo?

Dmitry : Ainda temos muitas coisas no GitHub. Pelo que me lembro agora, temos um mapa de status - um painel para a Grafana que foi para todos. É mencionado em quase todo segundo artigo sobre o monitoramento do Kubernetes no Medium. É impossível descrever brevemente o que é o mapa de status - você precisa de um artigo separado, mas isso é muito útil para monitorar o status ao longo do tempo, já que no Kubernetes geralmente precisamos mostrar o status ao longo do tempo. Também temos o LogHouse - este é um ClickHouse e uma peça baseada em magia negra para coletar logs no Kubernetes.

Muitos utilitários! E haverá ainda mais, porque várias soluções internas serão lançadas este ano. Dos grandes operadores baseados em add-ons, existem vários addons para o Kubernetes, mas como instalar o gerenciador de serts corretamente - uma ferramenta de gerenciamento de certificados, como instalar o Prometheus com um monte de desvios corretamente - são vinte binários diferentes que exportam dados e coletam algo, para isso Prometheus é gráficos e alertas impressionantes. Tudo isso é apenas um monte de complementos para o Kubernetes que são colocados em um cluster e passa de simples para legal, sofisticado, automático, no qual muitos problemas já foram resolvidos. Sim, fazemos muito.

Desenvolvimento de ecossistemas

- Parece-me que essa é uma grande contribuição para o desenvolvimento desta ferramenta e de seus métodos de uso. Você pode descobrir mais ou menos quem mais faria a mesma contribuição para o desenvolvimento do ecossistema?

Dmitry : Na Rússia, nenhuma dessas empresas que operam em nosso mercado está próxima . Obviamente, essa é uma afirmação de alto nível, porque existem grandes players como o Mail with Yandex - eles também fazem algo com o Kubernetes, mas mesmo assim eles não corresponderam à contribuição das empresas no mundo, que estão fazendo muito mais do que nós. É difícil comparar Flant com uma equipe de 80 pessoas e a Red Hat, na qual existem apenas 300 engenheiros da Kubernetes, se não me engano. É difícil comparar. Temos 6 pessoas no departamento de RnD, incluindo eu, que estão vendo todas as nossas ferramentas. 6 pessoas contra 300 engenheiros da Red Hat - é difícil comparar.

- No entanto, quando mesmo essas 6 pessoas podem fazer algo realmente útil e alienado, quando são confrontadas com uma tarefa prática e decidem a comunidade - um caso interessante. Entendo que em grandes empresas de tecnologia, onde eles têm seu próprio desenvolvimento e a equipe de suporte do Kubernetes, em princípio, as mesmas ferramentas podem ser desenvolvidas. Este é um exemplo para eles que podem ser desenvolvidos e dados à comunidade, para dar um impulso a toda a comunidade que usa o Kubernetes.

Dmitry : Este é provavelmente um chip integrador, sua característica. Temos muitos projetos e vemos muitas situações diferentes. Para nós, a principal maneira de criar valor agregado é analisar esses casos, encontrar os comuns e torná-los o mais barato possível para nós. Estamos fazendo isso ativamente. É difícil falar sobre a Rússia e o mundo, mas temos cerca de 40 engenheiros de DevOps na Kubernetes. Não acho que na Rússia existam muitas empresas com um número comparável de especialistas que entendem o Kubernetes, se houver.

Entendo tudo sobre o cargo de engenheiro do DevOps, todos entendem tudo e estão acostumados a chamar engenheiros do DevOps como engenheiros do DevOps. Não discutiremos isso. Todos esses 40 engenheiros maravilhosos do DevOps enfrentam problemas todos os dias e os resolvem, apenas analisamos essa experiência e tentamos resumir. Entendemos que, se permanecer conosco, em um ano ou dois a ferramenta será inútil, porque em algum lugar da comunidade uma ferramenta pronta aparecerá. Não faz sentido acumular essa experiência por dentro - é apenas uma perda de tempo e energia em dev / null. E assim não sentimos muito. É com grande prazer que publicamos tudo e compreendemos que precisamos publicá-lo, desenvolvê-lo, promovê-lo, promovê-lo, para que as pessoas possam usar e adicionar sua própria experiência - para que tudo cresça e viva. Depois de dois anos, a ferramenta não vai para o lixo. Não é uma pena continuar a derramar energia, porque é claro que alguém está usando sua ferramenta e, depois de dois anos, todos estão usando.

Isso faz parte da nossa grande estratégia com o dapp / werf . Parece que não me lembro de quando começamos a fazer isso há cerca de três anos. Inicialmente, geralmente estava no shell. Foi uma super prova de conceito, resolvemos algumas de nossas tarefas particulares - acabou! Mas há problemas com o shell, é impossível construí-lo ainda mais, a programação no shell é outra coisa. Tínhamos o hábito de escrever em Ruby, respectivamente, em Ruby refizemos algo, desenvolvemos, desenvolvemos, desenvolvemos e descansamos no fato de que a comunidade, uma multidão que não diz "queremos ou não queremos", vira o nariz para Ruby, não é engraçado. Percebemos que deveríamos escrever todas essas coisas no Go, apenas para corresponder ao primeiro parágrafo da lista de verificação: a ferramenta DevOps deve ser um binário estático . On Go ou não Go não é tão importante, mas um binário estático escrito em Go é melhor.

Esforçou-se, reescreveu o dapp no ​​Go e nomeou-o werf. O Dapp não é mais suportado, não se desenvolve, funciona em algumas versões mais recentes, mas há um caminho absoluto de atualização para o topo, e você pode segui-lo.

Por que o dapp foi criado?

- Você pode nos dizer brevemente por que o dapp foi criado, que problemas ele resolve?

Dmitry : A primeira razão na montagem. Inicialmente, tivemos fortes problemas de construção quando o Docker não sabia como fazer vários estágios, e fizemos vários estágios por conta própria. Depois, tivemos um monte de perguntas com a limpeza da imagem. Todo mundo que cria CI / CD, mais cedo ou mais tarde, enfrenta o problema de que há um monte de imagens coletadas, você precisa de alguma forma limpar o que não é necessário e deixar o que é necessário.

O segundo motivo está na implantação. Sim, existe Helm, mas resolve apenas parte dos problemas. Ironicamente, está escrito que "Helm - o Gerenciador de Pacotes do Kubernetes". Ou seja, que "o". Existem também as palavras "Gerenciador de Pacotes" - qual é a expectativa usual do Gerenciador de Pacotes? Dizemos: "Gerenciador de Pacotes - entregue o pacote!" e espere que ele nos diga: "O pacote foi entregue".

É interessante dizermos: "Helm, coloque o pacote" e, quando ele responde que o instalou, acontece que ele acabou de iniciar a instalação - Kubernetes apontou: "Execute essa coisa!", Mas foi iniciado ou não, funciona ou não Helm não resolve esse problema.

Acontece que o Helm é apenas um pré-processador de texto que carrega dados no Kubernetes.

Mas queremos saber na estrutura de qualquer implantação - o aplicativo foi lançado para produzir ou não? O lançamento do produto significa que o aplicativo foi para lá, uma nova versão foi implantada e, pelo menos, não travou e responde corretamente. Helm não resolve esse problema. Para resolvê-lo, você precisa gastar muita energia, porque precisa dar ao Kubernetes o comando para implantar e monitorar o que acontece lá - se ele virou, se saiu. E também há várias tarefas relacionadas à implantação, limpeza e montagem.

Planos

Este ano iremos para o desenvolvimento local. Queremos chegar ao que costumava ser no Vagrant - digitamos "vagrant up" e implantamos máquinas virtuais. Queremos chegar a um estado em que exista um projeto no Git, escrevemos "werf up" lá e gera uma cópia local desse projeto, implantada em um mini-Kub local, com todos os diretórios convenientes para o desenvolvimento. Dependendo da linguagem de desenvolvimento, isso é feito de maneiras diferentes, mas, no entanto, para que seja conveniente realizar o desenvolvimento local nos arquivos montados.

O próximo passo para nós é investir pesadamente na conveniência dos desenvolvedores . Para implantar rapidamente um projeto localmente, com uma ferramenta, para concluir, envie para o Git, e ele também será implementado no estágio ou nos testes, dependendo dos pipelines, e depois será direcionado ao produto com a mesma ferramenta. Essa unidade, unificação, reprodutibilidade da infraestrutura do ambiente local até a venda é um momento muito importante para nós. Mas isso ainda não está no werf - apenas planejando fazê-lo.

Mas o caminho para dapp / werf sempre foi o mesmo que com o Kubernetes no começo. Tivemos problemas, resolvemos-os com soluções alternativas - criamos algum tipo de solução para nós mesmos no shell, em qualquer coisa. Em seguida, essas soluções alternativas tentaram, de alguma forma, endireitar, generalizar e consolidar em binários nesse caso, que simplesmente compartilhamos.

Há outra visão de toda essa história, com analogias.

Kubernetes é uma estrutura de carro com um motor. Não há portas, janelas, rádio, árvores de Natal - nada. Somente o quadro e o motor. E há Helm - este é o volante. Legal - existe um volante, mas ainda precisa de um pino de direção, rack de direção, caixa de velocidades e rodas, mas sem eles nada.

No caso do werf, esse é outro componente do Kubernetes. Somente agora em nossa versão alfa do werf, por exemplo, Helm compila completamente o werf, porque estamos cansados ​​de fazer isso sozinhos. Existem muitas razões para fazer isso, em detalhes sobre por que compilamos o leme como um todo junto com o leme dentro do werf, vou contar apenas no relatório sobre o RIT ++ .

Agora o werf é um componente mais integrado. Temos um volante pronto, um pino de direção - eu não sou muito bom em carros, mas este é um bloco grande que já resolve uma gama bastante ampla de tarefas. Não precisamos escalar o catálogo, escolher uma parte da outra, pensar em como prendê-los um ao outro. Temos uma combinação pronta que resolve imediatamente um grande conjunto de tarefas. Mas, por dentro, é composto pelos mesmos componentes de código aberto, também usa o Docker para montagem, o Helm como parte da funcionalidade e há várias outras bibliotecas. Esta é uma ferramenta integrada para obter CI / CD rápido e conveniente de imediato.

O Kubernetes é difícil de manter?

- Você fala sobre a experiência que começou a usar o Kubernetes, este é um quadro, um motor para você, e você pode pendurar muitas coisas diferentes: corpo, volante, apertar pedais, assentos. A questão é: qual é a dificuldade do suporte do Kubernetes para você? Você tem uma experiência rica, quanto tempo e recursos são necessários para dar suporte ao Kubernetes separadamente de todo o resto?

Dmitry : Esta é uma pergunta muito difícil e, para responder, você precisa entender o que é o suporte e o que queremos do Kubernetes. Talvez você revele?

- Até onde eu sei e o que vejo, agora muitas equipes querem experimentar o Kubernetes. Todo mundo aproveitou para ele, colocou em seu joelho. Sinto que as pessoas nem sempre entendem a complexidade desse sistema.

Dmitry : É isso.

- Quão difícil é levar e entregar o Kubernetes sem nada para torná-lo pronto para a produção?

Dmitry : Você acha que é difícil transplantar um coração? Eu entendo, a pergunta é comprometedora. Carregar um bisturi e não cometer erros não é tão difícil. Se lhe for dito onde cortar e onde costurar, o procedimento em si é simples. É difícil garantir de tempos em tempos que tudo vai dar certo.

Coloque o Kubernetes e faça o trabalho simples: garota! - entregue, existem vários métodos de instalação. Mas o que acontece quando surgem problemas?

Sempre surgem perguntas - o que ainda não levamos em consideração? O que ainda não fizemos? Quais parâmetros do kernel do Linux você especificou incorretamente? Senhor, nós os apontamos ?! Quais componentes do Kubernetes entregamos e quais não são? Milhares de perguntas surgem e, para respondê-las, você precisa cozinhar por 15 a 20 anos neste setor.

Eu tenho um novo exemplo sobre esse tópico que pode revelar o significado do problema “É difícil manter o Kubernetes?”. Há algum tempo, consideramos seriamente se deveríamos tentar implementar o Cilium como uma rede no Kubernetes.

Deixe-me explicar o que é Cilium. O Kubernetes tem muitas implementações diferentes do subsistema de rede, e uma delas é muito legal - é o Cilium. Qual é o seu significado? No kernel, há algum tempo, tornou-se possível escrever ganchos para o kernel que de alguma forma invadem o subsistema de rede e vários outros subsistemas e permitem que você ignore grandes pedaços no kernel.

Historicamente, o kernel do Linux possui roteamento de ip, um super filtro, pontes e muitos componentes antigos com 15, 20, 30 anos. Em geral, eles funcionam, tudo é legal, mas agora eles fizeram um contêiner de contêineres, e parece uma torre de 15 tijolos um em cima do outro, e você fica de pé em uma perna - uma sensação estranha. Esse sistema se desenvolveu historicamente com muitas nuances, como um apêndice no corpo. Em algumas situações, há problemas com o desempenho, por exemplo.

Há um BPF maravilhoso e a capacidade de escrever ganchos para o kernel - os caras escreveram seus ganchos para o kernel. O pacote vem para o kernel do Linux, ele é retirado na entrada, processado sem pontes, sem TCP, sem a pilha de IP - em suma, ignorando tudo o que está escrito no kernel do Linux e cuspindo imediatamente no contêiner.

O que aconteceu? Desempenho muito legal, recursos legais - ótimo! Mas analisamos isso e vemos que em cada máquina há um programa que se conecta à API do Kubernetes e, de acordo com os dados recebidos dessa API, gera código C e compila os binários que ele carrega no kernel para que esses ganchos funcionem no espaço do kernel .

O que acontece se algo der errado? Nós não sabemos. Para entender isso, você precisa ler todo esse código, entender toda a lógica e isso é atordoante, quão difícil é. Mas, por outro lado, existem pontes, filtros de rede, roteamento de IP - eu não li suas fontes e 40 engenheiros que também trabalham em nossa empresa. Talvez algumas peças entendam unidades.

E qual a diferença? Acontece que há roteamento de ip, o kernel do Linux e há uma nova ferramenta - qual é a diferença, não entendemos nem um nem outro. Mas temos medo de usar o novo - por quê? Porque se a ferramenta tiver 30 anos, mais de 30 anos foram encontrados todos os bugs, todos os ancinhos vieram e você não precisa saber tudo - ela funciona como uma caixa preta e sempre funciona. Todo mundo sabe qual chave de fenda de diagnóstico deve ficar em qual lugar, qual tcpdump em que ponto iniciar. Todo mundo conhece bem os utilitários de diagnóstico e entende como esse conjunto de componentes funciona no kernel do Linux - não como ele funciona, mas como usá-lo.

E incrivelmente legal Cilium não tem 30 anos, ainda não está maduro. Com o Kubernetes, o mesmo problema, copie. Que Cilium está definido perfeitamente, que Kubernetes está definido perfeitamente, mas quando algo dá errado no prod, você é capaz de entender rapidamente o que deu errado em uma situação crítica?

Quando dizemos que é difícil manter o Kubernetes, não, é muito simples e, sim, é incrivelmente difícil. Kubernetes , .

« »

— , ? , Kubernetes, - .

: , , . , Kubernetes, . , ? , , , . , — , . Kubernetes.

Ubuntu 16.04. , , , LTS. systemd, , C-. Kubernetes , C-, , - — , , — systemd. , . highload. , , Cron Job, , Ubuntu 16.04 . load average - , C-. , , Ubuntu 16 Kubernetes.

, - systemd - , Linux 4.16 — C- . . , , 15 , C-, , — .

. , - — , . — Kubernetes, — . . , - - , , , . , Kubernetes — ?

, , , . , .

, , , , . .

IT, , « ». , , . , . .

— : , , «», , Red Hat, , Kubernetes, .

: . Kubernetes — .

?

— , Kubernetes ?

: , , -. : «Kubernetes, Kubernetes», . , , , 70% Kubernetes. .

— ? «» , Kubernetes — -.

, Kubernetes .

game-changer . — , Ansible, Chef, , Terraform. . Kubernetes — changer , .

, - , - , . , , Kubernetes : , infrastructure as code , , yml — . , .

— , Kubernetes, . ?

: . , dns-, FreeBSD 4.10 20 . . , 20 - . , - , , , , Kubernetes. .

, CI/CD — , Continuous Delivery, , , , — Kubernetes.

— . Kubernetes, — . — - , , , Kubernetes , . — Kubernetes - , Kubernetes?

: . «: ». , . , . , , . «». , , - , — , , . Isto não é verdade.

, , 300 , , , , , - — 10, 30 . , . , 3 60 , .

, — . , . , , .

, , , , Kubernetes , , , , , , Kubernetes, . — , , , . . — , , — .

— , Kubernetes , , , . . — , , , 10 — , . . , .

Kubernetes . : Kubernetes, , 4-5 , — . , . O que é isso Ubuntu Curios? Linux, . , . Kubernetes , , , , .

, , — «», 150 DevOps easy service. — . , DevOps, , . , . , , . , . , Kubernetes.

, 10 , . .

Amazon Google

— Amazon Google?

: , , . . , . , Amazon AWS: Load Balancer , «, , Load Balancer!» .

, , . 40 , , , 60 — . - , , .

, — , hosted- - . , , . Amazon Google . — . . clouds, , — Ager, , , OpenStack : Headster, Overage — , . , .

, — , , , hosted- .

Kubernetes?

— - Kubernetes? Kubernetes, «», Kubernetes?

: , Kubernetes : «, , Kubernetes, !». : «, Kubernetes, , ». , CI/CD , . , , .

, , , — ! — Kubernetes . . , , — Kubernetes , ! — ! — , ! — 100% uptime, 50 , . , !

, : «, ». , . , . CI/CD, . , .

, Kubernetes — Kubernetes .

, Kubernetes. , , , . , . Kubernetes — , , « », « », - .

. : , , — . . , , , , . , .

, - Kubernetes — .

Kubernetes , , , . — . - , — . - , , , , . . , DevOps , - , - . - .

. : «, !» — , : « , ». . , , - , , .

: Kubernetes. .

, :

• ;
  
• , , - ;
  
• , , , .
  

: / . , - IT-, , - — soft for easing the world, , . Kubernetes , .

Sobre sem servidor

- Se você olhar um pouco mais para o futuro, tentando resolver o problema da ausência de dor de cabeça com a infraestrutura, com a velocidade de lançamento e a velocidade da alteração de aplicativos, novas soluções aparecerão, por exemplo, sem servidor. Você sente algum potencial nessa direção e, digamos assim, um perigo para o Kubernetes e soluções semelhantes?

Dmitry : Aqui precisamos fazer uma observação novamente, de que não sou um visionário que olha para o futuro e diz - será assim! Embora eu tenha feito o mesmo. Olho para os meus pés e vejo um monte de problemas, por exemplo, como os transistores funcionam em um computador. Engraçado, né? Encontramos alguns erros na CPU.

Tornar sem servidor confiável o suficiente, barato, eficiente e conveniente, resolvendo todos os problemas do ecossistema. Então eu concordo com Elon Mask que precisamos de um segundo planeta para tolerar falhas na humanidade. Embora eu não saiba o que ele está dizendo, entendo que não estou pronto para voar para Marte e não será amanhã.

Com o servidor, fica claro que isso é ideologicamente correto, como tolerância a falhas para a humanidade - dois planetas são melhores que um. Mas como fazer isso agora? Enviar uma expedição não é um problema se nos concentrarmos nesse esforço. Enviar várias expedições e povoar milhares de pessoas por lá também é realista. Mas é completamente para tornar tolerância a falhas que metade da humanidade mora lá, parece-me agora impossível, não considerado.

Com um a um sem servidor: a coisa é legal, mas está longe dos problemas de 2019. Mais perto de 2030 - vamos viver para vê-lo. Não tenho dúvidas de que sobreviveremos, certamente sobreviveremos (repita antes de dormir), mas agora precisamos resolver outros problemas. É como acreditar em um fabuloso pônei Rainbow. Sim, alguns por cento dos casos são resolvidos e resolvidos perfeitamente, mas subjetivamente sem servidor é um arco-íris ... Para mim, esse tópico é muito longe e incompreensível. Eu não estou pronto para conversar. Em 2019, sem servidor, você não escreverá um único aplicativo.

Como o Kubernetes se desenvolverá

"À medida que avançamos em direção a esse futuro potencialmente bonito e distante, o que você acha que desenvolverá o Kubernetes e o ecossistema ao seu redor?"

Dmitry : Pensei muito sobre isso e tenho uma resposta clara. O primeiro é statefull - ainda sem estado é mais fácil de fazer. Kubernetes inicialmente investiu mais nele, tudo começou com ele. O Stateless funciona quase perfeitamente no Kubernetes, não há o que reclamar. Por estado, ainda existem muitos problemas, ou melhor, nuances. Tudo já funciona bem para nós lá, mas estamos. Para que isso funcione para todos, você precisa de pelo menos mais alguns anos. Este não é um indicador calculado, mas meu sentimento da cabeça.

Em suma, o statefull precisa - e vai - se desenvolver muito, porque todos os nossos aplicativos têm status, não há aplicativos sem estado. Isso é uma ilusão, você sempre precisa de algum tipo de banco de dados e algo mais. Statefull é a retificação de tudo que é possível, a correção de todos os erros, a melhoria de todos os problemas que estão enfrentando atualmente - vamos chamá-lo de adoção.

O nível do desconhecido, o nível de problemas não resolvidos, o nível de probabilidade de encontrar algo cairá drasticamente. Esta é uma história importante. E os operadores - tudo relacionado à codificação da lógica de administração, lógica de controle, para obter um serviço fácil: serviço fácil MySQL, serviço fácil RabbitMQ, serviço fácil Memcache - em geral, todos esses componentes que precisamos garantir que funcionem imediatamente. Isso apenas resolve a dor que queremos em um banco de dados, mas não queremos administrá-lo, ou queremos o Kubernetes, mas não queremos administrá-lo.

Essa história com o desenvolvimento de operadores de uma forma ou de outra será importante nos próximos dois anos.

Acho que a facilidade de uso deve aumentar bastante - a caixa ficará cada vez mais preta, mais e mais confiável, com voltas cada vez mais simples.

Certa vez, ouvi a antiga entrevista dos anos 80 de Isaac Asimov no YouTube no Saturday Night Live, um programa parecido com o urgente que é interessante. Ele foi questionado sobre o futuro dos computadores. Ele disse que o futuro é simples, como foi o caso do rádio. O rádio era originalmente uma coisa complicada. Para capturar a onda, foram necessários 15 minutos para girar os giros, girar os espetos e geralmente saber como tudo funciona, para entender a física da transmissão de ondas de rádio. Como resultado, uma torção permaneceu no rádio.

Agora em 2019, qual rádio? No carro, o rádio encontra todas as ondas, o nome das estações. A física do processo não mudou em 100 anos, a facilidade de uso mudou. Agora, e não só agora, já em 1980, quando houve uma entrevista com Azimov, todos usaram o rádio e ninguém pensou em como o arranjo era. Sempre funcionou - é um dado.

Azimov disse então que seria semelhante com os computadores - a facilidade de uso aumentaria . Se em 1980 você precisar obter uma educação especial para pressionar os botões no computador, no futuro isso não será o caso.

Tenho a sensação de que, com o Kubernetes e com a infraestrutura, a facilidade de uso também aumentará drasticamente. Isso, na minha opinião, é óbvio - está na superfície.

O que fazer com os engenheiros?

- E então o que acontecerá com os engenheiros, administradores de sistemas que suportam o Kubernetes?

Dmitry : E o que aconteceu com o contador após o aparecimento de 1C? Sobre o mesmo. Antes disso, eles pensaram em um pedaço de papel - agora no programa. A produtividade do trabalho aumentou em ordens de magnitude, e o próprio trabalho não desapareceu disso. Anteriormente, 10 engenheiros precisavam aparafusar a lâmpada, mas agora uma será suficiente.

Parece-me que o número de software e o número de tarefas estão crescendo a uma velocidade maior que os novos DevOps e a eficiência está aumentando. Há uma escassez específica no mercado e vai durar muito tempo. Posteriormente, tudo entrará em uma determinada norma, na qual a eficiência do trabalho aumentará, ficará mais sem servidor, eles anexarão um neurônio ao Kubernetes, que selecionará todos os recursos da maneira que deveria e, em geral, fará tudo como deve - a pessoa se afasta e não se incomoda.

Mas de qualquer maneira, alguém terá que tomar decisões. É claro que o nível de qualificação e especialização dessa pessoa é maior. Agora, no departamento de contabilidade, você não precisa de 10 funcionários que guardam livros para que suas mãos não se cansem. Isso simplesmente não é necessário. Muitos documentos são digitalizados e reconhecidos automaticamente pelo sistema de gerenciamento eletrônico de documentos. Um contador-chefe inteligente é suficiente, já com habilidades muito maiores, com um bom entendimento.

Em geral, esse caminho em todos os setores. É o mesmo com os carros: antes, um mecânico de automóveis e três motoristas estavam ligados ao carro. Agora, dirigir um carro é o processo mais simples do qual todos participamos todos os dias. Ninguém pensa que um carro é algo complicado.

O DevOps ou a engenharia de sistemas não irão a lugar algum - a eficiência operacional e de alto nível aumentará.

- Também ouvi uma ideia interessante de que o trabalho aumentará.

Dmitry : Claro, cem por cento! Porque a quantidade de software que escrevemos está em constante crescimento. O número de problemas que resolvemos com o software está em constante crescimento. A quantidade de trabalho está crescendo. Agora o mercado de DevOps está terrivelmente superaquecido. Isso é evidente a partir das expectativas salariais. De uma maneira boa, sem entrar em detalhes, deve haver juniores que querem X, intermediários que querem 1,5X e idosos que querem 2X. E agora, se você olhar para o mercado salarial de Moscou DevOps, o júnior quer de X a 3X e o sênior quer de X a 3X.

Ninguém sabe quanto custa. Seu nível salarial é medido por sua confiança - um hospício completo, para ser honesto, um mercado extremamente superaquecido.

Obviamente, essa situação mudará muito em breve - alguma saturação deve ocorrer. Com o desenvolvimento de software, esse não é o caso - apesar de todo mundo precisar de desenvolvedores e todo mundo precisa de bons desenvolvedores, o mercado entende quanto custa - a indústria se acalmou. Este não é o caso do DevOps.

- Pelo que ouvi, concluí que o atual administrador do sistema não deveria estar muito preocupado, mas é hora de baixar habilidades e se preparar para o fato de que amanhã haverá mais trabalho, mas será mais qualificado.

Dmitry : Absolutamente. Em geral, vivemos em 2019 e a regra da vida é a seguinte: aprendizado ao longo da vida - aprendemos toda a nossa vida . Parece-me que agora todos sabem e sentem, mas é necessário conhecer um pouco. Todos os dias temos que mudar. Se não o fizermos, mais cedo ou mais tarde seremos deixados à margem da profissão.

Prepare-se para curvas acentuadas de 180 graus. Não excluo uma situação em que algo muda drasticamente, eles surgem com algo novo - acontece. Hop! - e agora agimos de forma diferente. É importante estar preparado para isso e não vapor. Pode acontecer que amanhã tudo o que eu faça seja desnecessário - nada, estudei toda a minha vida e estou pronto para aprender outra coisa. Isto não é um problema. Você não deve ter medo da segurança no emprego, mas precisa estar preparado para aprender constantemente algo novo.

Desejos e um minuto de publicidade

- Você tem algum desejo?

Dmitry : Sim, tenho alguns desejos.

O primeiro e comercial - assine o YouTube . Caros leitores, acesse o YouTube e assine o nosso canal. Em cerca de um mês, iniciaremos uma expansão ativa no serviço de vídeo. Teremos um monte de conteúdo educacional sobre o Kubernetes, aberto e diferente: desde assuntos práticos até laboratórios, assuntos teóricos fundamentais e como aplicar o Kubernetes no nível de princípios e padrões.

O segundo desejo mercantil - vá ao GitHub e coloque estrelas, porque nós as comemos. Se você não nos der estrelas, não teremos nada para comer. É como mana em um jogo de computador. Estamos fazendo algo, fazendo, tentando, alguém diz que estas são bicicletas terríveis, alguém que geralmente está errado, e continuamos e agimos de maneira absolutamente honesta. Vemos o problema, resolvemos e compartilhamos nossa experiência. Portanto, dê-nos um asterisco, que não diminuirá de você, mas chegará até nós, porque nós os comemos.

O terceiro desejo, importante e não mais mercantil - deixa de acreditar em contos de fadas . Vocês são profissionais. O DevOps é uma profissão muito séria e responsável. Pare de brincar no local de trabalho. Deixe você clicar e você entenderá. Imagine que você irá ao hospital e lá o médico fará experiências com você. Entendo que isso possa ser ofensivo para alguém, mas provavelmente não é sobre você, mas sobre outra pessoa. Diga para os outros pararem também. Realmente estraga a vida de todos nós - muitos começam a se relacionar com a exploração, com administradores e DevOps, como com caras que novamente quebraram algo. Isso foi “quebrado” na maioria das vezes devido ao fato de termos ido jogar e não parecia com uma consciência fria que era assim, mas dessa maneira.

Isso não significa que você não precisa experimentar. Precisamos experimentar, fazemos nós mesmos. Para ser honesto, nós também tocamos algumas vezes - isso, é claro, é muito ruim, mas nada humano é estranho para nós. Vamos declarar 2019 o ano de experimentos sérios, não jogos no prod. Provavelmente sim.

- Muito obrigado!

Dmitry : Obrigado, Vitaly, pelo tempo e pela entrevista. Caros leitores, muito obrigado se de repente você chegou a esse ponto. Espero que pelo menos alguns pensamentos tenham lhe trazido.

Em uma entrevista, Dmitry tocou no werf. Agora é uma faca suíça universal que resolve quase todas as tarefas. Mas esse nem sempre foi o caso. No DevOpsConf no festival RIT ++ , Dmitry Stolyarov falará sobre essa ferramenta em detalhes. O relatório “werf é nossa ferramenta para CI / CD no Kubernetes” terá tudo: problemas e nuances ocultas do Kubernetes, soluções para essas dificuldades e a atual implementação do werf em detalhes. Entre nos dias 27 e 28 de maio, criaremos as ferramentas ideais.