👨‍✈️ ⬜️ 🏠 "Docker já está morto" ou o que quer que você quisesse saber sobre Devops, mas estava com medo de perguntar 🕋 ✍🏼 🔭

Recentemente, Alexander Chistyakov, DevOps com 7 anos de experiência e cofundador da Comunidade de Engenheiros DevOps de São Petersburgo, falou em nossas redes sociais.

Sasha é um dos principais palestrantes nesta área, ele se apresentou nos palcos principais em Highload ++, RIT ++, PiterPy, Strike, fazendo pelo menos 100 reportagens no total. Na segunda-feira passada, ele respondeu às perguntas dos telespectadores e falou sobre sua experiência.

Compartilhamos a gravação e a transcrição da transmissão.

Meu nome é Alexander Chistyakov, trabalho como engenheiro de DevOps há muitos anos. Tenho aconselhado várias empresas por muito tempo na implementação de práticas DevOps, usando ferramentas DevOps modernas e organizando infraestruturas para que todos possamos dormir bem à noite e as pessoas continuem a receber dinheiro por seus produtos e serviços.

Basicamente, consultei empresas estrangeiras.

Falaremos sobre como as pessoas usam o Kubernetes na prática diária, por que ele é necessário, por que você não deve ter medo dele, no que você deve prestar atenção e o que vai acontecer a seguir.

Acho que administradores de sistemas, engenheiros de DevOps, CIOs e outros gerentes de infraestrutura (e apoiadores) acharão isso útil.

Como essa paisagem se desenvolveu? Lembro-me de computadores com ROM Basic instalado e era possível escrever programas sem um SO instalado. Muita água correu por baixo da ponte desde então. No início, não existia nenhum sistema operacional (mais precisamente, eles foram escritos em linguagem assembly). Então a linguagem C apareceu e a situação melhorou dramaticamente. Claro, agora estamos todos familiarizados com o conceito de sistema operacional: é uma plataforma que nos permite executar aplicativos personalizados e gerenciar os recursos que temos neste computador. Ou outros, se for distribuído. Mesmo assim, foi possível montar um cluster de computação de alto desempenho a partir do seu laptop e desktop - foi isso que os alunos fizeram no dormitório do Instituto Politécnico de São Petersburgo em 1997.

Então descobri - provavelmente li este artigo há cerca de 10 anos - que o Google, que inventou o webmail, está construindo um sistema operacional em torno desse mesmo webmail para que os usuários possam usá-lo em tablets e telefones. Isso foi inesperado, geralmente o sistema operacional é algo que executa os binários, e quando você olha o aplicativo pelo navegador, nem sabe se o binário está lá. Você pode ler e-mails, bater papo em um mensageiro online, desenhar slides e editar documentos juntos. Descobriu-se que isso serve para muitos.

É verdade que o Google não era muito consistente e fazia muitos produtos que não eram necessários e não iam além do protótipo - por exemplo, o Google Wave. Bem, esta é a política de qualquer grande empresa - mover-se rapidamente, quebrar frequentemente, até que a empresa deixe de existir.

No entanto, na consciência de massa, houve uma mudança em direção à ideia do sistema operacional como uma plataforma que não fornece os serviços que uma vez foram aprovados por algum comitê de definição de padrões e foram designados para ele, mas simplesmente satisfaz as necessidades dos usuários. Quais são essas necessidades?

Costumava ser comum perguntar ao desenvolvedor no que ele escrevia. Havia especialistas em C ++ (provavelmente, e agora existem em algum lugar), agora existem muitos especialistas em PHP (eles riem de si mesmos, às vezes) e muitos desenvolvedores de JavaScript. Texto datilografado, a linguagem GoLang para a qual as pessoas com conhecimento de PHP mudaram, agora está ganhando popularidade. Havia a linguagem Perl (provavelmente ainda existe, mas perdeu muito em popularidade), a linguagem Ruby. Em geral, um aplicativo pode ser escrito em qualquer coisa. Se você mora no mundo real, provavelmente já se deparou com o fato de que eles estão escritos em qualquer coisa: Javascript, Rust, C; invente um nome - algo foi escrito nele.

E tudo isso deve ser explorado. Descobriu-se que em um sistema tão heterogêneo, em primeiro lugar, são necessários especialistas para desenvolver em diferentes linguagens e, em segundo lugar, é necessária uma plataforma que permita lançar um serviço em um ambiente agradável e monitorar seu ciclo de vida. Existe um certo contrato com essa plataforma, que no mundo moderno se parece com isto: você tem uma imagem de contêiner (o sistema de gerenciamento de contêiner agora está em toda parte - Docker, embora eu não possa dizer nada de bom sobre isso; falaremos sobre os problemas mais tarde).

Apesar de a humanidade estar se movendo por um certo processo evolutivo, esse processo tem convergência. Em nossa indústria, acontece que alguém ainda está escrevendo código em Perl (no mod_perl Apache) e alguém já está escrevendo uma arquitetura de microsserviço em GoLang. Acontece que o contrato com a plataforma é muito importante, o conteúdo da plataforma é muito importante e é muito importante que a plataforma ajude uma pessoa. Torna-se muito caro fazer operações manuais para finalizar e iniciar o serviço. Tive que lidar com projetos onde havia 20 serviços - e não era um projeto muito grande; Já ouvi falar de caras que têm mil serviços diferentes. 20 é um valor normal; e cada conjunto de serviços é desenvolvido por sua própria equipe em seu próprio idioma, eles são conectados apenas pelo protocolo de troca.

