Kubernetes 1.30 fica melhor em nomear coisas

Passaporte, por favor!

Após a notícia pública de um vazamento de contêiner em janeiro passado, o lançamento do Kubernetes 1.30 oferece mais alguns pontos de verificação de segurança, reforçando as permissões e os controles de acesso. Os processos errôneos não poderão mais vagar pelos contêineres e pods gerenciados pelo K8s sem nome.

Graças ao KEP 24 (“suporte AppArmor”), contêineres e pods Kubernetes podem ser protegidos por meio do AppArmor, um módulo de segurança Linux para aplicação de políticas durante tempos de execução. Limita o que um aplicativo pode fazer em um sistema com base no perfil do aplicativo.

Os usuários especificam perfis do AppArmor via API.

A proposta de melhoria está em vigor há cerca de três anos. A aplicação de permissão é algo difícil.

Outra melhoria: os pods agora podem ter nomes de usuário, graças ao KEP 127 (“Support User Namespaces”), cujo trabalho foi realizado rapidamente depois que uma série de vulnerabilidades críticas em contêineres foram encontradas em janeiro, aproveitando essa falta de acesso. designação.

Esse recurso “permite isolar os pods um pouco melhor”, disse Kat Cosgrove, que foi a líder de lançamento desta versão mais recente do Kubernetes.

Também por segurança, o KEP 3488 (“CEL for Admission Control”) introduz uma linguagem de expressão mais rica para controle de admissão, fornecendo “uma maneira um pouco mais dinâmica e expressiva de avaliar quaisquer solicitações de admissão”, disse Cosgrove.

“Você pode ter algumas políticas bastante complexas definidas e aplicadas em sua API Kubernetes que tornam os recursos de segurança e governança um pouco mais fáceis de controlar sem comprometer o desempenho.”

Líder de equipe: disputa necessária

Este lançamento, apelidado de “Uwubernetes”, era bastante rotineiro. Nada notável foi descontinuado e vem com algumas melhorias de segurança muito oportunas. No geral, a v1.30 traz 45 melhorias – 17 estáveis, 18 como Beta e 10 como Alpha.

Ser líder de lançamento do Kubernetes da Cloud Native Computing Foundation é um pouco como “pastorear gatos”, disse Cosgrove.

“Há muita política” para fazer.

Cosgrove liderou uma grande equipe, com nove subordinados diretos e 35 subordinados a eles. Eles estavam todos espalhados globalmente por cinco subequipes diferentes.

Kubernetes aprimorado

Colocar um recurso na próxima versão do Kubernetes envolve vários obstáculos.

Um recurso proposto começa como uma Proposta de Melhoria do Kubernetes (KEP). Um Grupo de Interesse Especial deve patrocinar um KEP para consideração no próximo lançamento. Os indicados passam para o congelamento de melhorias, após o qual nenhum novo KEPS será considerado para lançamento.

A pilha resultante de novos recursos pode ser um “jogo de dados completo”, dada a natureza aleatória em que são indicados. Após o congelamento das melhorias, o congelamento do código é aplicado, “e é aqui que muitos KEPs desaparecem”, disse Cosgrove. Talvez muitos tenham descoberto que seria mais trabalhoso levar seu código ao nível de produção do que o previsto.

Nesta última rodada, 95 KEPS conseguiram congelar o aprimoramento, mas apenas 45 conseguiram congelar o código.

“As pessoas estão muito otimistas em relação às melhorias e congelam em suas habilidades de realizar algo. E tudo bem, isso é totalmente normal”, disse Cosgrove. “E então enfrentamos a realidade com o congelamento do código.”

Os testes foram feitos ao longo de todo esse período, e algumas versões alfa e beta também podem ter sido lançadas na próxima versão (que não são amplamente utilizadas). Portanto, os candidatos a lançamento começarão a chegar logo depois.

Depois de todo esse encurralamento, o SIG geralmente exige que o líder de liberação da equipe dê um ciclo antes de voltar à briga.

“Estou pronto para dedicar algum tempo”, disse Cosgrove.

Kubernetes 1.30: Quem é você?

Além da segurança, outros recursos também trouxeram nuances às operações. Por exemplo, KEP 1610 (“Escalonamento automático de pod baseado em recursos de contêiner”) trouxe a capacidade de automatizar o escalonamento automático de pod com base no uso de recursos de contêiner.

“Isso permite configurar o escalonamento automático com base no uso de recursos para contêineres individuais, em vez de no uso total de recursos em um pod inteiro”, disse Cosgrove.

Esse ajuste fino poderia ajudar nos custos da nuvem, por exemplo. Um pod inteiro não será mais ampliado apenas para atender às demandas de um contêiner particularmente faminto por recursos.

Este chamou a atenção de Sergey Pronin, gerente de grupo do provedor de serviços de banco de dados Percona.

Até o momento, os sistemas de banco de dados não funcionaram bem com o escalonador automático de pod do Kubernetes, devido a restrições de dados.

“Com o crescente interesse em tecnologias de dados que dissociam armazenamento e computação (como Neon, Xata), esse recurso pode permitir que os usuários escalem adequadamente”, observou Pronin, por e-mail.

Pronin também apontou (KEP-4381 “DRA: parâmetros estruturados”) como “uma adição muito importante ao ecossistema k8s”. É outro recurso para dimensionar melhor os recursos. A alocação dinâmica de recursos fornece uma API para solicitar e compartilhar recursos entre pods e contêineres dentro de um pod.

Ele foi adicionado ao Kubernetes como um recurso alfa na v1.26, embora a inclusão de parâmetros estruturados introduzidos no Kubernetes 1.30 pareça torná-lo mais fácil de usar.

“Parâmetros estruturados para alocação dinâmica de recursos oferecem uma estrutura que permitiria aos drivers gerenciar eles próprios os recursos”, usando um ‘modelo estruturado’ específico pré-definido pelo Kubernetes”, observam os documentos.

A postagem Kubernetes 1.30 fica melhor em nomear coisas apareceu pela primeira vez em The New Stack.