🖐🏽 🧛 🤸🏾 Kubernetes 1.17: Visão geral das principais inovações 🕤 🔎 👩🏻‍🏫

Ontem, 9 de dezembro, o próximo lançamento do Kubernetes - 1.17. De acordo com a tradição do nosso blog, falamos sobre as mudanças mais significativas na nova versão.

As informações usadas para preparar este material são extraídas do anúncio oficial, da tabela de rastreamento de aprimoramentos do Kubernetes , CHANGELOG -1.17 e questões relacionadas, solicitações de recebimento e propostas de aprimoramento do Kubernetes (KEP). Então, o que há de novo? ..

Roteamento Baseado em Topologia

Há muito tempo, a comunidade Kubernetes aguarda esse recurso - roteamento de serviço com reconhecimento de topologia . Se o KEP se basear nele em outubro de 2018, e o aprimoramento oficial for de 2 anos atrás, os problemas comuns (como este ) serão ainda alguns anos mais antigos ...

A idéia geral se resume a fornecer a capacidade de implementar o roteamento “local” para serviços localizados no Kubernetes. "Localidade" neste caso significa "o mesmo nível topológico" (nível de topologia) , que pode ser:

mesmo nó para serviços,
mesmo rack de servidor
a mesma região
o mesmo provedor de nuvem
...

Exemplos de uso desse recurso:

economizando tráfego em instalações na nuvem com muitas zonas de disponibilidade (multi-AZs) - veja a ilustração mais recente sobre o exemplo de tráfego de uma região, mas AZs diferentes na AWS;
menos latência no desempenho / melhor rendimento;
um serviço fragmentado que possui informações de nó local em cada fragmento;
colocar fluentd (ou análogos) em um nó com aplicativos cujos logs são coletados;
...

Esse roteamento, “conhecer” sobre a topologia, também é chamado de afinidade de afinidade de rede - semelhante à afinidade de nó , afinidade / antiparidade de pod ou o recentemente lançado agendamento de volume com reconhecimento de topologia (e provisionamento de volume ) recentemente introduzido. O nível de implementação atual do ServiceTopology no Kubernetes é a versão alfa.

Para obter detalhes sobre como o recurso é organizado e como ele já pode ser usado, leia este artigo de um dos autores.

Suporte para pilha dupla IPv4 / IPv6

Progresso significativo foi registrado em outro recurso de rede: o suporte simultâneo de duas pilhas IP, introduzidas pela primeira vez no K8s 1.16 . Em particular, o novo lançamento trouxe as seguintes alterações:

O kube-proxy implementa a possibilidade de operação simultânea nos dois modos (IPv4 e IPv6);
o suporte para a API descendente apareceu em Pod.Status.PodIPs (ao mesmo tempo, /etc/hosts agora exigem a adição de um endereço IPv6 para o host);
suporte para duas pilhas no KIND (Kubernetes IN Docker) e no kubeadm ;
Testes e2e atualizados.

Ilustração KIND IPV4 / IPv6 de pilha dupla

Progresso do CSI

O suporte de topologia para repositórios baseados em CSI, apresentado pela primeira vez no K8s 1.12, foi declarado estável .

Iniciativa de plug-ins de volume de migração CSI - Migração CSI - Beta atingido. Esse recurso é crítico para transferir plug - ins existentes na árvore para uma interface moderna (CSI, fora da árvore) despercebida pelos usuários finais do Kubernetes. Será suficiente para os administradores de cluster ativar a Migração CSI, após o qual os recursos e cargas de trabalho com estado existentes ainda "funcionarão" ... mas usando drivers CSI atuais em vez dos drivers desatualizados incluídos no kernel do Kubernetes.

No momento, o status da migração para os drivers do AWS EBS ( kubernetes.io/aws-ebs ) e do GCE PD ( kubernetes.io/gce-pd ) está pronto no status beta. As previsões para outros repositórios são as seguintes:

Como o suporte de armazenamento "tradicional" nos K8s chegou ao CSI, falamos neste artigo . Uma transição para a migração de CSI no status beta é dedicada a uma publicação separada no blog do projeto.

Além disso, o status da versão beta (ou seja, a inclusão por padrão) no Kubernetes 1.17 foi atingido por outra funcionalidade significativa no contexto do CSI, originada em (implementação alfa) no K8s 1.12 - criando instantâneos e restaurando-os . Entre as alterações feitas no Kubernetes Volume Snapshot no caminho para a versão beta:

divida o snapshotter externo do CSI do side-car em dois controladores,
segredo de exclusão adicionado como uma anotação para o conteúdo do instantâneo do volume,
Um novo finalizador para impedir a remoção do objeto da API de captura instantânea, se houver alguma conexão restante.

No momento da liberação 1.17, o recurso era suportado por três drivers CSI: Driver CSI de Disco Persistente GCE, Driver Portworx CSI e Driver NetApp Trident CSI. Você pode ler mais sobre sua implementação e uso nesta postagem do blog.

Etiquetas do provedor de nuvem

Os rótulos atribuídos automaticamente aos nós e volumes criados, dependendo do provedor de nuvem usado , estão disponíveis no Kubernetes como beta há muito tempo - começando com o lançamento do K8s 1.2 (abril de 2016!) . Dado seu uso disseminado por tanto tempo, os desenvolvedores decidiram que era hora de declarar o recurso estável (GA).

Portanto, todos foram renomeados de acordo (por topologia):

