Sobre os pacotes de frota

Esta página explica os pacotes de frota, a API FleetPackage e como eles se relacionam ao Config Sync.

Uma FleetPackage é uma API declarativa que permite gerenciar pacotes em uma frota. Um pacote de frota é um conjunto de manifestos YAML do Kubernetes que definem a configuração do cluster. Ao usar pacotes de frota, você pode implantar pacotes em um lançamento progressivo ou total em clusters registrados na sua frota.

Você define cada objeto FleetPackage uma vez e depois pode atualizar esse pacote com uma nova revisão. Quando você aplica uma nova revisão, o serviço de pacote de frota detecta essas mudanças e as implanta nos clusters.

Vantagens

Use pacotes de frota para implantar recursos do Kubernetes em clusters que estão registrados em uma frota. Depois de criar e aplicar um pacote de frota, ele implanta automaticamente os arquivos de configuração do Kubernetes no repositório do Git no novo cluster. Os pacotes de frota são baseados nos benefícios do Config Sync, como a correção automática de desvio, e oferecem as seguintes vantagens exclusivos:

  • Implantação automatizada de recursos:depois que você configura um pacote de frota, os recursos do Kubernetes a que ele aponta são implantados automaticamente pelo serviço de pacote de frota em todos os clusters.

  • Configurar novos clusters automaticamente: se você configurar um pacote de frota e depois adicionar novos clusters a uma frota, todos os recursos definidos pelo pacote de frota serão implantados automaticamente no novo cluster.

  • Gerenciar a configuração do Kubernetes em escala:em vez de gerenciar clusters um por um, use pacotes de frota para implantar recursos em uma frota inteira de clusters.

  • Minimize o impacto de mudanças incorretas:escolha um número máximo de clusters para implantar recursos de uma só vez. É possível monitorar de perto as mudanças em cada cluster para garantir que alterações incorretas não afetem toda a frota.

  • Simplifique a configuração do Config Sync:os pacotes de frota usam o Cloud Build para autenticação no Git, o que significa que você autentica uma vez por projeto em vez de uma vez por objeto RootSync ou RepoSync.

Talvez seja melhor usar o Config Sync com objetos RootSync ou RepoSync em vez de pacotes de frota se um ou mais dos seguintes cenários se aplicarem a você:

  • Você gerencia um pequeno número de clusters.

  • Você precisa de mais controle sobre como os recursos são implantados nos clusters, além do que a API de pacote de frota oferece com rótulos e variantes.

Requisitos e limitações

  • Somente os repositórios do Git são compatíveis como fonte de verdade ao configurar um pacote de frota.

  • Os recursos do Kubernetes armazenados no Git precisam representar o estado final do recurso. Não há suporte para sobreposições adicionais para transformar o recurso armazenado no Git. Para mais informações sobre as diferenças entre esses recursos, consulte Prática recomendada: criar repositórios WET.

  • A API FleetPackage está disponível apenas na região us-central1. Ainda é possível implantar em clusters em regiões diferentes, mas é necessário configurar o Cloud Build e a CLI gcloud em us-central1.

Arquitetura

É possível usar a API FleetPackage para implantar manifestos do Kubernetes em uma frota de clusters. A API FleetPackage usa o Cloud Build para sincronizar e buscar recursos do Kubernetes no seu repositório do Git. O serviço de pacote de frota implanta esses recursos nos clusters.

Diagrama que mostra o fluxo de recursos do Kubernetes na sincronização do Git com uma frota de clusters

Exemplos de casos de uso

É possível usar pacotes de frota para implantar recursos de um repositório do Git em toda a frota de clusters. Também é possível configurar o pacote da frota para controlar como, onde e que tipo de recursos são implantados.

A seção a seguir mostra exemplos de diferentes configurações de FleetPackage. Para mais informações detalhadas sobre como aplicar pacotes de frota, consulte Implantar pacotes de frota.

Implantação em todos os clusters de uma frota

O FleetPackage a seguir usa uma estratégia contínua para implantar recursos do Kubernetes em três clusters por vez e segmenta todos os clusters em uma frota:

resourceBundleSelector:
  cloudBuildRepository:
    name: projects/my-project/locations/us-central1/connections/my-connection/repositories/my-repo
    tag: v1.0.0
    serviceAccount: projects/my-project/serviceAccounts/my-service-account@my-project.iam.gserviceaccount.com
target:
  fleet:
    project: projects/my-project
rolloutStrategy:
  rolling:
    maxConcurrent: 3

Implantação em um subconjunto de clusters

O FleetPackage a seguir usa um seletor de rótulos para implantar recursos do Kubernetes apenas em clusters com o rótulo de associação country que corresponde a "us" na frota:

resourceBundleSelector:
  cloudBuildRepository:
    name: projects/my-project/locations/us-central1/connections/my-connection/repositories/my-repo
    tag: v1.0.0
    serviceAccount: projects/my-project/serviceAccounts/my-service-account@my-project.iam.gserviceaccount.com
target:
  fleet:
    project: projects/my-project
    selector:
      matchLabels:
        country: "us"
rolloutStrategy:
  rolling:
    maxConcurrent: 3

Implantação de recursos variantes em um cluster

Para este exemplo, no repositório do Git, você tem uma pasta chamada "deployments" que contém duas especificações de implantação diferentes:

Réplicas: 3

    # small.yaml
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: nginx-deployment
      labels:
        app: nginx
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
          - name: nginx
            image: nginx:1.14.2
            ports:
            - containerPort: 80

Réplicas: 10

    # large.yaml
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: nginx-deployment
      labels:
        app: nginx
    spec:
      replicas: 10
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
          - name: nginx
            image: nginx:1.14.2
            ports:
            - containerPort: 80

É possível usar variantes para implantar as implantações "pequena" ou "grande" em clusters diferentes. Cada cluster tem um rótulo de nginx-size=small ou nginx-size=large.

O FleetPackage neste exemplo seria semelhante ao seguinte:

resourceBundleSelector:
  cloudBuildRepository:
    name: projects/my-project/locations/us-central1/connections/my-connection/repositories/my-repo
    tag: v1.0.0
    serviceAccount: projects/my-project/serviceAccounts/my-service-account@my-project.iam.gserviceaccount.com
    path: deployments
    variantsPattern: "*.yaml"
rolloutStrategy:
  rolling:
    maxConcurrent: 2
target:
  fleet:
    project: projects/my-project
variantSelector:
  variantNameTemplate: ${membership.labels['nginx-size']}

A seguir

Implantar pacotes de frota