研究開発部 Architectグループ ML Platformチームのジャン(a.k.a jc)です。 前回弊チームのKAZYがKubernetesクラスタ更新時のマニフェスト差分をGitのブランチで吸収する方法を紹介しました。 buildersbox.corp-sansan.com 今回は解像度をあげてKubernetesクラスタ更新時のIstioの対応方法について紹介します。
背景
Circuitについて
Circuitとは、2022年に研究開発部で導入したアプリケーション基盤です。AWS EKSを用いたKubernetesで動いています。
blue/green戦略について
Circuitにおいて、クラスタ更新はblue/green戦略を採用しています。クラスタ更新時には、新しいクラスタを立ち上げて、新しいクラスタにトラフィックを移行させることで、サービスの停止を最小限に抑えられます。
Istioについて
昨年末にアクセス頻度の低いアプリケーション・APIのサーバーレス化を行うため、CircuitにKnative Servingを導入することになりました。 その際、Knativeのnetwork componentとしてIstioを使うことに決めました。 本記事はIstioの導入によるblue/green戦略の対応方法に着目するものなので、Istioの詳細は割愛します。Knativeに関してもまた別の機会に紹介する予定です。
Istioのメリット
Istioは、トラフィックを制御するための機能を提供しています。 Istio用のRoute53とIngressさえ用意しておけば、アプリケーション向きのトラフィックをIstio ingress gatewayに経由させることで、各アプリケーションのためにいちいちRoute53, Load Balancer, Target Groupなどを作成する必要がなくなります。 アーキテクチャがシンプルになるため、運用コスト削減につながります。
また、Gateway、VirtualServiceなどのIsitoのリソースを使って、トラフィックの振り分けやトラフィックの細かい制御を行えます。
Gateway、VirtualService設定例を一つ紹介します。
事前にIstioのために*.example.com
のDNSレコードを作成して、トラフィックをIstioのALBに流すように設定しておく必要があります。
ALBは自ら設定しても良いですが、Ingressによって自動作成されたものを使うのが便利なので、EKSの場合はALB Ingress Controllerを使います。
実際にレコードyour-app.example.com
を作成する必要がなく、以下のようにGateway、VirtualServiceを設定することで、アプリケーションyour-app
向きのトラフィックをk8sのservice your-svc
に流せます。アプリケーション数が少ない場合は、このメリットはあまり感じられないかもしれませんが、アプリケーションの数が増えるほど、このメリットは大きくなります。
apiVersion: networking.istio.io/v1beta1 kind: Gateway metadata: name: your-gateway spec: selector: istio: ingressgateway servers: - hosts: - your-app.example.com port: name: http number: 80 protocol: HTTP
apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: your-virtual-service spec: hosts: - your-app.example.com gateways: - your-gateway http: - route: - destination: host: your-svc
apiVersion: v1 kind: Service metadata: name: "your-service" spec: selector: app: "your-app" ports: - name: http port: 80 targetPort: 8000
blue/green戦略のための追加対応
Circuitではblue/green戦略を採用しており、Route53の向き先を変えるだけでクラスタ間のトラフィック移行ができるようにしています。
blue/green戦略でもIstioのメリットを享受するために、少し工夫が必要です。
まず、Istioのgreen/blueのDNSレコード*.blue.example.com
と*.green.example.com
を用意しておきます。
その後、各アプリケーションのGateway, VirtualServiceにblue/greeeのレコードを追加することで、blue/greenのトラフィックをそれぞれのクラスタに振り分けられます。
your-app.blue.example.com
your-app.green.example.com
マニフェストの例は以下の通りです。
apiVersion: networking.istio.io/v1beta1 kind: Gateway metadata: name: your-gateway spec: selector: istio: ingressgateway servers: - hosts: - your-app.example.com - your-app.blue.example.com - your-app.green.example.com port: name: http number: 80 protocol: HTTP
apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: your-virtual-service spec: hosts: - your-app.example.com - your-app.blue.example.com - your-app.green.example.com gateways: - your-gateway http: - route: - destination: host: your-svc
トラフィックの向き先を変更する際は、Istioの設定だけを変更すれば良いので、運用がだいぶ楽になりました。
まとめ
Kubernetesクラスタ更新時にIstioの対応方法について紹介しました。 istioのGateway、VirtualServiceを利用することで、アプリケーションのトラフィックを簡単に制御できるだけでなく、クラスタ更新時にもその恩恵を受けられます。 ご参考になれば幸いです。
研究開発部ではMLOps/DevOpsエンジニア・プラットフォームエンジニアを募集しています。