結論
Operatorが管理するリソースを手で直しても、reconcileで元に戻ります。直すべきは、Operatorが入力として見ている「原本」です。
何が起きたか
OpenShift上のある製品でカスタムドメイン名を変更したら、ログインが401で通らなくなりました。原因は内部通信用のCA証明書が新旧で食い違っていたことです。
そのCAを保持しているConfigMapを手で書き換えると、401は消えます。ところがしばらくすると再発し、ConfigMapを見ると古いCAに戻っていました。直す→戻るを何度か繰り返して、ようやく「直す場所が違う」と気づきました。
なぜ巻き戻るのか
この製品では、証明書が3層のチェーンで管理されていました。
Operatorは「あるべき状態」を定期的に原本から作り直します。ConfigMapだけ直しても、次のreconcileで原本の旧CAがコピーされ戻ります。原本のSecretを直せば、reconcile後も新CAが維持されます。
直し方
原本のSecretを更新し、reconcileを待つと派生物まで自動で伝播します。
# 現状を保存（type の確認も兼ねる）
oc get secret <cert-secret> -n <namespace> -o yaml > cert-secret-backup.yaml
oc get secret <cert-secret> -n <namespace> -o jsonpath='{.type}{"\n"}'
# 中身だけ差し替える（type / labels / ownerReferences を保持）
oc patch secret <cert-secret> -n <namespace> --type=merge -p "$(cat <<EOF
{"data":{
"ca.crt":"$(base64 -w0 ca.crt)",
"tls.crt":"$(base64 -w0 tls.crt)",
"tls.key":"$(base64 -w0 tls.key)"
}}
EOF
)"
# チェーンが繋がっているか確認（中間CAがある場合は -untrusted intermediate.crt を追加）
openssl verify -CAfile ca.crt tls.crt
oc delete → oc create で作り直すと、Secretのtypeが Opaque に変わったり、ownerReferencesが消えてOperatorにデフォルト値で再作成されたりします。中身だけpatchするのが安全です。
派生のConfigMapや成果物には手を触れません。原本が正しくなれば、Operatorが下流を作り直してくれます。
ハマりやすい点
同名・別鍵のCA。 新旧のCAがCNまで同じで鍵だけ違うことがあります。名前で見ると「同じCAだ」と誤認しやすく、証明書検証の失敗を長く追う羽目になります。発行日や鍵の指紋で区別してください。
副次エラーに釣られる。 証明書チェーンが切れると、認証やアプリ層で別のエラーコードが出ることがあります。表面のエラーを追うと迷子になります。ログを時系列で並べ、どのエラーが他方を引き起こしているのか因果を追うのが早道です。
派生物が新しくなっても反映されない。 トラストストアは起動時に読み込まれることが多く、ConfigMapとp12が更新されても参照側のPodは旧トラストストアを掴んだままです。伝播を確認したら、参照側をrolloutしてください。
まとめ
Operator管理下のリソースを手で直すときの手順です。
- 派生物には ownerReferences が付くので、それを辿って原本を特定する
- 派生物ではなく原本を直す
- reconcileで派生物まで伝播したことを確認し、参照側Podをrolloutする
「一時的に直ったのにしばらくすると戻る」なら、原本ではなく派生物を直している可能性が高いです。