Sansan Tech Blog

Sansanのものづくりを支えるメンバーの技術やデザイン、プロダクトマネジメントの情報を発信

blue/green戦略によるKubernetesクラスタ更新時にIstioの対応方法

研究開発部 Architectグループ ML Platformチームのジャン(a.k.a jc)です。 前回弊チームのKAZYがKubernetesクラスタ更新時のマニフェスト差分をGitのブランチで吸収する方法を紹介しました。 buildersbox.corp-sansan.com 今回は解像度をあげてKubernetesクラスタ更新時のIstioの対応方法について紹介します。

背景

Circuitについて

Circuitとは、2022年に研究開発部で導入したアプリケーション基盤です。AWS EKSを用いたKubernetesで動いています。

speakerdeck.com

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などを作成する必要がなくなります。 アーキテクチャがシンプルになるため、運用コスト削減につながります。

Istio利用前

Istio利用後

また、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戦略

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の設定だけを変更すれば良いので、運用がだいぶ楽になりました。

Istio導入後のblue/green戦略

まとめ

Kubernetesクラスタ更新時にIstioの対応方法について紹介しました。 istioのGateway、VirtualServiceを利用することで、アプリケーションのトラフィックを簡単に制御できるだけでなく、クラスタ更新時にもその恩恵を受けられます。 ご参考になれば幸いです。

研究開発部ではMLOps/DevOpsエンジニア・プラットフォームエンジニアを募集しています。

open.talentio.com

open.talentio.com

© Sansan, Inc.