問題タブ [kubernetes-operator]

Kubernetes golang オペレーター SDK を使用して、RabbitMQ キューを管理するオペレーターを実装しています。k8s がカスタム リソースの特定の仕様フィールドの不変性を強制する方法があるかどうか疑問に思っています。私は、rabbitMQ キューを表す次の golang 構造体と、rabbitMQ 交換にバインドするためのいくつかのパラメーターを持っています。

特にフィールドに対して不変性が必要な理由VHostは、それが rabbitMQ でキューの名前空間を指定するために使用されるパラメーターだからです。既存の展開されたキューに対して変更された場合、k8s リコンサイラーは目的のキューに対して rabbitMQ のクエリに失敗します。これは、別の vhost (事実上別の名前空間) でクエリを実行するためです。これにより、新しいキューの作成または更新が発生する可能性があります。間違ったキューの。

必須の ObjectMeta.Name フィールドを使用して、連結された vhost とキュー名の両方を含め、デプロイされたキューに対してそれらが不変であることを確認するなど、いくつかの代替案を検討しています。または、何らかの方法で古い仕様をオペレーター内にキャッシュし (これを行う方法をまだ正確に把握していません)、リコンサイラーで古い仕様と現在の仕様を比較し、VHost変更された場合はエラーを返します。ただし、これらのアプローチはどちらも理想的とは思えません。理想的には、オペレーター フレームワークがVHostフィールドに不変性を適用できる場合、それはこれを処理するための簡単なアプローチになります。

カスタム Kubernetes コントローラーを作成しようとしています。この場合、CRD を作成しようとしているわけではないので、コントローラーを意味します。つまり、オペレーターではありません。基本的には、アノテーションを監視し、そのアノテーションの有無に基づいてアクションを実行するという点で、外部 DNSプロジェクトに似ています。

このようなものの簡単な例はありますか？私が見つけたリソースのほとんどは、オペレーターと CRD の作成に関するものですが、私の使用例では、注釈のみを確認するだけです。

デプロイを管理するカスタム リソースがあります。デプロイを直接スケーリングするのではなく、デプロイの CPU 使用率に基づいて HPA で CR レプリカ数をスケーリングできるようにしたいと考えています。デプロイを直接スケーリングする場合、調整ループがトリガーされると、CR に記載されているようにデプロイ レプリカ数と目的のレプリカ数との不一致がすぐにわかり、それに応じてデプロイが更新されます。

私はかなり近いです。CR のスケール エンドポイントが正常に機能しており、HPA もエンドポイントに到達できます。子のリソース使用量を読み取ることができません。

展開を直接スケーリングする場合も機能しますが、上で述べたように、それは実行可能なソリューションではありません。メトリクス サーバーが正常に機能しており、リソースの使用率が取得可能であることを証明するだけです。

HPA YAML:

そして、HPA が少なくとも CR のスケール エンドポイントに到達できることを証明します。

ご覧のとおり、リソース使用率の取得にダイスはありません...