[{"data":1,"prerenderedAt":797},["ShallowReactive",2],{"blog-ja-k3s-cilium-kube-proxy-replacement-nodeport-unreachable":3,"blog-related-ja-k3s-cilium-kube-proxy-replacement-nodeport-unreachable":746,"blog-ja-k3s-cilium-kube-proxy-replacement-nodeport-unreachable-alt":394},{"id":4,"title":5,"author":6,"body":7,"date":730,"description":731,"extension":732,"image":733,"locale":734,"meta":735,"navigation":394,"path":736,"seo":737,"stem":738,"tags":739,"__hash__":745},"blog\u002Fblog\u002Fja\u002Fk3s-cilium-kube-proxy-replacement-nodeport-unreachable.md","K3sでCiliumのkube-proxy置き換えをしたら、NodePortだけ繋がらなくなった","Kubo Team",{"type":8,"value":9,"toc":714},"minimark",[10,14,21,26,29,52,55,61,64,68,76,127,134,188,201,204,209,228,232,235,241,245,262,269,273,276,279,344,355,359,485,498,502,561,571,577,586,590,610,625,632,636,639,690,697,700,703,710],[11,12,13],"p",{},"K3sクラスタのネットワーキングをCiliumのeBPFベースのkube-proxy置き換え（kube-proxy replacement）に切り替えようとして、公式ドキュメント通りに設定したのに、なぜかNodePort経由の通信だけが届かなくなった――そんな経験はないだろうか。ClusterIP経由の通信は正常なのに、外部からNodePortで叩くと接続が返ってこない。この記事では、K3s特有の前提条件がCiliumの汎用手順とどこで食い違うのかを、実際に詰まったポイントに沿って整理する。",[11,15,16],{},[17,18],"img",{"alt":19,"src":20},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-cilium-kube-proxy-replacement-nodeport-unreachable\u002Fsection01.webp",[22,23,25],"h2",{"id":24},"_1-なぜk3sでciliumのkube-proxy-replacementを試すのか","1. なぜK3sでCiliumのkube-proxy replacementを試すのか",[11,27,28],{},"K3sは軽量Kubernetesディストリビューションとして、デフォルトでFlannel（CNI）、組み込みのkube-proxy、そしてServiceLB（旧Klipper LoadBalancer）を標準搭載している。これは「追加設定なしですぐ動く」というK3sの強みだが、本番運用でより高度な可観測性やネットワークポリシー、パフォーマンスを求める段階になると、CNCFのGraduatedプロジェクトであるCiliumへの置き換えを検討するチームが増えている。",[11,30,31,32,39,40,45,46,51],{},"Ciliumはカーネル内で動作するeBPFを使い、Service負荷分散をiptablesのような線形ルール処理ではなくハッシュテーブルで行う。これによりServiceやエンドポイントの数に関わらずO(1)に近いルックアップ時間を実現できるとされる（",[33,34,38],"a",{"href":35,"rel":36},"https:\u002F\u002Fthenewstack.io\u002Fbreaking-the-chains-of-kube-proxy-with-cilium\u002F",[37],"nofollow","The New Stackの解説記事","）。CiliumはCNCFの中でもKubernetes、OpenTelemetryに次ぐ活発さを持つプロジェクトとされ、2023年10月にCNCF Graduatedステータスを取得している（",[33,41,44],{"href":42,"rel":43},"https:\u002F\u002Fisovalent.com\u002Fblog\u002Fpost\u002Fcilium-graduates-cncf",[37],"Isovalentの公式ブログ","、",[33,47,50],{"href":48,"rel":49},"https:\u002F\u002Fcloudnativenow.com\u002Ffeatures\u002Fcncf-graduates-cilium-networking-software-project\u002F",[37],"CloudNativeNowの報道","）。",[11,53,54],{},"こうした背景から、「Flannelと組み込みkube-proxyをCiliumのkube-proxy replacementに置き換える」という構成変更は、K3sユーザーにとって現実的な選択肢になっている。問題は、Ciliumの公式手順自体は汎用的なKubernetesクラスタ（kubeadmベース）を前提に書かれており、K3s特有の初期設定をそのまま残したままでは、設定が「中途半端に二重」の状態になりやすいことだ。",[11,56,57],{},[17,58],{"alt":59,"src":60},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-cilium-kube-proxy-replacement-nodeport-unreachable\u002Fsection02.webp",[11,62,63],{},"こうした高度なCNI統合の検証自体にかかる時間は決して小さくない。こうした検証コストそのものをマネージドで肩代わりする選択肢があることも、構成変更を検討する際の判断材料になる。",[22,65,67],{"id":66},"_2-公式手順通りに導入したらnodeportだけ繋がらなくなった","2. 公式手順通りに導入したら、NodePortだけ繋がらなくなった",[11,69,70,71,51],{},"Cilium公式のK3sインストールガイドでは、マスターノードを以下のように起動することが案内されている（",[33,72,75],{"href":73,"rel":74},"https:\u002F\u002Fdocs.cilium.io\u002Fen\u002Fstable\u002Finstallation\u002Fk3s\u002F",[37],"Cilium公式ドキュメント",[77,78,83],"pre",{"className":79,"code":80,"language":81,"meta":82,"style":82},"language-bash shiki shiki-themes tokyo-night","curl -sfL https:\u002F\u002Fget.k3s.io | INSTALL_K3S_EXEC='--flannel-backend=none --disable-network-policy' sh -\n","bash","",[84,85,86],"code",{"__ignoreMap":82},[87,88,91,95,99,103,107,110,113,116,119,121,124],"span",{"class":89,"line":90},"line",1,[87,92,94],{"class":93},"sE3pS","curl",[87,96,98],{"class":97},"sT800"," -sfL",[87,100,102],{"class":101},"sPY7s"," https:\u002F\u002Fget.k3s.io",[87,104,106],{"class":105},"sAklC"," |",[87,108,109],{"class":93}," INSTALL_K3S_EXEC",[87,111,112],{"class":105},"=",[87,114,115],{"class":105},"'",[87,117,118],{"class":101},"--flannel-backend=none --disable-network-policy",[87,120,115],{"class":105},[87,122,123],{"class":93}," sh",[87,125,126],{"class":101}," -\n",[11,128,129,130,133],{},"さらにkube-proxyそのものを置き換える場合は、",[84,131,132],{},"--disable-kube-proxy"," フラグを追加する。公式ドキュメントでは、設定ファイル方式として以下も案内されている。",[77,135,139],{"className":136,"code":137,"language":138,"meta":82,"style":82},"language-yaml shiki shiki-themes tokyo-night","# \u002Fetc\u002Francher\u002Fk3s\u002Fconfig.yaml\nflannel-backend: \"none\"\ndisable-network-policy: true\ndisable-kube-proxy: true\n","yaml",[84,140,141,147,166,178],{"__ignoreMap":82},[87,142,143],{"class":89,"line":90},[87,144,146],{"class":145},"sbD-w","# \u002Fetc\u002Francher\u002Fk3s\u002Fconfig.yaml\n",[87,148,150,154,157,160,163],{"class":89,"line":149},2,[87,151,153],{"class":152},"s0U2E","flannel-backend",[87,155,156],{"class":105},":",[87,158,159],{"class":105}," \"",[87,161,162],{"class":101},"none",[87,164,165],{"class":105},"\"\n",[87,167,169,172,174],{"class":89,"line":168},3,[87,170,171],{"class":152},"disable-network-policy",[87,173,156],{"class":105},[87,175,177],{"class":176},"sOJ5S"," true\n",[87,179,181,184,186],{"class":89,"line":180},4,[87,182,183],{"class":152},"disable-kube-proxy",[87,185,156],{"class":105},[87,187,177],{"class":176},[11,189,190,191,195,196,51],{},"ここまでは多くの解説記事でも紹介されている標準手順だ。しかし、この状態でCiliumをHelmでインストールし、ClusterIP経由の疎通は確認できても、",[192,193,194],"strong",{},"NodePort経由だけアクセスできない","という事象に遭遇するケースが報告されている。Cilium公式のトラブルシューティング文脈でも、ネットワークインターフェースに紐づくIPアドレスの扱いによってNodePortが機能しないパターンが実際にIssueとして記録されている（",[33,197,200],{"href":198,"rel":199},"https:\u002F\u002Fgithub.com\u002Fcilium\u002Fcilium\u002Fissues\u002F12317",[37],"cilium\u002Fcilium Issue #12317",[11,202,203],{},"K3s特有の環境では、この事象の背景に次の3つの要因が複合的に絡んでいることが多い。",[205,206,208],"h3",{"id":207},"要因1-servicelb旧klipperが残ったままになっている","要因1: ServiceLB（旧Klipper）が残ったままになっている",[11,210,211,212,51,217,220,221,223,224,227],{},"K3sはデフォルトでServiceLBと呼ばれる簡易ロードバランサーを提供しており、LoadBalancerタイプのServiceに対してhostPortを使ったDaemonSetを各ノードに展開する（",[33,213,216],{"href":214,"rel":215},"https:\u002F\u002Fdocumentation.suse.com\u002Fcloudnative\u002Fk3s\u002Flatest\u002Fen\u002Fnetworking\u002Fnetworking-services.html",[37],"SUSE公式のK3sネットワーキングドキュメント",[84,218,219],{},"--flannel-backend=none"," や ",[84,222,132],{}," を指定しても、ServiceLBは",[192,225,226],{},"自動的には無効化されない","。この状態でCiliumのeBPFロードバランシングとServiceLBのhostPortバインドが同じノード上で競合し、期待したNodePortにトラフィックが届かなくなることがある。",[205,229,231],{"id":230},"要因2-traefikのデフォルト構成がservicelbに依存している","要因2: Traefikのデフォルト構成がServiceLBに依存している",[11,233,234],{},"K3sはデフォルトでTraefik Ingressコントローラーをデプロイし、ポート80\u002F443を使うLoadBalancer Serviceを公開する。このLoadBalancer Serviceの経路も標準ではServiceLBに依存しているため、要因1の問題を解消しないままTraefikだけ有効にしておくと、Ingress経由の通信も不安定になる。",[11,236,237],{},[17,238],{"alt":239,"src":240},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-cilium-kube-proxy-replacement-nodeport-unreachable\u002Fsection03.webp",[205,242,244],{"id":243},"要因3-apiサーバーへの接続情報k8sservicehostk8sserviceportの未設定","要因3: APIサーバーへの接続情報（k8sServiceHost\u002Fk8sServicePort）の未設定",[11,246,247,248,251,252,255,256,261],{},"kube-proxyを取り除いた構成では、kube-proxyが担っていた「APIサーバーServiceのプロキシ」機能も失われる。Cilium公式ドキュメントは、この状態でCiliumエージェントがAPIサーバーに到達できるよう、",[84,249,250],{},"k8sServiceHost"," と ",[84,253,254],{},"k8sServicePort"," を明示的に指定する必要があると説明している（",[33,257,260],{"href":258,"rel":259},"https:\u002F\u002Fdocs.cilium.io\u002Fen\u002Flatest\u002Fnetwork\u002Fkubernetes\u002Fkubeproxy-free\u002F",[37],"Cilium公式: Kubernetes Without kube-proxy","）。K3sのクイックスタート手順ではこの設定が省略されがちで、結果としてCiliumエージェントの初期化が不完全なまま起動し、Service連携全体が不安定になるケースがある。",[11,263,264,265,268],{},"同ドキュメントはさらに、既存のkube-proxyとCiliumのNATテーブルが互いを認識できないため、",[192,266,267],{},"両者が一時的にでも共存すると接続が切断される可能性がある","と明記している。K3sのように複数のネットワークコンポーネントがデフォルトで同梱されているディストリビューションでは、この「一時的な共存」が起きやすい。",[22,270,272],{"id":271},"_3-k3s向けの具体的な設定差分","3. K3s向けの具体的な設定差分",[11,274,275],{},"上記3つの要因を踏まえ、K3s環境でCiliumのkube-proxy replacementを安定稼働させるための設定を整理する。",[205,277,278],{"id":278},"マスターノードの起動オプション",[77,280,282],{"className":79,"code":281,"language":81,"meta":82,"style":82},"curl -sfL https:\u002F\u002Fget.k3s.io | INSTALL_K3S_EXEC=\"\\\n  --flannel-backend=none \\\n  --disable-network-policy \\\n  --disable-kube-proxy \\\n  --disable=servicelb \\\n  --disable=traefik\" sh -\n",[84,283,284,301,309,316,323,331],{"__ignoreMap":82},[87,285,286,288,290,292,294,296,298],{"class":89,"line":90},[87,287,94],{"class":93},[87,289,98],{"class":97},[87,291,102],{"class":101},[87,293,106],{"class":105},[87,295,109],{"class":93},[87,297,112],{"class":105},[87,299,300],{"class":105},"\"\\\n",[87,302,303,306],{"class":89,"line":149},[87,304,305],{"class":101},"  --flannel-backend=none ",[87,307,308],{"class":105},"\\\n",[87,310,311,314],{"class":89,"line":168},[87,312,313],{"class":101},"  --disable-network-policy ",[87,315,308],{"class":105},[87,317,318,321],{"class":89,"line":180},[87,319,320],{"class":101},"  --disable-kube-proxy ",[87,322,308],{"class":105},[87,324,326,329],{"class":89,"line":325},5,[87,327,328],{"class":101},"  --disable=servicelb ",[87,330,308],{"class":105},[87,332,334,337,340,342],{"class":89,"line":333},6,[87,335,336],{"class":101},"  --disable=traefik",[87,338,339],{"class":105},"\"",[87,341,123],{"class":93},[87,343,126],{"class":101},[11,345,346,347,350,351,354],{},"Cilium公式手順に加えて、",[84,348,349],{},"--disable=servicelb"," を明示的に追加するのがポイントだ。Traefikを引き続き使う場合は ",[84,352,353],{},"--disable=traefik"," を外し、後述のNodePort検証を終えてから有効化するとトラブルシュートが切り分けやすい。",[205,356,358],{"id":357},"cilium-helmインストール時の必須パラメータ","Cilium Helmインストール時の必須パラメータ",[77,360,362],{"className":79,"code":361,"language":81,"meta":82,"style":82},"helm repo add cilium https:\u002F\u002Fhelm.cilium.io\u002F\nhelm repo update\n\nhelm install cilium cilium\u002Fcilium \\\n  --namespace kube-system \\\n  --set kubeProxyReplacement=true \\\n  --set k8sServiceHost=\u003CAPI_SERVER_IP> \\\n  --set k8sServicePort=6443 \\\n  --set ipam.operator.clusterPoolIPv4PodCIDRList=\"10.42.0.0\u002F16\"\n",[84,363,364,381,390,396,411,421,434,457,470],{"__ignoreMap":82},[87,365,366,369,372,375,378],{"class":89,"line":90},[87,367,368],{"class":93},"helm",[87,370,371],{"class":101}," repo",[87,373,374],{"class":101}," add",[87,376,377],{"class":101}," cilium",[87,379,380],{"class":101}," https:\u002F\u002Fhelm.cilium.io\u002F\n",[87,382,383,385,387],{"class":89,"line":149},[87,384,368],{"class":93},[87,386,371],{"class":101},[87,388,389],{"class":101}," update\n",[87,391,392],{"class":89,"line":168},[87,393,395],{"emptyLinePlaceholder":394},true,"\n",[87,397,398,400,403,405,408],{"class":89,"line":180},[87,399,368],{"class":93},[87,401,402],{"class":101}," install",[87,404,377],{"class":101},[87,406,407],{"class":101}," cilium\u002Fcilium",[87,409,410],{"class":105}," \\\n",[87,412,413,416,419],{"class":89,"line":325},[87,414,415],{"class":97},"  --namespace",[87,417,418],{"class":101}," kube-system",[87,420,410],{"class":105},[87,422,423,426,429,432],{"class":89,"line":333},[87,424,425],{"class":97},"  --set",[87,427,428],{"class":101}," kubeProxyReplacement=",[87,430,431],{"class":176},"true",[87,433,410],{"class":105},[87,435,437,439,442,445,448,452,455],{"class":89,"line":436},7,[87,438,425],{"class":97},[87,440,441],{"class":101}," k8sServiceHost=",[87,443,444],{"class":105},"\u003C",[87,446,447],{"class":101},"API_SERVER_I",[87,449,451],{"class":450},"sGX4V","P",[87,453,454],{"class":105},">",[87,456,410],{"class":105},[87,458,460,462,465,468],{"class":89,"line":459},8,[87,461,425],{"class":97},[87,463,464],{"class":101}," k8sServicePort=",[87,466,467],{"class":176},"6443",[87,469,410],{"class":105},[87,471,473,475,478,480,483],{"class":89,"line":472},9,[87,474,425],{"class":97},[87,476,477],{"class":101}," ipam.operator.clusterPoolIPv4PodCIDRList=",[87,479,339],{"class":105},[87,481,482],{"class":101},"10.42.0.0\u002F16",[87,484,165],{"class":105},[11,486,487,490,491,493,494,51],{},[84,488,489],{},"\u003CAPI_SERVER_IP>"," には、各ワーカーノードから到達可能なAPIサーバーのIPアドレス（マスターノードのIPまたはHA構成ならロードバランサーVIP）を指定する。K3sのデフォルトPod CIDR（",[84,492,482],{},"）と一致させることも忘れてはならない。この値はCilium公式のK3sインストールガイドでも明示されている（",[33,495,497],{"href":73,"rel":496},[37],"Cilium公式ドキュメント: Installation Using K3s",[205,499,501],{"id":500},"nodeport疎通確認","NodePort疎通確認",[77,503,505],{"className":79,"code":504,"language":81,"meta":82,"style":82},"# Ciliumのサービス一覧にNodePortが登録されているか確認\ncilium service list\n\n# 実際にNodePortへアクセスして確認\ncurl http:\u002F\u002F\u003CNODE_IP>:\u003CNODE_PORT>\n",[84,506,507,512,523,527,532],{"__ignoreMap":82},[87,508,509],{"class":89,"line":90},[87,510,511],{"class":145},"# Ciliumのサービス一覧にNodePortが登録されているか確認\n",[87,513,514,517,520],{"class":89,"line":149},[87,515,516],{"class":93},"cilium",[87,518,519],{"class":101}," service",[87,521,522],{"class":101}," list\n",[87,524,525],{"class":89,"line":168},[87,526,395],{"emptyLinePlaceholder":394},[87,528,529],{"class":89,"line":180},[87,530,531],{"class":145},"# 実際にNodePortへアクセスして確認\n",[87,533,534,536,539,541,544,546,548,550,552,555,558],{"class":89,"line":325},[87,535,94],{"class":93},[87,537,538],{"class":101}," http:\u002F\u002F",[87,540,444],{"class":105},[87,542,543],{"class":101},"NODE_I",[87,545,451],{"class":450},[87,547,454],{"class":105},[87,549,156],{"class":101},[87,551,444],{"class":105},[87,553,554],{"class":101},"NODE_POR",[87,556,557],{"class":450},"T",[87,559,560],{"class":105},">\n",[11,562,563,566,567,570],{},[84,564,565],{},"cilium service list"," の出力にNodePortエントリが見当たらない場合、ServiceLBのhostPortバインドが競合している可能性が高い。",[84,568,569],{},"kubectl get pods -n kube-system -l app=svclb"," でServiceLB由来のPodが残っていないかを確認するとよい。",[11,572,573],{},[17,574],{"alt":575,"src":576},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-cilium-kube-proxy-replacement-nodeport-unreachable\u002Fsection04.webp",[11,578,579,580,585],{},"CiliumのService実装がこうして安定すると、こうしたネットワーク基盤の標準化はKubo CloudのようなPure Kubernetesを前提としたマネージド環境でも同じ考え方で再現できる。",[33,581,584],{"href":582,"rel":583},"https:\u002F\u002Fkubo.hexabase.io\u002F",[37],"Kubo"," はK3sベースでありながら標準Kubernetes API互換を維持しているため、CiliumのようなCNCF Graduatedプロジェクトをロックインなくそのまま組み込める。",[22,587,589],{"id":588},"_4-externaltrafficpolicyとtraefikを組み合わせる際の注意点","4. externalTrafficPolicyとTraefikを組み合わせる際の注意点",[11,591,592,593,596,597,600,601,604,605,51],{},"ServiceLBとTraefikを無効化してCilium主体の構成に移行した後、改めてIngress経由のトラフィックを扱う場合は ",[84,594,595],{},"externalTrafficPolicy"," の設定にも注意が必要だ。Kubernetes公式ドキュメントによれば、",[84,598,599],{},"externalTrafficPolicy: Cluster","（デフォルト）はクラスタ内のどのノードのPodにもトラフィックを転送できる一方でホップが増える可能性があり、",[84,602,603],{},"externalTrafficPolicy: Local"," は同一ノード上のPodにのみ転送することでクライアントIPを保持できる（",[33,606,609],{"href":607,"rel":608},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Freference\u002Fnetworking\u002Fvirtual-ips\u002F#external-traffic-policy",[37],"Kubernetes公式: Virtual IPs and Service Proxies",[11,611,612,613,615,616,619,620,624],{},"K3s公式ドキュメントは、NAT環境（パブリッククラウドなど）で ",[84,614,603],{}," を使ってクライアント送信元IPを保持したい場合、各ノードに ",[84,617,618],{},"node-external-ip"," を設定しないことを推奨している（",[33,621,623],{"href":214,"rel":622},[37],"SUSE公式K3sドキュメント","）。CiliumのeBPFロードバランサーに置き換えた後も、この制約自体はKubernetesのService仕様に基づくものであるため解消されない点に注意したい。",[11,626,627,628,631],{},"こうした細かい設定差分を一つずつ洗い出す作業は、オンプレミスで標準K8s運用の経験があるインフラエンジニアでも時間がかかる。",[33,629,584],{"href":582,"rel":630},[37]," のCaptain UIはクラスタの可視化された管理画面を提供しており、ServiceLBやkube-proxyの状態をブラックボックス化せずに確認できる構成を標準搭載している。",[22,633,635],{"id":634},"_5-本番投入前のチェックリスト","5. 本番投入前のチェックリスト",[11,637,638],{},"K3s + Ciliumのkube-proxy replacement構成を本番投入する前に、最低限次の項目を確認したい。",[640,641,642,652,661,668,673,680],"ul",{},[643,644,645,648,649,651],"li",{},[192,646,647],{},"ServiceLBが完全に無効化されているか",": ",[84,650,569],{}," で何も返らないことを確認",[643,653,654,648,657,660],{},[192,655,656],{},"Cilium Helm値にk8sServiceHost\u002Fk8sServicePortが設定されているか",[84,658,659],{},"helm get values cilium -n kube-system"," で確認",[643,662,663],{},[192,664,665,667],{},[84,666,565],{}," にNodePortエントリが登録されているか",[643,669,670],{},[192,671,672],{},"Pod CIDRがK3sのデフォルト（10.42.0.0\u002F16）または変更後の値と一致しているか",[643,674,675],{},[192,676,677,679],{},[84,678,595],{}," の設定意図（Cluster\u002FLocal）がIngress\u002FLoadBalancer構成と整合しているか",[643,681,682,685,686,689],{},[192,683,684],{},"移行作業中にkube-proxyとCiliumが一時的にでも共存していないか","（",[33,687,75],{"href":258,"rel":688},[37],"が警告する通り、NATテーブルの不整合による接続断を避けるため）",[11,691,692,693,696],{},"これらを一つずつ検証する作業は、構成管理の属人化を招きやすい部分でもある。AI-Driven Deploymentを特徴とする",[33,694,584],{"href":582,"rel":695},[37],"であれば、こうした検証・設定差分の洗い出しをAIに任せた上で、月額48,000円〜というコストで本格的なK3sベースのKubernetesクラスタを運用できる。",[22,698,699],{"id":699},"まとめ",[11,701,702],{},"K3sでCiliumのkube-proxy置き換えを試すと、公式手順だけでは見落としがちなK3s特有の前提（ServiceLBの残存、Traefikの依存関係、k8sServiceHost\u002Fk8sServicePortの未設定）によってNodePortが届かなくなることがある。原因は「Ciliumの手順が間違っている」のではなく、「K3sがデフォルトで同梱しているネットワークコンポーネントを明示的に無効化し切れていない」ことにある。ServiceLBとTraefikの無効化、Cilium Helm値の明示的な設定、そしてNodePort疎通確認を一つずつ積み重ねることで、K3sでも標準Kubernetesクラスタと同じeBPFベースのネットワーキングを安定運用できる。",[11,704,705,706,709],{},"マネージドK8sの世界では、EKSやAKSの高コストと複雑さ、ベンダーロックインに悩む必要はもうない。K3sベースの",[33,707,584],{"href":582,"rel":708},[37],"なら、Ciliumのような本格的なCNCFプロジェクトの機能をそのまま活かしながら、圧倒的なコスト効率で運用できる。",[711,712,713],"style",{},"html pre.shiki code .sE3pS, html code.shiki .sE3pS{--shiki-default:#C0CAF5}html pre.shiki code .sT800, html code.shiki .sT800{--shiki-default:#E0AF68}html pre.shiki code .sPY7s, html code.shiki .sPY7s{--shiki-default:#9ECE6A}html pre.shiki code .sAklC, html code.shiki .sAklC{--shiki-default:#89DDFF}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html pre.shiki code .sbD-w, html code.shiki .sbD-w{--shiki-default:#51597D;--shiki-default-font-style:italic}html pre.shiki code .s0U2E, html code.shiki .s0U2E{--shiki-default:#F7768E}html pre.shiki code .sOJ5S, html code.shiki .sOJ5S{--shiki-default:#FF9E64}html pre.shiki code .sGX4V, html code.shiki .sGX4V{--shiki-default:#A9B1D6}",{"title":82,"searchDepth":149,"depth":149,"links":715},[716,717,722,727,728,729],{"id":24,"depth":149,"text":25},{"id":66,"depth":149,"text":67,"children":718},[719,720,721],{"id":207,"depth":168,"text":208},{"id":230,"depth":168,"text":231},{"id":243,"depth":168,"text":244},{"id":271,"depth":149,"text":272,"children":723},[724,725,726],{"id":278,"depth":168,"text":278},{"id":357,"depth":168,"text":358},{"id":500,"depth":168,"text":501},{"id":588,"depth":149,"text":589},{"id":634,"depth":149,"text":635},{"id":699,"depth":149,"text":699},"2026-11-07","K3sにCiliumのkube-proxy replacementを公式手順通りに導入したら、NodePort経由の通信だけが届かなくなった。原因はFlannelやServiceLB(Klipper)との競合、k8sServiceHost未設定などK3s特有の設定差分にあった。本番投入前のチェックリストを解説。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-cilium-kube-proxy-replacement-nodeport-unreachable\u002Ftitle.webp","ja",{},"\u002Fblog\u002Fja\u002Fk3s-cilium-kube-proxy-replacement-nodeport-unreachable",{"title":5,"description":731},"blog\u002Fja\u002Fk3s-cilium-kube-proxy-replacement-nodeport-unreachable",[740,741,516,742,743,744],"k3s","kubernetes","ebpf","kube-proxy","networking","V36eqzGtyIrZHFZYpLo3g9HL9V_ZxzdTvR2LEJr7ReQ",[747,757,766,774,781,789],{"path":748,"title":749,"description":750,"date":751,"tags":752},"\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",[740,741,753,754,755,516,756,744],"cni","flannel","calico","networkpolicy",{"path":758,"title":759,"description":760,"date":761,"tags":762},"\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",[740,741,763,764,765,744],"gateway-api","traefik","ingress",{"path":767,"title":768,"description":769,"date":770,"tags":771},"\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",[740,741,744,772,754,773],"vxlan","mtu",{"path":775,"title":776,"description":777,"date":778,"tags":779},"\u002Fblog\u002Fja\u002Fkubernetes-cni-overlay-network-troubleshooting-ospf","OSPFなら1分で直る障害が、KubernetesのCNIだと半日かかる理由","Kubernetesのオーバーレイネットワークはなぜトラブルシューティングに時間がかかるのか。CNIの仕組み、Flannel VXLANとCalico BGPの違い、MTU不一致の切り分け手順まで、K3s運用者が押さえるべきポイントを解説する。","2026-08-16",[740,741,753,780,744],"overlay-network",{"path":782,"title":783,"description":784,"date":785,"tags":786},"\u002Fblog\u002Fja\u002Fkubernetes-ebpf-inspektor-gadget-observability","strace禁止、sidecar禁止、それでも診断できる。KubernetesをeBPFで透視するInspektor Gadgetという回答","特権コンテナもsidecarも追加できない本番Kubernetesで、Podの通信とシステムコールをどう診断するか。eBPFツール「Inspektor Gadget」の仕組みと2026年の最新動向を解説する。","2026-08-15",[740,741,742,787,788],"observability","cncf",{"path":790,"title":791,"description":792,"date":793,"tags":794},"\u002Fblog\u002Fja\u002Fkubevirt-calico-live-migration-networking","VMを動かしても通信は切れない。KubeVirtとCalicoが実現するKubernetesライブマイグレーションの舞台裏","KubernetesでVM（KubeVirt）をノード間へライブマイグレーションしても、なぜ通信が切れないのか。CalicoのIP永続化・BGPルート収束の仕組みと、VMware移行先としての実務的な意味を解説する。","2026-08-07",[740,741,795,744,796],"kubevirt","managed-kubernetes",1794305479212]