Installer et gérer Apigee hybrid avec des charts Helm
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Ce document vous guide tout au long du processus détaillé d'installation d'Apigee hybrid v1.10 à l'aide de charts Helm.
Version
Les charts Helm Apigee hybrid sont destinés à être utilisés avec Apigee hybrid v1.10.x. Consultez la page Historique des versions Apigee hybrid pour obtenir la liste des versions d'Apigee hybrid.
Cette version n'est compatible qu'avec Apigee hybrid version 1.10.5.
Cette version est compatible avec les protocoles suivants :
Nouvelles installations Apigee hybrid.
Installations Apigee hybrid existantes mises à niveau vers la version 1.10.5 et migrées vers la gestion Helm à l'aide de l'outil de migration Helm Apigee hybrid.
Cette version est compatible avec les protocoles suivants :
Les charts Helm ne sont pas entièrement compatibles avec les CRD. Nous allons donc utiliser la commande kubectl -k pour les installer et les mettre à niveau.
Notre objectif est de suivre les bonnes pratiques de la communauté et de Google en matière de gestion Kubernetes. Les déploiements CRD via Helm n'ont pas encore atteint un état communautaire, où nous constatons une assistance étendue ou des demandes pour un tel modèle. Par conséquent, la gestion des objets CRD Apigee doit être effectuée à l'aide de kubectl, comme indiqué dans ce document.
Dans apigeectl, nous avons utilisé des fichiers dans overrides.yaml pour les comptes de service et les certificats. Cependant, Helm ne permet pas de référencer des fichiers en dehors du répertoire de charts. Choisissez l'une des options suivantes pour les fichiers de compte de service et de certificat :
Placez des copies des fichiers pertinents dans chaque répertoire de charts.
Créez des liens symboliques dans chaque répertoire de charts pour chaque fichier ou un dossier. Helm suit des liens symboliques hors du répertoire de charts, mais génère un avertissement semblable au suivant : apigee-operator/gsa -> ../gsa
Utilisez les secrets Kubernetes. Par exemple, pour les comptes de service :
Ce tableau répertorie les ressources et les autorisations requises pour Kubernetes et Apigee.
Pour filtrer ce tableau, effectuez une ou plusieurs des opérations suivantes : sélectionnez une catégorie, saisissez un terme de recherche ou cliquez sur un en-tête de colonne pour trier les résultats.
L'installation des composants s'effectue de gauche à droite comme indiqué ci-dessous. Les composants empilés verticalement dans la figure peuvent être installés ensemble et dans n'importe quel ordre.
Une fois que vous avez installé un composant, vous pouvez le mettre à jour individuellement et à tout moment. Par exemple, une instance dupliquée, une mémoire, un processeur, etc.
Préparer l'installation d'Apigee hybrid avec des charts Helm
Créez l'espace de noms qui sera utilisé pour les ressources apigee.
Il doit correspondre au champ de l'espace de noms du fichier overrides.yaml. S'il n'est pas présent dans overrides.yaml, la valeur par défaut est apigee.
Vérifiez si l'espace de noms existe déjà :
kubectl get namespace apigee
Si l'espace de noms existe, le résultat inclut les éléments suivants :
NAME STATUS AGE
apigee Active 1d
Si l'espace de noms n'existe pas déjà, créez-le :
kubectl create namespace apigee
Créez l'espace de noms apigee-system utilisé par les ressources de l'opérateur Apigee.
Vérifiez si l'espace de noms existe déjà :
kubectl get namespace apigee-system
Si l'espace de noms n'existe pas déjà, créez-le :
kubectl create namespace apigee-system
Créez les comptes de service et attribuez-leur les rôles IAM appropriés. Apigee hybrid utilise les comptes de service suivants :
Compte de service
Rôles IAM
apigee-cassandra
Administrateur des objets de l'espace de stockage
apigee-logger
Rédacteur de journaux
apigee-mart
Agent Apigee Connect
apigee-metrics
Rédacteur de métriques Monitoring
apigee-runtime
Aucun rôle requis
apigee-synchronizer
Gestionnaire de synchronisateur Apigee
apigee-udca
Agent d'analyses Apigee
apigee-watcher
Agent d'exécution Apigee
Apigee fournit un outil, create-service-account, dans le répertoire apigee-operator/etc/tools :
Cet outil crée les comptes de service, attribue les rôles IAM à chaque compte et télécharge les fichiers de certificat au format JSON pour chaque compte.
Créez le répertoire dans lequel vous souhaitez télécharger les fichiers de certificat du compte de service. Vous le spécifierez dans la commande suivante à la place de SERVICE_ACCOUNTS_PATH.
Vous pouvez créer tous les comptes de service à l'aide d'une seule commande avec les options suivantes :
Si le résultat n'inclut pas l'ID du compte de service, activez l'accès au synchronisateur. Votre compte doit disposer du rôle IAM d'administrateur de l'organisation Apigee (roles/apigee.admin) pour effectuer cette tâche.
Vérifiez les libellés existants sur les nœuds de cluster.
Par défaut, Apigee planifie les pods de données sur les nœuds portant le libellé cloud.google.com/gke-nodepool=apigee-data et les pods d'exécution sont programmés sur les nœuds portant le libellé cloud.google.com/gke-nodepool=apigee-runtime. Vous pouvez personnaliser les libellés de votre pool de nœuds dans le fichier overrides.yaml.
Vérifiez qu'il est opérationnel en vérifiant l'état de l'environnement correspondant :
kubectl -n apigee get apigeeenv
NAME STATE AGE GATEWAYTYPE
apigee-org1-dev-xxx running 2d
Créez les certificats TLS. Vous devez fournir des certificats TLS pour la passerelle d'entrée d'exécution dans votre configuration Apigee hybrid.
Créez les certificats. Dans un environnement de production, vous devrez utiliser des certificats signés. Vous pouvez utiliser un certificat et une paire de clés ou un secret Kubernetes.
Pour l'installation de démonstration et de test, la passerelle d'exécution peut accepter les identifiants autosignés. Dans l'exemple suivant, openssl est utilisé pour générer les identifiants autosignés :
Vous devez installer un groupe d'environnements (hôte virtuel) à la fois. Spécifiez le groupe d'environnement avec --set envgroup=ENV_GROUP_NAME :
# repeat the following command for each env group mentioned in the overrides.yaml file
helm upgrade apigee-virtualhost-ENV_GROUP_NAME apigee-virtualhost/ \
--install \
--namespace apigee \
--atomic \
--set envgroup=ENV_GROUP_NAME \
-f overrides.yaml
Cela crée ApigeeRouteConfig (ARC) qui crée en interne ApigeeRoute une fois que l'observateur Apigee extrait les détails liés au groupe d'environnement du plan de contrôle. Par conséquent, vérifiez que l'état d'AR est en cours d'exécution :
kubectl -n apigee get arc
NAME STATE AGE
apigee-org1-dev-egroup 2d
kubectl -n apigee get ar
NAME STATE AGE
apigee-org1-dev-egroup-xxxxxx running 2d
Cas d'utilisation supplémentaires des charts Helm avec Apigee hybrid
Sauvegarde et restauration de bases de données Cassandra
Pour activer la sauvegarde, procédez comme suit :
Mettez à jour les détails de la sauvegarde Cassandra dans le fichier overrides.yaml :
La configuration multirégionale avec des charts Helm nécessite les mêmes conditions préalables que les procédures apigeectl actuelles. Pour plus d'informations, consultez la section Prérequis pour les déploiements multirégionaux.
La procédure de configuration d'Apigee hybrid pour une zone multirégionale est identique à la procédure existante via la configuration de l'hôte source multirégional, ainsi que la configuration du cluster Kubernetes et du contexte.
Configurer la première région
Procédez comme suit pour configurer la première région et vous préparer à configurer la deuxième région :
SEED_HOST_IP_ADDRESS par l'adresse IP de l'hôte source, par exemple 10.0.0.11.
DATACENTER_NAME par le nom du centre de données, par exemple dc-2.
RACK_NAME par le nom du rack, par exemple ra-1.
CLUSTER_NAME par le nom de votre cluster Apigee. La valeur par défaut est apigeecluster. Si vous utilisez un autre nom de cluster, vous devez spécifier une valeur pour cassandra.clusterName.
Cette valeur doit être identique dans toutes les régions.
Configurer la deuxième région
Pour configurer la nouvelle région, procédez comme suit :
Copiez votre certificat à partir du cluster existant vers le nouveau cluster.
Le nouveau certificat racine CA est utilisé par Cassandra et d'autres composants hybrides pour mTLS.
Par conséquent, il est essentiel de disposer de certificats cohérents dans l'ensemble du cluster.
Définissez le contexte sur l'espace de noms d'origine :
kubectl config use-context ORIGINAL_CLUSTER_NAME
Exportez la configuration actuelle de l'espace de noms dans un fichier :
kubectl get namespace apigee -o yaml > apigee-namespace.yaml
Exportez le secret apigee-ca vers un fichier :
kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
Définissez le contexte sur le nom du cluster de la nouvelle région :
kubectl config use-context NEW_CLUSTER_NAME
Importez la configuration de l'espace de noms dans le nouveau cluster. Veillez à mettre à jour l'espace de noms dans le fichier si vous utilisez un autre espace de noms dans la nouvelle région :
kubectl apply -f apigee-namespace.yaml
Importez le secret dans le nouveau cluster :
kubectl -n cert-manager apply -f apigee-ca.yaml
Utilisez les charts Helm pour installer Apigee hybrid dans la nouvelle région à l'aide des commandes des charts Helm suivantes (comme illustré dans la région 1) :
Une fois que tous les composants sont installés, configurez Cassandra sur tous les pods des nouveaux centres de données. Pour obtenir des instructions, consultez la page Configurer Apigee hybrid pour une zone multirégionale, sélectionnez votre plate-forme, faites défiler la page jusqu'à Configurer la nouvelle région, puis recherchez l'étape 5.
Une fois la réplication de données terminée et validée, mettez à jour les hôtes sources :
Supprimez multiRegionSeedHost: 10.0.0.11 de overrides-DATACENTER_NAME.yaml.
L'entrée multiRegionSeedHost n'est plus nécessaire une fois la réplication des données établie, et les adresses IP des pods sont susceptibles de changer au fil du temps.
Appliquez à nouveau la modification pour mettre à jour le RS de datastore apigee :
Au lieu de s'appuyer sur le dépôt Google Cloud public, vous pouvez éventuellement héberger les images en mode privé. Au lieu de remplacer chaque composant, vous pouvez ajouter des informations détaillées sur les remplacements :
hub: PRIVATE_REPO
Par exemple, si le hub suivant est fourni, le chemin d'accès de l'image sera automatiquement résolu :
hub: private-docker-host.com
comme ceci :
## an example of internal component vs 3rd party
containers:
- name: apigee-udca
image: private-docker-host.com/apigee-udca:1.10.5
imagePullPolicy: IfNotPresent
containers:
- name: apigee-ingressgateway
image: private-docker-host.com/apigee-asm-ingress:1.17.2-asm.8-distroless
imagePullPolicy: IfNotPresent
Cliquer pour développer la liste des images Apigee
Pour utiliser la fonctionnalité Rejets et tolérances de Kubernetes, vous devez définir la propriété de remplacement tolerations pour chaque composant Apigee hybrid.
Les composants suivants acceptent la définition des tolérances :
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2026/05/16 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2026/05/16 (UTC)."],[],[]]