Guide de l'utilisateur en version preview :
Version preview des nouvelles procédures d'installation et d'administration pour Apigee hybrid v1.8.
Dans ce document :
- Aperçu
- APERÇU
- Prérequis
- Installation de base d'Apigee hybrid
- Installation personnalisée d'Apigee hybrid
- Télécharger les fichiers de configuration
- Créer un espace de noms
- Utiliser des images Docker à partir de dépôts privés (facultatif)
- Configurer imagePullSecrets (facultatif)
- Configurer le proxy de transfert (facultatif)
- Spécifier des certificats TLS d'entrée
- Mettez à jour le déploiement d'entrée
- Configurer des comptes de service Google Cloud personnalisés
- Utiliser des identités de charge de travail
- Modifier les fichiers YAML des ressources
- Créer des ressources et un contrôleur d'initialisation
- Accorder des autorisations au compte de service du synchronisateur pour interagir avec le plan de contrôle
- Créer les composants du plan de données Apigee
- Attendre que les ressources démarrent
- Personnaliser l'installation pour cert-manager dans un espace de noms personnalisé
- Kustomize et composants
- Concepts
- Comprendre le script
- Structure des dossiers de configuration d'Apigee hybrid
- Stocker les clés de compte de service dans des vaults externes
- Mise à niveau d'Apigee hybrid
- Rollback Apigee hybrid
- Nettoyage
- Supprimer un environnement
- Installation multi-instances
Aperçu
Ce document est destiné aux persona d'opérateur Apigee (utilisateurs qui installent, gèrent et administrent les installations d'Apigee hybrid). Pour pouvoir suivre les instructions de ce document, un prérequis nécessaire est de maîtriser l'installation d'Apigee hybrid sur l'une des plates-formes Kubernetes compatibles. Il est recommandé de créer une organisation Apigee d'évaluation pour tenter les étapes ci-dessous.
Commentaires
Envoyez vos commentaires sur ce processus à l'adresse Apigee-hybrid-install-preview@google.com.
Présentation
La nouvelle expérience d'installation d'Apigee hybrid installe les composants Apigee à l'aide de kubectl et intègre l'installation et la gestion d'Apigee hybrid avec des outils d'orchestration de configuration Kubernetes tels que Kustomize. Les validations améliorées et la visibilité des composants installés permettent un meilleur débogage et améliorent le processus global d'installation.
Un script d'installation, apigee-hybrid-setup.sh, fournit un outil simple pour l'installation de base. Vous pouvez l'utiliser pour créer votre installation hybride, puis la modifier en fonction de vos besoins avec kubectl, ou créer votre installation hybride à partir de zéro à l'aide de kubectl.
Toutes les propriétés de configuration d'Apigee hybride sont stockées dans des fichiers YAML, un pour chaque composant principal. Cela permet un contrôle beaucoup plus précis de votre installation hybride sur votre environnement Kubernetes. Vous trouverez les fichiers de configuration et les scripts d'installation dans le dépôt GitHub.
Modifications apportées au nouveau processus d'installation
Apigee modifie le processus d'installation d'Apigee hybrid pour les raisons suivantes :
- La nouvelle méthode d'installation d'Apigee hybrid peut être intégrée aux outils CI/CD Kubernetes existants tels qu'Argo, Flux ou Anthos Config Management qui n'utilisent pas de fichier de configuration
overrides.yaml. - Apigee hybrid fournissait
apigeectl, un outil de création de modèles personnalisés qui génère les fichiers manifestes Kubernetes (entre autres) servant à installer et gérer Apigee hybrid dans les clusters Kubernetes. Le nouveau processus d'installation et de gestion offre une expérience semblable à celle d'autres éditeurs de logiciels. - Le nouveau processus permet une installation de base rapide en créant automatiquement des comptes de service avec les autorisations, certificats TLS, valeurs par défaut et autres éléments de base requis.
Prérequis
Avant d'utiliser cette version preview, vous devez remplir les conditions préalables suivantes :
Version bêta
Cette preview est destinée à fonctionner avec la version 1.8.x d'Apigee hybrid. Les versions ultérieures d'Apigee hybrid ne sont pas compatibles.
Configuration d'Apigee hybrid
Avant de procéder à l'installation réelle d'Apigee hybrid, vous devez suivre les instructions indiquées dans les sections suivantes de la documentation :
- Configuration du projet et de l'organisation
- Présentation des conditions préalables à l'installation d'Apigee hybrid.
- Étape 1 : Activez les API
- Étape 2 : Créez une organisation
- Étape 3 : Créer un environnement et un groupe d'environnements
- Configuration de l'environnement d'exécution hybride
Outils
En outre, vous devez télécharger et configurer les outils suivants sur votre poste de travail :
curldockerest requis pour exécuter le scriptapigee-hybrid-setup.sh. Suivez les instructions de la section Obtenir Docker pour installer Docker.envsubstdevrait être disponible sur la plupart des systèmes Linux/UNIX. Pour macOS et autres systèmes, suivez les instructions de ce dépôt.jqdoit être installé. Téléchargez jq.kptTéléchargez kpt.Version 1.23 ou ultérieure de
kubectl. Consultez la section Installer les outils : kubectl dans la documentation de Kubernetes.
Variables communes utilisées dans ce guide
Ce guide utilise les variables d'environnement suivantes dans plusieurs des étapes réalisées. Vous pouvez les définir en ligne de commande ou avec un script, ou remplacer le texte des commandes lorsque vous les saisissez.
APIGEE_NAMESPACE: votre espace de noms Apigee. Par défaut, il s'agit de la valeurapigee. Cependant, vous pouvez utiliser un espace de noms différent.CLUSTER_NAME: nom du cluster sur lequel vous installez Apigee hybrid. Il s'agit du cluster que vous créez à l'Étape 1 : Créer un cluster.CLUSTER_LOCATION: région de votre cluster. Les procédures décrites dans ce guide partent du principe que vous utilisez un cluster régional. Si vous utilisez un cluster zonal, reportez-vous aux instructions de l'Étape 1 : Créer un cluster.ENV_GROUP: nom du groupe d'environnements de votre installation Apigee hybrid. Il s'agit du groupe d'environnements que vous créez à l'Étape 3 : Créer un groupe d'environnements. Vous pouvez créer plusieurs groupes d'environnements.ENV_NAME: nom du groupe d'environnements de votre installation Apigee hybrid. Il s'agit du groupe d'environnements que vous créez à l'Étape 3 : Créer un groupe d'environnements. Vous pouvez créer plusieurs groupes d'environnements.INSTALL_DIR: répertoire dans lequel vous installez Apigee hybrid. Par défaut, il s'agit du sous-répertoireapigee-hybrid-install/du répertoire dans lequel vous téléchargez le programme d'installation, par exemple :/myhybrid/apigee-hybrid-install/. Il s'agit du répertoire racine de la structure de fichiers décrite dans la Structure des dossiers de configuration d'Apigee hybrid.INSTANCE_DIR: répertoire d'une instance Apigee hybrid spécifique. Par défaut, la première instance est nomméeinstance-1. Le répertoire d'instance est un sous-répertoire de${INSTALL_DIR}/overlays/instances/. Vous pouvez spécifier n'importe quel nom pour vos instances hybrid. Consultez la section Installation multi-instances.ORG_NAME: nom de votre organisation Apigee hybrid. Cette valeur doit être identique à l'ID du projet Google Cloud. Consultez l'Étape 2 : Créer une organisation.
Installation de base d'Apigee hybrid
Pour installer rapidement Apigee hybrid sans personnalisation intensive, vous pouvez utiliser la procédure suivante en deux étapes.
- Un environnement unique
- Un seul groupe d'environnements
- Un seul compte de service Google Cloud est créé et utilisé pour tous les composants individuels.
- Valeurs par défaut pour toutes les clés de chiffrement et tous les mots de passe.
Télécharger les fichiers de configuration
Téléchargez et préparez les fichiers de configuration en clonant le dépôt GitHub disponible à l'adresse https://github.com/apigee/apigee-hybrid-install/releases/tag/preview-1 :
Clonez le dépôt :
git clone https://github.com/apigee/apigee-hybrid-install.gitAccédez au répertoire du dépôt cloné :
cd apigee-hybrid-installCréez une branche à partir du tag preview-1 :
git branch preview-1 preview-1 git checkout preview-1Rendez le script d'installation exécutable :
chmod +x ./tools/apigee-hybrid-setup.shLe dépôt cloné présente une structure semblable à celle décrite dans la section Structure des dossiers de configuration d'Apigee hybrid :
Exécuter la configuration
Exécutez le script shell apigee-hybrid-setup.sh situé dans le dossier tools/.
./tools/apigee-hybrid-setup.sh --cluster-name $CLUSTER_NAME --cluster-region $CLUSTER_LOCATION --org $ORG_NAME --setup-all
Si vous rencontrez des erreurs, essayez d'exécuter le script une seconde fois.
Vous pouvez également utiliser les options suivantes :
--env $ENV_NAMEest le nom de l'environnement Apigee.--envgroup $ENV_GROUPest le groupe d'environnements.--ingress-domain $HOSTNAMEest le nom d'hôte que vous avez fourni pour votre groupe d'environnements.--gcp-project-id $PROJECT_IDest l'ID de votre projet Google Cloud.
Pour plus d'options, consultez la section Comprendre le script.
Toutes les erreurs d'exécution sont imprimées dans la sortie standard.
Une fois l'exécution du script terminée, vous avez réalisé l'installation de base d'hybrid. Vous pouvez tester votre installation en créant un exemple de proxy, comme indiqué dans la section Créer et déployer un proxy d'API.
Installation personnalisée d'Apigee hybrid
Pour les utilisateurs plus avancés souhaitant exercer un contrôle précis sur l'installation, vous pouvez suivre les étapes ci-dessous (pour la plupart des étapes indiquées ci-dessous, vous pouvez choisir d'effectuer l'étape manuellement ou d'utiliser le script shell pour l'automatiser) :
Télécharger les fichiers de configuration
Téléchargez et préparez les fichiers de configuration :
Cloner le dépôt GitHub à l'emplacement
https://github.com/apigee/apigee-hybrid-install/Le dépôt cloné présente une structure semblable à celle décrite dans la section Structure des dossiers de configuration d'Apigee hybrid :
cddans le répertoireapigee-hybrid-install/Rendez le script d'installation exécutable :
chmod +x ./tools/apigee-hybrid-setup.sh
Créer un espace de noms
Créez un espace de noms Kubernetes dans votre cluster contenant tous les composants du cluster Apigee.
kubectl create namespace apigee
Si vous choisissez un autre nom pour l'espace de noms, vous pouvez choisir de suivre l'une des trois options ci-dessous :
- (Option recommandée) Utilisez
--namespace={YOUR_NAMESPACE_NAME}lors du pré-remplissage des valeurs de la section Modifier les fichiers YAML des ressources. Exécutez les deux commandes suivantes :
Utilisez le paramètre
kptpour spécifier l'espace de noms Apigee :kpt fn eval "${INSTALL_DIR}/overlays/" \ --image gcr.io/kpt-fn/apply-setters:v0.2.0 -- \ APIGEE_NAMESPACE="${APIGEE_NAMESPACE}" # This is for replacing the namespace in istio discoveryAddress which cannot be # achieved with kptUtilisez
sedpour remplacer l'espace de noms dans istio discoveryAddress :sed -i -E -e "s/(discoveryAddress: apigee-ingressgateway-manager\.).*(\.svc:15012)/\1${APIGEE_NAMESPACE}\2/" "${INSTALL_DIR}/overlays/controllers/istiod/apigee-istio-mesh-config.yaml"
Vous pouvez également modifier manuellement les ressources à créer individuellement dans l'espace de noms de votre choix.
Utiliser des images Docker à partir de dépôts privés (facultatif)
Vous pouvez choisir de ne pas utiliser les images hébergées publiquement et pouvez utiliser des images de vos propres dépôts privés :
- La première étape consiste à transférer toutes les images vers votre dépôt privé, en suivant les étapes décrites dans apigee-pull-push | Apigee X Par défaut, les images se voient attribuer un tag correspondant à la version Apigee hybrid associée. Il est recommandé de ne pas modifier ces tags. Nous vous conseillons également de ne pas modifier les noms des images afin que le chemin d'accès final de l'image puisse être créé comme expliqué dans la section Hub d'images.
Définissez la valeur du champ
imageHubprésent dans le fichier apigee-hybrid-config.yaml sur le chemin d'accès à l'hôte du dépôt privé. (Consultez la page Image Hub pour plus de détails.)imageHub: "your.private.repo/apigee/hybrid"
Vous vous assurez ainsi que tous les composants Apigee hybrid utilisent les images de votre dépôt privé.
En outre, vous pouvez également utiliser une image privée pour le contrôleur et la passerelle d'entrée Apigee, pour lesquels vous devrez modifier les fichiers apigee-controller-deployment.yaml et apigee-ingressgateway-manager-deployment.yaml, et remplacer tous les champs image par l'image de leur dépôt privé.
Configurer imagePullSecrets (facultatif)
- Créez un secret Kubernetes contenant les identifiants permettant de s'authentifier auprès des dépôts privés. Consultez la section Extraire une image d'un registre privé pour comprendre comment créer le secret.
- Une fois le secret créé, il reste à y faire référence. Pour ce faire, modifiez le fichier apigee-hybrid-config.yaml et définissez la valeur du champ
imagePullSecretsur le nom du secret créé précédemment et activez le composantimagePullSecretdans le fichierkustomization.yamlcorrespondant.
Si vous spécifiez imagePullSecrets aux deux emplacements, celui présent dans le fichier "apigee-controller-manager.yaml" aura la priorité.
Configurer le proxy de transfert (facultatif)
Les proxys de transfert peuvent être configurés en ajoutant le champ forwardProxy au fichier apigee-hybrid-config.yaml. Exemple :
forwardProxy: |
scheme: HTTP
host: 10.12.0.47
port: 3128
Spécifier des certificats TLS d'entrée
Utiliser le script
./tools/apigee-hybrid-setup.sh --create-ingress-tls-certs
Pour en savoir plus sur cette option, consultez la section Comprendre le script.
Manuel
Vous devez fournir des certificats TLS qui seront utilisés pour la passerelle d'entrée Istio. Vous pouvez :
- Utiliser des certificats signés par une autorité connue en suivant les étapes décrites dans la section Obtenir des certificats TLS : exemple | Apigee X
- ou générer des certificats autosignés.
Prenons l'exemple des certificats autosignés. Vous pouvez générer des certificats autosignés (en supposant que DOMAIN a été correctement défini et doit correspondre au nom d'hôte défini dans votre envgroup) :
openssl req -nodes -new -x509 -keyout ./tls.key -out ./tls.crt -subj '/CN='$DOMAIN'' -days 3650
Cela crée deux fichiers nommés tls.key et tls.crt.
Vous devez ensuite créer un secret au format suivant. Vous pouvez utiliser kubectl create ou kubectl apply, comme expliqué dans la section "Utiliser une paire certificat/clé personnalisée pour l'autorité de signature des certificats" (facultatif) :
apiVersion: v1
kind: Secret
metadata:
name: "{ORG_NAME}-{ENV_GROUP_NAME}"
namespace: {$APIGEE_NAMESPACE}
type: Opaque
data:
cert: |
{BASE64_ENCODED_TLS_CRT}
key: |
{BASE64_ENCODED_TLS_KEY}
---
Exemple de création du secret à l'aide de kubectl create :
kubectl create secret tls {ORG_NAME}-{ENV_GROUP_NAME} \
--cert="tls.crt" \
--key="tls.key" \
-n {$APIGEE_NAMESPACE}
Mettre à jour le déploiement d'entrée
Pour créer/modifier des déploiements d'entrée, vous devez modifier le champ spec.components.ingressGateways dans la ressource personnalisée ApigeeOrganization dans bases/initialization/crds/customresourcedefinition-apigeeorganizations.apigee.cloud.google.com.yaml.
Par défaut, nous créons un déploiement d'entrée avec les paramètres par défaut (les valeurs par défaut seront affichées dans la documentation de référence sur les RS ) :
ingressGateways:
- name: "prod-1"
Exemples :
A. Remplacer les champs du service d'entrée
ingressGateways:
- name: "prod-1"
serviceSpec:
annotations:
{KEY}: ${VALUE}
loadBalancerIP: ${IP}
B. Modifier le nombre minimal/maximal d'instances répliquées
ingressGateways:
- name: "prod-1"
autoScaler:
minReplicas: 4
maxReplicas: 10
C. Ajouter un déploiement d'entrée
ingressGateways:
- name: "prod-1"
- name: "prod-2"
Configurer des comptes de service Google Cloud personnalisés
Utiliser le script
./tools/apigee-hybrid-setup.sh --create-gcp-sa-and-secrets --namespace APIGEE_NAMESPACE
Où APIGEE_NAMESPACE est votre espace de noms personnalisé. L'espace de noms par défaut est apigee.
Pour en savoir plus sur les options, consultez la section Comprendre le script.
Manuel
Les clés de compte de service Google Cloud doivent être stockées en tant que secrets dans le cluster. Le fichier YAML des secrets doit avoir la structure suivante :
apiVersion: v1
kind: Secret
metadata:
name: "{NAME}"
namespace: {APIGEE_NAMESPACE}
type: Opaque
data:
client_secret.json: |
{BASE64_ENCODED_SA_KEY}
Pour en savoir plus sur les éléments obligatoires pour tous les comptes de service et sur les noms des secrets, consultez la section Comptes de service Google Cloud.
Vous êtes libre de choisir un autre nom pour les secrets, mais vous devrez ensuite modifier en conséquence le composant où ce nom de secret a été utilisé. Par exemple, si vous décidez de remplacer le nom du secret du compte de service d'exécution de apigee-runtime-svc-account-${ORG_NAME}-${ENV_NAME} par my-runtime-svc, vous devez apporter une modification correspondante dans le fichier apigee-environment.yaml pour cet environnement.
Utiliser des identités de charge de travail
L'une des options consistant à configurer des comptes de service Google Cloud personnalisés ou à utiliser des identités de charge de travail est obligatoire.
Prérequis
Avant d'utiliser des identités de charge de travail, assurez-vous que la prise en charge est activée dans votre cluster GKE. Consultez la page Mettre à jour des pools de nœuds | Apigee X pour en savoir plus.
Activer workload-identity
Consultez la section Identités de la charge de travail sous Kustomize et Components pour savoir comment activer les identités de charge de travail avant l'installation.
Modifier les fichiers YAML des ressources
Certains emplacements des fichiers YAML des composants exigent la présence des noms corrects d'organisation, d'environnement et de groupe d'environnements. Vous pouvez définir ces valeurs manuellement ou utiliser le script shell pour les renseigner automatiquement.
Utiliser le script
./tools/apigee-hybrid-setup.sh --fill-values
Créer des ressources et un contrôleur d'initialisation
#Additional steps for openshift
kubectl apply -k ${INSTALL_DIR}/overlays/initialization/openshift
//apigee datastore
kubectl apply -f ${INSTANCE_DIR}/overlays/instances/${INSTANCE_DIR}/datastore/components/openshift-scc/scc.yaml
//telemetry
kubectl apply -f ${INSTANCE_DIR}/overlays/instances/${INSTANCE_DIR}/telemetry/components/openshift-scc/scc.yaml
#Create Apigee initialization kubernetes resources
kubectl apply -f ${INSTALL_DIR}/overlays/initialization/namespace.yaml
kubectl apply -k ${INSTALL_DIR}/overlays/initialization/certificates
kubectl apply --server-side --force-conflicts -k ${INSTALL_DIR}/overlays/initialization/crds
kubectl apply -k ${INSTALL_DIR}/overlays/initialization/webhooks
kubectl apply -k ${INSTALL_DIR}/overlays/initialization/rbac
kubectl apply -k ${INSTALL_DIR}/overlays/initialization/ingress
# Create controller config and controller
kubectl apply -k ${INSTALL_DIR}/overlays/controllers
# Wait for the controllers to be available
kubectl wait deployment/apigee-controller-manager deployment/apigee-ingressgateway-manager -n "${APIGEE_NAMESPACE}" --for=condition=available --timeout=2m
# Create the datastore and redis secrets first and then the rest of the secrets.
kubectl apply -f ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/datastore/secrets.yaml
kubectl apply -f ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/redis/secrets.yaml
kubectl apply -f ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/environments/${ENV_NAME}/secrets.yaml
kubectl apply -f ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/organization/secrets.yaml
Accorder des autorisations au compte de service du synchronisateur pour interagir avec le plan de contrôle
Suivez les étapes décrites dans la section Étape 8 : Activer l'accès au synchronisateur en remplaçant le nom du compte de service, apigee-non-prod ou apigee-synchronizer, par le nom apigee-all-sa du compte de service créé par le nouveau processus d'installation.
★ Important : Veillez à modifier le nom du compte de service dans les instructions sous Activer l'accès au synchronisateur. Sinon, l'activation de l'accès au synchronisateur échouera.
Créer les composants du plan de données Apigee
Si vous avez modifié le nom de l'une des ressources lors des étapes précédentes, vous devrez modifier en conséquence les autres fichiers YAML où cette ressource est référencée. Ensuite, utilisez les commandes de l'exemple suivant :
# Create the rest of the resources.
kubectl apply -k ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}
pour installer tous les composants.
Attendre que les ressources démarrent
kubectl wait "apigeedatastore/default" \
"apigeeredis/default" \
"apigeeenvironment/${ORG_NAME}-${ENV_NAME}" \
"apigeeorganization/${ORG_NAME}" \
"apigeetelemetry/apigee-telemetry" \
-n "${APIGEE_NAMESPACE}" --for="jsonpath=.status.state=running" --timeout=15m
Personnaliser l'installation pour cert-manager dans un espace de noms personnalisé
Personnalisez l'espace de noms dans lequel cert-manager s'exécute en procédant comme suit.
Si cert-manager est installé dans votre cluster dans un espace de noms autre que cert-manager, vous devez mettre à jour l'espace de noms utilisé pour créer le certificat racine Apigee.
- Modifiez le fichier customization.yaml pour créer le certificat :
$INSTALL_DIR/overlays/initialization/certificates/kustomize.yaml Ajoutez les lignes suivantes à la fin du fichier :
- patch: |- - op: replace path: /metadata/namespace value: "gk-cert-manager" target: group: cert-manager.io version: v1 kind: Certificate name: apigee-root-certificateEnregistrez le fichier.
Kustomize et composants
Présentation
La nouvelle installation d'hybrid hérite de l'idéologie Kustomize de structuration des fichiers yaml sous la forme de bases et superpositions.
- Les bases sont des fichiers fournis par Apigee, qui peuvent varier entre chaque nouvelle version d'hybrid. Vous n'êtes pas censé modifier ces fichiers. Ces fichiers contiennent certaines valeurs par défaut fournies par Apigee. Tous les fichiers situés sous le dossier de premier niveau
bases/contiennent ces bases. Les superpositions contiennent la configuration utilisateur et permettent de modifier les valeurs par défaut spécifiées dans les bases. Tous les fichiers situés sous le dossier de premier niveau
overlays/contiennent ces superpositions.
Utiliser les composants
Les sous-dossiers du répertoire overlays/ de premier niveau ont été structurés de telle sorte que vous puissiez activer (ou désactiver) une fonctionnalité supplémentaire en ajoutant (supprimant) des commentaires à certaines lignes des fichiers kustomization.yaml.
Par exemple, voici à quoi ressemble la structure du dossier overlays/instances/{INSTANCE_NAME}/telemetry :
telemetry
├── components
│ ├── http-proxy
│ ├── imagepullsecret
│ ├── logger
│ ├── metrics
│ ├── nodeselector
│ ├── openshift-scc
│ ├── workload-identity-logger
│ └── workload-identity-metrics
├── apigee-telemetry.yaml
└── kustomization.yaml
Voici à quoi les fichiers telemetry/kustomization.yaml ressembleraient probablement par défaut :
resources:
- apigee-telemetry.yaml
components:
- ./components/metrics
# - ./components/workload-identity-metrics
# - ./components/logger
# - ./components/workload-identity-logger
# - ./components/http-proxy
# - ./components/nodeselector/
# - ./components/imagepullsecret
# - ./components/openshift-scc
Nous constatons que le ./components/logger a été commenté, ce qui signifie simplement que nous n'avons pas activé la journalisation de Google Cloud par défaut. Pour ce faire, vous pouvez simplement annuler la mise en commentaire de la ligne suivante :
components:
- ./components/logger
De même, pour désactiver les métriques, vous pouvez ajouter un commentaire à la ligne ./components/metrics :
...
components:
...
# - ./components/metrics
…
Les sections suivantes décrivent ces différents composants, quand les utiliser et comment les configurer.
OpenShift
Pour les utilisateurs qui souhaitent installer Apigee hybrid dans un cluster OpenShift, vous devrez peut-être activer quelques composants/ressources avant d'effectuer l'installation. (Champ obligatoire si vous n'utilisez pas le script pour effectuer l'installation.) Les fichiers à modifier sont les suivants :
overlays/initialization/openshift/kustomization.yaml. Dans la sectionresources:, annulez la mise en commentaire :# - ../../../bases/initialization/openshift/overlays/instances/{INSTANCE_NAME}/datastore/kustomization.yamlAnnulez la mise en commentaire :# - ./components/openshift-sccet annulez la mise en commentaire du champ "
components:" s'il est toujours commenté.overlays/instances/{INSTANCE_NAME}/telemetry/kustomization.yamlAnnulez la mise en commentaire :# - ./components/openshift-sccet annulez la mise en commentaire du champ "
components:" s'il est toujours commenté.
Vous pouvez ensuite suivre la procédure d'installation.
imagepullsecret
Ce composant peut être activé lorsque des images sont stockées dans votre dépôt privé. Pour extraire des images d'un dépôt privé, vous pouvez créer un secret Kubernetes contenant vos informations d'authentification, puis y référencer ce secret. Consultez la section Configurer imagePullSecrets (facultatif) pour obtenir des instructions. Consultez les sections Extraire une image d'un registre privé | Kubernetes dans la documentation Kubernetes pour en savoir plus.
Disponible en :
overlays/controllers/apigee-controlleroverlays/controllers/istiodoverlays/instances/{INSTANCE_NAME}/datastoreoverlays/instances/{INSTANCE_NAME}/environments/{ENV_NAME}overlays/instances/{INSTANCE_NAME}/organizationoverlays/instances/{INSTANCE_NAME}/redisoverlays/instances/{INSTANCE_NAME}/telemetry
Activation :
Annulez la mise en commentaire de la ligne "./components/imagepullsecret/" dans les fichiers kustomization.yaml respectifs, partout où cela s'avère nécessaire.
Modifications à effectuer :
- components/imagepullsecret/patch.yaml
- OBLIGATOIRE : ajoutez les noms de secrets pertinents à la liste dans
spec.template.spec.imagePullSecrets.
- OBLIGATOIRE : ajoutez les noms de secrets pertinents à la liste dans
Utilisation :
- Si vous n'avez pas encore installé Apigee hybrid, vous pouvez continuer la procédure d'installation. Ces modifications seront appliquées lors du processus.
Si vous avez déjà installé Apigee hybrid, vous devrez appliquer ces nouvelles modifications à l'aide de la commande suivante :
kubectl apply -k overlays/instances/{INSTANCE_NAME}
nodeselector
Ce composant vous permet de planifier des pods pour une ressource Apigee sur des nœuds spécifiques. Pour en savoir plus, consultez Affecter des pods à des nœuds | Kubernetes.
Disponible en :
overlays/controllers/apigee-controlleroverlays/controllers/istiodoverlays/instances/{INSTANCE_NAME}/datastoreoverlays/instances/{INSTANCE_NAME}/environments/{ENV_NAME}overlays/instances/{INSTANCE_NAME}/organizationoverlays/instances/{INSTANCE_NAME}/redisoverlays/instances/{INSTANCE_NAME}/telemetry
Activation :
Annulez la mise en commentaire de la ligne "./components/nodeselector" dans les fichiers kustomization.yaml respectifs, partout où cela s'avère nécessaire.
Modifications à effectuer :
- components/nodeselector/patch.yaml
- FACULTATIF : remplacez la valeur
apigee-runtimeouapigee-datadu libellé du sélecteur de nœud par la valeur souhaitée.
- FACULTATIF : remplacez la valeur
Utilisation :
- Si vous n'avez pas encore installé Apigee hybrid, vous pouvez continuer la procédure d'installation. Ces modifications seront appliquées lors du processus.
Si vous avez déjà installé Apigee hybrid, vous devrez appliquer ces nouvelles modifications à l'aide de la commande suivante :
kubectl apply -k overlays/instances/{INSTANCE_NAME}
workload-identity
Plusieurs conteneurs de l'écosystème Apigee hybrid nécessitent des autorisations pour effectuer certains appels d'API au plan de contrôle/gestion Apigee. Workload Identity consiste à accorder ces autorisations aux pods (et aux conteneurs qu'ils contiennent). Voici des ressources utiles pour en savoir plus : Présentation de Workload Identity : une meilleure authentification pour vos applications GKE | Blog Google Cloud -Utiliser Workload Identity | Documentation Kubernetes Engine | Google Cloud
Disponible en :
overlays/instances/{INSTANCE_NAME}/datastoreoverlays/instances/{INSTANCE_NAME}/environments/{ENV_NAME}overlays/instances/{INSTANCE_NAME}/organizationoverlays/instances/{INSTANCE_NAME}/redisoverlays/instances/{INSTANCE_NAME}/telemetry
Conditions préalables :
Avant de pouvoir utiliser Workload Identity, vous devez accorder les autorisations appropriées dans votre projet Google Cloud à l'aide de la commande suivante :
gcloud iam service-accounts add-iam-policy-binding \
--role roles/iam.workloadIdentityUser \
--member "serviceAccount:${ORG_NAME}.svc.id.goog[${APIGEE_NAMESPACE}/${KSA_NAME}]" \
${GSA_NAME}@${ORG_NAME}.iam.gserviceaccount.com
où :
- ${ORG_NAME} est le nom de votre organisation Apigee.
- ${APIGEE_NAMESPACE} est l'espace de noms Kubernetes dans lequel les composants Apigee ont été installés. En général, il s'agit de apigee, sauf indication explicite de l'utilisateur lors de l'installation. - ${KSA_NAME} est le nom de l'espace de noms Kubernetes. Vous devez exécuter cette commande pour chaque compte de service Kubernetes mentionné dans les comptes de service Kubernetes. - ${GSA_NAME} est le nom du compte de service Google Cloud. Si vous n'avez apporté aucune modification lors de l'installation, cette valeur est apigee-all-sa. Si vous configurez plusieurs comptes de service Google Cloud pour des composants individuels, vous devez faire correspondre le KSA_NAME avec le GSA_NAME. Vous pouvez comparer les tableaux des comptes de service Google Cloud avec les comptes de service Kubernetes pour trouver les équivalents.
Activation :
Annulez la mise en commentaire de la ligne ./components/workload-identity dans les fichiers kustomization.yaml respectifs, partout où cela s'avère nécessaire. Notez qu'au sein de la télémétrie, il y a des modules complémentaires Workload Identity distincts pour les composants metrics et logger. Ils peuvent être activés individuellement.
Utilisation :
- Si vous n'avez pas encore installé Apigee hybrid, vous pouvez simplement activer workload-identity, comme indiqué dans la section précédente, et passer à l'installation qui utilisera automatiquement workload-identity.
Si vous avez déjà installé Apigee hybrid, vous devrez appliquer ces nouvelles modifications à l'aide de la commande suivante :
kubectl apply -k overlays/instances/{INSTANCE_NAME}
http-proxy
Vous pouvez configurer un serveur proxy dans chacun des composants suivants afin que le trafic de ce composant passe par le proxy HTTP configuré pour ce composant. Vous pouvez configurer le proxy pour chaque composant Apigee individuellement.
Disponible en :
overlays/instances/{INSTANCE_NAME}/datastoreoverlays/instances/{INSTANCE_NAME}/environments/{ENV_NAME}overlays/instances/{INSTANCE_NAME}/organizationoverlays/instances/{INSTANCE_NAME}/telemetry
Activation :
Annulez la mise en commentaire de la ligne "./components/http-proxy/" dans les fichiers kustomization.yaml respectifs, partout où cela s'avère nécessaire.
Modifications à effectuer :
- components/http-proxy/patch.yaml
Les paramètres suivants peuvent être configurés sous
spec.httpForwardProxyscheme: OBLIGATOIREHTTPouHTTPShost: OBLIGATOIRE Adresse hôte de votre proxyport: OBLIGATOIRE Numéro de portusername: FACULTATIF Nom d'utilisateur associé à votre proxypassword: FACULTATIF Mot de passe pour accéder au proxy
Utilisation :
- Si vous n'avez pas encore installé Apigee hybrid, vous pouvez continuer la procédure d'installation. Ces modifications seront appliquées lors du processus.
Si vous avez déjà installé Apigee hybrid, vous devrez appliquer ces nouvelles modifications à l'aide de la commande suivante :
kubectl apply -k overlays/instances/{INSTANCE_NAME}
logger et metrics
Vous pouvez activer ou désactiver individuellement les métriques dans overlays/instances/{INSTANCE_NAME}/telemetry. Par défaut, Logger est désactivé et les métriques activées. Pour les activer ou les désactiver, il suffit de supprimer ou ajouter des commentaires dans les lignes correspondantes dans le fichier telemetry/kustomization.yaml.
gcs-backup et gcs-restore
Ce composant Kustomize peut être utilisé pour effectuer une sauvegarde et une restauration de la base de données Cassandra sur Google Cloud Storage.
Disponible en :
overlays/instances/{INSTANCE_NAME}/datastore
Conditions préalables :
Téléchargez les clés des comptes de service Google Cloud pour un compte doté du rôle "Administrateur des objets de l'espace de stockage".
- Si vous avez utilisé le script pour effectuer l'installation et que vous n'avez pas utilisé workload-identities, vous pouvez réutiliser les clés téléchargées disponibles dans le dossier "service-accounts" créé par le script.
Vous pouvez également utiliser le script create-service-account.sh pour créer un compte de service et télécharger ses clés :
./tools/create-service-accounts=.sh --env prod --profile apigee‑cassandra
Une fois les clés téléchargées, vous devez créer un secret Kubernetes nommé apigee-cassandra-backup-and-restore-gcp-sa-key à l'aide de la commande suivante :
kubectl create secret generic "apigee-cassandra-backup-and-restore-gcp-sa-key" \ --from-file="dbbackup_key.json=${PATH_TO_SA_KEY}" \ -n "${APIGEE_NAMESPACE}"Où :
- ${PATH_TO_SA_KEY} : chemin d'accès au fichier contenant les clés du compte de service.
- ${APIGEE_NAMESPACE} : espace de noms Kubernetes dans lequel les composants Apigee ont été installés. En règle générale, cette valeur est apigee, sauf si elle a été explicitement modifiée lors de l'installation.
Vous pouvez également utiliser le fichier de modèle templates/secret-apigee-cassandra-backup-and-restore-gcp-sa-key.yaml pour créer ce secret.
Activation :
- Si vous souhaitez activer la sauvegarde, annulez la mise en commentaire de la ligne "./components/gcs-backup" dans le fichier kustomization.yaml du datastore.
- Si vous souhaitez restaurer une sauvegarde, annulez la mise en commentaire de la ligne "./components/gcs-restore" dans le fichier kustomization.yaml du datastore.
Modifications pour la sauvegarde uniquement
- components/gcs-backup/apigee-datastore-patch.yaml
- OBLIGATOIRE Modifiez la valeur de la variable d'environnement DATABASE_STORAGE_BUCKET, pour qu'elle soit au format gs://BUCKET_NAME, et qu'elle pointe vers le bucket Google Cloud Storage où les données doivent être sauvegardées. La description correspond à dbStorageBucket décrit ici.
- components/gcs-backup/cron-patch.yaml
- OBLIGATOIRE : Modifiez "spec.schedule" pour spécifier la fréquence de la sauvegarde. Le champ accepte le format de planification Crontab standard. La description correspond au calendrier décrit ici.
- OBLIGATOIRE Modifiez la valeur de la variable d'environnement DATABASE_STORAGE_BUCKET, pour qu'elle soit au format gs://BUCKET_NAME, et qu'elle pointe vers le bucket Google Cloud Storage où les données doivent être sauvegardées. La description correspond à dbStorageBucket décrit ici.
- FACULTATIF : modifiez la valeur de HTTP_PROXY_URL pour qu'elle pointe vers un proxy configuré. Le format peut être le suivant :
http://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}https://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}http://${HOST_IP_ADDRESS}:${HOST_PORT}http://${HOST_IP_ADDRESS>:${HOST_PORT}
Effectuer une sauvegarde
Vous pouvez effectuer la sauvegarde à l'aide de la commande suivante :
kubectl apply -k overlays/instances/{INSTANCE_NAME}
Pour appliquer les modifications et activer la sauvegarde, procédez comme suit :
Modifications pour la restauration uniquement
- components/gcs-restore/apigee-datastore-patch.yaml
- OBLIGATOIRE Modifiez la valeur de la variable d'environnement DATABASE_STORAGE_BUCKET, pour qu'elle soit au format gs://BUCKET_NAME, et qu'elle pointe vers le bucket Google Cloud Storage où les données doivent être sauvegardées. La description correspond à dbStorageBucket décrit ici.
- components/gcs-restore/job-patch.yaml
- OBLIGATOIRE Modifiez la valeur de la variable d'environnement DATABASE_STORAGE_BUCKET, pour qu'elle soit au format gs://BUCKET_NAME, et qu'elle pointe vers le bucket Google Cloud Storage où les données doivent être sauvegardées.
- OBLIGATOIRE Modifiez la valeur de la variable d'environnement BACKUP_SNAPSHOT_TIMESTAMP. La description correspond à restore:snapshotTimestamp décrit ici.
- FACULTATIF : modifiez la valeur de HTTP_PROXY_URL pour qu'elle pointe vers un proxy configuré.
Le format peut être le suivant :
http://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}https://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}http://${HOST_IP_ADDRESS}:${HOST_PORT}http://${HOST_IP_ADDRESS}:${HOST_PORT}
Exécutez la restauration :
Pour en savoir plus sur la restauration des sauvegardes, consultez la section Restaurer des sauvegardes | Apigee X | Google Cloud
- Créez un cluster Kubernetes avec un nouvel espace de noms dans lequel restaurer le déploiement de l'environnement d'exécution hybrid. Vous ne pouvez pas utiliser les mêmes cluster et espace de noms que ceux utilisé pour l'installation hybrid d'origine.
Installez Apigee hybrid dans le nouveau cluster avec les paramètres configurés ci-dessus, en plus des autres paramètres de votre choix :
- Vous pouvez utiliser l'installation de base et installer hybrid dans le nouvel espace de noms :
./tools/apigee-hybrid-setup.sh \ --cluster-name $CLUSTER_NAME \ --cluster-region $CLUSTER_LOCATION \ --namespace ${NEW_APIGEE_NAMESPACE}- Vous pouvez également suivre l'installation Apigee hybrid personnalisée pour configurer les éléments selon votre choix.
Une fois la restauration terminée, toutes les ressources de l'ancien espace de noms peuvent être supprimées et basculées vers le nouvel espace de noms.
Pour en savoir plus, consultez la section Restaurer des sauvegardes.
non-gcs-backup et non-gcs-restore
Ce composant Kustomize peut être utilisé pour effectuer une sauvegarde et une restauration de la base de données Cassandra sur Google Cloud Storage.
Disponible en :
overlays/instances/{INSTANCE_NAME}/datastore
Conditions préalables :
- Vous pouvez utiliser les étapes de la documentation existante sur la configuration du serveur et de SSH.
À partir des étapes ci-dessus, vous devez utiliser la clé privée SSH disponible dans le fichier "ssh_key" généré en suivant les étapes précédentes. Nous allons ensuite créer un secret Kubernetes nommé "apigee-cassandra-backup-and-restore-gcp-sa-key" contenant cette clé SSH privée.
Vous pouvez créer le secret Kubernetes à l'aide de la commande suivante :
kubectl create secret generic "apigee-cassandra-backup-and-restore-key-file" \ --from-file="key=${PATH_TO_SSH_PRIVATE_KEY}" \ -n "${APIGEE_NAMESPACE}"Où :
- ${PATH_TO_SSH_PRIVATE_KEY} : chemin d'accès au fichier contenant la clé privée SSH
- ${APIGEE_NAMESPACE} : espace de noms Kubernetes dans lequel les composants Apigee ont été installés. En règle générale, cette valeur est apigee, sauf si elle a été explicitement modifiée lors de l'installation.
Vous pouvez également utiliser le fichier de modèle templates/secret-apigee-cassandra-backup-and-restore-key-file.yaml pour créer ce secret.
Activation :
- Si vous souhaitez activer la sauvegarde, annulez la mise en commentaire de la ligne "
./components/non-gcs-backup" dans le fichier kustomization.yaml du datastore. - Si vous souhaitez restaurer une sauvegarde, annulez la mise en commentaire de la ligne "
./components/non-gcs-restore" dans le fichier kustomization.yaml du datastore.
Modifications pour la sauvegarde uniquement
- components/non-gcs-backup/apigee-datastore-patch.yaml
- OBLIGATOIRE Modifiez la valeur de BACKUP_SERVER_IP. La description correspond à BACKUP_SERVER_IP décrit ici.
- OBLIGATOIRE Modifiez la valeur de BACKUP_STORAGE_DIR. La description correspond à BACKUP_STORAGE_DIR décrit ici.
- components/non-gcs-backup/cron-patch.yaml
- OBLIGATOIRE : Modifiez "spec.schedule" pour spécifier la fréquence de la sauvegarde. Le champ accepte le format de planification Crontab standard. La description correspond au calendrier décrit ici.
- OBLIGATOIRE Modifiez la valeur de BACKUP_SERVER_IP. La description correspond à BACKUP_SERVER_IP décrit ici.
- OBLIGATOIRE Modifiez la valeur de BACKUP_STORAGE_DIR. La description correspond à BACKUP_STORAGE_DIR décrit ici.
- FACULTATIF : modifiez la valeur de HTTP_PROXY_URL pour qu'elle pointe vers un proxy configuré. Le format peut être le suivant :
http://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}https://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}http://${HOST_IP_ADDRESS}:${HOST_PORT}http://${HOST_IP_ADDRESS}:${HOST_PORT}
Effectuer une sauvegarde
Vous pouvez effectuer la sauvegarde à l'aide de la commande suivante :
kubectl apply -k overlays/instances/{INSTANCE_NAME}
Pour appliquer les modifications et activer la sauvegarde, procédez comme suit :
Modifications pour la sauvegarde uniquement
- components/non-gcs-restore/apigee-datastore-patch.yaml
- OBLIGATOIRE Modifiez la valeur de
BACKUP_SERVER_IP. La description correspond àBACKUP_SERVER_IPdécrit ici. - OBLIGATOIRE Modifiez la valeur de BACKUP_STORAGE_DIR. La description correspond à
BACKUP_STORAGE_DIRdécrit ici.
- OBLIGATOIRE Modifiez la valeur de
- components/non-gcs-restore/job-patch.yaml
- OBLIGATOIRE Modifiez la valeur de la variable d'environnement
BACKUP_SNAPSHOT_TIMESTAMP. La description correspond àrestore:snapshotTimestampdécrit ici. - OBLIGATOIRE Modifiez la valeur de
BACKUP_SERVER_IP. La description correspond àBACKUP_SERVER_IPdécrit ici. - OBLIGATOIRE Modifiez la valeur de
BACKUP_STORAGE_DIR. La description correspond àBACKUP_STORAGE_DIRdécrit ici. - FACULTATIF : remplacez la valeur de
HTTP_PROXY_URLpar un proxy configuré. Le format peut être le suivant :http://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}https://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}http://${HOST_IP_ADDRESS}:${HOST_PORT}http://${HOST_IP_ADDRESS}:${HOST_PORT}
- OBLIGATOIRE Modifiez la valeur de la variable d'environnement
Exécutez la restauration :
Pour en savoir plus sur la restauration de sauvegardes, consultez la page Présentation de la restauration Cassandra.
- Créez un cluster Kubernetes avec un nouvel espace de noms dans lequel restaurer le déploiement de l'environnement d'exécution hybrid. Vous ne pouvez pas utiliser les mêmes cluster et espace de noms que ceux utilisé pour l'installation hybrid d'origine.
Installez Apigee hybrid dans le nouveau cluster avec les paramètres configurés ci-dessus en plus des autres paramètres de votre choix. Vous pouvez utiliser l'installation de base et installer un environnement hybride dans le nouvel espace de noms :
./tools/apigee-hybrid-setup.sh \ --cluster-name $CLUSTER_NAME \ --cluster-region $CLUSTER_LOCATION \ --namespace ${NEW_APIGEE_NAMESPACE}Vous pouvez également suivre l'installation Apigee hybrid personnalisée pour configurer les éléments selon votre choix.
Une fois la restauration terminée, toutes les ressources de l'ancien espace de noms peuvent être supprimées et basculées vers le nouvel espace de noms.
Pour en savoir plus, consultez la section Planifier des sauvegardes sur un serveur distant.
http-client
Pour obtenir des instructions, consultez l'article Activer les clients HTTP | Apigee
Disponible en :
- overlays/instances/${INSTANCE_NAME}/route-config/${ENV_GROUP}
Activation :
Annulez la mise en commentaire de la ligne "./components/http-client" dans le fichier route-config/${ENV_GROUP}/kustomization.yaml correspondant
Modifications à effectuer :
- Aucune modification obligatoire n'est requise.
Utilisation :
- Si vous n'avez pas encore installé Apigee hybrid, vous pouvez continuer la procédure d'installation. Ces modifications seront appliquées lors du processus.
Si vous avez déjà installé Apigee hybrid, vous devrez appliquer ces nouvelles modifications à l'aide de la commande suivante :
kubectl apply -k overlays/instances/{INSTANCE_NAME}
non-sni-client
Équivalent de Comment configurer un client non SNI | Apigee déjà existant
Disponible en :
- overlays/instances/${INSTANCE_NAME}/route-config/${ENV_GROUP}
Activation :
Annulez la mise en commentaire de la ligne "./components/non-sni-client" dans le fichier route-config/${ENV_GROUP}/kustomization.yaml correspondant
Modifications à effectuer :
- components/non-sni-client/apigee-route.yaml
- OBLIGATOIRE La description de
credentialNamecorrespond à celle decredential_namedécrite ici.
- OBLIGATOIRE La description de
Utilisation :
- Si vous n'avez pas encore installé Apigee hybrid, vous pouvez continuer la procédure d'installation. Ces modifications seront appliquées lors du processus.
Si vous avez déjà installé Apigee hybrid, vous devrez appliquer ces nouvelles modifications à l'aide de la commande suivante :
kubectl apply -k overlays/instances/{INSTANCE_NAME}
http-and-non-sni-client
Pour obtenir des instructions, consultez la section Activer la compatibilité avec les clients non SNI et HTTP | Apigee :
Activation :
Annulez la mise en commentaire de la ligne "./components/http-and-non-sni-client" dans le fichier route-config/${ENV_GROUP}/kustomization.yaml correspondant
Modifications à effectuer :
- components/http-and-non-sni-client/apigee-route.yaml
- OBLIGATOIRE La description de
credentialNamecorrespond à celle decredential_namedécrite ici.
- OBLIGATOIRE La description de
Utilisation :
- Si vous n'avez pas encore installé Apigee hybrid, vous pouvez continuer la procédure d'installation. Ces modifications seront appliquées lors du processus.
Si vous avez déjà installé Apigee hybrid, vous devrez appliquer ces nouvelles modifications à l'aide de la commande suivante :
kubectl apply -k overlays/instances/{INSTANCE_NAME}
multirégional
Ce composant peut être utilisé lors de la configuration d'un déploiement Cassandra multirégional. Pour en savoir plus, consultez Déploiement multirégional sur GKE et GKE On-Prem.
Activation :
Annulez la mise en commentaire de la ligne "./components/multi-region" dans le fichier datastore/kustomization.yaml
Modifications à effectuer :
components/multi-region/cassandra-data-replication.yaml
- OBLIGATOIRE
source.regionNom du centre de données Cassandra source à partir duquel les données seront répliquées. Vous pouvez l'identifier à l'aide de la commande suivante dans le cluster source :
kubectl get apigeedatastore -n ${APIGEE_NAMESPACE} -o=jsonpath='{.items[*].spec.components.cassandra.properties.datacenter}'- OBLIGATOIRE
components/multi-region/patch.yaml
- OBLIGATOIRE
spec.components.properties.multiRegionSeedHostIP de l'un des pods Cassandra source. Nous pouvons utiliser :
kubectl get pods -n ${APIGEE_NAMESPACE} -o wide- Pour répertorier tous les pods et obtenir l'adresse IP de n'importe quel pod Cassandra, utilisez la commande suivante :
kubectl get pods -o wide -n apigeeLe résultat doit se présenter sous la forme suivante :
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE apigee-cassandra-default-0 1/1 Running 0 5d 10.0.0.11 gke-k8s-dc-2-default-pool-a2206492-p55d apigee-cassandra-default-1 1/1 Running 0 5d 10.0.2.4 gke-k8s-dc-2-default-pool-e9daaab3-tjmz apigee-cassandra-default-2 1/1 Running 0 5d 10.0.3.5 gke-k8s-dc-2-default-pool-e589awq3-kjch- OBLIGATOIRE
Pour plus d'informations, consultez la section Conditions préalables à l'utilisation de GKE dans la section "Déploiement multirégional sur GKE, GKE On-Prem et AKS" :
Utilisation :
L'utilisation de ce composant est surtout pertinente lorsque vous configurez Apigee hybrid dans un nouveau cluster et que vous avez déjà une autre configuration de fonctionnement pour Apigee hybrid.
- Le cluster nouveau et le cluster existant doivent utiliser les mêmes certificats TLS pour garantir une communication appropriée entre les pods Cassandra. Nous devons donc copier le secret
apigee-root-certificatedu cluster existant et l'utiliser également dans le cluster le plus récent : Exécutez la commande suivante :
kubectl config get-contexts- Pour obtenir la liste de tous les contextes Kubernetes, exécutez la commande suivante :
kubectl config use-context SOURCE_CLUSTER_CONTEXToù SOURCE_CLUSTER_CONTEXT est le nom du cluster Kubernetes source.
Stockez le secret du certificat racine dans un fichier :
kubectl get secret/apigee-root-certificate -n cert-manager -o yaml > apigee-root-certificate.yamlBasculez le contexte du cluster vers le nouveau cluster sur lequel vous installez Apigee hybrid.
kubectl config use-context ${NEW_CLUSTER_CONTEXT}Créez le secret racine dans le nouveau cluster :
kubectl -n cert-manager apply -f apigee-root-certificate.yamlDésactive la création d'un certificat racine. Cela nous permet de ne pas créer de
apigee-root-certificateet de ne pas écraser celui que nous avons créé à l'étape précédente.Annulez la mise en commentaire des lignes suivantes dans le fichier
overlays/initialization/certificates/kustomization.yaml:# components: # - ./components/disable-apigee-root-certificate-generationPoursuivez l'installation d'Apigee hybrid à l'aide de l'installation de base d'Apigee hybrid ou de l'installation personnalisée d'Apigee hybrid. Par exemple, en suivant l'installation Apigee hybrid de base, vous pouvez exécuter la commande suivante :
./tools/apigee-hybrid-setup.sh --cluster-name $CLUSTER_NAME --cluster-region $CLUSTER_LOCATIONVérifiez l'état de la recompilation à l'aide de la commande suivante.
kubectl -n ${APIGEE_NAMESPACE} get apigeeds -o json | jq ".items[].status.cassandraDataReplication"Vérifiez les processus de recompilation des journaux. Vérifiez également la taille des données à l'aide de la commande "nodetool status" :
kubectl logs apigee-cassandra-default-0 -f -n ${APIGEE_NAMESPACE} kubectl exec apigee-cassandra-default-0 -n ${APIGEE_NAMESPACE} -- nodetool -u ${JMX_USER} -pw ${JMX_PASSWORD} statusVérifiez l'état de la recompilation à l'aide de la commande suivante.
kubectl -n apigee get apigeeds -o json | jq ".items[].status.cassandraDataReplication"Les résultats doivent ressembler à ceci :
{ "rebuildDetails": { "apigee-cassandra-default-0": { "state": "complete", "updated": 1623105760 }, "apigee-cassandra-default-1": { "state": "complete", "updated": 1623105765 }, "apigee-cassandra-default-2": { "state": "complete", "updated": 1623105770 } }, "state": "complete", "updated": 1623105770 }Voir également : Déploiement multirégional.
Supprimez les lignes suivantes de
components/multi-region/patch.yaml:properties: multiRegionSeedHost: {IP_ADDRESS} # To be modified. REQUIREDAppliquez les modifications :
kubectl apply -k overlays/instances/{INSTANCE_NAME}
Concepts
Hub d'image
Les images de conteneur Docker sont généralement spécifiées au format suivant :
${REGISTRY_HOST_PATH}/${IMAGE_NAME}:${IMAGE_TAG}
ou celles qui utilisent un condensé se présentent comme suit :
${REGISTRY_HOST_PATH}/${IMAGE_NAME}@${DIGEST}
Apigee utilise le concept "Hub image", qui, dans les formats ci-dessus, fait référence au ${REGISTRY_HOST_PATH}. La valeur par défaut du hub d'image est gcr.io/apigee-release/hybrid/.
(Les images utilisant le condensé DIGEST doivent être définies individuellement dans chaque sous-composant.)
Apigee crée le chemin d'accès final de l'image en combinant la valeur suivante :
- "Image Hub" pouvant être remplacé dans apigee-hybrid-config.yaml (consultez la section Utiliser les images Docker à partir de dépôts privés pour obtenir des instructions détaillées sur la manière de remplacer la valeur Image Hub).
- La valeur de
IMAGE_TAGest obtenue à partir du champversion, qui figure dans le fichier yaml pour chacun des composants individuels (par exemple, apigee-organization.yaml. Apigee assigne des tags aux images avec la version Apigee hybrid :IMAGE_TAGest la version 1.8 pour Apigee hybride version 1.8. IMAGE_NAMEest déterminé implicitement à partir du nom du conteneur dans lequel l'image sera utilisée. Par exemple, pour le conteneurapigee-runtime,IMAGE_NAMEsera apigee-runtime.
Ainsi, un exemple complet de chemin d'accès d'image serait gcr.io/apigee-release/hybrid/apigee-runtime:1.8.0.
De cette manière, le chemin d'accès de l'image finale est construit. Il sera ensuite utilisé dans chacun des conteneurs de leurs pods respectifs.
Comptes de service Google Cloud
Les comptes de service Google Cloud sont des comptes utilisés par les applications pour effectuer des appels autorisés aux API Google. Il est possible de télécharger les clés de compte de service Google Cloud, qui peuvent ensuite être utilisées à des fins d'authentification. Apigee s'attend à ce que l'utilisateur fournisse des clés de compte de service en créant des secrets. Voici les noms des composants et le nom par défaut du secret dans lequel il recherche les clés de compte de service :
| Composant | Sous-composant | Nom de secret Kubernetes par défaut contenant la clé du compte de service |
|---|---|---|
| organisation | ||
| connectAgent | apigee-connect-agent-gcp-sa-key-${ORG_NAME} |
|
| watcher | apigee-watcher-gcp-sa-key-${ORG_NAME} |
|
| mart | apigee-mart-gcp-sa-key-${ORG_NAME} |
|
| udca | apigee-udca-gcp-sa-key-${ORG_NAME} |
|
| ingressGateways | N/A | |
| environment | ||
| runtime | apigee-runtime-gcp-sa-key-${ORG_NAME}-${ENV_NAME} |
|
| udca | apigee-udca-gcp-sa-key-${ORG_NAME}-${ENV_NAME} |
|
| Synchronisateur | apigee-synchronizer-gcp-sa-key-${ORG_NAME}-${ENV_NAME} |
|
| telemetry | ||
| métrique | apigee-metrics-gcp-sa-key |
|
| containerLogs | apigee-logger-gcp-sa-key |
Comptes de service Kubernetes
Les comptes de service Kubernetes fournissent des identités aux pods de votre cluster. Par défaut, le contrôleur Apigee les crée pour vous. Toutefois, si vous souhaitez ignorer la création (par exemple, lorsque vous utilisez les identités de charge de travail), vous pouvez spécifier le champ podServiceAccountName dans les différents sous-composants.
Liste des composants et de leurs sous-composants respectifs où le compte de service Kubernetes peut être spécifié avec le nom par défaut du compte de service k8s lorsque vous activez le correctif Workload Identity pour ces composants.
| Composant | Sous-composant | Nom par défaut (disponible lorsque vous avez activé le correctif Workload Identity) |
|---|---|---|
| organisation | ||
| connectAgent | apigee-connect-agent-svc-account-${ORG_NAME} |
|
| watcher | apigee-watcher-svc-account-${ORG_NAME} |
|
| mart | apigee-mart-svc-account-${ORG_NAME} |
|
| udca | apigee-udca-svc-account-${ORG_NAME} |
|
| environment | ||
| Synchronisateur | apigee-synchronizer-svc-account-${ORG_NAME}-${ENV_NAME} |
|
| udca | apigee-udca-svc-account-${ORG_NAME}-${ENV_NAME} |
|
| runtime | apigee-runtime-svc-account-${ORG_NAME}-${ENV_NAME} |
|
| datastore | ||
| cassandra | apigee-datastore-svc-account |
|
| telemetry | ||
| metricsApp | apigee-metricsApp-svc-account |
|
| metricsProxy | apigee-metricsProxy-svc-account |
|
| metricsAdapter | apigee-metricsAdapter-svc-account |
|
| containerLogs | apigee-container-logs-svc-account |
Identités des charges de travail
Les identités de charge de travail permettent aux pods (qui utilisent des comptes de service Kubernetes) exécutés dans GKE de s'authentifier directement auprès des API Google Cloud sans avoir besoin de clés de compte de service Google Cloud.
Ajouter un nouvel environnement
.
├── ...
├── instances/instance1/components
│ ├── ...
│ ├── environments
│ │ ├── dev
│ │ │ └── apigee-environment.yaml
│ │ │ └── secrets.yaml
│ │ └── new-env-name (new)
│ │ └── apigee-environment.yaml (new)
│ │ └── secrets.yaml (new)
└── ...
Il est facile d'ajouter un nouvel environnement :
- Création d'un dossier dans le répertoire des environnements (ou à l'emplacement correspondant à votre propre structure de dossiers)
- Copie du fichier
apigee-environment.yamlde n'importe quel environnement existant dans le nouveau dossier. - Si vous souhaitez créer un compte de service et des clés de chiffrement pour le nouvel environnement, copiez l'élément
secrets.yamldans le nouveau dossier et renommez les secrets de manière appropriée pour les distinguer des autres environnements existants (généralement en ajoutant le nom du environnement en tant que suffixe). - Réalisation des modifications appropriées de
apigee-environment.yaml, par exemple :- Changement du nom de l'environnement.
- Si des comptes de service et des clés de chiffrement doivent être créés, ils doivent être correctement référencés dans le fichier YAML.
- Application des fichiers
yaml:
kubectl apply -f components/environments/new-env-name/secrets.yaml
kubectl apply -f components/environments/new-env-name/apigee-environment.yaml
Utiliser la suppression forcée dans Apigee Datastore
Si la suppression du datastore ne progresse pas pour une raison quelconque, il est désormais possible de forcer la suppression d'un datastore Apigee à l'aide des commandes suivantes, quel que soit l'état actuel du cluster.
Supprimez l'objet
apigeedsdans l'espace de nomsapigee:Kubectl delete -n apigee apigeeds defaultSi cette étape se bloque, vous pouvez l'arrêter en appuyant sur CTRL+C.
Modifiez un nouveau
apigeeds:Kubectl edit -n apigee apigeeds defaultAjout/mise à jour d'un champ forceDelete dans la spécification de datastore apigee
spec: forceDelete: trueEnregistrez et fermez le fichier.
Attendez maintenant que le datastore soit supprimé. La suppression de toutes les ressources Cassandra peut prendre quelques minutes.
Comprendre le script
Le script apigee-hybrid-setup.sh effectue certaines validations de base et vous aide à automatiser les étapes que vous devriez sinon effectuer vous-même si vous souhaitez une personnalisation plus détaillée, comme documenté dans la section Installation personnalisée d'Apigee hybrid. Même avec l'installation personnalisée, vous pouvez toujours utiliser partiellement le script pour effectuer certaines tâches.
Vous pouvez exécuter ./tools/apigee-hybrid-setup.sh --help pour afficher la liste des options compatibles et obtenir une aide supplémentaire concernant le script. Les options suivantes sont acceptées pour le moment :
--namespacePar défaut, le script installe tous les composants dans l'espace de nomsapigee. Vous pouvez modifier ce comportement en spécifiant le nom de l'espace de noms à l'aide de cette option.--org: permet de fournir le nom de l'organisation Apigee. Si ce champ n'est pas spécifié, la valeur par défaut est définie sur le projet Google Cloud actuellement sélectionné dansgcloud.--envgroup: Permet de fournir le nom du groupe d'environnements au sein de votre organisation. Si cette option n'est pas spécifiée, une tentative est effectuée pour interroger les API du plan de contrôle pour déterminer le nom du groupe d'environnements. Si plusieurs groupes d'environnement sont détectés, une erreur est renvoyée et le script se ferme.--env: Permet de fournir le nom de l'environnement au sein de votre organisation. Si ce n'est pas le cas, une tentative est effectuée pour interroger les API du plan de contrôle afin de déterminer le nom de l'environnement. Si plusieurs environnements sont détectés ou si l'environnement ne fait pas partie du groupe d'environnements, une erreur est renvoyée et le script se ferme.--cluster-nameNom du cluster Kubernetes.--cluster-regionRégion dans laquelle se trouve le cluster Kubernetes.--gcp-project-id: ID du projet Google Cloud dans lequel se trouve le cluster Kubernetes.--ingress-domainNom d'hôte/nom de domaine qui sera utilisé pour générer les certificats TLS autosignés pour la passerelle d'entrée Istio. Si aucune valeur n'est spécifiée, une tentative est effectuée pour déterminer la valeur en interrogeant les API du plan de contrôle afin d'obtenir la valeur de l'envgroup. Si des problèmes sont survenus lors de la détermination de l'environnement ou si plusieurs noms d'hôte ont été configurés pour l'environnement, une erreur est renvoyée et le script se ferme.--generate-internal-tls-certsCette opération génère un secret Kubernetes nommé apigee-ca et contenant un certificat et une paire de clés générés par nous.--create-ingress-tls-certsCette opération génère un secret nommé{ORG_NAME}-{ENV_GROUP_NAME}(dérivé de l'organisation et du nom du groupe d'environnements) dans l'espace de noms istio-system qui contiendra un certificat et une paire de clés qui seront utilisés pour la communication TLS. Le nom de domaine utilisé pour générer ces certificats est dérivé de la valeur trouvée dans la configuration du groupe d'environnements. En cas de conflit (par exemple, lorsque plusieurs domaines sont détectés), des messages d'erreur appropriés s'affichent.--create-gcp-sa-and-secrets: Crée un compte de service Google Cloud unique dans le projet Google Cloud, télécharge les clés, puis crée les secrets Kubernetes contenant la clé. Vous trouverez les noms des secrets dans Comptes de service Google Cloud.--fill-valuesRemplace les valeurs de l'organisation, de l'environnement, du groupe d'environnements et des autres noms partout où elles sont requises dans les différents fichiers yaml.--apply-configurationLes émetteurs de certificats, les définitions de ressources personnalisées, les webhooks, les rôles et la ressource de contrôleur seront créés. Les ressources seront créées dans le bon ordre, et la commande sera bloquée jusqu'à ce que toutes soient saines.-- rename-directoriesRenomme l'environnement et le groupe d'environnements en utilisant les noms de l'environnement et du groupe d'environnement corrects.--verboseAffiche une sortie détaillée pour le débogage.--helpAffiche des informations d'utilisation.--setup-allCette action exécutera toutes les tâches pouvant être effectuées par ce script.
Structure du dossier de configuration d'Apigee hybrid
Le dossier apigee-hybrid-setup présente par défaut la structure hiérarchique suivante :
.
├── bases
│ ├── controllers
│ │ ├── apigee-controller
│ │ │ ├── apigee-controller-deployment.yaml
│ │ │ └── kustomization.yaml
│ │ └── apigee-ingressgateway-manager
│ │ ├── apigee-ingressgateway-manager-deployment.yaml
│ │ └── kustomization.yaml
│ ├── datastore
│ │ └── backup-and-restore
│ │ ├── backup
│ │ │ ├── cronjob.yaml
│ │ │ └── kustomization.yaml
│ │ ├── common
│ │ │ ├── kustomization.yaml
│ │ │ ├── rbac.yaml
│ │ │ └── tls-certificate.yaml
│ │ └── restore
│ │ ├── job.yaml
│ │ └── kustomization.yaml
│ └── initialization
│ ├── certificates
│ │ ├── certificates-and-issuers.yaml
│ │ └── kustomization.yaml
│ ├── crds
│ │ ├── customresourcedefinition-apigeedatastores.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeedeployments.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeeenvironments.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeeorganizations.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeeredis.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeerouteconfigs.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeeroutes.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeetelemetries.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-cassandradatareplications.apigee.cloud.google.com.yaml
│ │ └── kustomization.yaml
│ ├── openshift
│ │ ├── kustomization.yaml
│ │ └── scc.yaml
│ ├── rbac
│ │ ├── apigee-controller
│ │ │ ├── kustomization.yaml
│ │ │ └── rbac.yaml
│ │ └── apigee-embedded-ingress-controller
│ │ ├── cluster-role-bindings.yaml
│ │ ├── cluster-roles.yaml
│ │ ├── kustomization.yaml
│ │ └── service-account.yaml
│ └── webhooks
│ ├── kustomization.yaml
│ ├── mutatingwebhookconfiguration.yaml
│ └── validatingwebhookconfiguration.yaml
├── CONTRIBUTING.md
├── docs
│ └── api_references
│ ├── v1alpha1.md
│ └── v1alpha2.md
├── kokoro
│ ├── build.sh
│ ├── common.cfg
│ ├── continuous.cfg
│ ├── presubmit.cfg
│ └── release.cfg
├── LICENSE
├── overlays
│ ├── controllers
│ │ ├── apigee-controller
│ │ │ ├── apigee-hybrid-config.yaml
│ │ │ ├── components
│ │ │ │ ├── imagepullsecret
│ │ │ │ │ ├── kustomization.yaml
│ │ │ │ │ └── patch.yaml
│ │ │ │ └── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── kustomization.yaml
│ │ ├── apigee-ingressgateway-manager
│ │ │ ├── apigee-ingressgateway-manager-deployment-patch.yaml
│ │ │ ├── apigee-istio-mesh-config.yaml
│ │ │ ├── components
│ │ │ │ ├── imagepullsecret
│ │ │ │ │ ├── kustomization.yaml
│ │ │ │ │ └── patch.yaml
│ │ │ │ └── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── kustomization.yaml
│ │ └── kustomization.yaml
│ ├── initialization
│ │ ├── certificates
│ │ │ ├── apigee-ingressgateway-manager-certificate-patch.yaml
│ │ │ ├── apigee-serving-cert-patch.yaml
│ │ │ ├── components
│ │ │ │ └── disable-apigee-root-certificate-generation
│ │ │ │ └── kustomization.yaml
│ │ │ └── kustomization.yaml
│ │ ├── crds
│ │ │ └── kustomization.yaml
│ │ ├── ingress
│ │ │ ├── envoyfilter-1.11.yaml
│ │ │ └── kustomization.yaml
│ │ ├── namespace.yaml
│ │ ├── openshift
│ │ │ ├── kustomization.yaml
│ │ │ └── scc.yaml
│ │ ├── rbac
│ │ │ ├── apigee-controller
│ │ │ │ └── kustomization.yaml
│ │ │ ├── apigee-ingressgateway-manager
│ │ │ │ └── kustomization.yaml
│ │ │ └── kustomization.yaml
│ │ └── webhooks
│ │ ├── kustomization.yaml
│ │ ├── mutatingwebhookconfiguration.yaml
│ │ └── validatingwebhookconfiguration.yaml
│ └── instances
│ └── instance1
│ ├── datastore
│ │ ├── apigee-datastore.yaml
│ │ ├── components
│ │ │ ├── gcs-backup
│ │ │ │ ├── apigee-datastore-patch.yaml
│ │ │ │ ├── cron-patch.yaml
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── tls-certificate-patch.yaml
│ │ │ ├── gcs-restore
│ │ │ │ ├── apigee-datastore-patch.yaml
│ │ │ │ ├── job-patch.yaml
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── tls-certificate-patch.yaml
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── multi-region
│ │ │ │ ├── cassandra-data-replication.yaml
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── non-gcs-backup
│ │ │ │ ├── apigee-datastore-patch.yaml
│ │ │ │ ├── cron-patch.yaml
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── tls-certificate-patch.yaml
│ │ │ ├── non-gcs-restore
│ │ │ │ ├── apigee-datastore-patch.yaml
│ │ │ │ ├── job-patch.yaml
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── tls-certificate-patch.yaml
│ │ │ ├── openshift-scc
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── scc.yaml
│ │ │ └── workload-identity
│ │ │ ├── kustomization.yaml
│ │ │ ├── patch.yaml
│ │ │ └── service-accounts.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── environments
│ │ ├── kustomization.yaml
│ │ └── test
│ │ ├── apigee-environment.yaml
│ │ ├── components
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── kustomization.yaml
│ │ │ ├── patch.yaml
│ │ │ └── service-accounts.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── kustomization.yaml
│ ├── organization
│ │ ├── apigee-organization.yaml
│ │ ├── components
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── kustomization.yaml
│ │ │ ├── patch.yaml
│ │ │ └── service-accounts.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── redis
│ │ ├── apigee-redis.yaml
│ │ ├── components
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── kustomization.yaml
│ │ │ ├── patch.yaml
│ │ │ └── service-accounts.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── route-config
│ │ ├── kustomization.yaml
│ │ └── test-envgroup
│ │ ├── apigee-route-config.yaml
│ │ ├── components
│ │ │ ├── http-and-non-sni-client
│ │ │ │ ├── apigee-route.yaml
│ │ │ │ └── kustomization.yaml
│ │ │ ├── http-client
│ │ │ │ ├── apigee-route.yaml
│ │ │ │ └── kustomization.yaml
│ │ │ └── non-sni-client
│ │ │ ├── apigee-route.yaml
│ │ │ └── kustomization.yaml
│ │ └── kustomization.yaml
│ └── telemetry
│ ├── apigee-telemetry.yaml
│ ├── components
│ │ ├── http-proxy
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── imagepullsecret
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── logger
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── metrics
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── nodeselector
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── openshift-scc
│ │ │ ├── kustomization.yaml
│ │ │ └── scc.yaml
│ │ ├── workload-identity-logger
│ │ │ ├── kustomization.yaml
│ │ │ ├── patch.yaml
│ │ │ └── service-accounts.yaml
│ │ └── workload-identity-metrics
│ │ ├── kustomization.yaml
│ │ ├── patch.yaml
│ │ └── service-accounts.yaml
│ └── kustomization.yaml
├── README.md
├── templates
│ ├── certificate-org-envgroup.yaml
│ ├── secret-apigee-cassandra-backup-and-restore-gcp-sa-key.yaml
│ ├── secret-apigee-cassandra-backup-and-restore-key-file.yaml
│ ├── secret-gcp-sa-key.yaml
│ └── secret-ingress-tls-cert-key.yaml
└── tools
├── apigee-hybrid-setup.sh
├── apigee-pull-push.sh
├── common.sh
├── create-service-account.sh
└── dump_kubernetes.sh
Une version des fichiers ci-dessus est disponible dans le tag preview-1 du dépôt GitHub à l'adresse suivante : https://github.com/apigee/apigee-hybrid-install/releases/tag/preview-1.
Le dossier ci-dessus contient des fichiers manifestes Kubernetes pour l'environnement d'exécution Apigee hybrid et utilise Kustomize pour la gestion de la configuration. Les fichiers manifestes sont organisés en fonction du concept de bases et superpositions Kustomize. Le dossier de base contient la configuration minimale requise pour chaque composant Apigee. Le dossier de superposition contient plusieurs fonctionnalités supplémentaires (configurations) définies en tant que composants. Un composant peut être activé en annulant la mise en commentaire de sa référence dans le fichier kustomization.yaml.
Exemple : Pour activer le gcs-backup pour le datastore apigee, le composant gcs-backup a vu sa mise en commentaire annulé dans le fichier customization.yaml ci-dessous.
Chemin d'accès : ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/datastore/kustomization.yaml
namespace: "apigee" # kpt-set: ${APIGEE_NAMESPACE}
resources:
- apigee-datastore.yaml
components:
# - ./components/http-proxy
# - ./components/nodeselector/
# - ./components/imagepullsecret
# - ./components/workload-identity
# - ./components/openshift-scc
- ./components/gcs-backup (uncommented)
# - ./components/gcs-restore
# - ./components/non-gcs-backup
# - ./components/non-gcs-restore
Toute valeur nécessitant des personnalisations doit être définie dans le fichier patch.yaml correspondant pour gcs-backup.
Dans le fichier ci-dessous, la valeur de CLOUD_STORAGE_BUCKET_PATH doit être définie par l'utilisateur.
Chemin d'accès : $INSTALL_DIR/overlays/instances/$INSTANCE_DIR/datastore/components/gcs-backup/cron-patch.yaml
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: apigee-cassandra-backup
namespace: apigee
spec:
schedule: "${YOUR_BACKUP_SCHEDULE_CODE}" # To be modified
jobTemplate:
spec:
template:
spec:
containers:
- name: apigee-cassandra-backup
env:
- name: APIGEE_CLOUDPROVIDER
value: "GCP"
- name: DATABASE_STORAGE_BUCKET
value: "${CLOUD_STORAGE_BUCKET_PATH}" # To be modified. REQUIRED
volumeMounts:
- name: apigee-cassandra-backup
mountPath: /var/secrets/google
volumes:
- name: apigee-cassandra-backup
secret:
secretName: "apigee-cassandra-backup-and-restore-svc-account"
De même, toute fonctionnalité/configuration nécessitant des personnalisations peut être activée en annulant la mise en commentaire du composant dans le fichier kustomization.yaml du composant Apigee. De plus, comme requis, les valeurs correspondantes des champs du fichier patch.yaml du composant doivent être définies en conséquence.
Brève explication des dossiers et des fichiers :
bases
Ce dossier contient les modèles avec une configuration minimale minimale requise par chacun des composants Apigee. Il ne serait pas nécessaire de modifier les fichiers manifestes de ce dossier.
overlays
Ce dossier contient les modèles de composants Kustomize pour les configurations supplémentaires
initialization
namespaces.yaml
Espace de noms dans lequel les composants du plan de données Apigee seront installés. Le nom de l'espace de noms par défaut est apigee.
certificats
Contient les ressources Issuer et Certificate utilisées pour émettre des certificats aux webhooks. Contient également le Issuer utilisé pour émettre des certificats à différents pods pour la communication TLS.
rbac
Contient les Role, ClusterRole, RoleBinding et ClusterRoleBinding qui seront utilisés par divers composants.
crds
Contains the definition of all the CRDs which are used by Apigee.
webhooks
Contient ValidatingWebhookConfiguration et MutatingWebhookConfiguration qui seront utilisés pour effectuer des validations sur les ressources personnalisées.
ingress
Contient une configuration applicable à tous les Pods d'entrée. Par exemple, Modification d'en-tête courante, vérification de l'état, etc.
openshift
Contient la définition openshift SecurityContextConstraints.
Contrôleurs
apigee-controller
apigee-hybrid-config.yaml
Contient un ConfigMap qui est fourni en tant qu'entrée dans apigee-controller-manager.yaml. Ce fichier ConfigMap contient des configurations telles que imageHub, imagePullSecrets et forwardProxy.
apigee-controller-deployment.yaml
Contient deux services pour le contrôleur et le webhook, ainsi que le déploiement pour le contrôleur. Si vous souhaitez utiliser une image privée pour le contrôleur, c'est ici que vous devez effectuer la modification.
istiod
Apigee-istio-mesh-config.yaml Contient la configuration de maillage pour Istio utilisée par Apigee. Cela ne s'applique pas aux autres installations d'ASM/Istio dans le cluster.
apigee-ingressgateway-manager-deployment-patch.yaml
Contient un service et un déploiement d'Istiod. Il s'agit d'un Istiod privé utilisé uniquement pour les cas d'utilisation d'Apigee.
instances/{instanceName}
datastore
apigee-datastore.yaml
Contient la ressource personnalisée ApigeeDatastore qui gère Cassandra.
secrets.yaml
Contient les identifiants par défaut du datastore.
redis
apigee-redis.yaml
Contient la ressource personnalisée ApigeeRedis qui gère Redis.
secrets.yaml
Contient les identifiants par défaut du datastore.
organisation
apigee-organization.yaml
Contient la ressource personnalisée ApigeeOrganization qui gère d'autres sous-composants tels que connectAgent, watcherAndSynchronizer, MART,UDCA et Ingress.
secrets.yaml
Contient les Secret référencés dans le fichier apigee-organization.yaml. Certains secrets sont mis en commentaire au fur et à mesure qu'ils sont générés par le script. Si vous désactivez leur génération, vous devrez les créer manuellement.
environments
Inclut tous les environnements de votre organisation. Nous vous recommandons de créer un dossier distinct pour chaque environnement en copiant celui qui vous est déjà fourni et en le configurant conformément aux besoins.
dev
apigee-environment.yaml
Contient la ressource personnalisée ApigeeEnvironment qui gère d'autres sous-composants tels que l'environnement d'exécution.
secrets.yaml
Contient les Secret référencés dans le fichier apigee-environment.yaml. Certains secrets sont mis en commentaire au fur et à mesure qu'ils sont générés par le script. Si vous désactivez leur génération, vous devrez les créer manuellement.
telemetry
apigee-telemetry.yaml
Contient la ressource personnalisée ApigeeTelemetry.
secrets.yaml
Contient les Secret référencés dans le fichier apigee-telemetry.yaml. Certains secrets sont mis en commentaire au fur et à mesure qu'ils sont générés par le script. Si vous désactivez leur génération, vous devrez les créer manuellement.
route-config
dev-envgroup
apigee-route-config.yaml
Contient la ressource personnalisée ApigeeRouteConfig.
secrets.yaml
Contient un Secret référencé dans le fichier apigee-route-config.yaml. Elle est mise en commentaire car elle est générée automatiquement par le script apigee-hybrid-setup.sh et est conservée ici pour fournir un exemple de ce à quoi doit ressembler le secret si vous décidez de le créer manuellement.
diagnostic
diagnostic-collector.yaml
Ressources utilisées pour le déploiement de diagnostic
outils
apigee-hybrid-setup.sh
apigee-create-service-account.sh
dump-kubernetes.sh
apigee-pull-push.sh
Stocker les clés de compte de service dans des vaults externes
Vault (créé par Hashicorp) est un système de gestion de secrets populaire qui inclut plusieurs intégrations de magasins de secrets fournis par Google, Azure, AWS et d'autres fournisseurs. Hashicorp Vault vous permet de récupérer des secrets à partir d'une source externe, puis de les utiliser dans des ressources Kubernetes. Il existe plusieurs façons d'utiliser Vault pour créer des secrets sources. Les étapes suivantes servent d'exemple de base pour utiliser le fournisseur CSI Vault afin d'installer des clés de compte de service Google Cloud stockées dans un moteur de secrets fourni par Vault.
- Nous utilisons Helm pour installer les ressources associées à Vault dans votre cluster. Suivez les étapes indiquées dans la section Installer Helm pour savoir comment configurer Helm dans votre système.
Suivez la procédure décrite dans la section graphique d'installation de Helm Vault, à savoir :
Ajouter le dépôt Hashicorp à Helm
helm repo add hashicorp https://helm.releases.hashicorp.comMettre à jour les dépôts Helm
helm repo updateInstaller Vault
helm install vault hashicorp/vault \ --set "server.dev.enabled=true" \ --set "injector.enabled=false" \ --set "csi.enabled=true"
Nous allons maintenant stocker le secret dans Vault.
Obtenir une interface système dans le pod de développement Vault
kubectl exec -it vault-0 -- /bin/sh ```Dans cet exemple, nous allons utiliser le moteur de secrets clé/valeur pour stocker les données.
vault kv put secret/runtime-gcp-sa-key key="${BASE_64_ENCODED_KEY}"Pour vérifier que la clé a bien été stockée, utilisez :
vault kv get secret/runtime-gcp-sa-key
Configurez l'authentification pour permettre au pod d'exécution d'extraire la clé. Comme indiqué dans la section Comptes de service Kubernetes, les comptes de service Kubernetes fournissent une identité aux pods et leur permettent de s'authentifier auprès d'autres systèmes.
Obtenir une interface système dans le pod de développement Vault
kubectl exec -it vault-0 -- /bin/shActiver la méthode d'authentification Kubernetes
vault auth enable kubernetesÉcrire la configuration d'authentification
vault write auth/kubernetes/config \ issuer="https://kubernetes.default.svc.cluster.local" \ token_reviewer_jwt="$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \ kubernetes_host="https://$KUBERNETES_PORT_443_TCP_ADDR:443" \ kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt \ disable_iss_validation=trueCréer la règle d'authentification
vault policy write apigee-runtime-app - <<EOF path "secret/data/runtime-gcp-sa-key" { capabilities = ["read"] } EOFLier la stratégie au compte de service
vault write auth/kubernetes/role/apigee-runtime-role \ bound_service_account_names=apigee-runtime-sa \ bound_service_account_namespaces=${APIGEE_NAMESPACE} \ policies=apigee-runtime-app \ ttl=20m
Ici, nous supposons que le compte de service se trouve dans l'espace de noms apigee. Si vous disposez d'un autre espace de noms pour installer Apigee, vous utiliserez ce nom.
Quitter l'interface système dans vault-0 ?
exit
Installer le pilote CSI du magasin de secrets
# Add repo to helm helm repo add secrets-store-csi-driver https://raw.githubusercontent.com/kubernetes-sigs/secrets-store-csi-driver/master/charts # Install driver in cluster helm install csi secrets-store-csi-driver/secrets-store-csi-driverCréer une ressource Kubernetes
SecretProviderClassqui référence le secret que vous avez créé dans Vaultcat > spc-vault.yaml <<EOF apiVersion: secrets-store.csi.x-k8s.io/v1alpha1 kind: SecretProviderClass metadata: name: vault-apigee-runtime-gcp-sa-key spec: provider: vault parameters: vaultAddress: "http://vault.default:8200" roleName: "apigee-runtime-role" objects: | - objectName: "client_secret.json" secretPath: "secret/data/runtime-gcp-sa-key" secretKey: "key" EOFAppliquer la fonction
yamlkubectl apply -f spc-vault.yamlCréez le compte de service Kubernetes auquel nous avons attribué les autorisations à l'étape 4.e.
kubectl create serviceaccount -n ${APIGEE_NAMESPACE} apigee-runtime-saModifiez le fichier apigee-environment.yaml pour l'environnement et ajoutez les lignes suivantes :
apiVersion: apigee.cloud.google.com/v1alpha2 kind: ApigeeEnvironment # existing content spec: name: {ENV_NAME} organizationRef: {ORG_NAME} components: runtime: # existing content pod containers: - name: apigee-runtime podServiceAccountName: apigee-runtime-sa # existing content volumeMounts: - name: secrets-store-inline mountPath: "/opt/apigee/sa" readOnly: true volumes: - name: secrets-store-inline csi: driver: secrets-store.csi.k8s.io readOnly: true volumeAttributes: secretProviderClass: "vault-apigee-runtime-gcp-sa-key"Appliquez les modifications :
kubectl apply -k ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/environments/$ENV_NAME
Mise à niveau d'Apigee hybrid
Vous devez satisfaire toutes les exigences mentionnées dans la section Prérequis. En outre, il est recommandé d'effectuer un redémarrage progressif de tous les composants pour vérifier que le cluster est opérationnel. L'ordre de redémarrage est Cassandra, Redis, ApigeeOrganization et ApigeeEnvironment.
Créer une sauvegarde
Créez une copie de sauvegarde de la configuration actuelle d'hybrid. La sauvegarde sera nécessaire si vous êtes amené à effectuer un rollback de la mise à niveau vers la version actuelle.
tar -czvf apigee-hybrid-install.v-X.Y.Z.tar.gz $HYBRID_INSTALL_BASE_DIRCréez une sauvegarde de la base de données Cassandra. Les sauvegardes Cassandra constituent une mesure importante de protection contre les scénarios de catastrophe.
Mettre à niveau votre plate-forme Kubernetes si nécessaire
Cette étape n'est pas obligatoire à chaque fois, mais vous devrez mettre à niveau votre plate-forme Kubernetes telle que Kubernetes, OpenShift et les composants tels que cert-manager, cassandra, etc., si la version n'est plus compatible avec une version plus récente d'Apigee hybrid. La documentation contient les versions compatibles des plates-formes et des composants.
Télécharger les fichiers de configuration
Téléchargez le dépôt et remplacez les dossiers bases et tools de la configuration Apigee hybrid existante par un dossier plus récent :
Clonez le tag preview-1 du dépôt GitHub à l'adresse
https://github.com/apigee/apigee-hybrid-install/releases/tag/preview-1.Le dépôt cloné présente une structure semblable à celle décrite dans la section Structure des dossiers de configuration d'Apigee hybrid :
Remplacez le dossier d'initialisation, des outils et du contrôleur dans la configuration Apigee hybrid existante.
export HYBRID_INSTALL_HOME=PATH_TO_PREVIOUS_HYBRID_INSTALL_DIRECTORY mv -f bases $HYBRID_INSTALL_HOME/bases mv -f tools $HYBRID_INSTALL_HOME/tools
Mettre à jour les autorisations de compte de service si nécessaire
Cette étape n'est pas non plus nécessaire à chaque fois. Vous devez toutefois créer un nouveau compte de service ou mettre à jour les autorisations des comptes de service existants si nécessaire. Le guide de mise à niveau fournit des informations sur les comptes de service à modifier ou à créer, ainsi que sur les rôles à ajouter.
Si vous devez modifier les autorisations des comptes de service existants, utilisez la commande
gcloudappropriée. Le guide de mise à niveau contiendra les commandes et les rôles détaillés à ajouter.gcloud projects add-iam-policy-binding $PROJECT_ID \ --member="serviceAccount:apigee-component@$PROJECT_ID.iam.gserviceaccount.com" \ --role="roles/$NEW_ROLE"Si la version la plus récente d'Apigee hybrid peut nécessiter un compte de service supplémentaire pour les composants nouveaux / existants, vous devez les créer. Vous pouvez utiliser le script
apigee-create-service-account.shfourni dans le dossier de l'outil pour créer les nouveaux comptes de service. Comme le script sera déjà mis à jour dans le cadre de l'étape 4, il contiendra les détails et le nouveau profil requis pour la création du nouveau compte de service.Le nom du compte de service que vous venez de créer doit être référencé dans la ressource personnalisée du composant correspondant.
./tools/create-service-account --env prod --profile apigee-component
Mettre à niveau le contrôleur
Remplacez les champs de version des composants listés dans ${INSTALL_DIR}/overlays/instances/$INSTANCE_DIR/kustomization.yaml par la version hybride appropriée.
Voici un exemple de fichier $INSTALL_DIR/overlays/instances/$INSTANCE_DIR/kustomization.yaml. La valeur du champ de version doit être mise à jour vers la version appropriée.
resources:
- datastore/
- environments/
- organization/
- redis/
- route-config/
- telemetry/
patches:
- target:
group: apigee.cloud.google.com
version: v1alpha1
kind: ApigeeDatastore
patch: |-
- op: add
path: /spec/version
value: 1-6-1 (Modify the version)
- target:
group: apigee.cloud.google.com
version: v1alpha2
kind: ApigeeEnvironment
patch: |-
- op: add
path: /spec/version
value: 1-6-1 (Modify the version)
Suivez les mêmes étapes que celles fournies dans la section Créer des ressources et un contrôleur d'initialisation dans le workflow d'installation d'Apigee hybrid. Vous pouvez utiliser un script ou suivre les étapes manuelles fournies pour mettre à niveau les ressources et le contrôleur d'initialisation.
Mettre à jour les composants Kubernetes d'Apigee
Vous devrez apporter les modifications suivantes : - En cas de modification de l'architecture, d'introduction de nouveaux champs ou d'abandon d'anciens champs, vous devrez modifier les ressources personnalisées avec les modifications appropriées, conformément aux instructions du guide de mise à niveau. - Au minimum, vous devrez mettre à jour les champs de version dans les ressources personnalisées (qui indiqueront la version d'Apigee hybrid installée) vers la version la plus récente d'Apigee hybrid.
Appliquez les modifications aux ressources personnalisées Apigee. Pour les environnements non production, vous pouvez appliquer simultanément toutes les modifications aux composants Apigee.
kubectl apply -f ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}
Effectuer un rollback d'Apigee hybrid
Restaurer apigee-hybrid-setup
Accédez au répertoire contenant la version précédente de la configuration Apigee hybrid. Si cette version n'est pas disponible, restaurez-la à partir du fichier ZIP créé à l'étape 1 [lien] lors de la mise à niveau d'Apigee hybrid.
Effectuer un rollback des composants Kubernetes
Appliquez les modifications aux RS Apigee.
kubectl apply -k ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}Rollback du contrôleur
Suivez les mêmes étapes que celles fournies dans la section Créer des ressources et un contrôleur d'initialisation dans le workflow d'installation d'Apigee hybrid. Vous pouvez utiliser un script ou suivre les étapes manuelles fournies pour effectuer le rollback des ressources et du contrôleur d'initialisation.
Nettoyage
Vous devrez nettoyer toutes les nouvelles ressources supplémentaires créées lors de la mise à niveau, comme les nouveaux composants ou les comptes de service introduits dans la nouvelle version d'hybrid. Toutes les ressources à nettoyer et les étapes à suivre pour le faire seront fournies dans le guide de mise à niveau.
Supprimer un environnement
Voici les étapes à suivre pour supprimer toutes les ressources associées à un environnement de votre cluster Kubernetes :
Obtenez le nom de la RS de l'environnement. Pour ce faire, récupérez tous les environnements :
kubectl get env -n ${APIGEE_NAMESPACE}Stockez le nom de la ressource dans la variable d'environnement
APIGEE_ENV.Supprimez les clés de chiffrement de l'environnement. Par exemple, si vous n'avez pas modifié le nom des clés de chiffrement, vous pouvez les supprimer en utilisant :
kubectl delete secret -n ${APIGEE_NAMESPACE} $APIGEE_ENV-encryption-keysSupprimez les codes secrets du compte de service Google Cloud :
kubectl delete secret -n ${APIGEE_NAMESPACE} $(kubectl get env $APIGEE_ENV -n ${APIGEE_NAMESPACE} -o=jsonpath='{.spec.components.*.appServiceAccountSecretName}')Supprimez les comptes de service Kubernetes :
kubectl delete secret -n ${APIGEE_NAMESPACE} $(kubectl get env $APIGEE_ENV -n ${APIGEE_NAMESPACE} -o=jsonpath='{.spec.components.*.podServiceAccountName}')Supprimez la ressource personnalisée de l'environnement Apigee :
kubectl -n ${APIGEE_NAMESPACE} delete env $APIGEE_ENV
Supprimer une configuration hybride
Voici les étapes à suivre pour supprimer de votre cluster Kubernetes toutes les ressources liées à Apigee hybrid :
Vous devez supprimer les tâches de configuration d'utilisateur et de schéma Apigee.
# To list all jobs in ${APIGEE_NAMESPACE} kubectl -n ${APIGEE_NAMESPACE} get jobs # To delete all jobs in ${APIGEE_NAMESPACE} kubectl -n ${APIGEE_NAMESPACE} delete jobs $(kubectl -n ${APIGEE_NAMESPACE} get jobs -o custom-columns=':.metadata.name')Vous devez supprimer les composants Apigee hybrid déployés dans le plan de données. Exécutez la commande suivante pour supprimer tous les composants :
kubectl delete -k ${INSTALL_DIR}/overlays/instances/$INSTANCE_NAMECette étape n'est requise que si vous n'avez pas utilisé le nom par défaut pour les secrets de compte de service Kubernetes, les secrets de compte de service Google Cloud, etc. Si vous avez utilisé les noms par défaut, ils seront supprimés à l'étape suivante. Sinon, vous devrez les supprimer manuellement avec les commandes suivantes :
kubectl delete secret -n ${APIGEE_NAMESPACE} $(kubectl get ${APIGEE_COMPONENT} ${APIGEE_COMPONENT_NAME} -n ${APIGEE_NAMESPACE} -o=jsonpath='{.spec.components.*.appServiceAccountSecretName}') kubectl delete secret -n ${APIGEE_NAMESPACE} $(kubectl get ${APIGEE_COMPONENT} ${APIGEE_COMPONENT_NAME} -n ${APIGEE_NAMESPACE} -o=jsonpath='{.spec.components.*.podServiceAccountName}')Avec openshift, vous devez supprimer les contraintes SCC (Security Context Constraints) créées lors de l'installation d'Apigee hybrid.
kubectl delete scc ${SECURITY_CONTEXT_CONSTRAINTS_NAME}Exécutez la commande ci-dessous pour supprimer les rôles, liaisons de rôles, CRD, déploiements de contrôleurs, etc.
kubectl delete -k ${INSTALL_DIR}/overlays/initialization/ingress kubectl delete -k ${INSTALL_DIR}/overlays/initialization/rbac kubectl delete -k ${INSTALL_DIR}/overlays/initialization/webhooks kubectl delete -k ${INSTALL_DIR}/overlays/initialization/crds kubectl delete -k ${INSTALL_DIR}/overlays/initialization/certificatesExécutez la commande ci-dessous pour supprimer l'espace de noms Apigee.
kubectl delete -f ${INSTALL_DIR}/overlays/initialization/namespace.yamlVous pouvez également utiliser la commande suivante :
kubectl delete $APIGEE_NAMESPACE
Installation multi-instances
La configuration multi-instances fait référence à la configuration hybride qui peut s'étendre sur plusieurs régions ou dans les mêmes régions. Apigee recommande d'organiser les configurations de la deuxième instance dans une structure de répertoires distincte, car les configurations de l'environnement (instances répliquées, etc.) sont invariablement différentes entre les instances. Les configurations de chaque instance sont découplées et organisées indépendamment dans leurs structures de dossiers respectives.
Par exemple, pour une configuration active/passive dans un scénario multirégional, vous pouvez configurer une deuxième région de secours dans un modèle tiède, avec des configurations et des dimensionnements différents.
Dans la structure de dossiers ci-dessous, vous pouvez créer une copie du répertoire instance1 appelée instance2 et modifier les configurations du datastore et d'entrée si nécessaire.
Structure du dossier apigee-hybrid-setup pour la configuration multi-instance.
.
├── bases
│ ├── controllers
│ │ ├── apigee-controller
│ │ │ ├── apigee-controller-deployment.yaml
│ │ │ └── kustomization.yaml
│ │ └── istiod
│ │ ├── apigee-ingressgateway-manager-deployment.yaml
│ │ └── kustomization.yaml
│ └── initialization
│ ├── certificates
│ │ ├── certificates-and-issuers.yaml
│ │ └── kustomization.yaml
│ ├── crds
│ │ ├── customresourcedefinition-apigeedatastores.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeedeployments.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeeenvironments.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeeorganizations.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeeredis.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeerouteconfigs.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeeroutes.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeetelemetries.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-cassandradatareplications.apigee.cloud.google.com.yaml
│ │ └── kustomization.yaml
│ ├── ingress
│ │ ├── envoyfilter-1.11.yaml
│ │ └── kustomization.yaml
│ ├── openshift
│ │ ├── kustomization.yaml
│ │ └── scc.yaml
│ ├── rbac
│ │ ├── apigee-controller
│ │ │ ├── kustomization.yaml
│ │ │ └── rbac.yaml
│ │ └── apigee-embedded-ingress-controller
│ │ ├── cluster-role-bindings.yaml
│ │ ├── cluster-roles.yaml
│ │ ├── kustomization.yaml
│ │ └── service-account.yaml
│ └── webhooks
│ ├── kustomization.yaml
│ ├── mutatingwebhookconfiguration.yaml
│ └── validatingwebhookconfiguration.yaml
├── instances
│ └── instance1 (Add the 2nd instance under instances directory similar to instance1)
│ ├── datastore
│ │ ├── apigee-datastore.yaml
│ │ ├── components
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── environments
│ │ ├── kustomization.yaml
│ │ └── test
│ │ ├── apigee-environment.yaml
│ │ ├── components
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── kustomization.yaml
│ ├── organization
│ │ ├── apigee-organization.yaml
│ │ ├── components
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── redis
│ │ ├── apigee-redis.yaml
│ │ ├── components
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── route-config
│ │ ├── kustomization.yaml
│ │ └── test-env-group
│ │ ├── apigee-route-config.yaml
│ │ ├── components
│ │ │ ├── http-and-non-sni-client
│ │ │ │ ├── apigee-route.yaml
│ │ │ │ └── kustomization.yaml
│ │ │ ├── http-client
│ │ │ │ ├── apigee-route.yaml
│ │ │ │ └── kustomization.yaml
│ │ │ └── non-sni-client
│ │ │ ├── apigee-route.yaml
│ │ │ └── kustomization.yaml
│ │ └── kustomization.yaml
│ └── telemetry
│ ├── apigee-telemetry.yaml
│ ├── components
│ │ ├── http-proxy
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── imagepullsecret
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── logger
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── metrics
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── nodeselector
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── workload-identity-logger
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ └── workload-identity-metrics
│ │ ├── apigee-workload-identities.yaml
│ │ ├── kustomization.yaml
│ │ └── patch.yaml
│ └── kustomization.yaml
├── overlays
│ ├── controllers
│ │ ├── apigee-controller
│ │ │ ├── apigee-hybrid-config.yaml
│ │ │ ├── components
│ │ │ │ ├── imagepullsecret
│ │ │ │ │ ├── kustomization.yaml
│ │ │ │ │ └── patch.yaml
│ │ │ │ └── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── kustomization.yaml
│ │ ├── istiod
│ │ │ ├── apigee-ingressgateway-manager-deployment-patch.yaml
│ │ │ ├── apigee-istio-mesh-config.yaml
│ │ │ ├── components
│ │ │ │ ├── imagepullsecret
│ │ │ │ │ ├── kustomization.yaml
│ │ │ │ │ └── patch.yaml
│ │ │ │ └── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── kustomization.yaml
│ │ └── kustomization.yaml
│ ├── initialization
│ │ ├── certificates
│ │ │ ├── apigee-ingressgateway-manager-certificate.yaml
│ │ │ └── kustomization.yaml
│ │ ├── crds
│ │ │ └── kustomization.yaml
│ │ ├── ingress
│ │ │ └── kustomization.yaml
│ │ ├── namespace.yaml
│ │ ├── openshift
│ │ │ ├── kustomization.yaml
│ │ │ └── scc.yaml
│ │ ├── rbac
│ │ │ ├── apigee-controller
│ │ │ │ └── kustomization.yaml
│ │ │ ├── apigee-embedded-ingress-controller
│ │ │ │ └── kustomization.yaml
│ │ │ └── kustomization.yaml
│ │ └── webhooks
│ │ ├── kustomization.yaml
│ │ ├── mutatingwebhookconfiguration.yaml
│ │ └── validatingwebhookconfiguration.yaml
│ └── instances
│ └── instance1
│ ├── datastore
│ │ ├── apigee-datastore.yaml
│ │ ├── components
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── openshift-scc
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── scc.yaml
│ │ │ └── workload-identity
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── environments
│ │ ├── kustomization.yaml
│ │ └── test
│ │ ├── apigee-environment.yaml
│ │ ├── components
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── kustomization.yaml
│ ├── organization
│ │ ├── apigee-organization.yaml
│ │ ├── components
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── redis
│ │ ├── apigee-redis.yaml
│ │ ├── components
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── route-config
│ │ ├── kustomization.yaml
│ │ └── test-envgroup
│ │ ├── apigee-route-config.yaml
│ │ ├── components
│ │ │ ├── http-and-non-sni-client
│ │ │ │ ├── apigee-route.yaml
│ │ │ │ └── kustomization.yaml
│ │ │ ├── http-client
│ │ │ │ ├── apigee-route.yaml
│ │ │ │ └── kustomization.yaml
│ │ │ └── non-sni-client
│ │ │ ├── apigee-route.yaml
│ │ │ └── kustomization.yaml
│ │ └── kustomization.yaml
│ └── telemetry
│ ├── apigee-telemetry.yaml
│ ├── components
│ │ ├── http-proxy
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── imagepullsecret
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── logger
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── metrics
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── nodeselector
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── openshift-scc
│ │ │ ├── kustomization.yaml
│ │ │ └── scc.yaml
│ │ ├── workload-identity-logger
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ └── kustomization.yaml
│ │ └── workload-identity-metrics
│ │ ├── apigee-workload-identities.yaml
│ │ ├── kustomization.yaml
│ │ └── patch.yaml
│ └── kustomization.yaml
├── README.md
├── templates
│ ├── ingress-certificate.yaml
│ ├── ingress-cert-secret.yaml
│ └── service-account-key-secret.yaml
└── tools
├── apigee-hybrid-setup.sh
├── common.sh
├── create-service-account.sh
└── dump_kubernetes.sh
Configuration multi-instances sur GKE
Prérequis
Avant de configurer plusieurs instances d'hybrid, vous devez remplir les conditions préalables suivantes :
- Configurer des clusters Kubernetes dans plusieurs régions (identiques ou différentes) avec des blocs CIDR différents
- Configurez la communication interrégionale
- Ouvrez les ports Cassandra 7 000 et 7 001 entre les clusters Kubernetes dans toutes les régions (le port 7 000 peut être utilisé comme option de sauvegarde lors du dépannage). Consultez également la section Configurer les ports.
Vous pouvez utiliser un outil tel que ntpdate pour vérifier que les heures du serveur sont synchronisées.
Configurer l'hôte source multirégional
- Créez une copie du dossier $INSTANCE_NAME à partir de votre instance existante, puis ajoutez-le dans le dossier des instances.
- Modifiez la valeur du champ "namespace" si elle diffère de l'espace de noms instance1.
- Suivez les étapes spécifiées dans Spécifier des certificats TLS d'entrée pour modifier la configuration d'entrée de l'autre instance.
Consultez la section Gérer la passerelle d'entrée Apigee pour en savoir plus sur la configuration de l'adresse IP de l'équilibreur de charge pour l'autre instance.
Définissez le contexte kubectl sur le cluster d'origine avant de récupérer le nom source.
kubectl config use-context original-cluster-nameExécutez la commande kubectl suivante pour identifier une adresse d'hôte source pour Cassandra dans la région actuelle.
kubectl get pods -o wide -n apigee -l app=apigee-cassandraToutes les adresses IP de pod renvoyées par la commande précédente peuvent être considérées comme les hôtes sources multirégionaux.
Dans la deuxième instance, configurez la valeur de multiRegionSeedHost dans le RS de datastore apigee sous ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/datastore/apigee-datastore.yaml
Configurer la nouvelle instance
Définir le contexte du cluster de configuration
kubectl config use-context existing-cluster-nameExporter le secret apigee-ca vers un fichier
kubectl -n cert-manager get secret apigee-root-certificate -o yaml > apigee-root-certificate.yamlDéfinissez le contexte sur le nom du cluster de la nouvelle région :
kubectl config use-context NEW_CLUSTER_NAMEImporter le secret dans le nouveau cluster
kubectl -n cert-manager apply -f apigee-root-certificate.yamlInstallez la version hybride dans la nouvelle instance (région) en suivant les étapes décrites dans la section Créer des ressources et un contrôleur d'initialisation.
Configurez Cassandra sur tous les pods des nouveaux centres de données. Obtenez apigeeorg à partir du cluster à l'aide de la commande suivante :
kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name"Créez un fichier de ressource personnalisée pour la réplication de données Cassandra (YAML). Le fichier peut porter n'importe quel nom. Dans les exemples suivants, le fichier sera nommé datareplication.yaml. Le fichier doit contenir les éléments suivants :
apiVersion: apigee.cloud.google.com/v1alpha1 kind: CassandraDataReplication metadata: name: REGION_EXPANSION namespace: NAMESPACE spec: organizationRef: APIGEEORG_VALUE force: false source: region: SOURCE_REGIONOù :
- REGION_EXPANSION est le nom que vous attribuez à ces métadonnées. Vous pouvez choisir un nom tel que "cassandra-data-replication".
- NAMESPACE est le même espace de noms que celui choisi pour la deuxième instance. Il s'agit généralement de "apigee".
- APIGEEORG_VALUE APIGEEORG_VALUE est le résultat de la valeur de la commande kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name" de l'étape précédente.
- SOURCE_REGION est la valeur de la valeur du centre de données cassandra à partir de l'état de l'outil de nœud dans le cluster source.
Appliquez l'instance CassandraDataReplication à l'aide de la commande suivante :
kubectl apply -f datareplication.yamlVérifiez l'état de la recompilation à l'aide de la commande suivante.
kubectl -n apigee get apigeeds -o json | jq ".items[].status.cassandraDataReplication"Le résultat doit ressembler à ceci :
{ "rebuildDetails": { "apigee-cassandra-default-0": { "state": "complete", "updated": 1623105760 }, "apigee-cassandra-default-1": { "state": "complete", "updated": 1623105765 }, "apigee-cassandra-default-2": { "state": "complete", "updated": 1623105770 } }, "state": "complete", "updated": 1623105770 }Vérifiez les processus de recompilation des journaux. Vérifiez également la taille des données à l'aide de la commande "nodetool status" :
kubectl logs apigee-cassandra-default-0 -f -n apigeeReportez-vous au fichier datastore/secrets.yaml pour JMX_user et JMX_password.
kubectl exec apigee-cassandra-default-0 -n apigee -- nodetool -u JMX_user -pw JMX_password statusSupprimez
multiRegionSeedHostde la ressource personnalisée de datastore apigee et exécutez la commande ci-dessous pour appliquer la modification.kubectl apply k apply -k ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/datastoreVérifier l'état du cluster Cassandra
La commande suivante permet de voir si la configuration du cluster a réussi dans deux centres de données. La commande vérifie l'état de nodetool pour les deux régions.
kubectl exec apigee-cassandra-default-0 -n apigee -- nodetool -u JMX_user -pw JMX_password statusDatacenter: us-central1 ======================= Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.12.1.45 112.09 KiB 256 100.0% 3c98c816-3f4d-48f0-9717-03d0c998637f ra-1 UN 10.12.4.36 95.27 KiB 256 100.0% 0a36383d-1d9e-41e2-924c-7b62be12d6cc ra-1 UN 10.12.5.22 88.7 KiB 256 100.0% 3561f4fa-af3d-4ea4-93b2-79ac7e938201 ra-1 Datacenter: us-west1 ==================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.0.4.33 78.69 KiB 256 100.0% a200217d-260b-45cd-b83c-182b27ff4c99 ra-1 UN 10.0.0.21 78.68 KiB 256 100.0% 9f3364b9-a7a1-409c-9356-b7d1d312e52b ra-1 UN 10.0.1.26 15.46 KiB 256 100.0% 1666df0f-702e-4c5b-8b6e-086d0f2e47fa ra-1
Dépannage
Guide de compatibilité, de diagnostic et de dépannage
Nettoyage manuel après l'utilisation de la fonction forceDelete dans une configuration Apigee hybrid multirégionale
- L'exemple suivant comporte deux régions :
us-east1etus-west1. - Dans la région
us-west1, le datastore apigee a été supprimé à l'aide de la suppression forcée. - Dans la région
us-east1, Cassandra est toujours opérationnel. Vérifiez que
apigeedsest supprimé à l'aide de la commande.kubectl get apigeeds -n apigee No resources found in apigee namespace.Remplacez le contexte kubectl par l'autre région dans laquelle le cluster Cassandra est toujours opérationnel (ici
us-east1).Vérifiez que le datastore est en cours d'exécution.
kubectl get apigeeds -n apigee NAME STATE AGE default running 23hExécutez dans l'un des pods Cassandra de la région (ici
us-east1).kubectl exec -it -n apigee apigee-cassandra-default-0 -- bash apigee@apigee-cassandra-default-0:~$Vérifiez l'état de nodetool. Tous les nœuds indisponibles seront affichés dans la région supprimée (ici
us-west1).apigee@apigee-cassandra-default-0:~$ nodetool -u ${APIGEE_JMX_USER} -pw ${APIGEE_JMX_PASSWORD} statusDatacenter: us-east1 ==================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack UN 10.52.0.212 685.01 KiB 256 ? e1aa61e3-4eae-4549-9b58-506d495d87ab ra-1 UN 10.52.0.72 606.75 KiB 256 ? 477dfc03-f93e-40ea-810a-d15769822ad5 ra-1 UN 10.52.0.104 648.3 KiB 256 ? a8854cff-c2e3-4f0c-a342-e692787efcab ra-1 Datacenter: us-west1 ==================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack DN 10.60.0.143 567.06 KiB 256 ? 355d6ace-ab77-42cb-8138-9993bfd62d0e ra-1 DN 10.60.0.40 535.99 KiB 256 ? 4ed2c903-ff56-40fa-a15e-80a3de3cb22d ra-1 DN 10.60.0.17 573.08 KiB 256 ? f9a50d19-c04a-4d0d-a088-612384bed9f5 ra-1Supprimez tous les nœuds de la région supprimée (ici
us-west1).apigee@apigee-cassandra-default-0:~$ nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD removenode 355d6ace-ab77-42cb-8138-9993bfd62d0e apigee@apigee-cassandra-default-0:~$ nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD removenode 4ed2c903-ff56-40fa-a15e-80a3de3cb22d apigee@apigee-cassandra-default-0:~$ nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD removenode f9a50d19-c04a-4d0d-a088-612384bed9f5Vérifiez qu'aucun nœud de la région supprimée (ici
us-west1) ne reste.apigee@apigee-cassandra-default-0:~$ nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD statusDatacenter: us-east1 ==================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack UN 10.52.0.212 699.71 KiB 256 ? e1aa61e3-4eae-4549-9b58-506d495d87ab ra-1 UN 10.52.0.72 586.77 KiB 256 ? 477dfc03-f93e-40ea-810a-d15769822ad5 ra-1 UN 10.52.0.104 623.6 KiB 256 ? a8854cff-c2e3-4f0c-a342-e692787efcab ra-1Une fois l'opération terminée, supprimez le job de configuration de l'utilisateur dans la région (ici
us-east1). Le job est recréé automatiquement en quelques secondes.kubectl get jobs -n apigeeNAME COMPLETIONS DURATION AGE apigee-cassandra-schema-setup-apigee--0d2504c 0/1 5m54s 5m54s apigee-cassandra-user-setup--apigee--0d2504c 0/1 7s 7skubectl delete job apigee-cassandra-user-setup--apigee--0d2504cAttendez que la tâche de configuration de l'utilisateur soit terminée.
kubectl get jobs -n apigeeNAME COMPLETIONS DURATION AGE apigee-cassandra-schema-setup-apigee--0d2504c 1/1 5m54s 5m54s apigee-cassandra-user-setup--apigee--0d2504c 1/1 7m 7mVérifiez que les espaces de clés ne possèdent pas la région supprimée.
Créez un pod de débogage Cassandra.
Connectez-vous à cqlsh dans le pod de débogage à l'aide de la commande
apigee@cassandra-debug-client:~$ cqlsh apigee-cassandra-default-0.apigee-cassandra-default.apigee.svc.cluster.local -u ddl_user --ssl Password:Vérifiez que la région
us-west1est supprimée de tous les espaces de clés.ddl_user@cqlsh> SELECT * FROM system_schema.keyspaces;keyspace_name | durable_writes | replication ---------------------------+----------------+----------------------------------------------------------------------------------- cache_prince_hybrid_hybrid | True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'} rtc_prince_hybrid_hybrid | True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'} system_auth | True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'} system_schema | True | {'class': 'org.apache.cassandra.locator.LocalStrategy'} quota_prince_hybrid_hybrid | True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'} kms_prince_hybrid_hybrid | True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'} system_distributed | True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'} system | True | {'class': 'org.apache.cassandra.locator.LocalStrategy'} perses | True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'} kvm_prince_hybrid_hybrid | True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'} system_traces | True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'} (11 rows)