Cartomancia

O Kubernetes já desempenhou um papel importante no meu trabalho, e no futuro se tornará ainda mais importante. Mas 2018 está chegando ao fim, então esqueça a modéstia e faça uma previsão ousada:

O futuro do Kubernetes são máquinas virtuais, não contêineres

De acordo com o horóscopo chinês, 2018 foi o ano do cão, mas em tecnologia foi o ano de Kubernetes. Agora, muitos estão aprendendo sobre essa tecnologia revolucionária, e os departamentos de TI de todos os lugares estão tentando desenvolver uma "estratégia Kubernetes" [1]. Algumas organizações já transferiram grandes cargas de trabalho para o Kubernetes.

[1] Se você está tentando desenvolver uma estratégia do Kubernetes, já falhou, mas este é um tópico para outro artigo.

Em outras palavras, há muitas pessoas no Kubernetes em todas as etapas do "Ciclo de Sensação da Gartner". Alguns estão presos em um vazio de decepção ou afogados em um poço de desespero.


Jeremykemp, Wikipedia . Creative Commons CC BY-SA 3.0

Sou um grande fã de contêineres e não direi que eles estão mortos . Em 2013, o Docker nos deu um shell para Linux Containers: uma nova maneira incrível de criar, empacotar, compartilhar e implantar aplicativos. Apareceu no momento certo, quando começamos a levar a sério a entrega contínua. Seu modelo tornou-se ideal para a cadeia de entrega e contribuiu para o surgimento da plataforma PaaS e, em seguida, CaaS.



Os engenheiros do Google viram que a comunidade de TI estava finalmente pronta para os contêineres. O Google usa contêineres há muito tempo e, em certo sentido, eles podem ser considerados os inventores da contêiner. Eles começaram a desenvolver o Kubernetes. Como você sabe agora, esta é a reencarnação gratuita da plataforma Borg do Google.

Logo, o suporte ao Kubernetes foi fornecido por todas as nuvens grandes (GKE, AKS, EKS). Os serviços locais também aumentaram rapidamente as plataformas baseadas no Kubernetes (Pivotal Container Service, Openshift, etc.).

Multilocação suave

Foi necessário resolver um problema irritante, que pode ser considerado uma falta de contêineres ... isso é multilocação.

Os contêineres do Linux não foram criados como caixas de proteção seguras (como Solaris Zones ou FreeBSD Jails). Em vez disso, eles criaram um modelo comum de kernel que usa funções do kernel para fornecer isolamento básico do processo. Como diria Jesse Frazel , "os contêineres não são a coisa real".


Isso é agravado pelo fato de a maioria dos componentes do Kubernetes não estar ciente dos inquilinos. Obviamente, você tem namespaces de pod e políticas de segurança , mas não existe na API. Bem como em componentes internos, como kubelet ou kube-proxy . Isso leva ao fato de que o Kubernetes implementa o modelo de "aluguel suave" (arrendamento temporário).


Arquitetura Kubernetes

Abstrações se infiltram ainda mais. Uma plataforma em cima de contêineres herda muitos aspectos do aluguel suave. As plataformas em cima das máquinas virtuais com vários locatários herdam esse contrato difícil (VMware, Amazon Web Services, OpenStack etc.).

O modelo de aluguel flexível da Kubernetes coloca os prestadores de serviços e as distribuições em uma posição estranha. O próprio cluster Kubernetes está se tornando uma linha de "aluguel duro". Mesmo dentro da mesma organização, há muitos motivos para exigir um aluguel rígido entre usuários (ou aplicativos). Como as nuvens públicas fornecem Kubernetes totalmente gerenciados como um serviço, é fácil para os clientes pegar seu próprio cluster e usar o limite do cluster como um ponto de isolamento.

Algumas distribuições do Kubernetes, como o PKS (Pivotal Container Service) , conhecem bem esse problema de aluguel e usam um modelo semelhante, fornecendo o mesmo Kubernetes como um serviço que pode ser obtido de uma nuvem pública, mas em seu próprio data center.

Isso levou ao surgimento do modelo de "muitos clusters", em vez de "um grande cluster comum". Freqüentemente, os clientes GKE do Google têm dezenas de clusters Kubernetes implantados para várias equipes. Geralmente, cada desenvolvedor obtém seu próprio cluster. Esse comportamento gera um número chocante de instâncias (Kubesprawl).

Como alternativa, os operadores criam seus próprios clusters Kubernetes em seus próprios datacenters para realizar trabalhos adicionais para gerenciar vários clusters ou concordam em conceder um ou dois clusters grandes suavemente.

Normalmente, o menor cluster é de quatro máquinas (ou máquinas virtuais). Um (ou três para HA) para o Kubernetes Master, três para os Trabalhadores do Kubernetes. Muito dinheiro é gasto em sistemas que, na maioria das vezes, estão ociosos.