Com relação a como funciona o contrato do aplicativo. Existe um "manifesto de aplicação de 12 fatores" - 12 regras para como uma aplicação deve ser organizada para ser conveniente de usar. Eu não gosto dele. Em particular, ele diz que você precisa fornecer configurações por meio de variáveis de ambiente; e eu descobri repetidamente o fato de que na Amazon, por exemplo, o número de variáveis de ambiente que podem ser passadas para o Elastic Beanstalk é uma página do kernel Linux - 4 kilobytes. E eles transbordam muito rapidamente; quando você tem 80 variáveis diferentes, 81 é difícil de seguir. Além disso, é um espaço de configuração plano - quando existem variáveis, elas devem ser nomeadas em maiúsculas com sublinhado, não havendo hierarquia entre elas; é difícil entender o que está acontecendo. Ainda não descobri como lidar com isso, e não tenho ninguém com quem discutir - não há grupo de entusiastas,quem seria contra tal abordagem. Se isso de repente não servir para ninguém - escreva para mim (demeliorator em Telegram), eu saberei que não estou sozinho. Eu absolutamente não gosto disso. É difícil de gerenciar, difícil de transferir dados hierárquicos; Acontece que o trabalho de um engenheiro moderno é saber onde estão as variáveis, o que significam, se estão definidas corretamente, como é fácil alterá-las. Acho que as boas e velhas regras de configuração eram melhores.se eles estão configurados corretamente, como é fácil alterá-los. Parece-me que as boas e velhas regras de configuração eram melhores.se estão configurados corretamente, como é fácil alterá-los. Acho que as boas e velhas regras de configuração eram melhores.

Voltando ao contrato. Acontece que você precisa de uma imagem do Docker: você precisará do próprio Docker (apesar do fato de ser pobre - espero que alguns Microsoft comprem e enterrem ou desenvolvam normalmente). Se você não estiver satisfeito com o Docker, experimente o Red Hat's Stack; Não posso dizer nada sobre isso, embora me pareça que deveria ser melhor do que apenas Kubernetes vanilla. Os caras da Red Hat prestam muito mais atenção às questões de segurança, eles até sabem fazer instalações multi-turn, multiusuário, multi-cliente, com separação normal de direitos - em geral, eles garantem que o gerenciamento de direitos esteja em vigor.

Vamos nos concentrar nas questões de segurança. É ruim com ela em todos os lugares, não apenas no Kubernetes. Se falamos de segurança e orquestração de contêineres, tenho grandes esperanças para o web assembly, que é feito no lado do servidor, e para aplicativos de web assembly será possível limitar o consumo de recursos, as chamadas de sistema podem ser amarradas em contêineres especiais, em Rust. Esta seria uma boa resposta à pergunta de segurança. E o Kubernetes não tem segurança.

Digamos que temos um aplicativo. É uma imagem Docker, tem 12 fatores - ou seja, pode obter sua configuração de variáveis de ambiente, de um arquivo que você monta dentro do contêiner. Pode ser iniciado - dentro dele é autossuficiente, você pode tentar vinculá-lo a outros aplicativos através de configurações, automaticamente. E deve gravar logs na saída padrão - o que é provavelmente o menos prejudicial; quando o contêiner grava logs em arquivos, não é muito fácil coletar a partir daí. Até mesmo o Nginx foi corrigido para que você possa coletar logs da saída padrão do contêiner, isso é aceitável (em vez de passar a configuração por meio de um parâmetro). Na verdade, tínhamos vários orquestradores: Rancher, Marathon Mesos, Nomad; mas, como diz o princípio de Anna Karenina em relação aos sistemas técnicos,sistemas técnicos complexos são organizados da mesma maneira.

Com o Kubernetes, temos a mesma situação das companhias aéreas com o Boeing 737 MAX - ele não voa porque tem um erro, mas não há mais nada, porque o design é muito complexo. Não posso dizer que gosto - como a linguagem GoLang, e controle por meio do formato YAML, quando você tem alguma sintaxe e não há nada além disso - nenhuma verificação sobre o que você escreve, nenhum tipo de dados. Todas as verificações que você faz antes de aplicar as configurações no Kubernetes são rudimentos. Você pode tentar aplicar a configuração errada e ela se aplicará sem questionar e você não sabe o quê. É muito fácil escrever o arquivo de configuração errado. Este é um grande problema, e as pessoas já começaram a resolvê-lo aos poucos usando DSL e Kubernetes em linguagens Kotlin, até mesmo o Typescript. Existe um projeto Pulumi,há um projeto EKS da Amazon - embora seja mais focado na Amazon; Pulumi é um Terraform, apenas em Datilografado. Eu gostaria de ter experimentado Pulumi ainda porque acredito que é o futuro. A configuração deve ser descrita em uma linguagem de programação com forte tipagem estática, de forma que antes de ser aplicada, o que pode potencialmente destruir o cluster, você seria pelo menos informado em tempo de compilação que isso não é possível.

