云原生时代带来了 Kubernetes（K8s）作为容器编排平台的广泛应用，而 Apache APISIX 作为一款高性能、云原生动态 API 网关，在 Kubernetes 中的部署已经变得越来越普遍。然而，尽管 Apache APISIX 在 Kubernetes 上的部署过程相对轻松，但依然存在一些需要注意的关键问题。在本系列的 3 篇文章中，我们将分别探讨以下问题：
- 部署方式上的注意事项
- 健康检查 & 日志 & 监控
- 如何处理自定义插件和配置
上篇我们介绍了部署方式上的注意事项，本文将介绍第二点，即健康检查 & 日志 & 监控方面的注意事项。
健康检查
在 Kubernetes 中部署 APISIX 时，健康检查尤为重要，这也是 Kubernetes 中对应用的基本要求。在 Kubernetes 中，通过配置存活探针和就绪探针，可以确保 APISIX 实例的健康状态和可用性。
存活探针（Liveness Probe）用于检测应用程序是否处于运行状态，如果应用程序不健康，则 Kubernetes 将重新启动该实例。
就绪探针（Readiness Probe）用于检测应用程序是否准备好接收流量，如果应用程序尚未准备好，则它不会收到流量。这有助于防止将流量发送到尚未完全启动或已损坏的实例。
通过正确配置存活和就绪这两种探针，Kubernetes 能够自动管理不健康的 Pod 实例。这意味着当实例出现问题时，Kubernetes 将自动重启实例或停止将流量发送到不健康的实例，从而提高系统的可用性和稳定性。
示例 YAML 配置：
1apiVersion: v1
2kind: Deployment
3metadata:
4 name: my-apisix-pod
5spec:
6 containers:
7 - name: my-apisix-container
8 image: my-apisix-image
9 livenessProbe:
10 httpGet:
11 path: /healthz
12 port: 9080
13 initialDelaySeconds: 15
14 periodSeconds: 10
15 readinessProbe:
16 httpGet:
17 path: /readyz
18 port: 9080
19 initialDelaySeconds: 10
20 periodSeconds: 5此示例为容器定义了存活探针和就绪探针。存活探针将每隔 10 秒向路径 /healthz 发送 HTTP GET 请求以检查容器的健康状态。如果容器未响应或返回非 200 状态码，则 Kubernetes 将认为容器不健康，并尝试重新启动它。就绪探针类似，但是它用于检查容器是否准备好接收流量。
监控
对 APISIX 进行运行时监控有很多种方式，这里推荐集成 Prometheus 进行管理，因为 Prometheus 仍然是目前使用最为广泛的监控组件。
集成 Prometheus 可以帮助收集和监视 APISIX 及被其反向代理的服务指标。这些指标可以包括请求速率、错误率、延迟等关键性能指标。通过监控这些指标，您可以及时发现问题并进行性能调优和故障排除。确保配置正确的指标和警报规则，以便在系统出现问题时及时采取行动。
在 APISIX 中开启 Prometheus 插件非常方便。首先在 config.yaml 中设置 export_uri:
1plugin_attr:
2 prometheus:
3 export_uri: /apisix/metrics然后在需要被 Prometheus 统计的 API 或者 service 上开启插件。
1curl http://127.0.0.1:9180/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
2{
3 "uri": "/hello",
4 "plugins": {
5 "prometheus":{}
6 },
7 "upstream": {
8 ...
9 }
10}'
最后，Prometheus server 就可以从 export_uri 中定时拉取配置了。比如：
1scrape_configs:
2 - job_name: "apisix"
3 scrape_interval: 15s
4 metrics_path: "/apisix/prometheus/metrics"
5 static_configs:
6 - targets: ["127.0.0.1:9091"]在实际使用过程中，Prometheus 同样会要求以高可用的方式进行部署，比如 Thanos 等开源方案。可以采用 Thanos Sidecar 模式与 APISIX 进行集成。由于 Thanos Sidecar 模式超出本文讨论范围，这里不再赘述。
日志配置
在 APISIX 中，重要的日志大体分为两类：流量日志和审计日志。
流量日志是指 APISIX 作为反向代理时，对于每次请求都有相关的日志记录，是追踪和故障查的重要依据。这类日志既包含请求流量和返回的信息，也包含 APISIX 内部运行的日志记录。通常会通过设置合适的日志等级、日志格式进行记录。在实际场景中，考虑将日志输出到日志系统统一管理。比如 ELK（Elasticsearch、Logstash 和 Kibana）、Fluentd 或者 splunk。APISIX 提供当量的日志插件可供选用。
审计日志主要是指管理 APISIX 配置时形成的日志记录。不仅有助于满足合规性要求，还可以用于进行安全分析。通过分析审计日志，您可以识别潜在的安全风险和不当配置或者管理行为，并采取相应的措施来加强系统的安全性。
开源 APISIX 提供了 Admin API 方便配置下发，但并无审计日志相关配置。一般需要用户自行记录，或者使用 APISIX 的企业版产品。
Kubernetes 中关于日志的配置与其他环境并无太多差别。需要提醒的是，APISIX 配置 upstream 等相关信息时，通常会采用 Kubernetes 服务发现，推荐在日志中记录下服务名称，可以方便后续问题定位。
总结
通过配置健康检查机制检测到不健康的 APISIX 实例，Kubernetes 能够迅速采取行动迁移流量并进行恢复，从而保证了 API 服务的连续性和稳定性。APISIX 还支持集成 Prometheus 等先进的监控工具，从而实现对 API 性能和稳定性监控，包括请求速率、错误率和延迟等关键指标。这种监控能力使企业能够迅速发现潜在问题，及时进行性能调优和优化，确保 API 服务的高效运行。