Melhores práticas do Kubernetes. Organização Kubernetes com espaço para nome

Melhores práticas do Kubernetes. Criando contêineres pequenos

À medida que você começa a criar mais e mais serviços Kubernetes, as tarefas fáceis de iniciar ficam mais complicadas. Por exemplo, as equipes de desenvolvimento não podem criar serviços ou implantações com o mesmo nome. Se você possui milhares de lares, uma simples lista deles demorará muito tempo, sem mencionar o fornecimento de um gerenciamento normal. E isso é só o topo do iceberg.

Vamos dar uma olhada em como o namespace do namespace facilita o gerenciamento de recursos do Kubernetes. Então, o que exatamente é um espaço para nome? O espaço para nome pode ser pensado como um cluster virtual dentro do seu cluster Kubernetes. Você pode ter vários espaços para nome isolados um do outro no mesmo cluster Kubernetes. Eles podem realmente ajudar você e sua equipe com organização, segurança e até desempenho do sistema.



Na maioria das distribuições do Kubernetes, o cluster está "pronto para uso" com um espaço para nome chamado "padrão". Na verdade, existem três namespaces com os quais o Kubernetes está lidando: padrão, kube-system e kube-public. Atualmente, o Kube-public não é usado com muita frequência.



Não tocar no namespace do kube é uma boa ideia, especialmente em um sistema gerenciado como o Google Kubernetes Engine. Ele usa o espaço para nome padrão como o local onde seus serviços e aplicativos são criados. Não há absolutamente nada de especial nele, exceto que o Kubernetes está pronto para o uso e você não pode removê-lo. Isso é ótimo para iniciar e sistemas com pouco desempenho, mas eu não recomendaria o uso do espaço para nome padrão em grandes sistemas de produção. No último caso, uma equipe de desenvolvimento pode reescrever facilmente o código de outra pessoa e interromper o trabalho de outra equipe sem nem mesmo perceber.

Portanto, você deve criar vários namespaces e usá-los para segmentar seus serviços em links gerenciáveis. Um espaço para nome pode ser criado com um único comando. Se você deseja criar um espaço para nome chamado test, use o comando $ kubectl create namespace test ou apenas crie um arquivo YAML e use-o como qualquer outro recurso do Kubernetes.



Você pode visualizar todos os espaços para nome usando o comando $ kubectl get namespace.



Após sua execução, você verá três espaços para nome internos e um novo espaço para nome chamado "teste". Vejamos um arquivo YAML simples para criar pods. Você pode perceber que não há menção a um espaço para nome nele.



Se você usar o kubectl para executar este arquivo, ele criará o módulo mypod no espaço para nome ativo atual. Este será o espaço para nome padrão até você alterá-lo. Existem duas maneiras de informar ao Kubernetes em qual namespace você deseja criar seu recurso. A primeira maneira é usar o sinalizador de espaço para nome ao criar o recurso.



A segunda maneira é especificar o espaço para nome na declaração YAML.



Se você especificar um espaço para nome no YAML, o recurso será sempre criado nesse espaço. Se você tentar usar um espaço para nome diferente ao usar o sinalizador de espaço para nome, o comando falhará. Agora, se você tentar encontrar seu pod, não poderá fazê-lo.



Isso ocorre porque todos os comandos são executados fora do namespace ativo atual. Para encontrar seu pod, você precisa usar o sinalizador de espaço para nome, mas isso é muito chato, especialmente se você trabalha como desenvolvedor em um grupo que usa seu próprio espaço para nome e não deseja usar esse sinalizador para cada comando individual. Vamos ver como isso pode ser corrigido.



Fora da caixa, seu espaço para nome ativo é chamado padrão. Se você não especificar o espaço para nome na YAML do recurso, todos os comandos do Kubernetes usarão esse espaço para nome padrão ativo. Infelizmente, uma tentativa de gerenciar o espaço para nome ativo usando o kubectl pode falhar. No entanto, existe uma ferramenta muito boa chamada Kubens, que simplifica bastante esse processo. Ao executar o comando kubens, você vê todos os espaços para nome com o espaço para nome ativo destacado.



Para alternar o namespace ativo para o namespace de teste, basta executar o comando $ kubens test. Se após isso você digitar o comando $ kubens novamente, poderá ver que um novo espaço para nome ativo está agora alocado - test.



Isso significa que você não precisa de um sinalizador de espaço para nome para ver o pod no espaço para nome de teste.



Portanto, os espaços para nome são ocultos um do outro, mas não isolados um do outro. Um serviço de um espaço para nome pode facilmente se comunicar com um serviço em outro espaço para nome, o que geralmente é muito útil. A capacidade de se comunicar entre diferentes espaços para nome significa que o serviço de seus desenvolvedores pode interagir com o serviço de outro comando dev em um espaço para nome diferente.

Normalmente, quando seu aplicativo deseja acessar o serviço Kubernetes, você usa o serviço de descoberta de DNS interno e fornece apenas o nome do serviço. No entanto, você pode criar um serviço com o mesmo nome em vários espaços para nome, o que é inválido.