Portanto, no momento existe apenas um orquestrador. Eu sei que ainda há alguns usuários MATA, eu aperto sua mão; Espero que ninguém mais use o Docker Swarm - minha experiência com ele foi bastante negativa. Acredito que poderia ser diferente, mas não sei por quê; Não prevejo nenhum desenvolvimento posterior do Docker Swarm, e não acho que as pessoas que o lançarão farão algo com ele agora. Capitalismo; Se você não ganhar dinheiro, não há nada para gastar em desenvolvimento - e a empresa deles está no "vale da morte" para startups nos últimos dois anos: ninguém quer dar dinheiro a eles. Você pode dar lances para quem vai comprá-los. A Microsoft não estava interessada. Talvez algum Microfocus funcione se o Docker sobreviver.

Como só resta um Kubernetes, vamos conversar sobre isso. Há uma bela imagem com um pentagrama de cinco de seus binários; está escrito que o Kubernetes é muito simples, apenas cinco binários. Mas estou longe de medir a complexidade de um sistema pelo número de binários nos quais ele é compilado e pelo número de serviços que constituem o núcleo do sistema. Não importa quantos binários haja - o que importa é o que o Kubernetes pode fazer e como funciona internamente.

O que ele pode fazer? Imagine que você precise explicar a uma criança de cinco anos o que você fez no trabalho. E então o pai, que tentou escrever cartilhas e papéis no Ansible que lhe permitiriam fazer implantação azul-verde com base no Nginx em um host e um conjunto de contêineres que não estão registrados com nada além de tv-ansible, disse: “Sabe, filho, eu tentei de tudo é hora de fazer seu próprio Kubernetes. Não funciona bem, está mal testado, não entendo bem, não conheço todas as condições de contorno, funciona na mesma máquina, mas é minha! " Eu já vi isso injustificadamente muitas vezes - apenas assisti 2 ou 3 vezes, e 2 vezes participei escrevendo algo assim. Mais cedo ou mais tarde, quem participa disso percebe que não deve haver uma 4ª vez. É como meus amigos de carroquem uma vez restaurou o VAZ-2101 - instalou vidros elétricos, reparou o interior com rebanho, pintou em metálico. Criar seu próprio orquestrador é algo assim. Você pode tentar uma vez para ter certeza de que pode, mas não estou pronto para recomendá-lo a todos - não apenas aos entusiastas. Portanto, o gerenciamento do ciclo de vida, o gerenciamento do estado do contêiner é tarefa do Kubernetes.

Ele pode ter certeza de que o contêiner está sendo executado no nó onde há recursos, pode reiniciar um contêiner inativo, pode garantir que, se o contêiner não iniciar, o tráfego não irá para ele se houver uma nova implantação. Também começamos dizendo que o Kubernetes é o SO; onde o sistema operacional está, deve haver um gerenciador de pacotes. Quando o Kubernetes começou, as descrições dos objetos eram imperativas; conjunto com informações de estado e descrição de código são descrições que funcionam diretamente e você precisa adicionar algo na parte superior para tornar o estado de seu [??? 18:52 - falha de gravação]. Na verdade, a diferença radical do Ansible e de outros sistemas de gerenciamento de configuração semelhantes é que no Kubernetes você descreve o que deve acontecer, não como deve ser. Você naturalmente descrevequais objetos você possui e quais propriedades eles possuem. Os objetos são serviço, implantação, daemonset, statefulset. É interessante que, além daqueles objetos que podem ser criados de forma padrão, também existem objetos personalizados que podem ser descritos e criados no Kubernetes. É muito útil; também diminuirá bastante as fileiras de administradores de sistemas e engenheiros de desenvolvimento.

Quando o Kubernetes morrerá?

Boa pergunta. Depende do que se entende pela palavra "morrer". Aqui está Docker - há um ano nos reunimos em uma conferência em São Petersburgo, houve uma mesa redonda e decidimos juntos (bem, já que somos uma indústria, acho que havia uma maioria qualificada lá e poderíamos muito bem falar por todos) que Docker já morreu. Por quê? Porque na conferência não houve palestras sobre Docker, embora não tenha tantos anos. Ninguém disse nada sobre ele. Falamos sobre o Kubernetes, sobre as próximas etapas - Kube Flow, por exemplo, sobre o uso de operadores, sobre como colocar bases do Kubernetes. Qualquer coisa, menos Docker. Isso é morte - quando você é tão mau que parece estar vivo, mas ninguém vem até você.

Docker já está morto. Quando Kubernetes morrer - vamos esperar 5 anos. Ele não vai morrer, todos o terão - ele estará dentro do Tesla, dentro do seu telefone, em todos os lugares, e ninguém terá interesse em falar sobre ele. Eu acho que isso é a morte. Talvez nem em 5 anos, mas em 3. Outra questão é o que irá substituí-la: alguma nova tecnologia barulhenta sobre a qual todos vão falar, talvez nem seja do mundo DevOps. Agora eles falam sobre o Kubernetes apenas para manter a conversa, e tudo bem - está na moda.

O que há de errado com o Docker?

