Lançamentos seguros com o Anthos Config Management

Neste documento, mostramos aos operadores de cluster e aos administradores da plataforma como implantar alterações com segurança em vários ambientes usando o Anthos Config Management. O Anthos Config Management ajuda você a evitar erros que afetam todos os seus ambientes simultaneamente.

O Anthos Config Management permite gerenciar clusters únicos, clusters multilocatários e configurações do Kubernetes com vários clusters usando arquivos armazenados em um repositório Git. O Anthos Config Management combina três tecnologias: Config Sync, Policy Controller e Config Conector. O Config Sync monitora as atualizações de todos os arquivos no repositório Git e aplica alterações a todos os clusters relevantes automaticamente. O Policy Controller gerencia e aplica políticas para objetos nos clusters. O Config Connector usa recursos personalizados do Google Kubernetes Engine (GKE) para gerenciar recursos de nuvem.

As configurações do Config Sync podem representar várias coisas, incluindo as seguintes:

O Anthos Config Management é especialmente indicado para implantar configurações, políticas e cargas de trabalho que executam a plataforma baseada no Anthos. Por exemplo, agentes de segurança, agentes de monitoramento e gerenciadores de certificados.

Embora seja possível implantar aplicativos voltados para o usuário com o Anthos Config Management, não recomendamos vincular o ciclo de vida de suas versões ao da versão das cargas de trabalho administrativas mencionadas anteriormente. Em vez disso, você deve usar uma ferramenta dedicada à implantação de aplicativos, como uma de implantação contínua, para que as equipes de aplicativo possam controlar a programação de lançamentos.

O Anthos Config Management é um produto eficiente que gerencia muitos elementos. Portanto, você precisa de proteções para evitar erros de grande impacto. Este documento descreve vários métodos para criar proteções. A primeira seção aborda os lançamentos graduais; a segunda se concentra em testes e validações, e a terceira explica como usar o Policy Controller para criar proteções. A quarta seção mostra como monitorar as implantações do Anthos Config Management.

É possível usar a maioria dos métodos discutidos neste documento, mesmo que você esteja usando apenas o Config Sync, e não o produto completo do Anthos Config Management. Se você não estiver usando o produto Anthos Config Management completo, mas ainda quiser implementar os métodos envolvendo o Policy Controller, faça isso usando Gatekeeper. As exceções a essa regra são os métodos que dependem da página do Anthos Config Management no Console do Google Cloud, como atualizar a configuração do Anthos Config Management no Console do Google Cloud. Também é possível usar vários dos métodos descritos neste documento ao mesmo tempo. Na seção a seguir, uma tabela indica quais métodos podem ser usados simultaneamente.

Como implementar lançamentos graduais com o Anthos Config Management

Em um ambiente com vários clusters (situação comum para usuários do Anthos), não recomendamos aplicar uma alteração de configuração em todos os clusters ao mesmo tempo. Uma implantação gradual, cluster por cluster (ou até mesmo namespace por namespace, se você usá-los como o limite entre aplicativos), é muito mais segura, porque reduz o raio de alcance de qualquer erro.

Veja a seguir várias maneiras de implementar lançamentos graduais com o Anthos Config Management:

  • Use confirmações ou tags do Git para aplicar manualmente as alterações que você quer aos clusters.
  • Use as ramificações do Git para aplicar automaticamente as alterações quando elas forem mescladas. É possível usar diferentes ramificações para diferentes grupos de clusters.
  • Use os objetos ClusterSelector e NamespaceSelector para aplicar seletivamente alterações a subgrupos de clusters ou namespaces.

Todos os métodos para lançamentos graduais têm vantagens e desvantagens. A tabela a seguir mostra quais desses métodos podem ser usados ao mesmo tempo.

X é compatível com Y? Tags ou confirmações do Git Ramificações do Git Seletores de cluster Seletores de namespace
Tags ou confirmações do Git Incompatível Compatível Compatível
Ramificações do Git Incompatível Compatível Compatível
Seletores de cluster Compatível Compatível Compatível
Seletores de namespace Compatível Compatível Compatível

