Kubernetes での APISIX デプロイのための 3 つのヒント（パート 2）

Wei Jin

Wei Jin

May 7, 2024

Technology

クラウドネイティブコンピューティングの時代において、Kubernetesはコンテナオーケストレーションプラットフォームとして広く採用され、Apache APISIXは高性能なクラウドネイティブの動的APIゲートウェイとして登場しました。Kubernetes上でのApache APISIXのデプロイはますます一般的になっています。しかし、Kubernetes上でのApache APISIXのデプロイプロセスが比較的簡単であるにもかかわらず、いくつかの重要な問題点が存在します。このシリーズの記事では、以下のトピックについて詳しく説明します：

  1. デプロイ方法に関する考慮事項
  2. ヘルスチェック、ロギング、モニタリング
  3. カスタムプラグインと設定の取り扱い

前回の記事では、最初のポイントについて説明しました。この記事では、2番目のポイントであるヘルスチェック、ロギング、モニタリングに関する考慮事項に焦点を当てます。

ヘルスチェック

Kubernetes上でAPISIXをデプロイする際、ヘルスチェックは特に重要です。これは、Kubernetesにおけるアプリケーションの基本的な要件を表しています。Kubernetesでは、Liveness ProbeとReadiness Probeを設定することで、APISIXインスタンスの健全性と可用性を確保できます。

  • Liveness Probeは、アプリケーションが実行中かどうかを判断するために使用されます。アプリケーションが健全でないと判断された場合、Kubernetesはインスタンスを再起動します。

  • Readiness Probeは、アプリケーションがトラフィックを受信する準備ができているかどうかを確認するために使用されます。アプリケーションがまだ準備できていない場合、トラフィックを受信しません。これにより、完全に起動していないか、または損傷しているインスタンスにトラフィックが送信されるのを防ぎます。

Liveness ProbeとReadiness Probeを適切に設定することで、Kubernetesは不健全なPodインスタンスを自動的に管理できます。これは、インスタンスに問題が発生した場合、Kubernetesが自動的にそれらを再起動するか、不健全なインスタンスへのトラフィック送信を停止することを意味し、システムの可用性と安定性を向上させます。

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

この例では、コンテナのLiveness ProbeとReadiness Probeを定義しています。Liveness Probeは、10秒ごとにパス/healthzにHTTP GETリクエストを送信し、コンテナの健全性を確認します。コンテナが応答しないか、200以外のステータスコードを返す場合、Kubernetesはコンテナが不健全であると判断し、再起動を試みます。Readiness Probeも同様ですが、コンテナがトラフィックを受信する準備ができているかどうかを確認するために使用されます。

モニタリング

APISIXの実行時モニタリングにはさまざまな方法がありますが、Prometheusとの統合が推奨されるアプローチです。実際、Prometheusは現在も最も広く使用されているモニタリングコンポーネントです。

Prometheusを統合することで、APISIXおよびそれがプロキシするサービスのメトリクスを収集および監視できます。これらのメトリクスには、リクエストレート、エラーレート、レイテンシなどの重要なパフォーマンス指標が含まれる場合があります。これらのメトリクスを監視することで、問題を迅速に特定し、パフォーマンスチューニングやトラブルシューティングを行うことができます。メトリクスとアラートルールを適切に設定し、問題が発生した際に迅速に対応できるようにしてください。

APISIXでPrometheusプラグインを有効にするのは簡単です。まず、config.yamlでexport_uriを設定します。

plugin_attr:
  prometheus:
    export_uri: /apisix/metrics

次に、Prometheusで統計分析が必要なAPIまたはサービスでプラグインを有効にします。

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

最後に、Prometheusサーバーはexport_uriから定期的に設定をプルできます。

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

実際の使用では、Prometheusも高可用性を確保するためにデプロイする必要があります。例えば、Thanosなどのオープンソースソリューションを使用します。APISIXとの統合は、Thanosのサイドカーモードを使用して実現できます。

ロギング

APISIXでは、重要なログは大きく2つのタイプに分類されます：トラフィックログと監査ログです。

  • トラフィックログは、APISIXがリバースプロキシとして動作する際の各リクエストのログを指します。これらのログには、リクエストトラフィックと返された情報、およびAPISIXの内部操作ログが含まれており、トレースやトラブルシューティングに重要です。通常、適切なログレベルとフォーマットを設定して記録します。実際のシナリオでは、ログを集中ログシステム（ELK（Elasticsearch、Logstash、Kibana）、Fluentd、またはSplunkなど）に出力することを検討してください。APISIXはログプラグインを提供しています。

  • 監査ログは、主にAPISIXの設定を管理する際に生成されるログを指します。これらは、コンプライアンス要件を満たすだけでなく、セキュリティ分析にも役立ちます。監査ログを分析することで、潜在的なセキュリティリスクや不適切な設定や管理行為を特定し、対応策を講じてシステムのセキュリティを向上させることができます。

オープンソースのAPISIXは、設定配布を容易にするためのAdmin APIを提供していますが、監査ログに関する設定は含まれていません。通常、ユーザーはこれらのログを自分で記録するか、APISIXのエンタープライズ版を使用する必要があります。

Kubernetesと他の環境でのロギング設定には大きな違いはありません。APISIXでアップストリームと関連情報を設定する際、Kubernetesのサービスディスカバリが一般的に使用されることに注意してください。後続の問題のトラブルシューティングを容易にするために、ログにサービス名を記録することをお勧めします。

結論

ヘルスチェックメカニズムを設定してAPISIXの不健全なインスタンスを検出することで、Kubernetesは迅速にトラフィックの移行と回復を促進し、APIサービスの継続性と安定性を確保できます。APISIXはまた、Prometheusなどの高度なモニタリングツールとの統合をサポートしており、リクエストレート、エラーレート、レイテンシなどの主要なメトリクスを含むAPIのパフォーマンスと安定性を監視できます。この監視機能により、組織は潜在的な問題を迅速に特定し、タイムリーなパフォーマンスチューニングと最適化を行うことができ、APIサービスの効率的な運用を確保します。

Tags:
Kubernetes
APISIX Basics