Hoje, quarta-feira, próxima versão do Kubernetes - 1.16. De acordo com a tradição que se desenvolveu para o nosso blog, este é o décimo aniversário em que falamos das mudanças mais significativas na nova versão.
As informações utilizadas para preparar este material foram retiradas de , e questões relacionadas, solicitações pull e propostas de melhoria do Kubernetes (KEP). Então vamos!..
Nós
Um número verdadeiramente grande de inovações notáveis (em status de versão alfa) é apresentado na lateral dos nós do cluster K8s (Kubelet).
Em primeiro lugar, os chamados «» (Contêineres Efêmeros), projetado para simplificar os processos de depuração em pods. O novo mecanismo permite lançar contêineres especiais que começam no namespace de pods existentes e permanecem ativos por um curto período de tempo. Seu objetivo é interagir com outros pods e contêineres para resolver eventuais problemas e depurar. Um novo comando foi implementado para este recurso kubectl debug, semelhante em essência a kubectl exec: apenas em vez de executar um processo em um contêiner (como em exec) ele lança um contêiner em um pod. Por exemplo, este comando conectará um novo contêiner a um pod:
kubectl debug -c debug-shell --image=debian target-pod -- bashDetalhes sobre contêineres efêmeros (e exemplos de seu uso) podem ser encontrados em . A implementação atual (no K8s 1.16) é uma versão alfa, e entre os critérios para sua transferência para uma versão beta está “testar a API Ephemeral Containers para pelo menos 2 versões do [Kubernetes]”.
NB: Em sua essência e até mesmo em seu nome, o recurso lembra um plugin já existente sobre o qual nós . Espera-se que, com o advento dos contêineres efêmeros, o desenvolvimento de um plugin externo separado cesse.
Outra inovação - - projetado para fornecer mecanismo para calcular custos indiretos para pods, que pode variar muito dependendo do tempo de execução usado. Como exemplo, os autores resultam em Kata Containers, que requerem a execução do kernel convidado, agente Kata, sistema init, etc. Quando as despesas gerais se tornam tão grandes, elas não podem ser ignoradas, o que significa que é necessário haver uma maneira de levá-las em consideração para futuras cotas, planejamento, etc. Para implementá-lo em PodSpec campo adicionado Overhead *ResourceList (compara com dados em RuntimeClass, se for usado).
Outra inovação notável é gerenciador de topologia de nó (Gerenciador de topologia de nó), projetado para unificar a abordagem de ajuste fino da alocação de recursos de hardware para vários componentes no Kubernetes. Esta iniciativa é impulsionada pela necessidade crescente de vários sistemas modernos (da área das telecomunicações, aprendizagem automática, serviços financeiros, etc.) para computação paralela de alto desempenho e minimização de atrasos na execução de operações, para as quais utilizam CPU avançada e capacidades de aceleração de hardware. Até agora, tais otimizações no Kubernetes foram alcançadas graças a componentes díspares (gerenciador de CPU, gerenciador de dispositivos, CNI), e agora será adicionada uma única interface interna que unifica a abordagem e simplifica a conexão de novos semelhantes - a chamada topologia- ciente - componentes do lado do Kubelet. Detalhes - em .
Diagrama de Componentes do Gerenciador de Topologia
Próximo recurso - verificando contêineres enquanto eles estão em execução (). Como você sabe, para contêineres que demoram muito para serem lançados, é difícil obter um status atualizado: ou eles são “mortos” antes de realmente começarem a funcionar, ou ficam em um impasse por um longo tempo. Nova verificação (habilitada através do feature gate chamado StartupProbeEnabled) cancela - ou melhor, adia - o efeito de quaisquer outras verificações até o momento em que o pod termina de ser executado. Por esse motivo, o recurso foi originalmente chamado . Para pods que demoram muito para iniciar, você pode pesquisar o estado em intervalos de tempo relativamente curtos.
Além disso, uma melhoria para RuntimeClass está imediatamente disponível em status beta, adicionando suporte para “clusters heterogêneos”. C Agora não é necessário que cada nó tenha suporte para cada RuntimeClass: para pods você pode selecionar um RuntimeClass sem pensar na topologia do cluster. Anteriormente, para conseguir isso - para que os pods terminassem em nós com suporte para tudo o que precisam - era necessário atribuir regras e tolerâncias apropriadas ao NodeSelector. EM Fala sobre exemplos de uso e, claro, detalhes de implementação.
Сеть
Dois recursos de rede significativos que apareceram pela primeira vez (na versão alfa) no Kubernetes 1.16 são:
- pilha de rede dupla - IPv4/IPv6 - e seu “entendimento” correspondente no nível de pods, nós, serviços. Inclui interoperabilidade IPv4 para IPv4 e IPv6 para IPv6 entre pods, de pods para serviços externos, implementações de referência (dentro dos plug-ins Bridge CNI, PTP CNI e Host-Local IPAM), bem como compatibilidade reversa com clusters Kubernetes em execução Somente IPv4 ou IPv6. Os detalhes da implementação estão em .
Um exemplo de exibição de endereços IP de dois tipos (IPv4 e IPv6) na lista de pods:
kube-master# kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE nginx-controller 1/1 Running 0 20m fd00:db8:1::2,192.168.1.3 kube-minion-1 kube-master# - Nova API para Endpoint - . Ele resolve os problemas de desempenho/escalabilidade da API Endpoint existente que afetam vários componentes no plano de controle (apiserver, etcd, endpoints-controller, kube-proxy). A nova API será adicionada ao grupo Discovery API e será capaz de atender dezenas de milhares de endpoints de backend em cada serviço em um cluster composto por milhares de nós. Para fazer isso, cada serviço é mapeado para N objetos
EndpointSlice, cada um dos quais, por padrão, não tem mais de 100 pontos de extremidade (o valor é configurável). A API EndpointSlice também fornecerá oportunidades para seu desenvolvimento futuro: suporte para vários endereços IP para cada pod, novos estados para endpoints (não apenasReadyиNotReady), subconjunto dinâmico para endpoints.
O apresentado na última versão atingiu a versão beta , nomeado service.kubernetes.io/load-balancer-cleanup e anexado a cada serviço com o tipo LoadBalancer. No momento da exclusão de tal serviço, ele impede a exclusão real do recurso até que a “limpeza” de todos os recursos relevantes do balanceador seja concluída.
Máquinas API
O verdadeiro “marco de estabilização” está na área do servidor API Kubernetes e na interação com ele. Isto aconteceu em grande parte graças transferir para status estável aqueles que não precisam de introdução especial (CRD), que tem status beta desde os dias distantes do Kubernetes 1.7 (e isso é junho de 2017!). A mesma estabilização ocorreu nos recursos relacionados:
- com
/statusи/scalepara recursos personalizados; - versões para CRD, baseadas em webhook externo;
- (em K8s 1.15) valores padrão (padrão) e remoção automática de campo (poda) para recursos personalizados;
- usando o esquema OpenAPI v3 para criar e publicar a documentação OpenAPI usada para validar recursos CRD no lado do servidor.
Outro mecanismo que há muito se tornou familiar aos administradores do Kubernetes: - também permaneceu em status beta por muito tempo (desde K8s 1.9) e agora é declarado estável.
Dois outros recursos chegaram à versão beta: и .
E a única inovação significativa na versão alfa foi de SelfLink — um URI especial que representa o objeto especificado e faz parte ObjectMeta и ListMeta (ou seja, parte de qualquer objeto no Kubernetes). Por que eles estão abandonando isso? Motivação de forma simples como a ausência de razões reais (esmagadoras) para que este campo ainda exista. Razões mais formais são otimizar o desempenho (removendo um campo desnecessário) e simplificar o trabalho do generic-apiserver, que é forçado a lidar com tal campo de uma maneira especial (este é o único campo definido logo antes do objeto é serializado). Obsolescência verdadeira (dentro da versão beta) SelfLink acontecerá com o Kubernetes versão 1.20 e final - 1.21.
Armazenamento de dados
O principal trabalho na área de armazenamento, assim como nos lançamentos anteriores, é observado na área . As principais mudanças aqui foram:
- pela primeira vez (em versão alfa) Suporte ao plug-in CSI para nós de trabalho do Windows: a forma atual de trabalhar com armazenamento também substituirá plug-ins in-tree no núcleo do Kubernetes e plug-ins FlexVolume da Microsoft baseados em Powershell;
Esquema para implementação de plug-ins CSI no Kubernetes para Windows - oportunidade , introduzido no K8s 1.12, cresceu para uma versão beta;
- Uma "promoção" semelhante (de alfa para beta) foi alcançada pela capacidade de usar CSI para criar volumes efêmeros locais ().
Introduzido na versão anterior do Kubernetes (usando PVC existente como DataSource para criar novo PVC) também recebeu status beta.
Agendador
Duas mudanças notáveis na programação (ambas em alfa):
- - oportunidade use pods em vez de unidades lógicas de aplicação para “distribuição justa” de cargas (como Deployment e ReplicaSet) e ajustando essa distribuição (como um requisito rígido ou como uma condição flexível, ou seja, prioridade). O recurso expandirá os recursos de distribuição existentes de pods planejados, atualmente limitados por opções
PodAffinityиPodAntiAffinity, proporcionando aos administradores um controle mais preciso nesse assunto, o que significa melhor alta disponibilidade e consumo otimizado de recursos. Detalhes - em . - Usar Política BestFit в Função de prioridade RequestedToCapacityRatio durante o planejamento do pod, o que permitirá aplicar (“embalagem em contêineres”) tanto para recursos básicos (processador, memória) quanto para recursos estendidos (como GPU). Para mais detalhes, consulte .
Agendamento de pods: antes de usar a política de melhor ajuste (diretamente via agendador padrão) e com seu uso (via extensor de agendador)
Além disso, a capacidade de criar seus próprios plug-ins de agendador fora da árvore de desenvolvimento principal do Kubernetes (fora da árvore).
Outras mudanças
Também na versão 1.16 do Kubernetes você pode observar iniciativa para métricas disponíveis em ordem completa, ou mais precisamente, de acordo com para a instrumentação do K8. Eles dependem em grande parte do correspondente . As inconsistências surgiram por vários motivos (por exemplo, algumas métricas foram simplesmente criadas antes do aparecimento das instruções atuais), e os desenvolvedores decidiram que era hora de trazer tudo para um único padrão, “alinhado com o resto do ecossistema Prometheus”. A implementação atual desta iniciativa está em status alfa, que será progressivamente promovida nas versões subsequentes do Kubernetes para beta (1.17) e estável (1.18).
Além disso, podem ser observadas as seguintes alterações:
- Desenvolvimento de suporte do Windows с Utilitários Kubeadm para este sistema operacional (versão alfa),
RunAsUserNamepara contêineres do Windows (versão alfa), Conta de serviço gerenciado de grupo (gMSA) suporta até a versão beta, montar/anexar para volumes do vSphere. - mecanismo de compactação de dados em respostas de API. Anteriormente, era utilizado um filtro HTTP para esses fins, o que impunha uma série de restrições que impediam sua ativação por padrão. "Compactação de solicitação transparente" agora funciona: clientes enviando
Accept-Encoding: gzipno cabeçalho, eles recebem uma resposta compactada por GZIP se seu tamanho exceder 128 KB. Os clientes Go suportam automaticamente a compactação (envio do cabeçalho necessário), portanto, notarão imediatamente uma redução no tráfego. (Pequenas modificações podem ser necessárias para outros idiomas.) - escalonando o HPA de/para zero pods com base em métricas externas. Se você escalar com base em objetos/métricas externas, quando as cargas de trabalho estiverem ociosas, você poderá escalar automaticamente para 0 réplicas para economizar recursos. Este recurso deve ser especialmente útil para casos em que os trabalhadores solicitam recursos de GPU e o número de diferentes tipos de trabalhadores ociosos excede o número de GPUs disponíveis.
- Novo cliente - — para acesso “generalizado” a objetos. Ele foi projetado para recuperar facilmente metadados (ou seja, subseção
metadata) dos recursos do cluster e realizar operações de coleta de lixo e de cota com eles. - Construir Kubernetes sem provedores de nuvem legados (“integrados” na árvore) (versão alfa).
- Para o utilitário kubeadm capacidade experimental (versão alfa) de aplicar patches personalizados durante as operações
init,joinиupgrade. Saiba mais sobre como usar a bandeira--experimental-kustomize, ver em . - Novo endpoint para apiserver - , - permite exportar informações sobre sua prontidão. O servidor API agora também possui um sinalizador
--maximum-startup-sequence-duration, permitindo que você regule suas reinicializações. - Dois recursos do Azure declarado estável: suporte (Zonas de Disponibilidade) e (RG). Além disso, o Azure adicionou:
- AAD e ADFS;
-
service.beta.kubernetes.io/azure-pip-namepara especificar o IP público do balanceador de carga; - definições
LoadBalancerNameиLoadBalancerResourceGroup.
- AWS agora tem para EBS no Windows e Chamadas de API EC2
DescribeInstances. - Kubeadm agora é independente Configuração do CoreDNS ao atualizar a versão do CoreDNS.
- Binários etc. na imagem Docker correspondente executável mundialmente, que permite executar esta imagem sem a necessidade de direitos de root. Além disso, imagem de migração etcd Suporte à versão etcd2.
- В passou a usar distroless como imagem base, melhorou o desempenho e adicionou novos provedores de nuvem (DigitalOcean, Magnum, Packet).
- Atualizações em software usado/dependente: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.
PS
Leia também em nosso blog:
- «";
- «";
- «";
- «".
Fonte: habr.com