A árvore de decisão abaixo ajuda você a decidir quando usar um dos métodos de lançamento gradual.

Árvore de decisão para métodos de lançamento.

Usar confirmações ou tags do Git

Em comparação com os outros métodos de lançamento gradual, usar confirmações ou tags do Git oferece mais controle e segurança. Use a página do Anthos Config Management no console para atualizar vários clusters ao mesmo tempo. Use esse método se quiser aplicar alterações aos clusters um por um e controlar exatamente quando isso acontece.

Nesse método, você "fixa" cada cluster a uma versão específica (uma confirmação ou uma tag) do repositório do Anthos Config Management. Esse método é semelhante ao uso da confirmação de Git como tag de imagem do contêiner. Esse método é implementado especificando a confirmação ou a tag no campo spec.git.syncRev do recurso personalizado ConfigManagement. Se você sincronizar as configurações de vários repositórios, implementar esse método atualizando os recursos personalizados do RootSync e do RepoSync. Para mais informações sobre os campos de configuração, consulte Como configurar o operador. Se você gerencia seus recursos personalizados do ConfigManagement com uma ferramenta como o kustomize, pode reduzir o trabalho manual exigido para implementar as alterações. Com essa ferramenta, você só precisa alterar o parâmetro syncRev em um lugar e aplicar seletivamente o novo recurso personalizado do ConfigManagement aos clusters na ordem e no ritmo que quiser.

Além disso, se estiver usando o Anthos Config Management (e não o Config Sync), você terá acesso à página Anthos Config Management no console do Google Cloud. Nesta página, é possível atualizar o parâmetro syncRev para vários clusters pertencentes à mesma frota ao mesmo tempo. Se você tiver um sistema automatizado para atualizar a configuração do Anthos Config Management, recomendamos não usar o console para alterar essa configuração.

Por exemplo, a seguinte definição do ConfigManagement configura o Anthos Config Management para usar a tag 1.2.3:

apiVersion: configmanagement.gke.io/v1
kind: ConfigManagement
metadata:
  name: config-management
spec:
  # clusterName is required and must be unique among all managed clusters
  clusterName: my-cluster
  git:
    syncRepo: git@example.com:anthos/config-management.git
    # Pin the cluster using a tag
    syncRev: 1.2.3
    secretType: ssh

Se você aplicar essa configuração ao cluster, o Anthos Config Management usará a tag 1.2.3 do repositório example.com:anthos/config-management.git.

Para atualizar um cluster, altere o campo spec.git.syncRev para o novo valor do cluster. Isso permite que você defina quais clusters serão atualizados e quando. Se precisar reverter uma alteração, mude o campo spec.git.syncRev de volta para o valor anterior.

O diagrama a seguir ilustra o processo de lançamento desse método. Primeiro, confirme as alterações no repositório do Anthos Config Management e atualize as definições do ConfigManagement em todos os clusters:

Processo de lançamento para confirmações e tags do Git.

Recomendamos o seguinte:

  • Use IDs de confirmação do Git em vez de tags. Devido à maneira como o Git funciona, você tem uma garantia de que eles nunca serão alterados. Por exemplo, um git push --force não pode alterar a confirmação que o Anthos Config Management está usando. Essa abordagem é útil para fins de auditoria e para monitorar qual confirmação você está usando nos registros. Além disso, ao contrário das tags, não há mais uma etapa para confirmar os IDs.
  • Se você preferir usar tags Git em vez de IDs de confirmação do Git e estiver usando o GitLab, proteja as tags para evitar que sejam movidas ou excluídas. As outras principais soluções do Git não têm esse recurso.
  • Se você quiser atualizar vários clusters ao mesmo tempo, faça isso na página do console do Anthos Config Management. Para atualizar vários clusters de uma só vez, eles precisam fazer parte da mesma frota e estar no mesmo projeto.

Usar ramificações do Git

Se você quiser que as alterações sejam aplicadas aos clusters assim que eles forem mesclados no repositório Git, configure o Anthos Config Management para usar ramificações do Git em vez de confirmações ou tags. Nesse método, você pode criar várias ramificações de longa duração no repositório Git e configurar o Anthos Config Management em clusters diferentes para ler suas configurações de diversas ramificações.

Por exemplo, um padrão simples tem duas ramificações:

  • Uma ramificação staging para clusters que não sejam de produção.
  • Uma ramificação master para clusters de produção.

Para clusters que não sejam de produção, crie o objeto ConfigManagement com o campo spec.git.syncBranch definido como staging. Para clusters de produção, crie o objeto ConfigManagement com o parâmetro spec.git.syncBranch definido como master. Se você sincronizar as configurações de vários repositórios, faça essa configuração nos recursos personalizados RootSync e RepoSync. Para mais informações, consulte Como configurar o Operator.

Por exemplo, a seguinte definição do ConfigManagement configura o Anthos Config Management para usar a ramificação master:

apiVersion: configmanagement.gke.io/v1
kind: ConfigManagement
metadata:
  name: config-management
spec:
  # clusterName is required and must be unique among all managed clusters
  clusterName: my-cluster
  git:
    syncRepo: git@example.com:anthos/config-management.git
    # This cluster will apply the configuration
    # available on the master branch.
    syncBranch: master
    secretType: ssh

O diagrama abaixo ilustra o processo de lançamento desse método:

Processo de lançamento de ramificações do Git.

Você pode adaptar esse padrão a necessidades específicas, usando mais de duas ramificações ou ramificações mapeadas para outros itens, que não seja os ambientes. Se precisar reverter uma alteração, use o comando git revert para criar uma nova confirmação na mesma ramificação que reverte as alterações anteriores.

Recomendamos o seguinte:

  • Ao trabalhar com vários clusters, use pelo menos duas ramificações do Git para distinguir os clusters de produção e os de não-produção.
  • A maioria das soluções do Git permite que você use o recurso de ramificações protegidas para evitar exclusões ou alterações não analisadas dessas ramificações. Para mais informações, consulte a documentação do GitHub, do GitLab e do Bitbucket (links em inglês).

Usar objetos ClusterSelector e NamespaceSelector

As ramificações do Git são uma boa maneira de fazer um lançamento gradual de alterações em vários clusters que futuramente terão as mesmas políticas. No entanto, se você quiser implantar uma alteração apenas em um subconjunto de clusters ou namespaces, use os objetos ClusterSelector e NamespaceSelector. Esses objetos têm um propósito semelhante: permitem que você aplique objetos apenas a clusters ou namespaces com rótulos específicos.

Exemplo:

  • Com o uso de objetos ClusterSelector, é possível aplicar políticas diferentes aos clusters, dependendo do país em que estejam localizados, para vários sistemas de compliance.
  • Ao usar objetos NamespaceSelector, você pode aplicar políticas diferentes a namespaces usados por uma equipe interna e por um fornecedor externo.

Os objetos ClusterSelector e NamespaceSelector também permitem implementar avançadas metodologias de teste e lançamento, como as seguintes:

  • Versões canário de políticas, em que você implanta uma nova política em um pequeno subconjunto de clusters e namespaces por um longo tempo para estudar o impacto da política.
  • Testes A/B, em que você implanta diferentes versões da mesma política em diferentes clusters para avaliar o impacto dessas versões e escolher a melhor para uma implantação global.

Por exemplo, imagine uma organização com vários clusters de produção. A equipe de plataforma já criou duas categorias de clusters de produção, chamadas canary-prod e prod, usando os objetos Anthos Config Management, Cluster e ClusterSelector (consulte configurando apenas um subconjunto de clusters).

