Kubernetes 1.18: Visão geral das principais inovações

Ontem, 25 de março, o próximo lançamento do Kubernetes - 1.18. De acordo com a tradição do nosso blog, falamos das mudanças mais significativas na nova versão.



As informações utilizadas para preparar este material é retirado do anúncio oficial, as melhorias Kubernetes rastreamento mesa , CHANGELOG-1,18 , comentários de SUSE e Sysdig , bem como questões relacionadas, solicitações de pull, Propostas Kubernetes Enhancement (KEP) ...

O lançamento do Kubernetes 1.18 recebeu seu logotipo oficial, cuja essência é reduzida à comparação do projeto com o Large Hadron Collider. Como o LHC, que foi o resultado do trabalho de milhares de cientistas de todo o mundo, o Kubernetes reuniu milhares de desenvolvedores de centenas de organizações, e todos eles estão trabalhando em uma causa comum: "melhorar a computação em nuvem em todos os aspectos".



Enquanto isso, entusiastas da equipe do SUSE prepararam uma nuvem de palavras com base nas notas de versão para os commits 3412 feitos para o K8s 1.18. E ficou assim:



Agora - sobre o que está por trás dessas palavras, de uma forma mais compreensível para os usuários.

Agendador


A principal inovação aqui - perfila Planejamento (Programação de perfis) . Isso está relacionado ao fato de que quanto mais heterogêneas as cargas de trabalho no cluster se tornam, mais rapidamente surge a necessidade de diferentes abordagens para seu planejamento.

Para resolver esse problema, os autores propõem que o planejador use diferentes configurações atribuídas ao planejador e denominadas perfis. Iniciando, o kube-scheduler verifica todos os perfis disponíveis e os salva no registro. Se não houver perfis na configuração, a opção padrão ( default-scheduler) é selecionada . Depois que os pods estão na fila, o kube-scheduler realiza seu planejamento levando em consideração o agendador selecionado.

Planejamento de políticas Sami com base em um predicado ( PodFitsResources, PodMatchNodeSelector,PodToleratesNodeTaintsetc.) e as prioridades ( SelectorSpreadPriority, InterPodAffinityPriority, MostRequestedPriority, EvenPodsSpreadPriorityetc.). A implementação fornece imediatamente um sistema de plugins para que todos os perfis sejam adicionados por meio de uma estrutura especial.

Estrutura de configuração atual (será alterada em breve):

type KubeSchedulerConfiguration struct {
   ...
   SchedulerName string
   AlgorithmSource SchedulerAlgorithmSource
   HardPodAffinitySymmetricWeight
   Plugins *Plugins
   PluginConfig []PluginConfig
   ...
}

... e um exemplo de configuração:

profiles:
  - schedulerName: 'default-scheduler'
    pluginConfig:
      - name: 'InterPodAffinity'
      - args:
          hadPodAffinityWeight: <value>

No próximo lançamento do K8s, espera-se que o recurso seja traduzido para beta e depois de mais dois - estabilização. Para obter mais informações sobre perfis para o planejador, consulte o KEP apropriado .

Outra inovação que apareceu no status da versão alfa é a regra padrão para distribuição uniforme de pods (Even Pod Spreading) . Atualmente, as regras são definidas PodSpece anexadas aos pods e agora tornou-se possível definir a configuração global no nível do cluster. Os detalhes estão no KEP .

Ao mesmo tempo, o próprio recurso de propagação da topologia de pod (seu portão de recurso - EvenPodsSpread), que permite distribuir pods igualmente em um cluster de várias zonas, foi traduzido para o status beta.

Além disso, foi anunciada a estabilização do despejo baseado em contaminação , projetada para adicionar tensões aos nós quando certas condições ocorrerem. Pela primeira vez, o recurso apareceu no já distante lançamento do K8s 1.8 e recebeu o status beta em 1.13 .

Velocidade de escala personalizada da HPA


Por mais de um ano, um recurso interessante chamado Velocidade de escala configurável para HPA está definhando no forno de aprimoramentos da Kubernetes , ou seja, velocidade de zoom horizontal personalizável. (A propósito, nosso compatriota iniciou seu desenvolvimento .) No novo lançamento, ele foi trazido para o primeiro estágio do uso em massa - ficou disponível na versão alfa.

Como você sabe, o Horizontal Pod Autoscaler (HPA) no Kubernetes dimensiona o número de pods para qualquer recurso que suporte um sub-recursoscalecom base no consumo da CPU ou em outras métricas. Um novo recurso permite controlar a velocidade com que essa escala ocorre e nas duas direções. Até agora, era possível regulá-lo em uma extensão muito limitada (consulte, por exemplo, o parâmetro global para o cluster --horizontal-pod-autoscaler-downscale-stabilization-window).

