目次を開く
結論
再現可能な構成と、安全なクラスタ更新は別の性質として検証する。
背景
バージョンを固定できても、クラスタの状態や永続データまで固定できるわけではない。宣言的な構成管理と状態を持つシステムの更新手順を分けて考える。
設計と検証の論点
構成を検討するときは、次の責任と境界を分けて確認します。
- NixOS
- バージョンの固定
- etcd
- Kubernetesのバージョン差
- 段階的な展開
- ロールバック
- 試験
判断理由
NixOSと試験の関係を軸に、採用案と代替案の責任範囲を比較します。既存の制約を残す理由と、新しい境界で変えられることを分けて記述します。
トレードオフ
バージョンの固定を扱うために増える実装・保守・確認作業と、得られる制御可能性を比較します。障害時の経路と運用担当者の負担を含め、採用しない方がよい条件も示します。
制約
ロックファイル、バイナリ版、etcdのスナップショット、更新順、失敗時の復旧手順を確認する。構成ロールバックがデータ形式の逆変換を保証するとは扱わない。
関連事例
関連事例の担当範囲や設計判断を参照します。記事で提案する実験・構成を、その事例で実施済みとするものではありません。