🏣 🙅🏿 🤱🏻 "Vamos usar o Kubernetes!" Agora você tem 8 problemas 👨🏽‍🎨 👚 😂

Se você usa o Docker, o próximo passo lógico parece estar mudando para o Kubernetes, são os K8s, certo? Bem, suponha. No entanto, as soluções projetadas para 500 engenheiros de software que desenvolvem simultaneamente um único aplicativo são bem diferentes das soluções para 50 pessoas. E a solução para uma equipe de 5 programadores é outra história.

Se você trabalha em uma equipe pequena, o Kubernetes provavelmente não é para você. Trará muita dor em troca de benefícios extremamente modestos.
Vamos ver por que isso pode acontecer.

Todo mundo gosta das "partes móveis"

O Kubernetes está se movendo e mudando bastante: conceitos, subsistemas, processos, máquinas, código ... E tudo isso significa muitas dificuldades.

Vários carros

Kubernetes é um sistema distribuído: possui uma máquina host que controla o resto, trabalhadores. Cada máquina realiza trabalhos em contêineres.
Portanto, já estamos falando de pelo menos duas máquinas físicas ou virtuais, necessárias apenas para fazê-lo funcionar. Mas na verdade você recebe ... apenas um carro. Se você estiver escalando (é onde o cão está enterrado!), Você precisará de três, quatro ou talvez até dezessete máquinas virtuais.

Muito, muito código

A base de código Kubernetes no início de março de 2020 inclui mais de 580.000 linhas de código no Go. E este é apenas um código limpo, excluindo comentários, linhas em branco e pacotes de fornecedores. A revisão de segurança de 2019 descreve a base de código da seguinte maneira:
“A base de código do Kubernetes tem espaço significativo para melhorias. É grande e complexo, contém grandes seções de código com documentação mínima e um grande número de dependências, incluindo sistemas que não fazem parte do Kubernetes. Também na base de código há muitos casos de reimplementação da lógica, que poderiam ser centralizados no suporte a bibliotecas, o que reduziria a complexidade, simplificaria as correções e reduziria a carga de documentos em várias áreas da base de código. ”
Para ser honesto, o mesmo pode ser dito sobre muitos outros projetos grandes, mas todo esse código deve funcionar corretamente se você não quiser que seu aplicativo falhe.

Complexidade arquitetônica, operacional, configuração e conceitual

O Kubernetes é um sistema abrangente com muitos serviços, sistemas e muito mais.
Antes de iniciar seu único aplicativo, você precisará fornecer a seguinte arquitetura bastante simplificada (a imagem original é obtida na documentação do Kubernetes):

A documentação conceitual do K8s inclui muitas coisas puramente "educacionais", como o seguinte trecho:

In Kubernetes, an EndpointSlice contains references to a set of network endpoints. The EndpointSlice controller automatically creates EndpointSlices for a Kubernetes Service when a selector is specified. These EndpointSlices will include references to any Pods that match the Service selector. EndpointSlices group network endpoints together by unique Service and Port combinations.
By default, EndpointSlices managed by the EndpointSlice controller will have no more than 100 endpoints each. Below this scale, EndpointSlices should map 1:1 with Endpoints and Services and have similar performance.

Na verdade, entendo do que se trata, mas preste atenção em quantos conceitos você precisa aprender: EndpointSlice, Service, seletor, Pod, Endpoint.

E - sim, na maioria das vezes você não usará todos esses recursos. Portanto, na maioria das vezes você não precisará do Kubernetes.

Aqui está outro trecho aleatório:

Por padrão, o tráfego enviado para um Serviço ClusterIP ou NodePort pode ser roteado para qualquer endereço de back-end do Serviço. Desde o Kubernetes 1.7, é possível rotear tráfego "externo" para os Pods em execução no Nó que recebeu o tráfego, mas isso não é suportado pelos Serviços de ClusterIP, e topologias mais complexas - como o roteamento zonalmente - não são possíveis. O recurso de topologia de serviço resolve isso, permitindo que o criador do serviço defina uma política para rotear o tráfego com base nos rótulos dos nós dos nós de origem e de destino.

Aqui está o que a análise de segurança diz sobre isso:

Kubernetes — , . , Kubernetes — , , , .

Quanto mais você adquire o Kubernetes, mais difícil o processo normal de desenvolvimento se torna: você precisa de todos esses conceitos (Pod, Implantação, Serviço etc.) apenas para fazer seu código funcionar. Portanto, você precisa promover um sistema K8s completo, mesmo apenas para testes através de uma máquina virtual ou contêineres Docker aninhados.

E, desde que a sua aplicação torna-se mais difícil de ser executado localmente, o desenvolvimento é complicado por muitas opções para resolver este problema, a partir de um ambiente de banco para proxy um processo local de um cluster (eu escrevi esta ferramenta um par de anos atrás ) e proxy um processo remoto a uma máquina local ...