A principal motivação para introduzir uma velocidade de dimensionamento personalizada é a capacidade de separar as cargas de trabalho do cluster de acordo com sua importância para os negócios, permitindo que um aplicativo (que processa o tráfego mais crítico) tenha uma velocidade máxima de aumento de tamanho e uma velocidade de roll-up baixa (quando uma nova explosão de carga pode ocorrer), e para outros - escalar de acordo com outros critérios (para economizar dinheiro, etc.).

Solução proposta - objeto adicionado para configurações HPAbehavior, permitindo definir regras para controlar o dimensionamento nas duas direções ( scaleUpe scaleDown). Por exemplo, a configuração:

behavior:
  scaleUp:
    policies:
    - type: percent
      value: 900%

... levará ao fato de que o número de pods atualmente em execução aumentará em 900%. Ou seja, se o aplicativo iniciar como um único pod, se for necessário escalar, ele começará a crescer como 1 → 10 → 100 → 1000. Para

outros exemplos e detalhes de implementação, consulte KEP .

Nós


Progresso no suporte a páginas enormes ( KEP total para ficha ): a versão alfa implementou o suporte para essas páginas no nível do contêiner e a capacidade de solicitar páginas de tamanhos diferentes.

Nó Gerenciador de topologia ( o nó Gerenciador de topologia ) , projetado para unificar a abordagem para ajustar a alocação de recursos de hardware para diferentes componentes no Kubernetes, transferidos para o status beta.

O status da versão beta para obter uma idéia do recurso K8s 1.16 PodOverhead , o mecanismo proposto para calcular os custos indiretos.

kubectl


Foi adicionada uma versão alfa do comando kubectl debug ( seu KEP ), que desenvolveu o conceito de " contêineres efêmeros ". Eles foram introduzidos pela primeira vez no K8s 1.16 com o objetivo de simplificar a depuração em pods. Para fazer isso, no pod correto, é lançado um contêiner temporário (ou seja, vivendo por um curto período de tempo) contendo as ferramentas necessárias para a depuração. Como já escrevemos, esse comando é essencialmente idêntico ao plug-in kubectl-debug que existia até o momento ( sua revisão ).

Ilustração do trabalho kubectl debug:

% kubectl help debug
Execute a container in a pod.

Examples:
  # Start an interactive debugging session with a debian image
  kubectl debug mypod --image=debian

  # Run a debugging session in the same namespace as target container 'myapp'
  # (Useful for debugging other containers when shareProcessNamespace is false)
  kubectl debug mypod --target=myapp

Options:
  -a, --attach=true: Automatically attach to container once created
  -c, --container='': Container name.
  -i, --stdin=true: Pass stdin to the container
  --image='': Required. Container image to use for debug container.
  --target='': Target processes in this container name.
  -t, --tty=true: Stdin is a TTY

Usage:
  kubectl debug (POD | TYPE/NAME) [-c CONTAINER] [flags] -- COMMAND [args...] [options]

Use "kubectl options" for a list of global command-line options (applies to all commands).

Outra equipe, o kubectl diff , que apareceu pela primeira vez no K8s 1.9 e recebeu o status beta em 1.13, é finalmente declarado estável. Como o nome indica, ele permite comparar configurações de cluster. Na ocasião dos recursos de estabilização, ela apareceu no KEP e foi atualizada com toda a documentação relevante do site Kubernetes.

Além disso, a bandeira kubectl --dry prazo adicionado suporte para diferentes valores de ( client, server, none), que permite que você tentar executar o comando apenas no lado do cliente ou servidor. Por sua implementação no lado do servidor, suporte implementado para grandes equipes create, incluindo ,apply, patchE outros.

Redes


O recurso do Ingress começou a passar do grupo API ( extensions.v1beta1) atual networking.v1beta1para, seguido pela estabilização na exibição v1. Uma série de mudanças ( KEP ) está planejada para isso . No momento - como parte da versão beta do K8s 1.18 - o Ingress recebeu duas inovações significativas :

  • um novo campo pathTypeque permite determinar por qual princípio o caminho será comparado ( Exact, Prefixou ImplementationSpecific; o último comportamento é determinado em IngressClass);
  • um novo recurso IngressClasse um novo campo (imutável) Classna definição IngressSpecque indica qual controlador implementa o recurso do Ingress. Essas alterações substituem a anotação kubernetes.io/ingress.class, cujo uso será descontinuado.

