O Kubernetes 1.18 vem com melhorias para depuração Kubectl, segurança e muito mais

Na semana passada o lançamento da nova versão do a plataforma de orquestração de contêineres Kubernetes 1.18, versão que inclui 38 mudanças e melhorias, dos quais 15 estão em estado estável e 11 estão em estado beta, além de 12 novas mudanças de estado alfa são propostas. Na preparação da nova versão, esforços equitativos foram direcionados tanto para o refinamento de várias funções e para a estabilização das capacidades experimentais, como também para a incorporação de novos desenvolvimentos.

Para quem não está familiarizado com o Kubernetes, você deve saber que esta é uma plataforma de orquestração de contêineres que permite que você gerencie um cluster de contêineres isolados como um todo e fornecem mecanismos para implantar, manter e dimensionar aplicativos que são executados em contêineres.

O projeto foi originalmente criado pelo Google, mas depois foi transferido para uma plataforma separada, com curadoria da 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 aplicativo em qualquer ambiente de nuvem. O código do Kubernetes é escrito em Go e é distribuído sob a licença Apache 2.0.

O que há de novo no Kubernetes 1.18?

Esta nova versão do O Kubernetes vem com várias melhorias para o Kubectl, do qual é mencionado no anúncio que adicionou uma versão alfa do comando "kubectl debug", o que facilita a depuração em pods ao executar contêineres com ferramentas de depuração.

Enquanto o comando "Kubectl diff" foi declarado estável, que permite ver o que mudará no cluster se você aplicar o manifesto.

também todos os geradores de comando "kubectl run" foram removidos, exceto para a inicialização do gerador de pod único, mais o indicador –Dry-run foi alterado, dependendo de seu valor (cliente, servidor e nenhum), a execução de teste do comando é feita no lado do cliente ou servidor.

O código kubectl é atribuído a um repositório separado. Isso nos permitiu separar o kubectl das dependências internas do kubernetes e facilitou a importação de código para projetos de terceiros.

Em relação a mudanças de rede, é de notar que o suporte IPv6 está agora em beta, Clonagem de PVC foi adicionada, a possibilidade de dispositivos brutos de bloqueio de rede como discos permanentes, suporte para bloqueio de dispositivos brutos em CSI, transferência de informações sobre a unidade solicitando a conexão de um disco ao controlador CSI, além de um novo campo "imutável" foi adicionado aos objetos ConfigMap e Secret.

Das outras mudanças que se destacam:

  • A capacidade de usar os aplicativos obsoletos API group / v1beta1 e extensões / v1beta1 foi finalmente removida.
  • ServerSide Apply atualizado para o estado beta2. Esse aprimoramento traz a manipulação de objetos kubectl para o servidor de API.
  • API CertificateSigningRequest declarada estável.
  • Suporte para plataforma Windows.
  • O suporte a nós do Windows continua a se expandir
  • Suporte CRI-ContainerD
  • Implementação de RuntimeClass
  • proxy CSI
  • O suporte transferido está estável
  • Conta de serviço gerenciada por grupo
  • RunAsUserName
  • O Topology Manager recebeu o status beta. O recurso inclui distribuição NUMA, que evita a degradação do desempenho em sistemas com vários soquetes.
  • O status beta foi obtido usando a função PodOverhead, que permite especificar no RuntimeClass a quantidade adicional de recursos necessários para iniciar a casa.
  • Suporte estendido para enormes páginas, status de isolamento alfa adicionado ao contêiner e suporte para tamanhos de páginas grandes de vários níveis.
  • Adicionado campo AppProtocol onde você pode especificar qual protocolo o aplicativo usa
  • Traduzido para o estado beta e ativado por padrão EndpointSlicesAPI, que é uma substituição mais funcional para Endpoints regulares.
  • Um objeto IngressClass foi adicionado, indicando o nome do controlador de entrada, seus parâmetros adicionais e o sinal para usá-lo por padrão.
  • Adicionada a capacidade de especificar no manifesto HPA o grau de agressividade ao alterar o número de domicílios em operação, ou seja, quando a carga aumenta, inicia imediatamente N vezes mais cópias.

Seja o primeiro a comentar

Deixe um comentário

Seu endereço de email não será publicado. Campos obrigatórios são marcados com *

*

*

  1. Responsável pelos dados: Miguel Ángel Gatón
  2. Finalidade dos dados: Controle de SPAM, gerenciamento de comentários.
  3. Legitimação: Seu consentimento
  4. Comunicação de dados: Os dados não serão comunicados a terceiros, exceto por obrigação legal.
  5. Armazenamento de dados: banco de dados hospedado pela Occentus Networks (UE)
  6. Direitos: A qualquer momento você pode limitar, recuperar e excluir suas informações.