[{"data":1,"prerenderedAt":463},["ShallowReactive",2],{"blog-ja-k3s-service-mesh-linkerd-istio-ambient-mesh-decision":3,"blog-related-ja-k3s-service-mesh-linkerd-istio-ambient-mesh-decision":405,"blog-ja-k3s-service-mesh-linkerd-istio-ambient-mesh-decision-alt":393},{"id":4,"title":5,"author":6,"body":7,"date":387,"description":388,"extension":389,"image":390,"locale":391,"meta":392,"navigation":393,"path":394,"seo":395,"stem":396,"tags":397,"__hash__":404},"blog\u002Fblog\u002Fja\u002Fk3s-service-mesh-linkerd-istio-ambient-mesh-decision.md","K3sにサービスメッシュを足したら、軽くなったのはLinkerdだった。Istio Ambient Meshとの分かれ道","Kubo Team",{"type":8,"value":9,"toc":378},"minimark",[10,15,19,26,29,40,44,50,53,66,77,92,96,102,105,133,142,149,156,160,166,169,190,256,277,280,284,290,293,306,309,313,319,322,336,343,346,349,355,374],[11,12,14],"h2",{"id":13},"_1-なぜ今k3sにサービスメッシュを検討するのか","1. なぜ今、K3sにサービスメッシュを検討するのか",[16,17,18],"p",{},"K3sを選ぶ理由は、たいてい「軽量であること」だ。シングルバイナリで動き、リソースの限られたエッジやオンプレのノードにも収まる。そこにサービスメッシュを足すという話は、一見するとその前提と矛盾しているように聞こえる。",[16,20,21],{},[22,23],"img",{"alt":24,"src":25},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-service-mesh-linkerd-istio-ambient-mesh-decision\u002Fsection01.webp",[16,27,28],{},"だが実際には、マルチサービス構成のK3sクラスタでmTLS通信や可観測性を求める声は増えている。問題は「サービスメッシュを入れるかどうか」ではなく、「K3sという軽量環境に合う構成はどちらか」だ。ここでは、代表的な2つの選択肢であるLinkerdとIstio Ambient Meshを、実際のリソース数値とK3s特有のハマりどころを踏まえて比較する。",[16,30,31,32,39],{},"Kubernetesの運用を軽くしたいというP1（インフラエンジニア／SRE）の関心事に対して、サービスメッシュはむしろ「足すことで重くなるかもしれない」変数だ。",[33,34,38],"a",{"href":35,"rel":36},"https:\u002F\u002Fkubo.hexabase.io\u002F",[37],"nofollow","Kubo"," のようなK3sベースのマネージド環境を使っていても、アドオンの選定判断そのものは自分たちで下す必要がある。",[11,41,43],{"id":42},"_2-linkerdとistio-ambient-mesh構造がまるで違う","2. LinkerdとIstio Ambient Mesh、構造がまるで違う",[16,45,46],{},[22,47],{"alt":48,"src":49},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-service-mesh-linkerd-istio-ambient-mesh-decision\u002Fsection02.webp",[16,51,52],{},"両者は「サイドカーを使わない」という共通点を持ちながら、内部構造がまったく異なる。",[16,54,55,59,60,65],{},[56,57,58],"strong",{},"Linkerd","は単一層構造だ。Pod横に配置されるRust製のマイクロプロキシが、L4とL7の両方を1つのプロセスで処理する。L7の機能（リトライやタイムアウトなど）を有効にしても、追加されるのは設定だけで、プロキシの階層は増えない。",[33,61,64],{"href":62,"rel":63},"https:\u002F\u002Fwww.buoyant.io\u002Farticles\u002Flinkerd-vs-istio-ambient-mode-an-operators-architecture-comparison-for-2026",[37],"Buoyantの2026年のアーキテクチャ比較記事","は、この違いを「1種類のプロキシと設定変更」対「2種類のプロキシとトポロジー変更」という言葉で表現している。",[16,67,68,71,72,76],{},[56,69,70],{},"Istio Ambient Mesh","は2層構造になる。ノードごとに共有される軽量なL4プロキシ「ztunnel」がまずすべての通信を受け持ち、HTTPルーティングや認可ポリシーのようなL7機能が必要なネームスペースにだけ、Envoyベースの「waypoint」プロキシが追加される。トラフィックは ",[73,74,75],"code",{},"source ztunnel → waypoint → destination ztunnel"," という経路をたどることになり、L7を使うかどうかでネットワークトポロジー自体が変わる。",[16,78,79,80,85,86,91],{},"Ambient Modeは2024年11月公開のIstio v1.24でGAに到達し、ztunnel・waypoint・関連APIがIstioのTechnical Oversight Committeeによって「Stable」と認定された(",[33,81,84],{"href":82,"rel":83},"https:\u002F\u002Fistio.io\u002Flatest\u002Fblog\u002F2024\u002Fambient-reaches-ga\u002F",[37],"Istio公式ブログ","、",[33,87,90],{"href":88,"rel":89},"https:\u002F\u002Fwww.cncf.io\u002Fblog\u002F2024\u002F11\u002F07\u002Ffast-secure-and-simple-istios-ambient-mode-reaches-general-availability-in-v1-24\u002F",[37],"CNCF Blog",")。2022年9月の構想発表から26ヶ月かけて安定版になった経緯を見ても、決して思いつきの機能ではない。",[11,93,95],{"id":94},"_3-リソース使用量を数字で見る","3. リソース使用量を数字で見る",[16,97,98],{},[22,99],{"alt":100,"src":101},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-service-mesh-linkerd-istio-ambient-mesh-decision\u002Fsection03.webp",[16,103,104],{},"「軽量である」を数字で確認する。",[106,107,108,121,127],"ul",{},[109,110,111,114,115,120],"li",{},[56,112,113],{},"Linkerdのマイクロプロキシ",": 1インスタンスあたりメモリ10〜20MB程度、CPUは1コアの1\u002F4以下という報告がある。ARM64\u002FARMv7にネイティブ対応しており、Raspberry Piのような小型ノードでも動く(",[33,116,119],{"href":117,"rel":118},"https:\u002F\u002Fwww.buoyant.io\u002Fkubernetes-service-mesh-edge",[37],"Buoyantのエッジ環境向け記事",")。",[109,122,123,126],{},[56,124,125],{},"Istio sidecarモード",": Pod1つごとにEnvoyインスタンスが立つため、メモリは1podあたり50〜100MB。100Pod規模のクラスタでは、プロキシだけで25〜30GiBのメモリを消費するという試算もある。",[109,128,129,132],{},[56,130,131],{},"Istio Ambient（ztunnel）",": L4プロキシがノードで共有されるため、同じ100Pod規模で3〜4GiBまで圧縮できるという報告がある。",[16,134,135,136,141],{},"実測ベンチマークでも傾向は同様だ。",[33,137,140],{"href":138,"rel":139},"https:\u002F\u002Foneuptime.com\u002Fblog\u002Fpost\u002F2026-02-24-how-to-benchmark-istio-ambient-vs-sidecar-performance\u002Fview",[37],"oneuptime.comのベンチマーク記事","では、L4のみのトラフィックであればAmbientの平均レイテンシは約3.2msで、sidecarモードの約4.8msより速く、スループットもAmbientが約5000QPSに対しsidecarが約3330QPSという結果が出ている。ただし同記事は「L7機能を多用するワークロードでは性能差が縮まる」とも指摘しており、ワークロードの性質によって有利不利が変わる点には注意が必要だ。",[16,143,144,145,148],{},"K3sの前提であるリソース制約を考えると、",[56,146,147],{},"LinkerdとIstio Ambientはどちらもsidecar型のIstioより現実的","だが、Pod数が数百規模になるほどノード共有型のAmbientが効いてくる、というのが数字から見える傾向になる。",[16,150,151,152,155],{},"こうしたプロキシのメモリ・CPU使用量は、ノードのリソースが逼迫してから初めて気づくことが多い。",[33,153,38],{"href":35,"rel":154},[37]," のCaptain UIはノード単位のリソース使用状況を可視化するため、サービスメッシュのようなアドオンを追加した際の変化にも早い段階で気づける。",[11,157,159],{"id":158},"_4-k3sで実際にハマったポイント-cniパス設定","4. K3sで実際にハマったポイント — CNIパス設定",[16,161,162],{},[22,163],{"alt":164,"src":165},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-service-mesh-linkerd-istio-ambient-mesh-decision\u002Fsection04.webp",[16,167,168],{},"K3sにIstio Ambient Meshを入れる際、最初につまずきやすいのがCNI設定のパスだ。",[16,170,171,172,175,176,179,180,185,186,189],{},"K3sはCNIプラグインのバイナリを ",[73,173,174],{},"$DATA_DIR\u002Fdata\u002Fcni","（デフォルトでは ",[73,177,178],{},"\u002Fvar\u002Flib\u002Francher\u002Fk3s\u002Fdata\u002Fcni","）に配置するなど、標準的なKubernetesディストリビューションとは異なる非標準の場所を使う(",[33,181,184],{"href":182,"rel":183},"https:\u002F\u002Fdocs.k3s.io\u002Fnetworking\u002Fmultus-ipams",[37],"K3s公式ドキュメント",")。この違いを吸収するため、Istioのインストール時には ",[73,187,188],{},"global.platform=k3s"," の指定が必須になる。",[191,192,197],"pre",{"className":193,"code":194,"language":195,"meta":196,"style":196},"language-bash shiki shiki-themes tokyo-night","helm install istio-cni istio\u002Fcni -n istio-system \\\n  --set profile=ambient \\\n  --set global.platform=k3s \\\n  --wait\n","bash","",[73,198,199,229,240,250],{"__ignoreMap":196},[200,201,204,208,212,215,218,222,225],"span",{"class":202,"line":203},"line",1,[200,205,207],{"class":206},"sE3pS","helm",[200,209,211],{"class":210},"sPY7s"," install",[200,213,214],{"class":210}," istio-cni",[200,216,217],{"class":210}," istio\u002Fcni",[200,219,221],{"class":220},"sT800"," -n",[200,223,224],{"class":210}," istio-system",[200,226,228],{"class":227},"sAklC"," \\\n",[200,230,232,235,238],{"class":202,"line":231},2,[200,233,234],{"class":220},"  --set",[200,236,237],{"class":210}," profile=ambient",[200,239,228],{"class":227},[200,241,243,245,248],{"class":202,"line":242},3,[200,244,234],{"class":220},[200,246,247],{"class":210}," global.platform=k3s",[200,249,228],{"class":227},[200,251,253],{"class":202,"line":252},4,[200,254,255],{"class":220},"  --wait\n",[16,257,258,259,262,263,266,267,270,271,276],{},"この指定を忘れると、",[73,260,261],{},"istio-cni"," がK3sのデフォルトCNIであるFlannelの設定ファイルを見つけられず、ztunnelとの接続が確立しないままPodが起動に失敗する。カスタムCNIを使っている場合は、さらに ",[73,264,265],{},"cniConfDir"," と ",[73,268,269],{},"cniBinDir"," を明示的に指定する必要があると",[33,272,275],{"href":273,"rel":274},"https:\u002F\u002Fistio.io\u002Flatest\u002Fdocs\u002Fambient\u002Finstall\u002Fplatform-prerequisites\u002F",[37],"Istio公式のプラットフォーム別要件ドキュメント","には書かれている。K3sのシンプルさに慣れていると見落としやすい設定だ。",[16,278,279],{},"なお、K3sのデフォルトCNIであるFlannelはL7検査やNetworkPolicyの実装を持たないシンプルな構成のため、Istioのトラフィックインターセプト自体を妨げにくい。相性という意味では悪くない組み合わせになる。",[11,281,283],{"id":282},"_5-waypointが静かに素通りする既知の挙動","5. waypointが「静かに素通りする」既知の挙動",[16,285,286],{},[22,287],{"alt":288,"src":289},"section05","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-service-mesh-linkerd-istio-ambient-mesh-decision\u002Fsection05.webp",[16,291,292],{},"もう一つ、運用前提として知っておくべき挙動がある。",[16,294,295,296,299,300,305],{},"Istio 1.27.1環境で、waypointを正しくデプロイし、対象サービスに ",[73,297,298],{},"istio.io\u002Fuse-waypoint"," ラベルを付け、AuthorizationPolicyのtargetRefsも正しく設定しているにもかかわらず、L7ポリシーが適用されないという事象が",[33,301,304],{"href":302,"rel":303},"https:\u002F\u002Fgithub.com\u002Fistio\u002Fistio\u002Fissues\u002F58432",[37],"istio\u002Fistioの公開Issue","で報告されている。トラフィックがwaypointを経由せず、ztunnel経由のL4のみで宛先に直接流れてしまうケースだ。",[16,307,308],{},"Ambient Meshの設計では、L4ポリシーはztunnel単体で強制でき、L7ポリシーだけがwaypointを必要とする。waypointへのルーティングに問題があるとき、ztunnelは通信を許可してしまうのではなく「フェイルセーフでトラフィックを拒否する」設計になっている。今回のIssueのように意図せず素通りするケースがあるのは事実だが、これは執筆時点でオープンな既知の課題であり、今後のマイナーバージョンで解消される可能性がある点は踏まえておきたい。裏を返せば、L7ポリシーを本番のセキュリティ境界として使う場合は、設定後に実際のトラフィックログで経路を確認する運用ステップを省略できない、ということでもある。",[11,310,312],{"id":311},"_6-どちらを選ぶべきか-判断基準","6. どちらを選ぶべきか — 判断基準",[16,314,315],{},[22,316],{"alt":317,"src":318},"section06","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-service-mesh-linkerd-istio-ambient-mesh-decision\u002Fsection06.webp",[16,320,321],{},"ここまでの内容を整理すると、判断基準は次のように単純化できる。",[106,323,324,330],{},[109,325,326,329],{},[56,327,328],{},"カナリアリリース、フォールトインジェクション、細かいHTTPルーティングなど、L7のトラフィック管理機能が本番要件として必須"," → Istio Ambient Mesh。waypointの運用コストを払ってでも得られる機能が多い",[109,331,332,335],{},[56,333,334],{},"必要なのはmTLSと基本的な可観測性で、運用チームの人数が少ない"," → Linkerd。プロキシが1種類で済み、アップグレードの影響範囲も小さい",[16,337,338,342],{},[33,339,341],{"href":62,"rel":340},[37],"Buoyantの比較記事","は判断のチェックリストとして「運用対象コンポーネント数」「アップグレードプロセスの複雑さ」「障害時のトレーサビリティ」「1年後のアーキテクチャがどうなっているか」「各プロジェクトの信頼性の実績」の5項目を挙げている。K3sの文脈に置き換えるなら、ここに「そのノードのリソースに本当に余裕があるか」を加えて考えるべきだろう。",[11,344,345],{"id":345},"まとめ",[16,347,348],{},"K3sは軽量であることが価値の前提だ。サービスメッシュを足すこと自体は否定されるべきものではないが、「何を選ぶか」でその前提が簡単に崩れる。LinkerdはPodあたり10〜20MBという軽さでK3sの思想と親和性が高く、Istio Ambient Meshは2024年のGA以降Stableな機能として、L7の高度なトラフィック管理が必要なチームにとって現実的な選択肢になった。",[16,350,351,352,354],{},"一方で、",[73,353,188],{}," のような設定の見落としや、waypointのルーティングに関する既知の課題のように、実際に手を動かして初めて分かる落とし穴もある。こうしたアドオンの選定・検証・アップグレード対応まで含めた運用は、決して小さな負荷ではない。",[16,356,357,361,362,367,368,373],{},[33,358,360],{"href":35,"rel":359},[37],"Kubo Cloud"," はK3sベースのマネージドKubernetesとして、Prometheus + Grafanaによるモニタリングやcert-managerによる証明書自動管理など、こうしたアドオンの標準搭載・運用をあらかじめ引き受けている。サービスメッシュのような追加コンポーネントの選定に工数を割く前に、土台となる運用そのものを外部化するという選択肢も検討する価値がある。K3sならではの落とし穴を含めた設計・運用の相談は、",[33,363,366],{"href":364,"rel":365},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[37],"お問い合わせ"," から可能だ。EKSやAKSと比較したコスト構造が気になる場合は、",[33,369,372],{"href":370,"rel":371},"https:\u002F\u002Fwww.hexabase.com\u002Fpricing\u002F",[37],"料金プラン"," で具体的な数字を確認してほしい。",[375,376,377],"style",{},"html pre.shiki code .sE3pS, html code.shiki .sE3pS{--shiki-default:#C0CAF5}html pre.shiki code .sPY7s, html code.shiki .sPY7s{--shiki-default:#9ECE6A}html pre.shiki code .sT800, html code.shiki .sT800{--shiki-default:#E0AF68}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);}",{"title":196,"searchDepth":231,"depth":231,"links":379},[380,381,382,383,384,385,386],{"id":13,"depth":231,"text":14},{"id":42,"depth":231,"text":43},{"id":94,"depth":231,"text":95},{"id":158,"depth":231,"text":159},{"id":282,"depth":231,"text":283},{"id":311,"depth":231,"text":312},{"id":345,"depth":231,"text":345},"2026-09-26","K3sにLinkerdとIstio Ambient Meshを実際に導入して比較しました。プロキシ構成の違い、メモリ使用量の実測値、K3s特有のCNIパス設定の落とし穴まで、軽量なK3s環境でサービスメッシュを選ぶ際に確認すべき判断基準を具体的な数字とともに解説します。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-service-mesh-linkerd-istio-ambient-mesh-decision\u002Ftitle.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fk3s-service-mesh-linkerd-istio-ambient-mesh-decision",{"title":5,"description":388},"blog\u002Fja\u002Fk3s-service-mesh-linkerd-istio-ambient-mesh-decision",[398,399,400,401,402,403],"k3s","kubernetes","service-mesh","linkerd","istio","ambient-mesh","W8Yxi4tJe3Dlyulx0YpwqlueM4LlTxAAuOOH7lWQj-U",[406,415,424,433,443,453],{"path":407,"title":408,"description":409,"date":410,"tags":411},"\u002Fblog\u002Fja\u002Fk3s-hpa-containerresource-sidecar-utilization-dilution","HPAがサイドカーの分まで合算してスケールしていた。KubernetesのContainerResourceという盲点","KubernetesのHPAはPod内の全コンテナの使用量を合算して利用率を計算するため、Istioサイドカーやログエージェントの負荷が判定を薄める。ContainerResourceメトリクスで解決する方法をK3s\u002FKubo文脈で解説する。","2026-10-21",[398,399,412,413,414,400],"hpa","containerresource","autoscaling",{"path":416,"title":417,"description":418,"date":419,"tags":420},"\u002Fblog\u002Fja\u002Fkubernetes-microservices-chatty-calls-latency","1つの注文処理で、裏側は5回叩かれていた。Kubernetesマイクロサービスの「チャッティ呼び出し」とレイテンシの正体","1回の注文処理の裏側でサービスが5回も呼び出されていた。原因はKubernetesマイクロサービスが陥る「チャッティ呼び出し」というアーキテクチャの問題。分散システムのN+1問題と解決策を解説する。","2026-08-02",[399,398,421,400,422,423],"microservices","latency","managed-kubernetes",{"path":425,"title":426,"description":427,"date":428,"tags":429},"\u002Fblog\u002Fja\u002Fkubernetes-networking-cni-service-mesh-network-engineer","サブネットは計算できるのに、Podは繋がらない。Kubernetesネットワーキングで最初にハマる壁","サブネット設計は得意なのに、なぜKubernetesのPod間通信では毎回つまずくのか。CNI・Service Mesh・NetworkPolicyというKubernetesネットワーキングの基礎を、伝統的なネットワーク設計の知識と対比しながら整理する。","2026-07-22",[399,398,430,431,400,432],"networking","cni","network-policy",{"path":434,"title":435,"description":436,"date":437,"tags":438},"\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",[398,399,431,439,440,441,442,430],"flannel","calico","cilium","networkpolicy",{"path":444,"title":445,"description":446,"date":447,"tags":448},"\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",[398,399,449,450,451,452],"topology-spread-constraints","poddisruptionbudget","scheduling","node-drain",{"path":454,"title":455,"description":456,"date":457,"tags":458},"\u002Fblog\u002Fja\u002Fkyverno-validatingadmissionpolicy-cel-migration-silent-bypass","CELに書き換えたポリシーは、本当に同じ意味なのか。KyvernoからValidatingAdmissionPolicyへの移行で\"黙って素通り\"したリソースの正体","KyvernoのClusterPolicyが廃止へ向かう中、ValidatingAdmissionPolicy（CEL）に移行したら一部リソースだけ検証が素通りしていた。原因のCELランタイムエラーとfailurePolicyの罠、安全な移行手順を解説する。","2026-10-18",[398,399,459,460,461,462],"validatingadmissionpolicy","kyverno","cel","admission-control",1792592611056]