設計上の判断

このドキュメントでは、このリポジトリ内のHelm Chartのデザインに関して行われた理由と決定事項を収集します。提案をお待ちしております。決定の適用方法については、意思決定を参照してください。

問題のある設定の捕捉を試みる

これらのチャートの複雑さとその柔軟性のレベルにより、予測不可能または完全に機能しないデプロイにつながる設定を生成できるオーバーラップがいくつかあります。既知の問題のある設定の組み合わせを回避するために、設定が機能しないことを検出し、ユーザーに警告するように設計されたテンプレートロジックを実装しました。

これは非推奨の動作をレプリケートしますが、機能的な設定を保証することに特化しています。

!757 checkConfig: 既知のエラーをテストする方法を追加で導入

非推奨による破壊的な変更

これらのチャートの開発中に、既存のデプロイのプロパティに改変を必要とする改善を行うことがあります。2つの例は、MinIOの使用を設定するための一元化と、（当社の好みに従って）外部オブジェクトストレージの設定をプロパティからシークレットへの移行でした。

機能しなくなる設定に対して破壊的な変更を含むこれらのチャートの更新バージョンをユーザーが誤ってデプロイすることを防ぐ手段として、非推奨通知を実装することにしました。これらは、プロパティの場所が変更、改変、置換、または完全に削除されたことを検出し、設定に必要な変更についてユーザーに通知するように設計されています。これには、プロパティをシークレットに置き換える方法に関するドキュメントを見るようにユーザーに通知することが含まれる場合があります。これらの通知により、Helmのinstallまたはupgradeコマンドが解析エラーで停止し、対処が必要な項目の完全なリストを出力します。ユーザーがエラー、修正、繰り返しのループに陥らないように注意を払っています。

デプロイを成功させるには、すべての非推奨に対処する必要があります。ユーザーは、デバッグが必要な予期しない動作や完全な失敗を経験するよりも、破壊的な変更について知らされることを好むと考えています。

!396 Deprecations: バッファリングされた非推奨のリストを実装で導入

環境変数よりもinitコンテナ内のシークレットを優先する

多くのコンテナエコシステムは、環境変数を介して設定される機能を備えているか、または期待しています。この構成プラクティスは、The Twelve-Factor Appの概念に由来します。これにより、複数のデプロイ環境全体での設定が大幅に簡素化されますが、コンテナの環境を介してパスワードやキーなどの接続シークレットを渡すことには、セキュリティ上の懸念が残ります。

ほとんどのコンテナエコシステムは、実行中のコンテナの状態を検査する簡単な方法を提供しており、通常は環境が含まれます。Dockerを例として使用すると、デーモンと通信できるすべてのプロセスは、実行中のすべてのコンテナの状態をクエリできます。つまり、dindのような特権コンテナがある場合、そのコンテナは、特定のノード上の_すべて_のコンテナの環境を検査し、内部に含まれる_すべて_のシークレットを公開できます。完全なDevOpsライフサイクルの一部として、dindは、レジストリにプッシュされ、その後デプロイされるコンテナの構築に定期的に使用されます。

この懸念が、initContainersを介して機密情報を投入することを優先することにした理由です。

サブチャートはグローバルチャートからデプロイされます

このリポジトリのすべてのサブチャートは、グローバルチャートを介してデプロイされるように設計されています。各コンポーネントは個別にデプロイできますが、グローバルチャートによって容易になる共通のプロパティセットを利用します。

この決定により、リポジトリ全体の利用とメンテナンスの両方が簡素化されます。

関連イシューを参照してください:

#352

`gitlab/*`のテンプレートパーシャルは、可能な限りグローバルにする必要があります

gitlab/*サブチャートのすべてのテンプレートパーシャルは、可能な限りグローバルまたはGitLabサブチャートtemplates/_helpers.tplの一部である必要があります。フォークしたチャートからのテンプレートは、それらのチャートの一部になります。これにより、これらのフォークのメンテナンスへの影響が軽減されます。

これによる利点は、非常に簡単です:

DRYの動作が向上し、メンテナンスが容易になります。単一のエントリで十分な場合、複数のサブチャートにわたって同じ関数の複製を作成する理由はありません。
テンプレートの名前の競合が軽減されます。チャート全体のすべてのパーシャルがまとめてコンパイルされるため、グローバルな動作と同様に扱うことができます。

関連イシューを参照してください:

#352

フォークしたチャート

次のチャートは、フォークおよび新しいチャートのガイドラインに従って、このリポジトリでフォークまたは再作成されています

Redis

3.0リリースのGitLab Helmチャートでは、アップストリームRedisチャートをフォークしなくなり、依存関係として含めるようになりました。

Redis HA

Redis-HAは、3.0より前のリリースに含まれていたチャートでした。削除され、オプションのHAサポートが追加されたアップストリームRedisチャートに置き換えられました。

MinIO

当社のMinIOチャートは、アップストリームMinIOから変更されました。

プロパティから新しいKubernetes Secretsを作成する代わりに、既存のKubernetes Secretsを使用します。
環境を介した機密情報の提供を削除します。
defaultBucket.*プロパティの代わりにdefaultBucketsを介して複数のバケットの作成を自動化します。

レジストリ

当社のレジストリチャートは、アップストリームdocker-registryから変更されました。

チャート内のMinIOサービスの使用を自動的に有効にします。
GitLabサービスへの認証を自動的にフックします。

NGINX Ingress

当社のNGINX Ingressチャートは、アップストリームNGINX Ingressから変更されました。

TCP ConfigMapをチャートの外部に配置できるようにする機能を追加
リリース名に基づいてIngressクラスをテンプレート化できるようにする機能を追加

チャート全体で使用されるKubernetesバージョン

さまざまなKubernetesバージョンのサポートを最大化するには、現在の安定リリースのKubernetesよりも1つ小さいマイナーバージョンのkubectlを使用します。これにより、少なくとも3つ、場合によってはさらに多くのKubernetesマイナーバージョンがサポートされるはずです。kubectlバージョンの詳細については、イシュー1509を参照してください。

CNGとともに出荷されるイメージバリアント

日付: 2022-02-10

CNGプロジェクトは、DebianとUBIの両方に基づいてイメージを出荷します。両方のディストリビューションの設定を維持するという決定は、以下に基づいています:

Debianベースのイメージを出荷する理由:
- 実績、先例
- ディストリビューションの知識
- コミュニティ対「エンタープライズ」
- 認識されたベンダーロックインの欠如
UBIベースのイメージを出荷する理由:
- 一部の顧客環境で必須
- RHEL認定およびOpenShift Marketplace / RedHatカタログへの包含に必要

このトピックに関する詳細なディスカッションについては、イシュー#3095を参照してください。

Kubernetesリリースサポートポリシー

日付: 2024-03-26

GitLabは、Kubernetesの3つのマイナーリリース（N、N-1、およびN-2）を正式にサポートします。Nは次のいずれかです:

認定が完了している場合は、Kubernetesの最新リリースされたマイナーバージョン。
最新のマイナーバージョンの認定を完了していないか、開始していない場合は、次に最新のマイナーバージョン。

たとえば、現在利用可能なリリースが1.28、1.27、1.26、1.25であり、リリース1.28を認定していない場合、Nは1.27になり、この表に示すように、リリース1.25、1.26、および1.27を正式にサポートします。

リリース	参照
`1.27`	`N`
`1.26`	`N-1`
`1.25`	`N-2`

詳細については、Distribution Team Kubernetes and OpenShift release support policyをご覧ください

OpenShiftリリースサポートポリシー