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

Ontem, 9 de dezembro, ocorreu a mais recente versão do Kubernetes — 1.17. Como de costume em nosso blog, falamos sobre as mudanças mais significativas nesta nova versão.

Kubernetes 1.17: visão geral das principais novidades

As informações utilizadas para preparar este material foram extraídas do anúncio oficial, tabela de rastreamento de melhorias do Kubernetes, CHANGELOG-1.17 e das questões, pull requests e propostas de melhorias do Kubernetes (KEP) correspondentes. Então, o que há de novo?..

Roteamento ciente da topologia

A comunidade do Kubernetes aguardava há bastante tempo por esse recurso — Roteamento de serviço ciente da topologia. Se KEP ele teve início em outubro de 2018, e a melhoria oficial — há 2 anos, mas algumas questões (como — são ainda mais antigas… disso) A ideia geral é permitir a implementação de um roteamento "local" para serviços que estão no Kubernetes. "Localidade" nesse caso significa "o mesmo nível topológico"

(topology level) , que pode ser:o mesmo nó para os serviços,

o mesmo rack de servidores,
a mesma região,
o mesmo provedor de nuvem,
Exemplos de uso desse recurso:
…

economia de tráfego em instalações em nuvem com múltiplas zonas de disponibilidade (multi-AZ) — veja.

uma nova ilustração com tráfego de uma região, mas diferentes AZs na AWS; menores latências no desempenho/melhor largura de banda;
serviço shardado, que possui informações locais sobre o nó em cada shard;
execução do fluentd (ou similares) em um nó com aplicativos cujos logs estão sendo coletados;
Esse tipo de roteamento, que "conhece" a topologia, é também chamado de afinidade de rede — semelhante a
…

afinidade de nó afinidade/anti-afindade de pod, ou à recente introdução de Escalonamento de Volume Ciente da Topologia Provisionamento de Volume ). O nível atual de implementação (e ServiceTopologyno Kubernetes — é a versão alfa. Para mais detalhes sobre como o recurso funciona e como você já pode utilizá-lo, leia em um dos autores.

Suporte a pilha dupla IPv4/IPv6 este artigo Um progresso significativo

foi registrado

em outro recurso de rede: o suporte simultâneo a dois stacks IP, que foi apresentado pela primeira vez no K8s 1.16. Em particular, a nova versão trouxe as seguintes mudanças: no kube-proxy,a capacidade de operar simultaneamente em ambos os modos (IPv4 e IPv6);

Pod.Status.PodIPs são implementadas suporte a API downward (ao mesmo tempo, agora requer que o host adicione também o endereço IPv6);
em suporte a dois stacks em foi introduzida KIND /etc/hosts (Kubernetes IN Docker) e
testes e2e atualizados. KIND (Kubernetes IN Docker) e kubeadm;
testes e2e atualizados.

Kubernetes 1.17: visão geral das principais novidades
Ilustração uso de pilha dupla IPV4/IPv6 no KIND

Progresso em CSI

Declarado estável suporte a topologias para armazenamento baseado em CSI, apresentado pela primeira vez em K8s 1.12.

Iniciativa para migração de plugins de volumes para CSI — Migração CSI – atingiu a versão beta. Este recurso é crucial para migrar plugins de armazenamento existentes (in-tree) para a interface moderna (CSI, out-of-tree) invisivelmente para os usuários finais do Kubernetes. Os administradores de clusters apenas precisarão ativar a Migração CSI, após o que os recursos stateful existentes e as cargas de trabalho continuarão "funcionando normalmente"… mas agora utilizando drivers CSI atualizados em vez de obsoletos que vêm integrados ao Kubernetes.

Atualmente, na versão beta, a migração para drivers AWS EBS (kubernetes.io/aws-ebs) e GCE PD (kubernetes.io/gce-pd). As previsões para outros armazenamentos são as seguintes:

Kubernetes 1.17: visão geral das principais novidades

Sobre como o suporte "tradicional" ao armazenamento no K8s evoluiu para o CSI, discutimos em este artigo. E a migração do CSI para o status beta é abordada em uma publicação separada no blog do projeto.

Além disso, atingiu o status beta (ou seja, habilitação por padrão) na versão do Kubernetes 1.17 outra funcionalidade significativa no contexto do CSI, que teve sua origem (implementação alfa) no K8s 1.12 – criação de snapshots e restauração a partir deles. Entre as mudanças realizadas no Kubernetes Volume Snapshot rumo ao lançamento beta:

divisão do sidecar CSI external-snapshotter em dois controladores,
adicionado segredo para exclusão (deletion secret) como anotação ao conteúdo do snapshot do volume,
novo finalizador (finalizer) para evitar a exclusão do objeto API do snapshot quando ainda houver vínculos restantes.

No momento do lançamento 1.17, o recurso é suportado por três drivers CSI: GCE Persistent Disk CSI Driver, Portworx CSI Driver e NetApp Trident CSI Driver. Mais detalhes sobre sua implementação e uso podem ser lidos em desta publicação no blog.

Cloud Provider Labels

Rótulos que são automaticamente atribuídos aos nós e volumes criados, dependendo do provedor de nuvem utilizado, estavam disponíveis no Kubernetes como versão beta já há muito tempo – desde o lançamento do K8s 1.2 (abril de 2016!). Considerando seu amplo uso por tanto tempo, os desenvolvedores decidiram, que era hora de declarar o recurso estável (GA).

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

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 sob seus nomes antigos (para compatibilidade). No entanto, todos os administradores são incentivados a migrar para os rótulos atualizados. Documentação correspondente K8s foi atualizado.

Saída estruturada do kubeadm

Apresentado pela primeira vez no formato alpha saída estruturada para a ferramenta kubeadm. Formatos suportados: JSON, YAML, modelo Go.

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

Embora o Kubernetes possa ser implementado manualmente, o padrão de fato (se não de jure) para essa operação é usar o kubeadm. Ferramentas populares de gerenciamento de sistemas como o Terraform confiam no kubeadm para implantar o Kubernetes. Melhorias planejadas na API do Cluster incluem um pacote combinável para bootstrapping do Kubernetes com kubeadm e cloud-init.
Sem uma saída estruturada, até as mudanças mais inofensivas podem quebrar o Terraform, a API do Cluster e outros softwares que utilizam os resultados do kubeadm.

Os próximos planos incluem suporte (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 para o 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": "O token de bootstrap padrão gerado pelo 'kubeadm init'.",
    "extraGroups": [
      "system:bootstrappers:kubeadm:default-node-token"
    ]
  },
  "raw": "Rm9yIHRoZSBhY3R1YWwgb3V0cHV0IG9mIHRoZSAia3ViZWFkbSBpbml0IiBjb21tYW5kLCBwbGVhc2Ugc2VlIGh0dHBzOi8vZ2lzdC5naXRodWIuY29tL2FrdXR6LzdhNjg2ZGU1N2JmNDMzZjkyZjcxYjZmYjc3ZDRkOWJhI2ZpbGUta3ViZWFkbS1pbml0LW91dHB1dC1sb2c="
}

