À propos des packages de parc

Cette page explique les packages de parc, l'API FleetPackage et leur lien avec Config Sync.

FleetPackage est une API déclarative qui vous permet de gérer des packages sur un parc. Un package de parc est un ensemble de fichiers manifestes YAML Kubernetes qui définissent la configuration du cluster. Les packages de parc vous permettent de déployer des packages en une seule fois ou de manière progressive sur les clusters enregistrés dans votre parc.

Vous définissez chaque objet FleetPackage une seule fois, puis vous pouvez mettre à jour ce package avec une nouvelle révision. Lorsque vous appliquez une nouvelle révision, le service de package de parc récupère ces modifications et les déploie sur vos clusters.

Avantages

Utilisez des packages de parc pour déployer des ressources Kubernetes sur des clusters enregistrés dans un parc. Une fois que vous avez créé et appliqué un package de parc, il déploie automatiquement les fichiers de configuration Kubernetes du dépôt Git sur le nouveau cluster. Les packages de parc s'appuient sur les avantages de Config Sync, comme la correction automatique de la dérive, et offrent les avantages uniques suivants :

• Automatiser le déploiement des ressources : une fois que vous avez configuré un package de parc, les ressources Kubernetes auxquelles il fait référence sont automatiquement déployées par le service de package de parc sur tous les clusters.

• Configurer automatiquement les nouveaux clusters : si vous configurez un package de parc, puis que vous ajoutez ultérieurement des clusters à un parc, toutes les ressources définies par le package de parc sont automatiquement déployées sur le nouveau cluster.

• Gérez la configuration Kubernetes à grande échelle : au lieu de gérer les clusters un par un, utilisez des packages de parc pour déployer des ressources sur l'ensemble d'un parc de clusters.

• Minimisez l'impact des modifications incorrectes : choisissez un nombre maximal de clusters dans lesquels déployer des ressources à la fois. Vous pouvez surveiller de près les modifications apportées à chaque cluster pour vous assurer que les modifications incorrectes n'ont pas d'impact sur l'ensemble de votre parc.

• Simplifier la configuration de Config Sync : les packages de parc utilisent Cloud Build pour s'authentifier auprès de Git. Cela signifie que vous vous authentifiez une seule fois par projet au lieu d'une fois par objet RootSync ou RepoSync.

Vous préférerez peut-être utiliser Config Sync avec des objets RootSync ou RepoSync plutôt que des packages de parc si l'un ou plusieurs des scénarios suivants s'appliquent à votre cas :

• Vous gérez un petit nombre de clusters.

• Vous avez besoin de plus de contrôle sur la façon dont les ressources sont déployées sur vos clusters, au-delà de ce que l'API de package de parc fournit avec les libellés et les variantes.

Conditions requises et limites

• Seuls les dépôts Git sont acceptés comme source de vérité lors de la configuration d'un package de parc.

• Les ressources Kubernetes stockées dans Git doivent représenter l'état final de la ressource. Les calques supplémentaires permettant de transformer la ressource stockée dans Git ne sont pas acceptés. Pour en savoir plus sur les différences entre ces ressources, consultez Bonnes pratiques : créer des dépôts WET.

• L'API FleetPackage n'est disponible que dans la région us-central1. Vous pouvez toujours déployer des clusters dans différentes régions, mais vous devez configurer Cloud Build et la gcloud CLI dans us-central1.

Architecture

Vous pouvez utiliser l'API FleetPackage pour déployer des fichiers manifestes Kubernetes sur un parc de clusters. L'API FleetPackage utilise Cloud Build pour synchroniser et récupérer les ressources Kubernetes de votre dépôt Git. Le service de package de parc déploie ensuite ces ressources sur vos clusters.

Exemples de cas d'utilisation

Vous pouvez utiliser des packages de parc pour déployer des ressources à partir d'un dépôt Git sur l'ensemble de votre parc de clusters. Vous pouvez également configurer votre package de parc pour contrôler comment, où et quel type de ressources sont déployées.

La section suivante présente des exemples de différentes configurations FleetPackage. Pour en savoir plus sur l'application des packages de parc, consultez Déployer des packages de parc.

Déploiement sur tous les clusters d'un parc

L'FleetPackage suivant utilise une stratégie Rolling pour déployer des ressources Kubernetes sur trois clusters à la fois et cible tous les clusters d'un parc :

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

Déploiement sur un sous-ensemble de clusters

L'objet FleetPackage suivant utilise un sélecteur de libellés pour déployer des ressources Kubernetes uniquement sur les clusters dont le libellé d'appartenance country correspond à "us" dans le parc :

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

Déploiement des ressources de variantes dans un cluster

Dans cet exemple, votre dépôt Git contient un dossier nommé "deployments" (déploiements) qui contient deux spécifications de déploiement différentes :

    # 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
    

    # 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
    

Vous pouvez utiliser des variantes pour déployer les déploiements "petits" ou "grands" sur différents clusters. Chaque cluster est associé à un libellé nginx-size=small ou nginx-size=large.

Dans cet exemple, FleetPackage ressemblerait à ce qui suit :

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']}

Étapes suivantes

Déployer des packages de parc