Tudo. Este é um binar único para gerenciar tudo, este é um serviço que deve ser lançado no sistema, esta é uma peça que é controlada via socket também. Este é um produto que tem muito código que não foi revisado por ninguém, como eu acho. Este é um produto para o qual, em geral, não há dinheiro da empresa. A Red Hat tem pessoas muito inteligentes, eu tenho muito respeito por eles, e se você é um engenheiro médio, deveria olhar o que eles estão fazendo porque isso pode definir o cenário nos próximos 5 anos. Bem, a Red Hat abandonou completamente o Docker. Eles estão caminhando para não tê-lo. Até agora, eles não podem fazer isso até o fim, mas estão próximos e, mais cedo ou mais tarde, concluirão o Docker. Ele, além de tudo que listei, tem uma grande área de ataque. Não há segurança lá. Não foram levantados muitos CVEs sobre isso, mas se você olhar para eles, é claro que,como em qualquer outro projeto em que a segurança não esteja em primeiro lugar, ela é tratada com base nas sobras. Esta é a lei. A segurança é longa, cara, enfadonha, restringe o desenvolvedor, complica muito a vida. Fazer com que a segurança seja bem executada é um trabalho árduo e você tem que pagar por isso. Se você conversar com qualquer profissional de segurança, não importa quais qualificações, você ouvirá muitas histórias de terror sobre o Docker e histórias sobre como as coisas estão ruins. Eles estão parcialmente conectados com o próprio Docker, parcialmente com as pessoas que o operam, mas o próprio Docker poderia ajudar as pessoas e realizar algumas verificações de segurança dentro de si; por exemplo, não inicie um processo em um contêiner a partir da raiz, a menos que seja explicitamente instruído a fazê-lo.limita o desenvolvedor, torna a vida muito difícil. Fazer com que a segurança seja bem executada é um trabalho árduo e você tem que pagar por isso. Se você conversar com qualquer profissional de segurança, não importa quais qualificações, você ouvirá muitas histórias horríveis sobre o Docker e histórias sobre como as coisas estão ruins. Eles estão parcialmente conectados com o próprio Docker, parcialmente com as pessoas que o operam, mas o próprio Docker poderia ajudar as pessoas e realizar algumas verificações de segurança dentro de si; por exemplo, não inicie um processo em um contêiner a partir da raiz, a menos que seja explicitamente instruído a fazê-lo.limita o desenvolvedor, torna a vida muito difícil. Fazer com que a segurança seja bem feita é um trabalho árduo e você tem que pagar por isso. Se você conversar com qualquer profissional de segurança, não importa quais qualificações, você ouvirá muitas histórias horríveis sobre o Docker e histórias sobre como as coisas estão ruins. Eles estão parcialmente relacionados ao próprio Docker, em parte às pessoas que o operam, mas o próprio Docker poderia ajudar as pessoas e realizar algumas verificações de segurança dentro de si; por exemplo, não inicie um processo em um contêiner a partir da raiz, a menos que seja explicitamente instruído a fazê-lo.parcialmente - com as pessoas que o exploram, mas o próprio Docker poderia ajudar as pessoas e realizar algumas verificações de segurança dentro de si; por exemplo, não inicie um processo em um contêiner a partir da raiz, a menos que seja explicitamente instruído a fazê-lo.parcialmente - com as pessoas que o exploram, mas o próprio Docker poderia ajudar as pessoas e realizar algumas verificações de segurança dentro de si; por exemplo, não inicie um processo em um contêiner a partir da raiz, a menos que seja explicitamente instruído a fazê-lo.

Como armazenar estados? Posso hospedar o banco de dados no Kubernetes?

Se você perguntar ao DBA, ou à pessoa que era responsável pela infraestrutura desse banco de dados antes de decidir colocá-lo no Kubernetes, essa pessoa dirá não. Acho que em muitas mesas redondas as pessoas dirão que não deveria haver nenhum banco de dados no Kubernetes: é difícil, não confiável, não está claro como gerenciá-lo.

Eu acredito que os bancos de dados no Kubernetes podem ser representados. Quão confiável é? Bem, veja: estamos lidando com um sistema distribuído. Ao colocar um banco de dados em um cluster, você deve entender que tem um requisito de tolerância a falhas. Se você tiver esse requisito, provavelmente o que você colocou dentro do Kubernetes é um cluster de banco de dados. Quantas pessoas no mundo moderno sabem como fazer um cluster de banco de dados normal? Muitos bancos de dados fornecem recursos de cluster? Aqui começa a divisão dos bancos de dados em tradicionais - relacionais e não relacionais. A diferença deles não é que o último não suporte SQL de uma forma ou de outra. A diferença é que os bancos de dados não relacionais são muito mais adequados para trabalhar em clusters, porque foram originalmente escritos para que o banco de dados fosse distribuído. Portanto,se para algum MongoDB ou Cassandra você deseja hospedar no Kubernetes, não posso te dissuadir, mas você deve ter uma boa ideia do que vai acontecer a seguir. Você deve entender muito bem onde estão seus dados, o que acontecerá em caso de falha e recuperação, como os backups estão indo, onde está o ponto de recuperação e quanto tempo levará para ser recuperado. Essas perguntas não são relevantes para o Kubernetes; eles têm a ver com como você basicamente opera uma solução de cluster baseada em bancos de dados convencionais. É mais fácil com as soluções NoSQL, elas estão prontas para a nuvem imediatamente.onde está o ponto de restauração e quanto tempo levará para recuperar. Essas perguntas não são relevantes para o Kubernetes; eles têm a ver com como você basicamente opera uma solução de cluster baseada em bancos de dados convencionais. É mais fácil com as soluções NoSQL, elas estão prontas para a nuvem imediatamente.onde está o ponto de restauração e quanto tempo levará para recuperar. Essas perguntas não são relevantes para o Kubernetes; eles têm a ver com como você basicamente opera uma solução de cluster baseada em bancos de dados convencionais. É mais fácil com as soluções NoSQL, elas estão prontas para a nuvem imediatamente.

