
As informações usadas para preparar este material são retiradas da tabela de rastreamento de melhorias do Kubernetes , CHANGELOG-1.19 , a visão geral do Sysdig , bem como questões relacionadas, solicitações de pull, Propostas de aprimoramento do Kubernetes (KEP).
Vamos começar com algumas inovações importantes de natureza bastante geral ...
Com o lançamento do Kubernetes 1.19, a "janela de suporte" para as versões do Kubernetes foi aumentada de 9 meses (ou seja, os últimos 3 lançamentos) para 1 ano (ou seja, 4 lançamentos). Por quê?
Descobriu-se que, devido à alta velocidade de desenvolvimento do projeto (lançamentos principais frequentes), os administradores de cluster do Kubernetes não têm tempo para atualizar suas instalações. Os autores do KEP correspondente referem-se a uma pesquisa realizada pelo grupo de trabalho no início do ano passado e mostrou que cerca de um terço dos usuários do Kubernetes estão lidando com versões obsoletas do K8s em execução na produção:

(No momento da pesquisa, a versão atual do Kubernetes era 1.13, ou seja, todos os usuários do K8s 1.9 e 1.10 funcionavam com versões que não eram mais suportadas na época.)
Assim, presume-se que uma extensão de 3 meses do período de suporte para versões do Kubernetes - o lançamento de patches que corrigem problemas encontrados no código - garantirá que mais de 80% dos usuários trabalharão em versões com suporte do K8s (em vez dos 50-60% assumidos no momento )
Outro grande desenvolvimento: um padrão para logs estruturados foi desenvolvido ... O sistema de registro atual no plano de controle não garante uma estrutura única para mensagens e referências de objeto no Kubernetes, o que complica o processamento de tais registros. Para resolver este problema, uma nova estrutura para mensagens em logs é introduzida, para a qual a biblioteca klog foi estendida com novos métodos que fornecem uma interface estruturada para geração de logs, bem como métodos auxiliares para identificar objetos K8s nos logs.
Simultaneamente à migração para o klog v2, é realizada a transição para um novo formato de saída dos logs em JSON , o que simplificará a execução das solicitações aos logs e seu processamento. Para fazer isso, aparece um sinalizador
--logging-format
que, por padrão, usa o formato de texto antigo.
Como o repositório do Kubernetes é enorme e os autoresOs KEPs de Log Estruturado são realistas e concentrarão seus esforços para dar vida a novas ideias nas mensagens mais comuns.
Uma ilustração de registro usando os novos métodos em klog:
klog.InfoS("Pod status updated", "pod", "kubedns", "status", "ready")
I1025 00:15:15.525108 1 controller_utils.go:116] "Pod status updated" pod="kubedns"
klog.InfoS("Pod status updated", "pod", klog.KRef("kube-system", "kubedns"), "status", "ready")
I1025 00:15:15.525108 1 controller_utils.go:116] "Pod status updated" pod="kube-system/kubedns" status="ready"
klog.ErrorS(err, "Failed to update pod status")
E1025 00:15:15.525108 1 controller_utils.go:114] "Failed to update pod status" err="timeout"
Usando o formato JSON:
pod := corev1.Pod{Name: "kubedns", Namespace: "kube-system", ...}
klog.InfoS("Pod status updated", "pod", klog.KObj(pod), "status", "ready")
{
"ts": 1580306777.04728,
"v": 4,
"msg": "Pod status updated",
"pod":{
"name": "nginx-1",
"namespace": "default"
},
"status": "ready"
}
Outra inovação importante (e muito relevante) é o mecanismo para informar sobre APIs obsoletas , implementado imediatamente como uma versão beta (ou seja, ativo em instalações por padrão). Como explicado por os autores, em muitos Kubernetes capacidade constantemente ultrapassada, permanecendo em estados diferentes e com diferentes tempos s perspectivas mi. Manter o controle deles, ler atentamente todas as notas de versão e limpar manualmente as configurações / ajustes, é quase impossível.
Para resolver este problema, agora ao usar a API obsoleta, um cabeçalho é adicionado às suas respostas
Warning
, que é reconhecido no lado do cliente (client-go
) com a possibilidade de diferentes respostas: ignorar, desduplicar, registrar. No utilitário kubectl, eles ensinaram como enviar essas mensagens para stderr, destacar a mensagem no console com cores e também adicionar um sinalizador --warnings-as-errors
com um nome autoexplicativo .
Além disso, métricas especiais foram adicionadas para relatar o uso de APIs obsoletas e anotações de auditoria.
Por fim, os desenvolvedores participaram do avanço dos recursos do Kubernetes a partir da versão beta . Como a experiência do projeto mostrou, alguns novos recursos e mudanças na API ficaram "presos" no status Beta pelo motivo de já estarem automaticamente (por padrão) ativados e não exigirem mais ações dos usuários.
Para evitar que isso aconteça, sugere-se enviará automaticamente para a lista de suspensão de uso os recursos que estão em beta há 6 meses (duas versões) e não atendem a nenhuma destas condições:
- atender aos critérios do GA e serem promovidos ao status estável;
- tem um novo beta que torna obsoleto o beta anterior.
Agora, para as outras mudanças no Kubernetes 1.19, categorizadas por seus respectivos SIGs.
Vaults
Os novos objetos CSIStorageCapacity têm como objetivo melhorar o processo de agendamento para pods que usam volumes CSI: eles não serão hospedados em nós que ficaram sem espaço de armazenamento. Para isso, as informações sobre o espaço em disco disponível serão armazenadas no servidor API e disponibilizadas para os drivers CSI e o planejador. O status de implementação atual é a versão alfa; veja KEP para detalhes .
Outra inovação na versão alfa é a capacidade de definir volumes efêmeros diretamente nas especificações de pod, volumes inline efêmeros genéricos ( KEP) Volumes efêmeros são criados para pods específicos no momento em que são gerados e são excluídos quando saem. Eles poderiam ter sido definidos anteriormente (incluindo diretamente na especificação, ou seja, pelo método inline), mas a abordagem existente, tendo provado a consistência do próprio recurso, não cobriu todos os casos de seu uso.
O novo mecanismo oferece uma API simples para definir volumes efêmeros para qualquer driver com suporte de provisionamento dinâmico (anteriormente, isso exigiria uma modificação do driver). Ele permite que você trabalhe com qualquer volume efêmero (CSI e in-tree, como
EmptyDir
) e também fornece suporte para outro novo recurso (descrito acima) - rastrear o espaço de armazenamento disponível.
Um exemplo de objeto Kubernetes de alto nível usando um novo volume efêmero (inline genérico):
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluentd-elasticsearch
namespace: kube-system
spec:
selector:
matchLabels:
name: fluentd-elasticsearch
template:
metadata:
labels:
name: fluentd-elasticsearch
spec:
containers:
- name: fluentd-elasticsearch
image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
volumeMounts:
- name: varlog
mountPath: /var/log
- name: scratch
mountPath: /scratch
volumes:
- name: varlog
hostPath:
path: /var/log
- name: scratch
ephemeral:
metadata:
labels:
type: fluentd-elasticsearch-volume
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: "scratch-storage-class"
resources:
requests:
storage: 1Gi
Aqui, o controlador DaemonSet cria pods com nomes de visualização
fluentd-elasticsearch-b96sd
, após os quais um PersistentVolumeClaim será adicionado a tal pod fluentd-elasticsearch-b96sd-scratch
.
E o último recurso de armazenamento completamente novo, introduzido como uma versão alfa, é um novo campo
csidriver.spec.SupportsFSGroup
para drivers CSI que indica suporte para permissões baseadas em FSGroup ( KEP ). Motivação: uma mudança de propriedade para um volume CSI é realizada antes de ser montado em um contêiner, mas nem todos os tipos de armazenamento suportam tal operação (por exemplo, NFS), e é por isso que agora pode levar a erros.
Até a versão beta (ou seja, as inclusões padrão):
- CSI- Azure vSphere ( , Kubernetes);
- Secrets ConfigMaps.
/ Kubelet
Seccomp foi declarado estável (GA) . Em particular, esses trabalhos levaram à transição para campos para seccomp na API em vez de anotações declaradas obsoletas (novos Kubelets ignoram anotações) e afetou PodSecurityPolicy .
Um novo campo foi adicionado ao PodSpec
fqdnInHostname
para permitir que você defina o FQDN (Nome de domínio totalmente qualificado) para o host do pod . O objetivo é melhorar o suporte para aplicativos legados no Kubernetes. Veja como os autores explicam suas intenções:
« Unix Linux-, Red Hat CentOS, FQDN- hostname. , , Kubernetes, . ».
O padrão será
false
preservar o comportamento antigo (para Kubernetes). Status do recurso - versão alfa, que deve ser declarada estável na próxima versão (1.20).
Decidiu-se abandonar as métricas do acelerador coletadas por Kubelet . É proposto coletar essas métricas por agentes de monitoramento externos por meio da API PodResources. Essa API foi criada precisamente com o objetivo de remover todas as métricas específicas do dispositivo do repositório principal do Kubernetes, permitindo que os fornecedores as implementem sem fazer alterações no núcleo do Kubernetes. A API PodResources está em beta (feature gate é responsável por ela
KubeletPodResources
) e estará estável em breve. Para a versão atual, o processo de abandono está em status alfa, os detalhes estão em KEP .
De agora em diante, o Kubelet pode ser construído sem o Docker : por isso "sem" os autores significam a ausência de qualquer código específico do Docker e dependência do pacote Golang
docker/docker
. O objetivo final desta iniciativa é chegar a um Kubelet completamente "dockerless" (ou seja, sem dependência Docker). Você pode ler mais sobre motivação, como sempre, no KEP . Esta oportunidade recebeu imediatamente o status de GA.
O Node Topology Manager, que atingiu sua versão beta no último lançamento do K8s, agora tem a capacidade de nivelar recursos no nível do pod.
Agendador
De volta ao Kubernetes 1.18, escrevemos sobre uma configuração global para distribuição uniforme de pod (Even Pod Spreading) , mas então foi decidido adiar esse recurso com base nos resultados do teste de desempenho. Ela agora está no Kubernetes (em status Alfa).
A essência da inovação é a adição de restrições globais (
DefaultConstraints
), que permitem regular as regras de distribuição de pods em um nível superior - no nível do cluster, e não apenas em PodSpec
(através topologySpreadConstraints
), como era até agora. A configuração padrão será semelhante ao plugin atual DefaultPodTopologySpread
:
defaultConstraints:
- maxSkew: 3
topologyKey: "kubernetes.io/hostname"
whenUnsatisfiable: ScheduleAnyway
- maxSkew: 5
topologyKey: "topology.kubernetes.io/zone"
whenUnsatisfiable: ScheduleAnyway
Os detalhes estão no KEP .
Outro recurso relacionado ao Even Pod Spreading: a distribuição de um grupo de pods por domínios de falha (regiões, zonas, nós, etc.), - transferidos de alfa para beta (habilitado por padrão).
Três outros recursos no agendador alcançaram um "aumento" semelhante:
- Perfis de planejamento (Scheduling the Profiles) , apresentados em 1.18;
- opção para ativar / desativar a preempção de pod em PriorityClasses;
- arquivo de configuração kube-scheduler ComponentConfig .
Redes
O recurso Ingress é finalmente declarado estável e tem uma versão
v1
na API. A este respeito, algumas atualizações foram apresentadas na documentação relevante. Deve-se prestar atenção especial às mudanças perceptíveis ao usuário a partir deste PR : por exemplo, existem renomeações como spec.backend
→ spec.defaultBackend
, serviceName
→ service.name
, servicePort
→ service.port.number
...
O campo AppProtocol para Serviços e Endpoints, bem como a API EndpointSlice (kube-proxy no Linux inicia use EndpointSlices por padrão, mas permaneceu em alfa para Windows) e suporte SCTP .
kubeadm
Dois novos recursos (na versão alfa) são introduzidos para o utilitário kubeadm.
O primeiro é usar patches para modificar os manifestos gerados pelo kubeadm. Já era possível modificá-los usando o Kustomize (em alfa), porém os desenvolvedores do kubeadm decidiram que usar patches regulares era a forma preferida (já que o Kustomize se torna uma dependência desnecessária, o que não é bem-vindo).
Agora é possível a aplicação de remendos matérias-(via uma bandeira
--experimental-patches
) para comandos kubeadm init
, join
e upgrade
, assim como as suas fases. A implementação baseada em Kustomize (sinalizador --experimental-kustomize
) será descontinuada e removida.
O segundo recurso é uma nova abordagem para trabalhar com configurações de componentescom o qual o kubeadm funciona. O utilitário gera, valida, define valores padrão, armazena configurações (na forma de ConfigMaps) para componentes de cluster do Kubernetes como Kubelet e kube-proxy. Com o tempo, ficou claro que isso traz uma série de dificuldades: como distinguir entre configurações geradas pelo kubeadm ou enviadas pelo usuário (e se não, o que fazer com a migração de configuração)? Quais campos com valores padrão foram gerados automaticamente e quais foram definidos intencionalmente? ..
Para resolver esses problemas, um grande conjunto de alterações é apresentado , incluindo: recusa em definir valores padrão (isso deve ser feito pelos próprios componentes), a delegação de validação de configuração dos próprios componentes, assinando cada ConfigMap gerado, etc.
E outro recurso menos significativo para o kubeadm é um portão de recurso chamado
PublicKeysECDSA
, que inclui a capacidade de criar um cluster [via kubeadm init
] com certificados ECDSA. A atualização de certificados existentes (via kubeadm alpha certs renew
) também é fornecida, mas não há mecanismos para alternar facilmente entre RSA e ECDSA.
Outras mudanças
- O status GA recebeu 3 recursos no campo de autenticação: API CertificateSigningRequest , restringindo o acesso do nó a certas APIs (por meio de um plugin de admissão
NodeRestriction
), bootstrap e renovação automática do certificado do cliente Kubelet. - A nova API de eventos também foi declarada estável com uma abordagem alterada de desduplicação (para evitar sobrecarregar o cluster com eventos).
- (kube-apiserver, kube-scheduler, etcd )
debian
distroless
. : , ( — KEP). - Kubelet Docker runtime target-,
TargetContainerName
EphemeralContainer ( ). - « »
.status.conditions
, API . - kube-proxy IPv6DualStack Windows ( feature gate).
- A porta de recursos com um nome autoexplicativo
CSIMigrationvSphere
(migração do plug-in integrado - na árvore - para vSphere para o driver CSI) mudou para a versão beta. - Para bandeira
kubectl run
adicionada--privileged
. - Um novo ponto de extensão foi adicionado ao planejador - , - que inicia após a fase .
PostFilter
Filter
- O suporte Cri-containerd no Windows atingiu a versão beta.
Mudanças de dependência:
- versão do CoreDNS incluída no kubeadm - 1.7.0;
- cri-tools 1.18.0;
- CNI (Container Networking Interface) 0.8.6;
- etcd 3.4.9;
- a versão do Go usada é 1.15.0-rc.1.
PS
Leia também em nosso blog: