Esta noite mais um lançamento do Kubernetes — . De acordo com a tradição do nosso blog, falamos sobre as principais mudanças na nova versão deste maravilhoso produto Open Source.
As informações usadas para preparar este material foram retiradas de , e dos respectivos issues, pull requests, Propostas de Melhoria do Kubernetes (KEP).
Comecemos com uma introdução importante do SIG cluster-lifecycle: clusters dinâmicos e tolerantes a falhas O Kubernetes (ou, mais precisamente, implantações HA autogeridas) agora com os comandos habituais (no contexto de clusters de um único nó) kubeadm (init e join). Em resumo, para isso:
- os certificados usados pelo cluster são transferidos para os segredos;
- para permitir o uso do etcd dentro do cluster K8s (ou seja, eliminando a dependência externa existente), foi utilizado ;
- as configurações recomendadas para o balanceador de carga externo que fornece uma configuração tolerante a falhas são documentadas (futuramente está prevista a possibilidade de eliminar também essa dependência, mas não neste estágio).
Arquitetura do cluster HA do Kubernetes, criado com kubeadm
Para mais detalhes sobre a implementação, você pode consultar . Este recurso foi realmente esperado: a versão alfa era esperada desde o K8s 1.9, mas surgiu apenas agora.
API
Time apply e, de modo geral, gerenciamento declarativo de objetos do kubectl para o apiserver. Os próprios desenvolvedores explicam sua decisão dizendo que kubectl apply é uma parte fundamental do trabalho com as configurações no Kubernetes, no entanto, "está cheia de bugs e é difícil de corrigir", razão pela qual essa funcionalidade precisa ser aprimorada e transferida para o controle de planeamento. Exemplos simples e ilustrativos dos problemas existentes hoje:
Mais detalhes sobre a implementação estão em . A prontidão atual é a versão alfa (o avanço para beta está planejado para o próximo lançamento do Kubernetes).
A versão alfa agora disponibiliza de usar o esquema OpenAPI v3 para criação e publicação da documentação OpenAPI para CustomResources (CR), usados para validação (no lado do servidor) de recursos K8s definidos pelo usuário (CustomResourceDefinition, CRD). A publicação do OpenAPI para CRD permite que os clientes (por exemplo, kubectl) realizem validação em seu lado (no âmbito de kubectl create e kubectl apply) e gerar documentação com o esquema (kubectl explain). Detalhes — em .
Os logs existentes anteriormente com a flag O_APPEND (e não O_TRUNC) para evitar a perda de logs em certas situações e facilitar o truncamento dos logs por utilitários externos para rotação.
No contexto da API do Kubernetes, também se pode observar que PodSandbox e PodSandboxStatus campo runtime_handler para levar em conta informações sobre RuntimeClass no pod (mais detalhes podem ser encontrados no texto sobre , onde essa classe surgiu como versão alfa), e nos Admission Webhooks a possibilidade de definir quais versões AdmissionReview eles suportam. Finalmente, nas regras dos Admission Webhooks agora o escopo de sua aplicação a namespaces e limites de cluster.
Armazenamentos
, que tinham status de versão beta desde o lançamento , estáveis (GA): esse recurso não será mais desativado e será removido no Kubernetes 1.17.
o uso de variáveis de ambiente do chamado (por exemplo, o nome do pod) para nomes de diretórios montados como , foi aprimorado — na forma de um novo campo subPathExpr, que agora determina o nome do diretório necessário. Inicialmente, esse recurso apareceu no Kubernetes 1.11, mas permaneceu na versão alfa para 1.14.
Como na versão anterior do Kubernetes, muitas mudanças significativas foram apresentadas para o em desenvolvimento ativo CSI (Interface de Armazenamento de Contêiner):
CSI
Agora está disponível (no âmbito da versão alfa) para redimensionamento de volumes CSI.Para usá-lo, será necessário ativar o recurso conhecido como ExpandCSIVolumes, bem como o suporte a essa operação no driver CSI específico.
Mais uma funcionalidade para o CSI na versão alfa — referenciar diretamente (ou seja, sem usar PV/PVC) volumes CSI dentro da especificação dos pods. Isso remove a limitação de usar o CSI exclusivamente como armazenamento de dados remotos, abrindo para eles as portas para o mundo dos Para uso () é necessário ativar o recurso de volume inline CSI .
Houve progresso também nas 'entranhas' do Kubernetes relacionadas ao CSI, que não são tão visíveis para os usuários finais (administradores de sistema)… Neste momento, os desenvolvedores são obrigados a manter duas versões de cada plugin de armazenamento: uma — 'do jeito antigo', dentro do código do K8s (in-tree), e a outra — no novo CSI (para mais detalhes, consulte, por exemplo, o ). Isso causa inconvenientes compreensíveis que precisam ser resolvidos à medida que o CSI se estabiliza. Simplesmente declarar APIs internas (in-tree) obsoletas (deprecated) não é viável devido à .
Tudo isso levou ao fato de que as versões alfa alcançaram do código interno dos plugins, implementados como in-tree, para plugins CSI, reduzindo assim a carga dos desenvolvedores para manter uma única versão de seus plugins, enquanto a compatibilidade com APIs anteriores será mantida, permitindo que sejam declaradas obsoletas de acordo com o cenário padrão. Espera-se que até o próximo lançamento do Kubernetes (1.15) a migração de todos os plugins de provedores de nuvem seja concluída, e a implementação receba status de versão beta e seja ativada em instalações K8s por padrão. Mais detalhes podem ser encontrados em . Uma consequência dessa migração também foi das restrições para volumes definidos por provedores de nuvem específicos (AWS, Azure, GCE, Cinder).
Além disso, o suporte a dispositivos de bloco com CSI (CSIBlockVolume) trazido
à versão beta.
Nós/Kubelet um novo endpoint no Kubelet, destinado afornecer métricas sobre os principais recursos. /metrics/resource/v1alpha1. De um modo geral, enquanto antes o Kubelet recebia estatísticas de uso de contêineres do cAdvisor, agora esses dados são provenientes do ambiente de execução de contêiner através do CRI (Container Runtime Interface), mantendo, no entanto, a compatibilidade com versões antigas do Docker. Anteriormente, as estatísticas coletadas no Kubelet eram fornecidas através da API REST, e agora isso é feito por meio de um endpoint localizado em é minimizar o conjunto de métricas fornecidas pelo Kubelet. Aliás, essas métricas de 'resource metrics', em vez de 'core metrics', e descrevem como 'recursos de primeira classe, como CPU e memória'.
Uma nuance bastante interessante: apesar da clara vantagem de desempenho do endpoint gRPC em comparação com vários casos de uso do formato Prometheus o resultado de um dos benchmarks está abaixo), os autores preferiram o formato de texto do Prometheus devido à clara liderança deste sistema de monitoramento na comunidade.
«gRPC não é compatível com os principais pipelines de monitoramento. O Endpoint será útil apenas para fornecer métricas ao Metrics Server ou componentes de monitoramento que se integram diretamente a ele. Ao usar o cache no Metrics Server, o desempenho do formato de texto Prometheus é bastante bom para nós, preferirmos Prometheus em vez de gRPC, dada a ampla aceitação do Prometheus na comunidade. Quando o formato OpenMetrics se tornar mais estável, poderemos nos aproximar do desempenho do gRPC usando o formato baseado em proto».
Um dos testes comparativos de desempenho entre os formatos gRPC e Prometheus no novo endpoint do Kubelet para métricas. Mais gráficos e outros detalhes podem ser encontrados em .
Entre outras mudanças:
- O Kubelet agora (uma vez) os contêineres em estado desconhecido antes das operações de reinício e exclusão.
- Ao usar agora é adicionado ao init-contêiner Kubelet
- começou a usar
do provedor de estatísticas CRI, e para nós e contêineres no Windowsestatísticas de rede. As informações sobre o sistema operacional e a arquitetura agora são gravadas nos rótulos - kubernetes.io/os
kubernetes.io/archedos objetos Node (transferido da beta para GA).A capacidade de especificar um grupo de usuários do sistema específico para contêineres no pod ( - RunAsGroup
, foi introduzida noK8s 1.11 ) du e find, usados no cAdvisor, - foram substituídos No cli-runtime e kubectl
CLI
foi adicionado kustomize Exemplo de uso simples do arquivo ):
kustomization overlays )
nova comando
- kubectl create cronjob
, cujo nome fala por si.kubectl logs - Em
agora podeser combinado -f--follow(para streaming de logs) e-l--selector(para query de label).aprendemos - kubectl Na equipe
- kubectl wait
foi adicionado um sinalizador--allpara selecionar todos os recursos no namespace do tipo de recurso especificado.Outras
O status estável (GA) foi obtido para os seguintes recursos:
ReadinessGate
- , utilizado na especificação do pod para determinar condições adicionais consideradas na prontidão do pod;
- Suporte a grandes páginas (feature gate chamada );
- ;
- API PriorityClass, .
Outras mudanças apresentadas no Kubernetes 1.14:
- A política RBAC padrão não concede mais acesso à API
discoveryeaccess-reviewpara usuários sem autenticação (unauthenticated). - O suporte oficial ao CoreDNS apenas para Linux, portanto, ao usar kubeadm para a implantação (do CoreDNS) no cluster, os nós devem operar somente no Linux (para essa limitação são utilizados os nodeSelectors).
- A configuração padrão do CoreDNS agora em vez de proxy. Além disso, no CoreDNS readinessProbe, impedindo a distribuição de carga para os respectivos pods (não prontos para serviço).
- No kubeadm, nas fases
initouupload-certs, fazer upload de certificados necessários para conectar o novo control-plane ao segredo kubeadm-certs (o flag utilizado é--experimental-upload-certs). - Para instalações no Windows, uma versão alfa gMSA (Group Managed Service Account) — contas de serviço especiais no Active Directory que podem ser usadas por contêineres.
- Para GCE criptografia mTLS entre etcd e kube-apiserver.
- Atualizações no software utilizado/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 do API do Docker suportada tornou-se 1.26.
P.S.
Confira também em nosso blog:
- «»;
- «»;
- «»;
- «».
Fonte: habr.com
