A segunda-feira
deveria ocorrer oficialmente
( mas até agora isso não aconteceu ... ATUALIZADO 20/06 : o anúncio apareceu no blog do K8s) O próximo lançamento do
Kubernetes é a
1,15 . De acordo com a tradição que se desenvolveu para o nosso blog, falamos das mudanças mais significativas na nova versão.
As informações usadas para preparar este material são retiradas da
tabela de rastreamento de aprimoramentos do Kubernetes ,
CHANGELOG-1.15 e questões relacionadas, solicitações pull, bem como das Propostas de aprimoramento do Kubernetes (KEP). Desde que a conferência KubeCon em Xangai será realizada na próxima semana, este lançamento teve um ciclo de 11 semanas mais curto (em vez de 12 semanas), o que, no entanto, não afetou significativamente o número de mudanças significativas. Então vamos lá ..
Data warehouses
Introduziu uma
nova API ExecutionHook , que permite executar dinamicamente comandos do usuário em um pod / contêiner ou grupo de pods / contêineres e, com ele, o controlador correspondente (
ExecutionHookController ) que implementa o gerenciamento do ciclo de vida do gancho. A motivação para a aparência desse recurso foi o desejo de fornecer aos usuários a capacidade de criar / excluir snapshots de acordo com a lógica do aplicativo, ou seja, execute qualquer comando específico do aplicativo antes e depois de criar o instantâneo. Supõe-se que esses ganchos também possam ser úteis em outras situações - por exemplo, executando atualizações, depuração, atualização de arquivos de configuração, reiniciando o contêiner, preparando-se para outros eventos como migração de banco de dados. Status atual - versão alfa (com tradução para beta para o próximo lançamento), detalhes - no
KEP .
No armazenamento efêmero , que permite diferenciar pods / contêineres específicos do volume de espaço
compartilhado (armazenamento compartilhado) ,
foi adicionado suporte para cotas do sistema de arquivos. Esse novo mecanismo usa cotas de projeto (cotas de
projeto ) disponíveis no XFS e ext4, fornecendo monitoramento do consumo de recursos e a imposição opcional de limites a eles. Status atual - versão alfa; os planos para versões futuras ainda não foram especificados.
Outro novo recurso introduzido pelo sig-storage é o uso de PVCs existentes como
DataSource para criar novos PVCs. Em outras palavras, esta é uma
implementação da função de clonagem de volume . Os clones devem ser diferenciados dos instantâneos, pois cada clone é um volume novo e "completo": é criado como uma cópia de um existente, mas segue completamente o ciclo de vida dos volumes comuns (diferente dos instantâneos, embora sejam cópias de volumes em um determinado momento, mas não independentes). volumes). Ilustração da oportunidade:
kind: PersistentVolumeClaim apiVersion: v1 metadata: name: pvc-2 namespace: myns spec: capacity: storage: 10Gi dataSource: kind: PersistentVolumeClaim name: pvc-1
Nesse caso, um novo PV / PVC independente ( pvc-2 ) será criado contendo os mesmos dados que no pvc-1 . É indicado que o novo PVC deve ter o mesmo espaço para nome que o original.As limitações existentes são
CLONE_VOLUME apenas pelo provisionador dinâmico e apenas pelos plug-ins CSI (eles devem ter o recurso
CLONE_VOLUME ). Leia mais em
KEP .
Os seguintes recursos "cresceram" para o status da versão beta (e, portanto, a ativação nas instalações padrão do Kubernetes):
- Função de expansão de tamanho de volume persistente "online", ou seja, sem a necessidade de reiniciar o pod usando o PVC apropriado. Pela primeira vez (no status alfa), apareceu no K8s 1.11.
- Suporte para variáveis de ambiente para nomes de diretório montados como
subPath , que foi introduzido pela primeira vez no K8s 1.11 e desenvolvido no passado 1.14.
Mas o processo de migração das partes internas dos plug-ins antigos para repositórios implementados dentro da base de código Kubernetes (na árvore) se arrastou a favor dos plug-ins para a nova interface CSI. Esperava-se que o lançamento da versão 1.15 concluísse a migração de todos os plug-ins dos provedores de nuvem, no entanto, foi
decidido manter o status da versão alfa, pois o recurso depende das APIs introduzidas no K8s 1.15 e até agora implementadas apenas na versão alfa (em particular, estamos falando de melhorias no suporte do Azure: plug-ins de
arquivo e
disco do Azure no csi-translation-lib).
Planejador
Duas inovações notáveis - ambas na forma alfa até agora - estão disponíveis no Kubernetes Scheduler.
A primeira é a
estrutura de agendamento (
Kubernetes Scheduling Framework ), que é um novo conjunto de APIs para plug-ins que ampliam os recursos de um agendador existente. Os plug-ins são criados fora do repositório principal (fora da árvore), mas são incluídos no planejador durante a compilação. Assim, o núcleo funcional do agendador permanece o mais simples e conveniente de oferecer suporte, e recursos adicionais são implementados separadamente, sem as muitas restrições que a
maneira atual de expandir os recursos do agendador "sofreu" com a ajuda dos webhooks.
Na nova estrutura, cada tentativa de agendamento de pod é dividida em dois estágios:
- ciclo de agendamento - onde o nó do pod está selecionado,
- e ligação (ciclo de ligação) - onde a solução selecionada é implementada dentro do cluster.
Em cada um desses estágios (juntos, eles também são chamados de
contexto de agendamento ), existem muitos
pontos de extensão , em cada um dos quais os plug-ins de estrutura podem ser chamados.
(Ciclo de vida para chamar plug-ins na Estrutura de agendamento.)Como parte da versão alfa da estrutura, apenas pontos
Reserve ,
Unreserve e
Prebind são implementados . Leia mais sobre essa inovação massiva na
KEP .
A segunda é a
opção Non-Preempting para PriorityClasses .
As classes prioritárias receberam status estável (GA) na última versão do Kubernetes, o que afetou o planejamento e a seleção de pods: os pods são planejados de acordo com a prioridade e, se o pod não puder ser criado devido à falta de recursos, os pods prioridade mais baixa pode ser excluída para liberar o espaço necessário.
A nova opção -
Preempting , definida como um booleano na estrutura
PriorityClass , significa: se um pod estiver aguardando seu planejamento e tiver
Preempting=false , a criação
não impedirá outros pods. Este campo aparece no
PodSpec durante o processo de
admissão do
pod (semelhante ao valor de
PriorityClass ). Detalhes da implementação estão no
KEP .
API Machinery
Para
CustomResources , são apresentadas melhorias projetadas para implementar os dados armazenados dessa maneira (dentro da estrutura do JSON no CRD), um comportamento que melhor corresponde à API Kubernetes geralmente aceita (para objetos K8s "nativos"):
- exclusão automática de campos não especificados nos esquemas de validação do OpenAPI - para obter detalhes, consulte KEP "Poding for Custom Resources ";
- a capacidade de definir valores padrão para campos nos esquemas de validação do OpenAPI v3, o que é especialmente importante para manter a compatibilidade da API ao adicionar novos campos aos objetos. Para obter detalhes, consulte o KEP "Padrão para recursos personalizados ".
Ambos os recursos foram planejados originalmente para serem incluídos no lançamento do K8s 1.12, mas somente agora eles são apresentados em versões alfa.
As mudanças na DRC não se limitaram a isso:
- Publicar o recurso CRAP OpenAPI - ou seja, a validação CustomResources do lado do servidor (usando o esquema OpenAPI v3) introduzida na última versão do Kubernetes - chegou à versão beta e agora está ativada por padrão;
- O mecanismo de conversão de versão para recursos CRD baseado em webhooks externos também foi convertido para beta.
Outra inovação interessante é chamada de
marcador de relógio . Sua essência se resume a adicionar um novo tipo de evento à
API Watch -
Bookmark . Esse tipo significa um rótulo que todos os objetos até uma certa
resourceVersion já foram processados pelo relógio. Esse mecanismo reduzirá a carga no kube-apiserver, reduzindo o número de eventos que precisam ser processados toda vez que o relógio for reiniciado, além de reduzir o número de erros indesejados, como
"versão do recurso muito antiga" . No Kubernetes 1.15, o recurso tem o status da versão alfa e seu aumento para beta é esperado para a próxima versão.
Added EventType = "ADDED" Modified EventType = "MODIFIED" Deleted EventType = "DELETED" Error EventType = "ERROR" Bookmark EventType = "BOOKMARK"
(Tipos de eventos possíveis na API do Watch.)No Webhooks de Admissão:
- Adicionado suporte para um seletor de objetos , além dos seletores de namespace existentes
- implementou a capacidade de registrar uma versão específica de um recurso e chamar quando qualquer versão mais antiga desse recurso é modificada;
- O campo
Option foi adicionado à API AdmissionReview, opções de relatório para a operação que está sendo executada.
Rede
Uma inovação significativa na parte de rede do Kubernetes é a chamada "
Finalizer Protection" para balanceadores de carga. Agora, antes de excluir os recursos do LoadBalancer, é verificado se o recurso de Serviço correspondente não foi completamente excluído. Para fazer isso, um chamado finalizador é anexado a cada serviço com o
type=LoadBalancer : quando esse serviço é excluído, a exclusão real do recurso é bloqueada até que o finalizador seja excluído e o finalizador não é excluído até que a "eliminação" dos recursos do balanceador de carga correspondente seja concluída (
service.kubernetes.io/load-balancer-cleanup ). A versão atual da implementação é a versão alfa, e detalhes sobre isso podem ser encontrados no
KEP .
Além disso:
- O plug- in NodeLocal DNS Cache introduzido no Kubernetes 1.13 e melhorando o desempenho do DNS chegou à versão beta.
- O Kube-proxy não remove mais automaticamente as regras de rede criadas como resultado de sua operação em outros modos (isso requer o lançamento explícito do
kube-proxy --cleanup ).
CLI
Como sempre, havia algumas pequenas coisas agradáveis nos comandos do console para trabalhar com os clusters do Kubernetes:
Outros
Entre outras mudanças notáveis no Kubernetes 1.15:
- Foi adicionado suporte ao PDB (Pod Disruption Budget) para recursos / controladores baseados em CRD de terceiros (por exemplo: EtcdCluster, MySQLReplicaSet ...) usando o sub- recurso Scale . Até agora, esta é uma versão beta que ficará estável no próximo lançamento. Os detalhes estão no KEP .
- Dois recursos para nós / Kubelet chegaram à versão beta: suporte para plug-ins de monitoramento de dispositivos de terceiros (para remover todo o conhecimento específico do dispositivo do Kubelet, ou seja, fora da árvore) e
SupportNodePidsLimit (isolamento de PIDs do nó para o pods). - O suporte aos módulos Go foi adicionado e ativado por padrão para a base de código do Kubernetes (em vez do modo Godep e GOPATH, que está obsoleto).
- O suporte ao AWS NLB (Network Load Balancer), introduzido pela primeira vez no K8s 1.9, atingiu o nível beta. Em particular, ela conseguiu configurar
accessLogs , encerrar o TLS e LoadBalancerSourceRanges . - Implementou a capacidade de configurar o provedor de nuvem do Azure a partir dos segredos do Kubernetes (para isso, uma nova opção
cloudConfigType foi cloudConfigType , uma das quais pode ser secret ). Além disso, o Kubelet no Azure agora pode funcionar sem a identidade do Azure ( useInstanceMetadata deve estar habilitado para isso). - No ciclo de vida do cluster, a possibilidade de criar clusters de HA usando o kubeadm foi trazida para a versão beta e eles também concluíram a próxima etapa (v1beta2) na reorganização do formato do arquivo de configuração do kubeadm.
- O número de pods no status pendente em diferentes filas é adicionado às métricas do planejador e são adicionadas estatísticas sobre volumes através das métricas de volume kubelet da CSI.
- Atualizações no software usado / dependente: Vá para 1.12.5, cri-tools 1.14.0, etcd 3.3.10 (a versão não foi alterada para o servidor, mas foi atualizada para o cliente) . As versões do CNI, CSI, CoreDNS não foram alteradas (em uma das versões alfa do Kubernetes 1.15, ela foi atualizada para a 1.5.0, mas depois revertida para a 1.3.1) , versões suportadas do Docker.
PS
Leia também em nosso blog: