web-dev-qa-db-ja.com

ソース管理にkubernetes構成を保存するためのベストプラクティス

Kubernetesドキュメントサイトのいくつかの場所では、バージョン管理、ロールバック、展開を簡単にするために、構成YAMLファイルをソース管理内に保存することをお勧めしています。

同僚と私は現在、gitリポジトリの構造を決定しようとしています。

  • アプリのコードを変更せずに構成を変更できるため、構成を別の共有リポジトリに保存することを決定しました。
  • 特定の環境（クラスター）内で並行して実行される一部のコンポーネントの複数のバージョンが必要になる場合があります。これらのバージョンには異なる構成があります。

多くの潜在的なバリエーションがあるように思われ、それらのすべてに欠点があります。そのようなリポジトリを構造化するために受け入れられている方法は何ですか？

gitconfigurationkubernetes
23
Kir

helm は、kubernetesクラスター用のアプリケーションインストーラーを作成する標準的な方法になると思います。アプリの展開をパラメーター化するために、独自の chart を作成しようとします。

3
Gabriel Miretti aka gmiretti

確立された標準はまだありません、私は信じています。ヘルムのチャートは最初から複雑すぎて、特にk8sクラスター上で別のアンマネージドコンポーネントが実行されていることがわかりました。これは、15のマイクロサービスと5つの異なる環境（devx2、ステージング、qa、prod）のセットアップで非常にうまく機能するワークフローです。

2つの重要なアイデア：

  1. Kubernetes構成は、他のビルドツールがある同じソースリポジトリに保存します。例：特定のマイクロサービスを構築/リリースするためのツールを備えたマイクロサービスのソースコードと一緒に。
  2. Jinjaのようなものでkubernetes構成をテンプレート化し、ターゲットとする環境に従ってテンプレートをレンダリングします。

このツールは、いくつかのbashスクリプトをまとめたり、Makefileなどと統合したりすることで、簡単に把握できます。

編集：コメント内のいくつかの質問に答える

アプリケーションのソースコードリポジトリは、単一の真実のソースとして使用されます。つまり、すべてが正常に機能する場合、変更をkubernetesクラスターからリポジトリに移動しないでください。

サーバーでの直接の変更は、ワークフローで禁止されています。発生した場合は、手動でアプリケーションリポジトリに再度入力する必要があります。

繰り返しますが、ソースコードに格納されている構成は実際にはテンプレートであり、 secretKeyRef を非常に自由に使用していることに注意してください。つまり、一部の構成はレンダリング時にCIツールから取得され、一部はクラスター上にのみ存在する秘密（データベースパスワード、APIトークンなど）から取得されます。

10
iamnat

私の意見では、Helmはkukernetesに、Docker-composeはdockerに

ヘルムを恐れる理由はありません。最も基本的な機能であり、kubectl apply -f templates。

ヘルムに慣れたら、values.yamlおよび最大の柔軟性を得るためにkubernetesテンプレートに値を追加します。

values.yaml

name: my-name

templates/deployment.yaml内

name: {{ .Values.name }}

https://helm.sh/

私のアプローチは、各プロジェクトにhelmサブディレクトリを作成することです。これは、docker-compose.ymlファイルを含めるのと同じ方法です。

これに加えて、ビルド済みのイメージを参照するすべてのプロジェクトのヘルムリポジトリを維持することもできます

2
yosefrow