[{"data":1,"prerenderedAt":1155},["ShallowReactive",2],{"blog-index-ja":3},[4,16,26,36,46,55,64,72,81,90,98,107,115,123,132,141,150,158,166,175,183,193,203,211,218,227,236,245,252,260,269,276,282,291,301,310,321,330,339,346,355,364,372,381,391,398,407,415,423,432,442,452,461,467,474,483,492,502,510,519,526,532,540,549,556,564,571,578,586,595,605,611,618,624,632,639,647,654,660,667,675,681,687,694,701,707,714,721,728,736,743,750,756,763,772,779,785,793,801,809,816,823,829,836,843,850,857,865,874,880,887,895,902,910,917,924,931,938,946,956,964,974,982,991,998,1004,1010,1019,1026,1037,1044,1052,1061,1071,1077,1084,1093,1101,1111,1121,1131,1139,1148],{"path":5,"title":6,"description":7,"date":8,"tags":9},"\u002Fblog\u002Fja\u002Fk3s-ai-agent-audit-log-traceability-gap","AIエージェントがKubernetes APIを叩いた後、何をしたのか追えなかった。Audit Logの設定に空いていた穴","AIエージェントをKubernetes上で動かし始めたら、トラブル発生時にAudit Logだけでは「誰が・何の目的で」操作したのか追えないことに気づいた。Audit Policyの盲点とトレーサビリティ確保の実践を解説する。","2026-11-09",[10,11,12,13,14,15],"k3s","kubernetes","ai-agent","audit-log","rbac","observability",{"path":17,"title":18,"description":19,"date":20,"tags":21},"\u002Fblog\u002Fja\u002Fk3s-kubelet-eviction-inode-exhaustion-diskpressure","K3sでPodが次々Evictedされた。ディスクは余っているのにinodeだけ枯渇していた","K3sでPodが次々Evictedされ、df -hは正常なのに復旧しない。原因はディスク容量ではなくinode枯渇だった。kubeletのeviction閾値とdf -iでの診断、再発防止策を解説する。","2026-11-08",[10,11,22,23,24,25],"kubelet","eviction","diskpressure","troubleshooting",{"path":27,"title":28,"description":29,"date":30,"tags":31},"\u002Fblog\u002Fja\u002Fk3s-cilium-kube-proxy-replacement-nodeport-unreachable","K3sでCiliumのkube-proxy置き換えをしたら、NodePortだけ繋がらなくなった","K3sにCiliumのkube-proxy replacementを公式手順通りに導入したら、NodePort経由の通信だけが届かなくなった。原因はFlannelやServiceLB(Klipper)との競合、k8sServiceHost未設定などK3s特有の設定差分にあった。本番投入前のチェックリストを解説。","2026-11-07",[10,11,32,33,34,35],"cilium","ebpf","kube-proxy","networking",{"path":37,"title":38,"description":39,"date":40,"tags":41},"\u002Fblog\u002Fja\u002Fk3s-memory-qos-cgroup-v2-memory-high-throttling","requestsもlimitsも正しいのに、K3sのPodが突然重くなった。犯人はOOMKillではなくcgroup v2のmemory.high早期スロットリングだった","K3sでrequests\u002Flimitsを正しく設定したPodが、OOMKilledイベントもなく突然重くなった謎を追った記録。原因はcgroup v2のmemory.highによる早期スロットリング。切り分け方法と対策を解説する。","2026-11-06",[10,11,42,43,44,45],"cgroup-v2","memory-qos","memory-high","resource-management",{"path":47,"title":48,"description":49,"date":50,"tags":51},"\u002Fblog\u002Fja\u002Fdocker-compose-k3s-local-path-provisioner-permission-denied","Docker Composeではそのまま動いていたボリュームが、K3sに持ち込んだ瞬間Permission deniedになった","Docker ComposeからK3sへ移行したら、ローカルでは問題なかったボリュームがPermission deniedになった。local-path-provisionerの仕様が原因。移行時の回避策を実例で解説。","2026-11-05",[10,11,52,53,54],"docker-compose","local-path-provisioner","persistent-storage",{"path":56,"title":57,"description":58,"date":59,"tags":60},"\u002Fblog\u002Fja\u002Fk3s-opencost-onprem-gcp-default-pricing","K3sのオンプレ環境にOpenCostを入れたら、コストは最初からGCPの値段で計算されていた","K3sのオンプレ・ベアメタル環境にOpenCostを導入しても、デフォルト設定のままではノードのCPU・RAMコストがGCP us-central1のクラウド料金で計算されてしまう。K3s環境で実際のハードウェアコストを正しく可視化するために必要なカスタム価格設定の手順と、見落としやすい理由を解説する。","2026-11-04",[10,11,61,62,63],"opencost","finops","cost-optimization",{"path":65,"title":66,"description":67,"date":68,"tags":69},"\u002Fblog\u002Fja\u002Fk3s-prometheus-agent-mode-stale-marker-edge-monitoring","K3sエッジのPrometheusをAgent modeにしたら、ターゲットが消えた瞬間にメトリクスも消えていた","K3sエッジクラスタでPrometheus Agent modeを使うと、ターゲット消失時のstale marker処理次第で中央監視に古い値が残り続けることがある。K3s edge環境の監視設計とつまずきポイントを解説する。","2026-11-03",[10,11,70,71,15],"prometheus","edge-computing",{"path":73,"title":74,"description":75,"date":76,"tags":77},"\u002Fblog\u002Fja\u002Fk3s-argocd-flux-traefik-outofsync-comparison","ArgoCD vs Flux、K3sのGitOpsで知るべき「Traefik OutOfSync」の罠","K3sでArgoCDとFluxのどちらを選ぶべきか迷う人向けに、UI・マルチクラスタ管理の機能差に加え、K3s標準搭載のTraefikがArgoCDで永続OutOfSyncになる実例と、FluxのHelmChart CRDがK3sと名前衝突する注意点を解説し、選定基準を示す。","2026-11-02",[10,11,78,79,80],"argocd","flux","gitops",{"path":82,"title":83,"description":84,"date":85,"tags":86},"\u002Fblog\u002Fja\u002Fk3s-mutatingadmissionpolicy-webhook-sidecar-injection","Webhookの証明書管理、もう要らない。MutatingAdmissionPolicyがK3sのサイドカー注入を変える","MutatingAdmissionPolicyがKubernetes v1.36でGAした。ラベル付与やサイドカー注入のための自作Mutating Webhookは、どこまでCELに置き換えられ、どこから先はWebhookのまま残すべきか。K3s運用での判断基準を整理する。","2026-11-01",[10,11,87,88,89],"mutatingadmissionpolicy","cel","admission-control",{"path":91,"title":92,"description":93,"date":94,"tags":95},"\u002Fblog\u002Fja\u002Fk3s-system-upgrade-controller-plan-stuck-node-drain","Planは消えずに残っていた。K3sのsystem-upgrade-controllerが止まり続けた理由","K3sのsystem-upgrade-controllerで自動アップグレードを組んだら、特定ノードだけPlanが進まなくなった。原因はPodDisruptionBudgetとtaintの盲点。仕組みと復旧手順、Kuboでの解決策を解説する。","2026-10-31",[10,11,96,97,71],"system-upgrade-controller","rolling-upgrade",{"path":99,"title":100,"description":101,"date":102,"tags":103},"\u002Fblog\u002Fja\u002Fk3s-spegel-embedded-registry-mirror-airgap-node-join","K3sの組み込みレジストリミラーが効いているはずなのに、新しいエッジノードだけimage pullに失敗した","K3sの組み込みレジストリミラー（Spegel）はクラスタ全体で有効なはずが、新規追加したエッジノードだけimage pullに失敗した。原因はregistries.yamlの未配布と認証ドリフト、containerd 2.0の既知バグ。エアギャップ運用の正しい配布手順を解説する。","2026-10-30",[10,11,104,105,106,71],"spegel","registry-mirror","airgap",{"path":108,"title":109,"description":110,"date":111,"tags":112},"\u002Fblog\u002Fja\u002Fk3s-microshift-etcd-ostree-edge-comparison","エッジでetcdを固定されるのは罠か前提か。K3sとMicroShift、OSTree自動ロールバックの代償を比較する","K3sとMicroShiftはどちらも「軽量Kubernetes」と語られるが、データストアとOS更新モデルの前提が根本的に違う。etcd固定とOSTree自動ロールバックの実態を比較し、エッジ本番運用でどちらを選ぶべきかを整理する。","2026-10-29",[10,113,11,71,114],"microshift","redhat",{"path":116,"title":117,"description":118,"date":119,"tags":120},"\u002Fblog\u002Fja\u002Fk3s-rootless-kubelet-user-namespace-k8s-137","KubeletInUserNamespaceがBetaになった日、K3sのRootless Modeは「時代遅れ」になったのか","Kubernetes 1.37でKubeletInUserNamespace(Rootless Mode)がBetaに昇格した。K3sは以前から独自のRootless Modeを持つが仕組みは全く別物だ。2つの方式の違いと、環境に応じた選び方を解説する。","2026-10-28",[10,11,121,122,22],"rootless","security",{"path":124,"title":125,"description":126,"date":127,"tags":128},"\u002Fblog\u002Fja\u002Fhpa-vpa-aep-5342-multidimensional-pod-autoscaler","HPAとVPAの併用問題、Kubernetes本体がAEP-5342で解決しようとしている。GKE版MPAとの違いとKuboで今できること","HPAとVPAの併用は長年危険とされてきたが、GKEのMultidimensional Pod AutoscalerとKubernetes本体のAEP-5342提案が解決の方向性を示し始めている。K3s\u002FKuboで今日から実践できる設計も解説する。","2026-10-27",[10,11,129,130,131],"hpa","vpa","autoscaling",{"path":133,"title":134,"description":135,"date":136,"tags":137},"\u002Fblog\u002Fja\u002Fkarpenter-cluster-autoscaler-k3s-bare-metal-limitations","Karpenterは使えない。K3sオンプレでノードオートスケーリングを選ぶ前に知るべき制約","KarpenterとCluster Autoscalerの比較記事はAWS前提ばかりだ。K3s・オンプレ・ベアメタル環境でノードオートスケーリングを検討する前に知っておくべき制約と、現実的な選択肢を解説する。","2026-10-26",[10,11,138,139,140,63],"karpenter","cluster-autoscaler","node-provisioning",{"path":142,"title":143,"description":144,"date":145,"tags":146},"\u002Fblog\u002Fja\u002Fk3s-vs-microk8s-ha-etcd-dqlite-edge-production","K3sとMicroK8s、同じ\"軽量\"でも本番で勝つのはどちらか。dqliteとetcdが分けるHA構成の分岐点","K3sとMicroK8s、同じ軽量Kubernetesでも本番運用の明暗を分けるのはHA構成だ。K3sのembedded etcdとMicroK8sのdqlite、それぞれの最小RAM要件・アーキテクチャの違いを公式ドキュメントのデータで比較し、選定基準を解説する。","2026-10-25",[10,147,11,148,71,149],"microk8s","high-availability","comparison",{"path":151,"title":152,"description":153,"date":154,"tags":155},"\u002Fblog\u002Fja\u002Fk3s-metrics-server-default-kubeadm-hpa-kubectl-top","kubectl topが無反応だった。原因はmetrics-server未導入、K3sでは起きない理由","kubectl topやHPAが突然動かなくなった時、まず疑うべきはmetrics-serverの有無だ。K3sに標準搭載されている理由と、標準Kubernetes(kubeadm)環境で必ず手動導入が必要になる技術的背景、障害発生時の切り分け手順までを公式ドキュメントベースで解説する。","2026-10-24",[10,11,156,129,157],"metrics-server","kubeadm",{"path":159,"title":160,"description":161,"date":162,"tags":163},"\u002Fblog\u002Fja\u002Fk3s-k8s-default-serviceaccount-automount-rbac-multi-tenant","K3sもKubernetesも\"デフォルトのServiceAccount\"が同じ罠を持っている。マルチテナント環境でautomountを放置すると何が起きるか","K3s vs K8sを比較しても、defaultのServiceAccountが抱えるautomountの罠は変わらない。マルチテナント環境での権限昇格リスクと、実際のCVEを交えた4層の対策を解説する。","2026-10-23",[10,11,14,164,165,122],"serviceaccount","multi-tenancy",{"path":167,"title":168,"description":169,"date":170,"tags":171},"\u002Fblog\u002Fja\u002Fk3s-containerd-v1-v2-patch-version-skew-policy","K3sの\"ただのパッチ\"アップデートで、containerd設定テンプレートが効かなくなった。v1→v2移行はバージョンスキューポリシーの外側で起きる","K3sのパッチリリースでcontainerdがv1からv2に切り替わり、カスタム設定テンプレートが効かなくなった実例から、Kubernetes公式のバージョンスキューポリシーが見ていない場所で起きる非互換変更を解説する。","2026-10-22",[10,11,172,173,174],"containerd","version-skew","patch-upgrade",{"path":176,"title":177,"description":178,"date":179,"tags":180},"\u002Fblog\u002Fja\u002Fk3s-hpa-containerresource-sidecar-utilization-dilution","HPAがサイドカーの分まで合算してスケールしていた。KubernetesのContainerResourceという盲点","KubernetesのHPAはPod内の全コンテナの使用量を合算して利用率を計算するため、Istioサイドカーやログエージェントの負荷が判定を薄める。ContainerResourceメトリクスで解決する方法をK3s\u002FKubo文脈で解説する。","2026-10-21",[10,11,129,181,131,182],"containerresource","service-mesh",{"path":184,"title":185,"description":186,"date":187,"tags":188},"\u002Fblog\u002Fja\u002Fk3s-vs-kubernetes-cni-flannel-default-comparison","K3s vs 標準Kubernetes、CNIの出発点はここまで違う。Flannel標準搭載とCNI選択制が生む差","K3sはFlannelをデフォルト同梱し、標準KubernetesはCNI未選定の状態から始まる。この出発点の違いがNetworkPolicyの可否や通信性能にどう影響するかを、K3s\u002FKubernetes\u002FCalico\u002FCiliumの公式ドキュメントをもとに比較・解説する。","2026-10-20",[10,11,189,190,191,32,192,35],"cni","flannel","calico","networkpolicy",{"path":194,"title":195,"description":196,"date":197,"tags":198},"\u002Fblog\u002Fja\u002Fk3s-topology-spread-constraints-poddisruptionbudget-node-drain-pending","ノードをdrainしたらPodがPendingのまま戻らなかった。K3sでTopology Spread ConstraintsとPodDisruptionBudgetが衝突する理由","K3s本番でノードをdrainしたら一部PodがPendingのまま戻らなかった。原因はTopology Spread ConstraintsのmaxSkewとPodDisruptionBudgetの衝突。drainがノード数不足を自ら作り出す仕組みを公式ドキュメントベースで検証する。","2026-10-19",[10,11,199,200,201,202],"topology-spread-constraints","poddisruptionbudget","scheduling","node-drain",{"path":204,"title":205,"description":206,"date":207,"tags":208},"\u002Fblog\u002Fja\u002Fkyverno-validatingadmissionpolicy-cel-migration-silent-bypass","CELに書き換えたポリシーは、本当に同じ意味なのか。KyvernoからValidatingAdmissionPolicyへの移行で\"黙って素通り\"したリソースの正体","KyvernoのClusterPolicyが廃止へ向かう中、ValidatingAdmissionPolicy（CEL）に移行したら一部リソースだけ検証が素通りしていた。原因のCELランタイムエラーとfailurePolicyの罠、安全な移行手順を解説する。","2026-10-18",[10,11,209,210,88,89],"validatingadmissionpolicy","kyverno",{"path":212,"title":213,"description":214,"date":215,"tags":216},"\u002Fblog\u002Fja\u002Fk3s-vpa-inplaceorrecreate-pod-resize-cgroup","VPAをInPlaceOrRecreateにしたのに、Podはまだ再起動していた。K3sでInPlacePodVerticalScalingの\"無停止\"を検証する","VPAのInPlaceOrRecreateモードとIn-Place Pod ResizeでPodは本当に再起動しないのか。K3s環境でQoSクラス制約とcgroup v1の罠を実際の設定例とkubectlコマンドで検証する。","2026-10-17",[10,11,130,131,217],"cgroup",{"path":219,"title":220,"description":221,"date":222,"tags":223},"\u002Fblog\u002Fja\u002Fk3s-pod-security-admission-restricted-servicelb-outage","restrictedを有効にしたらServiceLBが死んだ。K3sのPod Security Admissionに潜む、汎用ガイドにない設定差分","K3sでPod Security Admissionのrestrictedプロファイルを有効化したら、標準Kubernetesのガイド通りに進めたのにServiceLBが機能停止した。原因と安全な導入手順をK3s公式ハードニングガイドの記述とともに解説する。","2026-10-16",[10,11,224,225,226,122],"pod-security-admission","pod-security-standards","servicelb",{"path":228,"title":229,"description":230,"date":231,"tags":232},"\u002Fblog\u002Fja\u002Fk3s-sealed-secrets-gitops-rebuild-private-key-lost","GitOpsで全部コード化してたのに。K3sクラスタを作り直したら、Sealed Secretsが一つも復号できなくなった理由","K3sクラスタをGitOpsで再構築したらSealed Secretsが全て復号できない状態に陥った。原因は秘密鍵の扱いにある。障害の仕組みと復旧手順、再発防止の運用設計を解説する。","2026-10-15",[10,11,233,234,80,235],"sealed-secrets","secrets-management","disaster-recovery",{"path":237,"title":238,"description":239,"date":240,"tags":241},"\u002Fblog\u002Fja\u002Fk3s-velero-backup-restore-local-path-provisioner-empty-pvc","毎晩\"Completed\"と出ていたVeleroのバックアップ。K3sでリストアしたらPVCが空だった理由","K3s標準のlocal-path-provisionerはCSIスナップショット非対応。Veleroのバックアップが\"Completed\"でも、障害時のリストアでPVCが空になることがある。原因の切り分けとFile System Backup・リストアドリルによる対策を解説する。","2026-10-13",[10,11,242,243,235,244],"velero","backup","csi",{"path":246,"title":247,"description":248,"date":249,"tags":250},"\u002Fblog\u002Fja\u002Fk3s-hpa-prometheus-adapter-discovery-interval-stale-metrics","discoveryIntervalを疑え。K3sのHPAがPrometheus Adapter経由で\"古いメトリクス\"を掴み続ける設定ミス","K3sのHPAがCPU使用率は正常なのにスケールしない。原因はPrometheus Adapterのmetrics-relist-interval\u002Fmetrics-max-ageとHPA sync-periodが噛み合っていない設定ミスだった。3層の遅延構造と診断コマンドを解説する。","2026-10-12",[10,11,129,251,131,15],"prometheus-adapter",{"path":253,"title":254,"description":255,"date":256,"tags":257},"\u002Fblog\u002Fja\u002Fkyverno-opa-gatekeeper-k3s-wildcard-policy-overhead","KyvernoとOPA Gatekeeper、K3sの本番で本当に差が出たのはワイルドカードポリシーだった","KyvernoとOPA GatekeeperはK3sの本番運用でどちらを選ぶべきか。ワイルドカードポリシーが招く負荷急増とレプリカ構成別のp99レイテンシ実測データから、K3s特有の判断基準を整理する。","2026-10-11",[10,11,210,258,89,259],"opa-gatekeeper","policy-as-code",{"path":261,"title":262,"description":263,"date":264,"tags":265},"\u002Fblog\u002Fja\u002Fk3s-ingress-gateway-api-migration-traefik-gap","Ingressはもう終わる。Gateway APIに移行したら、K3sのTraefikは半分しか乗り換えられなかった","K3s Gateway API 移行を試みると、標準搭載のTraefikでもCRD未導入・Canary設定の作り直し・証明書連携の見直しが必要になる。2026年のingress-nginx退役とKubernetes 1.36移行を踏まえ、K3s特有の落とし穴と実務対応をまとめた。","2026-10-10",[10,11,266,267,268,35],"gateway-api","traefik","ingress",{"path":270,"title":271,"description":272,"date":273,"tags":274},"\u002Fblog\u002Fja\u002Fk3s-kubeadm-ha-etcd-failover-rto-gap","RTO30秒のはずが3分止まった。K3sとkubeadmのHA構成で\"カタログ値\"と\"実運用\"がズレる理由","K3sのembedded etcdとkubeadmのstacked\u002Fexternal etcd、HA構成のフェイルオーバーは実際どれだけ時間がかかるのか。公式ドキュメントのRTO目安と実運用の体感時間のギャップを、障害ドメインの分離・必要ノード数の違いから検証する。","2026-10-09",[10,11,275,148,157],"etcd",{"path":277,"title":278,"description":279,"date":280,"tags":281},"\u002Fblog\u002Fja\u002Fkubernetes-hpa-vpa-autoscaling-conflict-design","\"両方入れれば安心\"が一番危ない。KubernetesでHPAとVPAを併用するとスケーリングが暴走する理由","KubernetesでHPAとVPAを両方有効にすると、良かれと思った自動化同士が干渉し、スケーリングが際限なく暴走することがある。衝突が起きる仕組みと、updateModeやメトリクス分離による安全な併用設計を解説する。","2026-10-07",[10,11,129,130,131],{"path":283,"title":284,"description":285,"date":286,"tags":287},"\u002Fblog\u002Fja\u002Fk3s-rke2-migration-production-downtime-cis-ha","K3sをRKE2に移行して本番が2時間止まった。\"軽量K8s\"選定で見落とされがちな前提","K3s vs RKE2の選定で見落とされがちな前提を、実際の移行障害事例とCIS Hardening・HA構成・ストレージ設計の違いから整理し、本番環境でどちらのKubernetesディストリビューションを選ぶべきか判断基準を具体的に解説する。","2026-10-05",[10,288,11,289,148,290],"rke2","cis-benchmark","production-kubernetes",{"path":292,"title":293,"description":294,"date":295,"tags":296},"\u002Fblog\u002Fja\u002Fk3s-kubeadm-memory-benchmark-datastore-comparison","「K3sは軽い」は本当か。Kubernetes標準(kubeadm)とメモリ使用量を実測したら、結果が割れた","K3sは本当に軽いのか。Kubernetes標準のkubeadmとコントロールプレーンのメモリ・CPU使用量を公式データと複数の独立ベンチマークで比較。データストア選択(etcd\u002FSQLite)次第で結果が逆転する理由を解説する。","2026-10-04",[10,11,157,297,298,299,300],"resource-profiling","memory-benchmark","control-plane","datastore-comparison",{"path":302,"title":303,"description":304,"date":305,"tags":306},"\u002Fblog\u002Fja\u002Fk3s-keda-hpa-event-driven-autoscaling-decision","CPU使用率は正常なのにリクエストが詰まる。KubernetesでHPAにKEDAを足すべきタイミング","KEDAとHPAはどちらか一方を選ぶものではない。K3s\u002FKubernetesでイベント駆動ワークロードが増えたとき、HPAだけで限界に達する理由とKEDAを併用する判断基準を解説する。","2026-10-03",[10,11,307,129,131,308,309],"keda","event-driven-scaling","scaledobject",{"path":311,"title":312,"description":313,"date":314,"tags":315},"\u002Fblog\u002Fja\u002Fk3s-edge-ai-inference-fractional-gpu-time-slicing","K3sでエッジAI推論基盤を組んだら、1台のGPUに2つのモデルを乗せられなかった。fractional GPUという壁","K3sでエッジAI推論基盤を構築する際、標準KubernetesのGPUリソース管理(整数単位・request=limit固定)が壁になる。1台のGPUに複数モデルを同居させる方法とtime-slicing導入時の注意点を解説する。","2026-10-02",[10,11,316,317,318,319,320],"edge-ai","gpu-scheduling","device-plugin","time-slicing","fractional-gpu",{"path":322,"title":323,"description":324,"date":325,"tags":326},"\u002Fblog\u002Fja\u002Fk3s-vs-kubernetes-cicd-build-runner-latency-cost","CI\u002FCDのビルドランナー基盤、K3sか標準Kubernetesか。ジョブ起動レイテンシとコストで決める選定基準","CI\u002FCDのビルドランナー基盤はK3sか標準Kubernetesか。ジョブ起動レイテンシ、Cluster Autoscalerのコールドスタート、GitLab Runner\u002FGitHub Actions ARCのコスト構造を比較し、最適な選定基準を解説する。","2026-10-01",[10,11,327,328,329],"ci-cd","gitlab-runner","github-actions",{"path":331,"title":332,"description":333,"date":334,"tags":335},"\u002Fblog\u002Fja\u002Fk3s-helmchart-crd-manual-helm-upgrade-reconcile-revert","K3sのHelmChart CRDで配ったアプリを直接helm upgradeしたら、次のreconcileで設定が消えた","K3sとKubernetesの違いは機能一覧だけでは分からない。HelmChart CRDという自動化レイヤーが、手動でのhelm upgradeやkubectl editを静かに巻き戻す仕組みと回避策を解説する。","2026-09-29",[10,11,336,337,80,338],"helm-controller","helmchart-crd","reconcile",{"path":340,"title":341,"description":342,"date":343,"tags":344},"\u002Fblog\u002Fja\u002Fk3s-cluster-autoscaler-node-provisioning-lag-pending-pods","スケールアウト指示から実際にPodが動くまでの5分間。Cluster Autoscalerのノード追加が間に合わない理由","HPAがレプリカ数を増やしてもPodがPendingのまま動かない。原因はCluster Autoscalerのノード追加に数分かかること。遅延の内訳、診断チェックリスト、オーバープロビジョニング、Karpenterとの速度比較まで実務目線で解説する。","2026-09-27",[10,11,139,138,140,129,345],"priorityclass",{"path":347,"title":348,"description":349,"date":350,"tags":351},"\u002Fblog\u002Fja\u002Fk3s-service-mesh-linkerd-istio-ambient-mesh-decision","K3sにサービスメッシュを足したら、軽くなったのはLinkerdだった。Istio Ambient Meshとの分かれ道","K3sにLinkerdとIstio Ambient Meshを実際に導入して比較しました。プロキシ構成の違い、メモリ使用量の実測値、K3s特有のCNIパス設定の落とし穴まで、軽量なK3s環境でサービスメッシュを選ぶ際に確認すべき判断基準を具体的な数字とともに解説します。","2026-09-26",[10,11,182,352,353,354],"linkerd","istio","ambient-mesh",{"path":356,"title":357,"description":358,"date":359,"tags":360},"\u002Fblog\u002Fja\u002Fk3s-cert-manager-servicelb-http01-challenge-renewal-failure","K3sでcert-managerの証明書が自動更新されない。HTTP-01チャレンジをServiceLBが奪っていた","K3sでcert-managerの証明書が更新されない原因はTraefikでもcert-manager自体でもなく、port 80\u002F443を専有するServiceLBだった。HTTP-01チャレンジが静かに失敗する仕組みと恒久対処を解説する。","2026-09-25",[10,11,361,226,362,363],"cert-manager","tls","lets-encrypt",{"path":365,"title":366,"description":367,"date":368,"tags":369},"\u002Fblog\u002Fja\u002Fk3s-networkpolicy-dual-stack-kube-router-ipv6-gap","「K3sはNetworkPolicyを無視する」は嘘だった。それでも通信が漏れていた、ServiceLBという死角","K3sはkube-router内蔵コントローラでNetworkPolicyをデフォルト強制する。それでもLoadBalancer経由の通信だけが漏れる理由は、ServiceLBの実装とNetworkPolicy APIの恒久的な制約が組み合わさった結果だった。検証手順と対処法を解説する。","2026-09-24",[10,11,192,226,370,371],"kube-router","network-security",{"path":373,"title":374,"description":375,"date":376,"tags":377},"\u002Fblog\u002Fja\u002Fk3s-longhorn-storage-network-multus-replica-rebuild-stall","K3sノードを再起動したら、Longhornのレプリカ再構築が0%のまま静かに止まっていた。Storage Networkの起動順序という盲点","K3sノードを再起動したらLonghornのレプリカ再構築が0%で止まっていた。実際のバグ報告からStorage Network(Multus)の起動順序、レプリカ数設計、ノードdrain時の詰みポイントを解説する","2026-09-23",[10,11,378,379,380,54],"longhorn","storage-network","multus",{"path":382,"title":383,"description":384,"date":385,"tags":386},"\u002Fblog\u002Fja\u002Fk3s-hpa-scaledown-stabilization-window-replica-flapping","HPAのレプリカ数が数分おきに増減する。原因はメトリクスではなくscaleDownスタビライゼーションウィンドウの設計不足だった","K3s上のHPAでメトリクスは正常なのにレプリカ数が数分おきに増減する。原因はscaleUp\u002FscaleDownの非対称なデフォルト値とbehavior設計の不足。stabilizationWindowSecondsとCPU requestsを見直して振動を止める具体的な設定手順を解説する。","2026-09-22",[10,11,387,388,389,390],"scaling-policy","stabilization-window","replica-flapping","cpu-requests",{"path":392,"title":393,"description":394,"date":395,"tags":396},"\u002Fblog\u002Fja\u002Fk3s-etcd-snapshot-restore-token-cluster-reset-pitfalls","自動etcdスナップショットは毎日取れていた。K3sのリストアが本番障害で動かなかった理由","K3sのetcdスナップショットは正常に取れていたのに、本番障害でリストアが失敗した——トークン管理、S3リストア事故、cluster-resetの落とし穴という3つの実例から、embedded etcdバックアップの本当のリスクを解説する。","2026-09-21",[10,11,275,397,235,148],"backup-restore",{"path":399,"title":400,"description":401,"date":402,"tags":403},"\u002Fblog\u002Fja\u002Fk3s-gpu-oomkilled-vpa-resource-estimation","GPUメモリ不足でAIトレーニングジョブがOOMKilled。K3sでVPAが効かない理由とリソース設計","K3s上でAIトレーニングジョブがGPUメモリ不足でOOMKilledされる原因と、Vertical Pod Autoscalerが GPU リソースには効かない理由を解説。requests\u002Flimitsの正しい見積もり方法と実測ベースの設計手順まで、運用者向けに具体的に紹介します。","2026-09-20",[10,11,404,405,130,406,45],"gpu","oomkilled","ai-infrastructure",{"path":408,"title":409,"description":410,"date":411,"tags":412},"\u002Fblog\u002Fja\u002Fk3s-traefik-servicelb-ingress-nginx-port-conflict","K3sのTraefikを無効化したはずなのに、ingress-nginxが443番を取れない。ServiceLBという見えない同居人","K3sでTraefik無効化を実行したのにingress-nginxが443番ポートを取れない――原因はServiceLB(klipper-lb)というもう一つのデフォルトコンポーネント。診断から正しい無効化手順、MetalLB併用時の注意まで解説する。","2026-09-19",[10,11,267,226,413,414],"ingress-nginx","load-balancer",{"path":416,"title":417,"description":418,"date":419,"tags":420},"\u002Fblog\u002Fja\u002Fk3s-vpa-poddisruptionbudget-mass-eviction","K3sで自動リソース最適化を入れたら、全レプリカが同時に退避した。PodDisruptionBudgetという防波堤","K3sでリソース最適化ツールを有効化した直後、全レプリカが同時に退避され503が発生した実例をもとに、Podが一斉に退避されるメカニズムと、PodDisruptionBudgetのminAvailable設定による具体的な防御方法をエンジニア向けに詳しく解説する。","2026-09-18",[10,11,200,23,421,422],"vertical-scaling","resource-optimization",{"path":424,"title":425,"description":426,"date":427,"tags":428},"\u002Fblog\u002Fja\u002Fk3s-proxmox-storage-expansion-sata-scsi-pitfall","Proxmoxのディスクを無停止で拡張したつもりが、K3sノードには反映されなかった。SATAコントローラという見落とし","Proxmoxで本番運用中のK3sクラスタのストレージが逼迫した時、無停止で拡張したつもりが反映されない典型的な原因(ディスクコントローラ設定)と、CephでOSDを追加する際にK3sのetcdクォーラムが受ける影響、公式ドキュメントに基づく正しい拡張手順を具体的に解説する。","2026-09-17",[10,11,429,430,431,275],"proxmox","storage","ceph",{"path":433,"title":434,"description":435,"date":436,"tags":437},"\u002Fblog\u002Fja\u002Fk3s-cronjob-silent-failure-concurrencypolicy-missed-schedule","CronJobは緑のまま、24日間何もしていなかった。K3sで実行が静かに止まる4つの罠","K3s\u002FKubernetesのCronJobは「Succeeded」表示のまま実行されないことがある。concurrencyPolicy・startingDeadlineSeconds・100回ミス上限・Exit Code 0が重なって起きる静かな失敗の仕組みと監視での防ぎ方を解説する。","2026-09-16",[10,11,438,439,440,441],"cronjob","concurrencypolicy","monitoring","sre",{"path":443,"title":444,"description":445,"date":446,"tags":447},"\u002Fblog\u002Fja\u002Fk3s-dns-intermittent-ndots-conntrack-race","K3sのDNSが1日に数回だけ失敗する。犯人はndots:5でもconntrackでもなく、その「掛け算」だった","K3sで外部APIへの接続が時々タイムアウトする間欠障害の正体は、ndots:5によるDNSクエリ増幅とUDP conntrackレースの複合要因にある。NodeLocal DNSCacheの効果と副作用、K3s固有のcoredns-custom永続化まで解説する。","2026-09-15",[10,11,448,449,450,451],"coredns","dns","conntrack","nodelocal-dnscache",{"path":453,"title":454,"description":455,"date":456,"tags":457},"\u002Fblog\u002Fja\u002Fk3s-local-path-provisioner-capacity-node-affinity-pvc-pending","K3sのPVCがPendingのまま戻ってこない。ローカルストレージの『容量無視』とノードアフィニティが起こす静かな詰み","K3sのPVCがPending状態から戻らない原因は、local-path-provisionerが容量制限を無視する設計にある。ハイパーバイザーのthin provisioning、Volume Node Affinity Conflict、バックアップの誤解まで、K3sのローカルストレージ設計の落とし穴を解説する。","2026-09-12",[10,11,430,53,458,459,460],"persistent-volume","node-affinity","zfs",{"path":462,"title":463,"description":464,"date":465,"tags":466},"\u002Fblog\u002Fja\u002Fk3s-keda-vs-hpa-event-driven-autoscaling-decision","K3sでイベント駆動オートスケーリングが必要になったら。HPAとKEDA、どちらを選ぶかの判断基準","K3sでHPAのCPU\u002Fメモリベースのスケーリングでは対応しきれないイベント駆動ワークロードに直面したとき、標準のHPAを使い続けるべきか、CNCF GraduatedプロジェクトのKEDAを導入すべきか。3つの判断基準とK3s環境での注意点を整理する。","2026-09-10",[10,11,129,307,131],{"path":468,"title":469,"description":470,"date":471,"tags":472},"\u002Fblog\u002Fja\u002Fk3s-proxmox-live-migration-etcd-quorum-affinity-design","Proxmoxのライブマイグレーションで、K3sのetcdクォーラムが静かに崩れる。仮想化とRaftが衝突する設計","Proxmox上のK3sコントロールプレーンVMをライブマイグレーションした際にetcdクォーラムが崩れる仕組みを、heartbeat\u002Felection-timeoutとProxmoxのaffinity設計から解説。実運用で使える具体的な対策手順を紹介する。","2026-09-09",[10,11,429,275,473,148],"live-migration",{"path":475,"title":476,"description":477,"date":478,"tags":479},"\u002Fblog\u002Fja\u002Fk3s-harbor-private-registry-docker-hub-rate-limit","深夜のCIがDocker Hubのpull制限で全滅した。K3s\u002FKuboにHarborプライベートレジストリを構える設計","K3sクラスタでDocker Hubのpull rate limitに阻まれた経験はないか。HarborプライベートレジストリのProxy Cache機能で制限を回避し、脆弱性スキャン・署名・本番運用設計まで解説する。","2026-09-08",[10,11,480,481,482],"harbor","container-registry","private-registry",{"path":484,"title":485,"description":486,"date":487,"tags":488},"\u002Fblog\u002Fja\u002Faks-cost-optimization-fixed-cost-structure-k3s-comparison","AKSのコスト最適化を一通りやったのに、請求額はなぜ下げ止まるのか","AKSコスト最適化のノード右サイジングやSpot導入をやり切っても請求額が下げ止まるのは、LoadBalancer課金・監視アドオンという構造的な固定費があるため。K3s軽量アーキテクチャとのコスト構造比較で本当のボトルネックを解説する。","2026-09-07",[10,11,489,490,63,491],"aks","azure","managed-kubernetes",{"path":493,"title":494,"description":495,"date":496,"tags":497},"\u002Fblog\u002Fja\u002Fk3s-ai-agent-opentelemetry-observability","K3s上で動くAIエージェントは、いま何をしているか分からない。OpenTelemetryで非決定論的な実行をトレースする設計","K3s上のMCPサーバーやAIエージェントは、ログだけでは何を考えてツールを呼んだか分からない。OpenTelemetry GenAIセマンティック規約で非決定論的な実行を可視化する設計を解説する。","2026-09-06",[10,11,498,499,500,501],"opentelemetry","distributed-tracing","genai","telemetry",{"path":503,"title":504,"description":505,"date":506,"tags":507},"\u002Fblog\u002Fja\u002Fk3s-zero-trust-kubectl-management-access","社内VPNを信頼するのをやめる。K3s管理アクセスを『境界のない』設計に変える3つの手順","K3sクラスタへの管理アクセスを、社内VPN前提のまま設計していないか。kubectl・Rancherダッシュボードへのアクセスを『境界』ではなく『アイデンティティ』で守るK3sゼロトラスト設計の3つの手順と、導入時に陥りやすい落とし穴まで具体的に解説する。","2026-09-05",[10,11,508,122,509],"zero-trust","rancher",{"path":511,"title":512,"description":513,"date":514,"tags":515},"\u002Fblog\u002Fja\u002Fk3s-litmuschaos-chaos-engineering-blast-radius","「本番のK3sを、自分でわざと壊す。」LitmusChaosで始めるカオスエンジニアリング、最初に壊していいワークロードの見極め方","K3s本番環境の耐障害性は、実際に壊れてからでないと分からない。監視やアラートは「壊れた後」を検知する仕組みに過ぎない。CNCFのLitmusChaosを使ったカオスエンジニアリングの始め方と、最初に壊していいワークロード・壊してはいけないワークロードの見極め方をK3s環境の実例で解説する。","2026-09-04",[10,11,516,517,518,441],"chaos-engineering","litmuschaos","resilience",{"path":520,"title":521,"description":522,"date":523,"tags":524},"\u002Fblog\u002Fja\u002Fk3s-mcp-ai-agent-rbac-permission-bypass","AIエージェントに『Pod見てきて』と頼んだら、K3sクラスタごと乗っ取れた。MCPサーバーの権限バイパスが教えるRBAC設計の盲点","MCP経由でAIエージェントにKubernetes操作を任せる際の権限バイパスの実例から、K3s\u002FKubernetesクラスタに必須のRBAC設計と監査ログ分離の実践を解説する。","2026-09-03",[10,11,525,14,12],"mcp",{"path":527,"title":528,"description":529,"date":530,"tags":531},"\u002Fblog\u002Fja\u002Fk3s-hpa-not-scaling-metrics-unknown-vpa-death-spiral","HPAの設定は合っている。なのにPodが増えない。K3sで起きる『メトリクス不明』の正体とHPA\u002FVPAの死のスパイラル","K3sでHPAを設定したのにPodが増えない。原因はリソースリクエスト未設定によるメトリクス不明化と、HPA\u002FVPAの死のスパイラルにあることが多い。診断手順と対策を解説する。","2026-09-02",[10,11,129,130,131,156],{"path":533,"title":534,"description":535,"date":536,"tags":537},"\u002Fblog\u002Fja\u002Fk3s-flannel-vxlan-overlay-mtu-troubleshooting","pingは通るのにHTTPだけ詰まる。K3sのFlannel VXLANオーバーレイネットワークがMTUで壊れる理由","K3sクラスタでpingは通るのにHTTPリクエストだけ詰まる——それはVXLANオーバーレイネットワークのMTU不整合が原因かもしれない。Flannel\u002FCalicoのMTU設計、PMTUブラックホールの正体、3ステップの診断手順とクラウド別の恒久対策までを解説する。","2026-09-01",[10,11,35,538,190,539],"vxlan","mtu",{"path":541,"title":542,"description":543,"date":544,"tags":545},"\u002Fblog\u002Fja\u002Fk3s-ai-inference-gpu-scheduling-dra-keda-kserve","Kubernetesは10年前と同じ設計のままでいいのか。AI推論ワークロードのためにK3sクラスタが見直すべき3つの前提","Kubernetesが登場して10年。AIエージェント・LLM推論の普及で、GPUリソースの扱い方、オートスケーリング、推論サービングという3つの前提が根本から変わった。K3sクラスタでDynamic Resource Allocation・KEDA・KServeをどう見直すべきかを解説する。","2026-08-31",[10,11,546,317,547,548],"ai-workload","dynamic-resource-allocation","mlops",{"path":550,"title":551,"description":552,"date":553,"tags":554},"\u002Fblog\u002Fja\u002Fk3s-servicemonitor-prometheus-not-scraping-connection-points","ServiceMonitorのYAMLは合ってる。K3sでPrometheusにターゲットが出てこない『接続点』の診断手順","K3sでkubernetes service monitorを設定したのにPrometheusのTargetsに何も出てこない。原因の9割はラベルセレクタ・ポート名・RBAC・namespaceSelectorという4つの接続点にある。1段ずつ疑って直す診断手順を解説する。","2026-08-30",[10,11,70,555,440,15],"service-monitor",{"path":557,"title":558,"description":559,"date":560,"tags":561},"\u002Fblog\u002Fja\u002Fedge-k3s-hardware-selection-beyond-appliance","家庭用ルーターを自作PCに置き換える動きが加速。エッジKubernetesも「専用アプライアンス」依存を見直す時期だ","ISP支給ルーターを自作PC+OSSに置き換える動きが個人の間で広がっている。工場や店舗のエッジKubernetesも同じ理由で専用アプライアンス依存を見直すべき理由と、ハードウェア選定の具体的なチェックリスト、GitOpsによる拠点運用の標準化までを解説する。","2026-08-29",[10,11,71,562,563],"hardware-selection","network-appliance",{"path":565,"title":566,"description":567,"date":568,"tags":569},"\u002Fblog\u002Fja\u002Fcicd-pipeline-devsecops-gate-design-four-layers","そのCI\u002FCDパイプライン、セキュリティチェックをどこに置くか決めずに継ぎ足していないか。DevSecOpsゲート設計の4層モデル","SASTもDASTもコンテナスキャンも導入した。それでも本番で事故は起きる。CI\u002FCDパイプラインのセキュリティを『4つの層』で設計し直すDevSecOpsゲート設計の考え方を、K3s\u002FKubernetes運用の観点から解説する。","2026-08-28",[10,11,327,570,89,80],"devsecops",{"path":572,"title":573,"description":574,"date":575,"tags":576},"\u002Fblog\u002Fja\u002Fk3s-cert-manager-acme-renewal-pitfalls","土曜の朝、K3sの本番サイトがTLS証明書切れで落ちた。手動更新から抜け出すACME自動化の設計","K3sの本番環境にcert-managerを導入していても、Issuerの参照ミスやDNS検証失敗、Let's Encryptのレート制限、Secret未リロードといった見落としで証明書は静かに失効する。手動更新時代の属人化と同じ罠に陥らないための、ACME自動更新を本当に機能させる監視・設計のポイントを解説する。","2026-08-27",[10,11,361,362,363,577],"acme",{"path":579,"title":580,"description":581,"date":582,"tags":583},"\u002Fblog\u002Fja\u002Fk3s-baremetal-loadbalancer-bgp-metallb-cilium","ベアメタルK3sのLoadBalancer、ARPだけでは限界が来る。BGPで外部ルーティングを設計する","オンプレ・エッジのK3sクラスタでクラウドLBに頼れないとき、Layer2(ARP)方式のロードバランシングはなぜ限界に達するのか。MetalLB BGPモードとCilium BGP Control Planeの違い、移行の判断基準を解説する。","2026-08-26",[10,11,584,585,414,71],"metallb","bgp",{"path":587,"title":588,"description":589,"date":590,"tags":591},"\u002Fblog\u002Fja\u002Fk3s-homelab-raspberry-pi-kubestronaut","Kubestronaut認定者は、教科書より先にRaspberry Pi 3台を壊していた","Kubernetes未経験からKubestronaut(CNCF全認定資格保持)に至った学習者の共通点は、資格対策より先にK3sホームラボで壊れる環境を持っていたことだ。K3s学習の本質を解説する。","2026-08-25",[10,11,592,593,594],"kubestronaut","homelab","devops",{"path":596,"title":597,"description":598,"date":599,"tags":600},"\u002Fblog\u002Fja\u002Fk3s-container-image-security-supply-chain-checklist","「スキャン済み」は本番投入の許可証にならない。K3sコンテナイメージセキュリティ、署名からアドミッション制御まで","コンテナ セキュリティ ガイドラインというと『スキャンしてるから大丈夫』で止まりがちだ。K3s環境でベースイメージの最小化から脆弱性スキャン、SBOM生成、署名、アドミッション制御まで、本番投入前に通すべき工程を実務チェックリストとして具体的に解説する。","2026-08-24",[10,11,601,602,603,604],"container-security","image-scanning","sbom","supply-chain-security",{"path":606,"title":607,"description":608,"date":609,"tags":610},"\u002Fblog\u002Fja\u002Fkubernetes-cost-management-eks-aks-billing-visibility","EKSの請求書は月末にならないと読めない。Kubernetesのコストが『後から分かる』構造的な理由","EKS\u002FAKSのKubernetesコストはなぜ想定外に膨らむのか。オートスケールとクロスAZ課金がコストを見えなくする構造を分解し、K3sベースのマネージドインフラで固定費化する方法を解説します。","2026-08-22",[10,11,63,491,489,62],{"path":612,"title":613,"description":614,"date":615,"tags":616},"\u002Fblog\u002Fja\u002Fkubernetes-operations-specialization-managed-k3s-hiring","eBPFもcert-managerもService Meshも。Kubernetes運用がひとりのエンジニアの手に負えなくなった理由","Kubernetes運用の求人がなぜ埋まらないのか。原因はツール知識の不足ではなく、専門分野が広がりすぎたことにある。採用で埋めるのではなく基盤に吸収させる、マネージドK3sという解決策を解説する。","2026-08-21",[10,11,491,594,617],"platform-engineering",{"path":619,"title":620,"description":621,"date":622,"tags":623},"\u002Fblog\u002Fja\u002Fk3s-opentelemetry-observability-correlation","3つのダッシュボードを往復する障害対応はもう終わり。K3sの可観測性をOpenTelemetryで『相関』させる設計","PrometheusとLokiとJaegerを個別に確認して原因究明に時間を溶かしていないか。K3sクラスタの可観測性をOpenTelemetryで相関させ、障害調査時間を短縮する設計とOpenTelemetry Collectorの導入パターンを、K3s\u002FKubernetes運用の現場目線で解説する。","2026-08-20",[10,11,498,15,499],{"path":625,"title":626,"description":627,"date":628,"tags":629},"\u002Fblog\u002Fja\u002Fcncf-project-maturity-graduation-criteria-production","GitHubスター1万は『卒業証書』にならない。KubernetesでCNCFプロジェクトを選ぶ基準はコミット数ではなく成熟度ステージ","Kubernetesの技術選定でCNCFプロジェクトを採用する際、GitHubスター数や知名度だけで判断していないか。Sandbox\u002FIncubating\u002FGraduatedという成熟度基準とHarborの事例から、本番導入前に確認すべき基準を解説する。","2026-08-19",[10,11,630,631,481],"cncf","oss-governance",{"path":633,"title":634,"description":635,"date":636,"tags":637},"\u002Fblog\u002Fja\u002Fai-agent-authentication-kubernetes-keycloak-spiffe","AIエージェントに鍵を持たせるな。KubernetesでMCPサーバーを『キーレス』に認証する設計","AIエージェントに静的なAPIキーを持たせる運用は、いずれ破綻する。KubernetesでMCPサーバーを運用する現場で起きている静的シークレット問題の構造的な限界と、KeycloakとSPIFFE\u002FSPIREを組み合わせて鍵を配らずに認証する『キーレス』設計思想を解説する。","2026-08-18",[10,11,12,525,638,508],"keycloak",{"path":640,"title":641,"description":642,"date":643,"tags":644},"\u002Fblog\u002Fja\u002Fgitlab-auto-devops-k3s-admission-controller-gate","GitLab Auto DevOpsの『とりあえず動くCI』が、本番K3sクラスタへの一番近い脅威になる理由","GitLab Auto DevOpsは有効化するだけでSAST\u002FDASTが自動的に動く。しかしスキャンが『動いている』ことと、脆弱性を含んだイメージが本番K3sクラスタに届かないことはまったく別の話だ。CI\u002FCDとクラスタの間に監査ゲートを作る設計を解説する。","2026-08-17",[10,11,645,327,570,646],"gitlab","admission-controller",{"path":648,"title":649,"description":650,"date":651,"tags":652},"\u002Fblog\u002Fja\u002Fkubernetes-cni-overlay-network-troubleshooting-ospf","OSPFなら1分で直る障害が、KubernetesのCNIだと半日かかる理由","Kubernetesのオーバーレイネットワークはなぜトラブルシューティングに時間がかかるのか。CNIの仕組み、Flannel VXLANとCalico BGPの違い、MTU不一致の切り分け手順まで、K3s運用者が押さえるべきポイントを解説する。","2026-08-16",[10,11,189,653,35],"overlay-network",{"path":655,"title":656,"description":657,"date":658,"tags":659},"\u002Fblog\u002Fja\u002Fkubernetes-ebpf-inspektor-gadget-observability","strace禁止、sidecar禁止、それでも診断できる。KubernetesをeBPFで透視するInspektor Gadgetという回答","特権コンテナもsidecarも追加できない本番Kubernetesで、Podの通信とシステムコールをどう診断するか。eBPFツール「Inspektor Gadget」の仕組みと2026年の最新動向を解説する。","2026-08-15",[10,11,33,15,630],{"path":661,"title":662,"description":663,"date":664,"tags":665},"\u002Fblog\u002Fja\u002Fkubernetes-servicemonitor-silent-metrics-failure","Prometheusは動いている。なのにメトリクスが無い。ServiceMonitorが『静かに』失敗する3つの理由","Kubernetesのkubernetes service monitorが原因不明にスクレイプされない——ラベル不一致・namespaceSelector・RBACという3つの落とし穴を、公式ドキュメントを元に切り分け手順つきで解説する。","2026-08-14",[10,11,70,15,666],"servicemonitor",{"path":668,"title":669,"description":670,"date":671,"tags":672},"\u002Fblog\u002Fja\u002Fkubernetes-gpu-multitenancy-namespace-vs-dedicated-node","高価なGPUを独り占めさせるな。Kubernetesでアクセラレーターを分け合う設計に「唯一の正解」がない理由","KubernetesのGPUマルチテナント設計は namespace分離か専用ノードかの二択ではない。コストと分離レベルのトレードオフを解説し、ハイブリッド設計の考え方を紹介する。","2026-08-13",[10,11,673,63,674],"gpu-multitenancy","namespace-isolation",{"path":676,"title":677,"description":678,"date":679,"tags":680},"\u002Fblog\u002Fja\u002Fkubernetes-gitops-branch-antipattern-fleet-scaling","そのdev\u002Fstaging\u002Fprodブランチ、実は時限爆弾。KubernetesのGitOpsが壊れる本当の理由","dev\u002Fstaging\u002FproductionをGitブランチで分けるGitOps運用は、実はKubernetesの宣言的インフラの前提を壊すアンチパターンだ。ドリフトが起きる理由とディレクトリ構成・トランクベース運用への移行手順、フリート規模での崩壊を防ぐ設計を解説する。","2026-08-10",[10,11,80,78,594],{"path":682,"title":683,"description":684,"date":685,"tags":686},"\u002Fblog\u002Fja\u002Fkubernetes-certificate-management-cert-manager-process-debt","証明書の更新、1行のコードより2ヶ月の会議が長かった。Kubernetesの証明書管理が『技術』ではなく『手続き』の問題である理由","Kubernetesの証明書管理は技術的には数日で終わる。だが実際に時間がかかるのは合意形成という『手続き』だ。cert-managerによる自動化と、組織的負債をなくす設計を解説する。","2026-08-09",[10,11,361,362,122],{"path":688,"title":689,"description":690,"date":691,"tags":692},"\u002Fblog\u002Fja\u002Fai-agent-sandbox-kata-containers-kubernetes","AIエージェントのコードは「信頼できる製品」じゃない。Kubernetesサンドボックス設計の答え","AIエージェントが生成・実行するコードはもう「信頼できる製品」ではない。KubernetesでAIエージェント向けサンドボックスを設計する際、コンテナ分離の限界とKata Containersによるマイクロ VM分離がなぜ必要になるのかを解説する。","2026-08-08",[10,11,693,12,122],"kata-containers",{"path":695,"title":696,"description":697,"date":698,"tags":699},"\u002Fblog\u002Fja\u002Fkubevirt-calico-live-migration-networking","VMを動かしても通信は切れない。KubeVirtとCalicoが実現するKubernetesライブマイグレーションの舞台裏","KubernetesでVM（KubeVirt）をノード間へライブマイグレーションしても、なぜ通信が切れないのか。CalicoのIP永続化・BGPルート収束の仕組みと、VMware移行先としての実務的な意味を解説する。","2026-08-07",[10,11,700,35,491],"kubevirt",{"path":702,"title":703,"description":704,"date":705,"tags":706},"\u002Fblog\u002Fja\u002Fkubernetes-image-signing-sigstore-supply-chain","イメージタグは誰でも書き換えられる。Kubernetesのイメージ署名にSigstoreで『来歴』を刻むという発想","コンテナイメージ署名の仕組みを解説。イメージタグは誰でも書き換え可能で、CI\u002FCDのテストを通過した保証にはならない。SigstoreとKyvernoを組み合わせ、Kubernetes\u002FK3s上で未署名イメージの起動を拒否する防御層を構築する方法を、GitOps運用との統合も含めて紹介する。","2026-08-06",[10,11,327,80,122],{"path":708,"title":709,"description":710,"date":711,"tags":712},"\u002Fblog\u002Fja\u002Fkubernetes-high-availability-broadcast-seamless-switching","「同じ映像を2回送って、早く着いた方を使う。」放送業界の非常識がKubernetesの高可用性設計そのものだった件","ワールドカップ放送は同じ映像を2つの経路で二重送信し、早く着いた方だけを使う。この一見無駄な冗長化がKubernetesの高可用性設計・マルチAZ構成と同じ思想である理由を解説する。","2026-08-05",[10,11,148,713,441],"multi-az",{"path":715,"title":716,"description":717,"date":718,"tags":719},"\u002Fblog\u002Fja\u002Fai-generated-kubernetes-manifest-resource-overprovisioning","Kubernetesリソース設計はAI任せにできない。「動く」YAMLがクラウド代を69%溶かす理由","AIが生成したKubernetesマニフェストはkubectl applyが通り「動く」。しかしKubernetesリソース設計を誤ると過剰プロビジョニングでクラウド代が膨らむ。AIの限界と本番品質のrequests\u002Flimits設計を解説する。","2026-08-04",[10,11,45,720,491],"capacity-planning",{"path":722,"title":723,"description":724,"date":725,"tags":726},"\u002Fblog\u002Fja\u002Fk3s-edge-fleet-declarative-management","1台のトラブルシューティングは笑い話で済む。それが1000台なら経営リスクになる。K3sエッジ運用を属人化から救うRancher Fleetという選択肢","K3sエッジ運用のフリート管理は、1台ずつの手作業トラブルシューティングでは破綻する。宣言的管理とRancher Fleetの仕組みから、属人化しないエッジ運用の設計を解説する。","2026-08-03",[10,11,71,80,727],"fleet-management",{"path":729,"title":730,"description":731,"date":732,"tags":733},"\u002Fblog\u002Fja\u002Fkubernetes-microservices-chatty-calls-latency","1つの注文処理で、裏側は5回叩かれていた。Kubernetesマイクロサービスの「チャッティ呼び出し」とレイテンシの正体","1回の注文処理の裏側でサービスが5回も呼び出されていた。原因はKubernetesマイクロサービスが陥る「チャッティ呼び出し」というアーキテクチャの問題。分散システムのN+1問題と解決策を解説する。","2026-08-02",[11,10,734,182,735,491],"microservices","latency",{"path":737,"title":738,"description":739,"date":740,"tags":741},"\u002Fblog\u002Fja\u002Fkubernetes-ai-inference-reversal-conformance-design","推論が学習を逆転した。KubeCon Japanで語られた、AI時代のKubernetesクラスタ設計指針","AI計算需要は学習から推論へ逆転し、2030年には推論の計算能力が学習の1.5倍に達すると予測される。KubeCon Japanの議論とCNCF AI Conformance Programから、Kubernetes\u002FK3sクラスタが備えるべき設計指針を解説する。","2026-08-01",[11,10,742,630,491],"ai-inference",{"path":744,"title":745,"description":746,"date":747,"tags":748},"\u002Fblog\u002Fja\u002Fhybrid-k3s-edge-metrics-network-overhead","2000台のIoTデバイスがネットワーク回線を圧迫していた。ハイブリッドK3s運用でpush型メトリクスが牙を剥いた日","2000台規模のエッジデバイスを支えるK3sエッジ運用の現場で見えた、軽量Kubernetesを選ぶべき理由と、push型メトリクス収集が生むネットワークコストの実態を、具体的な数値とハイブリッドクラスタ設計の観点から詳しく解説する記事。エンジニア・運用担当者向け。","2026-07-31",[10,11,71,749,491],"hybrid-cluster",{"path":751,"title":752,"description":753,"date":754,"tags":755},"\u002Fblog\u002Fja\u002Fkubernetes-mlops-gpu-scheduling-talent-shortage","AIがコードを書ける時代に、なぜインフラエンジニアの給料は上がったのか。企業のAI導入ラッシュが生んだ「MLOps人材不足」の実態","生成AIの普及でコードは誰でも書ける時代になったが、企業のAI導入が進むほどKubernetes上でGPUやモデルサービングを安定運用できるMLOps人材の需要は逆に高まっている。その理由と解決策を解説する。","2026-07-30",[11,10,548,406,317,594],{"path":757,"title":758,"description":759,"date":760,"tags":761},"\u002Fblog\u002Fja\u002Fkubernetes-secrets-rbac-etcd-encryption","Base64を見て安心するな。KubernetesのSecretsが「素通し」される理由とRBAC設計の落とし穴","KubernetesのSecretsはBase64エンコードされているだけで、暗号化されていない。etcdへの平文相当保存とRBACの過剰権限が引き起こす事故と、K3s本番運用で実践すべきSecrets管理の対策を解説する。","2026-07-29",[11,10,234,14,122,762],"etcd-encryption",{"path":764,"title":765,"description":766,"date":767,"tags":768},"\u002Fblog\u002Fja\u002Fkubernetes-cpu-throttling-connection-pool-exhaustion","『CPU使用率は低いから大丈夫』は罠。Kubernetesが隠すスロットリングと接続プール枯渇の天井","KubernetesでPodを増やしても遅延が直らないとき、真のKubernetes遅延原因はCPUではなくスロットリングやDB接続プールの枯渇かもしれない。見えない天井の正体と正しい診断・対処法を解説する。","2026-07-28",[11,10,769,770,771,129],"performance-tuning","cpu-throttling","connection-pooling",{"path":773,"title":774,"description":775,"date":776,"tags":777},"\u002Fblog\u002Fja\u002Fkubernetes-aiops-incident-response-distributed-tracing","AIに『直して』と頼んでも直らない。Kubernetes本番障害調査は分散トレーシングから始まる","Kubernetes本番環境の障害対応をAIに任せても、分散システムの因果関係が見えなければ的外れな対処になる。AIOpsを機能させる分散トレーシング設計とOpenTelemetry導入の実践ステップを解説する。","2026-07-27",[11,10,15,499,498,778],"aiops",{"path":780,"title":781,"description":782,"date":783,"tags":784},"\u002Fblog\u002Fja\u002Fedge-k3s-observability-homelab-dashboard","壁に貼っただけで「安心」に変わる。ホームラボの壁掛けダッシュボードが教えてくれた、エッジK3sクラスタの観測性設計","自宅の壁掛けダッシュボード作りで起きた総当たりのトラブルシューティングは、工場や店舗に分散したエッジKubernetesクラスタの運用でも同じ罠になる。K3s・Prometheus・Grafanaの公式ドキュメントを引きながら、観測性を後回しにしないための設計原則を解説する。","2026-07-26",[10,11,71,15,440,491],{"path":786,"title":787,"description":788,"date":789,"tags":790},"\u002Fblog\u002Fja\u002Fkubernetes-multi-tenancy-capsule-namespace-isolation","「namespaceで区切ったつもり」が事故のもと。KubernetesマルチテナンシーをCapsuleが解決する仕組み","namespaceで環境を分けただけでは、ポリシーもリソース制限も自動では引き継がれない。Kubernetesマルチテナンシーの落とし穴と、Capsule・vCluster・HNCという3つの解決アプローチを実務目線で解説する。","2026-07-25",[10,11,165,791,792,491],"capsule","namespace",{"path":794,"title":795,"description":796,"date":797,"tags":798},"\u002Fblog\u002Fja\u002Fkubernetes-feature-flags-progressive-delivery-rollback","テストを増やすほど本番は壊れる。Kubernetes運用で『機能フラグ』が監視より効く理由","QAテストを積み増しても本番障害は減らない。すべての例外パターンを事前に洗い出すのは原理的に不可能だからだ。Kubernetes運用で注目される『機能フラグ×監視×自動ロールバック』という壊れる前提の設計思想と、K3s環境で無理なく始めるための段階的ロードマップを解説する。","2026-07-24",[10,11,799,800,594,491],"feature-flags","progressive-delivery",{"path":802,"title":803,"description":804,"date":805,"tags":806},"\u002Fblog\u002Fja\u002Fcncf-graduated-project-oss-selection-criteria","CNCFの『卒業』ロゴを信じていいのか。TOC公開議事から見えた、審査の地味な実態とOSS選定基準","CNCFの「卒業（Graduated）」ロゴは安全証明ではない。TOC公開会議の議事から見える審査の実態と、Sandbox・Incubating・Graduatedの基準・タイムラインを解説し、本番導入前にOSSの成熟度を見極める視点を紹介する。","2026-07-23",[630,11,10,807,491,808],"oss","governance",{"path":810,"title":811,"description":812,"date":813,"tags":814},"\u002Fblog\u002Fja\u002Fkubernetes-networking-cni-service-mesh-network-engineer","サブネットは計算できるのに、Podは繋がらない。Kubernetesネットワーキングで最初にハマる壁","サブネット設計は得意なのに、なぜKubernetesのPod間通信では毎回つまずくのか。CNI・Service Mesh・NetworkPolicyというKubernetesネットワーキングの基礎を、伝統的なネットワーク設計の知識と対比しながら整理する。","2026-07-22",[11,10,35,189,182,815],"network-policy",{"path":817,"title":818,"description":819,"date":820,"tags":821},"\u002Fblog\u002Fja\u002Fkubernetes-namespace-environment-cost-design","本番前に環境はいくつ必要か。namespace分離で請求書を膨らませないKubernetes環境設計","開発・テスト・ステージング・本番と環境を増やすほどKubernetesのクラウド費用は膨らむ。namespace分離とResourceQuota、本番専用クラスタのハイブリッド構成でコストと隔離性を両立するKubernetes環境設計を解説する。","2026-07-21",[11,10,792,63,491,822],"resource-quota",{"path":824,"title":825,"description":826,"date":827,"tags":828},"\u002Fblog\u002Fja\u002Fbroadcast-redundancy-kubernetes-high-availability-design","FIFAワールドカップの中継は、なぜ絶対に途切れないのか。放送業界の二重伝送に学ぶKubernetesの本当の高可用性設計","Kubernetesの高可用性は「レプリカを増やす」だけでは実現しない。放送業界のSMPTE ST 2022-7二重伝送技術を手がかりに、Topology Spread ConstraintsとマルチAZ設計の本質を解説する。","2026-07-20",[11,10,148,199,441,491],{"path":830,"title":831,"description":832,"date":833,"tags":834},"\u002Fblog\u002Fja\u002Fqa-to-devops-kubernetes-career-transition","QAエンジニアの『バグを壊す視点』はKubernetes運用に転用できる。テスト自動化スキルからDevOpsキャリアへの最短ルート","QAエンジニアが持つ品質ゲート思考とテスト自動化スキルは、実はKubernetes運用に直結するDevOps適性だ。半年で転身するための現実的なロードマップと、学習の最大の壁を越える方法を解説する。","2026-07-19",[11,10,594,327,835],"career",{"path":837,"title":838,"description":839,"date":840,"tags":841},"\u002Fblog\u002Fja\u002Fai-manifest-generation-kubernetes-architecture-bottleneck","AIがYAMLを1秒で書いても、クラスタは1秒も速くならない。Kubernetes運用の本当のボトルネックはコードではなくアーキテクチャという話","AIでKubernetesマニフェストを爆速生成しても、本番のKubernetes運用が速くなるとは限らない。CPUスロットリング、HPAとVPAの競合、DB接続不足という3つの本当のボトルネックと、AIと人間の役割分担を解説する。","2026-07-18",[11,10,45,131,842,594],"ai-ops",{"path":844,"title":845,"description":846,"date":847,"tags":848},"\u002Fblog\u002Fja\u002Fshadow-ai-kubernetes-admission-control-governance","野良デプロイが会社を壊す。KubernetesクラスターのシャドーAI問題とAdmission Controlという処方箋","SaaSの無断導入だけがシャドーAIではない。Kubernetesクラスター内で誰が何をデプロイしているか分からない状態が生むリスクと、Admission Controlによるガバナンス実装を解説する。","2026-07-17",[11,10,849,89,210,122],"shadow-ai",{"path":851,"title":852,"description":853,"date":854,"tags":855},"\u002Fblog\u002Fja\u002Fplatform-engineering-kubernetes-idp-managed-k3s","生のKubernetesを渡すな。プラットフォームエンジニアリングという“隠す”設計思想と、Kuboという答え","プラットフォームエンジニアリングとKubernetesの関係を解説。開発者にK8sの複雑さを直接渡さない設計思想、IDP構築の3本柱、そしてマネージドK3sという選択肢を紹介する。","2026-07-16",[11,10,617,856,80,491],"internal-developer-platform",{"path":858,"title":859,"description":860,"date":861,"tags":862},"\u002Fblog\u002Fja\u002Fcanary-release-kubernetes-auto-rollback-gitops","全員が同じCI\u002FCDにたどり着けない理由。カナリアリリース×自動ロールバックで作る『壊れても安全』なKubernetesデプロイ設計","本番障害の多くは「一気にデプロイする」ことが原因で起きる。カナリアリリース・自動ロールバック・監視をKubernetes上でどう設計するか、Argo RolloutsとGitOpsを軸に、中小チームでも運用し続けられる実践手順を具体的に解説する。","2026-07-15",[11,10,327,863,80,864],"canary-release","argo-rollouts",{"path":866,"title":867,"description":868,"date":869,"tags":870},"\u002Fblog\u002Fja\u002Fprivate-cloud-openstack-k3s-day2-operations","「プライベートクラウド構築は自分たちでできる」は半分正解。OpenStack×K3sで検証するDay2運用の現実","VMware移行やクラウド費用増を背景にプライベートクラウド回帰が進む2026年。OpenStack×K3sで自前構築した場合の初期コストとDay2運用の負荷を、実際の運用データや統計をもとに具体的に検証し、内製とマネージドK8sサービスの分岐点をわかりやすく解説する。","2026-07-14",[10,11,871,872,873],"openstack","private-cloud","on-premise",{"path":875,"title":876,"description":877,"date":878,"tags":879},"\u002Fblog\u002Fja\u002Fmlops-kubernetes-devops-ai-skills-2026","「DevOpsエンジニアは不要になる」は嘘だった。AI時代のKubernetes運用者が今すぐ身につけるべきMLOpsスキル5選","AIがインフラ構築を自動化する時代、DevOpsエンジニアは本当に不要なのか？実態は逆で、MLOps Kubernetesを扱える人材の需要が急増。2026年に求められる5つのスキルと具体的な習得法を解説。","2026-07-11",[11,548,594,10,327,406],{"path":881,"title":882,"description":883,"date":884,"tags":885},"\u002Fblog\u002Fja\u002Fai-platform-kubernetes-convergence-2026","生成AIを動かす企業の66%がKubernetesを選んだ——AI基盤はなぜK8sに収束するのか","CNCF 2026年調査で生成AI組織の66%がKubernetesを採用。GPUスケジューリング、マルチテナント、コスト最適化——AIワークロードを本番で動かすためにK8sが選ばれる理由と、マネージドK8sで最短構築する方法を解説。","2026-07-10",[11,886,617,548,10,404],"ai",{"path":888,"title":889,"description":890,"date":891,"tags":892},"\u002Fblog\u002Fja\u002Fmanaged-k8s-infrastructure-evolution-2026","2026年、なぜ「マネージドK8s」が答えなのか：インフラ進化の5段階から読み解く","DevOpsエンジニアが陥る「段階スキップの罠」とは？インフラ管理の進化論から、なぜマネージドKubernetesが最適解なのかを徹底解説","2026-06-12",[11,594,893,894,10],"マネージドサービス","インフラ進化",{"path":896,"title":897,"description":898,"date":899,"tags":900},"\u002Fblog\u002Fja\u002Fkubernetes-v136-k3s-managed-cost-reduction","マネージドKubernetesはもう高すぎる。K3s軽量化とv1.36セキュリティ強化で実現する『月額4万円台フルK8s運用』の現実味","Kubernetes v1.36「Haru」で強化されたUser Namespaces、セキュリティ機能をK3s軽量環境で活用する方法を解説。EKSより60%コスト削減を実現するマネージドK3s運用戦略と2026年のインフラ選定指針。","2026-05-28",[10,11,901,491,63,122],"kubernetes-v136",{"path":903,"title":904,"description":905,"date":906,"tags":907},"\u002Fblog\u002Fja\u002Fargocd-gitops-kubernetes-guide","ArgoCD で始める GitOps: Kubernetes 宣言的デプロイの実践","ArgoCD を使った GitOps ベースの Kubernetes 宣言的デプロイを実践的に解説。リポジトリ構成、Sync Wave、ApplicationSet、マルチクラスタ管理まで網羅。","2026-05-27",[78,80,11,327,908,909],"デプロイ自動化","宣言的管理",{"path":911,"title":912,"description":913,"date":906,"tags":914},"\u002Fblog\u002Fja\u002Fcert-manager-automatic-tls","cert-manager で Kubernetes の TLS 証明書を自動管理する","cert-manager を使って Kubernetes 環境の TLS 証明書を自動発行・自動更新する方法を解説。Let's Encrypt、ACME チャレンジ、Ingress 連携まで。",[361,11,362,363,577,630,915,916],"セキュリティ","証明書",{"path":918,"title":919,"description":920,"date":906,"tags":921},"\u002Fblog\u002Fja\u002Fcicd-pipeline-security-devsecops","ci-cd パイプラインのセキュリティ: DevSecOps 実践ガイド","ci-cd パイプラインのセキュリティを DevSecOps の観点で実践的に解説。SAST\u002FDAST、サプライチェーン保護、SLSA フレームワーク、Policy as Code まで。",[570,327,915,922,923,11],"サプライチェーン","slsa",{"path":925,"title":926,"description":927,"date":906,"tags":928},"\u002Fblog\u002Fja\u002Fcilium-ebpf-kubernetes-networking","Cilium と eBPF で Kubernetes ネットワーキングを革新する","Cilium が eBPF 技術で Kubernetes ネットワーキングを変革する仕組みを解説。従来の CNI との比較、L7 セキュリティポリシー、Hubble による可観測性まで。",[32,33,11,929,189,630,915,930],"ネットワーキング","hubble",{"path":932,"title":933,"description":934,"date":906,"tags":935},"\u002Fblog\u002Fja\u002Fcncf-graduated-projects-2025-overview","CNCF Graduated プロジェクト一覧 2025: 本番環境で信頼できる OSS","CNCF Graduated プロジェクト全36件を徹底解説。Kubernetes、Prometheus から Cilium、Crossplane まで、本番環境で信頼できる OSS のカテゴリ別ガイド。",[630,936,937,807,11,70,32,498],"graduated","クラウドネイティブ",{"path":939,"title":940,"description":941,"date":906,"tags":942},"\u002Fblog\u002Fja\u002Fcontainer-registry-harbor-setup","Harbor でプライベートコンテナレジストリを構築する","Harbor を使ったプライベートコンテナレジストリの構築から運用まで完全ガイド。Trivy 統合による脆弱性スキャン、RBAC、レプリケーション、Helm デプロイを実践的に解説。",[480,943,944,11,915,945,14],"コンテナレジストリ","docker","trivy",{"path":947,"title":948,"description":949,"date":906,"tags":950},"\u002Fblog\u002Fja\u002Fdocker-compose-to-kubernetes-migration","Docker Compose から Kubernetes への移行ガイド","Docker Compose で動作するアプリケーションを Kubernetes に移行するステップバイステップガイド。Kompose による変換、Helm\u002FKustomize での本番化、移行時の注意点を網羅的に解説。",[52,11,951,952,953,954,955],"移行","kompose","helm","kustomize","コンテナオーケストレーション",{"path":957,"title":958,"description":959,"date":906,"tags":960},"\u002Fblog\u002Fja\u002Fdocker-multi-stage-build-optimization","Docker マルチステージビルドで本番イメージを最適化する","Docker マルチステージビルドの実践テクニックを徹底解説。ビルドステージの分離、レイヤーキャッシュ活用、distroless 採用で本番イメージを最大97%軽量化する方法を紹介します。",[944,961,962,594,327,963],"マルチステージビルド","コンテナ最適化","イメージ軽量化",{"path":965,"title":966,"description":967,"date":906,"tags":968},"\u002Fblog\u002Fja\u002Fdocker-networking-deep-dive","Docker ネットワーキング完全解説: bridge\u002Fhost\u002Foverlay の使い分け","Docker のネットワークドライバー bridge・host・overlay を徹底比較。仕組み、パフォーマンス、セキュリティ、ユースケース別の選択指針を実践的なコード例とともに解説します。",[944,929,969,970,971,972,973],"bridge","overlay","host","コンテナ","docker-swarm",{"path":975,"title":976,"description":977,"date":906,"tags":978},"\u002Fblog\u002Fja\u002Fdocker-security-scanning-best-practices","Docker コンテナセキュリティ: スキャンと脆弱性対策","Docker コンテナの脆弱性スキャンを ci-cd に統合する実践ガイド。Trivy・Snyk・Grype の比較、シフトレフト戦略、Harbor 連携による多層防御を詳しく解説します。",[944,915,979,945,980,981,570],"脆弱性スキャン","snyk","コンテナセキュリティ",{"path":983,"title":984,"description":985,"date":906,"tags":986},"\u002Fblog\u002Fja\u002Fdockerfile-best-practices-2025","Dockerfile ベストプラクティス 2025: 軽量・安全・高速なイメージ構築","2025年最新の Dockerfile ベストプラクティスを徹底解説。軽量ベースイメージ選択、レイヤー最適化、セキュリティ対策、BuildKit 活用で本番品質のコンテナイメージを構築する方法。",[987,944,988,972,915,989,990],"dockerfile","ベストプラクティス","buildkit","最適化",{"path":992,"title":993,"description":994,"date":906,"tags":995},"\u002Fblog\u002Fja\u002Ffluxcd-vs-argocd-comparison","FluxCD vs ArgoCD: GitOps ツール徹底比較","FluxCD と ArgoCD を徹底比較。アーキテクチャ、UI、マルチクラスタ対応、リソース消費、セキュリティモデル、Helm 統合まで詳しく解説。",[996,78,80,11,997,630],"fluxcd","比較",{"path":999,"title":1000,"description":1001,"date":906,"tags":1002},"\u002Fblog\u002Fja\u002Fgithub-actions-kubernetes-cicd","GitHub Actions で Kubernetes ci-cd パイプラインを構築する","GitHub Actions を活用した Kubernetes ci-cd パイプラインの構築方法を解説。Helm デプロイ、ARC による自動スケーリング、セキュリティ対策まで網羅。",[329,11,327,953,972,1003],"自動化",{"path":1005,"title":1006,"description":1007,"date":906,"tags":1008},"\u002Fblog\u002Fja\u002Fgitlab-ci-container-deployment","GitLab ci-cd でコンテナデプロイを自動化する方法","GitLab ci-cd と Kubernetes Agent を使ったコンテナデプロイの自動化を実践解説。パイプライン構成、Auto DevOps、セキュリティ設定まで詳しく紹介。",[645,327,11,972,1009,908],"auto-devops",{"path":1011,"title":1012,"description":1013,"date":906,"tags":1014},"\u002Fblog\u002Fja\u002Fgrafana-dashboard-kubernetes-observability","Grafana ダッシュボード設計: Kubernetes オブザーバビリティ実践","Grafana で Kubernetes のオブザーバビリティを実現するダッシュボード設計手法。RED メソッド、Four Golden Signals、パネル構成のベストプラクティスを解説。",[1015,11,15,1016,630,70,1017,1018],"grafana","ダッシュボード","監視","可視化",{"path":1020,"title":1021,"description":1022,"date":906,"tags":1023},"\u002Fblog\u002Fja\u002Fhelm-charts-best-practices","Helm チャート開発のベストプラクティス 2025","Helm チャート開発のベストプラクティスを 2025 年の最新動向とともに解説。テンプレート設計、テスト戦略、OCI レジストリ、セキュリティまで網羅。",[953,11,1024,1025,988,80],"パッケージ管理","チャート開発",{"path":1027,"title":1028,"description":1029,"date":906,"tags":1030},"\u002Fblog\u002Fja\u002Fk3s-edge-iot-deployment","K3s でエッジ\u002FIoT 環境に Kubernetes を展開する完全ガイド","K3s を使ってエッジ・IoT環境にKubernetesを展開する方法を、Raspberry Piデプロイからフリート管理・エアギャップ運用まで実践的に解説します。",[10,1031,1032,1033,1034,1035,1036],"エッジコンピューティング","iot","raspberry-pi","arm","フリート管理","エアギャップ",{"path":1038,"title":1039,"description":1040,"date":906,"tags":1041},"\u002Fblog\u002Fja\u002Fk3s-on-proxmox-cluster","Proxmox 上に K3s クラスタを構築する: ステップバイステップ","Proxmox VE 上に K3s 軽量 Kubernetes クラスタを構築する完全手順。VM テンプレート作成から HA 構成、ストレージ、Ingress 設定まで網羅。",[10,11,429,1042,972,1043,594],"セルフホスティング","クラスタ構築",{"path":1045,"title":1046,"description":1047,"date":906,"tags":1048},"\u002Fblog\u002Fja\u002Fk3s-production-best-practices","K3s を本番環境で運用するためのベストプラクティス完全ガイド","K3s を本番環境で安全かつ安定的に運用するためのベストプラクティスを、HA構成・セキュリティ・監視・バックアップの観点から徹底解説します。",[10,11,1049,1050,915,1051,988],"本番環境","高可用性","運用",{"path":1053,"title":1054,"description":1055,"date":906,"tags":1056},"\u002Fblog\u002Fja\u002Fk3s-vs-k8s-when-to-choose","K3s vs K8s：ユースケース別 Kubernetes 選定ガイド","K3s と標準 Kubernetes（K8s）を、アーキテクチャ・リソース消費・ユースケースの観点から徹底比較。プロジェクトに最適な選択肢がわかります。",[10,11,1057,997,1058,1059,1060],"k8s","選定ガイド","軽量Kubernetes","エッジ",{"path":1062,"title":1063,"description":1064,"date":906,"tags":1065},"\u002Fblog\u002Fja\u002Fkubernetes-cost-optimization-guide","Kubernetes コスト最適化完全ガイド：EKS\u002FAKS\u002FGKE vs Kubo 徹底比較","Kubernetes のクラウドコストを30〜50%削減する実践的な最適化戦略を解説。EKS・AKS・GKE の料金比較と Kubo の圧倒的コスト優位性を検証します。",[11,1066,1067,489,1068,62,1069,1070],"コスト最適化","eks","gke","クラウドコスト","kubo",{"path":1072,"title":1073,"description":1074,"date":906,"tags":1075},"\u002Fblog\u002Fja\u002Fkubernetes-hpa-vpa-autoscaling","Kubernetes オートスケーリング完全ガイド：HPA\u002FVPA\u002FKEDA の使い分けと実践","Kubernetes のオートスケーリング（HPA・VPA・KEDA）を完全解説。各ツールの特徴・組み合わせパターン・コスト最適化効果を実践例付きで紹介します。",[11,1076,129,130,307,138,1066],"オートスケーリング",{"path":1078,"title":1079,"description":1080,"date":906,"tags":1081},"\u002Fblog\u002Fja\u002Fkubernetes-network-policies-security","Kubernetes Network Policy によるゼロトラストセキュリティ実践ガイド","Kubernetes Network Policy でゼロトラストネットワークを実装する方法を、Default Deny からCilium\u002FCalico活用まで実例付きで徹底解説します。",[11,815,1082,915,32,191,1083],"ゼロトラスト","ネットワーク",{"path":1085,"title":1086,"description":1087,"date":906,"tags":1088},"\u002Fblog\u002Fja\u002Fopentelemetry-distributed-tracing","OpenTelemetry で分散トレーシングを実装する: 入門から実践まで","OpenTelemetry を使った分散トレーシングの実装方法を解説。Collector の構成、自動計装、Jaeger\u002FTempo との連携、Kubernetes 環境でのベストプラクティス。",[498,1089,11,630,15,1090,1091,1092],"分散トレーシング","jaeger","tempo","マイクロサービス",{"path":1094,"title":1095,"description":1096,"date":906,"tags":1097},"\u002Fblog\u002Fja\u002Fprometheus-monitoring-kubernetes-guide","Prometheus で Kubernetes を監視する完全ガイド","Prometheus を使った Kubernetes 監視の導入から運用まで。PromQL、Alertmanager、サービスディスカバリなど本番環境で必要な設定を体系的に解説します。",[70,11,1017,1098,630,15,1099,1100],"モニタリング","promql","alertmanager",{"path":1102,"title":1103,"description":1104,"date":906,"tags":1105},"\u002Fblog\u002Fja\u002Fproxmox-backup-disaster-recovery","Proxmox のバックアップと災害復旧: データ保護の完全ガイド","Proxmox Backup Server を活用した 3-2-1 バックアップ戦略、重複排除、暗号化、リモート同期、災害復旧手順を包括的に解説する実践ガイド。",[429,1106,1107,1108,1109,1110,1042],"バックアップ","災害復旧","pbs","データ保護","3-2-1ルール",{"path":1112,"title":1113,"description":1114,"date":906,"tags":1115},"\u002Fblog\u002Fja\u002Fproxmox-gpu-passthrough-ai-workloads","Proxmox GPU パススルー設定: AI\u002FML ワークロード対応","Proxmox VE で NVIDIA GPU パススルーを設定し、AI\u002FML ワークロードを実行する完全ガイド。IOMMU、VFIO 設定から Ollama、vLLM の運用まで。",[429,404,1116,886,1117,1118,1119,1120],"パススルー","機械学習","nvidia","vfio","iommu",{"path":1122,"title":1123,"description":1124,"date":906,"tags":1125},"\u002Fblog\u002Fja\u002Fproxmox-high-availability-setup","Proxmox HA クラスタの構築と運用: 可用性を最大化する","Proxmox VE の HA クラスタ構築を徹底解説。Corosync 設定、フェンシング、HA グループ、フェイルオーバー検証、メンテナンス手順まで完全網羅。",[429,1126,1050,1127,1128,1129,1130],"ha","クラスタ","フェンシング","corosync","インフラ",{"path":1132,"title":1133,"description":1134,"date":906,"tags":1135},"\u002Fblog\u002Fja\u002Fproxmox-ve-complete-setup-guide","Proxmox VE 完全セットアップガイド: インストールから運用まで","Proxmox VE のインストール手順、ストレージ設定、ネットワーク構成、セキュリティ対策まで、本番運用に必要な全ステップを網羅した完全ガイド。",[429,1136,1042,1130,1137,460,1138],"仮想化","linux","サーバー構築",{"path":1140,"title":1141,"description":1142,"date":906,"tags":1143},"\u002Fblog\u002Fja\u002Fproxmox-vs-vmware-esxi-comparison","Proxmox vs VMware ESXi: 仮想化基盤の選定ガイド","Proxmox VE と VMware ESXi を徹底比較。Broadcom 買収後のコスト変動、機能差、移行手順、エンタープライズ対応力を詳細に分析し選定を支援。",[429,1144,1145,1136,997,951,1146,1147],"vmware","esxi","broadcom","コスト削減",{"path":1149,"title":1150,"description":1151,"date":1152,"tags":1153},"\u002Fblog\u002Fja\u002Fkubernetes-ai-gpu-cost-optimization-dra","GPU利用率20%で満足してる？Kubernetes AI基盤で50-70%コスト削減を実現する動的リソース管理術","GPU利用率わずか20-30%の現状を打破。Kubernetes Dynamic Resource Allocationによる動的リソース管理で50-70%のAIインフラコスト削減を実現する2026年最新手法を解説。","2026-05-26",[11,886,404,1154,63],"dra",1794305599196]