Você pode escolha qualquer opção, mas nenhuma delas será perfeita. A maneira mais fácil de não usar o Kubernetes.

Microsserviços (essa é uma má ideia)

Um problema secundário é que, como o seu sistema permite executar muitos serviços, você deve escrever esses muitos serviços. Péssima ideia.
Aplicação distribuída é difícil de escrever qualidade. De fato , quanto mais partes móveis, mais esses problemas interferem no trabalho.

Aplicativos distribuídos são difíceis de depurar. Você precisará de um tipo completamente novo de ferramentas de depuração e registro, que ainda fornecerão menos do que os logs de um aplicativo monolítico.

Os microsserviços são uma das técnicas de dimensionamento nas organizações: quando você tem 500 desenvolvedores que atendem a um site produtivo, faz sentido aceitar o custo de um sistema distribuído em larga escala se permitir que as equipes de desenvolvimento trabalhem independentemente. Assim, cada equipe de 5 pessoas recebe um único microsserviço e finge que todos os outros microsserviços são serviços externos nos quais você não deve confiar.

Se toda a sua equipe é composta por 5 pessoas, você tem 20 microsserviços e as circunstâncias de força maior não o obrigam a criar um sistema distribuído; então, em algum lugar que você calculou mal. Em vez de 5 pessoas por 1 microsserviço, como nas grandes empresas, você recebe 0,25 pessoas.

Kubernetes não é útil?

Dimensionamento

O Kubernetes pode ser útil se você precisar de uma escalabilidade séria. No entanto, vamos ver quais alternativas você tem:

Você pode comprar VMs na nuvem, e elas terão até 416 CPUs virtuais e 8 TB de RAM, ou seja, uma potência completamente desagradável. Vai custar um centavo bonito, mas será extremamente simples de fazer.
Muitos aplicativos web simples podem ser dimensionados de maneira bastante fácil com serviços como o Heroku.

Supõe-se, é claro, que um aumento no número de VMs em funcionamento também funcionará em suas mãos:

A maioria dos aplicativos não requer dimensionamento significativo; eles terão otimização de alta qualidade suficiente.
O gargalo para dimensionar a maioria dos aplicativos da Web são bancos de dados, não trabalhadores da Web

Confiabilidade

Quanto mais partes móveis, maior o potencial de ocorrência de um erro.
Os recursos do Kubernetes, aprimorados pelo aumento da confiabilidade (verificações de integridade, implantações contínuas), em muitos casos já podem ser integrados ou implementados com muito mais facilidade. Por exemplo, o nginx pode fazer verificações de saúde nos processos de trabalho e você também pode usar o docker-autoheal ou algo semelhante para reiniciar automaticamente esses processos.

Se você estiver particularmente preocupado com o tempo de inatividade, o primeiro pensamento que o visitará não deve ser "como reduzo o tempo de inatividade ao implantar de 1 segundo a 1 milissegundo), mas deve ser" como garantir que as alterações no esquema do banco de dados permitam a reversão se eu em algum lugar em algum lugar?
E se você precisar de trabalhadores da Web confiáveis sem uma única máquina como ponto de falha, há muitas maneiras de implementar isso sem o Kubernetes.

Melhores práticas?

De fato, não existem boas práticas na natureza. Existem apenas práticas recomendadas para cada situação específica. Portanto, se algo está em tendência e é popular, isso não significa que seja a escolha certa especificamente para você.
Em alguns casos, o Kubernetes é a melhor opção. O resto é uma perda de tempo.

A menos que você sinta a necessidade urgente de todas essas complexidades, você tem uma ampla seleção de ferramentas que resolverão seus problemas: Docker Compose para uma máquina, Nomad da Hashicorp para orquestração, Heroku e sistemas similares para dimensionamento e algo como Shakemake para pipelines de computação.

Posfácio do Editor

Como um provedor de nuvem, encontramos regularmente uma grande variedade de clientes, desde pequenas startups a grandes organizações com processos de negócios complexos e solicitações de infraestrutura relacionadas. Independentemente da qualidade da tecnologia, sempre haverá precedentes nos quais sua aplicação resultará em dificuldades desnecessárias. Você deve sempre sair da situação e pesar cuidadosamente os prós e contras das opções disponíveis. O autor do artigo engrossou um pouco suas cores, mas sua mensagem é bastante clara: às vezes, para tomar a decisão certa, vale a pena se afastar das tendências e avaliar seu projeto de forma imparcial. Isso economizará a força dos desenvolvedores e o uso dos recursos da empresa o tornará mais apropriado.

"Vamos usar o Kubernetes!" Agora você tem 8 problemas