Sempre foi difícil hospedar com segurança um grande número de usuários em um único cluster do Kubernetes. O principal motivo é que todas as organizações usam o Kubernetes de maneira diferente, portanto, um único modelo multiusuário provavelmente não funcionará para todos. Em vez disso, o Kubernetes oferece componentes para criar sua própria solução, como Role Based Access Control (RBAC) e NetworkPolicies; quanto melhores forem esses componentes, mais fácil será construir um cluster multiusuário seguro.
Namespaces correm para o resgate
De longe, o mais importante desses componentes são os namespaces . Eles são a base para quase todas as políticas de compartilhamento de plano de segurança e controle no Kubernetes. Por exemplo, RBAC, NetworkPolicies e ResourceQuotas oferecem suporte a namespaces por padrão, enquanto objetos como Secret, ServiceAccount e Ingress estão disponíveis gratuitamente em um espaço, mas completamente isolados dos outros .
Os namespaces têm alguns recursos principais que os tornam ideais para a aplicação de políticas. Primeiro, eles podem ser usados para representar propriedade . A maioria dos objetos Kubernetes deveestar em qualquer namespace. Ao usar namespaces para representar propriedade, você sempre pode contar com esses objetos para ter um proprietário.
Em segundo lugar, apenas usuários com os direitos apropriados podem criar e usar namespaces . Você precisa de privilégios elevados para criar namespaces e outros usuários precisam de permissão explícita para trabalhar com eles - ou seja, para criar, visualizar ou modificar objetos nesses namespaces. Assim, primeiro um namespace é criado com um conjunto elaborado de políticas e, somente depois disso, usuários sem privilégios podem criar objetos "regulares" como pods e serviços.
Restrições de namespace
Infelizmente, na prática, os namespaces não são flexíveis o suficiente e não se encaixam bem em alguns casos de uso comuns. Por exemplo, uma determinada equipe possui vários microsserviços com diferentes segredos e cotas. Idealmente, eles devem dividir esses serviços em namespaces separados para isolá-los uns dos outros, mas isso apresenta dois problemas.
Primeiro, esses namespaces carecem de um único conceito de propriedade, embora ambos sejam propriedade da mesma equipe. Isso significa que não apenas o Kubernetes não sabe nada sobre o fato de que esses namespaces têm um proprietário, mas também não tem a capacidade de aplicar políticas globais a todos os namespaces controlados de uma vez.
Em segundo lugar, como você sabe, a autonomia é a chave para um trabalho em equipe eficaz. Visto que a criação de namespaces requer privilégios elevados, é improvável que qualquer pessoa na equipe de desenvolvimento tenha esses privilégios. Em outras palavras, sempre que uma equipe decide criar um novo namespace, ela deve entrar em contato com o administrador do cluster. Isso pode ser perfeitamente aceitável para uma pequena empresa, mas à medida que cresce, os efeitos negativos de tal organização tornam-se mais pronunciados.
Apresentando namespaces hierárquicos
Os namespaces hierárquicos são um novo conceito desenvolvido pelo grupo de trabalho de multilocação do Kubernetes ( wg- multilocação ) para resolver esses problemas. De forma simplificada, um namespace hierárquico é um namespace regular do Kubernetes com um pequeno recurso personalizado incluído que aponta para um (opcional) namespace pai. Isso estende o conceito de propriedade aos próprios namespaces, não apenas aos objetos dentro deles.
O conceito de propriedade também implementa dois tipos adicionais de relacionamentos:
- : namespace' . : subnamespaces, .
Isso resolve os dois problemas de uma equipe de desenvolvimento típica. O administrador do cluster pode criar um espaço "raiz" para ele junto com as políticas necessárias e delegar autoridade para criar subespaços aos membros da equipe. Dessa forma, os desenvolvedores podem criar subnamespaces para seu próprio uso sem violar as políticas definidas pelos administradores de cluster.
Um pouco de prática
Os namespaces hierárquicos são implementados usando uma extensão do Kubernetes chamada Hierarchical Namespace Controller ou HNC . HNC consiste em dois componentes:
- O Manager opera em um cluster, gerencia subnamespaces, distribui objetos de política, garante que as hierarquias sejam válidas e gerencia pontos de extensão.
- Um plug-in kubectl chamado
kubectl-hnspermite que os usuários interajam com o gerenciador.
O guia de instalação do componente pode ser encontrado na página de lançamentos no repositório do projeto.
Vamos dar uma olhada em como o HNC funciona. Suponha que eu não tenha privilégios para criar namespaces, mas posso navegar no namespace
team-ae criar subnamespaces nele *. O plug-in me permite inserir o seguinte comando:
$ kubectl hns create svc1-team-a -n team-a
* Tecnicamente falando, você cria um pequeno objeto chamado "âncora de subnamespace" no espaço pai e, em seguida, o HNC cria um subnamespace.
Isso criará um namespace
svc1-team-a. Observe que os subnamespaces não são diferentes dos namespaces regulares do Kubernetes, portanto, seus nomes devem ser exclusivos.
Você pode ver a estrutura resultante usando o comando
tree:
$ kubectl hns tree team-a
# Output:
team-a
└── svc1-team-a
Se houver alguma política no espaço pai, ela será copiada para o filho *. Por exemplo, suponha que você
team-atenha um RBAC RoleBinding chamado sres. Este RoleBinding também aparecerá no namespace correspondente:
$ kubectl describe rolebinding sres -n svc1-team-a
# Output:
Name: sres
Labels: hnc.x-k8s.io/inheritedFrom=team-a # inserted by HNC
Annotations: <none>
Role:
Kind: ClusterRole
Name: admin
Subjects: …
* Por padrão, apenas Roles e RoleBindings no RBAC são redistribuídos, mas você pode configurar o HNC para propagar qualquer objeto Kubernetes.
Finalmente, o HNC adiciona rótulos a esses namespaces com informações úteis sobre a hierarquia. Eles podem ser usados para aplicar outras políticas. Por exemplo, você pode criar a seguinte NetworkPolicy:
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: allow-team-a
namespace: team-a
spec:
ingress:
- from:
- namespaceSelector:
matchExpressions:
- key: 'team-a.tree.hnc.x-k8s.io/depth' # Label created by HNC
operator: Exists
Essa política será propagada aos descendentes
team-ae também permitirá o tráfego de entrada entre todos esses namespaces. Apenas o HNC pode atribuir o rótulo "árvore". É garantido que reflita a hierarquia atual.
Detalhes sobre a funcionalidade HNC podem ser encontrados no manual do usuário .
Próximas etapas e participação no processo
Se você acha que o namespace hierárquico é útil em sua organização, a versão HNC v0.5.1 está disponível no GitHub (disponível de 28 de agosto até a versão v0.5.2 - ca. Perevi ..) . Gostaríamos de saber o que você pensa sobre ele, quais problemas você resolve e quais recursos você gostaria de adicionar a ele. Como acontece com qualquer software nos estágios iniciais de desenvolvimento, deve-se tomar cuidado ao usar o HNC na produção. E quanto mais feedback tivermos, mais rápido podemos chegar ao HNC 1.0.
Também aceitamos contribuições de colaboradores terceirizados, sejam correções de bugs / informações sobre eles ou ajuda na criação de protótipos de novos recursos, como exceções, monitoramento aprimorado, cotação hierárquica de recursos ou otimização de configuração.
Você pode nos contatar no repositório , newsletter ou Slack . Estamos ansiosos para seus comentários!
O anúncio original foi feito por Adrian Ludwin , engenheiro de software e líder técnico do controlador de namespace hierárquico.
Bônus! Roteiro e problemas
Publique os problemas - quanto mais, mais divertido! Os bugs serão analisados primeiro e as solicitações de recursos serão priorizadas, após o que serão incluídos no plano de trabalho ou backlog.
O HNC ainda não atingiu o status GA, então tome cuidado ao usá-lo em clusters com objetos de configuração que você não pode perder (por exemplo, aqueles que não estão armazenados em um repositório Git).
Todos os problemas de HNC estão incluídos no plano de trabalho correspondente. No momento, as seguintes etapas principais deste plano foram implementadas ou planejadas:
- v1.0: final de I - início do II trimestre de 2021; HNC é recomendado para produção.
- v0.8: início de 2021; novas funções críticas podem aparecer.
- v0.7: final de 2020; muito provavelmente a API v1beta1 aparecerá.
- v0.6: 2020-; v1alpha2 API .
- v0.5: 2020-; , .
- v0.4: 2020-; API production-.
- v0.3: 2020-; UX subnamespace'.
- v0.2: 2019-; non-production.
- v0.1: 2019-; . , - .
- : .
PS do tradutor
Leia também em nosso blog: