こんばんは、ACS 事業部の埜下です。
KubeCon + CloudNativeCon Europe 2023 の 3 日目、「Autoscaling Elastic Kubernetes Infrastructure for Stateful Applications Using Proxyless gRPC and Istio」というセッションを聞き、ステートフルなアプリケーションのスケールダウンに対して Istio がどう対処しようとしているのかまとめました。
背景
Kubernetes では Horizontal Pod Autoscaler (HPA ) や Cluster Autoscaler (CA) という機能を使うことで、インフラをオートスケーリングしてキャパシティやコストを最適化することができます。
Kubernetes 上で動くアプリケーションがステートレスな場合は特に問題ないのですが、ステートフルアプリケーションの場合は、クライアントからのセッションは「状態」を維持するために同一の Pod でやりとりするが必要です。
ロードバランサ経由でサービスに接続する場合は Cookie セッションアフィニティを、Istio などのサービスメッシュでの接続の場合は gRPC のセッションアフィニティを使用することで、同一 Pod での通信を維持します。
ステートフルな Pod が HPA などのオートスケーリングの機能で停止された場合、その Pod に対して接続していたクライアントは別の Pod に繋がるようになりますが、その Pod は同じ「状態」を持っていません。
HPA などで Pod の停止処理が動いても、リクエストを捌くまでは Pod を維持する必要があります。
対処
そこで、Pod に特別な DRAINING という状態を作って対処するようです。
ロードバランサは DRAINING 状態の Pod に新しいセッションを割り当てませんが、既存のセッションは引き続き DRAINING 状態の Pod が受け持ちます。
Istio は、この DRAINING 状態を実装するそうです。
Istio は EndpointSlice API を使用してサービスのエンドポイントを取得し、サービスでステートフル セッション アフィニティが有効になっている場合にエンドポイントを healthStatus=DRAINING とマークします。
プロキシレス gRPC クライアントは、新しいセッションこのエンドポイントにリクエストを送信しますが、既存のセッションは接続済みの Pod に対してリクエストを送ります。 これにより「状態」を維持することが可能になるそうです。
現在、この機能は以下のステータスのようです。
- gRPC の設計および実装は gRFC の A55 で進行中
- Envoy の Stateful Session 機能は実装済み
Istio では以下のようなラベルのサポートを追加
labels: istio.io/persistent-session: my-cookie-name
おわりに
今回はセッション周りのステートフルなワークロードについてどのような考慮が必要か、そして Istio がどのような機能で対処するのか知ることができました。
AKS でも Istio Addon の Public Preview が公開されましたので、改めて Istio について理解を深める必要がありますね。
