[{"data":1,"prerenderedAt":398},["ShallowReactive",2],{"blog-ja-k3s-harbor-private-registry-docker-hub-rate-limit":3,"blog-related-ja-k3s-harbor-private-registry-docker-hub-rate-limit":347,"blog-ja-k3s-harbor-private-registry-docker-hub-rate-limit-alt":336},{"id":4,"title":5,"author":6,"body":7,"date":330,"description":331,"extension":332,"image":333,"locale":334,"meta":335,"navigation":336,"path":337,"seo":338,"stem":339,"tags":340,"__hash__":346},"blog\u002Fblog\u002Fja\u002Fk3s-harbor-private-registry-docker-hub-rate-limit.md","Docker Hubの無料枠が凍りついた朝、K3sクラスタは静かに詰む。Harborを自前で持つべきタイミング","Kubo Team",{"type":8,"value":9,"toc":321},"minimark",[10,15,23,44,58,71,75,81,98,101,123,132,136,142,155,163,183,191,195,201,204,216,242,251,258,262,268,271,274,294,318],[11,12,14],"h2",{"id":13},"_1-docker-hubのレート制限はもう他人事ではない","1. Docker Hubのレート制限は「もう他人事」ではない",[16,17,18],"p",{},[19,20],"img",{"alt":21,"src":22},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fk3s-harbor-private-registry-docker-hub-rate-limit\u002Fsection01.webp",[16,24,25,26,30,31,34,35,38,39,43],{},"朝、オートスケールで増えたはずのK3sワーカーノードが、いつまで経ってもRunning状態にならない。",[27,28,29],"code",{},"kubectl describe pod"," を叩くと、原因は ",[27,32,33],{},"ImagePullBackOff"," と ",[27,36,37],{},"429 Too Many Requests"," だった——これは特殊な事故ではなく、Docker Hubの",[40,41,42],"strong",{},"Harbor container registry","（自前運用のコンテナレジストリ）を検討すべきタイミングを知らせるシグナルだ。",[16,45,46,53,54,57],{},[47,48,52],"a",{"href":49,"rel":50},"https:\u002F\u002Fdocs.docker.com\u002Fdocker-hub\u002Fdownload-rate-limit\u002F",[51],"nofollow","Docker公式ドキュメント","によると、Docker Hubの無料枠は「未認証ユーザー: 6時間あたり100pull」「無料認証ユーザー: 6時間あたり200pull」という枠で運用されている。問題は、この制限が",[40,55,56],{},"IPv4アドレスまたはIPv6 \u002F64サブネット単位","でカウントされることだ。",[16,59,60,61,66,67,70],{},"社内ネットワークやクラウドのNAT Gateway配下では、複数の開発者・CI runner・K3sノードが同じパブリックIPを共有しているケースが珍しくない。",[47,62,65],{"href":63,"rel":64},"https:\u002F\u002Foneuptime.com\u002Fblog\u002Fpost\u002F2026-02-08-how-to-fix-docker-too-many-requests-rate-limit-errors\u002Fview",[51],"oneuptimeの解説記事","が指摘する通り、忙しいCIパイプラインだけで数分のうちにこの100pullの枠を使い切ってしまい、後から来たK3sノードのpullが ",[27,68,69],{},"429"," で弾かれる。オートスケールでノードを増やした瞬間にデプロイが止まる、というのはこの構造的な欠陥が引き起こす典型的な障害パターンだ。",[11,72,74],{"id":73},"_2-なぜキャッシュを挟むだけでは足りないのか","2. なぜ「キャッシュを挟む」だけでは足りないのか",[16,76,77],{},[19,78],{"alt":79,"src":80},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fk3s-harbor-private-registry-docker-hub-rate-limit\u002Fsection02.webp",[16,82,83,84,89,90,93,94,97],{},"この問題への第一の答えとして「pull-throughキャッシュを挟む」がよく挙げられる。",[47,85,88],{"href":86,"rel":87},"https:\u002F\u002Fcontainer-registry.com\u002Fposts\u002Fovercome-docker-hub-rate-limit\u002F",[51],"container-registry.comの解説","にある通り、一度取得したイメージをキャッシュ側に保存しておけば、同じイメージの再pullはDocker Hubを経由せずに済み、レート制限を実質的に回避できる。K3sであれば、",[27,91,92],{},"registries.yaml"," の ",[27,95,96],{},"mirrors"," 設定でDocker Hubへのリクエストをキャッシュ経由にルーティングするだけで導入できる手軽さもある。",[16,99,100],{},"ただし、キャッシュはあくまで「Docker Hubへの依存を減らす」ための緩和策であり、次の3つの課題には答えてくれない。",[102,103,104,111,117],"ul",{},[105,106,107,110],"li",{},[40,108,109],{},"可用性",": キャッシュサーバー自体が単一障害点になり、キャッシュが落ちればDocker Hub直叩きに逆戻りする",[105,112,113,116],{},[40,114,115],{},"脆弱性スキャン",": キャッシュされたイメージにCVEが含まれていないかを継続的に検査する仕組みがない",[105,118,119,122],{},[40,120,121],{},"来歴管理",": 誰がどのイメージをいつビルドし、どこにデプロイしたかを追跡できない",[16,124,125,126,131],{},"つまり、「pullできない」という症状だけを止血する段階と、「本番で使うイメージの品質と出所を管理する」段階は別の問題であり、後者に踏み込むなら自前のコンテナレジストリが必要になる。この線引きは、突き詰めれば「K3s運用のどこまでを自分たちで背負うか」という設計判断でもある。",[47,127,130],{"href":128,"rel":129},"https:\u002F\u002Fkubo.hexabase.io\u002F",[51],"Kubo","のようなマネージドK3s環境を選ぶ場合、この判断自体をクラスタ運用の一部としてベンダー側に委ねる選択肢も生まれる。",[11,133,135],{"id":134},"_3-harborをk3skubernetesで動かすときに効いてくる設計判断","3. HarborをK3s\u002FKubernetesで動かすときに効いてくる設計判断",[16,137,138],{},[19,139],{"alt":140,"src":141},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fk3s-harbor-private-registry-docker-hub-rate-limit\u002Fsection03.webp",[16,143,144,145,148,149,154],{},"ここで候補に上がるのが、",[40,146,147],{},"Harbor","（Harborコンテナレジストリ）だ。",[47,150,153],{"href":151,"rel":152},"https:\u002F\u002Fwww.cncf.io\u002Fprojects\u002Fharbor\u002F",[51],"CNCFのプロジェクトページ","によれば、Harborは2018年にCNCFへ加入し、2020年6月にGraduatedステータスへ昇格した、CNCFの中でも成熟度の高いプロジェクトの一つとされている。",[16,156,157,162],{},[47,158,161],{"href":159,"rel":160},"https:\u002F\u002Fgoharbor.io\u002F",[51],"Harbor公式サイト","が挙げる中核機能は、コンテンツの保存・署名・スキャンの3つだ。具体的には、脆弱性スキャン、コンテンツ署名と検証、マルチテナント対応のRBAC、そしてHarbor自身を含む複数レジストリ間のレプリケーション機能が標準で組み込まれている。単なる「イメージ置き場」ではなく、サプライチェーンセキュリティのゲートとして機能する設計になっている点が、単純なpull-throughキャッシュとの本質的な違いだ。",[16,164,165,166,171,172,175,176,178,179,182],{},"K3s側の設定はシンプルだ。",[47,167,170],{"href":168,"rel":169},"https:\u002F\u002Fdocs.k3s.io\u002Finstallation\u002Fprivate-registry",[51],"K3s公式ドキュメント","によれば、K3sは起動時に ",[27,173,174],{},"\u002Fetc\u002Francher\u002Fk3s\u002Fregistries.yaml"," の存在を確認し、そこに定義された ",[27,177,96],{},"（レジストリのエンドポイント）と ",[27,180,181],{},"configs","（認証情報・TLS設定）を元にcontainerdの設定を生成する。このファイルは、ミラーを利用したいすべてのノードに配置する必要があり、設定変更後はノードごとのK3s再起動が必要になる点は運用フローに組み込んでおきたい。",[16,184,185,190],{},[47,186,189],{"href":187,"rel":188},"https:\u002F\u002Fwww.civo.com\u002Flearn\u002Fself-hosting-container-registy-kubernetes-harbor",[51],"Civoの解説記事","も指摘する通り、本番でHarborを動かすなら「高可用性モード」での運用を前提に設計する必要がある。ここが、次章で扱う「隠れたコスト」の入り口になる。",[11,192,194],{"id":193},"_4-自前運用の隠れたコスト-データベースredisストレージ","4. 「自前運用」の隠れたコスト — データベース・Redis・ストレージ",[16,196,197],{},[19,198],{"alt":199,"src":200},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fk3s-harbor-private-registry-docker-hub-rate-limit\u002Fsection04.webp",[16,202,203],{},"Harbor自体はOSSであり、ライセンス費用はかからない。しかし「自前で持つ」ということは、Harborを支える周辺コンポーネントの運用責任もまるごと引き受けるということだ。",[16,205,206,211,212,215],{},[47,207,210],{"href":208,"rel":209},"https:\u002F\u002Fgoharbor.io\u002Fdocs\u002F1.10\u002Finstall-config\u002Fharbor-ha-helm\u002F",[51],"Harbor公式のHelm HAガイド","を見ると、HelmでHarborをHA構成にする場合、以下は",[40,213,214],{},"Harbor自身が面倒を見てくれない","ため、利用者側で別途用意する必要がある。",[102,217,218,224,230,236],{},[105,219,220,223],{},[40,221,222],{},"高可用性PostgreSQL",": Harbor core・Notary server・Notary signer用に複数のデータベースを作成する必要がある",[105,225,226,229],{},[40,227,228],{},"高可用性Redis",": HarborのRedisクライアントはSentinelをサポートしないため、HAProxy等で単一エントリーポイントを作る構成が推奨される",[105,231,232,235],{},[40,233,234],{},"共有ストレージ",": 複数ノードから書き込み可能なPVC（ReadWriteMany）か、S3互換のオブジェクトストレージ",[105,237,238,241],{},[40,239,240],{},"高可用性Ingressコントローラー",": 外部公開エンドポイントの可用性もHarborの管轄外",[16,243,244,245,250],{},"つまりHarborの導入は「レジストリを1つ追加する」のではなく、「PostgreSQL・Redis・オブジェクトストレージ・Ingressという4つのステートフルなコンポーネントを新たに本番運用に組み込む」ことに近い。",[47,246,249],{"href":247,"rel":248},"https:\u002F\u002Fcanonical.com\u002Fmicrok8s\u002Fdocs\u002Fdockerhub-limits",[51],"Canonicalのドキュメント","も、本番環境では「プライベートレジストリでDocker Hubをミラーリングする」ことを強く推奨しつつ、その運用コストを織り込んだ設計を促している。",[16,252,253,254,257],{},"このステートフルな部分の運用工数を、K3sクラスタ本体の運用工数に上乗せできるかどうかが、自前運用に踏み切るかどうかの分岐点になる。",[47,255,130],{"href":128,"rel":256},[51],"のようにRancher管理基盤とHelmチャート対応が標準搭載されたマネージドK3s環境であれば、Harborを含むエコシステムのデプロイ・監視・アップグレードをHelmチャート単位で一括管理でき、この「4つのステートフルコンポーネント」を人力で個別管理する負担を減らせる。",[11,259,261],{"id":260},"_5-まとめ-自前で持つか任せるかの判断基準","5. まとめ — 「自前で持つ」か「任せる」かの判断基準",[16,263,264],{},[19,265],{"alt":266,"src":267},"section05","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fk3s-harbor-private-registry-docker-hub-rate-limit\u002Fsection05.webp",[16,269,270],{},"Docker Hubのレート制限は、単一クラスタ・小規模チームであればpull-throughキャッシュで当面しのげる問題だ。しかし、マルチクラスタ運用、エッジ環境への展開、あるいは脆弱性スキャンやイメージ署名がコンプライアンス要件に含まれる組織にとっては、Harborのような自前レジストリへの投資が避けられない選択肢になる。",[16,272,273],{},"判断基準はシンプルだ。",[102,275,276,282,288],{},[105,277,278,281],{},[40,279,280],{},"単一クラスタ・検証環境レベル"," → pull-throughキャッシュで十分",[105,283,284,287],{},[40,285,286],{},"マルチクラスタ・本番の可用性が問われる環境"," → Harbor自前運用、ただしHA PostgreSQL\u002FRedis\u002Fストレージの運用体制とセットで検討する",[105,289,290,293],{},[40,291,292],{},"運用工数そのものを圧縮したい"," → レジストリ運用を含めてマネージドK3s環境に寄せる",[16,295,296,299,300,305,306,311,312,317],{},[47,297,130],{"href":128,"rel":298},[51],"は、K3sベースの標準構成にRancher管理基盤とHelm対応を組み込んでおり、EKSやAKSに対して",[47,301,304],{"href":302,"rel":303},"https:\u002F\u002Fwww.hexabase.com\u002Fpricing\u002F",[51],"月額48,000円からのコスト構成","でフルスペックのKubernetesクラスタを運用できる。Harborを含むコンテナ基盤の設計判断を、コスト予測可能な形で相談したい場合は、",[47,307,310],{"href":308,"rel":309},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[51],"お問い合わせ","から具体的な構成イメージを確認してみてほしい。データ主権やAir-Gapped環境が要件になる場合は、",[47,313,316],{"href":314,"rel":315},"https:\u002F\u002Fwww.hexabase.com\u002Fproduct\u002Fkubo\u002Fon-premise",[51],"Kubo On-Premise","側でオンプレミス完結の設計も可能だ。",[16,319,320],{},"Docker Hubの無料枠が凍りつく朝は、突然やってくる。その日が来る前に、自分たちのクラスタがどちらの選択肢を取るべきか、一度棚卸ししておく価値はある。",{"title":322,"searchDepth":323,"depth":323,"links":324},"",2,[325,326,327,328,329],{"id":13,"depth":323,"text":14},{"id":73,"depth":323,"text":74},{"id":134,"depth":323,"text":135},{"id":193,"depth":323,"text":194},{"id":260,"depth":323,"text":261},"2026-08-23","Docker Hubのpull rate limitで本番K3sクラスタのイメージ取得が止まるリスクが現実味を増している。CNCF卒業プロジェクトHarborを自前運用する設計判断と隠れたコストを解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fk3s-harbor-private-registry-docker-hub-rate-limit\u002Feyecatch.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fk3s-harbor-private-registry-docker-hub-rate-limit",{"title":5,"description":331},"blog\u002Fja\u002Fk3s-harbor-private-registry-docker-hub-rate-limit",[341,342,343,344,345],"k3s","kubernetes","harbor","container-registry","cncf","1aKfgPwBr7UmnjL_jI6G0Z_P_f0vXa1c4uBbQpRwlvs",[348,355,363,371,379,389],{"path":349,"title":350,"description":351,"date":352,"tags":353},"\u002Fblog\u002Fja\u002Fcncf-project-maturity-graduation-criteria-production","GitHubスター1万は『卒業証書』にならない。KubernetesでCNCFプロジェクトを選ぶ基準はコミット数ではなく成熟度ステージ","Kubernetesの技術選定でCNCFプロジェクトを採用する際、GitHubスター数や知名度だけで判断していないか。Sandbox\u002FIncubating\u002FGraduatedという成熟度基準とHarborの事例から、本番導入前に確認すべき基準を解説する。","2026-08-19",[341,342,345,354,344],"oss-governance",{"path":356,"title":357,"description":358,"date":359,"tags":360},"\u002Fblog\u002Fja\u002Fkubernetes-ebpf-inspektor-gadget-observability","strace禁止、sidecar禁止、それでも診断できる。KubernetesをeBPFで透視するInspektor Gadgetという回答","特権コンテナもsidecarも追加できない本番Kubernetesで、Podの通信とシステムコールをどう診断するか。eBPFツール「Inspektor Gadget」の仕組みと2026年の最新動向を解説する。","2026-08-15",[341,342,361,362,345],"ebpf","observability",{"path":364,"title":365,"description":366,"date":367,"tags":368},"\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",[342,341,369,345,370],"ai-inference","managed-kubernetes",{"path":372,"title":373,"description":374,"date":375,"tags":376},"\u002Fblog\u002Fja\u002Fcncf-graduated-project-oss-selection-criteria","CNCFの『卒業』ロゴを信じていいのか。TOC公開議事から見えた、審査の地味な実態とOSS選定基準","CNCFの「卒業（Graduated）」ロゴは安全証明ではない。TOC公開会議の議事から見える審査の実態と、Sandbox・Incubating・Graduatedの基準・タイムラインを解説し、本番導入前にOSSの成熟度を見極める視点を紹介する。","2026-07-23",[345,342,341,377,370,378],"oss","governance",{"path":380,"title":381,"description":382,"date":383,"tags":384},"\u002Fblog\u002Fja\u002Fk3s-container-image-security-supply-chain-checklist","「スキャン済み」は本番投入の許可証にならない。K3sコンテナイメージセキュリティ、署名からアドミッション制御まで","コンテナ セキュリティ ガイドラインというと『スキャンしてるから大丈夫』で止まりがちだ。K3s環境でベースイメージの最小化から脆弱性スキャン、SBOM生成、署名、アドミッション制御まで、本番投入前に通すべき工程を実務チェックリストとして具体的に解説する。","2026-08-24",[341,342,385,386,387,388],"container-security","image-scanning","sbom","supply-chain-security",{"path":390,"title":391,"description":392,"date":393,"tags":394},"\u002Fblog\u002Fja\u002Fkubernetes-cost-management-eks-aks-billing-visibility","EKSの請求書は月末にならないと読めない。Kubernetesのコストが『後から分かる』構造的な理由","EKS\u002FAKSのKubernetesコストはなぜ想定外に膨らむのか。オートスケールとクロスAZ課金がコストを見えなくする構造を分解し、K3sベースのマネージドインフラで固定費化する方法を解説します。","2026-08-22",[341,342,395,370,396,397],"cost-optimization","aks","finops",1787649512053]