Mesmo assim, surge a pergunta: por que colocar o banco de dados no Kubernetes? Você pode pegar um serviço prestado pelo seu provedor, uma solução gerenciada; você pode levar RDS na Amazon, e também banco de dados gerenciado no Google. E mesmo um cluster desse banco de dados distribuído geograficamente, no caso da Amazon, esse é o Aurora, você pode instalar e usar. Mas, se você for instalar um cluster distribuído geograficamente da base, leia a documentação com atenção; Eu encontrei clusters Aurora com um único nó - eles não estavam nem mesmo divididos em duas regiões. Além disso, a segunda região não era necessária. Em geral, as pessoas têm coisas muito estranhas na cabeça: acreditam que o principal é escolher um produto, e então ele se dará e funcionará como deveria. Não. Os bancos de dados relacionais não estavam prontos para funcionar, mesmo em um cluster regular,para não mencionar geo-distribuído. Portanto, se você estiver fazendo algo complexo com base neles, verifique a documentação.

Basicamente, tenho experiência em operar um banco de dados dentro do Kubernetes. Não havia nada de errado. Houve vários travamentos relacionados à queda do nó; o movimento funcionou normalmente para outro nó. Tudo está sob controle. A única coisa que não posso agradar é dizer que houve um grande número de milhares de pedidos por segundo.

Se você tem uma solução média ou pequena - uma solução média para a Rússia corresponde aproximadamente a uma grande agência de notícias como a Lenta - então não deve haver um grande número de consultas complexas no banco de dados. Se a base falhar, provavelmente você está fazendo algo errado e precisa pensar a respeito. Não amplie descuidadamente. Mover uma solução não agrupada para um cluster tem suas vantagens, mas também um grande número de desvantagens - especialmente se você pegar um cluster postgres baseado em Patroni ou Stallone. Existem muitas condições de limite; Eu não os encontrei, mas colegas da Data Egret ficarão felizes em contar a você como isso acontece. Existe um relatório maravilhoso de Alexei Lesovsky sobre o que acontecerá se você tentar transferir sua base para um cluster sem pensar.

Cerca de milhares de solicitações por segundo. Se você tiver uma única Instância de banco de dados, ajustá-la a milhares de solicitações por segundo ainda será um aumento de escala. Mais cedo ou mais tarde você terá problemas. Parece-me que é melhor, se uma carga pesada for planejada, considerar as opções de escala horizontal. Encontre a maior tabela em seu banco de dados, veja o que há e pense se ela pode ser movida para um armazenamento não relacional. Pense em como não armazenar em um banco de dados relacional o que você normalmente armazena nele - por exemplo, logs de acesso do sistema, dos quais muitos caem, e você geralmente os acessa de acordo com o mesmo padrão que você usa para acessar o armazenamento de valor-chave ... Então, por que não escrever logs no Cassandra? Esta é uma pergunta para um arquiteto. Manter uma instância de base pequena e não muito ocupada no Kubernetes é o principalporque a magia do operador passa a ser responsável por isso.

Basicamente, se você observar o que o Kubernetes é como sistema operacional e plataforma, este é um construtor do tipo faça você mesmo. Há tudo para você construir uma arquitetura de microsserviço, incluindo a capacidade de armazenar estados em discos, organizar telemetria, monitoramento e alertas. Isso é feito por Helm, o gerenciador de pacotes do Kubernetes. Há um grande número de gráficos do Helm de código aberto disponíveis publicamente na Internet. A maneira mais fácil de aumentar a infraestrutura de um projeto é pegar o Helm Chart que coloca sua aplicação, seu serviço, se este serviço for um banco de dados Redis, PostgreSQL, Patroni - o que for; comece a configurá-lo e aplique esta configuração. É totalmente declarativo; tudo o que pode ser previsto, os autores do Helm Charts geralmente fornecem. É melhor lançar seu aplicativo com o Helm também.O terceiro Helm não contém serviços do lado do cluster; o segundo continha, ele tinha um serviço trabalhando constantemente do administrador do cluster, que era necessário para distribuir releases por namespace, mas o terceiro Helm fechou essa brecha de segurança.

Helm é um mecanismo de modelo baseado na sintaxe de modelo GoLang. Recebe uma lista de variáveis, que são uma estrutura não planar (graças a Deus, é hierárquica - escrita em YAML); Usando o Helm, essas variáveis são colocadas nos lugares certos nos modelos do Helm, então você aplica tudo em algum namespace, seus códigos, serviços são iniciados lá, suas funções são criadas. Há um gerador de andaimes que permite que o Helm Chart escreva sem recuperar a consciência. A única coisa que não gosto é a necessidade de conhecer a sintaxe da modelagem GoLang e das ramificações condicionais no próprio Helm; eles são feitos de acordo com o princípio de Lisp, com notação de prefixo. É bom que outra pessoa goste, mas sempre muda a cabeça. Bem, vamos superar isso.

