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

Ontem, 9 de dezembro, aconteceu próxima versão do Kubernetes - 1.17. Seguindo a tradição que se desenvolveu em nosso blog, falamos sobre as mudanças mais significativas na nova versão.

As informações utilizadas na elaboração deste material foram retiradas do edital oficial, Tabelas de rastreamento de melhorias do Kubernetes, LOGOTIPO DE ALTERAÇÕES-1.17 e questões relacionadas, solicitações pull e propostas de melhoria do Kubernetes (KEP). Quais as novidades?..

Roteamento com reconhecimento de topologia

A comunidade Kubernetes espera por esse recurso há muito tempo - Roteamento de serviço com reconhecimento de topologia. Se KEP tem origem em outubro de 2018, e o oficial aprimoramento — 2 anos atrás, os problemas habituais (como ele) - e mais alguns anos mais velho...

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

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

Exemplos de uso deste recurso:

economia de tráfego em instalações em nuvem com múltiplas zonas de disponibilidade (multi-AZ) - consulte. ilustração fresca usando o exemplo de tráfego da mesma região, mas AZs diferentes na AWS;
menor latência de desempenho/melhor rendimento;
um serviço fragmentado que possui informações locais sobre o nó em cada fragmento;
colocação do fluentd (ou análogos) no mesmo nó das aplicações cujos logs são coletados;
...

Esse roteamento, que “conhece” a topologia, também é chamado de afinidade de rede - por analogia com afinidade de nó, afinidade/anti-afinidade do pod ou apareceu não faz muito tempo Agendamento de volume com reconhecimento de topologia (e Provisionamento de Volume). Nível atual de implementação ServiceTopology no Kubernetes - versão alfa.

Para obter detalhes sobre como o recurso funciona e como você já pode usá-lo, leia Este artigo de um dos autores.

Suporte a pilha dupla IPv4/IPv6

Progresso significativo fixo em outro recurso de rede: suporte simultâneo para duas pilhas IP, que foi introduzido pela primeira vez em K8s 1.16. Em particular, a nova versão trouxe as seguintes alterações:

em kube-proxy implementado possibilidade de operação simultânea nos dois modos (IPv4 e IPv6);
в Pod.Status.PodIPs apareceu suporte para API descendente (ao mesmo tempo que em /etc/hosts agora eles exigem que o host adicione um endereço IPv6);
suporte de pilha dupla TIPO (Kubernetes IN Docker) e kubeadm;
testes e2e atualizados.

Ilustração usando pilha dupla IPV4/IPv6 em KIND

Progresso em CSI

Declarado estável suporte de topologia para armazenamento baseado em CSI, introduzido pela primeira vez em K8s 1.12.

Iniciativa para migração de plugins de volume para CSI - Migração CSI - alcançou a versão beta. Este recurso é fundamental para traduzir plug-ins de armazenamento existentes (na árvore) para uma interface moderna (CSI, fora da árvore) invisível para os usuários finais do Kubernetes. Os administradores de cluster só precisarão habilitar a migração CSI, após a qual os recursos e cargas de trabalho com estado existentes continuarão a “simplesmente funcionar”... mas usando os drivers CSI mais recentes em vez dos desatualizados incluídos no núcleo do Kubernetes.

No momento, a migração para drivers AWS EBS está pronta em versão beta (kubernetes.io/aws-ebs) e GCE PD (kubernetes.io/gce-pd). As previsões para outras instalações de armazenamento são as seguintes:

Conversamos sobre como o suporte de armazenamento “tradicional” em K8s chegou ao CSI em Este artigo. E a transição da migração do CSI para o status beta é dedicada a publicação separada no blog do projeto.

Além disso, outra funcionalidade significativa no contexto do CSI, que se origina (implementação alfa) no K1.17s 8, atingiu o status beta (ou seja, habilitado por padrão) na versão Kubernetes 1.12 - criando instantâneos e recuperação deles. Entre as alterações feitas no Kubernetes Volume Snapshot no caminho para a versão beta:

dividindo o sidecar do snapshot externo CSI em dois controladores,
adicionado segredo para exclusão (segredo de exclusão) como uma anotação para o conteúdo de um instantâneo de volume,
novo finalizador (finalizador) para evitar que o objeto da API de instantâneo seja excluído se houver conexões restantes.

