Version en disponibilité générale privée : utiliser un gestionnaire de certificats personnalisé avec Apigee hybridCette fonctionnalité est proposée en disponibilité générale privée pour Apigee hybrid version 1.13. |
|---|
Cette fonctionnalité vous permet d'installer un cert-manager personnalisé pour Apigee hybrid avec une configuration modifiée liée au contrôle des accès basé sur les rôles (RBAC) utilisant des autorisations restrictives.
Avant de commencer
Avant de poursuivre l'installation, téléchargez le chart Helm à l'aide des commandes suivantes :
export CHART_REPO=oci://us-docker.pkg.dev/apigee-release/apigee-hybrid-helm-chartsexport CERT_MANAGER_VERSION=v1.14.5helm pull $CHART_REPO/apigee-cert-manager --version $CERT_MANAGER_VERSION --untar
Configurer le cert-manager personnalisé
Pour configurer un cert-manager personnalisé, procédez comme suit :
Nouvelle installation d'un cert-manager personnalisé
Pour effectuer une nouvelle installation d'un cert-manager personnalisé à utiliser avec Apigee hybrid, procédez comme suit :
- Installez les CRD à l'aide de
kubectl, à l'aide des commandes suivantes :export CERT_MANAGER_VERSION=v1.14.5kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/${CERT_MANAGER_VERSION}/cert-manager.crds.yaml - Installez le composant cert-manager à l'aide du chart Helm.
helm install CERT_MANAGER_RELEASE_NAME apigee-cert-manager/ \ --namespace APIGEE_NAMESPACE
Par la suite, lorsque la nouvelle version du chart sera disponible, vous pouvez la mettre à niveau avec
helm upgrade:helm upgrade CERT_MANAGER_RELEASE_NAME apigee-cert-manager/ \ --namespace APIGEE_NAMESPACE
Passer au cert-manager personnalisé
Pour migrer d'un cert-manager non personnalisé existant vers une version personnalisée, procédez comme suit. Un seul cert-manager peut s'exécuter dans le cluster à un moment donné.
- Désactivez les webhooks existants et mettez à jour le déploiement pour qu'il n'ait aucune instance répliquée pour une migration fluide :
kubectl delete validatingwebhookconfiguration cert-manager-webhookkubectl delete mutatingwebhookconfiguration cert-manager-webhook# set the replicas to 0kubectl scale deployment cert-manager -n cert-manager --replicas=0kubectl scale deployment cert-manager-cainjector -n cert-manager --replicas=0kubectl scale deployment cert-manager-webhook -n cert-manager --replicas=0 - Installez les CRD :
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/${CERT_MANAGER_VERION}/cert-manager.crds.yaml - Installez le cert-manager personnalisé :
helm install CERT_MANAGER_RELEASE_NAME apigee-cert-manager/ \ --namespace APIGEE_NAMESPACE
- Une fois l'installation terminée, vous pouvez supprimer cert-manager installé précédemment.
Installer ou mettre à niveau Apigee hybrid avec un cert-manager personnalisé
Pour installer ou mettre à niveau Apigee hybrid avec un cert-manager personnalisé, vous devez apporter les modifications suivantes aux procédures d'installation ou de mise à niveau.
Modifications apportées à l'installation d'Apigee hybrid
Lorsque vous installez Apigee hybrid v1.13 ou version ultérieure avec un cert-manager personnalisé, apportez la modification suivante dans votre fichier overrides.yaml avant d'installer les composants Apigee hybrid dans l'Étape 10 : Installer Apigee hybrid à l'aide de Helm.
Mettez à jour votre fichier overrides.yaml pour indiquer à l'opérateur où trouver les ressources associées à cert-manager et lui permettre d'utiliser l'émetteur de cert-manager personnalisé.
certManager: namespace: APIGEE_NAMESPACE ao: certManagerCAIssuerEnabled: true
Modifications apportées à la procédure de mise à niveau d'Apigee hybrid
Lorsque vous mettez à niveau Apigee hybrid vers la version 1.13 ou une version ultérieure avec un cert-manager personnalisé, apportez les modifications suivantes après avoir suivi la procédure décrite dans Préparer la mise à niveau des charts Helm et avant d'installer les charts Helm d'Apigee hybrid :
- Apportez les modifications suivantes dans votre fichier
overrides.yamlpour indiquer à l'opérateur où trouver les ressources associées à cert-manager et lui permettre d'utiliser le ClusterIssuer du cert-manager personnalisé.certManager: namespace: APIGEE_NAMESPACE ao: certManagerCAIssuerEnabled: true
- Copiez le secret apigee-ca existant de l'espace de noms cert-manager vers votre espace de noms apigee :
kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
- Modifiez le fichier
apigee-ca.yamlpour supprimer le paramètre d'espace de noms qui identifie l'espace de noms en tant quecert-manager. - Appliquez le secret
apigee-caà votre espace de noms apigee aveckubectl apply:kubectl -n APIGEE_NAMESPACE apply -f apigee-ca.yaml
Effectuer un rollback d'une mise à niveau d'Apigee hybrid
Si vous devez effectuer un rollback vers une version précédente d'Apigee hybrid, suivez les instructions de la section Effectuer un rollback vers la version précédente.
Effectuer un rollback et désinstaller le cert-manager personnalisé
Rétablir le cert-manager personnalisé
Pour effectuer un rollback de cert-manager personnalisé, procédez comme suit :
- Désinstallez la version de Helm à l'aide de la commande suivante :
helm uninstall CERT_MANAGER_RELEASE_NAME
- Installez le cert-manager standard (non personnalisé) à l'aide de la méthode de votre choix. Veillez à utiliser la version correspondante des définitions de ressources personnalisées. Par exemple, si vous utilisez la méthode kubectl pour installer le cert-manager, les définitions de ressources personnalisées seront mises à jour vers une version correspondante, car la charge utile inclura également des définitions de ressources personnalisées. Assurez-vous que la méthode d'installation que vous utilisez inclut les définitions de ressources personnalisées.
Désinstaller le cert-manager personnalisé
Pour désinstaller le cert-manager personnalisé, procédez comme suit :
- Désinstallez la version de Helm à l'aide de la commande suivante :
helm uninstall CERT_MANAGER_RELEASE_NAME
- Supprimez les objets CRD à l'aide des commandes suivantes :
export CERT_MANAGER_VERSION=v1.14.5kubectl delete -f https://github.com/cert-manager/cert-manager/releases/download/${CERT_MANAGER_VERSION}/cert-manager.crds.yaml
Infrastructure as Code (overrides.yaml)
Le graphique Helm est compatible avec les remplacements si nécessaire, ce qui vous permet d'utiliser un fichier de remplacement si nécessaire lors de l'installation ou de la mise à niveau.
Pour éviter toute confusion, nous vous recommandons d'utiliser un nom de fichier tel que cert-manager-overrides.yaml.
Consultez la documentation cert-manager pour connaître toutes les configurations de remplacement cert-manager acceptées.
Configurations cert-manager courantes
Les exemples suivants montrent comment effectuer certaines configurations courantes de cert-manager dans Apigee hybrid.
Remplacer des images
Voici un exemple de remplacement d'images avec imagepullsecrets si vous devez héberger l'image de manière privée.
# cert-manager-overrides.yaml
global:
# Reference to one or more secrets to be used when pulling images
# ref: https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/
#
# For example:
# imagePullSecrets:
# - name: "image-pull-secret"
imagePullSecrets: []
image:
# Override the image tag to deploy by setting this variable.
# If no value is set, the chart's appVersion will be used.
repository: quay.io/jetstack/cert-manager-controller
webhook:
image:
# without a tag
repository: quay.io/jetstack/cert-manager-webhook
cainjector:
image:
# without a tag
repository: quay.io/jetstack/cert-manager-cainjector
startupapicheck:
image:
# without a tag
repository: quay.io/jetstack/cert-manager-startupapicheck
NodeSelector et affinité de nœuds
Lors de l'installation d'Apigee hybrid, vous devez utiliser des nœuds distincts pour les pods Cassandra et les autres pods. Si vous souhaitez exécuter cert-manager dans le pool de nœuds non lié à Cassandra, vous pouvez utiliser l'affinité de nœuds :
# A Kubernetes Affinity, if required; see https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.27/#affinity-v1-core
#
# For example:
# affinity:
# nodeAffinity:
# requiredDuringSchedulingIgnoredDuringExecution:
# nodeSelectorTerms:
# - matchExpressions:
# - key: cloud.google.com/gke-nodepool
# operator: In
# values:
# - master
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: KEY
operator: In
values:
- value for the non-C* node pool
webhook:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: KEY
operator: In
values:
- value for the non-C* node pool
cainjector:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: KEY
operator: In
values:
- value for the non C* node pool
Tolérances
Vous pouvez également fournir des tolérances, comme illustré dans l'exemple suivant :
# A list of Kubernetes Tolerations, if required; see https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.27/#toleration-v1-core # # For example: # tolerations: # - key: node.kubernetes.io/not-ready # operator: Equal # value: master # effect: NoSchedule tolerations: [] webhook: tolerations: [] cainjector: tolerations: [] startupapicheck: tolerations: []