質問: 閲覧ありがとうございます。 Kubernetes初心者です。 これまで、コンテナ技術に関しては VPSにてdocker-composeでサービスを公開、運用するという方法は経験しているのですが docker-composeの場合の `コンテナ : Githubリポジトリ : dockerレジストリ`の関係は `n : 1 : 0`でした。 (docker-composeではdockerレジストリを必須とする理由が特になかったので使っていませんでした) しかし、Kubernetesの場合は まだ、Kubernetesのkの字も分からない程度の段階ですが 少し触ってみて体験した感じ `コンテナ : Githubリポジトリ : dockerレジストリ`の関係は `1 : 1 : 1`ではないか?と思っているのですが この認識であっていますでしょうか? その他も、現場ではどのように使われているのか教えていただけると有り難いです! 現在、Kubernetesではどのようなプロジェクト管理を行うのか分からなくて悩んでいます。
回答: DockerレジストリはDocker/Docker Composeでも使っていますし、少なくとも本番でコンテナアプリケーションを動かす上では必須のものであるという認識です。 Composeを使った場合、compose up時にビルドをすることができるためにこのような状況が実現できてしまうのですが、毎回ビルドをすると、「動いたものをそのまま他の環境に渡して使う」という、Dockerコンテナのポータビリティが活かせないため、レジストリが必要になる、というのが私の理解です。 > > コンテナ : Githubリポジトリ : dockerレジストリの関係はn : 1 : 0でした。 > > > ComposeでBuild区を利用されている場合、たしかにこれは間違ってはいないかもしれませんが、厳密にはレジストリは0ではないと思います(Dockerfileに書かれているベースイメージはもともとレジストリから引っ張ってきているからです)。 > > コンテナ : Githubリポジトリ : dockerレジストリの関係は1 : 1 : 1ではないか?と思っているのですがこの認識であっていますでしょうか? > > > コンテナとイメージを管理するレジストリの対応関係はn:nになりますが、Gitのリポジトリは必ずしもそうなるとは限らないと思います。 例えば、あるアプリケーションがあって、それが フロントエンド - [バックエンドA - バックエンドB] - [データベースA - データベースB] のようなサービスで構成されていると仮定します。このとき、DBはマネージドサービスや自前のホスト上にMySQLなどを用意して使うとしても、フロントエンド用のアプリケーションとバックエンドの2つはそれぞれ用意する必要があります。 コンテナを使う場合、それぞれが独立したコンテナとして動くのが一般的ですが、規模が大きいとそれぞれのアプリケーションごとにリポジトリを分けたほうが良いこともあります。 そんなわけで、Gitのリポジトリとコンテナの数の関係は一般化が難しいと思います。 また、Kubernetesの場合、Composeとは違ってスケーリングの概念があります。 つまり、バックエンドAの負荷が高い状態のときに条件に応じて水平にスケールアウトしてくれるような機能のことです。コンテナ(KubernetesではPodと呼びますが)の数がスケールアウトによって増えている場合、この数は一定ではないので、これもまたいつも同じとは限りません。