Agora um pouco sobre o que vai acontecer a seguir. Já me parecia com operadores; esses são os serviços que residem dentro do cluster Kubernetes e gerenciam o ciclo de vida de outro aplicativo maior. Difícil o suficiente. Você pode pensar em uma operadora como o engenheiro de confiabilidade de seu site doméstico de silício; com certeza no futuro as pessoas escreverão mais e mais operadores, pois ninguém quer manter uma mudança de pessoal de 1º nível de suporte que seguiria o cronograma do Nagios, notaria interrupções e tomaria ações manuais. O operador entende quais estados do sistema são possíveis; é uma máquina de estado. Agora a concentração do conhecimento humano, escrito na linguagem GoLang ou algo semelhante, é compilada, colocada em um cluster e faz muito trabalho para você: adiciona ou remove nós, reconfigura, garante que o caído suba,para que os dados sejam encaixados nos códigos desejados de onde estão. Em geral, ele gerencia o ciclo de vida do que está instalado por baixo. Os operadores agora estão literalmente para tudo. Tenho me divertido com o fato de que, usando o operador Rook, coloquei sev diretamente no cluster Kubernetes. Observei como isso está acontecendo e estou muito feliz, e acho que mais operadores são necessários e todos devemos participar de seus testes. O tempo que você gasta corrigindo a operadora de outra pessoa é um presente para a humanidade. Você não precisa mais fazer o mesmo trabalho repetidamente. Você pode colocar este trabalho de uma forma alienada no repositório, e então um programa inteligente fará isso por você - não é felicidade?Os operadores agora estão literalmente para tudo. Tenho me divertido usando o operador Rook para colocar sev diretamente no cluster do Kubernetes. Observei como isso está acontecendo e estou muito feliz, e acho que mais operadores são necessários e todos devemos participar de seus testes. O tempo que você gasta corrigindo a operadora de outra pessoa é um presente para a humanidade. Você não precisa mais fazer o mesmo trabalho repetidamente. Você pode colocar este trabalho de uma forma alienada no repositório, e então um programa inteligente fará isso por você - não é felicidade?Os operadores agora estão literalmente para tudo. Tenho me divertido com o fato de que, usando o operador Rook, coloquei sev diretamente no cluster Kubernetes. Observei como isso está acontecendo e estou muito feliz, e acho que mais operadores são necessários e todos devemos participar de seus testes. O tempo que você gasta corrigindo a operadora de outra pessoa é um presente para a humanidade. Você não precisa mais fazer o mesmo trabalho repetidamente. Você pode colocar este trabalho de uma forma alienada no repositório, e então um programa inteligente fará isso por você - não é felicidade?que você gasta corrigindo a operadora de outra pessoa é um presente para a humanidade. Você não precisa mais fazer o mesmo trabalho repetidamente. Você pode colocar este trabalho de uma forma alienada no repositório, e então um programa inteligente fará isso por você - não é felicidade?que você gasta corrigindo a operadora de outra pessoa é um presente para a humanidade. Você não precisa mais fazer o mesmo trabalho repetidamente. Você pode colocar este trabalho de uma forma alienada no repositório, e então um programa inteligente fará isso por você - não é felicidade?

Eu baixei o livro Red Hat - eles distribuem gratuitamente - sobre como os operadores do Kubernetes funcionam e como escrever o seu próprio, recomendo que você vá ao site deles e faça o download também, o livro é muito interessante. Quando eu ler na íntegra, talvez possamos analisar algum operador juntos.

Quem apóia o Swarm? Além da Docker Inc?

Ninguém. And Docker Inc. já rasgado em duas metades e metade vendida em algum lugar. Não sigo o que está acontecendo com eles; certa vez chamaram o produto de Mobi, mas era uma versão open source, ou seja, não era uma versão aberta. E algo foi vendido com direitos, mas algo não foi vendido. Para mim, parece "um paciente suava antes de morrer" - as pessoas estão tentando de alguma forma extrair o dinheiro investido. Em geral, ninguém apóia isso.

Senhor de escravos

Funciona. Se o mestre / escravo parar de funcionar em um banco de dados relacional, o mundo acabará aí. O Kubernetes não interfere no banco de dados de forma alguma; a única coisa que ele traz são verificações de saúde diferentes, que podem ser desabilitadas se desejado, e, em princípio, gerenciamento de estado. É aconselhável não desativá-lo - sua operadora que gerencia o banco de dados deve ver seu estado.

Qual é o nome do livro Red Hat?

Os operadores do Kubernetes são chamados assim. O pato é desenhado lá. O livro de O'Reilly, agora redesenhado as capas; vários livros foram publicados em colaboração com a Red Hat. A Red Hat tem mais 3 ou 4 livros do Kubernetes que você pode baixar gratuitamente: por exemplo, Kubernetes Patterns, gRPC. O protocolo gRPC, embora não esteja diretamente relacionado ao Kubernetes, é usado por muitos para trocar dados entre microsserviços. Além disso, é usado em balanceadores de carga de próxima geração, por exemplo, no Envoy.