Felizmente, isso é facilmente contornado usando a forma expandida do endereço DNS. Os serviços do Kubernetes expõem seus pontos de extremidade usando um padrão DNS comum. Parece algo assim:



como regra, você só precisa do nome do serviço, e o DNS determinará automaticamente o endereço completo.



No entanto, se você precisar acessar o serviço em um espaço para nome diferente, basta usar o nome do serviço mais o nome do espaço para nome:



Por exemplo, se você deseja se conectar ao banco de dados do serviço no espaço para nome de teste, poderá usar o endereço de banco de dados database.test



Se desejar se conectar para o banco de dados de serviço no namespace prod, você está usando database.prod.



Se você realmente deseja isolar e restringir o acesso ao espaço para nome, o Kubernetes permite fazer isso usando as Diretivas de Rede do Kubernetes. Vou falar sobre isso na próxima série.

Muitas vezes me perguntam quantos namespaces precisam ser criados e com que objetivos? O que é um dado gerenciado?

Se você criar muitos namespaces, eles apenas atrapalharão. Se houver muito poucos deles, você perderá todas as vantagens dessa solução. Eu acho que existem quatro estágios principais pelos quais cada empresa passa no processo de criação de sua própria estrutura organizacional. Dependendo do estágio de desenvolvimento em que seu projeto ou empresa está localizado, você pode adotar a estratégia apropriada para criar um espaço para nome.

Imagine que você faz parte de uma pequena equipe que trabalha no desenvolvimento de 5 a 10 microsserviços e pode montar facilmente todos os desenvolvedores em uma sala. Nessa situação, faz sentido executar todos os serviços de prod no espaço para nome padrão. Obviamente, para um maior escopo de ação, você pode usar 2 namespaces - separadamente para prod e dev. E provavelmente, você está testando seu desenvolvimento em um computador local usando algo como o Minikube.

Suponha que as condições tenham mudado e agora você tenha uma equipe em rápido crescimento que trabalha simultaneamente em mais de 10 microsserviços. Chega um momento em que você precisa usar vários clusters ou namespaces, separadamente para prod e dev. Você pode dividir uma equipe em vários subgrupos para que cada um deles tenha seus próprios microsserviços e cada uma dessas equipes possa escolher seu próprio espaço para nome para facilitar o processo de gerenciar o desenvolvimento e a liberação do software.



À medida que cada membro da equipe tem uma idéia de como o sistema como um todo funciona, coordenar cada alteração com todos os outros desenvolvedores se torna cada vez mais difícil. Tentar girar uma pilha completa no computador local está ficando mais difícil a cada dia.

Nas grandes empresas, os desenvolvedores não sabem exatamente quem está trabalhando no quê. As equipes se comunicam usando contratos de serviço ou usam a tecnologia de malha de serviço, que adiciona uma camada de abstração na rede, como a ferramenta de configuração Istio. Não é possível tentar executar a pilha inteira localmente.Eu recomendo o uso de uma plataforma de entrega contínua (CD) como o Spinnaker no Kubernetes. Então, chega o momento em que cada equipe definitivamente precisa de seu próprio espaço para nome. Cada comando pode até selecionar vários namespaces para o ambiente de desenvolvimento e o ambiente de produção.

Por fim, existem grandes empresas empreendedoras nas quais um grupo de desenvolvimento nem sequer está ciente da existência de outros grupos. Essa empresa geralmente pode contratar desenvolvedores de terceiros que interagem com APIs bem documentadas. Em cada grupo, existem várias equipes e vários microsserviços. Nesse caso, você deve usar todas as ferramentas mencionadas anteriormente.



Os programadores não devem implantar serviços manualmente e não devem ter acesso a namespaces que não os interessam. Nesse estágio, é aconselhável ter vários clusters para reduzir o "raio de explosão" de aplicativos mal configurados, para simplificar os processos de cobrança e gerenciamento de recursos.

Portanto, o uso correto dos espaços para nome da sua organização torna o Kubernetes mais gerenciável, gerenciável, seguro e flexível.

Melhores práticas do Kubernetes. Teste de viabilidade Kubernetes com testes de prontidão e vida

Um pouco de publicidade :)

Obrigado por ficar com a gente. Você gosta dos nossos artigos? Deseja ver materiais mais interessantes? Ajude-nos fazendo um pedido ou recomendando aos seus amigos o VPS baseado em nuvem para desenvolvedores a partir de US $ 4,99 , um analógico exclusivo de servidores básicos que foi inventado por nós para você: Toda a verdade sobre o VPS (KVM) E5-2697 v3 (6 núcleos) 10GB DDR4 480GB SSD 1Gbps de 10GB de US $ 19 ou como dividir o servidor? (as opções estão disponíveis com RAID1 e RAID10, até 24 núcleos e até 40GB DDR4).

Dell R730xd 2 vezes mais barato no data center Equinix Tier IV em Amsterdã? Somente nós temos 2 TVs Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV a partir de US $ 199 na Holanda!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - a partir de US $ 99! Leia sobre como construir infraestrutura classe c usando servidores Dell R730xd E5-2650 v4 que custam 9.000 euros por um centavo?