Esta noite próxima versão do Kubernetes - . Seguindo a tradição que se desenvolveu em nosso blog, estamos falando das principais mudanças na nova versão deste maravilhoso produto Open Source.
As informações utilizadas para preparar este material foram retiradas de , e questões relacionadas, solicitações pull, propostas de melhoria do Kubernetes (KEP).
Vamos começar com uma introdução importante do ciclo de vida do cluster SIG: clusters de failover dinâmico Kubernetes (ou, para ser mais preciso, implantações de HA auto-hospedadas) agora está usando comandos familiares (no contexto de clusters de nó único) kubeadm (init и join). Resumindo, para isso:
- os certificados usados pelo cluster são transferidos para segredos;
- pela possibilidade de usar o cluster etcd dentro do cluster K8s (ou seja, livrar-se da dependência externa existente anteriormente) ;
- Documenta as configurações recomendadas para um balanceador de carga externo que fornece uma configuração tolerante a falhas (no futuro está planejado eliminar essa dependência, mas não neste estágio).
Arquitetura de um cluster Kubernetes HA criado com kubeadm
Detalhes da implementação podem ser encontrados em . Esse recurso era realmente muito aguardado: a versão alfa era esperada no K8s 1.9, mas só apareceu agora.
API
Equipe apply e geralmente gerenciamento de objetos declarativos de kubectl no apiserver. Os próprios desenvolvedores explicam brevemente sua decisão dizendo que kubectl apply - parte fundamental do trabalho com configurações no Kubernetes, porém “é cheio de bugs e difícil de consertar” e, portanto, essa funcionalidade precisa ser normalizada e transferida para o plano de controle. Exemplos simples e claros de problemas que existem hoje:
Detalhes sobre a implementação estão em . A prontidão atual é alfa (a promoção para beta está planejada para o próximo lançamento do Kubernetes).
Disponibilizado em versão alfa usando o esquema OpenAPI v3 para criando e publicando documentação OpenAPI para CustomResources (CR) usado para validar recursos definidos pelo usuário K8s (lado do servidor) (CustomResourceDefinition, CRD). Publicar OpenAPI para CRD permite que clientes (por exemplo kubectl) realizar a validação do seu lado (dentro kubectl create и kubectl apply) e emitir documentação de acordo com o esquema (kubectl explain). Detalhes - em .
Registros pré-existentes com bandeira O_APPEND (e não O_TRUNC) para evitar a perda de logs em algumas situações e para a conveniência de truncar logs com utilitários externos para rotação.
Ainda no contexto da API Kubernetes, pode-se notar que em PodSandbox и PodSandboxStatus campo runtime_handler para registrar informações sobre RuntimeClass no pod (leia mais sobre isso no texto sobre , onde esta classe apareceu como uma versão alfa) e em Admission Webhooks capacidade de determinar quais versões AdmissionReview eles apoiam. Por fim, as regras dos Webhooks de admissão agora são a extensão de seu uso por namespaces e estruturas de cluster.
Armazenamento
, que tinha status beta desde o lançamento , estável (GA): este recurso não está mais desabilitado e será removido no Kubernetes 1.17.
usando variáveis de ambiente chamadas (por exemplo, o nome do pod) para os nomes dos diretórios montados como , foi desenvolvido - na forma de um novo campo subPathExpr, que agora é usado para determinar o nome do diretório desejado. O recurso apareceu inicialmente no Kubernetes 1.11, mas no 1.14 ele permaneceu no status de versão alfa.
Tal como acontece com a versão anterior do Kubernetes, muitas mudanças significativas são introduzidas para o CSI (Container Storage Interface) em desenvolvimento ativo:
CSI
Tornou-se disponível (como parte da versão alfa) redimensionamento para volumes CSI. Para usá-lo você precisará habilitar o feature gate chamado ExpandCSIVolumes, bem como a presença de suporte para esta operação em driver CSI específico.
Outro recurso do CSI na versão alfa - consulte diretamente (ou seja, sem usar PV/PVC) aos volumes CSI dentro da especificação do pod. Esse remove a restrição ao uso de CSI como armazenamento exclusivamente remoto de dados, abrindo portas para o mundo para eles . Para uso () deve estar habilitado CSIInlineVolume portão de recurso.
Também houve progresso nos “internos” do Kubernetes relacionados ao CSI, que não são tão visíveis para os usuários finais (administradores de sistema)... Atualmente, os desenvolvedores são forçados a suportar duas versões de cada plugin de armazenamento: uma - “no maneira antiga”, dentro da base de código K8s (in -tree), e a segunda - como parte do novo CSI (leia mais sobre isso, por exemplo, em ). Isto causa inconvenientes compreensíveis que precisam ser resolvidos à medida que o próprio CSI se estabiliza. Não é possível simplesmente descontinuar a API de plug-ins internos (na árvore) devido a .
Tudo isso levou ao fato de que a versão alfa atingiu código do plugin interno, implementado como in-tree, em plugins CSI, graças ao qual as preocupações dos desenvolvedores serão reduzidas a suportar uma versão de seus plugins, e a compatibilidade com APIs antigas permanecerá e elas poderão ser declaradas obsoletas no cenário usual. Espera-se que até a próxima versão do Kubernetes (1.15) todos os plugins do provedor de nuvem sejam migrados, a implementação receba status beta e seja ativada nas instalações do K8s por padrão. Para obter detalhes, consulte . Essa migração também resultou em dos limites de volume definidos por provedores de nuvem específicos (AWS, Azure, GCE, Cinder).
Além disso, suporte para dispositivos de bloco com CSI (CSIBlockVolume) para a versão beta.
Nós/Kubelet
Versão alfa apresentada em Kubelet, projetado para retornar métricas sobre recursos-chave. De modo geral, se anteriormente o Kubelet recebia estatísticas sobre o uso de contêineres do cAdvisor, agora esses dados vêm do ambiente de execução do contêiner via CRI (Container Runtime Interface), mas a compatibilidade para trabalhar com versões mais antigas do Docker também é preservada. Anteriormente, as estatísticas coletadas no Kubelet eram enviadas por meio da API REST, mas agora um endpoint localizado em /metrics/resource/v1alpha1. Estratégia de longo prazo dos desenvolvedores é minimizar o conjunto de métricas fornecido pelo Kubelet. A propósito, essas próprias métricas não “métricas principais”, mas “métricas de recursos”, e são descritas como “recursos de primeira classe, como CPU e memória”.
Uma nuance muito interessante: apesar da clara vantagem de desempenho do endpoint gRPC em comparação com vários casos de uso do formato Prometheus (veja o resultado de um dos benchmarks abaixo), os autores preferiram o formato de texto do Prometheus devido à clara liderança desse sistema de monitoramento na comunidade.
“O gRPC não é compatível com os principais pipelines de monitoramento. O Endpoint só será útil para entregar métricas ao Metrics Server ou monitorar componentes que se integram diretamente a ele. Desempenho do formato de texto do Prometheus ao usar cache no Metrics Server bom o bastante para preferirmos o Prometheus ao gRPC, dada a ampla adoção do Prometheus na comunidade. Assim que o formato OpenMetrics se tornar mais estável, seremos capazes de abordar o desempenho do gRPC com um formato baseado em proto.”
Um dos testes comparativos de desempenho do uso dos formatos gRPC e Prometheus no novo endpoint Kubelet para métricas. Mais gráficos e outros detalhes podem ser encontrados em .
Entre outras mudanças:
- Kubelet agora (uma vez) contêineres em um estado desconhecido antes de reiniciar e excluir operações.
- Quando se utiliza o agora para o contêiner de inicialização as mesmas informações de um contêiner normal.
- KubeletGenericName
usageNanoCoresdo provedor de estatísticas CRI e para nós e contêineres no Windows estatísticas da rede. - As informações do sistema operacional e da arquitetura agora são registradas em rótulos
kubernetes.io/osиkubernetes.io/archObjetos de nó (transferidos de beta para GA). - Capacidade de especificar um grupo de usuários do sistema específico para contêineres em um pod (
RunAsGroup, apareceu em ) antes da versão beta (ativada por padrão). - du e find usado no cAdvisor, implementação em Go.
CLI
Em cli-runtime e kubectl -k sinalizador para integração com (aliás, seu desenvolvimento agora é realizado em um repositório separado), ou seja, para processar arquivos YAML adicionais de diretórios especiais de personalização (para obter detalhes sobre como usá-los, consulte ):
Exemplo de uso simples de arquivo (uma aplicação mais complexa de kustomize é possível dentro )
Além disso:
- novo time
kubectl create cronjob, cujo nome fala por si. - В
kubectl logspode agora bandeiras-f(--followpara registros de streaming) e-l(--selectorpara consulta de rótulo). - kubectl copiar arquivos selecionados por curinga.
- Para a equipe
kubectl waitbandeira--allpara selecionar todos os recursos no namespace do tipo de recurso especificado.
Outros
Os seguintes recursos receberam status estável (GA):
- , usado na especificação do pod para definir condições adicionais levadas em consideração na prontidão do pod;
- Suporte para páginas grandes (feature gate chamado );
- ;
- API PriorityClass .
Outras mudanças introduzidas no Kubernetes 1.14:
- A política RBAC padrão não permite mais acesso à API
discoveryиaccess-reviewusuários sem autenticação (não autenticado). - Suporte oficial CoreDNS Somente Linux, portanto, ao usar o kubeadm para implantá-lo (CoreDNS) em um cluster, os nós devem ser executados apenas no Linux (nodeSelectors são usados para esta limitação).
- A configuração padrão do CoreDNS agora é em vez de proxy. Além disso, no CoreDNS readinessProbe, que impede o balanceamento de carga em pods apropriados (não prontos para serviço).
- No kubeadm, nas fases
initouupload-certs, carregue os certificados necessários para conectar o novo plano de controle ao segredo kubeadm-certs (use o sinalizador--experimental-upload-certs). - Uma versão alfa apareceu para instalações do Windows gMSA (Group Managed Service Account) - contas especiais no Active Directory que também podem ser usadas por contêineres.
- Para G.C.E. Criptografia mTLS entre etcd e kube-apiserver.
- Atualizações em software usado/dependente: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, suporte ao Docker 18.09 no kubeadm e a versão mínima suportada da API do Docker agora é 1.26.
PS
Leia também em nosso blog:
- «";
- «";
- «";
- «".
Fonte: habr.com