APISIX、Prometheus、KEDAを使用してKubernetesでアプリケーションを弾力的にスケーリングする
February 17, 2023
はじめに
アプリケーションに入るトラフィック量は時とともに変化します。例えば、オンラインショッピングアプリケーションは、通常の日よりも休暇シーズンの方がはるかに忙しくなります。トラフィックに基づいてアプリケーションの容量を調整できるようになれば、ユーザー体験とサービスが大幅に向上します。
Apache APISIX は、アプリケーションのスケーリングが必要かどうかを判断するための有意義なメトリクスを提供できる高性能なクラウドネイティブAPIゲートウェイです。これは、アップストリームアプリケーションに送信されるすべてのトラフィックを処理するミドルウェアであり、その過程でトラフィックデータを収集することができます。
弾力的なスケーリングを実行するために、KEDAがコントローラーとして使用され、Prometheus がAPISIXによって提供されるメトリクスを取得するために使用されます。
KEDAでPrometheusスケーラーを使用する方法
KEDA はKubernetesのイベントベースのオートスケーラーで、さまざまなスケーラーを設定できます。この記事では、APISIXによって公開されたメトリクスを取得するためにPrometheusスケーラーを使用します。
KEDAのデプロイ
KEDAのデプロイは比較的簡単で、対応するHelmリポジトリを追加してインストールするだけです。
(MoeLove) ➜ helm repo add kedacore https://kedacore.github.io/charts
"kedacore" がリポジトリに追加されました
(MoeLove) ➜ helm repo update kedacore
最新のチャートを取得するまでお待ちください...
..."kedacore" チャートリポジトリから更新を取得しました
更新が完了しました。⎈Happy Helming!⎈
(MoeLove) ➜ helm install keda kedacore/keda --namespace keda --create-namespace
NAME: keda
LAST DEPLOYED: Thu Jan 19 00:01:00 2023
NAMESPACE: keda
STATUS: deployed
REVISION: 1
TEST SUITE: None
インストール後、Podの ステータス が Running になっていることを確認します。
(MoeLove) ➜ kubectl -n keda get pods
NAME READY STATUS RESTARTS AGE
keda-operator-metrics-apiserver-6d4db7dcff-ck9qg 1/1 Running 0 36s
keda-operator-5dd4748dcd-k8jjz 1/1 Running 0 36s
Prometheusのデプロイ
ここではPrometheus Operatorを使用してPrometheusをデプロイします。Prometheus Operatorは、Kubernetes内でPrometheusインスタンスを迅速にデプロイし、宣言的な設定を通じて監視ルールを追加するのに役立ちます。
以下の手順でPrometheus Operatorのインストールを完了します。
(MoeLove) ➜ https://github.com/prometheus-operator/prometheus-operator/releases/download/v0.62.0/bundle.yaml
(MoeLove) ➜ kubectl apply --server-side -f bundle.yaml
customresourcedefinition.apiextensions.k8s.io/alertmanagerconfigs.monitoring.coreos.com serverside-applied
customresourcedefinition.apiextensions.k8s.io/alertmanagers.monitoring.coreos.com serverside-applied
customresourcedefinition.apiextensions.k8s.io/podmonitors.monitoring.coreos.com serverside-applied
customresourcedefinition.apiextensions.k8s.io/probes.monitoring.coreos.com serverside-applied
customresourcedefinition.apiextensions.k8s.io/prometheuses.monitoring.coreos.com serverside-applied
customresourcedefinition.apiextensions.k8s.io/prometheusrules.monitoring.coreos.com serverside-applied
customresourcedefinition.apiextensions.k8s.io/servicemonitors.monitoring.coreos.com serverside-applied
customresourcedefinition.apiextensions.k8s.io/thanosrulers.monitoring.coreos.com serverside-applied
clusterrolebinding.rbac.authorization.k8s.io/prometheus-operator serverside-applied
clusterrole.rbac.authorization.k8s.io/prometheus-operator serverside-applied
deployment.apps/prometheus-operator serverside-applied
serviceaccount/prometheus-operator serverside-applied
service/prometheus-operator serverside-applied
次に、以下の設定をPrometheusの設定として使用し、Kubernetesクラスターに適用します。
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: prometheus
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: prometheus
rules:
- apiGroups: [""]
resources:
- nodes
- nodes/metrics
- services
- endpoints
- pods
verbs: ["get", "list", "watch"]
- apiGroups: [""]
resources:
- configmaps
verbs: ["get"]
- apiGroups:
- networking.k8s.io
resources:
- ingresses
verbs: ["get", "list", "watch"]
- nonResourceURLs: ["/metrics"]
verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: prometheus
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: prometheus
subjects:
- kind: ServiceAccount
name: prometheus
namespace: default
---
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
name: prometheus
spec:
serviceAccountName: prometheus
serviceMonitorSelector:
matchLabels:
app: apisix
serviceMonitorNamespaceSelector:
matchLabels:
team: apisix
resources:
requests:
memory: 400Mi
enableAdminAPI: false
---
apiVersion: v1
kind: Service
metadata:
name: prometheus
spec:
type: LoadBalancer
ports:
- name: web
port: 9090
protocol: TCP
targetPort: web
selector:
prometheus: prometheus
Kubernetesクラスターに適用した後、default ネームスペースの下にPrometheusインスタンスが作成されていることが確認できます。Prometheusを TYPE LoadBalancer で設定したため、ユーザーはLoadBalancerのパブリックIPを介して直接Prometheusにアクセスできます。
(MoeLove) ➜ kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.43.0.1 <none> 443/TCP 96m
prometheus-operator ClusterIP None <none> 8080/TCP 92m
prometheus-operated ClusterIP None <none> 9090/TCP 41m
prometheus LoadBalancer 10.43.125.194 216.6.66.66 9090:30099/TCP 41m
APIゲートウェイのデプロイと監視の有効化
次に、APISIX Ingressコントローラーをデプロイし、Prometheusを使用してメトリクスを収集します。
APISIX IngressコントローラーではなくAPISIXのみを使用するユーザーも同様の方法で行えます。 ここでは個別に説明しません。
ここでは、Helmを使用してデプロイし、APISIX IngressコントローラーとAPISIXを同時にクラスターにデプロイします。
(MoeLove) ➜ helm repo add apisix https://charts.apiseven.com
"apisix" は既に同じ設定で存在するため、スキップします
(MoeLove) ➜ helm repo update apisix
最新のチャートを取得するまでお待ちください...
..."apisix" チャートリポジトリから更新を取得しました
更新が完了しました。⎈Happy Helming!⎈
(MoeLove) ➜ helm upgrade --install apisix apisix/apisix --create-namespace --namespace apisix --set gateway.type=LoadBalancer --set ingress-controller.enabled=true --set ingress-controller.config.apisix.serviceNamespace=apisix
Release "apisix" がアップグレードされました。Happy Helming!
NAME: apisix
LAST DEPLOYED: Thu Jan 19 02:11:23 2023
NAMESPACE: apisix
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
1. 以下のコマンドを実行してアプリケーションのURLを取得します：
NOTE: LoadBalancer IPが利用可能になるまで数分かかる場合があります。
'kubectl get --namespace apisix svc -w apisix-gateway' を実行してステータスを確認できます。
export SERVICE_IP=$(kubectl get svc --namespace apisix apisix-gateway --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}")
echo http://$SERVICE_IP:80
次に、APISIXのPrometheusプラグインを有効にします。具体的な設定方法と関連パラメータについては、以下の2つのドキュメントを参照してください。
- prometheus plugins | Apache APISIX®
- How to access Apache APISIX Prometheus metrics on Kubernetes | Apache APISIX®
有効にすると、PrometheusはServiceMonitorリソースを作成することでAPISIXによって公開されたメトリクスをキャプチャできます。
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: example-app
labels:
app: apisix
spec:
selector:
matchLabels:
app: apisix
endpoints:
- port: web
アプリケーションの弾力的なスケーリング能力を検証する
まず、アプリケーションを作成します。
(MoeLove) ➜ kubectl create deploy httpbin --image=kennethreitz/httpbin --port=80
deployment.apps/httpbin created
(MoeLove) ➜ kubectl expose deploy httpbin --port 80
以下のルーティングルールを作成し、Kubernetesクラスターに適用して、APISIXを介してリクエストをプロキシします。
apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
name: httpserver-route
spec:
http:
- name: rule1
match:
hosts:
- local.httpbin.org
paths:
- /*
backends:
- serviceName: httpbin
servicePort: 80
次に、KEDA ScaledObjectを作成し、Prometheus関連の設定を構成します。
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: prometheus-scaledobject
namespace: default
spec:
scaleTargetRef:
name: httpbin
triggers:
- type: prometheus
metadata:
serverAddress: http://prometheus.default.svc:9090
metricName: apisix_http_status
threshold: '10'
query: sum(rate(apisix_http_status{route="httpserver-route"}[1m]))
上記の設定は、sum(rate(apisix_http_status{route="httpserver-route"}[1m])) をクエリ式として使用し、結果が10に達した場合に拡張を開始することを意味します（ここでの設定はデモンストレーション用ですので、実際の状況に応じて変更してください）。その後、curlを使用してhttpbinサービスに継続的にリクエストを送信します。
その後、アプリケーションのPodを確認すると、KEDAによって2つに自動拡張されていることがわかります。
(MoeLove) ➜ kubectl get pods
NAME READY STATUS RESTARTS AGE
httpbin-d46d778d7-chtdw 1/1 Running 0 12m
httpbin-d46d778d7-xanbj 1/1 Running 0 10s
しばらくしてアプリケーションがアイドル状態になると、Podの数が自動的に1インスタンスに縮小されていることがわかります。
(MoeLove) ➜ kubectl get pods
NAME READY STATUS RESTARTS AGE
httpbin-d46d778d7-chtdw 1/1 Running 0 32m
まとめ
KEDAはPrometheusをスケーラーとして使用し、APISIX によって公開されたメトリクスを収集します。すべてのトラフィックが最初にAPISIXを通過するため、APISIX側で統計を取得する方がはるかに簡単で便利です。
ビジネスリクエストの量が増加すると、アプリケーションは自動的に拡張され、ビジネスリクエストの量が減少すると、アプリケーションは自動的に縮小されます。
この方法により、多くの本番環境での手動の拡張/縮小操作を軽減し、最高のユーザー体験を確保できます。