ProHoster > Blog > notícias da internet > Lançamento do Kubernetes 1.18, sistema para gerenciamento de cluster de containers isolados

Lançamento do Kubernetes 1.18, sistema para gerenciamento de cluster de containers isolados

publicado lançamento da plataforma de orquestração de contêineres Kubernetes 1.18, que permite gerenciar um cluster de contêineres isolados como um todo e fornece mecanismos para implantação, manutenção e dimensionamento de aplicativos em execução em contêineres. O projeto foi originalmente criado pelo Google, mas depois transferido para um site independente supervisionado pela Linux Foundation. A plataforma se posiciona como uma solução universal desenvolvida pela comunidade, não vinculada a sistemas individuais e capaz de funcionar com qualquer aplicação em qualquer ambiente de nuvem. O código do Kubernetes é escrito em Go e distribuído por licenciado sob Apache 2.0.

Fornece funções para implantação e gerenciamento de infraestrutura, como manutenção de banco de dados DNS, balanceamento de carga,
distribuição de contêineres entre nós do cluster (migração de contêineres dependendo das mudanças nas necessidades de carga e serviço), verificações de integridade no nível do aplicativo, gerenciamento de contas, atualização e escalonamento dinâmico de um cluster em execução, sem interrompê-lo. É possível implantar grupos de containers com operações de atualização e desfazer para todo o grupo de uma só vez, bem como divisão lógica do cluster em partes com divisão de recursos. Há suporte para migração dinâmica de aplicativos, para armazenamento de dados dos quais podem ser utilizados sistemas de armazenamento local e de armazenamento em rede.

A versão 1.18 do Kubernetes inclui 38 alterações e melhorias, das quais 15 foram movidas para o status estável e 11 para o status beta. 12 novas alterações são propostas no status alfa. Ao preparar a nova versão, esforços iguais foram direcionados tanto para refinar diversas funcionalidades quanto para estabilizar capacidades experimentais, bem como adicionar novos desenvolvimentos. Principais mudanças:

  • KubectlGenericName
    • Adicionado por Uma versão alfa do comando "kubectl debug", que permite simplificar a depuração em pods iniciando contêineres efêmeros com ferramentas de depuração.
    • Declarado estável o comando “kubectl diff”, que permite ver o que mudará no cluster se você aplicar o manifesto.
    • Removido todos os geradores do comando "kubectl run", exceto o gerador para executar um único pod.
    • Alterado flag “--dry-run”, dependendo do seu valor (cliente, servidor e nenhum), a execução experimental do comando é realizada no lado cliente ou servidor.
    • código kubectl destacado para um repositório separado. Isso permitiu que o kubectl fosse desacoplado das dependências internas do kubernetes e facilitou a importação de código para projetos de terceiros.
  • Ingresso
    • Iniciado alterando o grupo de API do Ingress para networking.v1beta1.
    • Adicionado novos campos:
      • pathType, que permite especificar como o caminho na solicitação será comparado
      • IngressClassName é um substituto para a anotação kubernetes.io/ingress.class, que foi declarada obsoleta. Este campo especifica o nome do objeto especial InressClass
    • Adicionado um objeto IngressClass, que indica o nome do controlador de ingresso, seus parâmetros adicionais e o sinal de uso por padrão
  • e eficaz
    • Добавлено o campo AppProtocol, no qual você pode especificar qual protocolo o aplicativo usa
    • Traduzido em status beta e habilitado por padrão EndpointSlicesAPI, que é um substituto mais funcional para Endpoints regulares.
  • Сеть
    • apoio O IPv6 foi movido para o status beta.
  • Discos permanentes. A seguinte funcionalidade foi declarada estável:
  • Configuração do aplicativo
    • Para objetos ConfigMap e Secret adicionado novo campo "imutável". Definir o valor do campo como verdadeiro evita a modificação do objeto.
  • Agendador
    • Adicionado por capacidade de criar perfis adicionais para o kube-scheduler. Se antes era necessário executar agendadores separados adicionais para implementar algoritmos de distribuição de pod não padrão, agora é possível criar conjuntos adicionais de configurações para o agendador padrão e especificar seu nome no mesmo campo de pod “.spec.schedulerName”. Status - alfa.
    • Despejo baseado em contaminação declarado estável
  • Escala
    • Adicionado por a capacidade de especificar no HPA manifestar o grau de agressividade ao alterar o número de pods em execução, ou seja, quando a carga aumentar, lançar N vezes mais instâncias de uma vez.
  • KubeletGenericName
    • Gerente de Topologia recebeu status beta. O recurso permite a alocação NUMA, o que evita a degradação do desempenho em sistemas com vários soquetes.
    • Estado beta recebido Função PodOverhead, que permite especificar em RuntimeClass a quantidade adicional de recursos necessários para executar o pod.
    • Expandido suporte para HugePages, em status alfa adicionado isolamento em nível de contêiner e suporte para vários tamanhos de páginas enormes.
    • Excluído endpoint para métricas /metrics/resource/v1alpha1, /metrics/resource é usado em vez disso
  • API
    • Finalmente Removida a capacidade de usar os grupos de API desatualizados apps/v1beta1 e extensions/v1beta1.
    • Aplicação no servidor atualizado para o status beta2. Essa melhoria move a manipulação de objetos do kubectl para o servidor API. Os autores da melhoria afirmam que isto irá corrigir muitos erros existentes que não podem ser corrigidos na situação atual. Eles também adicionaram uma seção “.metadata.ownedFields”, na qual propõem armazenar o histórico de alterações dos objetos, indicando quem, quando e o que exatamente mudou.
    • Anunciado API CertificateSigningRequest estável.
  • Suporte à plataforma Windows.

Fonte: opennet.ru

Adicionar um comentário