ここの話です．
Issueの内容を熟知している方には余計なお世話です．
いやーこんなの自分には関係ないだろうと思ってたら見事に当たりました．
問題になるケース
問題になるケースはおそらく以下の2パターン．
- OwnerとChildが別のnamespaceに所属するパターン
- namespaceに所属するOwnerがcluster scopeなChildからOwnerReferenceを張られているパターン
ちなみにこれは作成時にエラーになるわけではない．あくまでGCコントローラの挙動の変更なので，リソースが削除される挙動が変更になっている．
私の場合2に該当していた．
CRDを定義して，カスタムリソースをapplyするとAdmissionWebhookのConfigurationと，それに合わせたWebhookのPodとServiceを作るようなコントローラを作っていた． このとき，CRDのscopeをNamespacedにしていたんだけど，NamespacedなカスタムリソースがCluster scopeのValidating/MutatingWebhookConfigurationをChildに持つ場合，がっつり上記に該当してGCされなくなる． 結果として，カスタムリソースを削除してもWebhookConfigurationが削除されないという状態になった．
対応
私の場合の話なので，2に該当する場合なのだけれど，OwnerがNamespacedである必要がないのであれば，OwnerをCluster scopeにしてしまえば良い．Cluster scopeなOwnerがCluster scopeなChildを持つことは特に問題ない．また，Cluster scopeなOwnerがNamespace scopeのChildを持つことも，特に問題はない．GCコントローラはちゃんとOwnerが消えたときにChildも消してくれる．
今回で言うなら，Validating/MutatingWebhookConfigurationのOwnerなので，別にCluster scopeで良くて，Cluster scopeに変更することで対応できた．合わせて作るPodとServiceのnamespaceをどこにするかは悩みどころではあったが．Cluster scopeなカスタムリソースもそれらのPodやServiceのOwnerになれるので，特に問題はなかった．
1についても同様なのだけれど，OwnerがCluster scopeで良いのであれば，Cluster scopeにすることで正しいOwnerReferenceになる．
問題はOwnerがNamespace scopeである必要がある場合なのだが，それってどんなケースなのか想像できないのでちょっと対応策も思いつかない……．
気づいた経緯
そもそもこの話は知っていたんだけど，完全に無関係だろうと思っていた．ので完全に油断していたんだけど，先日書いたkind local registryによりE2Eがそれなりの頻度でCIで走るようになったおかげで気づいた．
Kubernetes 1.20に上げたところでテストが落ちて，AdmissionWebhookが消えなくなっていたので，そこで問題が発覚した．
E2Eテスト便利や．
ちなみに記事でも紹介されてたけど kubectl-check-ownerrefefrences を使えば一発でわかるんで，これも便利だったよ．