A equipe de plataforma quer implantar uma política com o Policy Controller para impor a presença de um rótulo em namespaces identificando a qual equipe cada namespace pertence. Ela já implantou uma versão dessa política no modo de teste e agora quer aplicá-la a um pequeno número de clusters. Usando objetos ClusterSelector, eles criam dois recursos K8sRequiredLabels diferentes aplicados a diferentes clusters.

  • O recurso K8sRequiredLabels é aplicado a clusters do tipo prod, com um parâmetro enforcementAction definido como dryrun:

    apiVersion: constraints.gatekeeper.sh/v1beta1
    kind: K8sRequiredLabels
    metadata:
      name: ns-must-have-team
      annotations:
        configmanagement.gke.io/cluster-selector: prod
    Spec:
      enforcementAction: dryrun
      match:
        kinds:
          - apiGroups: [""]
            kinds: ["Namespace"]
      parameters:
        labels:
          - key: "team"
    
  • O recurso K8sRequiredLabels é aplicado a clusters do tipo canary-prod, sem o parâmetro enforcementAction, o que significa que a política é realmente aplicada:

    apiVersion: constraints.gatekeeper.sh/v1beta1
    kind: K8sRequiredLabels
    metadata:
      name: ns-must-have-team
      annotations:
        configmanagement.gke.io/cluster-selector: canary-prod
    spec:
      match:
        kinds:
          - apiGroups: [""]
        kinds: ["Namespace"]
      parameters:
        labels:
          - key: "team"
    

A anotação configmanagement.gke.io/cluster-selector permite que a equipe aplique a política somente em clusters do tipo canary-prod, impedindo que efeitos colaterais indesejados se espalhem para toda a frota de produção. Para mais informações sobre o recurso de teste do Policy Controller, consulte Como criar restrições.

Recomendamos o seguinte:

  • Use objetos ClusterSelector e NamespaceSelector se precisar aplicar uma alteração de configuração apenas a um subconjunto de clusters ou namespaces indefinidamente ou por um longo período.
  • Se você implementar uma alteração usando seletores, tenha muito cuidado. Se você usar as confirmações do Git, qualquer erro afetará apenas um cluster por vez, porque você estará implantando cluster por cluster. Mas, se você usar ramificações do Git, qualquer erro poderá afetar todos os clusters que usam essa ramificação. Se você usar seletores, o erro poderá afetar todos os clusters de uma só vez.

Como implementar avaliações, testes e validações

Uma vantagem do Anthos Config Management é que ele gerencia tudo de maneira declarativa: recursos do Kubernetes, recursos em nuvem e políticas. Isso significa que os arquivos em um sistema de gerenciamento de controle de origem representam os recursos (arquivos Git, no caso do Anthos Config Management). Essa característica permite implementar fluxos de trabalho de desenvolvimento que você já usa para o código-fonte de um aplicativo: avaliações e testes automatizados.

Implementar avaliações

Como o Anthos Config Management é baseado em Git, use sua solução Git preferida para hospedar o repositório Anthos Config Management. Sua solução do Git provavelmente tem um recurso de revisão de código, que pode ser usado para revisar as alterações feitas no repositório do Anthos Config Management.

As práticas recomendadas para analisar as alterações no repositório do Anthos Config Management são as mesmas de uma análise de código normal, da seguinte maneira:

Devido à confidencialidade do codebase do Anthos Config Management, também recomendamos que você faça as seguintes configurações, se possível com sua solução Git:

Ao usar esses recursos diferentes, é possível aplicar aprovações para cada solicitação de alteração à codebase do Anthos Config Management. Por exemplo, você pode garantir que cada alteração seja aprovada pelo menos por um membro da equipe de plataforma (que opera a frota de clusters) e por um membro da equipe de segurança (responsável por definir e implementar políticas de segurança).

Recomendamos a seguinte ação:

  • Aplique análises de pares no repositório do Anthos Config Management e proteja as ramificações do Git usadas pelos clusters.

Implementar testes automatizados

Uma prática recomendada comum quando se trabalha em uma codebase é implementar a integração contínua. Isso significa que você configura testes automatizados para serem executados quando uma solicitação de alteração é criada ou atualizada. Os testes automatizados podem detectar muitos erros antes de uma pessoa analisar a solicitação de mudança. Isso aumenta o loop de feedback para o desenvolvedor. É possível implementar a mesma ideia usando as mesmas ferramentas para o repositório do Anthos Config Management.

