O Kubernetes -
1.14 será lançado esta noite. De acordo com a tradição que se desenvolveu para o nosso blog, estamos falando de mudanças importantes na nova versão deste maravilhoso produto Open Source.
As informações usadas para preparar este material são retiradas da
tabela de rastreamento de aprimoramentos do Kubernetes ,
CHANGELOG-1.14 e questões relacionadas, solicitações pull, propostas de aprimoramento do Kubernetes (KEP).
ATUALIZAÇÃO (26 de março): O
anúncio oficial do lançamento também apareceu no blog do K8s.
Vamos começar com uma introdução importante do ciclo de vida do cluster SIG:
os clusters de failover dinâmico do Kubernetes (e, mais precisamente, as implantações de HA auto-hospedadas) agora
podem ser criados usando os comandos habituais (no contexto de clusters de nó único)
kubeadm (
init e
join ). Em suma, para isso:
- os certificados usados pelo cluster são transferidos para segredos;
- para a possibilidade de usar o cluster etcd dentro do cluster K8s (isto é, se livrar da dependência externa que existia até agora), o operador etcd é usado ;
- As configurações recomendadas para um balanceador de carga externo que fornece uma configuração tolerante a falhas estão documentadas (no futuro, a possibilidade de falha dessa dependência está planejada, mas não neste estágio).
Arquitetura de cluster Kubernetes HA construída com kubeadmDetalhes da implementação podem ser encontrados na
proposta de design . Esse recurso era muito aguardado: a versão alfa era esperada no K8s 1.9, mas só apareceu agora.
API
O comando
apply e o
gerenciamento de objetos geralmente
declarativo são movidos do
kubectl para o apiserver. Os próprios desenvolvedores explicam brevemente sua decisão dizendo que o
kubectl apply é uma parte fundamental do trabalho com configurações no Kubernetes, no entanto, é "cheio de bugs e difíceis de corrigir" e, portanto, essa funcionalidade precisa ser restaurada ao normal e transferida para o plano de controle. Exemplos simples e ilustrativos dos problemas de hoje:
Detalhes da implementação estão no
KEP . A disponibilidade atual é a versão alfa (a promoção para beta está planejada para a próxima versão do Kubernetes).
Na versão alfa, a
capacidade de usar o esquema OpenAPI v3 para
criar e publicar a documentação do OpenAPI no CustomResources (CR) usado para validar os recursos K8s definidos pelo usuário (no lado do servidor) (CustomResourceDefinition, CRD) ficou disponível. A publicação do OpenAPI for CRD permite que os clientes (por exemplo,
kubectl ) executem a validação do lado deles (como parte do
kubectl create e
kubectl apply ) e emitam a documentação de acordo com o esquema (
kubectl explain ). Os detalhes estão no
KEP .
Os logs preexistentes
agora são abertos com o sinalizador
O_APPEND (em vez de
O_TRUNC ) para evitar a perda de logs em algumas situações e para a conveniência de truncar logs com utilitários de rotação externos.
Também no contexto da API do Kubernetes, pode-se observar que no campo
PodSandbox e
PodSandboxStatus campo
PodSandboxStatus é
runtime_handler para levar em conta as informações sobre o
RuntimeClass no pod (leia mais sobre isso no texto sobre
o Kubernetes 1.12 , onde essa classe apareceu como uma versão alfa), e em Os Webhooks de Admissão
implementaram a capacidade de determinar quais versões do
AdmissionReview eles suportam. Por fim, nas regras de Webhooks de admissão, agora
você pode limitar o escopo de seu aplicativo ao namespace e ao escopo do cluster.
Instalações de armazenamento
PersistentLocalVolumes que têm status beta desde o lançamento do
K8s 1.10 são
declarados estáveis (GA): esse portão de recurso não será mais desativado e será removido no Kubernetes 1.17.
Foi desenvolvida a capacidade de usar as variáveis de ambiente da chamada
API descendente (por exemplo, o nome do pod) para nomes de diretório montados como
subPath - na forma de um novo campo
subPathExpr , com o qual o nome do diretório desejado agora é determinado. Inicialmente, o recurso apareceu no Kubernetes 1.11, mas no 1.14 ele permaneceu no status da versão alfa.
Como na versão anterior do Kubernetes, muitas alterações significativas são introduzidas para o CSI (Container Storage Interface), em rápida evolução:
CSI
Suporte para redimensionar o suporte para volumes CSI ficou disponível (como parte da versão alfa). Para usá-lo, será necessário ativar o portão de recurso chamado
ExpandCSIVolumes , bem como a presença de suporte para esta operação em um driver CSI específico.
Outro recurso para CSI na versão alfa é a
capacidade de se referir diretamente (ou seja, sem usar PV / PVC) a volumes CSI como parte da especificação do pod. Isso
remove a restrição de usar o CSI como data warehouses exclusivamente remotos , abrindo a porta para eles no mundo dos
volumes efêmeros locais . Para usar (
exemplo da documentação ), você deve ativar o portão de recurso
CSIInlineVolume .
Houve um progresso nos "internos" do Kubernetes relacionados ao CSI, que não são tão perceptíveis para os usuários finais (administradores de sistema) ... No momento, os desenvolvedores são obrigados a oferecer suporte a duas versões de cada plug-in de armazenamento: um "à moda antiga", dentro da base de código do K8s (em -tree) e o segundo - como parte do novo CSI
(leia mais sobre isso, por exemplo, aqui ) . Isso causa um inconveniente compreensível que precisa ser tratado como o CSI, enquanto tal se estabiliza. Simplesmente descontinuar a API descontinuada dos plug-ins em árvore não é possível devido à
política correspondente do Kubernetes .
Tudo isso levou ao fato de que a versão alfa alcançou o
processo de migração do código interno de plug-ins implementados como in-trees para
plug-ins CSI, devido a que as preocupações dos desenvolvedores serão reduzidas ao suporte a uma versão de seus plug-ins, e a compatibilidade com APIs antigas permanecerá e elas podem ser declarar obsoleto como de costume. Espera-se que até a próxima versão do Kubernetes (1.15), todos os plug-ins de provedor de nuvem sejam migrados, a implementação receba o status beta e será ativada nas instalações padrão do K8s. Veja a
proposta de design para detalhes. Essa migração também resultou na
rejeição de restrições para volumes definidos por provedores de nuvem específicos (AWS, Azure, GCE, Cinder).
Além disso, o suporte para dispositivos de bloco CSI (
CSIBlockVolume ) foi
convertido para beta.
Nós / Kubelet
Introduziu uma versão alfa do
novo terminal no Kubelet, projetado para
retornar métricas para os principais recursos . De um modo geral, se o Kubelet costumava obter estatísticas sobre o uso de contêineres do cAdvisor, agora esses dados vêm do tempo de execução do contêiner por meio do CRI (Container Runtime Interface), mas a compatibilidade com versões mais antigas do Docker é preservada. Anteriormente, as estatísticas coletadas no Kubelet eram fornecidas por meio da API REST, mas agora ele usa o terminal localizado em
/metrics/resource/v1alpha1 . A estratégia de longo prazo dos desenvolvedores
é minimizar o conjunto de métricas fornecidas pelo Kubelet.
A propósito, essas métricas em si agora são chamadas não de "métricas principais", mas de "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 no desempenho do ponto de extremidade do gRPC em comparação com os diferentes casos de uso do formato Prometheus
(o resultado de um dos benchmark'ov veja abaixo) , os autores preferiram o formato de texto Prometheus devido à clara liderança desse sistema de monitoramento na comunidade.
“O GRPC não é compatível com os principais pipelines de monitoramento. O terminal será útil apenas para fornecer métricas ao Metrics Server ou monitorar componentes que se integram diretamente a ele. Ao usar o cache no Metrics Server, o desempenho do formato de texto do Prometheus é bom o suficiente para preferirmos o Prometheus ao invés do gRPC, dado o amplo uso do Prometheus na comunidade. Quando o formato OpenMetrics se torna mais estável, podemos nos aproximar do desempenho do gRPC com um formato baseado em proto. ”
Um dos testes de desempenho comparativo usando os formatos gRPC e Prometheus no novo terminal Kubelet para métricas. Mais gráficos e outros detalhes podem ser encontrados no KEP .Entre outras mudanças:
- O Kubelet agora aceita o parâmetro
pid=<number> nas opções --kube-reserved e --kube-reserved , garantindo que o PID especificado seja reservado para todo o sistema ou daemons do sistema Kubernetes, respectivamente. O recurso é ativado quando a porta do recurso é ativada, chamada SupportNodePidsLimit . - O Kubelet agora (uma vez) tenta parar os contêineres em um estado desconhecido antes de reiniciar e excluir operações.
- Ao usar o
PodPresets , as mesmas informações são adicionadas ao contêiner init como um contêiner normal. - O Kubelet começou a usar o
usageNanoCores do provedor de estatísticas do CRI, e as estatísticas da rede foram adicionadas para nós e contêineres no Windows. - As informações sobre o sistema operacional e a arquitetura agora são registradas nos
kubernetes.io/arch e kubernetes.io/arch dos objetos Node (transferidos de beta para GA). - A capacidade de especificar um grupo de usuários do sistema específico para contêineres no pod (
RunAsGroup , exibido no K8s 1.11 ) progrediu para a versão beta (ativada por padrão). - du e find utilizados no cAdvisor são substituídos pelas implementações Go.
CLI
O sinalizador -k foi
adicionado ao cli-runtime e ao kubectl para integração com o
kustomize (a propósito, agora está sendo desenvolvido em um repositório separado), ou seja, para processar arquivos YAML adicionais a partir de diretórios especiais de personalização (para obter detalhes sobre seu uso, consulte
KEP ):
Um exemplo de um uso simples do arquivo de personalização ( também é possível um uso mais complicado de kustomize nas sobreposições )Além disso:
- O logotipo do kubectl e sua documentação foram atualizados - consulte kubectl.docs.kubernetes.io .
- Um novo comando
kubectl create cronjob foi kubectl create cronjob , cujo nome fala por si. - Nos
kubectl logs agora você pode combinar os sinalizadores -f ( --follow para logs de streaming) e -l ( --selector para consulta de rótulo). - O kubectl ensinou a copiar arquivos selecionados com um curinga.
- O sinalizador
--all foi adicionado ao comando kubectl wait para selecionar todos os recursos no espaço para nome do tipo de recurso especificado. - Mecanismo de plugin estável declarado para o kubectl .
Outros
O status Estável (GA) recebeu os seguintes recursos:
- Suporte para nós do Windows (incluindo o Windows Server 2019), o que implica a possibilidade de planejar contêineres do Windows Server no Kubernetes (consulte também KEP );
ReadinessGate usado na especificação do pod para determinar condições adicionais que são consideradas na prontidão do pod;- Suporte para páginas grandes (porta de recurso chamada
HugePages ); - CustomPodDNS ;
- API PriorityClass, Pod Priority & Preemption .
Outras alterações introduzidas no Kubernetes 1.14:
- A política RBAC padrão não fornece mais acesso à API de
discovery e access-review a usuários não autenticados. - O suporte oficial ao CoreDNS é fornecido apenas para Linux; portanto, ao usar o kubeadm para sua implantação (CoreDNS) em um cluster, os nós devem funcionar apenas no Linux (nodeSelectors são usados para essa limitação).
- A configuração padrão do CoreDNS agora usa o plug-in de encaminhamento em vez do proxy. Além disso, o readinessProbe foi adicionado ao CoreDNS, o que impede o balanceamento de carga nos pods correspondentes (não prontos para o serviço).
- No kubeadm, nas
upload-certs init ou upload-certs , tornou-se possível fazer o upload dos certificados necessários para conectar o novo plano de controle ao segredo kubeadm-certs (o --experimental-upload-certs é usado). - Para instalações do Windows, uma versão alfa do suporte para gMSA (conta de serviço gerenciado por grupo) - contas especiais no Active Directory, que podem ser usadas por contêineres, apareceu.
- Para o GCE , a criptografia mTLS foi ativada entre o etcd e o kube-apiserver.
- Atualizações no software usado / dependente: Vá para 1.12.1, CSI 1.1, CoreDNS 1.3.1, suporte para Docker 18.09 no kubeadm e a versão mínima suportada da API do Docker era 1.26.
PS
Leia também em nosso blog: