はじめに
ここでは Cluster API v0.3.12 の変更内容についてまとめています。Cluster API は複数の Kubernetes クラスタのプロビジョニングやアップグレード、オペレーションをするための宣言的な API とツールを提供する SIG Cluster Lifecycle のサブプロジェクトです。
✨ 新しい機能
- Secret と ConfigMap でキャッシュしないクライアントとメタデータのみを使用するように変更されました (#3986) — 影響: メモリ使用量の軽減。全監視対象の Namespace の全てのオブジェクトのローカルキャッシュを作成する代わりに、Secret と ConfigMap に対するクエリはコントローラが直接 API サーバにアクセスするようになりました。
-
Secret と ConfigMap を使うコントローラが増えてきたので、キャッシュの容量が多くなってきたことへの対策のようです。キャッシュするのがオブジェクトのメタデータのみに変更され、オブジェクトを変更する場合はキャッシュではなく直接 API サーバにアクセスするように変更されています。
-
- Cluster API GCP プロバイダが
clusterctl providers listに追加されました (#4008)
🐛 バグ修正
- MachineHealthCheck (MHC) は継続的なパッチを避けるために MHC
.status.targetsのリストをソートします (#3998)-
MHC の対象ノードのリストの並び順がソートされていなかったことで、リストに変更がなくても
statusフィールドが更新されてしまっていたようです
-
- KubeadmControlPlane のスケールイン時の確認では、削除されようとしているマシンが除外されるように修正されました (#3984)
-
KubeAdmControlPlane のスケールアウト/イン時には全 ControlPlane マシンの preflightCheckCondition が
Trueであるかどうかを確認して、問題のあるマシンがあれば処理が進まないようになっているのですが、スケールイン中の例えば etcd を削除している最中にコントローラがクラッシュすると、次の reconsile 時に Condition の確認に失敗するため、スケールイン処理がブロックされてしまっていました。
-
- KubeadmControlPlane (KCP) は、etcd メンバを reconsile する際に自身の NodeRefs 使用するように修正されました (#3971) - 影響: コントローラがクラスタと ControlPlane としてノードのリストにまだ登録されていない Kubernetes ノードをアップグレートしようとする間の競合状態が解決されます
-
これまで etcd メンバを reconsile するときにはワークロードクラスタから
node-role.kubernetes.io/masterラベルを持つノードのリストを取得して対象を探していました。しかし、Machine オブジェクトのstatus.nodeRefフィールドで実際にどのノードなのかの情報は取得可能なため、この変更でワークロードクラスタへの問い合わせることをやめることで安定性が向上します。
-
- apierrors の際に
errors.Causeが適切に確認されるようになりました (#3969) — 影響: マシンの削除がスタックしたり、何度も再試行した後にタイムアウトする問題が解決されます - MachinePool のブートストラップトークンがローテーションされます (#3965) — 影響: MachinePool のブートストラップトークンは以前はローテーションされておらず、15分後に期限切れになっていました。この変更により、新しい MachinePool のインスタンスは、タイムアウト後にもクラスタに参加できるようになりました
📖 ドキュメンテーション
- クイックスタート内の Cluster API OpenStack の変数が更新されました (#3952)
所感
このリリースは大きな機能追加が含まれていませんが、クラスタに対しての操作の安定性向上に取り組まれていて着実によくなってきているという印象を持ちました。また、MachinePool でのブートストラップの期限切れ問題で、私は MachinePool は使っていないのですが単にマシンの作成時時間がかかりすぎていてトークンの期限切れが起きているので対処を検討中です（このバージョンでうまくいったらここを更新します）。