beta.kubernetes.io/instance-type → node.kubernetes.io/instance-type
failure-domain.beta.kubernetes.io/zone → topology.kubernetes.io/zone
failure-domain.beta.kubernetes.io/region → topology.kubernetes.io/region

... mas ainda disponível pelos nomes antigos (para compatibilidade com versões anteriores). No entanto, todos os administradores são incentivados a mudar para os rótulos atuais. A documentação relevante do K8s foi atualizada.

Kubeadm de saída estruturada

No formato alfa, a saída estruturada para o utilitário kubeadm é apresentada pela primeira vez. Formatos suportados: JSON, YAML, Go-template.

A motivação para implementar esse recurso (de acordo com o KEP ) é a seguinte:

Embora o Kubernetes possa ser implantado manualmente, o padrão de fato (se não for de direito) desta operação é usar o kubeadm. Ferramentas populares de gerenciamento de sistemas, como o Terraform, contam com o kubeadm para a implantação do Kubernetes. Os aprimoramentos agendados para a API de cluster incluem um pacote de composição para inicialização do Kubernetes com kubeadm e cloud-init.

Sem saída estruturada, mesmo as alterações mais inócuas à primeira vista podem quebrar o Terraform, a API do Cluster e outros softwares que usam os resultados do kubeadm.

Num futuro próximo, o suporte aparecerá (na forma de saída estruturada) para os seguintes comandos do kubeadm:

alpha certs
config images list
init
token create
token list
upgrade plan
version

Ilustração da resposta JSON ao comando kubeadm init -o json :

 { "node0": "192.168.20.51:443", "caCrt": "sha256:1f40ff4bd1b854fb4a5cf5d2f38267a5ce5f89e34d34b0f62bf335d74eef91a3", "token": { "id": "5ndzuu.ngie1sxkgielfpb1", "ttl": "23h", "expires": "2019-05-08T18:58:07Z", "usages": [ "authentication", "signing" ], "description": "The default bootstrap token generated by 'kubeadm init'.", "extraGroups": [ "system:bootstrappers:kubeadm:default-node-token" ] }, "raw": "Rm9yIHRoZSBhY3R1YWwgb3V0cHV0IG9mIHRoZSAia3ViZWFkbSBpbml0IiBjb21tYW5kLCBwbGVhc2Ugc2VlIGh0dHBzOi8vZ2lzdC5naXRodWIuY29tL2FrdXR6LzdhNjg2ZGU1N2JmNDMzZjkyZjcxYjZmYjc3ZDRkOWJhI2ZpbGUta3ViZWFkbS1pbml0LW91dHB1dC1sb2c=" }

Estabilização de outras inovações

Em geral, o lançamento do Kubernetes 1.17 foi realizado sob o lema " Estabilidade ". Isso foi facilitado pelo fato de que muitos recursos nele (seu número total é 14 ) receberam o status de GA. Entre aqueles:

Nós de “marcação” sob certas condições ( TaintNodesByCondition ), que apareceram no K8s 1.8 ;
Watch Bookmarks - um novo tipo de eventos com um rótulo em que todos os objetos até uma determinada versão ( resourceVersion ) já foram processados pelo watch;
valores padrão para recursos personalizados;
compartilhado entre contêineres nos espaços para nome do processo do pod;
ScheduleDaemonSetPods - agendar pods no DaemonSet usando o kube-scheduler (em vez do controlador DaemonSet);
limites dinâmicos no número de volumes, dependendo do tipo de nó;
suporte para variáveis de ambiente para nomes de diretório montados como subPath ;
portando pulsações do Kubelet para uma API de concessão especializada;
“ Proteção do Finalizador ” para balanceadores de carga (verificando os recursos de Serviço correspondentes antes de excluir os recursos do LoadBalancer);
a otimização do desempenho do kube-apiserver ao trabalhar com vários relógios que monitoram conjuntos idênticos de objetos é obtida evitando a serialização repetida dos mesmos objetos para cada observador.

Outras mudanças

A lista completa de inovações no Kubernetes 1.17, é claro, não se limita às listadas acima. Aqui estão alguns outros (e para uma lista mais completa - consulte CHANGELOG ):

A versão beta do RunAsUserName for Windows apresentada na versão anterior cresceu para a versão beta;
uma mudança semelhante aconteceu com a API EndpointSlice (também do K8s 1.16), mas até agora esta solução para melhorar o desempenho / escalabilidade da API do Endpoint não foi ativada por padrão;
os pods críticos para a operação do cluster agora podem ser criados, não apenas nos namespaces do kube-system (consulte a documentação para o consumo da classe de prioridade limite para obter detalhes) ;
uma nova opção para o kubelet - --reserved --reserved-cpus - permite definir explicitamente uma lista de CPUs reservadas para o sistema;
para kubectl logs um novo sinalizador é apresentado - prefixo, adicionando o nome do pod e o contêiner de origem a cada linha do log;
no label.Selector adicionado label.Selector ;
todos os contêineres no kube-dns agora são executados com menos privilégios;
o hyperkube é alocado para um repositório GitHub separado e não será mais incluído nas versões do Kubernetes;
aprimorou significativamente o desempenho do proxy kube para portas não UDP.

Alterações de dependência:

Versão CoreDNS no kubeadm - 1.6.5;
versão crictl atualizada para v1.16.1;
CSI 1.2.0;
etcd 3.4.3;
A versão mais recente verificada do Docker foi atualizada para 03.19
a versão Go mínima necessária para compilar o Kubernetes 1.17 é 1.13.4.

Kubernetes 1.17: Visão geral das principais inovações