既存のアーキテクチャ

このセクションでは、シンプルな画像ホスティング例を使用して、Kubernetesデプロイメントでのストレージの取り扱い方法を探ります。サンプルストアアプリケーションの既存のデプロイメントから始め、それを画像ホストとして機能するように変更します。UIコンポーネントはステートレスなマイクロサービスであり、水平スケーリングとPodの宣言的な状態管理を可能にするため、デプロイメントのデモンストレーションに最適な例です。

UIコンポーネントの役割の1つは、静的な製品画像を提供することです。現在、これらの画像はビルドプロセス中にコンテナにバンドルされています。しかし、このアプローチには重大な制限があります - コンテナがデプロイされた後に新しい画像を追加することができません。この制限に対処するために、Amazon Elastic File SystemとKubernetesのPersistent Volumeを使用して、共有ストレージ環境を作成するソリューションを実装します。これにより、複数のWebサーバーコンテナが資産を提供しながら、需要に応じて動的にスケールすることが可能になります。

現在のDeploymentのボリューム構成を調べてみましょう：

~$kubectl describe deployment -n ui

Name:                   ui

Namespace:              ui

[...]

  Containers:

   ui:

    Image:      public.ecr.aws/aws-containers/retail-store-sample-ui:1.2.1

    Port:       8080/TCP

    Host Port:  0/TCP

    Limits:

      memory:  1536Mi

    Requests:

      cpu:     250

      memory:  1536Mi

    [...]

    Mounts:

      /tmp from tmp-volume (rw)

  Volumes:

   tmp-volume:

    Type:          EmptyDir (a temporary directory that shares a pod's lifetime)

    Medium:        Memory

    SizeLimit:     <unset>

[...]

Volumesセクションを見ると、現在のDeploymentがPodの存続期間中のみ存在するEmptyDirボリュームタイプを使用していることがわかります。これは、Podが終了すると、このボリュームに保存されたデータが永久に失われることを意味します。

ただし、UIコンポーネントの場合、製品画像は現在Spring Bootによる静的Webコンテンツとして提供されているため、画像はファイルシステム上に存在していません。