置き換えか更新か — 変えられない属性は、作り直しになる

宣言の1行を書き換えて apply したとき、世界の側で起きることは2通りあります。今ある実体をその場で直すか、壊して新しく作るかです。書き換えた行の見た目は同じでも、結果はまるで違います。作り直せば id が変わり、中にあったものは消え、壊してから作るまでの間には何も無い時間ができます。

Terraform の文書は、作り直しになる条件をこう書きます。

By default, when Terraform must change a resource argument that cannot be updated in-place due to remote API limitations, Terraform destroys the existing object and then creates a new replacement object with the new configured arguments.

鍵は due to remote API limitations です。変えられないのは Terraform の都合ではなく、相手の API にその場で変える手段が無いからです。その事情を知っているのは、相手の API を包んだプロバイダです。プロバイダ向けの SDKv2 の文書は、属性ごとの印をこう定義します。

ForceNew indicates that any change in this field requires the resource to be destroyed and recreated.

属性がその場で変えられるかどうかは、プロバイダがスキーマで申告しています。 Terraform 本体はその申告を読んで、plan に作り直しを載せます。書き手の側にも手段はあります。replace_triggered_by は Terraform replaces the resource when any of the referenced resources or specified attributes change.、plan の -replace は指定した実体の置き換えを指示し、逆に ignore_changes は指定した属性を更新の計画で無視させます。

既定の「壊してから作る」には、間に何も無い時間があります。これを避ける規則が create_before_destroy ですが、文書はそれが既定でない理由を書いています。

This is an opt-in behavior because many remote object types have unique name requirements or other constraints that must be accommodated for both a new and an old object to exist concurrently.

先に作れば、一瞬、新旧の2つが並びます。名前が一意でなければならない相手では、その一瞬が成り立ちません。文書は続けて、名前に乱数の接尾辞を付ける選択肢を持つ型もあるが Terraform CLI cannot automatically activate such features と書きます。名前をずらすのは書く人の仕事です。

Kubernetes では、決める者の置き方が違います。Pod はコンテナを包む最小の単位、ReplicaSet は指定した数の Pod を保つコントローラ、Deployment は ReplicaSet を使って Pod の更新を進めるコントローラです。

1つ目の決め手は API サーバの検証 です。文書は A Deployment's label selector is immutable after creation; と書き、変えたいなら you have to delete the Deployment and recreate it. とします。Terraform のように自動で作り直すのではなく、要求そのものを拒否します。

2つ目は コントローラの作り です。Pod の中身を決める template を変えると、Deployment は今の Pod を直さず、新しい ReplicaSet を作って古いほうを減らします(A new ReplicaSet is created, and the Deployment gradually scales it up while scaling down the old ReplicaSet)。新しい ReplicaSet の名前には template から決まる pod-template-hash が付くので、新旧の名前はぶつかりません。これは create_before_destroy の文書が挙げた「名前をずらす」を、コントローラが毎回やっている形だと読めます(この対応づけは教材側の整理です)。

例外もあります。Pod の CPU とメモリの requests と limits は、Stable since Kubernetes v1.35 の in-place resize で、動いている Pod を作り直さずに変えられます。これは Pod を直接変える話で、Deployment の template を変えれば rollout になる規則は変わりません。