No momento da versão 1.17, o recurso é compatível com três drivers CSI: driver CSI de disco persistente GCE, driver CSI Portworx e driver CSI NetApp Trident. Mais detalhes sobre sua implementação e uso podem ser encontrados em esta publicação no blog.

Etiquetas do provedor de nuvem

Etiquetas que automaticamente atribuído a nós e volumes criados dependendo do provedor de nuvem usado, estão disponíveis no Kubernetes como uma versão beta há muito tempo - desde o lançamento do K8s 1.2 (abril de 2016!). Dado o seu uso generalizado durante tanto tempo, os desenvolvedores decidiu, que é hora de declarar o recurso estável (GA).

Portanto, todos eles 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 estão disponíveis com seus nomes antigos (para compatibilidade com versões anteriores). No entanto, recomenda-se que todos os administradores mudem para os rótulos atuais. Documentação Relacionada K8s foi atualizado.

Saída estruturada do kubeadm

Apresentado em versão alfa pela primeira vez saída estruturada para o utilitário kubeadm. Formatos suportados: JSON, YAML, modelo Go.

Motivação para implementação deste recurso (de acordo com KEP) é:

Embora o Kubernetes possa ser implantado manualmente, o padrão de fato (se não de jure) para esta operação é usar o kubeadm. Ferramentas populares de gerenciamento de sistemas, como o Terraform, contam com o kubeadm para implantação do Kubernetes. As melhorias planejadas para a API Cluster incluem um pacote combinável para inicialização do Kubernetes com kubeadm e cloud-init.

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

Nossos planos imediatos incluem suporte (na forma de saída estruturada) para os seguintes comandos kubeadm:

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

Ilustração de uma resposta JSON a um 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 ocorreu sob o lema “Estabilidade" Isso foi facilitado pelo fato de que muitos recursos nele (seu número total é 14) recebeu o status de GA. Entre eles:

“marcar” nós de acordo com certas condições (TaintNodesByCondition), apareceu em K8s 1.8;
Assistir aos favoritos - um novo tipo de evento que possui um rótulo informando que todos os objetos estão até uma determinada versão (resourceVersion) já foram processados pelo watch;
valores padrão (padrão) para recursos personalizados;
compartilhado entre contêineres nos namespaces do processo do pod;
ScheduleDaemonSetPods - agendando pods no DaemonSet usando kube-scheduler (em vez do controlador DaemonSet);
limites dinâmicos no número de volumes dependendo do tipo de nó;
suporte a variável de ambiente para nomes de diretórios montados como subPath;
Transferência de batimentos cardíacos Kubelet para uma API de Lease especializada;
"proteção do finalizador" (Proteção do finalizador) para balanceadores de carga (verificando os recursos de serviço correspondentes antes de excluir os recursos do LoadBalancer);
otimização kube-apiserver no desempenho ao trabalhar com vários relógios monitorando conjuntos idênticos de objetos - conseguido 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):

O recurso apresentado na última versão chegou à versão beta RunAsUserName para Windows;
mudança semelhante aconteceu API EndpointSlice (também do K8s 1.16), porém por enquanto esta solução para melhorar o desempenho/escalabilidade da API Endpoint não está habilitada por padrão;
pods agora são essenciais para a operação do cluster pode ser criado não apenas em namespaces kube-system (para obter detalhes, consulte a documentação do Limitar o consumo da Classe Prioritária);
nova opção para kubelet - --reserved-cpus — permite definir explicitamente a lista de CPUs reservadas para o sistema;
para kubectl logs apresentado nova bandeira --prefix, adicionando o nome do pod e do contêiner de origem a cada linha do log;
в label.Selector adicionado RequiresExactMatch;
todos os contêineres em kube-dns agora estão correndo com menos privilégios;
hiperkubo separado em um repositório GitHub separado e não será mais incluído nas versões do Kubernetes;
muito performance melhorada kube-proxy para portas não UDP.

Mudanças de dependência:

A versão do CoreDNS incluída no kubeadm é 1.6.5;
versão do crictl atualizada para v1.16.1;
CSI 1.2.0;
etc. 3.4.3;
Última versão testada do Docker atualizada para 19.03;
A versão Go mínima necessária para construir o Kubernetes 1.17 é 1.13.4.

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