[{"data":1,"prerenderedAt":546},["ShallowReactive",2],{"blog-ja-k3s-dns-intermittent-ndots-conntrack-race":3,"blog-related-ja-k3s-dns-intermittent-ndots-conntrack-race":485,"blog-ja-k3s-dns-intermittent-ndots-conntrack-race-alt":473},{"id":4,"title":5,"author":6,"body":7,"date":467,"description":468,"extension":469,"image":470,"locale":471,"meta":472,"navigation":473,"path":474,"seo":475,"stem":476,"tags":477,"__hash__":484},"blog\u002Fblog\u002Fja\u002Fk3s-dns-intermittent-ndots-conntrack-race.md","K3sのDNSが1日に数回だけ失敗する。犯人はndots:5でもconntrackでもなく、その「掛け算」だった","Kubo Team",{"type":8,"value":9,"toc":454},"minimark",[10,15,23,31,46,57,61,79,86,111,118,123,126,151,155,161,174,189,192,196,204,250,254,260,281,294,308,311,318,326,332,353,365,398,405,409,425,450],[11,12,14],"h2",{"id":13},"さっき失敗したapi再実行したら普通に繋がった","「さっき失敗したAPI、再実行したら普通に繋がった」",[16,17,18],"p",{},[19,20],"img",{"alt":21,"src":22},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-dns-intermittent-ndots-conntrack-race\u002Fsection01.webp",[16,24,25,26,30],{},"外部APIへのリクエストが、1日に数回だけタイムアウトする。ログを見ても異常なし。再実行すると何事もなかったように成功する——K3sを本番運用しているインフラエンジニアなら、一度はこの",[27,28,29],"strong",{},"DNS間欠障害","に心当たりがあるはずです。",[16,32,33,34,37,38,41,42,45],{},"厄介なのは、この症状が単一の原因では説明できないことです。多くのチームは「CoreDNSが重いのでは」と当たりをつけて時間を溶かしますが、実際に効いているのは",[27,35,36],{},"ndots:5によるDNSクエリの増幅","と",[27,39,40],{},"UDP conntrackのカーネルレース","という、性質の異なる2つの問題の「掛け算」です。さらに、その対策として導入したはずの",[27,43,44],{},"NodeLocal DNSCache","が、条件次第で新たな間欠障害の発生源になることもあります。",[16,47,48,49,56],{},"この記事では、K3sクラスタで実際に起きるDNS間欠障害を、原因の層ごとに切り分けて解説します。こうした罠は本来、運用チームが個別に踏みながら学ぶのではなく、クラスタの設計段階で潰しておきたいところです（記事の最後で、マネージドK8sサービス",[50,51,55],"a",{"href":52,"rel":53},"https:\u002F\u002Fkubo.hexabase.io\u002F",[54],"nofollow","Kubo","がどう解決しているかにも触れます）。",[11,58,60],{"id":59},"_1回の名前解決のつもりが実は4回のクエリになっている","1回の名前解決のつもりが、実は4回のクエリになっている",[16,62,63,64,68,69,72,73,78],{},"まず疑うべきなのは、Podの ",[65,66,67],"code",{},"\u002Fetc\u002Fresolv.conf"," に自動設定される ",[65,70,71],{},"ndots:5"," というオプションです。",[50,74,77],{"href":75,"rel":76},"https:\u002F\u002Fwww.kubenatives.com\u002Fp\u002Fkubernetes-dns-troubleshooting-coredns",[54],"Kubenatives の解説","によれば、この設定は「名前に含まれるドットが5個未満なら、まず検索ドメインを付加してから名前解決を試みる」という挙動をリゾルバに指示するものです。",[16,80,81,82,85],{},"Pod内から ",[65,83,84],{},"api.stripe.com","（ドットは2個）のような外部ドメインに接続しようとすると、実際には次の順序でクエリが飛びます。",[87,88,89,96,101,106],"ol",{},[90,91,92,95],"li",{},[65,93,94],{},"api.stripe.com.default.svc.cluster.local"," → NXDOMAIN",[90,97,98,95],{},[65,99,100],{},"api.stripe.com.svc.cluster.local",[90,102,103,95],{},[65,104,105],{},"api.stripe.com.cluster.local",[90,107,108,110],{},[65,109,84],{}," → 成功",[16,112,113,114,117],{},"つまり",[27,115,116],{},"1回の名前解決のつもりが、実際には4回のクエリが発生し、そのうち3回は必ず失敗する","設計になっています。トラフィックの少ないクラスタでは気づきにくいですが、Podの数が増えるほど無駄なクエリが積み重なり、CoreDNSの負荷とレイテンシの両方を押し上げます。",[119,120,122],"h3",{"id":121},"対策-fqdnの末尾にドットを付けるまたはndots自体を下げる","対策: FQDNの末尾にドットを付ける、またはndots自体を下げる",[16,124,125],{},"外部ドメインへのアクセスが多いアプリケーションでは、次のいずれかで無駄なクエリを削減できます。",[127,128,129,136],"ul",{},[90,130,131,132,135],{},"接続先を ",[65,133,134],{},"api.stripe.com.","（末尾にドット）と明示的なFQDNとして指定する。これにより「検索ドメインを付加しない完全な名前である」とリゾルバに伝えられます",[90,137,138,139,142,143,146,147,150],{},"Podの ",[65,140,141],{},"dnsConfig"," で ",[65,144,145],{},"ndots"," の値を ",[65,148,149],{},"\"2\""," 程度に下げる（内部サービス名の解決に影響が出ないか事前に検証が必要です）",[11,152,154],{"id":153},"もう一つの罠-udp-conntrackのカーネルレースが5秒待ちを生む","もう一つの罠 — UDP conntrackのカーネルレースが「5秒待ち」を生む",[16,156,157],{},[19,158],{"alt":159,"src":160},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-dns-intermittent-ndots-conntrack-race\u002Fsection02.webp",[16,162,163,164,169,170,173],{},"ndots:5によるクエリ増幅だけでも十分やっかいですが、K3s\u002FKubernetesクラスタではもう一つ、カーネルレベルの問題が重なります。",[50,165,168],{"href":166,"rel":167},"https:\u002F\u002Fgithub.com\u002Fweaveworks\u002Fweave\u002Fissues\u002F3287",[54],"weaveworks\u002Fweave の Issue #3287"," で報告されているように、これは",[27,171,172],{},"カーネルレベルのSNATレースコンディション","です。",[16,175,176,177,182,183,188],{},"多くのリゾルバはA(IPv4)レコードとAAAA(IPv6)レコードを同時に問い合わせますが、この2つのUDPパケットが同じ送信元ポートを使ってNAT変換される際に、Linuxカーネルのconntrackテーブルで衝突が起きることがあります。片方のパケットが失われると、アプリケーション側はタイムアウト（多くの場合5秒）を待ってからリトライし、そこでようやく成功します。これはWeave・Flannelなど特定のCNIに限らず起きる既知の問題で、",[50,178,181],{"href":179,"rel":180},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Ftasks\u002Fadminister-cluster\u002Fnodelocaldns\u002F",[54],"Kubernetes公式のNodeLocalDNSドキュメント","も ",[50,184,187],{"href":185,"rel":186},"https:\u002F\u002Fgithub.com\u002Fkubernetes\u002Fkubernetes\u002Fissues\u002F56903",[54],"kubernetes\u002Fkubernetes#56903"," として言及しています。",[16,190,191],{},"公式ドキュメントはさらに、UDPのDNSクエリがconntrackエントリを生成し続けること自体もリスクだと指摘しており、「UDPからTCPへの移行がパケットロスやDNSタイムアウト（最大30秒）に起因するテール・レイテンシを削減する」としています。UDPのconntrackエントリはタイムアウトするまでテーブルに残るため、DNSクエリの多いクラスタほど圧迫されやすくなります。",[119,193,195],{"id":194},"対策-single-request-reopenでaaaaaクエリを直列化する","対策: single-request-reopenでA\u002FAAAAクエリを直列化する",[16,197,198,203],{},[50,199,202],{"href":200,"rel":201},"https:\u002F\u002Foneuptime.com\u002Fblog\u002Fpost\u002F2026-01-06-debug-kubernetes-dns-issues\u002Fview",[54],"OneUptime のデバッグガイド","では、カーネル5.9より前の環境向けに、次のPod設定でA\u002FAAAAクエリを同時ではなく順番に送るワークアラウンドが紹介されています。これにより同一ソケットでの競合が起きにくくなり、5秒待ちの発生率を下げられます。",[205,206,211],"pre",{"className":207,"code":208,"language":209,"meta":210,"style":210},"language-yaml shiki shiki-themes tokyo-night","dnsConfig:\n  options:\n    - name: single-request-reopen\n","yaml","",[65,212,213,225,233],{"__ignoreMap":210},[214,215,218,221],"span",{"class":216,"line":217},"line",1,[214,219,141],{"class":220},"s0U2E",[214,222,224],{"class":223},"sAklC",":\n",[214,226,228,231],{"class":216,"line":227},2,[214,229,230],{"class":220},"  options",[214,232,224],{"class":223},[214,234,236,240,243,246],{"class":216,"line":235},3,[214,237,239],{"class":238},"sgJMe","    -",[214,241,242],{"class":220}," name",[214,244,245],{"class":223},":",[214,247,249],{"class":248},"sPY7s"," single-request-reopen\n",[11,251,253],{"id":252},"対策のはずが罠に-nodelocal-dnscacheが新しい間欠障害を生む瞬間","対策のはずが罠に — NodeLocal DNSCacheが新しい間欠障害を生む瞬間",[16,255,256],{},[19,257],{"alt":258,"src":259},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-dns-intermittent-ndots-conntrack-race\u002Fsection03.webp",[16,261,262,263,265,266,269,270,274,275,280],{},"ここまでの2つの問題への定番の処方箋が ",[27,264,44],{}," です。各ノードにDaemonSetとしてキャッシュエージェントを配置し、リンクローカルアドレス（",[65,267,268],{},"169.254.0.0\u002F16"," 範囲、",[50,271,273],{"href":179,"rel":272},[54],"Kubernetes公式ドキュメント","による）で待ち受けることで、キャッシュヒット時はCoreDNSへのネットワークホップをスキップできます。ある運用ブログでは、大量のPodが同時起動してDNS問い合わせが集中した障害と、導入後のレイテンシ改善（数百ミリ秒単位の応答が数ミリ秒台まで短縮）が",[50,276,279],{"href":277,"rel":278},"https:\u002F\u002Fsvalle.ru\u002Fposts\u002Fkubernetes\u002Fcoredns-nodelocal-cache\u002F",[54],"実測値として報告されています","。",[16,282,283,284,287,288,293],{},"しかし、ここで終わりではありません。NodeLocal DNSCache自体もDaemonSetである以上、",[27,285,286],{},"それ自身が新たな間欠障害の発生源になり得る","ことを見落としがちです。",[50,289,292],{"href":290,"rel":291},"https:\u002F\u002Fadhdecode.com\u002Fdebugging\u002Fcoredns\u002Fnode-local-dns-upstream-timeout\u002F",[54],"ADHDecode の解説","は次の2つのケースを指摘しています。",[127,295,296,302],{},[90,297,298,301],{},[27,299,300],{},"ローリング更新中",": NodeLocal DNSCacheのDaemonSetを更新すると、一時的にキャッシュPodが存在しないノードが生じる",[90,303,304,307],{},[27,305,306],{},"ノードのリソース逼迫時",": CPU\u002Fメモリ\u002Fディスクの逼迫でPodがEvictされる際、NodeLocal DNSCacheのPodも対象になり得る",[16,309,310],{},"さらに興味深いのは、この状態で起きる症状のパターンです。「内部のKubernetesサービス名は解決できるのに、外部ドメインだけ時々タイムアウトする」——これは、内部名の解決経路と外部名の解決経路が異なるために起きる、一見矛盾した現象です。「NodeLocalDNSを入れたのに、まだ時々失敗する」と感じたら、まずキャッシュPod自体の稼働状況を疑う価値があります。",[16,312,313,314,317],{},"このDaemonSetのローリング更新タイミングやノードのリソース逼迫を運用者が常に監視し続けるのは、地味に工数がかかる作業です。",[50,315,55],{"href":52,"rel":316},[54]," はK3sベースのマネージドKubernetesとして、NodeLocal DNSCacheを含む標準コンポーネントの健全性をCaptain UIで可視化し、更新時の切り替えも運用側で管理する設計になっています。",[11,319,321,322,325],{"id":320},"k3s固有の落とし穴-kubectl-edit-configmap-corednsが消える理由","K3s固有の落とし穴 — ",[65,323,324],{},"kubectl edit configmap coredns","が消える理由",[16,327,328],{},[19,329],{"alt":330,"src":331},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-dns-intermittent-ndots-conntrack-race\u002Fsection04.webp",[16,333,334,335,338,339,344,345,348,349,352],{},"ここまでの3つの問題を理解していても、K3sならではの落とし穴がもう一つあります。K3sはCoreDNSを",[27,336,337],{},"バンドルされたAddon","として管理しており、",[50,340,343],{"href":341,"rel":342},"https:\u002F\u002Fdocs.k3s.io\u002Fadvanced",[54],"K3s公式ドキュメント","には「CoreDNSの設定をカスタマイズするには、",[65,346,347],{},"kube-system"," namespaceに",[65,350,351],{},"coredns-custom","という名前のConfigMapを作成する」と明記されています。",[16,354,355,356,358,359,364],{},"つまり、CoreDNSの設定を直接 ",[65,357,324],{}," で編集しても、K3sの起動時にAddonとして再デプロイされ、その変更は消えてしまいます。",[50,360,363],{"href":361,"rel":362},"https:\u002F\u002Foneuptime.com\u002Fblog\u002Fpost\u002F2026-03-20-k3s-coredns-custom-config\u002Fview",[54],"OneUptime のK3s向け解説","は、正しい永続化の手順を次のように整理しています。",[127,366,367,372,382,388],{},[90,368,369,371],{},[65,370,351],{}," という名前のConfigMapを作成する",[90,373,374,377,378,381],{},[65,375,376],{},"*.override"," に書いたキーは既定の ",[65,379,380],{},":.53"," Server Blockに取り込まれる",[90,383,384,387],{},[65,385,386],{},"*.server"," に書いたキーは追加のServer Blockとして扱われる",[90,389,390,391,394,395],{},"このConfigMapのマニフェストを ",[65,392,393],{},"\u002Fvar\u002Flib\u002Francher\u002Fk3s\u002Fserver\u002Fmanifests\u002Fcoredns-custom.yaml"," に配置しておくことで、",[27,396,397],{},"K3sの再起動・アップグレードをまたいで設定が消えない",[16,399,400,401,404],{},"K3s公式ドキュメントはさらに、",[65,402,403],{},"--resolv-conf"," オプションでシステムの設定ファイルを書き換えずに代替のresolver設定を渡せることも案内しています。DNS周りのカスタマイズをK3sクラスタで行う際は、この永続化の作法を最初に押さえておく必要があります。",[11,406,408],{"id":407},"dnsの間欠障害は1つの原因を探しても見つからない","DNSの間欠障害は「1つの原因」を探しても見つからない",[16,410,411,412,414,415,417,418,420,421,424],{},"K3sクラスタでのDNS間欠障害は、単一の犯人がいるわけではありません。",[27,413,71],{},"が名前解決を4倍のクエリに増幅し、",[27,416,40],{},"がパケットロス→5秒待ちを生み、その対策である",[27,419,44],{},"自体がローリング更新やノード逼迫時に新たな障害源になり、",[27,422,423],{},"K3s固有のAddon管理","が素朴な設定変更を再起動のたびに消し去る——4つのレイヤーが互いに独立していながら組み合わさって現れるため、「これを直せば解決」という単純な対処では再発しやすいのが実情です。",[16,426,427,428,431,432,437,438,443,444,449],{},"こうした罠を一つひとつ踏みながら学んでいく状態は、本来インフラの専門性を割くべき場所ではないはずです。",[50,429,55],{"href":52,"rel":430},[54]," はK3sベースのマネージドKubernetesサービスとして、NodeLocal DNSCacheの適切な設定やCoreDNSカスタマイズの永続化パターンをあらかじめ組み込んだ状態でクラスタを提供します。DNSスタックの設計・検証を一から自分たちで積み上げる前に、",[50,433,436],{"href":434,"rel":435},"https:\u002F\u002Fwww.hexabase.com\u002Fpricing\u002F",[54],"料金プラン","も含めて比較してみる価値はあるはずです。EKS\u002FAKSのようなフルマネージドの利便性と、K3sならではのコスト効率を両立できるよう設計されています。オンプレミスでのデータ主権が要件になる場合は",[50,439,442],{"href":440,"rel":441},"https:\u002F\u002Fwww.hexabase.com\u002Fproduct\u002Fkubo\u002Fon-premise",[54],"Kubo On-Premise","も選択肢です。DNSスタックを含むクラスタ設計の相談は",[50,445,448],{"href":446,"rel":447},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[54],"お問い合わせ","からどうぞ。",[451,452,453],"style",{},"html pre.shiki code .s0U2E, html code.shiki .s0U2E{--shiki-default:#F7768E}html pre.shiki code .sAklC, html code.shiki .sAklC{--shiki-default:#89DDFF}html pre.shiki code .sgJMe, html code.shiki .sgJMe{--shiki-default:#9ABDF5}html pre.shiki code .sPY7s, html code.shiki .sPY7s{--shiki-default:#9ECE6A}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":210,"searchDepth":227,"depth":227,"links":455},[456,457,460,463,464,466],{"id":13,"depth":227,"text":14},{"id":59,"depth":227,"text":60,"children":458},[459],{"id":121,"depth":235,"text":122},{"id":153,"depth":227,"text":154,"children":461},[462],{"id":194,"depth":235,"text":195},{"id":252,"depth":227,"text":253},{"id":320,"depth":227,"text":465},"K3s固有の落とし穴 — kubectl edit configmap corednsが消える理由",{"id":407,"depth":227,"text":408},"2026-09-15","K3sで外部APIへの接続が時々タイムアウトする間欠障害の正体は、ndots:5によるDNSクエリ増幅とUDP conntrackレースの複合要因にある。NodeLocal DNSCacheの効果と副作用、K3s固有のcoredns-custom永続化まで解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-dns-intermittent-ndots-conntrack-race\u002Ftitle.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fk3s-dns-intermittent-ndots-conntrack-race",{"title":5,"description":468},"blog\u002Fja\u002Fk3s-dns-intermittent-ndots-conntrack-race",[478,479,480,481,482,483],"k3s","kubernetes","coredns","dns","conntrack","nodelocal-dnscache","sGn_-JQEd8My0ejcNxiYRqvWEtHGkcN8DVEeo8DYAuw",[486,496,508,518,528,536],{"path":487,"title":488,"description":489,"date":490,"tags":491},"\u002Fblog\u002Fja\u002Fk3s-hpa-containerresource-sidecar-utilization-dilution","HPAがサイドカーの分まで合算してスケールしていた。KubernetesのContainerResourceという盲点","KubernetesのHPAはPod内の全コンテナの使用量を合算して利用率を計算するため、Istioサイドカーやログエージェントの負荷が判定を薄める。ContainerResourceメトリクスで解決する方法をK3s\u002FKubo文脈で解説する。","2026-10-21",[478,479,492,493,494,495],"hpa","containerresource","autoscaling","service-mesh",{"path":497,"title":498,"description":499,"date":500,"tags":501},"\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",[478,479,502,503,504,505,506,507],"cni","flannel","calico","cilium","networkpolicy","networking",{"path":509,"title":510,"description":511,"date":512,"tags":513},"\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",[478,479,514,515,516,517],"topology-spread-constraints","poddisruptionbudget","scheduling","node-drain",{"path":519,"title":520,"description":521,"date":522,"tags":523},"\u002Fblog\u002Fja\u002Fkyverno-validatingadmissionpolicy-cel-migration-silent-bypass","CELに書き換えたポリシーは、本当に同じ意味なのか。KyvernoからValidatingAdmissionPolicyへの移行で\"黙って素通り\"したリソースの正体","KyvernoのClusterPolicyが廃止へ向かう中、ValidatingAdmissionPolicy（CEL）に移行したら一部リソースだけ検証が素通りしていた。原因のCELランタイムエラーとfailurePolicyの罠、安全な移行手順を解説する。","2026-10-18",[478,479,524,525,526,527],"validatingadmissionpolicy","kyverno","cel","admission-control",{"path":529,"title":530,"description":531,"date":532,"tags":533},"\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",[478,479,534,494,535],"vpa","cgroup",{"path":537,"title":538,"description":539,"date":540,"tags":541},"\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",[478,479,542,543,544,545],"pod-security-admission","pod-security-standards","servicelb","security",1792592604174]