🦄

Kubernetesによるマルチリージョンデプロイ - Pythonアプリの実装とコンテナ化 -

2025/06/02に公開

1. はじめに

アプリケーションの開発において、効率的なデプロイと運用は重要な課題です。
本記事では、AWS Network Firewallのルール作成を自動化するPython(Streamlit)アプリケーションを、Kubernetesを使ってマルチリージョンにデプロイした事例を紹介します。

2. Kubernetesとは

Kubernetesは、コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化するオープンソースのコンテナオーケストレーションプラットフォームです。

2-1. 主な特徴

3. 技術スタック

3-1. Streamlit

Streamlitは、Pythonでデータアプリケーションを簡単に作成できるフレームワークです。

3-2. Kubernetes（minikube）

minikubeは、ローカル環境でKubernetesを簡単に試せるツールです。

4. ソース

こちらのGitHubリポジトリを参照してください。

5. 準備

5-1. ヒアリングシート

AWS Network Firewallで制限したい、IPなどの要件をまとめたもの。

5-2. AWS Network Firewallのルールリスト

ルール作成の元となるパラメータをまとめたもの。
東京、シンガポール、バージニアの非本番/本番環境にわけている。

Action: alert(アラート)、pass(許可)は1セット。　

・シート名: IP set variables NonProd

ヒアリングシートに記載のIPが複数存在する時、そのままルールに書くと長くなる。
なので、IP sett variablesに予め変数を定義しておき、簡略化している。

6. Kubernetesでのデプロイ手順

6-1. 環境構築

# Minikubeの起動
minikube start --driver=docker --memory=2048 --cpus=2 --kubernetes-version=v1.25.0

# 名前空間の作成
kubectl create ns tokyo-prod
kubectl create ns tokyo-nonprod
kubectl create ns singapore-prod
kubectl create ns singapore-nonprod
kubectl create ns virginia-prod
kubectl create ns virginia-nonprod

6-2. Minikubeトンネルの開始（別ターミナルで実行）

# 別のターミナルウィンドウで実行
minikube tunnel

6-3. Dockerイメージのビルド

# Minikubeのdocker環境を使用
eval $(minikube docker-env)

# イメージのビルド
docker build -t fw-transfer:v3 .

6-4. 各環境へのデプロイ

# 東京の環境
kubectl apply -k kubernetes/overlays/tokyo/prod
kubectl apply -k kubernetes/overlays/tokyo/nonprod

# シンガポールの環境
kubectl apply -k kubernetes/overlays/singapore/prod
kubectl apply -k kubernetes/overlays/singapore/nonprod

# バージニアの環境
kubectl apply -k kubernetes/overlays/virginia/prod
kubectl apply -k kubernetes/overlays/virginia/nonprod

6-5. デプロイの確認

# 各名前空間のPodを確認
kubectl get pods -n tokyo-prod
kubectl get pods -n tokyo-nonprod
kubectl get pods -n singapore-prod
kubectl get pods -n singapore-nonprod
kubectl get pods -n virginia-prod
kubectl get pods -n virginia-nonprod

# サービスの確認
kubectl get svc -A

6-6. アプリケーションへのアクセス

# 東京のnonprod環境
kubectl port-forward -n tokyo-prod svc/fw-transfer-service 8501:80

# 東京のprod環境
kubectl port-forward -n tokyo-nonprod svc/fw-transfer-service 8502:80

# シンガポールのnonprod環境
kubectl port-forward -n singapore-prod svc/fw-transfer-service 8503:80

# シンガポールのprod環境
kubectl port-forward -n singapore-nonprod svc/fw-transfer-service 8504:80

# バージニアのnonprod環境
kubectl port-forward -n virginia-prod svc/fw-transfer-service 8505:80

# バージニアのprod環境
kubectl port-forward -n virginia-nonprod svc/fw-transfer-service 8506:80

ブラウザで対応するURLにアクセス：

東京nonprod: http://localhost:8501
東京prod: http://localhost:8502
シンガポールnonprod: http://localhost:8503
シンガポールprod: http://localhost:8504
バージニアnonprod: http://localhost:8505
バージニアprod: http://localhost:8506

7. Network FIrewallの転記自動化アプリの動作確認

7-1. 操作方法

Tokyo-NonProdの環境を例にします。
使用方法は、アプリの下記で載せています。

7-2. アップロード

ファイルをアップロードし、処理開始ボタンを押す。処理中として、バーが表示される。

7-3. 処理完了

結果をダウンロードをクリック。

7-4. 結果確認

ヒアリングシートの内容が、”Rules NonProd New”というシートに、ルールの設定値として転記できています。
Source IP、Destination IPで、IPアドレスがIP set variablesで定義した変数に変換されています。

8. エラー対応とポイント

8-1. Dockerfileの最適化

8-2. Kubernetesリソースの修正

8-3. Kustomizeの設定修正

8-4. ポートフォワーディングの問題解決

8-5. 環境変数の設定

8-6. Minikubeトンネルの設定

9. まとめ

マルチリージョンの環境でアプリケーションを、マルチテナント構成で実現できました。
無事、Kubernetesでデプロイができました。