3 conseils pour déployer APISIX dans Kubernetes (Partie 2)

L'ère du cloud computing natif a vu une adoption généralisée de Kubernetes en tant que plateforme d'orchestration de conteneurs, avec Apache APISIX émergeant comme une passerelle API dynamique haute performance et native du cloud. Le déploiement d'Apache APISIX dans Kubernetes est devenu de plus en plus courant. Cependant, malgré le processus de déploiement relativement simple d'Apache APISIX sur Kubernetes, il reste encore quelques points clés à considérer. Dans cette série d'articles, nous approfondirons les sujets suivants :

1. Considérations sur les méthodes de déploiement
2. Vérifications de santé, journalisation et surveillance
3. Gestion des plugins et configurations personnalisés

Dans l'article précédent, nous avons discuté du premier point. Cet article se concentrera sur le deuxième point : les considérations concernant les vérifications de santé, la journalisation et la surveillance.

Vérifications de santé

Lors du déploiement d'APISIX dans Kubernetes, les vérifications de santé sont particulièrement importantes, car elles représentent une exigence fondamentale pour les applications dans Kubernetes. Dans Kubernetes, en configurant les sondes Liveness et Readiness, l'état de santé et la disponibilité des instances d'APISIX peuvent être assurés.

• La sonde Liveness est utilisée pour déterminer si l'application est en cours d'exécution. Si l'application est jugée non saine, Kubernetes redémarrera l'instance.

• La sonde Readiness est employée pour déterminer si l'application est prête à recevoir du trafic. Si l'application n'est pas encore prête, elle ne recevra aucun trafic. Cela aide à empêcher le trafic d'être envoyé à des instances qui ne sont pas complètement démarrées ou qui sont endommagées.

En configurant correctement les sondes Liveness et Readiness, Kubernetes peut automatiquement gérer les instances de Pod non saines. Cela implique que lorsque des instances rencontrent des problèmes, Kubernetes les redémarrera automatiquement ou arrêtera d'envoyer du trafic aux instances non saines, améliorant ainsi la disponibilité et la stabilité du système.

Exemple de configuration YAML :

apiVersion: v1
kind: Deployment
metadata:
  name: my-apisix-pod
spec:
  containers:
  - name: my-apisix-container
    image: my-apisix-image
    livenessProbe:
      httpGet:
        path: /healthz
        port: 9080
      initialDelaySeconds: 15
      periodSeconds: 10
    readinessProbe:
      httpGet:
        path: /readyz
        port: 9080
      initialDelaySeconds: 10
      periodSeconds: 5

Cet exemple définit les sondes Liveness et Readiness pour le conteneur. La sonde Liveness envoie une requête HTTP GET au chemin /healthz toutes les 10 secondes pour vérifier l'état de santé du conteneur. Si le conteneur ne répond pas ou retourne un code d'état autre que 200, Kubernetes considère que le conteneur est non sain et tente de le redémarrer. La sonde Readiness est similaire mais est utilisée pour vérifier si le conteneur est prêt à recevoir du trafic.

Surveillance

Il existe diverses méthodes pour surveiller APISIX en temps d'exécution, avec l'intégration de Prometheus étant une approche recommandée. En fait, Prometheus reste le composant de surveillance le plus largement utilisé à ce jour.

L'intégration de Prometheus aide à collecter et surveiller les métriques pour APISIX et les services qu'il proxifie. Ces métriques peuvent inclure les taux de requêtes, les taux d'erreurs, la latence et d'autres indicateurs de performance critiques. En surveillant ces métriques, les problèmes peuvent être rapidement identifiés et des ajustements de performance et des dépannages peuvent être effectués. Assurez-vous de configurer correctement les métriques et les règles d'alerte pour agir rapidement lorsque des problèmes surviennent.

Activer le plugin Prometheus dans APISIX est simple. Tout d'abord, définissez l'export_uri dans config.yaml.

plugin_attr:
  prometheus:
    export_uri: /apisix/metrics

Ensuite, activez le plugin sur l'API ou le service qui doit être analysé statistiquement par Prometheus.

curl http://127.0.0.1:9180/apisix/admin/routes/1  -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "uri": "/hello",
    "plugins": {
        "prometheus":{}
    },
    "upstream": {
        ...
    }
}'

Enfin, le serveur Prometheus peut périodiquement extraire les configurations de l'export_uri.

scrape_configs:
  - job_name: "apisix"
    scrape_interval: 15s
    metrics_path: "/apisix/prometheus/metrics"
    static_configs:
      - targets: ["127.0.0.1:9091"]

Dans un usage pratique, Prometheus nécessite également un déploiement hautement disponible, comme en utilisant des solutions open source comme Thanos. L'intégration avec APISIX peut être réalisée en utilisant le mode sidecar de Thanos.

Journalisation

Dans APISIX, les journaux importants sont globalement classés en deux types : les journaux de trafic et les journaux d'audit.

• Les journaux de trafic font référence à l'enregistrement de chaque requête lorsque APISIX agit comme un proxy inverse. Ces journaux, contenant à la fois le trafic des requêtes et les informations retournées, ainsi que les journaux d'opération internes d'APISIX, sont cruciaux pour le traçage et le dépannage. Typiquement, des niveaux et formats de journal appropriés sont définis pour l'enregistrement. Dans des scénarios pratiques, envisagez de sortir les journaux vers un système de journalisation centralisé, comme ELK (Elasticsearch, Logstash et Kibana), Fluentd ou Splunk. APISIX fournit des plugins de journalisation pour sélection.

• Les journaux d'audit font principalement référence aux journaux générés lors de la gestion des configurations d'APISIX. Ils aident non seulement à répondre aux exigences de conformité, mais servent également pour l'analyse de sécurité. En analysant les journaux d'audit, des risques de sécurité potentiels et des configurations ou comportements de gestion inappropriés peuvent être identifiés, et des mesures correspondantes peuvent être prises pour améliorer la sécurité du système.

L'APISIX open source fournit une API Admin pour une distribution facile des configurations mais manque de configuration liée aux journaux d'audit. Typiquement, les utilisateurs doivent enregistrer ces journaux eux-mêmes ou utiliser l'édition entreprise d'APISIX.

Il n'y a pas beaucoup de différences dans la configuration de la journalisation entre Kubernetes et d'autres environnements. Il est à noter que lors de la configuration des informations en amont et connexes dans APISIX, la découverte de service Kubernetes est couramment utilisée. Il est recommandé d'enregistrer le nom du service dans les journaux pour faciliter le dépannage des problèmes ultérieurs.

Conclusion

En configurant des mécanismes de vérification de santé pour détecter les instances non saines d'APISIX, Kubernetes peut rapidement agir pour migrer le trafic et faciliter la récupération, assurant ainsi la continuité et la stabilité des services API. APISIX prend également en charge l'intégration avec des outils de surveillance avancés tels que Prometheus, permettant la surveillance des performances et de la stabilité des API, y compris des métriques clés telles que les taux de requêtes, les taux d'erreurs et la latence. Cette capacité de surveillance permet aux organisations d'identifier rapidement les problèmes potentiels et de procéder à des ajustements et optimisations de performance en temps opportun, assurant le fonctionnement efficace des services API.