Pour en savoir plus sur les versions, consultez les notes de version de Distributed Cloud Connected.

Utiliser des packages de parc dans Distributed Cloud connecté

Cette page explique comment utiliser les packages de parc Config Sync dans votre environnement Google Distributed Cloud connecté. Les packages de parc sont un outil qui utilise un dépôt Git comme source unique d'informations pour la configuration de votre cluster.

Les packages de parc dans Distributed Cloud connecté utilisent la même technologie et les mêmes commandes sous-jacentes que les clusters Google Kubernetes Engine standards. La documentation GKE explique comment créer et gérer des packages de parc sur la page Déployer des packages de parc. Cette page explique comment adapter ce guide à votre environnement Distributed Cloud connecté.

Les sections suivantes expliquent ce que vous devez faire différemment pour Distributed Cloud connecté et les étapes de la documentation GKE que vous pouvez suivre sans modification.

Conditions requises

L'utilisation des packages de parc Config Sync dans Distributed Cloud connecté est soumise aux conditions suivantes :

Étant donné que le contrôleur de déploiement réside dans le cloud, votre dépôt Git doit être accessible sur l'Internet public. Les serveurs Git internes ou sur site qui ne sont pas exposés publiquement ne sont pas compatibles.
Distributed Cloud connecté n'est compatible qu'avec l'utilisation de la fédération d'identité de charge de travail de parc pour l'authentification auprès des Google Cloud services. Les autres méthodes d'authentification Config Sync, telles que les clés SSH ou les cookies, ne sont pas compatibles avec la connexion entre vos clusters et le dépôt de bundle versionné. Pour en savoir plus, consultez la section Authentification du cluster Workload Identity.
Tous les clusters d'un parc doivent appartenir au même projet. Distributed Cloud connecté n'est pas compatible avec l'enregistrement de clusters dans plusieurs projets dans un seul projet central pour la gestion du parc.
Vos fichiers manifestes Kubernetes doivent respecter les limites de charge de travail de Distributed Cloud connecté. Les fichiers manifestes qui ne respectent pas ces restrictions sont bloqués par le contrôleur d'admission du cluster.
Les packages de parc nécessitent Config Sync version 1.16.0 ou ultérieure.

Comportement du système

Les packages de parc dans Distributed Cloud connecté présentent les comportements suivants :

Les packages de parc transforment vos fichiers manifestes Kubernetes en images OCI versionnées. Ces images sont stockées dans un dépôt Artifact Registry géré nommé fleet-packages, qui est créé automatiquement dans votre projet. Vos clusters extraient ces images directement du dépôt pour garantir une diffusion cohérente et fiable.
Les packages de parc héritent du comportement de correction de dérive de Config Sync. Les modifications manuelles apportées aux ressources d'un cluster sont automatiquement écrasées pour correspondre aux bundles OCI versionnés.
Si un cluster Distributed Cloud connecté passe en mode de survie, l'agent Config Sync continue d'appliquer localement la dernière configuration synchronisée. Toutefois, les nouveaux déploiements ou mises à jour du package de parc sont mis en pause jusqu'à ce que la connectivité cloud soit rétablie.
Les packages de parc héritent du comportement d'élagage automatique des ressources de Config Sync. Lorsque vous créez un tag dans votre dépôt Git et que vous mettez à jour la configuration du package de parc avec le nouveau tag pour lancer une synchronisation, l'agent Config Sync supprime la ressource correspondante de votre cluster si vous supprimez un fichier manifeste de votre dépôt Git.
Si plusieurs packages de parc gèrent la même ressource, un conflit de propriété se produit. Si vous tentez de supprimer un package de parc alors qu'il est en conflit de propriété, la suppression peut être bloquée. Pour résoudre ce problème, modifiez l'un des packages de parc en conflit afin de supprimer la ressource en conflit avant de tenter de supprimer le package.

