Vários ambientes (teste, controle de qualidade, produção etc.) com Kubernetes

O que é considerado uma boa prática com K8S para gerenciar vários ambientes (QA, Staging, Production, Dev, etc)?

Por exemplo, digamos que uma equipe esteja trabalhando em um produto que requer a implantação de algumas APIs, juntamente com um aplicativo front-end. Normalmente, isso exigirá pelo menos 2 ambientes:

• Staging: Para iterações / testes e validação antes de liberar para o cliente
• Produção: Este é o ambiente ao qual o cliente tem acesso. Deve conter recursos estáveis ​​e bem testados.

Portanto, supondo que a equipe esteja usando o Kubernetes, qual seria uma boa prática para hospedar esses ambientes? Até agora, consideramos duas opções:

1. Use um cluster K8s para cada ambiente
2. Use apenas um cluster K8s e mantenha-os em namespaces diferentes.

(1) Parece a opção mais segura, pois minimiza os riscos de possíveis erros humanos e falhas da máquina, que podem colocar o ambiente de produção em perigo. No entanto, isso acarreta o custo de mais máquinas master e também o custo de mais gerenciamento de infraestrutura.

(2) Parece que simplifica o gerenciamento de infraestrutura e implantação porque há um único cluster, mas levanta algumas questões como:

• Como ter certeza de que um erro humano pode afetar o ambiente de produção?
• Como ter certeza de que uma carga alta no ambiente de teste não causará perda de desempenho no ambiente de produção?

Pode haver algumas outras preocupações, então estou entrando em contato com a comunidade K8s no StackOverflow para ter uma melhor compreensão de como as pessoas estão lidando com esse tipo de desafio.

Considerações sobre vários clusters

Dê uma olhada nesta postagem do blog de Vadim Eisenberg ( IBM / Istio ): Lista de verificação: prós e contras do uso de vários clusters Kubernetes e como distribuir cargas de trabalho entre eles .

Gostaria de destacar alguns dos prós / contras:

Razões para ter vários clusters

• Separação de produção / desenvolvimento / teste: especialmente para testar uma nova versão do Kubernetes, de uma malha de serviço, de outro software de cluster
• Conformidade: de acordo com alguns regulamentos, alguns aplicativos devem ser executados em clusters / VPNs separados
• Melhor isolamento para segurança
• Nuvem / local: para dividir a carga entre serviços locais

Razões para ter um único cluster

• Reduza a sobrecarga de configuração, manutenção e administração
• Melhorar a utilização
• Redução de custos

Considerando um ambiente não muito caro, com manutenção média, e ainda garantindo o isolamento de segurança para aplicativos de produção, eu recomendaria:

• 1 cluster para DEV e STAGING (separados por namespaces, talvez até isolados, usando políticas de rede, como em Calico )
• 1 cluster para PROD

Paridade Ambiental

É uma boa prática manter o desenvolvimento, a preparação e a produção o mais semelhante possível:

As diferenças entre os serviços de apoio significam que pequenas incompatibilidades surgem, fazendo com que o código que funcionou e passou nos testes de desenvolvimento ou teste falhe na produção. Esses tipos de erros criam atrito que desincentiva a implantação contínua.

Combine uma ferramenta poderosa de CI / CD com o leme . Você pode usar a flexibilidade dos valores do leme para definir as configurações padrão, apenas substituindo as configurações que diferem de um ambiente para outro.

O GitLab CI / CD com AutoDevops tem uma integração poderosa com o Kubernetes, que permite gerenciar vários clusters do Kubernetes já com suporte ao helm.

Gerenciando vários clusters ( kubectlinterações)

Quando você está trabalhando com vários clusters do Kubernetes, é fácil confundir os contextos e executar kubectlno cluster errado. Além disso, o Kubernetes tem restrições para incompatibilidade de versão entre o cliente ( kubectl) e o servidor (mestre do kubernetes), portanto, executar comandos no contexto certo não significa executar a versão certa do cliente.

Para superar isso:

• Use asdfpara gerenciar várias kubectlversões
• Defina oKUBECONFIG env var para mudar entre vários kubeconfigarquivos
• Use kube-ps1para acompanhar seu contexto / namespace atual
• Use kubectxekubens para mudar rapidamente entre clusters / namespaces
• Use aliases para combiná-los todos juntos

Tenho um artigo que exemplifica como fazer isso: usando diferentes versões de kubectl com vários clusters Kubernetes

Eu também recomendo as seguintes leituras:

• Dominar o arquivo KUBECONFIG de Ahmet Alp Balkan ( engenheiro do Google )
• Como Zalando gerencia mais de 140 clusters do Kubernetes, de Henning Jacobs ( Zalando Tech )

Definitivamente, use um cluster separado para desenvolvimento e criação de imagens docker para que seus clusters de teste / produção possam ser bloqueados em termos de segurança. Depende de você staging + productiondecidir com base no risco / custo se você usar clusters separados - certamente mantê-los separados ajudará a evitar stagingefeitos production.