Por exemplo, um bom ponto de partida é executar o comando nomos vet automaticamente em novas alterações. Este comando valida a sintaxe do seu repositório do Anthos Config Management. É possível implementar esse teste usando o Cloud Build seguindo o tutorial de validação de configs. Integre o Cloud Build com as seguintes opções:

Como você pode ver no tutorial Como validar configurações, o teste é feito usando uma imagem de contêiner. Portanto, é possível implementar o teste em qualquer solução de integração contínua que execute contêineres, e não apenas no Cloud Build. Especificamente, você pode implementá-lo com o GitLab CI, seguindo este exemplo, que também inclui testes do Policy Controller.

Para aumentar ainda mais o loop de feedback, solicite que os usuários executem o comando nomos vet como um gancho de pré-confirmação do Git. Uma restrição é que talvez alguns usuários não tenham acesso aos clusters do Kubernetes gerenciados pelo Anthos Config Management e talvez não consigam executar a validação completa em suas estações de trabalho. Execute o comando nomos vet --clusters "" para restringir a validação a verificações semânticas e sintáticas.

Você pode implementar qualquer outro teste que achar necessário ou útil. Se você usar o Policy Controller, poderá implementar testes automatizados de alterações sugeridas em relação às políticas, conforme descrito em Testar alterações com base nas políticas do Policy Controller.

Recomendamos a seguinte ação:

  • Implemente testes em um pipeline de integração contínua. Execute pelo menos o comando nomos vet em todas as alterações sugeridas.

Como usar o Policy Controller

O Policy Controller é um controlador de admissão dinâmico do Kubernetes. Quando você instala e configura o Policy Controller, o Kubernetes pode rejeitar as alterações que não estão em conformidade com as regras pré definidas, chamadas de políticas.

Veja estes dois exemplos de casos de uso do Policy Controller:

  • Impor a presença de rótulos específicos em objetos do Kubernetes
  • Impedir a criação de pods com privilégios

Uma biblioteca de modelos de políticas está disponível para implementar as políticas mais usadas, mas você pode criar as suas com uma linguagem poderosa chamada Rego. Com o Policy Controller, é possível, por exemplo, restringir os nomes de host que os usuários podem configurar em uma entrada. Para mais informações, consulte este tutorial.

Assim como o Config Sync, o Policy Controller faz parte do Anthos Config Management. O Policy Controller e o Config Sync têm casos de uso diferentes, mas complementares, da seguinte maneira:

  • O Config Sync é uma ferramenta de estilo GitOps que permite criar qualquer objeto do Kubernetes, inclusive em vários clusters ao mesmo tempo. Como mencionado na introdução, o Config Sync é especialmente útil para gerenciar políticas.
  • O Policy Controller permite definir políticas para objetos que podem ser criados no Kubernetes. Você define essas políticas em recursos personalizados, que são os próprios objetos do Kubernetes.

Os recursos anteriores criam um relacionamento bidirecional entre os dois aplicativos. É possível usar o Config Sync para criar as políticas aplicadas pelo Policy Controller e usá-las para controlar exatamente quais objetos o Config Sync (ou qualquer outro processo) pode criar, conforme mostrado no diagrama a seguir:

Config Sync e Policy Controller.

O repositório Git, o Config Sync, o Policy Controller, o Kubernetes, um sistema de implantação contínua (CD) e os usuários interagem entre si das seguintes maneiras:

  • Os usuários interagem com o repositório Git do Anthos Config Management para criar, atualizar ou excluir objetos do Kubernetes;
  • O Config Sync lê sua configuração a partir do repositório Anthos Config Management;
  • O Config Sync interage com o servidor da API Kubernetes para criar objetos, que incluem políticas do Policy Controller;
  • O sistema de CD também interage com o servidor da API Kubernetes para criar objetos. Isso pode criar restrições para o Policy Controller. No entanto, recomendamos que você use o Anthos Config Management para esse caso de uso, porque ele oferece um local centralizado para gerenciar e testar as restrições;
  • O servidor da API Kubernetes aceita ou rejeita a criação de objetos pelo Config Sync e pelo sistema CD, com base na resposta do Policy Controller;
  • O Policy Controller fornece essa resposta com base nas políticas que ele lê do servidor da API Kubernetes.