Estabilização de outras inovações

De fato, o lançamento do Kubernetes 1.17 ocorreu sob o lema "Estabilidade"). Isso foi facilitado pelo fato de que muitas funcionalidades nele (totalizando 14) receberam o status GA. Entre elas:

marcação de nós por condições específicas (TaintNodesByCondition), apresentada no K8s 1.8;
Watch Bookmarks — novo tipo de eventos que possuem a etiqueta de que todos os objetos até uma determinada versão (resourceVersion) já foram tratados pelo watch;
valores padrão (defaulting) para Recursos Customizados;
namespaces de processo compartilhados entre contêineres no pod;
ScheduleDaemonSetPods — agendamento de pods em DaemonSet usando o kube-scheduler (em vez do controlador DaemonSet);
limites dinâmicos no número de volumes dependendo do tipo de nó;
suporte a variáveis de ambiente para nomes de diretórios montados como subPath;
transferência de batidas do Kubelet na API Lease especializada;
"proteção de finalizador" (Finalizer Protection) para balanceadores de carga (verificação dos recursos correspondentes do Service antes de remover os recursos do LoadBalancer);
otimização do kube-apiserver na performance ao lidar com múltiplos watches, observando conjuntos idênticos de objetos, — alcançada ao evitar a reserialização dos mesmos objetos para cada watcher.

Outras mudanças

A lista completa de inovações no Kubernetes 1.17, é claro, não se limita ao que foi mencionado acima. Aqui estão algumas outras (para uma lista mais completa — veja. CHANGELOG):

até a versão beta "chegou" a funcionalidade apresentada na versão anterior RunAsUserName para Windows.;
uma alteração semelhante alcançou a API EndpointSlice (também do K8s 1.16), no entanto, essa solução para melhorar a performance/escabilidade da API Endpoint não está ativada por padrão;
pods críticos para o funcionamento do cluster agora podem ser criadas não apenas nos espaços de nomes kube-system (veja os detalhes na documentação sobre Limit Priority Class consumption);
uma nova opção para kubelet — --reserved-cpus — permite definir explicitamente a lista de CPUs reservados para o sistema;
para agora pode apresentado uma nova flag --prefix, que adiciona o nome do pod e do contêiner fonte a cada linha do log;
em label.Selector adicionaram RequiresExactMatch;
todos os contêineres no kube-dns agora são executados com privilégios menores;
hyperkube destacado em um repositório GitHub separado e não será mais incluído nas versões do Kubernetes;
significativamente melhorou a performance do kube-proxy para portas não-UDP.

Mudanças nas dependências:

a versão do CoreDNS incluída no kubeadm é 1.6.5;
a versão do crictl foi atualizada para v1.16.1;
CSI 1.2.0;
etcd 3.4.3;
a versão mais recente testada do Docker foi elevada para 19.03;
a versão mínima do Go exigida para compilar o Kubernetes 1.17 é 1.13.4.

P.S.

Confira também em nosso blog:

Fonte: habr.com