cert-manager 機能ゲート
v1 リリース以降、cert-manager は安定版と見なされています。API の変更を行う際には、Kubernetes API 互換性ポリシーに従うことを目指しており、ユーザーの既存の cert-manager インストールを破壊しないように API 互換性 を参照してください。これは、開発者として、既存の動作を変更することに、つまり、API 要素の名前変更や削除、または動作の変更に、ある程度の制限があることを意味します。
まだ安定していない新機能1を追加することはできますが、フィーチャゲートの背後に配置する必要があります。
フィーチャゲートの有効化/無効化
フィーチャゲートは、CLIフラグまたは設定ファイルを使用して有効化または無効化できます。詳細については、コンポーネントの設定を参照してください。
フィーチャゲート付きAPIフィールド
フィーチャゲート付きAPIフィールドは、cert-managerの--feature-gates
フラグを使用して実装されています。webhook、cainjector、およびcontroller。
フィーチャゲート付きAPIフィールドは、ユーザーには常に表示されます(つまり、kubectl explain <some-resource>
を実行した場合)。ただし、webhookとコントローラーの両方でフィーチャフラグを明示的に有効にした場合にのみ機能します。
ユーザーがフィーチャゲート付きフィールドを非nil値に設定したリソースを適用しようとしますが、フィーチャゲートが有効になっていない場合、リソースはwebhook検証によって拒否されます。このメカニズムは、Kubernetesがフィーチャゲート付きAPIフィールドの実装に使用する方法とは異なり、フィーチャゲートが無効になっている場合、フィールドは単純にnilに設定されます。フィーチャゲート付きフィールドを使用しようとしているが、フィーチャゲートの有効化を忘れてしまったユーザーのデバッグを容易にするために、webhook検証を使用することを選択しました。
実装
- 新しいフィールドを実装し、それがフィーチャゲート付きであり、使用する際にはコントローラーとwebhookのフィーチャゲートを有効にする必要があることを文書化します。
- フィールドの新しいwebhookフィーチャゲートを追加します。
- 関連するリソースの種類について、webhook検証チェックを更新して、フィーチャゲート付きフィールドが設定されているが、webhookフィーチャゲートが有効になっていない場合、リソースが拒否されるようにします。
- フィールドの新しいコントローラーフィーチャゲートを追加します。
- フィーチャを使用するすべての制御ループで、フィーチャゲートが実際に有効になっていることを確認します。(これは、webhookがフィーチャがGAであるcert-managerのバージョンを実行しているのに対し、コントローラーがフィーチャがまだ実験段階にある古いバージョンを実行している場合などのエッジケースをカバーするために必要です。)
- makeおよびbashスクリプトで、フィーチャゲートがCIとローカルテストのcert-managerインストールスクリプトに追加されていることを確認します。
- デフォルトのcert-manager e2e CIテストは、すべてのコンポーネントのすべてのフィーチャゲートが有効になっている状態で実行されます。すべてのフィーチャゲートが無効になっている状態で実行される追加のオプションのe2eテストがあります。PRに対して
/test pull-cert-manager-e2e-feature-gates-disabled
を使用してトリガーして、新しいフィーチャゲートの有無にかかわらずすべてが期待通りに動作することを確認できます。
潜在的な問題
-
cert-managerをデプロイする人は、機能させるために、webhookとコントローラーの2つのcert-managerフィーチャゲートを設定する必要があることを覚えておく必要があります。一方を設定し忘れると、予期しない動作が発生する可能性があります。
-
ユーザーは、以前に有効にしたAPI機能を無効にする際に、アルファフィールドをマニフェストから削除することを覚えておく必要があります。そうしないと、予期しない動作が発生する可能性があります。たとえば、
Certificate
リソースからフィーチャゲート付きフィールドを削除することを忘れると、cert-managerのコントローラーがCertificate
のspecを更新しようとする際に、webhookがフィーチャゲート付きフィールドが設定されているために更新を拒否するため、後で更新に失敗する可能性があります。
参考文献
-
cert-managerのAPI互換性に関する約束
-
Kubernetes API変更設計
脚注
-
たとえば、ユーザーからのフィードバックに応じて将来変更される可能性のある機能↩