[{"data":1,"prerenderedAt":420},["ShallowReactive",2],{"blog-ja-k3s-helmchart-crd-manual-helm-upgrade-reconcile-revert":3,"blog-related-ja-k3s-helmchart-crd-manual-helm-upgrade-reconcile-revert":369,"blog-ja-k3s-helmchart-crd-manual-helm-upgrade-reconcile-revert-alt":357},{"id":4,"title":5,"author":6,"body":7,"date":351,"description":352,"extension":353,"image":354,"locale":355,"meta":356,"navigation":357,"path":358,"seo":359,"stem":360,"tags":361,"__hash__":368},"blog\u002Fblog\u002Fja\u002Fk3s-helmchart-crd-manual-helm-upgrade-reconcile-revert.md","K3sのHelmChart CRDで配ったアプリを直接helm upgradeしたら、次のreconcileで設定が消えた","Kubo Team",{"type":8,"value":9,"toc":340},"minimark",[10,15,24,31,43,54,58,69,92,98,115,119,137,150,156,173,180,184,193,218,222,225,267,273,282,286,293,300,312,316,328],[11,12,14],"h2",{"id":13},"_1-本番でhelmリリースを直接upgradeしたら翌朝設定が消えていた","1. 本番でHelmリリースを直接upgradeしたら、翌朝設定が消えていた",[16,17,18,19,23],"p",{},"K3sクラスタ上でHelmChart CRDから配布していたアプリケーションに、緊急のパラメータ変更が必要になった。",[20,21,22],"code",{},"helm upgrade --set"," で直接値を書き換え、Podが正しい設定で立ち上がったことを確認して作業を終えた。",[16,25,26],{},[27,28],"img",{"alt":29,"src":30},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-helmchart-crd-manual-helm-upgrade-reconcile-revert\u002Fsection01.webp",[16,32,33,34,37,38,42],{},"ところが翌朝、ノードの定期メンテナンスでクラスタが再起動した後、設定は昨日のupgrade前の状態に戻っていた。",[20,35,36],{},"helm history"," を見てもリビジョンは上がっているのに、実際に動いているPodの中身は古いままだった。K3sとKubernetesの違いを調べていくと、原因は自分のミスではなく、",[39,40,41],"strong",{},"K3sだけに存在する「HelmChart CRD」という自動化レイヤー","にあることが分かった。",[16,44,45,46,53],{},"こうした「クラスタが裏で何を自動化しているか分からない」という不安は、K3sベースのマネージドサービスを選ぶときにも見落とされがちな観点だ。",[47,48,52],"a",{"href":49,"rel":50},"https:\u002F\u002Fkubo.hexabase.io\u002F",[51],"nofollow","Kubo","のように運用の透明性を訴求するサービスもあるが、まずはK3s自体の仕組みを理解しておく必要がある。",[11,55,57],{"id":56},"_2-k3sだけに存在する3層構造-helmchart-crd-helm-controller-kubernetes-job","2. K3sだけに存在する3層構造: HelmChart CRD → helm-controller → Kubernetes Job",[16,59,60,61,64,65,68],{},"vanilla Kubernetesで ",[20,62,63],{},"helm install"," を使う場合、Helmクライアントがチャートをレンダリングし、Kubernetes APIに直接リソースを作成する。そこには「宣言的な監視者」は存在せず、次に誰かが ",[20,66,67],{},"helm upgrade"," するまで状態は変わらない。",[16,70,71,72,75,76,81,82,85,86,91],{},"K3sはこれとは別に、独自の",[39,73,74],{},"Helm Controller","を同梱している。",[47,77,80],{"href":78,"rel":79},"https:\u002F\u002Fdocs.k3s.io\u002Fadd-ons\u002Fhelm",[51],"K3sの公式ドキュメント","によれば、K3sは ",[20,83,84],{},"HelmChart"," というCustom Resource Definition（CRD）を使って、Helmチャートのインストール・アップグレード・アンインストールを宣言的に管理する仕組みを持つ。組み込みのTraefikやServiceLBだけでなく、",[47,87,90],{"href":88,"rel":89},"https:\u002F\u002Foneuptime.com\u002Fblog\u002Fpost\u002F2026-03-20-k3s-auto-deploying-helm-charts\u002Fview",[51],"任意の自作Helmチャートをこの仕組みで自動デプロイすることもできる","。",[16,93,94],{},[27,95],{"alt":96,"src":97},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-helmchart-crd-manual-helm-upgrade-reconcile-revert\u002Fsection02.webp",[16,99,100,101,106,107,110,111,114],{},"つまりK3sでは「HelmChart CRD（宣言）→ helm-controller（監視）→ Kubernetes Job（実行）」という3層構造がバックグラウンドで常に動いている。",[47,102,105],{"href":103,"rel":104},"https:\u002F\u002Fgithub.com\u002Fk3s-io\u002Fhelm-controller\u002Fblob\u002Fmaster\u002Fdoc\u002Fhelmchart.md",[51],"k3s-io\u002Fhelm-controllerのフィールドリファレンス","には ",[20,108,109],{},"chartContent"," や ",[20,112,113],{},"valuesContent"," など多数の設定項目があるが、「CRDの外側で加えられた変更がどう扱われるか」については明記されていない。これがトラブルの温床になる。",[11,116,118],{"id":117},"_3-何が起きていたか-failurepolicyとjobの再実行トリガー","3. 何が起きていたか: failurePolicyとJobの再実行トリガー",[16,120,121,106,125,128,129,132,133,136],{},[47,122,124],{"href":78,"rel":123},[51],"K3s公式ドキュメント",[20,126,127],{},"failurePolicy"," という設定があり、デフォルトは ",[20,130,131],{},"\"reinstall\""," となっている。これはJobが失敗と判定された場合に、クリーンなアンインストール→再インストールを自動実行する挙動だ。",[20,134,135],{},"\"abort\""," に切り替えない限り、helm-controllerは「desired state（HelmChart CRDの内容）」と「actual state（クラスタの実際の状態)」の差分を検知するたびに、Helm操作を伴うJobを再実行する。",[16,138,139,140,145,146,149],{},"この挙動は実際に複数の障害報告として上がっている。",[47,141,144],{"href":142,"rel":143},"https:\u002F\u002Fgithub.com\u002Fk3s-io\u002Fhelm-controller\u002Fissues\u002F50",[51],"k3s-io\u002Fhelm-controllerのIssue #50","では、チャートのバージョンが変わっていないにもかかわらず、helm-controllerが繰り返しinstall Jobを再トリガーし、新しいリビジョンを生成し続けるという事象が報告されている。ログには ",[20,147,148],{},"DesiredSet - Replace Wait batch\u002Fv1, Kind=Job"," という記録が残り、コントローラーがJobリソースの置き換えを継続的に検知していたことが分かる。",[16,151,152],{},[27,153],{"alt":154,"src":155},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-helmchart-crd-manual-helm-upgrade-reconcile-revert\u002Fsection03.webp",[16,157,158,159,164,165,168,169,172],{},"さらに",[47,160,163],{"href":161,"rel":162},"https:\u002F\u002Fgithub.com\u002Fk3s-io\u002Fk3s\u002Fissues\u002F2893",[51],"k3s-io\u002Fk3sのIssue #2893","では、",[20,166,167],{},"HelmChartConfig"," でTraefikのカスタム設定（ダッシュボード有効化やTLS設定）を加えていたユーザーが、「K3sやホストを再起動するたびに、このカスタマイズが読み込まれず、デフォルト設定が適用される」と報告している。この報告では、マニフェストファイルに空白や改行を加えて強制的に再読込させることで一時的に回避したとされている。手動での ",[20,170,171],{},"kubectl edit"," はこの3層構造から見れば「一時的にしか残らない差分」でしかない。",[16,174,175,176,179],{},"このJobの再実行トリガーを管理画面上で追えるかどうかは、運用のしやすさに直結する。",[47,177,52],{"href":49,"rel":178},[51],"のCaptain UIは、こうしたバックグラウンドで動くJobやHelmリリースの状態を可視化する機能を持ち、「気づいたら設定が戻っていた」状態を減らす方向で設計されている。",[11,181,183],{"id":182},"_4-落とし穴その2-helmchartconfigを消してもロールバックされないリソースがある","4. 落とし穴その2: HelmChartConfigを消してもロールバックされないリソースがある",[16,185,186,187,192],{},"さらに厄介なのは、reconcileの挙動が全てのリソース種別で一貫していない点だ。",[47,188,191],{"href":189,"rel":190},"https:\u002F\u002Fgithub.com\u002Fk3s-io\u002Fk3s\u002Fissues\u002F5534",[51],"k3s-io\u002Fk3sのIssue #5534","では、TraefikのポートをHelmChartConfigでカスタムポート（1234\u002F5555）に変更した後、そのHelmChartConfigを削除しても、LoadBalancerタイプのServiceとklipper-lb Podはカスタム値のまま元に戻らなかったと報告されている。",[16,194,195,196,201,202,207,208,211,212,217],{},"つまり「HelmChartConfigを外せば必ず元通りになる」という前提も安全ではない。",[47,197,200],{"href":198,"rel":199},"https:\u002F\u002Fforums.suse.com\u002Ft\u002Fk3s-traefik-configuration-override-problems\u002F37264",[51],"SUSEコミュニティフォーラム","や",[47,203,206],{"href":204,"rel":205},"https:\u002F\u002Fgithub.com\u002Fk3s-io\u002Fk3s\u002Fdiscussions\u002F11176",[51],"k3s-io\u002Fk3sのDiscussion #11176","にも「HelmChartConfigを当てたのに反映されない、あるいは想定通りに戻らない」という相談が繰り返し寄せられている。K3sのHelm Controllerは起動時に ",[20,209,210],{},"\u002Fvar\u002Flib\u002Francher\u002Fk3s\u002Fserver\u002Fmanifests\u002F"," を監視してJobを生成する仕組みであり、姉妹プロジェクトである",[47,213,216],{"href":214,"rel":215},"https:\u002F\u002Fdocs.rke2.io\u002Fadd-ons\u002Fhelm",[51],"RKE2の公式ドキュメント","でも「manifestsディレクトリ配下のマニフェストはAddOnカスタムリソースとして自動デプロイされる」と同様の仕組みが説明されている。それでもなお、リソース種別ごとの差分検知ロジックが必ずしも直感的ではない。",[11,219,221],{"id":220},"_5-正しい直し方-helmchartconfig経由の変更とfailurepolicy-abort","5. 正しい直し方: HelmChartConfig経由の変更とfailurePolicy: abort",[16,223,224],{},"この構造を踏まえると、K3s上でHelmChart CRD管理下のアプリやアドオンを変更する際のルールは明確になる。",[226,227,228,239,251,261],"ul",{},[229,230,231,238],"li",{},[39,232,233,110,235,237],{},[20,234,171],{},[20,236,22],{}," で直接変更しない","。次のreconcileで消える前提で考える",[229,240,241,250],{},[39,242,243,244,246,247,249],{},"変更は必ず ",[20,245,167],{}," の ",[20,248,113],{}," 経由で行う","。これは helm-controller が正式な入力として認識するため、reconcileされても消えない",[229,252,253,260],{},[39,254,255,256,259],{},"意図しない自動再インストールを避けたい場合は ",[20,257,258],{},"failurePolicy: abort"," を設定する","。失敗時にクリーン再インストールせず、失敗状態のまま止めて手動介入を待つようになる",[229,262,263,266],{},[39,264,265],{},"HelmChartConfigを削除するときは、対象リソースが実際に既定値へ戻るか個別に確認する","（Issue #5534のように戻らないリソース種別があるため）",[16,268,269],{},[27,270],{"alt":271,"src":272},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-helmchart-crd-manual-helm-upgrade-reconcile-revert\u002Fsection04.webp",[16,274,275,276,281],{},"これはK3sを「軽量なKubernetes」としてだけ理解していると見落としがちな挙動だ。",[47,277,280],{"href":278,"rel":279},"https:\u002F\u002Fgithub.com\u002Fk3s-io\u002Fhelm-controller\u002Fissues\u002F351",[51],"k3s-io\u002Fhelm-controllerのIssue #351","でも、reconcileロジック自体の改善要望が継続的に議論されており、この構造は今後も注意深く付き合っていく必要がある領域だと分かる。",[11,283,285],{"id":284},"_6-kuboならどうなるか","6. Kuboならどうなるか",[16,287,288,289,292],{},"K3sベースの",[47,290,52],{"href":49,"rel":291},[51],"を使っていても、このHelmChart CRDの仕組み自体は同じK3sの標準機能として存在する。違いは、この「見えない自動化レイヤー」がブラックボックスのまま放置されるか、可視化された状態で運用できるかだ。",[16,294,295,296,299],{},"Kubo Captain UIは、クラスタ内で自動的に走っているHelm ChartやJobの状態を管理画面上で確認できるように設計されており、「知らないうちにreconcileが走って設定が戻っていた」という事態に気づきやすくする。EKSやAKSでは触れないK3s内部の自動化を、",[47,297,52],{"href":49,"rel":298},[51],"ならブラックボックスにせず運用できる。",[16,301,302,303,305,306,311],{},"また、Air-Gapped環境で ",[20,304,210],{}," の手動編集すら難しい金融・医療・製造業向けには、",[47,307,310],{"href":308,"rel":309},"https:\u002F\u002Fwww.hexabase.com\u002Fproduct\u002Fkubo\u002Fon-premise",[51],"Kubo On-Premise","が「Your Infrastructure. Your Rules.」の思想でこの運用課題に向き合う選択肢になる。",[11,313,315],{"id":314},"_7-まとめ","7. まとめ",[16,317,318,319,322,323,110,325,327],{},"K3sとKubernetesの違いは、レプリカセットやネットワーキングの実装だけではない。K3sが同梱する",[39,320,321],{},"HelmChart CRD + helm-controller + Kubernetes Job","という3層の自動化構造は、vanilla Kubernetesには存在しない独自レイヤーであり、これを知らずに ",[20,324,171],{},[20,326,67],{}," で直接変更すると、次のreconcileで静かに元へ戻される。",[16,329,243,330,332,333,335,336,339],{},[20,331,167],{}," 経由で行い、",[20,334,127],{}," の挙動を理解した上で運用する。それがK3sクラスタを安定して本番運用するための最初の一歩だ。この自動化レイヤーを可視化しながら運用したいなら、",[47,337,52],{"href":49,"rel":338},[51],"のCaptain UIも選択肢に入れてみてほしい。",{"title":341,"searchDepth":342,"depth":342,"links":343},"",2,[344,345,346,347,348,349,350],{"id":13,"depth":342,"text":14},{"id":56,"depth":342,"text":57},{"id":117,"depth":342,"text":118},{"id":182,"depth":342,"text":183},{"id":220,"depth":342,"text":221},{"id":284,"depth":342,"text":285},{"id":314,"depth":342,"text":315},"2026-09-29","K3sとKubernetesの違いは機能一覧だけでは分からない。HelmChart CRDという自動化レイヤーが、手動でのhelm upgradeやkubectl editを静かに巻き戻す仕組みと回避策を解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-helmchart-crd-manual-helm-upgrade-reconcile-revert\u002Ftitle.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fk3s-helmchart-crd-manual-helm-upgrade-reconcile-revert",{"title":5,"description":352},"blog\u002Fja\u002Fk3s-helmchart-crd-manual-helm-upgrade-reconcile-revert",[362,363,364,365,366,367],"k3s","kubernetes","helm-controller","helmchart-crd","gitops","reconcile","0qO8Uv3Qh-68dg7qOzaQZCRiajhfZwTf0UM93dORSrI",[370,379,388,396,403,411],{"path":371,"title":372,"description":373,"date":374,"tags":375},"\u002Fblog\u002Fja\u002Fk3s-sealed-secrets-gitops-rebuild-private-key-lost","GitOpsで全部コード化してたのに。K3sクラスタを作り直したら、Sealed Secretsが一つも復号できなくなった理由","K3sクラスタをGitOpsで再構築したらSealed Secretsが全て復号できない状態に陥った。原因は秘密鍵の扱いにある。障害の仕組みと復旧手順、再発防止の運用設計を解説する。","2026-10-15",[362,363,376,377,366,378],"sealed-secrets","secrets-management","disaster-recovery",{"path":380,"title":381,"description":382,"date":383,"tags":384},"\u002Fblog\u002Fja\u002Fcicd-pipeline-devsecops-gate-design-four-layers","そのCI\u002FCDパイプライン、セキュリティチェックをどこに置くか決めずに継ぎ足していないか。DevSecOpsゲート設計の4層モデル","SASTもDASTもコンテナスキャンも導入した。それでも本番で事故は起きる。CI\u002FCDパイプラインのセキュリティを『4つの層』で設計し直すDevSecOpsゲート設計の考え方を、K3s\u002FKubernetes運用の観点から解説する。","2026-08-28",[362,363,385,386,387,366],"ci-cd","devsecops","admission-control",{"path":389,"title":390,"description":391,"date":392,"tags":393},"\u002Fblog\u002Fja\u002Fkubernetes-gitops-branch-antipattern-fleet-scaling","そのdev\u002Fstaging\u002Fprodブランチ、実は時限爆弾。KubernetesのGitOpsが壊れる本当の理由","dev\u002Fstaging\u002FproductionをGitブランチで分けるGitOps運用は、実はKubernetesの宣言的インフラの前提を壊すアンチパターンだ。ドリフトが起きる理由とディレクトリ構成・トランクベース運用への移行手順、フリート規模での崩壊を防ぐ設計を解説する。","2026-08-10",[362,363,366,394,395],"argocd","devops",{"path":397,"title":398,"description":399,"date":400,"tags":401},"\u002Fblog\u002Fja\u002Fkubernetes-image-signing-sigstore-supply-chain","イメージタグは誰でも書き換えられる。Kubernetesのイメージ署名にSigstoreで『来歴』を刻むという発想","コンテナイメージ署名の仕組みを解説。イメージタグは誰でも書き換え可能で、CI\u002FCDのテストを通過した保証にはならない。SigstoreとKyvernoを組み合わせ、Kubernetes\u002FK3s上で未署名イメージの起動を拒否する防御層を構築する方法を、GitOps運用との統合も含めて紹介する。","2026-08-06",[362,363,385,366,402],"security",{"path":404,"title":405,"description":406,"date":407,"tags":408},"\u002Fblog\u002Fja\u002Fk3s-edge-fleet-declarative-management","1台のトラブルシューティングは笑い話で済む。それが1000台なら経営リスクになる。K3sエッジ運用を属人化から救うRancher Fleetという選択肢","K3sエッジ運用のフリート管理は、1台ずつの手作業トラブルシューティングでは破綻する。宣言的管理とRancher Fleetの仕組みから、属人化しないエッジ運用の設計を解説する。","2026-08-03",[362,363,409,366,410],"edge-computing","fleet-management",{"path":412,"title":413,"description":414,"date":415,"tags":416},"\u002Fblog\u002Fja\u002Fplatform-engineering-kubernetes-idp-managed-k3s","生のKubernetesを渡すな。プラットフォームエンジニアリングという“隠す”設計思想と、Kuboという答え","プラットフォームエンジニアリングとKubernetesの関係を解説。開発者にK8sの複雑さを直接渡さない設計思想、IDP構築の3本柱、そしてマネージドK3sという選択肢を紹介する。","2026-07-16",[363,362,417,418,366,419],"platform-engineering","internal-developer-platform","managed-kubernetes",1792592605936]