Portanto, você precisa de alguma forma mover o Kubernetes em direção a uma multilocação rígida. A comunidade Kubernetes está bem ciente dessa necessidade. Um grupo de trabalho com várias locações já foi formado. Ela está trabalhando duro nesse problema, e eles têm vários modelos e sugestões sobre como trabalhar com cada modelo.

Jesse Frazel escreveu um post sobre este tópico, e é ótimo porque ela é muito mais esperta do que eu, para que eu possa me referir a ela e me salvar de dez anos de intenso estudo, tentando alcançar seu nível. Se você não leu essa postagem, leia-a agora.

Apenas VMs muito pequenas otimizadas para velocidade ...

O Kata Containers é um projeto de código aberto e uma comunidade trabalhando para criar uma implementação padrão de máquinas virtuais leves que parecem e funcionam como contêineres, mas fornecem isolamento de carga de trabalho e benefícios de segurança da VM.

Jesse sugere usar a tecnologia de contêineres VM, como os contêineres Kata . Eles oferecem isolamento no nível da VM, mas funcionam como contêineres. Isso permite que o Kubernetes dê a cada "inquilino" (assumimos que o inquilino no espaço de nomes) seu próprio conjunto de serviços do sistema Kubernetes em execução em contêineres VM aninhados (o contêiner VM dentro da máquina virtual que a infraestrutura IaaS fornece).


Imagem de Jesse Frasel: locação múltipla em Kubernetes

Esta é uma elegante solução de aluguel múltiplo da Kubernetes. Sua proposta vai ainda mais longe para o Kubernetes usar contêineres VM aninhados para cargas de trabalho (Pods) em execução no Kubernetes, o que fornece um aumento significativo na utilização de recursos.

Temos pelo menos mais uma otimização. Crie o hipervisor certo para o provedor de infraestrutura subjacente ou provedor de nuvem. Se o contêiner da VM for uma abstração de primeiro nível fornecida pelo IaaS, aumentaremos ainda mais a utilização de recursos. O número mínimo de VMs para iniciar um cluster Kubernetes é reduzido para uma máquina (ou três para HA) para hospedar o sistema de gerenciamento Kubernetes, disponível para o "superusuário".

Multilocação (custo) com otimização de recursos

Uma implantação do Kubernetes com dois namespaces e vários aplicativos em execução terá a seguinte aparência:

Nota: existem outras cargas na mesma infraestrutura IaaS. Por serem contêineres de VM, eles têm o mesmo nível de isolamento que as VMs em nuvem convencionais. Portanto, eles podem trabalhar no mesmo hipervisor com risco mínimo.

Inicialmente, nenhuma infraestrutura é implantada na nuvem; portanto, para um superusuário, os custos são zero.

Um superusuário solicita um cluster Kubernetes da nuvem. O provedor de serviços em nuvem cria uma máquina virtual com um contêiner (ou três para HA) que executa as principais APIs do Kubernetes e os serviços do sistema. O superusuário pode implantar módulos no espaço para nome do sistema ou criar novos espaços para delegar o acesso a outros usuários.

O superusuário cria dois namespaces foo e bar . O Kubernetes solicita dois contêineres de VM da nuvem para cada nível de gerenciamento de namespace (API do Kubernetes e Serviços do Sistema). O superusuário delega o acesso a esses namespaces a alguns usuários, cada um deles lança algumas cargas de trabalho (módulos) e os contêineres da VM solicitam esses contêineres para essas cargas de trabalho.

Em todas as etapas, o superusuário paga apenas pelos recursos realmente consumidos. O provedor de serviços em nuvem controla esses recursos e eles estão disponíveis para qualquer usuário da nuvem.

Eu realmente não estou dizendo nada de novo ...

Os provedores de serviços em nuvem já estão trabalhando nessa direção. Você pode verificar isso assistindo a eventos da comunidade (a Amazon já pode ter feito isso silenciosamente com o Fargate).

A primeira dica é o Virtual Kubelet , uma ferramenta de código aberto projetada para disfarçar como kubelet. Ele conecta o Kubernetes a outras APIs, o que permite ao Kubernetes solicitar contêineres de VM de um agendador padrão na nuvem.

Outras dicas são um grande número de novas tecnologias para contêineres de VM, como os contêineres Kata já mencionados, bem como o Firecracker da Amazon e o orientador do Google.

Conclusão

Se você implementar corretamente as melhorias no modelo de aluguel rígido, encontrará a virtualização do Santo Graal de Kubernetes. Isolamento completo de cargas de trabalho e sem custos adicionais.

Se você não usar a nuvem pública, ainda obterá os benefícios de uma maior utilização de recursos, que compensa com os requisitos de hardware mais baixos.

Esperamos que o VMware e o OpenStack prestem atenção e liberem hipervisores com base em contêineres leves da VM e nas implementações correspondentes do Virtual Kubelet.