Aide relative à l’exécution d’une passerelle auto-hébergée sur Kubernetes en production

  • Article

S’APPLIQUE À : Développeur | Premium

Afin d’exécuter la passerelle auto-hébergée en production, il y a plusieurs aspects à prendre en compte. Par exemple, elle doit être déployée de façon hautement disponible, utiliser des sauvegardes de configuration pour gérer les déconnexions temporaires et bien plus encore.

Cet article fournit une aide sur la façon d’exécuter une passerelle auto-hébergée sur Kubernetes pour les charges de travail de production afin de s’assurer qu’elle fonctionnera correctement et de manière fiable.

Access token (Jeton d’accès)

Sans un jeton d’accès valide, une passerelle auto-hébergée ne peut pas accéder aux données de configuration ni les télécharger à partir du point de terminaison du service Gestion des API associé. Le jeton d’accès reste valide pendant un maximum de 30 jours. Le jeton doit être regénéré, et le cluster doit être configuré avec un nouveau jeton, manuellement ou via l’automatisation, avant son expiration.

Lorsque vous automatisez l’actualisation des jetons, utilisez cette opération d’API de gestion pour générer un nouveau jeton. Pour plus d’informations sur la gestion des secrets Kubernetes, consultez le site Web Kubernetes.

Conseil

Vous pouvez également déployer la passerelle auto-hébergée sur Kubernetes et activer l’authentification auprès de l’instance API management à l’aide de Microsoft Entra ID.

Mise à l’échelle automatique

Alors que nous fournissons des conseils sur le nombre minimal de réplicas pour la passerelle auto-hébergée, nous vous recommandons d’utiliser la mise à l’échelle automatique pour la passerelle auto-hébergée pour répondre à la demande de votre trafic de manière plus proactive.

Il existe deux façons de mettre automatiquement à l’échelle la passerelle auto-hébergée :

  • Mise à l’échelle automatique en fonction de l’utilisation des ressources (UC et mémoire)
  • Mise à l’échelle automatique en fonction du nombre de demandes par seconde

Cela est possible grâce à la fonctionnalité Kubernetes native, ou à l’utilisation de la mise à l’échelle automatique pilotée par les événements Kubernetes (KEDA). KEDA est un projet CNCF Incubation qui s’efforce de rendre la mise à l’échelle automatique des applications simple.

Notes

KEDA est une technologie open source qui n’est pas prise en charge par le support Azure et qui doit être gérée par les clients.

Mise à l’échelle automatique basée sur les ressources

Kubernetes vous permet de mettre à l’échelle automatiquement la passerelle auto-hébergée en fonction de l’utilisation des ressources à l’aide d’un Autoscaler de pod horizontal. Cela vous permet de définir des seuils de mémoire et d’UC, ainsi que le nombre de réplicas pour effectuer un scale-out ou un scale-in.

Une alternative consiste à utiliser la mise à l’échelle automatique pilotée par les événements Kubernetes (KEDA), ce qui vous permet de mettre à l’échelle des charges de travail en fonction d’une variété d’échelles, y compris le processeur et la mémoire.

Conseil

Si vous utilisez déjà KEDA pour mettre à l’échelle d’autres charges de travail, nous vous conseillons d’utiliser KEDA comme un autoscaler d’application unifié. Dans le cas contraire, nous vous conseillons de vous appuyer sur la fonctionnalité Kubernetes native à l’aide d’un autoscaler de pod horizontal.

Mise à l’échelle automatique basée sur le trafic

Kubernetes ne fournit pas de mécanisme prêt à l’emploi pour la mise à l’échelle automatique basée sur le trafic.

La mise à l’échelle automatique pilotée par les événements Kubernetes (KEDA) offre plusieurs méthodes qui peuvent vous aider à mettre à l’échelle la mise à l’échelle automatique basée sur le trafic :

  • Vous pouvez le mettre à l’échelle en fonction des métriques d’une entrée de Kubernetes si elles sont disponibles dans Prometheus ou Azure Monitor à l’aide d’une mise à l’échelle prête à l’emploi
  • Vous pouvez installer le module complémentaire HTTP, disponible en version bêta, et la mise à l’échelle en fonction du nombre de demandes par seconde.

Sauvegarde de la configuration

Configurez un volume de stockage local pour le conteneur de la passerelle auto-hébergée, afin qu’il puisse conserver une copie de sauvegarde de la dernière configuration téléchargée. Si la connectivité est interrompue, le volume de stockage peut utiliser la copie de sauvegarde lors du redémarrage. Le chemin du montage du volume doit être /apim/config et doit être détenu par l’ID de groupe 1001. Consultez un exemple sur GitHub. Pour en savoir plus sur le stockage dans Kubernetes, consultez le site Web Kubernetes. Pour modifier la propriété d’un chemin monté, consultez le paramètre securityContext.fsGroup sur le site web de Kubernetes.

Notes

Pour en savoir plus sur le comportement de la passerelle auto-hébergée en cas de panne de connectivité temporaire à Azure, consultez Vue d’ensemble de la passerelle auto-hébergée.

Étiquette de l’image conteneur

Le fichier YAML fourni dans le Portail Azure utilise la balise la plus récente. Cette balise référence toujours la version la plus récente de l’image de conteneur de passerelle auto-hébergée.

Il est conseillé d’utiliser une étiquette de version distincte en production pour éviter toute mise à niveau involontaire vers une version plus récente.

Vous pouvez télécharger la liste complète des balises disponibles.

Conseil

Lors de l’installation avec Helm, le balisage d’image est optimisé pour vous. La version d’application du chart Helm épingle la passerelle sur une version donnée et ne s’appuie pas sur latest.

En savoir plus sur l’installation d’une passerelle auto-hébergée Gestion des API sur Kubernetes avec Helm.

Ressources sur les conteneurs

Par défaut, le fichier YAML fourni dans le portail Azure ne spécifie pas les demandes de ressources de conteneur.

Il est impossible de prédire et donc de recommander de manière fiable la quantité de ressources processeur et mémoire pour chaque conteneur, ainsi que le nombre de réplicas nécessaires pour prendre en charge une charge de travail spécifique. Ceci est dû à de nombreux facteurs, comme :

  • Le matériel spécifique sur lequel le cluster s’exécute.
  • La présence et le type de virtualisation.
  • Le nombre et le taux de connexions clientes simultanées.
  • Le taux de demandes.
  • Le type et le nombre de stratégies configurées.
  • La taille de la charge utile, et si les charges utiles sont mises en mémoire tampon ou diffusées en continu.
  • La latence du service back-end.

Nous vous recommandons de définir les demandes de ressources sur deux cœurs et 2 Gio comme point de départ. Effectuez un test de charge et augmentez/diminuez la taille des instances en fonction des résultats.

Noms de domaine personnalisés et certificats SSL

Si vous utilisez des noms de domaine personnalisés pour les Points de terminaison Gestion des API, et en particulier si vous utilisez un nom de domaine personnalisé pour le point de terminaison de gestion, vous devrez peut-être mettre à jour la valeur de config.service.endpoint dans le fichier <nom-passerelle.>yaml pour remplacer le nom de domaine par défaut par le nom de domaine personnalisé. Assurez-vous que le point de terminaison de gestion est accessible à partir du pod de la passerelle auto-hébergée dans le cluster Kubernetes.

Dans ce scénario, si le certificat SSL utilisé par le point de terminaison de gestion n’est pas signé par un certificat d’autorité de certification connu, vous devez vous assurer que le certificat de l’autorité de certification est approuvé par le pod de la passerelle auto-hébergée.

Notes

Avec la passerelle auto-hébergée v2, Gestion des API fournit un nouveau point de terminaison de configuration : <apim-service-name>.configuration.azure-api.net. Les noms d’hôte personnalisés sont pris en charge pour ce point de terminaison et peuvent être utilisés à la place du nom d’hôte par défaut.

Stratégie DNS

La résolution de noms DNS joue un rôle essentiel dans la capacité d’une passerelle auto-hébergée à se connecter aux dépendances dans Azure, et à distribuer des appels d’API aux services back-end.

Le fichier YAML fourni dans le Portail Azure applique la stratégie ClusterFirst par défaut. Cette stratégie entraîne le transfert des requêtes de résolution de noms non résolues par le DNS du cluster au serveur DNS en amont hérité du nœud.

Pour en savoir plus sur la résolution de noms dans Kubernetes, consultez le site Web Kubernetes. Envisagez de personnaliser la stratégie DNS ou la configuration DNS en fonction de votre configuration.

Stratégie de trafic externe

Le fichier YAML fourni dans le portail Azure définit le champ externalTrafficPolicy de l’objet externalTrafficPolicy sur Local. Cela préserve l’adresse IP de l’appelant (accessible dans le contexte de la demande) et désactive l’équilibrage de charge entre les nœuds, éliminant ainsi les tronçons réseau qui en découlent. Sachez que ce paramètre peut entraîner une distribution asymétrique du trafic dans les déploiements avec un nombre inégal de pods de passerelle par nœud.

Haute disponibilité

La passerelle auto-hébergée est un composant essentiel de l’infrastructure et doit être hautement disponible. Toutefois, une défaillance peut se produire.

Pensez à protéger la passerelle auto-hébergée contre les interruptions.

Conseil

Lors de l’installation avec Helm, activez facilement la planification de la haute disponibilité en activant l’option de configuration highAvailability.enabled.

En savoir plus sur l’installation d’une passerelle auto-hébergée Gestion des API sur Kubernetes avec Helm.

Protection contre les défaillances de nœuds

Pour éviter d’être affecté en raison de défaillances du centre de données ou des nœuds, envisagez d’utiliser un cluster Kubernetes qui utilise des zones de disponibilité pour obtenir une haute disponibilité au niveau des nœuds.

Les zones de disponibilité vous permettent de planifier le pod de la passerelle auto-hébergée sur des nœuds répartis entre les zones en utilisant :

Notes

Si vous utilisez Azure Kubernetes Service, découvrez comment utiliser les zones de disponibilité dans cet article.

Protection contre les interruptions de pod

Les pods peuvent subir des interruptions pour diverses raisons, telles que la suppression manuelle d’un pod, la maintenance d’un nœud, etc.

Envisagez d’utiliser des budgets d’interruption des pods pour imposer un nombre minimum de pods devant être disponibles à tout moment.

Proxy HTTP(S)

La passerelle auto-hébergée prend en charge le proxy HTTP(S) à l’aide des variables d’environnement traditionnelles HTTP_PROXY, HTTPS_PROXY et NO_PROXY.

Une fois configurée, la passerelle auto-hébergée utilise automatiquement le proxy pour toutes les requêtes HTTP(S) sortantes vers les services principaux.

À compter de la version 2.1.5 ou ultérieure, la passerelle auto-hébergée fournit une observabilité liée au proxy de requête :

  • L’Inspecteur d’API affiche des étapes supplémentaires lorsque le proxy HTTP(S) est utilisé et ses interactions associées.
  • Des journaux détaillés sont fournis pour indiquer le comportement du proxy de requête.

Remarque

En raison d’un problème connu avec des proxys HTTP utilisant l’authentification de base, l’utilisation de la validation d’une liste de révocation de certificats n’est pas prise en charge. Découvrez plus d’informations dans notre Documentation de référence sur les paramètres de passerelle auto-hébergée pour la configurer de manière appropriée.

Avertissement

Assurez-vous que les exigences de l’infrastructure ont été remplies et que la passerelle auto-hébergée peut toujours se connecter à celles-ci ou bien certaines fonctionnalités ne fonctionneront pas correctement.