O que é um SRA?

Este é o tipo de pessoa que entende o período de tempo das mudanças que ocorrem em um sistema distribuído. A grosso modo, ele entende há quanto tempo você está deitado este mês, quanto mais pode, se pode dar permissão para a liberação. Gerencia as chaves de backups, planos de recuperação, problemas de recuperação de desastres, problemas de manutenção de infraestrutura para uma aplicação industrial que deve funcionar 24 horas por dia, 7 dias por semana. Ele tem métricas para o estado e o estado do negócio do aplicativo nas métricas do aplicativo - quanta latência, onde e quantas solicitações; esses mesmos 4 sinais de ouro. Além disso, o SRA, com base nessas métricas, pode tomar medidas para trazer o sistema de volta à prontidão de combate, ele tem um plano de como fazer isso. Por alguma razão, isso não é exigido do DevOps clássico, apenas ajuda o desenvolvedor a lançar o aplicativo, geralmente para implementá-lo em algum lugar.E a SRA também resiste ao fluxo de solicitações de diferentes lados.

Prometi falar sobre segurança. Você sabe, este é um tópico bastante recente no Kubernetes. Eu só conheço o básico: por exemplo, que você não deve executar um aplicativo em um serviço a partir do root, porque assim que isso acontecer, ele terá acesso a tudo no namespace, direitos de superusuário, e você poderá tentar quebrar o kernel do sistema host, que, provavelmente funcionará (e realizará quaisquer outras operações a partir da raiz). Não dê aos hackers uma dica como essa; se possível, conceda aos usuários o mínimo de direitos possível e controle bem a entrada do usuário. Parece-me que se falamos sobre segurança do Kubernetes, ela precisa ser removida em algum lugar dos circuitos fechados que temos atualmente. Ou, se você realmente deseja entrar em questões de segurança, deve verificar o projeto Cilium. Ele sabe como usar protetores contra sobretensão,Diferenciação de tráfego de rede baseada em BPF - funciona melhor do que iptables. Este é o futuro. Parece-me que fora da Califórnia ninguém realmente usa, mas você já pode começar. Talvez haja algum outro projeto, mas duvido. Em geral, a humanidade tem poucas mãos que trabalham.

Portanto, não tenho nada de especial a dizer sobre segurança. Existem várias opções para locação montada no Kubernetes, mas aí você tem que sentar com um lápis e descobrir o que as pessoas fizeram, que vulnerabilidade elas eliminaram, se fazia sentido, se se aplica ao seu modelo de ameaça. A propósito, recomendo começar procurando uma descrição de como o modelo de ameaça é construído e construindo você mesmo. Existem métodos mais ou menos formais. Desenhe, olhe para ele e talvez um insight aconteça e você entenderá o que precisa e o que não é na situação atual. Talvez seja o suficiente para conduzir todos os Kubernetes a um ciclo fechado. A propósito, esta é a decisão certa; Eu descobri isso e é impenetrável. Se você conseguir acessar o sistema apenas apresentando um passe no relógio, e não houver Internet dentro, e a troca passar por algum gateway especial,localizado na DMZ e é difícil de quebrar porque é escrito de forma incomum - então é um sistema bem protegido. Como fazer isso por meios técnicos - bem, você precisa monitorar o mercado atual de soluções. Está mudando muito, segurança é um tema quente. Há muitos jogadores tentando ser, mas qual deles está mentindo e qual não está - eu não pretendo dizer. Embora a Red Hat provavelmente não esteja mentindo, ela não está à frente de todos. Você só precisa pesquisar (e eu também), porque ainda não está claro.Você só precisa pesquisar (e eu também), porque ainda não está claro.Você só precisa pesquisar (e eu também), porque ainda não está claro.

Vamos falar sobre o que mais o cluster Kubernetes deve ter. Já que temos a oportunidade de instalar aplicativos lá gratuitamente, e não temos medo de armazenar o banco de dados lá. A propósito, se você tiver Kubernetes gerenciado, não há dúvidas sobre onde armazenar o banco de dados: você tem armazenamento tolerante a falhas, de uma forma ou de outra (geralmente na forma de dispositivos de bloco) fornecido pela nuvem em que o Kubernetes gerenciado está localizado. Você pode colocar discos deste armazenamento em seu cluster com segurança e usar instantâneos para fazer backups consistentes. Só não se esqueça de que o instantâneo não é um backup, você também precisa copiar o instantâneo em algum lugar. Isso é óbvio, mas é bom repetir as coisas óbvias para que não sejam esquecidas.