Conditions préalables pour Distributed Cloud connecté

Avant de suivre les étapes de la section Déployer des packages de parc, assurez-vous que votre environnement Distributed Cloud connecté et vos autorisations utilisateur sont correctement configurés.

Mise en réseau et sécurité

Votre environnement réseau doit répondre aux exigences suivantes :

VPC Service Controls. Si votre projet est protégé par un périmètre de service VPC, assurez-vous que vos agents de service Cloud Build et Config Delivery, par exemple service-PROJECT_NUMBER@gcp-sa-configdelivery.iam.gserviceaccount.com, sont autorisés à traverser le périmètre et à extraire des images d'Artifact Registry. Pour en savoir plus, consultez la section Configurer l'intégration de VPC Service Controls.
Accès sortant. Vos clusters Distributed Cloud connecté doivent avoir un accès sortant à us-central1-docker.pkg.dev. Les packages de parc stockent vos bundles de fichiers manifestes sous forme d'images OCI dans Artifact Registry. Les clusters doivent pouvoir extraire ces images directement d'Artifact Registry.

Configuration du dépôt

Le dépôt Artifact Registry contenant vos bundles de fichiers manifestes doit se trouver dans le même projet que le package de parc et dans la région us-central1.

Autorisations requises

Pour effectuer les étapes dans l'environnement Distributed Cloud connecté, vous devez disposer des rôles IAM suivants sur le projet :

Administrateur Config Delivery (roles/configdelivery.admin) : requis pour créer et gérer des packages de parc et des déploiements
Administrateur Developer Connect (roles/developerconnect.admin) : requis pour créer et gérer des connexions de dépôt
Administrateur IAM du projet (roles/resourcemanager.projectIamAdmin) : requis pour accorder les rôles nécessaires au compte de service

Pour en savoir plus sur l'attribution de rôles, consultez la section Accorder, modifier et révoquer l'accès à des ressources.

API requises

Vous devez activer les API pour les connexions de dépôt et la communication sécurisée avec les clusters Distributed Cloud connecté. Pour activer les API requises, exécutez la commande gcloud services enable suivante :

gcloud services enable anthosconfigmanagement.googleapis.com \
    configdelivery.googleapis.com \
    cloudbuild.googleapis.com \
    connectgateway.googleapis.com \
    developerconnect.googleapis.com \
    artifactregistry.googleapis.com

Ces API sont requises pour les composants suivants :

anthosconfigmanagement.googleapis.com: gère l'agent Config Sync sur vos clusters
configdelivery.googleapis.com: coordonne le déploiement des ressources Kubernetes dans votre parc de clusters
cloudbuild.googleapis.com: récupère vos fichiers manifestes Kubernetes à partir de Git et les regroupe dans des bundles versionnés
connectgateway.googleapis.com: fournit une connexion sécurisée entre le service Config Delivery et vos clusters Distributed Cloud connecté
developerconnect.googleapis.com: permet des connexions sécurisées à votre hôte de dépôt Git externe
artifactregistry.googleapis.com: stocke les bundles de packages versionnés sous forme d'images OCI dans votre projet

Paramètres d'environnement par défaut

L'API Config Delivery pour les packages de parc n'est compatible qu'avec la région us-central1. Pour vous assurer que vos commandes sont correctement routées, utilisez la gcloud config set commande pour définir votre projet et votre emplacement par défaut :

Définissez le projet par défaut :
```
gcloud config set project PROJECT_ID
```
Remplacez PROJECT_ID par votre Google Cloud projet ID.
Définissez l'emplacement par défaut pour les packages de parc. Toutes les connexions de dépôt Cloud Build utilisées avec les packages de parc doivent se trouver dans la région us-central1.
```
gcloud config set config_delivery/location us-central1
```

Différences de procédure

Le tableau suivant explique comment appliquer les étapes de la section Déployer des packages de parc à votre environnement Distributed Cloud connecté.

