Kubernetesクラスターのバージョンアップ｜kubeadm更新順序・互換性・復旧
kubeadmクラスター自体の更新前確認、業務停止の判断、実施順序、更新後の復旧確認を整理。
この記事の目的
マイナー更新の互換性と停止条件を確かめ、安全に段階的な更新を判断。
まず確認
context、API Serverとkubelet版、etcd、Pod退避可能性。
1. 更新前に知っておくこと
対象環境と停止リスクを先に確認し、作業可否を判断します。
- 版とAPI
- version skew、非推奨API、CNI/CSIを確認
- Pod退避
- PDB、空き容量、レプリカ、ステートフルデータを確認
- 復元
- Control Plane/etcd quorumとアプリデータ復元手順を確認
対象環境と更新できる範囲
対象：Linuxでkubeadmを使用して構築したKubernetesクラスター。 EKS/GKE/AKS、k3sなどは管理者や提供元の専用更新手順を使います。マイナーバージョン飛ばしは非サポート。今の版から次のマイナーへ段階的に進め、対象リリースの公式文書を利用します。最終公式情報確認：2026年11月1日。
本記事は基盤そのものの更新。Deploymentのロールアウトはアプリの変更で別の検索意図です。
停止を避けられる構成か最初に判定
| 条件・監視結果 | 具体的な対応 |
|---|---|
| 単一Control Plane | 更新中APIが止まる可能性あり。既存Podが残ってもAPI依存の処理は影響する。完全無停止の保証はできない |
| HA Control Plane・etcd | LB配下のAPI Serverを順次更新し、etcd quorum・証明書・API可用性を毎段階で確認。quorum崩壊リスクがあれば中止 |
| Worker複数台、各アプリ冗長＋余剰容量 | PDB、readiness、graceful termination、Node間分散、退避先CPU/メモリを検証してカナリアNodeから開始 |
| 単一レプリカ、local PV/退避不可Pod | Pod停止やデータ影響があり得る。無停止前提ではなく、アプリ改修・一時移行または停止時間の合意を求める |
PodDisruptionBudgetはEviction APIによる退避を調整しますが、全障害・手動削除を防ぎません。「drain成功＝ユーザー業務が無停止」ではないため、外形監視と業務テストが必要です。Kubernetes公式：Disruptions。
バージョンスキュー・非推奨API・アドオンを判断
| 確認結果 | 次に行うこと |
|---|---|
| API Serverとkubelet | kubeletをAPI Serverより新しくしない。許容するマイナー差は公式version skew規定を確認 |
| kubectlの版差 | 通常はAPI Serverの前後1マイナー。HAでAPI Server版が混在すると制約が狭くなる |
| Ingress/CNI/CSI/CoreDNS/Operator | 提供元の対応版を調べる。CRD、廃止予定・削除APIを棚卸し |
| PodDisruptionBudget・Node空きリソース | drainの退避先と最小稼働レプリカを確保。PDBを無断緩和しない |
| HA/etcdの健全性 | quorum、LB、証明書期限、復旧コンソールとスナップショットを確認 |
Nodeが1台だけ、または余剰容量が不足する場合、稼働停止を伴う可能性があります。更新中の負荷・サービス影響を事前に合意します。
バージョン対応表を作成してから更新先を選ぶ
| 確認条件・症状 | 対応・判定 |
|---|---|
| API Server・kubeadm・kubelet | 現行版/目標版を分けて記録。kubeletをAPI Serverより新しくしない。混在中も公式skewポリシーに適合 |
| kubectl/外部Operator | API Serverとの許容版差、廃止API・CRDの利用実績と対応バージョンを確認 |
| CNI/CSI/CoreDNS/kube-proxy | アドオン提供元の対応表・バージョン変更・追加の更新順序を記録 |
| PDB・Node配置 | drainの許容退避数、余剰リソース、local data/emptyDir、単一ノード運用時の停止条件を確認 |
| HA/etcd | LB、Control Planeのquorum、etcd方式（stacked/external）と証明書の状態を記録 |
例えば1.36.x→1.37.xは更新経路の説明例であり、運用時の全環境で適用すべき最新バージョンを示すものではありません。対象のリリース別公式ガイドを確認。kubectl api-resourcesで表示されるのは利用可能なAPIであり、廃止APIを現在どのアプリが使用しているかまでは判定できません。監査ログ、マニフェスト、Operatorの提供元情報を使います。
secretRef・configMapRefなど、API上のSecret/ConfigMapを直接参照する構成はv1.37で禁止されています。/etc/kubernetes/manifests/配下など管理対象のStatic Podを更新前に棚卸しし、該当する場合は対応する設定・機密情報の供給方法を設計して、検証環境で起動確認ができるまで本番更新を保留してください。Kubernetes公式：v1.37の互換性変更。cgroup v1と実行環境の互換性確認
Kubernetes 1.35以降はfailCgroupV1が既定でtrueとなり、cgroup v1使用ノードではkubeletが起動できない可能性があります。これは1.37で初めて導入された変更ではありません。1.37でも一時的な回避設定は残るものの、長期運用ではOS/kernel・container runtimeとともにcgroup v2への移行計画が必要。cgroup driverの不整合も確認してください。公式1.37リリース。
現行→目標のAPI Server/kubeadm/kubelet/kubectl版、廃止API、CNI/CSI/CoreDNS/Ingress/Operator対応、サポート期限を1件ずつ記録し、証跡がない項目はGo判定を出さないようにします。
更新前に対象context・稼働状況・版を確かめる
誤ったクラスターへ接続しないよう、実行するcontext、Control Plane/Worker台数、etcd構成、RBACを確認。すでにNotReadyのNodeやAPI不調があれば更新を保留し、原因を切り分けます。
etcd・業務データのバックアップと復元確認
etcdスナップショットは暗号化・アクセス制限のうえ保管し、実際に復元できることを検証。/etc/kubernetesの構成、証明書/管理情報、GitOpsマニフェストとアプリDBは別にバックアップしてください。kubeadmが自動生成するバックアップの存在だけで復旧可能とは限りません。
作業前に各Nodeの更新順序、PDB、DaemonSet、emptyDir/local storage、残余リソース、監視、API/業務の正常値を記録し、サービス停止を許容できる時間を決めます。
etcdバックアップと復元条件は構成別に確認する
stacked etcd、external etcd、HA Control Planeでは復旧・quorumの要件が異なります。復元に必要なTLS証明書、etcd endpoint、管理者アクセスを保護して保存し、隔離環境でのスナップショット復元試験を実施。実環境で不用意に/var/lib/etcdを上書きしないでください。アプリのDB・PersistentVolumeとetcdは別に保全します。
Pod退避とControl Planeの停止影響
- 単一Control PlaneならAPI停止の可能性を前提に保守窓を確保
- HAではロードバランサとetcd quorumを維持する順序で1台ずつ更新
- Podの退避先CPU/メモリ・PDB・local storage・DaemonSetを先に確認
- バックアップと実際の復元手順、RPO/RTO、緊急連絡先が確認できない場合は作業中止
2. 確認コマンドと結果の読み方
代表例を見てから、必要なコマンドの詳しい判定へ進みます。
以下は結果の読み方を示す想定例であり、実環境の測定結果ではありません。
| 確認 | 目安 | 要確認・異常時 |
|---|---|---|
kubectl get nodes -o wide | 対象NodeのReadyと予定版 | NotReadyや想定外cordonは保留 |
kubectl get pdb -A | ALLOWED DISRUPTIONSと対象Pod | 0はPDB障害と限らないが退避可否を再判定 |
kubectl get --raw='/readyz?verbose' | API readinessの確認 | 業務アプリの正常は別 |
確認コマンドの期待出力・正常判定・異常時の対応
kubeadmで構築したLinuxクラスター向け想定例であり、実クラスタのログではありません。正常＝承認した版・対象・構成・業務基準と一致、要確認＝PDBの許容退避0・Job Completed・意図したcordonなど、異常＝想定外のUnavailable/NotReady/API異常、判定不能＝RBAC/接続/ツール未導入で結果が観測できない状態。いずれも重要条件が判定不能なら更新を開始・継続しません。
全コマンドの想定出力と結果別の判断を見る
実機の環境や版によって出力は変わります。必要な箇所を開き、対象ホストと終了コードも照合してください。
| コマンド・操作 | 想定出力 | 結果別判断と次工程 |
|---|---|---|
kubectl config current-context | 対象クラスターcontext名 | 変更票のcontextと一致が必須。異なるなら誤対象を防いでNo-Go。空/エラーはkubeconfig・認証確認 |
kubectl cluster-info | control planeの接続先URL・CoreDNSなど（環境次第） | 接続先/名前解決が承認したclusterと一致。認証や到達不能なら更新開始禁止 |
kubectl version | Client/Serverの版（取得不能時Clientのみ等） | API Serverの現行版とkubectl skewを確認。Server取得不可はAPI/権限/ネットワークの判定保留 |
kubectl get nodes -o wide | Node名、STATUS=Ready/NotReady、VERSION、IP | 作業前は承認ノード全件Ready・版一致が基本。更新中Ready,SchedulingDisabledは計画cordonなら想定内 |
kubectl get pods -A | namespace、READY、STATUS=Running/Completed/Pending等 | 重要deploymentのdesired/ready、JobのCompleted等を個別照合。Pending/CrashLoopは原因確認。Completed自体はJobでは正常のことあり |
kubectl get pods -A -o wide | PodのNode割当・PodIP・Ready数 | drain前後の退避先と対象namespaceを比較。想定外のPending/偏り/終了は次Node更新禁止 |
kubectl get pdb -A | PDB、MIN AVAILABLE、ALLOWED DISRUPTIONS | 対象PodのPDB許容量と余剰capacityを評価。0はPDB異常ではないが対象Nodeのdrain実施可否は保留 |
kubectl get --raw='/readyz?verbose' | 各API readiness項目がok、readyz check passed等 | すべてokはAPIのreadiness。ForbiddenはRBAC/認証を確認、failedはAPI/etcd調査。これだけでアプリ合格にしない |
kubectl get apiservices | NAME、AVAILABLE=True/False/Unknown等 | 重要なaggregated APIがTrue。False/UnknownはAPIServiceとログ調査。存在しないAPIの扱いは構成依存 |
kubectl get csidriver | 導入CSI Driverのリソース名と設定、0件も可 | ストレージを利用する場合は対応Driverが確認できること。0件はCSI非利用の場合は想定内 |
stat -fc %T /sys/fs/cgroup | cgroup2fs（v2）またはtmpfs（v1等） | 1.35+のデフォルトでv1ならkubelet起動/前提検査に失敗し得る→v2移行計画。取得不能はノードアクセス確認 |
kubelet --version | kubelet version: v1.X.Y等 | 現在API Serverとのskewがサポート範囲内。更新先のkubeletとOS/CRI/cgroup互換も確認 |
sudo systemctl status kubelet --no-pager | active(running)、failed、起動ログ | activeだけでNode正常とは限らない。failed/再起動ループはjournal/CRI/CNIを調査 |
kubeadm version -o short | v1.X.Y | 現行/導入後のkubeadm版が計画のマイナー/パッチと一致。計画外版なら更新停止 |
sudo kubeadm upgrade plan | 対象版候補・現在版・upgradeability/エラー等 | 選定した次マイナーとversion skew・preflightが許容。拒否/警告は診断。確認結果なしなら判定不能 |
grep -R 'pkgs.k8s.io\|apt.kubernetes.io' ... | source内の対象minor別URL、設定なしなら空 | 対象版のpkgs.k8s.io seriesを使用。古いrepo/混在/未設定なら更新中止 |
apt-cache madison kubeadm | 利用できるkubeadm version候補 | 選定版の実在を確認。無ければrepoと鍵/対象minorを調査 |
apt-cache madison kubelet | 利用できるkubelet候補 | kubeadmとskewを満たす対象版。未提供/誤版ならGo不可 |
apt-mark showhold | hold中のkubeadm/kubelet/kubectlなど | 予定されるhold/unholdを確認。意図外の先行アップグレードを防ぐ |
sudo kubeadm upgrade apply vX.Y.Z | 初回Control Planeのupgrade進捗と完了/失敗 | 選定版に置換して初回CPのみ実施。API・etcd/Addonの再検証が完了するまで別CPへ進まない |
sudo kubeadm upgrade node | 追加Control Plane/Workerでローカル設定の更新結果 | 対象ノードと版・前提条件が一致して実行。失敗時はAPI/etcd/kubeletの状態保存、無条件force禁止 |
kubectl drain NODE_NAME --ignore-daemonsets | node/<name> cordoned, evicting pod, node/<name> drained等 | 対象Node・PDB・退避先が承認どおりのときのみ実行。PDB拒否/timeout/未管理Podは一旦停止し原因を調査 |
sudo systemctl daemon-reload | 通常出力なし、exit 0（systemd構成再読込） | 失敗時はsystemd設定問題を調査。出力なしはkubelet正常の証拠ではない |
sudo systemctl restart kubelet | 通常出力なし、exit 0（kubeletサービス再起動） | status/kubelet journal、Node Readyと版確認が必要。失敗またはNode NotReadyならuncordonせず調査 |
kubectl uncordon NODE_NAME | node/<name> uncordoned等の確認 | 実行前にNode Readyと安全な復帰条件を確認。実行後にPod/Service/業務検証し次Nodeへ進むか判断 |
想定出力例：NodeとPDB
drainオプションの危険性を混同しない
| オプション | 意味 | 運用判断 |
|---|---|---|
--ignore-daemonsets | DaemonSet管理Podを削除せず無視する | 対象のDaemonSet影響を別途確認 |
--force | 非管理Podや管理元がないPodの削除を許す | PDB回避ではない。データ・再作成可否を承認 |
--delete-emptydir-data | emptyDir利用Podでデータ削除が起こる退避を許す | 一時データ損失・アプリ影響を承認 |
--disable-eviction | EvictionでなくDeleteを利用しPDBチェックを回避 | 本番で無断使用禁止。別途承認・業務影響を評価 |
公式仕様：kubectl drain。NodeのReadyは復帰の前提の一つだが、uncordon直後の業務成功・観測期間の合格まで次Nodeへは進まない。
作業判定票：Go / Hold / Abort / Recovery を明確化
以下の欄を更新前に実環境の数値・対象・責任者で記入し、未確定のまま本番更新しません。閾値を記事の架空数値で共通化しないでください。
| 工程 | 必要な証跡・判断者 | 許可・保留・中止条件 |
|---|---|---|
| Preflight / Go | 対象host/node、現行/目標版、パッケージ差分、公式修正情報、復旧試験、切替担当と承認者 | すべて照合済みならGo。未実施/権限不足/候補違いはHold |
| Canary / Hold | 対象をLB/スケジューラで隔離、OS・アプリログ、重要ユニット・業務APIの基準値 | 事前SLOしきい値超過、データ異常、想定外の再起動ならAbort |
| 段階復帰 / Go | アプリ認証、HTTP成功率・5xx、p95、DB read/write、Job、監視、観測時間の記録 | 合格後に対象を復帰し観測完了した場合のみ次ホストへ。回復せず原因不明ならHold |
| 復旧 / Recovery | 原因ログ、バックアップと復元点、データ互換性、RTO/RPO、復旧承認者 | 変更を止め、既知の復旧手順を使用。ロールバック不能なら担当者へエスカレーション |
想定出力（実クラスタでの実測ではない）
Readyでも業務通信が正常とは限りません。更新途中にはNodeごとのバージョン混在が発生するため、許容差と実際のAPI Serverとの関係を確認します。
3. 安全な進め方・完了確認と復旧
環境ごとの作業計画を前提に、変更・監視・中止・復旧の順で確認します。
次へ進める条件：Control Plane/WorkerごとのAPI・etcd・Pod・業務の合格を確認して次へ。
Control PlaneからWorkerへ順番に更新
操作の前提：現在版→次の1マイナーの正式な更新先、正確なパッケージ版と対象リポジトリ、バックアップ、停止計画、責任者承認が確定していること。パッケージ管理（apt/DNF）やHA条件でコマンドが異なるため、実際の対象版の公式手順を優先してください。
- 最初のControl Planeで選定版のkubeadmパッケージを更新し、
sudo kubeadm upgrade planで状態確認。 - 承認後に最初のControl Planeへ
kubeadm upgrade applyを実施。 - 追加Control Planeをノードごとに
kubeadm upgrade nodeで更新。 - kubeletのマイナー更新前に対象Nodeをdrainし、OSパッケージ更新とkubeletの再起動を行う。
- Node Ready・アプリ動作を確認した後、uncordonして次のノードへ進む。
--forceは管理コントローラー不在のPodの削除を許可し、PDB回避ではありません。--delete-emptydir-dataはemptyDirデータ消失を許容します。--disable-evictionはEviction APIを使わずPDBチェックを回避するため、通常の運用で無断指定してはいけません。更新先のパッケージリポジトリとholdを確認（Ubuntu例）
最新のkubeadmパッケージはマイナーごとに分かれるpkgs.k8s.ioのリポジトリで提供されます。旧apt.kubernetes.ioのままでは新しいリリースを取得できません。まず管理方式・署名鍵・リポジトリの対象系列を照合し、更新先の正確なパッチ版を選びます。
kubeadm、kubelet、kubectlのholdを一斉に解除せず、各段階で更新対象のパッケージのみを変更します。公式ガイドのapt-mark unhold→選定版のapt-get install→apt-mark holdを使用し、安易なOS全体の更新でkubeletが先に上がらないようにします。
Control Plane・Workerそれぞれの実施順序
- 最初のControl Plane：対象版のkubeadmだけをパッケージ更新、
kubeadm version・sudo kubeadm upgrade planを確認、選んだ正確な版でsudo kubeadm upgrade apply vX.Y.Z。API・etcdとアドオンの健全性を確認。 - 同Control Planeのkubelet：対象Nodeのdrain可否を確認→kubelet/kubectlの対象パッケージを更新→systemdからkubeletを再起動→Readyとアプリ動作を確認→uncordon。
- 追加Control Plane：各ノードのkubeadm更新後、
kubeadm upgrade nodeを使う。Control Plane/etcdの健全性を確認し、kubeletの更新とPod退避は別手順で実施。 - Worker（公式のLinux Node更新順序）：対象版のkubeadm/kubectl更新→
kubeadm upgrade node→kubectl drain→kubelet更新・再起動→Readyと実業務疎通確認→kubectl uncordon。
kubeadm upgrade applyは最初のControl Planeで使用し、kubeadm upgrade nodeと使い分けます。--forceは非管理Podへの操作、--delete-emptydir-dataはローカル一時データ消失、--disable-evictionはPDBチェック回避という別々のリスクがあるため、いずれも無断指定しないでください。Linux Worker Nodeの公式順序と安全な更新例
公式順序：kubeadmとkubectlの版指定更新 → kubeadm upgrade node → Control Plane側からdrain → kubeletの版指定更新・サービス再起動 → Ready/業務確認 → uncordon。過去の記事にあった「drain→kubeadm」の簡略順序はこの公式順序に修正しました。Control Planeは初回のkubeadm upgrade applyと追加ノードのkubeadm upgrade nodeを使い分けます。
実コマンドのパッケージ版は選定したマイナー系列のpkgs.k8s.ioから取得し、hold/unholdを含め対象版の公式ページで確認。退避前にPDB・emptyDir・local PVと退避先を調べ、--force、--disable-eviction、--delete-emptydir-dataを無断指定して退避を進めない。公式：Worker Nodeアップグレード。
Control Plane・Workerを段階的に更新
- 最初のControl Planeを更新し、etcd quorumとAPI/LB、CoreDNS・管理用認証を確認。失敗時は追加Control Planeへ進まない。
- 追加Control Planeを1台ずつ更新。API・etcdのヘルスとLB疎通を毎回確認。
- 代表Worker 1台をカナリアとして更新。PDBやPod分散、Node Readyだけでなく業務API/DB、ジョブ・外形監視を確認。
- 承認した観測期間とSLOしきい値を満たしたら次Nodeへ。違反したら次のNode更新を停止し、対象Nodeを隔離して調査。
障害・保留時の分岐
| 確認結果 | 次に行うこと |
|---|---|
| upgrade planが非対応版を表示 | 作業中止。マイナー飛ばし・選定版・パッケージ提供元を再確認 |
| drainがPDBで止まる | 容量とreplica、業務要件を検討。強制的にPodを消さない |
| NodeがNotReady | kubeletのsystemctl/journal、CRIとCNIを調査し次Nodeの更新を保留 |
| PodはRunningだがサービス障害 | Service・EndpointSlice・Ingress・アプリログを確認 |
| CRD/Operatorが非対応 | 廃止APIとアドオン提供元を調べ、管理者にエスカレーション |
問題が起きた段階別の詳細な判断
| 確認条件・症状 | 対応・判定 |
|---|---|
| kubeadm upgrade planが不許容版を表示 | 現在版/目標版・マイナー飛ばし・aptリポジトリ・holdを確認。解消するまで更新しない |
| drainがPDBまたはlocal volumeで停止 | PDBの許容退避数、レプリカ、空きNodeとデータ保持要件を調査。無条件にPodを削除しない |
| Control PlaneのAPI/etcdが不健康 | 追加ノード更新を即中止し、static Pod・証明書・kubelet・etcdログとquorumを保全 |
| NodeがReadyだがService不通 | EndpointSlice、CNI、CoreDNS、Ingress、認証、業務リクエストを確認 |
| Operator/CRDが起動しない | 廃止API・提供元互換表を再確認。アプリ担当の承認なしにCRDを削除しない |
次Nodeへ進む条件・中止基準
| 条件・監視結果 | 具体的な対応 |
|---|---|
| etcd quorum・API Server/LBの不調 | Control Plane/Workerの追加更新を中止。スナップショットとログを保全し復旧判断 |
| PDBでdrain停止、Pod Pending、PVマウント失敗 | 無理に削除せずReplica/余剰容量/ストレージを確認 |
| readiness・EndpointSliceは正常でも業務エラー増加 | 業務HTTP成功率、p95遅延、認証/DB/ジョブ処理の基準と比較。閾値超過なら次Nodeへ進まない |
| etcd/業務データの復元点に疑い | 旧データを上書きしない。基盤・アプリ管理者の承認があるまで作業中止 |
停止しきい値、責任者、観測時間は作業前にサービスのSLOに合わせて決定。Readyだけで継続判断しないことを運用ルールにします。
更新後の合格・不合格条件
合格：Control Planeと各Nodeが選定版・version skewを満たし、Ready、重要Podとアドオンが正常、業務通信も成功。不合格：API到達不可、NotReady、Pod退避失敗、アプリ疎通異常が残る場合。正常化前に次のNodeへ進みません。
uncordonと次ノード更新のゲート
| 確認条件・症状 | 対応・判定 |
|---|---|
| 選定した版と互換性を満たす | Control Plane/kubeadm/kubeletの実版と公式version skewを照合 |
| Nodeと重要Podが正常 | Node Ready、Pod Ready、PDBに違反せずCNI/CSI/監視が正常 |
| 業務データと通信が正常 | Service/EndpointSlice、アプリHTTP、DB読み書きと外形監視が正常 |
| 不正な状態が残る | uncordonや次ノードへの更新を行わず、該当段階のログを保全 |
すべてのNodeがReadyでもAPI互換性、コントローラーや業務処理の正常を保証しません。各段階の完了が次のノードへの進行条件です。
失敗時の復旧・エスカレーション
Kubernetes更新のダウングレードは、単なる旧パッケージの再導入では成立しません。etcd、API/CRDやコントロールプレーン構成の整合性が必要です。更新途中の失敗はログ・構成変更・etcd状態を保全し、公式の再実行可能条件を確認。無条件のkubeadm upgrade apply --forceは避けます。
復旧策は事前に検証したetcd/Control Planeの復元手順、アプリデータの保全と業務整合性を担当者が判断。復旧経路不明、quorum消失、重大サービス障害なら作業を止め、SRE・ネットワーク・アプリ担当へエスカレーション。
再試行できる失敗と、復元を要する失敗を区別する
Kubernetes公式では、kubeadm upgradeが冪等的で再試行できる場合があると説明されています。ただしAPI/etcd、静的Pod、証明書、構成の整合性が条件です。ログを採取し、対象版の公式手順と状態を確認してから判断します。
| 確認条件・症状 | 対応・判定 |
|---|---|
| APIとetcdは健全、途中コマンドのみ失敗 | ログと現行構成を保全し、公式再実行条件を管理者が判断 |
| etcdやControl Planeに重大な異常 | 次Node更新を止め、構成とquorumに合う検証済み復旧計画を起動 |
| kubelet/CRI/CNIのNode局所障害 | 該当Nodeのsystemd・コンテナランタイム・CNIログで切り分け |
| 復元点またはバックアップの整合性が不明 | 旧etcdを直接上書きしない。業務責任者とRPO/RTOを確認しエスカレーション |
関連記事と一次資料
更新前の確認チェックを開く （任意・作業メモ作成）
更新前リスクをチェックして、作業メモを作る
構成・停止条件・復旧準備とNode退避・etcdを確認。未確認事項と次に読む説明を整理し、チェック結果をテキスト保存できます。実機診断や更新の実行許可ではありません。
ブラウザ内で判定し、入力内容をこの機能から外部送信・自動保存しません。機密情報は入力しないでください。