概念 - アプリケーションをデプロイする
Kubernetes にアプリケーションをデプロイする前に、Kubernetes のデプロイについて確認し、このシナリオでの制限事項をお話ししましょう。
Kubernetes のデプロイとは
Kubernetes Deployment はポッドが進化したものです。 デプロイにより、ポッドをインテリジェントなオブジェクト内にラップして、"スケールアウト" できるようにします。アプリケーションを簡単に複製したり、スケーリングしたりして、より多くの負荷をサポートすることができます。複雑なネットワーク ルールを構成する必要はありません。
デプロイを行うと、イメージ タグを変更するだけで、ダウンタイムを発生させずにアプリケーションを更新できます。 デプロイの更新では、すべてのアプリが削除されて新しいアプリが作成されるのではなく、オンライン アプリが 1 つずつオフにされて、最新バージョンに置き換えられます。つまり、デプロイでは、可用性に目に見える影響を与えずに、その中のポッドを更新できます。
ポッドに対してデプロイを使うと多くのベネフィットがありますが、ここでのシナリオを適切に処理することはできません。
このシナリオに含まれるイベントドリブン アプリケーションは、さまざまな時間に多数のイベントを受信します。 KEDA スケーラー オブジェクトまたは HPA がない場合は、そのイベント数を処理できるようにレプリカの数を手動で調整し、負荷が正常に戻ったらデプロイを "スケールダウン" する必要があります。
配置マニフェストのサンプル
配置マニフェストのサンプル スニペットを次に示します。
apiVersion: apps/v1
kind: Deployment
metadata:
name: contoso-microservice
spec:
replicas: 10 # Tells K8S the number of pods needed to process the Redis list items
selector: # Define the wrapping strategy
matchLabels: # Match all pods with the defined labels
app: contoso-microservice # Labels follow the `name: value` template
template: # Template of the pod inside the deployment
metadata:
labels:
app: contoso-microservice
spec:
containers:
- image: mcr.microsoft.com/mslearn/samples/redis-client:latest
name: contoso-microservice
このサンプル マニフェストでは、replicas が 10 に設定されています。これは、ピーク イベント数の処理に必要なレプリカ数に設定できる最大値です。 ただし、このようにすると、ピーク時以外にはアプリケーションが消費するリソースが多くなりすぎて、クラスター内の他のデプロイで不足する場合があります。
1 つの解決策は、スタンドアロン HPA を使ってポッドの CPU 使用量を監視することです。これは、両方向に手動でスケーリングするより優れたオプションです。 ただし、HPA では Redis リストへの受信イベント数は注視されません。
最もよい解決策は、KEDA と Redis スケーラーを使ってリストのクエリを実行し、イベントの処理に必要なポッドの数がさらに多いか少ないかを判断することです。