Métriques et journaux locaux

La passerelle auto-hébergée envoie des données de télémétrie à Azure Monitor et à Azure Application Insights selon les paramètres de configuration du service Gestion des API associé. Lorsque la connectivité à Azure est temporairement perdue, le flux des données de télémétrie envoyées vers Azure est interrompu et les données sont perdues pendant toute la durée de la panne.

Envisagez d’utiliser les insights de conteneur Azure Monitor pour superviser vos conteneurs ou configurer la supervision locale pour vous assurer la capacité d’observer le trafic d’API et d’empêcher la perte de télémétrie pendant les pannes de connectivité Azure.

Espace de noms

Les espaces de noms Kubernetes permettent de diviser un cluster entre plusieurs équipes, projets ou applications. Les espaces de noms fournissent une étendue pour les ressources et les noms. Ils peuvent être associés à un quota de ressources et à des stratégies de contrôle des accès.

Le Portail Azure fournit des commandes pour créer des ressources de passerelle auto-hébergées dans l’espace de noms par défaut. Cet espace de noms est automatiquement créé, il existe dans chaque cluster et il ne peut pas être supprimé. Dans un environnement de production, il est conseillé de créer et déployer une passerelle auto-hébergée dans un espace de noms distinct.

Nombre de réplicas

Le nombre minimal de réplicas adapté à la production est de trois,de préférence en combinaison avec une planification à haute disponibilité des instances.

Par défaut, une passerelle auto-hébergée est déployée avec une stratégie de déploiement de type RollingUpdate. Passez en revue les valeurs par défaut. Il est conseillé de définir explicitement les champs maxUnavailable et maxSurge, en particulier si vous utilisez un nombre élevé de réplicas.

Performances

Nous vous recommandons de réduire les journaux de conteneur à des avertissements (warn) pour améliorer les performances. Pour plus d’informations, consultez notre référence de configuration de passerelle auto-hébergée.

Limitation des tentatives d’accès

La limitation des demandes dans une passerelle auto-hébergée peut être activée à l’aide de la Gestion des API stratégie de limite de débit ou de limite de débit par clé. Configurez le nombre de limites de débit pour synchroniser les instances de passerelle sur les nœuds de cluster en exposant les ports suivants dans le déploiement Kubernetes pour la découverte d’instances :

  • Port 4290 (UDP), pour la synchronisation limitant le débit
  • Port 4291 (UDP), pour l’envoi de pulsations à d’autres instances

Notes

Dans une passerelle auto-hébergée, les nombres limites de taux peuvent être configurés pour être synchronisés localement (entre les instances de passerelle sur les nœuds de cluster), par exemple par le biais d’un déploiement de graphique Helm pour Kubernetes ou à l’aide des modèles de déploiement du portail Azure. Toutefois, les nombres limites de débit ne se synchronisent pas avec d’autres ressources de passerelle configurées dans l’instance Gestion des API, notamment la passerelle managée dans le cloud.

Sécurité

La passerelle auto-hébergée peut s’exécuter en tant que non-racine dans Kubernetes, ce qui permet aux clients d’exécuter la passerelle en toute sécurité.

Voici un exemple de contexte de sécurité pour le conteneur de passerelle auto-hébergée :

securityContext:
  allowPrivilegeEscalation: false
  runAsNonRoot: true
  runAsUser: 1001       # This is a built-in user, but you can use any user ie 1000 as well
  runAsGroup: 2000      # This is just an example
  privileged: false
  capabilities:
    drop:
    - all

Avertissement

L’exécution de la passerelle auto-hébergée avec le système de fichiers en lecture seule (readOnlyRootFilesystem: true) n’est pas prise en charge.

Avertissement

Lorsque vous utilisez des certificats d’autorité de certification locale, la passerelle auto-hébergée doit s’exécuter avec l’ID utilisateur (UID) 1001 pour gérer les certificats d’autorité de certification, sinon la passerelle ne démarre pas.

Étapes suivantes