k3s崩壊の記事を追加

content/posts/2025-06-01/index.md

@@ -1,104 +0,0 @@
----
-author: usbharu
-draft: false
-categories:
-  - null
-date: 2025-06-01T12:33:00+09:00
-tags:
-  - null
-keywords:
-  - null
-title: 知っておいて欲しい順 開発に関すること
-relpermalink: posts/2025-06-01/
-url: posts/2025-06-01/
-decription: TBD
----
-
-謎のモチベーションが湧いてきたので、なんとなく書いてみることにしました。基本的に概念の把握のため、正確さを落としています。
-
-## Git・バージョン管理
-
-有名なバージョン管理システム。
-まず、ここで言うバージョン管理というのは
-
-```
-2024年4月用企画書1_最終版_誤字修正済み(1)のコピー.docx
-2024年4月用企画書1_最終版_本当に最終版.docx
-2024年4月用企画書2コピー（1）最新版.docx
-```
-や、![WordのUndoとRedoボタン](image.png)
-のようにファイルのバージョンを管理することです。
-
-でも上の例ではどれが最新版なのか、どれを編集すれば良いのか、どれが最終的に使われるファイルか分かりません。そもそもプログラミングではファイル名に制約があったり、同じような内容が書かれているファイルが複数あったらエラーになるかもしれません[^1]。
-
-[^1]: 例えばJavaなら、同じクラスが複数あったらエラーになりますね。
-
-バージョン管理システムはこれらを機械的に処理し、チームで共有できるようにしたものです。おもに以下の概念を覚えておくと良いと思います。
-
-### コミット・チェックポイント
-
-ユーザーが任意のタイミングでチェックポイントのようなもの[^2]を作成し、チェックポイントの履歴をプロジェクトごと[^3]に自由に巻き戻す事ができます。
-
-[^2]: コミット(Commit)と呼びます。
-
-[^3]: 正確にはプロジェクトごとではなく、リポジトリ(Repository)ごとです。1プロジェクトに複数リポジトリが関わることも、その逆もあります。
-
-### ブランチ・分岐
-
-また履歴の分岐[^4]を作成し、チームメンバーがそれぞれの分岐で作業することで、複数人が別の機能を同時に開発することができます。
-
-[^4]: ブランチ(Branch)と呼びます。
-
-### マージ・分岐の結合
-
-分岐をいい感じに結合し、複数人が同時に開発した別の機能をまとめて最新のチェックポイントとして作成する[^5]ことができます。いい感じに結合できなかった場合、コンフリクト(Conflict/競合)が発生し、手動で治す必要があります。
-
-[^5]: マージ(Merge)と呼びます。
-
-### Git
-
-現在デファクトスタンダードになっているバージョン管理システムです。
-
-[サル先生のGit入門〜バージョン管理を使いこなそう〜【プロジェクト管理ツールBacklog】](https://backlog.com/ja/git-tutorial/) https://backlog.com/ja/git-tutorial/
-
-## GitHub・Gitサーバー
-
-[Git](#git)をチームで共有するには、Gitサーバーが必要です。また、[マージ](#マージ・分岐の結合)を行うため、誰かのGitに[分岐](#ブランチ・分岐)の[履歴](#コミット・チェックポイント)全部を送りつける必要があります。Gitサーバーはプロジェクトに存在する履歴と分岐を、1箇所で管理する保存場所のような場所です。
-
-### プル・分岐の履歴のダウンロード
-
-まずの分岐の履歴ダウンロード[^6]を行い、他のチームメンバーとスタート地点を合わせます。
-
-[^6]: プル(Pull)と呼びます。
-
-### プッシュ・分岐の履歴のアップロード
-
-開発を進めていき、[コミット](#コミット・チェックポイント)がいくつかできたところで機能が完成したとします。完成した機能を他のチームメンバーと共有、[マージ](#マージ・分岐の結合)するため、機能を開発していた分岐の履歴をGitサーバーにアップロード[^7]します。
-
-[^7]: プッシュ(Push)と呼びます。
-
-### プルリクエスト・Gitサーバーでのマージ
-
-プルリクやPull Request、PRと呼ばれたり、マージリクエストと呼ばれたりもしますが、要はGitサーバーにアップロードした分岐の履歴(ブランチ)をマージする準備のことです。
-
-プッシュされ、Gitサーバー上に存在する[ブランチ](#ブランチ・分岐)(分岐の履歴)を本流のブランチ[^8]にマージするため、様々なチェックなどを行います。([レビュー](#レビュー))
-
-[^8]: 開発時点での最新版、最終的にすべてのブランチがマージされてくる大もとのブランチで、develop、main、masterなどがよく使われます。
-
-### GitHub
-
-有名なGitサーバーです。[CI](#ci)/[CD](#cd)や[レビュー](#レビュー)に必要な環境が整っています。
-
-[GitHub](https://github.com/) https://github.com/
-
-## テスト
-
-## フォーマッター・Formatter
-
-## リンター・Linter
-
-## CI
-
-## CD
-
-## レビュー

content/posts/2025-07-10/index.md

@@ -0,0 +1,49 @@
+---
+author: usbharu
+draft: false
+categories:
+  - 技術
+date: 2025-07-10T01:08:10+09:00
+tags:
+  - k3s
+  - Proxmox
+keywords:
+  - k3s
+  - Proxmox
+title: k3sのクラスタが大崩壊を起こしたときの復旧メモ
+relpermalink: posts/2025-07-10/
+url: posts/2025-07-10/
+decription: k3sのクラスタが大崩壊を起こしたときの復旧メモ
+---
+
+先日k3sのクラスタが暴走(?)し、VMがハング、なぜか同時にホストマシンのProxmoxの管理画面もフリーズし、無事クラスタの大崩壊が発生しました。監視基板ごと死んだのかアラート等が一切出ずメトリクス等も消えたため、原因は不明です。
+
+それはさておき、こんな構成のk3sクラスタがあります。
+
+- HA構成
+- server(コントロールプレーン+Worker) 3台
+- 内2台がRyzen機 残りがN150機
+- 各k3sはProxmox上のVMに構築
+
+今回はRyzen機に乗っている2つのk3sノードが死にました。残っている一つのクラスタからetcdとかをいい感じにする必要があります。
+
+## k3sのetcdスナップショットからの復元
+
+https://docs.k3s.io/ja/cli/etcd-snapshot
+
+基本的におせっかい機能しかないk3sやmicrok8sですが、今回はそれに救われました。
+
+
+生きているノードで以下を実行します。
+
+```bash
+k3s server --cluster-reset --cluster-reset-restore-path=/var/lib/rancher/k3s/server/db/snapshots/<スナップショットファイル>
+```
+
+とりあえずこれでk3sのetcdに関するエラーは直ると思います。
+
+## k3sのクラスター復旧
+
+これは普通にk3sのHA構成のときの新しいノード追加方法と同じで、serverを指定して追加していくだけです。
+
+https://docs.k3s.io/ja/datastore/ha-embedded