O diagrama a seguir ilustra essas interações:

Interações entre o repositório Git, o Config Sync, o Policy Controller, o Kubernetes, um sistema de implantação contínua e os usuários.

O Policy Controller pode evitar violações de políticas que não são detectadas por revisores humanos e testes automatizados. Assim, você pode considerá-lo a última linha de defesa para seus clusters do Kubernetes. O Policy Controller também se torna mais útil à medida que aumenta o número de revisores humanos para o Anthos Config Management. Devido ao fenômeno da indolência social, quanto mais revisores você tiver, menor a probabilidade de que eles apliquem as regras definidas na organização de maneira consistente.

Teste as alterações com base nas políticas do Policy Controller

Se você usa o Policy Controller, pode adicionar algumas etapas ao pipeline de integração contínua (consulte Implementar testes automatizados) para testar automaticamente as alterações sugeridas em relação às políticas. A automação dos testes dá um feedback mais rápido e mais visível à pessoa que sugere a alteração. Se você não testar as alterações em relação às políticas no pipeline de integração contínua, precisará confiar no sistema descrito em Monitorar lançamentos para receber alertas de erros de sincronização do Anthos Config Management. O teste das alterações com base nas políticas expõe qualquer violação à pessoa que sugere a mudança, de maneira clara e antecipada.

É possível implementar esse teste no Cloud Build seguindo o tutorial Como usar o Policy Controller em um pipeline de CI. Conforme mencionado anteriormente em Implementar testes automatizados, é possível integrar o Cloud Build ao GitHub e ao Bitbucket. Também é possível implementar esse teste com o GitLab CI. Consulte este repositório para ver um exemplo de implementação.

Recomendamos a seguinte ação:

  • Se você usa o Policy Controller, valide as alterações sugeridas com base nas respectivas políticas no seu pipeline de integração contínua.

Como monitorar lançamentos

Mesmo que você implemente todas as proteções abordadas neste documento, ainda podem ocorrer erros. Veja a seguir dois tipos comuns de erros:

  • Erros que não representam um problema para o Config Sync em si, mas impedem que as cargas de trabalho funcionem corretamente, como um NetworkPolicy excessivamente restritivo que afeta a comunicação dos componentes da carga de trabalho.
  • Erros que impedem que o Config Sync aplique alterações a um cluster, como um manifesto do Kubernetes inválido ou um objeto rejeitado por um controlador de admissão. Os métodos explicados anteriormente devem detectar a maioria desses erros.

A detecção dos erros descritos no primeiro marcador acima é quase impossível no nível do Anthos Config Management, porque isso exige a compreensão do estado de cada uma das suas cargas de trabalho. Por esse motivo, a detecção desses erros é mais eficaz pelo sistema de monitoramento existente, que avisa quando um aplicativo apresenta um comportamento inadequado.

A detecção dos erros descritos no segundo item (que deve ser baixa se você tiver implementado todas as proteções), requer uma configuração específica. Por padrão, o Anthos Config Management grava erros nos registros (encontrados no Cloud Logging). Os erros também são exibidos na página do console do Anthos Config Management. Geralmente, nem os registros nem o console são suficientes para detectar erros, porque você provavelmente não os monitora o tempo todo. A maneira mais simples de automatizar a detecção de erros é executar o comando nomos status, que informa se há um erro em um cluster.

Você também pode configurar uma solução mais avançada com alertas automáticos para erros. O Anthos Config Management expõe métricas no formato do Prometheus. É possível usar o Prometheus para extrair essas métricas, configurar a importação de métricas do Prometheus para o Cloud Monitoring ou usar qualquer solução de monitoramento compatível com o formato do Prometheus. Para mais informações, consulte Como monitorar o Anthos Config Management.