Eu também recomendo usar GitOps para promover versões de seus aplicativos entre seus ambientes.

Para minimizar o erro humano, também recomendo que você automatize o máximo que puder para seu CI / CD e promoção.

Esta é uma demonstração de como automatizar CI / CD com vários ambientes no Kubernetes usando GitOps para promoção entre ambientes e ambientes de visualização em solicitações pull que foi feito ao vivo no GKE, embora o Jenkins X seja compatível com a maioria dos clusters de kubernetes

Depende do que você deseja testar em cada um dos cenários. Em geral, eu tentaria evitar a execução de cenários de teste no cluster de produção para evitar efeitos colaterais desnecessários (impacto no desempenho, etc.).

Se sua intenção é testar com um sistema de teste que imita exatamente o sistema de produção, eu recomendaria acionar uma réplica exata do cluster completo e desligá-lo depois de terminar o teste e mover as implantações para produção.

Se o seu objetivo é testar um sistema de preparação que permite testar o aplicativo para implantação, eu executaria um cluster de preparação menor permanentemente e atualizaria as implantações (com também uma versão reduzida das implantações) conforme necessário para o teste contínuo.

Para controlar os diferentes clusters, prefiro ter uma máquina ci / cd separada que não faça parte do cluster, mas usada para ativar e desativar clusters, bem como realizar trabalhos de implantação, iniciar testes, etc. Isso permite configurar e desligar clusters como parte de cenários de teste automatizados.

É claro que, ao manter o cluster de produção separado do cluster de teste, o risco de erros em potencial afetando os serviços de produção é reduzido. No entanto, isso tem um custo de mais gerenciamento de infraestrutura / configuração, uma vez que requer pelo menos:

• pelo menos 3 mestres para o cluster de produção e pelo menos um mestre para o de teste
• 2 arquivos de configuração Kubectl a serem adicionados ao sistema CI / CD

Também não podemos esquecer que pode haver mais de um ambiente. Por exemplo, trabalhei em empresas onde existem pelo menos 3 ambientes:

• QA: onde fizemos implantações diárias e fizemos nosso QA interno antes de liberar para o cliente)
• QA do cliente: onde implantamos antes de implantar para produção, para que o cliente pudesse validar o ambiente antes de liberar para produção)
• Produção: onde os serviços de produção são implantados.

Acho que clusters efêmeros / sob demanda fazem sentido, mas apenas para certos casos de uso (teste de carga / desempenho ou muito «grande» integração / teste ponta a ponta), mas para ambientes mais persistentes / fixos, vejo uma sobrecarga que pode ser reduzida executando-os em um único cluster.

Acho que gostaria de entrar em contato com a comunidade k8s para ver quais padrões são usados ​​para cenários como os que descrevi.

A menos que a conformidade ou outros requisitos determinem o contrário, sou a favor de um único cluster para todos os ambientes. Com esta abordagem, os pontos de atenção são:

• Certifique-se de agrupar nós por ambiente usando rótulos. Você pode então usar os nodeSelectorrecursos on para garantir que eles estejam sendo executados em nós específicos. Isso reduzirá as chances de o consumo de recursos (em excesso) se espalhar entre os ambientes.

• Trate seus namespaces como sub-redes e proíba todo o tráfego de entrada / saída por padrão. Consulte https://kubernetes.io/docs/concepts/services-networking/network-policies/ .

• Tenha uma estratégia para gerenciar contas de serviço. ClusterRoleBindingsimplicam em algo diferente se um cluster hospeda mais de um ambiente.

• Use o escrutínio ao usar ferramentas como Helm. Alguns gráficos instalam descaradamente contas de serviço com permissões para todo o cluster, mas as permissões para contas de serviço devem ser limitadas ao ambiente em que estão.

Usar vários clusters é a norma, na própria lista, para impor uma forte separação entre produção e "não produção".

Nesse espírito, observe que o GitLab 13.2 (julho de 2020) agora inclui:

Implantação de vários clusters Kubernetes no Core

O uso do GitLab para implantar vários clusters Kubernetes com o GitLab exigia anteriormente uma licença Premium.
Nossa comunidade falou e nós ouvimos: implantar em vários clusters é útil até mesmo para colaboradores individuais.
Com base em seu feedback, a partir do GitLab 13.2, você pode implantar em vários grupos e clusters de projeto no Core.

Veja a documentação e questão /

Acho que executar um único cluster faz sentido porque reduz a sobrecarga e o monitoramento. Mas, você deve certificar-se de colocar políticas de rede e controle de acesso em vigor.

Política de rede - para proibir que a carga de trabalho do ambiente dev / qa interaja com armazenamentos de produção / preparação.

Controle de acesso - quem tem acesso a diferentes recursos do ambiente usando ClusterRoles, Roles etc.