[{"data":1,"prerenderedAt":542},["ShallowReactive",2],{"blog-ja-k3s-pod-security-admission-restricted-servicelb-outage":3,"blog-related-ja-k3s-pod-security-admission-restricted-servicelb-outage":492,"blog-ja-k3s-pod-security-admission-restricted-servicelb-outage-alt":480},{"id":4,"title":5,"author":6,"body":7,"date":474,"description":475,"extension":476,"image":477,"locale":478,"meta":479,"navigation":480,"path":481,"seo":482,"stem":483,"tags":484,"__hash__":491},"blog\u002Fblog\u002Fja\u002Fk3s-pod-security-admission-restricted-servicelb-outage.md","restrictedを有効にしたらServiceLBが死んだ。K3sのPod Security Admissionに潜む、汎用ガイドにない設定差分","Kubo Team",{"type":8,"value":9,"toc":466},"minimark",[10,22,27,34,42,56,64,152,171,175,181,198,211,214,218,224,230,252,294,301,316,320,326,329,346,359,363,369,372,420,427,431,434,437,444,453,462],[11,12,13,14,21],"p",{},"K3sクラスタでPod Security Admission（PSA）のrestrictedプロファイルを有効にした途端、LoadBalancer型のServiceが軒並み外部IPを失った——そんな経験をした運用者は少なくないはずだ。",[15,16,20],"a",{"href":17,"rel":18},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Ftasks\u002Fconfigure-pod-container\u002Fenforce-standards-namespace-labels\u002F",[19],"nofollow","Kubernetes公式ドキュメント","の手順通りにnamespaceへラベルを付けただけなのに、なぜK3sだけが壊れるのか。本記事では、K3s vs 標準Kubernetesの構成差分という観点からPod Security Admissionの落とし穴を整理する。",[23,24,26],"h2",{"id":25},"_1-pod-security-admissionとは何か-k3sと標準kubernetesで前提が違う","1. Pod Security Admissionとは何か ― K3sと標準Kubernetesで前提が違う",[11,28,29],{},[30,31],"img",{"alt":32,"src":33},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-pod-security-admission-restricted-servicelb-outage\u002Fsection01.webp",[11,35,36,37,41],{},"Pod Security Admission（PSA）は、Podの作成リクエストを検査しセキュリティ基準への準拠を強制するadmission controllerだ。privileged（無制限）、baseline（既知の権限昇格を防ぐ最低限の制限）、restricted（Podハードニングのベストプラクティスに従う厳格な制限）という3つのレベルを持ち、それぞれをenforce（違反時にブロック）・audit（監査ログに記録）・warn（警告のみ）の3モードで運用できる（",[15,38,40],{"href":17,"rel":39},[19],"kubernetes.io公式ドキュメント","）。",[11,43,44,45,50,51,41],{},"PSAは2022年にリリースされたKubernetes v1.25で安定版（stable）となり、長年ベータのまま塩漬けになっていた旧来のPodSecurityPolicy（PSP）を置き換える形で導入された（",[15,46,49],{"href":47,"rel":48},"https:\u002F\u002Fwww.techtarget.com\u002Fit-infrastructure\u002Fnews\u002F252524237\u002FKubernetes-security-reaches-maturity-milestone-with-v125",[19],"TechTargetの解説記事","）。PSPはユーザーやサービスアカウントへのバインドという複雑な権限モデルを持っていたため運用が難しく、v1.25で完全に削除されている（",[15,52,55],{"href":53,"rel":54},"https:\u002F\u002Fgoteleport.com\u002Fdocs\u002Fadmin-guides\u002Fdeploy-a-cluster\u002Fhelm-deployments\u002Fmigration-kubernetes-1-25-psp",[19],"Teleportの移行ガイド",[11,57,58,59,63],{},"ここで押さえておきたいのは、",[60,61,62],"strong",{},"PSAはデフォルトでは何も強制しない","という設計思想だ。既存ワークロードを壊さずに段階的に導入できるよう、管理者が明示的にnamespaceへラベルを付けるまでは何のポリシーも適用されない。",[65,66,71],"pre",{"className":67,"code":68,"language":69,"meta":70,"style":70},"language-yaml shiki shiki-themes tokyo-night","apiVersion: v1\nkind: Namespace\nmetadata:\n  name: production\n  labels:\n    pod-security.kubernetes.io\u002Fenforce: restricted\n    pod-security.kubernetes.io\u002Fenforce-version: v1.37\n","yaml","",[72,73,74,91,102,111,122,130,141],"code",{"__ignoreMap":70},[75,76,79,83,87],"span",{"class":77,"line":78},"line",1,[75,80,82],{"class":81},"s0U2E","apiVersion",[75,84,86],{"class":85},"sAklC",":",[75,88,90],{"class":89},"sPY7s"," v1\n",[75,92,94,97,99],{"class":77,"line":93},2,[75,95,96],{"class":81},"kind",[75,98,86],{"class":85},[75,100,101],{"class":89}," Namespace\n",[75,103,105,108],{"class":77,"line":104},3,[75,106,107],{"class":81},"metadata",[75,109,110],{"class":85},":\n",[75,112,114,117,119],{"class":77,"line":113},4,[75,115,116],{"class":81},"  name",[75,118,86],{"class":85},[75,120,121],{"class":89}," production\n",[75,123,125,128],{"class":77,"line":124},5,[75,126,127],{"class":81},"  labels",[75,129,110],{"class":85},[75,131,133,136,138],{"class":77,"line":132},6,[75,134,135],{"class":81},"    pod-security.kubernetes.io\u002Fenforce",[75,137,86],{"class":85},[75,139,140],{"class":89}," restricted\n",[75,142,144,147,149],{"class":77,"line":143},7,[75,145,146],{"class":81},"    pod-security.kubernetes.io\u002Fenforce-version",[75,148,86],{"class":85},[75,150,151],{"class":89}," v1.37\n",[11,153,154,155,158,159,164,165,170],{},"標準的なkubeadmクラスタでPSA導入を解説する記事の多くは、この「何もしなければ何も起きない」という前提で書かれている。だが",[60,156,157],{},"K3sは事情が異なる","。",[15,160,163],{"href":161,"rel":162},"https:\u002F\u002Fdocs.k3s.io\u002Fsecurity\u002Fhardening-guide",[19],"K3s公式のCISハードニングガイド","は、「K3sはデフォルトでPod SecurityもNetworkPolicyも一切含まない」と明記しており、K3sならではの同梱コンポーネントが後述する落とし穴を生む。こうした構成差分を自前で追いかけ続ける運用コストは、",[15,166,169],{"href":167,"rel":168},"https:\u002F\u002Fkubo.hexabase.io\u002F",[19],"Kubo","のようなマネージドK3sサービスを検討する動機のひとつにもなる。",[23,172,174],{"id":173},"_2-標準kubernetesの手順通りにrestrictedを適用したらk3sのservicelbが止まった","2. 標準Kubernetesの手順通りにrestrictedを適用したら、K3sのServiceLBが止まった",[11,176,177],{},[30,178],{"alt":179,"src":180},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-pod-security-admission-restricted-servicelb-outage\u002Fsection02.webp",[11,182,183,184,187,188,191,192,197],{},"典型的な事故のシナリオはこうだ。CISベンチマーク対応のためK3sクラスタ全体にrestrictedを適用しようと、kubernetes.io公式の手順に従って",[72,185,186],{},"kubectl label","を全namespaceへ実行する。Baselineプロファイルの時点で既に、hostPathボリュームの使用は",[72,189,190],{},"spec.volumes[*].hostPath","が未定義であることを要求され禁止される（",[15,193,196],{"href":194,"rel":195},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fsecurity\u002Fpod-security-standards\u002F",[19],"Pod Security Standards公式ドキュメント","）。Restrictedはこれをさらに厳格化したものだ。",[11,199,200,201,204,205,210],{},"適用直後、クラスタ内のLoadBalancer型Serviceが次々と外部IPを失う。原因を追うと、K3sが標準で同梱しているロードバランサ機能「ServiceLB」が提供する",[72,202,203],{},"svclb-*","という名前のPodが、新しく作成できなくなっていることが分かる。ServiceLBはServiceごとにPodをスケジュールし、ホストのポートを直接bindする仕組みで動作する（",[15,206,209],{"href":207,"rel":208},"https:\u002F\u002Fdocs.k3s.io\u002Fnetworking\u002Fnetworking-services",[19],"K3s公式のネットワーキング解説","）。この仕組みが、restrictedプロファイルの制約と正面から衝突する。",[11,212,213],{},"標準Kubernetesクラスタでは外部ロードバランサはクラウドプロバイダーのLBサービスに委ねられ、クラスタ内にこの種のPodは存在しない。つまり**「標準Kubernetesの手順では問題にならないものが、K3sでは致命的な障害になる」**という典型例がServiceLBなのだ。",[23,215,217],{"id":216},"_3-原因はservicelbが要求するnet_adminとunsafe-sysctls","3. 原因はServiceLBが要求するNET_ADMINとunsafe sysctls",[11,219,220],{},[30,221],{"alt":222,"src":223},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-pod-security-admission-restricted-servicelb-outage\u002Fsection03.webp",[11,225,226,229],{},[15,227,163],{"href":161,"rel":228},[19],"には、restrictedを有効化する際に用意すべき3種類のポリシー例が明記されている。",[231,232,233,240,246],"ul",{},[234,235,236,239],"li",{},[60,237,238],{},"restricted-psp",": 標準的な制限ポリシー",[234,241,242,245],{},[60,243,244],{},"system-unrestricted-psp",": kube-systemのシステムPod用に権限を緩和したポリシー",[234,247,248,251],{},[60,249,250],{},"svclb-psp",": ServiceLB専用。以下を明示的に許可する",[65,253,255],{"className":67,"code":254,"language":69,"meta":70,"style":70},"allowedCapabilities:\n  - NET_ADMIN\nallowedUnsafeSysctls:\n  - net.ipv4.ip_forward\n  - net.ipv6.conf.all.forwarding\n",[72,256,257,264,273,280,287],{"__ignoreMap":70},[75,258,259,262],{"class":77,"line":78},[75,260,261],{"class":81},"allowedCapabilities",[75,263,110],{"class":85},[75,265,266,270],{"class":77,"line":93},[75,267,269],{"class":268},"sgJMe","  -",[75,271,272],{"class":89}," NET_ADMIN\n",[75,274,275,278],{"class":77,"line":104},[75,276,277],{"class":81},"allowedUnsafeSysctls",[75,279,110],{"class":85},[75,281,282,284],{"class":77,"line":113},[75,283,269],{"class":268},[75,285,286],{"class":89}," net.ipv4.ip_forward\n",[75,288,289,291],{"class":77,"line":124},[75,290,269],{"class":268},[75,292,293],{"class":89}," net.ipv6.conf.all.forwarding\n",[11,295,296,297,300],{},"ServiceLBはポートを直接bindしIPフォワーディングを制御する都合上、",[72,298,299],{},"NET_ADMIN","ケーパビリティと特定のunsafe sysctlsを必要とする。これらはrestrictedプロファイルが原則として禁止する項目であり、例外として明示的に許可しない限りPodの作成自体が拒否される。",[11,302,303,304,306,307,310,311,315],{},"重要なのは、この",[72,305,250],{},"という概念が",[60,308,309],{},"K3s公式ドキュメントにしか出てこない","という点だ。汎用的なPod Security Admission解説記事や、標準Kubernetes向けのCISベンチマーク対応ガイドをいくら読んでも、ServiceLBという単語は登場しない。K3sをマネージドK8sの選択肢として検討する際、「標準Kubernetesの知識で十分」と思い込んでいると、こうした同梱コンポーネント固有の例外設定を見落としやすい。",[15,312,314],{"href":167,"rel":313},[19],"Kubo Cloud","のようにPure Kubernetes構成をベースにしたサービスであれば、こうした既知の落とし穴を踏まえた標準構成が最初から提供される余地がある。",[23,317,319],{"id":318},"_4-k3sのpsa導入で見落としやすいもう一つの落とし穴","4. K3sのPSA導入で見落としやすい、もう一つの落とし穴",[11,321,322],{},[30,323],{"alt":324,"src":325},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-pod-security-admission-restricted-servicelb-outage\u002Fsection04.webp",[11,327,328],{},"ServiceLB以外にも、K3s標準構成の中にはPSA導入時に注意すべきコンポーネントがある。",[11,330,331,332,335,336,339,340,345],{},"K3sの既定ストレージである",[72,333,334],{},"local-path-provisioner","は、PVCのプロビジョニング時に内部でhelperPodを生成しhostPathを扱う実装になっている。この仕組み自体はPod自身がhostPathボリュームを直接マウントするわけではないため、アプリケーションPodがrestrictedポリシーに抵触することは基本的にない。ただし設定ミスがセキュリティリスクに直結する点は意識しておきたい。実際に、",[72,337,338],{},"local-path-config","ConfigMapへの書き込み権限を持つユーザーがhelperPodテンプレートを操作し、特権コンテナやhostPathマウントを注入できる脆弱性（CVE-2026-44543）が報告され、0.0.36で修正されている（",[15,341,344],{"href":342,"rel":343},"https:\u002F\u002Fosv.dev\u002Fvulnerability\u002FGHSA-7fxv-8wr2-mfc4",[19],"OSV.devの脆弱性データベース","）。PSAのrestrictedポリシーを適切に運用することは、こうした設定ミス由来の攻撃経路を狭める効果もある。",[11,347,348,349,354,355,358],{},"また、監視基盤として一般的なnode-exporterのようなDaemonSetは、ホストのメトリクスを取得するためhostNetworkやhostPathを必要とし、baseline・restrictedいずれのプロファイルにも非準拠となる（",[15,350,353],{"href":351,"rel":352},"https:\u002F\u002Foneuptime.com\u002Fblog\u002Fpost\u002F2026-07-31-containerized-node-exporter-host-metrics\u002Fview",[19],"OneUptimeの技術解説","）。これはK3s固有の問題ではなく標準Kubernetesでも同様に起きるが、",[60,356,357],{},"K3sクラスタをまとめてrestrictedにする際は、ServiceLBとあわせて事前に洗い出しておくべき対象","として押さえておきたい。",[23,360,362],{"id":361},"_5-安全にpod-security-admissionを導入するためのk3sチェックリスト","5. 安全にPod Security Admissionを導入するためのK3sチェックリスト",[11,364,365],{},[30,366],{"alt":367,"src":368},"section05","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-pod-security-admission-restricted-servicelb-outage\u002Fsection05.webp",[11,370,371],{},"K3sクラスタにPSAを安全に導入するには、次の手順を踏むとよい。",[373,374,375,393,402,408,414],"ol",{},[234,376,377,380,381,384,385,387,388,392],{},[60,378,379],{},"v1.25以降ならPSA設定ファイルを用意する",": ",[72,382,383],{},"--kube-apiserver-arg=\"admission-control-config-file=...\"","でAdmissionConfigurationを指定し、",[72,386,250],{},"相当の例外を事前に組み込む（",[15,389,391],{"href":161,"rel":390},[19],"K3s公式ハードニングガイド","）",[234,394,395,398,399,392],{},[60,396,397],{},"いきなりenforceにしない",": まずwarn・auditモードで全namespaceに適用し、違反が出るワークロードを洗い出す（",[15,400,40],{"href":17,"rel":401},[19],[234,403,404,407],{},[60,405,406],{},"kube-system・ServiceLB関連namespaceは個別に扱う",": 一律ラベルではなく、システムコンポーネントが稼働するnamespaceだけ例外ポリシーを設計する",[234,409,410,413],{},[60,411,412],{},"hostPath\u002FhostNetworkに依存するコンポーネントを棚卸しする",": local-path-provisionerのhelperPod、監視エージェント等を事前にリストアップする",[234,415,416,419],{},[60,417,418],{},"段階的にenforceへ移行する",": 違反がゼロになったnamespaceから順にenforceへ切り替える",[11,421,422,423,426],{},"この手順を自前で毎回組み立て、K3sのバージョンアップごとに例外ポリシーの差分を追い続けるのは、決して小さくない運用コストだ。",[15,424,169],{"href":167,"rel":425},[19],"のようなK3sベースのマネージドサービスであれば、こうした既知の設定差分を踏まえた構成をあらかじめ提供できる余地がある。",[23,428,430],{"id":429},"_6-まとめ-標準kubernetesの知識だけでは足りない","6. まとめ ― 「標準Kubernetesの知識」だけでは足りない",[11,432,433],{},"K3sはCNCF認定の軽量Kubernetesディストリビューションであり、APIレベルでは標準Kubernetesと高い互換性を持つ。しかしServiceLBのような同梱コンポーネントは、標準Kubernetesのクラウド依存のロードバランサ構成とは根本的に異なる前提で動いている。Pod Security Admissionという「Kubernetes標準機能」を導入する場面でも、この構成差分が思わぬ障害を引き起こす。",[11,435,436],{},"K3s vs 標準Kubernetesという比較軸で技術選定をする際は、機能一覧やベンチマーク数値だけでなく、「同梱コンポーネントがセキュリティポリシーとどう干渉するか」まで踏み込んで確認しておきたい。",[11,438,439,440,443],{},"運用負荷の高いセキュリティ設定の棚卸しや例外ポリシーの維持を外部に任せたい場合は、",[15,441,314],{"href":167,"rel":442},[19],"のPure Kubernetes構成とAI-Driven Deploymentが選択肢になる。EKS\u002FAKSのコストと複雑さに悩まされず、K3sベースの本格的なKubernetesをそのまま使える。",[11,445,446,447,452],{},"一方、金融機関や医療機関のようにデータ主権・Air-Gapped環境が求められる現場では、ハードニング済みの構成を自社インフラ内に閉じて運用できる",[15,448,451],{"href":449,"rel":450},"https:\u002F\u002Fwww.hexabase.com\u002Fproduct\u002Fkubo\u002Fon-premise",[19],"Kubo On-Premise","が適している。CISベンチマーク対応やPod Security Admissionの例外設計をゼロから自前で積み上げる前に、こうした選択肢も検討してみる価値はあるはずだ。",[11,454,455,456,461],{},"セキュリティ設定の見直しやK3s移行を具体的に検討しているなら、",[15,457,460],{"href":458,"rel":459},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[19],"お問い合わせ","から相談してみてほしい。",[463,464,465],"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 .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);}html pre.shiki code .sgJMe, html code.shiki .sgJMe{--shiki-default:#9ABDF5}",{"title":70,"searchDepth":93,"depth":93,"links":467},[468,469,470,471,472,473],{"id":25,"depth":93,"text":26},{"id":173,"depth":93,"text":174},{"id":216,"depth":93,"text":217},{"id":318,"depth":93,"text":319},{"id":361,"depth":93,"text":362},{"id":429,"depth":93,"text":430},"2026-10-16","K3sでPod Security Admissionのrestrictedプロファイルを有効化したら、標準Kubernetesのガイド通りに進めたのにServiceLBが機能停止した。原因と安全な導入手順をK3s公式ハードニングガイドの記述とともに解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-pod-security-admission-restricted-servicelb-outage\u002Ftitle.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fk3s-pod-security-admission-restricted-servicelb-outage",{"title":5,"description":475},"blog\u002Fja\u002Fk3s-pod-security-admission-restricted-servicelb-outage",[485,486,487,488,489,490],"k3s","kubernetes","pod-security-admission","pod-security-standards","servicelb","security","kfgYyq3O5kb7RimOYHJBGWBGY8JR6ncPZdtQO_GJm3U",[493,502,511,520,528,534],{"path":494,"title":495,"description":496,"date":497,"tags":498},"\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",[485,486,499,489,500,501],"cert-manager","tls","lets-encrypt",{"path":503,"title":504,"description":505,"date":506,"tags":507},"\u002Fblog\u002Fja\u002Fk3s-networkpolicy-dual-stack-kube-router-ipv6-gap","「K3sはNetworkPolicyを無視する」は嘘だった。それでも通信が漏れていた、ServiceLBという死角","K3sはkube-router内蔵コントローラでNetworkPolicyをデフォルト強制する。それでもLoadBalancer経由の通信だけが漏れる理由は、ServiceLBの実装とNetworkPolicy APIの恒久的な制約が組み合わさった結果だった。検証手順と対処法を解説する。","2026-09-24",[485,486,508,489,509,510],"networkpolicy","kube-router","network-security",{"path":512,"title":513,"description":514,"date":515,"tags":516},"\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",[485,486,517,489,518,519],"traefik","ingress-nginx","load-balancer",{"path":521,"title":522,"description":523,"date":524,"tags":525},"\u002Fblog\u002Fja\u002Fk3s-zero-trust-kubectl-management-access","社内VPNを信頼するのをやめる。K3s管理アクセスを『境界のない』設計に変える3つの手順","K3sクラスタへの管理アクセスを、社内VPN前提のまま設計していないか。kubectl・Rancherダッシュボードへのアクセスを『境界』ではなく『アイデンティティ』で守るK3sゼロトラスト設計の3つの手順と、導入時に陥りやすい落とし穴まで具体的に解説する。","2026-09-05",[485,486,526,490,527],"zero-trust","rancher",{"path":529,"title":530,"description":531,"date":532,"tags":533},"\u002Fblog\u002Fja\u002Fkubernetes-certificate-management-cert-manager-process-debt","証明書の更新、1行のコードより2ヶ月の会議が長かった。Kubernetesの証明書管理が『技術』ではなく『手続き』の問題である理由","Kubernetesの証明書管理は技術的には数日で終わる。だが実際に時間がかかるのは合意形成という『手続き』だ。cert-managerによる自動化と、組織的負債をなくす設計を解説する。","2026-08-09",[485,486,499,500,490],{"path":535,"title":536,"description":537,"date":538,"tags":539},"\u002Fblog\u002Fja\u002Fai-agent-sandbox-kata-containers-kubernetes","AIエージェントのコードは「信頼できる製品」じゃない。Kubernetesサンドボックス設計の答え","AIエージェントが生成・実行するコードはもう「信頼できる製品」ではない。KubernetesでAIエージェント向けサンドボックスを設計する際、コンテナ分離の限界とKata Containersによるマイクロ VM分離がなぜ必要になるのかを解説する。","2026-08-08",[485,486,540,541,490],"kata-containers","ai-agent",1792592609684]