Étape standard	Ajustement pour Distributed Cloud connecté
Enregistrer des clusters dans le parc	Ignorez cette étape. Les clusters Distributed Cloud connecté sont automatiquement enregistrés dans un parc de votre projet lors de leur création.
Installer Config Sync	Suivez les étapes standards, mais nous vous recommandons d'utiliser la Installer sur l'ensemble du parc (par défaut du parc) méthode. Configurez cette méthode dans les paramètres Hub ou Parc de la Google Cloud console. Cette implémentation garantit que tous les nœuds Distributed Cloud connecté existants ou futurs de votre zone reçoivent automatiquement l'agent Config Sync. Pour le type de membre d'authentification, vous devez sélectionner Workload Identity. Le compte de service que vous utilisez pour Workload Identity doit disposer du rôle `roles/artifactregistry.reader` sur le projet afin que l'agent Config Sync puisse extraire des bundles de fichiers manifestes du dépôt `fleet-packages` géré.
Créer un compte de service	Suivez les instructions pour créer un compte de service pour Cloud Build et accorder les autorisations requises. Le compte de service doit se trouver dans le même projet que votre package de parc. Nous vous recommandons d'utiliser les commandes suivantes : Créez le compte de service en exécutant la `gcloud iam service-accounts create` commande : gcloud iam service-accounts create "`SERVICE_ACCOUNT_NAME`" Remplacez `SERVICE_ACCOUNT_NAME` par le nom que vous souhaitez donner au compte de service. Ajoutez les rôles Identity and Access Management obligatoires en exécutant la `gcloud projects add-iam-policy-binding` commande pour chacun des rôles suivants. Pour en savoir plus sur IAM, consultez la présentation d'IAM. `roles/configdelivery.resourceBundlePublisher` : permet au compte de service de créer et de gérer des bundles de ressources et des versions `roles/cloudbuild.connectionUser` : permet au compte de service d'utiliser la connexion de dépôt Cloud Build `roles/logging.logWriter` : permet au compte de service d'écrire des journaux de compilation `roles/artifactregistry.writer` : permet au compte de service d'envoyer des bundles de packages versionnés à Artifact Registry `roles/developerconnect.connectionUser` : permet au compte de service d'utiliser la connexion Developer Connect Le compte de service a également besoin d'une autorisation de lecture à partir de votre dépôt Git connecté sur votre fournisseur Git. Pour savoir comment autoriser la connexion, consultez la section Se connecter à un dépôt.
Identifier le nom d'appartenance	Lorsqu'une commande demande un `MEMBERSHIP_NAME`, utilisez le nom de votre cluster Distributed Cloud connecté. Vous pouvez trouver le nom du cluster en exécutant la `gcloud container fleet memberships list` commande.
Identifier un cluster	Avant de cibler un cluster avec un package de parc, si vos charges de travail nécessitent une configuration réseau au niveau de l'hôte, telle que HugePages ou SR-IOV, appliquez et vérifiez les `NodeSystemConfigUpdate` ressources sur chaque nœud du cluster.
Identifier les tags Git	Le contrôleur de déploiement nécessite que les tags Git soient au format de version sémantique complet (`major.minor.patch`). Par exemple, `v1.0.0` est valide, mais `v1` ne l'est pas.
Cibler des clusters spécifiques	Bien que les clusters soient enregistrés automatiquement, vous devez ajouter manuellement des étiquettes aux appartenances au cluster si vous souhaitez cibler des sous-ensembles de clusters à l'aide de sélecteurs d'étiquettes.
Stratégies de déploiement	Utilisez des étiquettes et des variantes pour cibler des clusters spécifiques. Pour Distributed Cloud connecté, les variables de métadonnées d'appartenance, telles que le projet et l'emplacement, utilisées dans vos modèles de variantes font référence aux ressources côté cloud associées à votre cluster Distributed Cloud connecté. Les métadonnées d'appartenance spécifiques à Distributed Cloud suivantes peuvent être utilisées dans les modèles de variantes : `cluster_name` : nom de votre cluster Distributed Cloud connecté `location` : région associée au cluster Google Cloud `project` : ID du projet dans lequel le cluster est enregistré `labels` : toutes les étiquettes que vous avez appliquées à l'appartenance au cluster