Para muitos recursos de rede, o status de disponibilidade foi aumentado:

  • o plugin NodeLocal DNS Cache se tornou estável , o que melhora o desempenho do DNS usando um agente para o cache DNS nos nós do cluster;
  • estável e declarado um campo AppProtocolque define o protocolo do aplicativo para cada porta de serviço (recursos ServicePorte EndpointPort);
  • O suporte ao IPv6 é reconhecido como estável o suficiente para convertê-lo em uma versão beta;
  • Por padrão, a API EndpointSlices agora está ativada (como parte da versão beta) , agindo como uma substituição mais escalável e expansível para os Endpoints comuns.

Instalações de armazenamento


A versão alfa fornece a base para a criação de volumes com os dados pré-carregados neles - Generic Data Populators ( KEP ). Como implementação, propõe-se enfraquecer a validação de campo DataSourcepara que objetos de tipos arbitrários possam ser fontes de dados.

Antes de montar o volume no contêiner, os direitos de todos os seus arquivos são alterados de acordo com o valor fsGroup. Essa operação pode interromper o trabalho de alguns aplicativos (por exemplo, DBMSs populares) e também levar muito tempo (para grandes volumes - mais de 1 TB). O novo campoPermissionChangePolicy para PersistentVolumeClaimVolumeSource permite determinar se você deseja alterar o proprietário para o conteúdo do volume. A implementação atual é uma versão alfa, os detalhes estão emKEP .

Para objetos Secrets, ConfigMaps um novo campo foi immutableadicionado , tornando-os imutáveis. Como regra, esses objetos são usados ​​em pods como arquivos. Quaisquer alterações nesses arquivos rapidamente (após cerca de um minuto) se aplicam a todos os pods que montaram os arquivos. Portanto, uma atualização malsucedida de um segredo ou do ConfigMap pode levar à falha de todo o aplicativo.

Os autores do recurso afirmam que, mesmo no caso de atualizar os aplicativos com o método recomendado - por meio de atualizações contínuas -, podem ocorrer falhas causadas por atualizações sem êxito dos segredos existentes / ConfigMaps. Além disso, o processo de atualização desses objetos nos pods em execução é complicado em termos de desempenho e escalabilidade (cada kubelet é forçado a monitorar constantemente cada segredo / CM exclusivo).

Na implementação atual, é feita para que, após o recurso ser marcado como imutável, essa alteração não possa ser revertida. Você precisará não apenas excluir o objeto e criá-lo novamente, mas também recriar os pods que usam o segredo remoto. Versão - alfa, detalhes - KEP .

Estável declarado:


Outras mudanças


Entre outras inovações no Kubernetes 1.18 (para uma lista mais completa, consulte CHANGELOG ) :

  • JWT- Kubernetes service accounts (KSA) Kubernetes API. - . API- discovery-, OIDC (OpenID Connect) . OIDC (.. K8s-) KCA-, API-. — KEP.
  • - Priority and Fairness API (KEP) — API- ( max-in-flight). . ( FlowSchema) ( RequestPriority). kubectl:

    kind: RequestPriority
    meta:
      name: workload-high
    spec:
      assuredConcurrencyShares: 30
      queues: 128
      handSize: 6
      queueLengthLimit: 100
    
    kind: FlowSchema
    meta:
      name: workload-high
    spec:
      requestPriority:
        name: workload-high
      flowDistinguisher:
        source: namespace
        # no transformation in this case
      match:
      - and: # users using kubectl
        - notPatternMatch:
          field: user
          pattern: system:serviceaccount:.*
  • CertificateSigningRequest API, x509- Certificate Authority. K8s 1.4 - 1.6.
  • Várias melhorias significativas no trabalho com o Windows: suporte a CRI-ContainerD (versão alfa), implementação RuntimeClass (versão alfa), suporte a driver CSI via proxy CSI (versão alfa), versões estáveis ​​do suporte GMSA (conta de serviço gerenciado por grupo) e RunAsUserName .

Alterações de dependência:

  • Versão CoreDNS no kubeadm - 1.6.7;
  • ferramentas críticas 1.17.0;
  • CNI (Container Networking Interface) 0.8.5, Calico 3.8.4;
  • A versão do Go usada é 1.13.8.

O que está desatualizado?


  • API do servidor não está atendendo a API desatualizada: todos os recursos apps/v1beta1ea extensions/v1beta1necessidade de seguir em frente apps/v1, e prestar atenção ao recurso especial daemonsets, deployments, replicasets, networkpolicies, podsecuritypolicies,
  • o terminal para métricas /metrics/resource/v1alpha1 não é atendido - agora, em vez disso /metrics/resource;
  • todos os geradores de equipe kubectl run removidos, exceto o responsável pela geração do pod.

PS


Leia também no nosso blog:


All Articles