É muito importante quando você tem uma plataforma de arquitetura de microsserviço para torná-la rastreável, observável, para que você possa entender onde as solicitações estão e onde estão perdendo tempo, e assim por diante. Construir essa plataforma é muito trabalhoso. Você precisará do Prometheus. Será necessário porque é um projeto Cloud Native Computing Foundation; ele é projetado especificamente para monitorar Kubernetes. Contém um grande número de exportadores, colecionadores de métricas; alguns aplicativos contêm nativamente todos os seus painéis. Se seu aplicativo não os contiver, levará 20 minutos para anexar ao aplicativo de painel do Prometheus de longa duração. Embora por algum motivo ninguém o anexa. Na minha experiência, isso ocorre porque as pessoas mantêm seus produtos nas nuvens. Há Amazon CloudWatch, Google StackDriver,e você pode enviar métricas para lá da mesma maneira - embora isso custe dinheiro. Ou seja, se as pessoas ainda pagam pela infraestrutura, então pagam pelas ferramentas de monitoramento anexadas a ela. No entanto, o Prometheus pode ser muito conveniente se você tiver vários lugares diferentes de onde obtém métricas, se a nuvem não estiver em um lugar, se for híbrida, se você tiver máquinas no local e precisar de uma infraestrutura centralizada. Então Prometheus é sua escolha.se você tem máquinas no local e precisa de uma infraestrutura centralizada. Então Prometheus é sua escolha.se você tiver máquinas no local e precisar de uma infraestrutura centralizada. Então Prometheus é sua escolha.

O que mais você precisa? É claro que onde o Prometheus está, também é necessário o Alert Manager. E você também precisa de algum tipo de rastreamento distribuído de suas solicitações. Como fazer isso no Kubernetes - bem, pegue algum produto como jaeger ou zipkin ou o que quer que esteja no topo agora; também Cassandra para armazenar seus traços, também Grafana para renderizá-los. Pelo que entendi, esse recurso apareceu no Grafana recentemente, mas isso não é uma razão para não implementá-lo. Ou seja, você pode montar manualmente um ambiente no qual os aplicativos irão [glitches 49:14] (ter?) Nesse tempo de execução, contadores e outras métricas adequadas para a construção, visualização de seus traços distribuídos: onde o aplicativo gasta quanto tempo?

É menos conveniente falar sobre isso do que mostrar, mas não há nada para me mostrar agora; Não tenho nada disso em meu laboratório agora. Um dia provavelmente estarei pronto.

Acho que contei tudo o que queria contar. Vou repetir as disposições principais mais uma vez.

Primeiro: o Kubernetes libera você da necessidade de escrever um mecanismo para a substituição à prova de falhas de um contêiner por outro no Ansible Engine X.

Segundo: o Kubernetes não desaparecerá em lugar nenhum. Ele pode "morrer", mas não é mais possível parar de usá-lo, ele conquistou grande parte do mercado. À pergunta "quando o Kubernetes morrerá:" eu quero perguntar "quando o WordPress morrerá?" E ele ainda precisa viver e viver. Vamos definir a ordem: primeiro WP, depois Kubernetes.

Então, o Kubernetes está conosco. Não é ele quem é interessante, mas os serviços que são enrolados no topo são interessantes - são os operadores e a Definição de Recursos Customizados. A capacidade de pegar e escrever seu próprio recurso, que será chamado de "cluster PostgreSQL", descrevê-lo com um rodapé YAML e jogá-lo no cluster.

O que mais vai acontecer? Haverá também a capacidade de gerenciar tudo isso, linguagens de programação com tipos estáticos, como GoLang e TypeScript. E eu realmente acredito em Kotlin - muitas DSLs legais já estão escritas nele. E mais será escrito.

Haverá também Helm Chart pago, aplicativos pagos que podem ser lançados no local, alguns licenciados, por assinatura. Haverá integração de vários serviços - na verdade, ele já existe, por exemplo, o DataDog já está se integrando ao Kubernetes. E novos caras que aparecerão no mercado de alertas de monitoramento também se integrarão ao Kubernetes, por razões óbvias. Nenhum produto de nuvem passará pelo Kubernetes, de uma forma ou de outra. Esta é a plataforma que todos buscarão.

Mas tudo isso não significa que o Kubernetes seja bom e nada poderia ser melhor. Eu comparo com o que era antes - com soluções da Amazon: ECS, Elastic Beanstalk. Quem já os conheceu sabe que, na minha velha analogia, aquela coisa, aquela outra seria não apenas 737 MAX, mas 737 MAX, feito de fita isolante e plasticina. Portanto, os principais players - Amazon, Microsoft Azure, Google - já estão todos no Kubernetes. Provavelmente, Yandex e Mail.ru também estão, mas eu não os sigo. Este é um futuro tão comum. Um futuro comum tão ruim, mas "bom o suficiente" com o qual todos concordam até agora. Você tem que perguntar à Red Hat - eles são mais espertos do que eu.

Como Java se sente em relação ao Kubernetes?

Bem.

Qual sistema operacional você está usando no seu PC?

Ambos estão no macOS.

Os especialistas em DevOps são recrutados ativamente agora?

Sim, elas sempre foram tiradas ativamente em um local remoto e agora são tiradas ativamente da mesma maneira. A situação não vai mudar fundamentalmente, eu acho. Em geral, não considero um trabalho não removido: nem toda boa empresa tem um escritório em São Petersburgo. Claro, haverá uma distância, e os acontecimentos atuais mostraram às pessoas que isso é possível. O número de pessoas que se sentem mais confortáveis com isso só vai aumentar. Dizem que “muitas pessoas tentaram e voltaram para o escritório” - bem, voltar para o escritório custa dinheiro. Sem dinheiro - sem escolha, e muitas empresas estão economizando agora.

"Docker já está morto" ou o que quer que você quisesse saber sobre Devops, mas estava com medo de perguntar