Procédures partagées

Pour les tâches opérationnelles suivantes, la syntaxe des commandes et le comportement des services sont les mêmes pour Distributed Cloud connecté et GKE standard. Lorsque vous suivez ces instructions, utilisez les paramètres et les valeurs définis dans le tableau de la section Différences de procédure de ce document.

Créer un package de parc : définissez la ressource FleetPackage pour extraire et déployer votre configuration.
Mettre à jour un package de parc : modifiez votre package pour déployer des modifications ou mettre à jour des paramètres.
Gérer les déploiements de packages de parc: Suspendez, reprenez ou annulez les déploiements actifs.
Inspecter les bundles de ressources et les versions: déboguez la génération et la gestion des versions des variantes. Les bundles de ressources sont des conteneurs pour vos configurations, et les versions sont des instances versionnées de ces bundles. Pour vérifier que la diffusion sur votre matériel Distributed Cloud connecté a réussi, utilisez la gcloud container fleet memberships get-credentials commande pour accéder à votre cluster, puis utilisez kubectl pour inspecter l'état RootSync sur le cluster.
Supprimer un package de parc: supprimez un package de parc et ses ressources gérées. Pour garantir une suppression propre, vérifiez que les objets RootSync gérés associés au package de parc sont supprimés de vos clusters.

Surveillance et dépannage

Pour surveiller plus efficacement les déploiements, utilisez l'indicateur --format avec la commande gcloud afin d'obtenir des messages d'état détaillés lors d'un déploiement.

Par exemple, exécutez la commande gcloud container fleet packages rollouts describe suivante pour afficher un message d'état détaillé pour chaque cluster de votre parc :

gcloud container fleet packages rollouts describe ROLLOUT_NAME \
    --fleet-package=FLEET_PACKAGE_NAME \
    --format=json

Remplacez les valeurs suivantes :

ROLLOUT_NAME : nom du déploiement.
FLEET_PACKAGE_NAME : nom du package de parc.

Si une compilation échoue ou est bloquée, vous trouverez un lien vers les journaux de streaming de la tâche Cloud Build dans le résultat de la gcloud container fleet packages list commande. Si un déploiement reste à l'état PENDING ou STALLED, vérifiez la connectivité de votre matériel Distributed Cloud connecté, comme décrit dans la section Résoudre les problèmes liés à Distributed Cloud connecté.

Pour en savoir plus sur le diagnostic des erreurs liées à Cloud Build, consultez la section Résoudre les erreurs de compilation.

Vérifier l'état de la synchronisation sur le cluster

Pour vérifier que votre cluster se synchronise correctement avec le package de parc, examinez la ressource RootSync sur le cluster. Le nom de l'objet RootSync sur le cluster est identique au FLEET_PACKAGE_NAME que vous avez choisi pour votre package.

Pour vérifier l'état, exécutez la commande suivante :

kubectl get rootsync FLEET_PACKAGE_NAME -n config-management-system

Une synchronisation réussie affiche l'état SYNCED. Si l'état Error s'affiche, exécutez la commande suivante pour obtenir plus de détails :

kubectl describe rootsync FLEET_PACKAGE_NAME -n config-management-system

Pour en savoir plus, consultez la section Surveiller les objets RootSync et RepoSync dans la documentation GKE.

Pour obtenir de l'aide sur le décodage de codes d'erreur spécifiques dans le résultat, consultez la section Référence des erreurs Config Sync.

Utiliser des packages de parc dans Distributed Cloud connecté Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.