Depois que você tiver as métricas do Anthos Config Management no seu sistema de monitoramento, crie um alerta para notificar quando a métrica gkeconfig_monitor_errors for maior que 0. Para mais informações, consulte como gerenciar políticas de alertas do Cloud Monitoring ou regras de alerta para o Prometheus.

Resumo dos mecanismos para lançamentos seguros com o Anthos Config Management

A tabela a seguir resume os vários mecanismos descritos anteriormente neste documento. Nenhum desses mecanismos é exclusivo. É possível usar alguns deles ou todos para diferentes propósitos.

Mecanismo Indicações de uso Não é bom para Exemplo de caso de uso:
IDs e tags de confirmação do Git Use IDs ou tags de confirmação Git específicas para controlar com precisão quais alterações de cluster serão aplicadas. Não use IDs de confirmação do Git ou tags para diferenças de longa duração entre clusters. Use seletores de cluster. Todos os clusters estão configurados para aplicar a confirmação 12345 do Git. Você faz uma alteração com uma nova confirmação, abcdef, que pretende testar. Você altera a configuração de um único cluster para usar essa nova confirmação e validar a alteração.
Ramificações do Git Use várias ramificações do Git quando quiser implantar a mesma alteração em vários ambientes, um após o outro. Não use várias ramificações do Git para diferenças de longa duração entre os clusters. As ramificações irão divergir e será difícil mesclá-las novamente. Primeiro, mescle a alteração na ramificação de preparação, que será escolhida pelos clusters de preparo.
Em seguida, mescle a alteração na ramificação mestre, onde ela será selecionada por clusters de produção.
Seletores de cluster e seletores de namespace Use seletores para diferenças de longa duração entre clusters e namespaces. Não use seletores para um lançamento gradual em vários ambientes. Se você quiser, primeiro, testar uma modificação na preparação para, depois, implantá-la na produção, use ramificações do Git separadas. Se as equipes de aplicativo precisarem de acesso total aos clusters de desenvolvimento, mas tiverem somente acesso de leitura a clusters de produção, use o objeto ClusterSelector para aplicar as políticas de RBAC corretas apenas aos clusters relevantes.
Avaliações de peering Use avaliações de peering para garantir que as equipes relevantes aprovem as alterações. Revisores humanos não detectam todos os erros, especialmente itens como erros de sintaxe. Sua organização exige que a equipe de segurança avalie alterações de configuração que afetam vários sistemas. Peça para um membro da equipe de segurança avaliar as alterações.
Testes automatizados no pipeline de integração contínua Use testes automatizados para detectar erros nas alterações sugeridas. Os testes automatizados não podem substituir totalmente um revisor humano. Use os dois Executar um comando nomos vet em todas as alterações sugeridas confirma que o repositório é uma configuração válida do Anthos Config Management.
Policy Controller Aplique políticas em toda a organização e implemente proteções diretamente no nível do servidor da API Kubernetes. O Policy Controller não pode ser usado para criar, atualizar ou excluir políticas. Esse é o papel do Anthos Config Management. O Policy Controller só pode aplicar políticas. A equipe de segurança usa o Anthos Config Management para criar uma restrição do Policy Controller e impedir que os usuários criem contêineres com privilégios, mesmo em namespaces gerenciados diretamente pelas equipes de aplicativo.
Teste as alterações em relação às restrições do Policy Controller. Verifique se o Policy Controller não está rejeitando alterações quando o Anthos Config Management as aplica. Testar alterações em relação às restrições do Policy Controller em um pipeline de integração contínua não substitui a ativação do Policy Controller nos clusters. Cada namespace precisa ter um rótulo "equipe" para identificar o proprietário. Um usuário quer criar um novo namespace e esquece de adicionar esse rótulo a essa alteração sugerida. O pipeline de integração contínua detecta o erro antes que um humano revise a alteração.
Monitorar erros de sincronização Verifique se o Anthos Config Management realmente aplica as alterações aos clusters. Os erros de sincronização ocorrem apenas se o Anthos Config Management tentar aplicar um repositório inválido ou se o servidor da API Kubernetes rejeitar alguns dos objetos. Se você não codificou todas as restrições nas políticas do Policy Controller, os recursos que violarem essas restrições não serão detectados. Um usuário ignora todos os testes e revisões e confirma uma alteração inválida no repositório do Anthos Config Management. Essa alteração não pode ser aplicada aos clusters. Se você estiver monitorando erros de sincronização, será alertado caso ocorra um erro.

Exemplo de estratégia de lançamento

Nesta seção, usamos os conceitos apresentados no restante deste artigo para ajudar você a criar uma estratégia de implantação completa em todos os clusters da sua organização. Essa estratégia pressupõe que você tenha frotas separadas para desenvolvimento, preparação e produção (como mostrado no Exemplo de frota 1 da abordagem 1).

.

Nessa situação, você configura cada cluster para sincronizar com o repositório Git do Anthos Config Management usando uma confirmação Git específica. A implantação de uma alteração em uma determinada frota é um processo de quatro etapas:

  1. Atualize um único cluster (o "canário") na frota para usar a nova confirmação primeiro.
  2. Confirme que tudo funciona conforme esperado ao executar testes e monitorar o lançamento.
  3. Atualize o restante dos clusters na frota.
  4. Confirme novamente que tudo está funcionando conforme esperado.

Para implantar uma alteração em todos os clusters, repita esse processo para cada frota. Tecnicamente, é possível aplicar esse método a qualquer confirmação do Git de qualquer ramificação. No entanto, sugerimos que você adote o seguinte processo para identificar problemas no início do processo de revisão:

  1. Quando alguém abrir uma solicitação de alteração no repositório Git do Anthos Config Management, implante essa alteração em um dos clusters de desenvolvimento.
  2. Se a solicitação de alteração for aceita e mesclada na ramificação principal, execute a implantação completa em todas as frotas, conforme descrito anteriormente.

Embora algumas alterações possam segmentar apenas uma frota específica, recomendamos que você implante todas as alterações posteriormente em todas as frotas. Essa estratégia elimina o problema de rastrear qual frota precisa ser sincronizada com qual confirmação. Preste atenção especial às alterações que visam apenas a frota de produção porque testes adequados não terão sido realizados nas frotas anteriores. Por exemplo, isso significa esperar mais para que os problemas apareçam entre a implantação nos clusters canário e no restante dos clusters.

Em suma, uma implantação completa tem a seguinte aparência:

  1. Alguém abre uma solicitação de alteração.
  2. Testes e validações automatizados são executados, e uma revisão manual é feita.
  3. Você aciona um job manualmente para implantar a alteração no cluster canário na frota de desenvolvimento. Testes automatizados de ponta a ponta são executados neste cluster.
  4. Se estiver tudo certo, você deve mesclar a solicitação de mudança na ramificação principal.
  5. A mescla aciona um job automatizado para implantar a confirmação nova da ramificação principal no cluster canário na frota de desenvolvimento. Testes automatizados de ponta a ponta são executados neste cluster para detectar possíveis incompatibilidades entre duas solicitações de alteração que foram criadas e mescladas aproximadamente ao mesmo tempo.
  6. Os jobs a seguir são executados um após o outro (você os aciona manualmente ou após um horário predefinido para permitir os relatórios de regressões dos usuários):
    1. Implante em todos os clusters da frota de desenvolvimento.
    2. Execute testes e validações nos clusters da frota de desenvolvimento.
    3. Implante no cluster canário da frota de preparo.
    4. Execute testes e validações no cluster canário da frota de preparo.
    5. Implante em todos os clusters da frota de preparo.
    6. Execute testes e validações nos clusters da frota de preparo.
    7. Implante no cluster canário da frota de produção.
    8. Execute testes e validações no cluster canário da frota de produção.
    9. Implante em todos os clusters da frota de produção.
    10. Execute testes e validações nos clusters da frota de produção.

Processo completo de lançamento.

A seguir