ACK + kro で実現する K8s ネイティブな AWS リソース管理 ~ Helm の限界を kro の依存解決で超える ~ 2026年6⽉16⽇ 株式会社ログラス 

⾃⼰紹介 mekka∕⾒形 親久 https://x.com/melpo_mel∕Chikahisa Mikata 株式会社ログラス 共通基盤部 SRE SIerでアプリケーションエンジニアとしてキャリアスタート ToB SaaS企業でSRE組織⽴ち上げを経験。2024年よりログラスのクラウド基盤チー ムに参画、SREの推進とプラットフォーム開発に従事 

アジェンダ ACK + kro で Helm の構造的限界を補完した話 • ACK で AWS リソースを K8s から管理する仕組みと課題 • kro（Kube Resource Orchestrator）で何が変わるのか • PoC で実証した「⽂字列構築」から「実値参照」への移⾏ 今⽇お話しすること 

Helm + ACK で起きている課題 

課題 マルチアカウント構成 

課題 • サービスに必要な AWS リソースは開発者⾃⾝が構成すべき • SRE への依頼駆動ではスケールしない ⽬指す姿 — 開発者への権限移譲 開発者が YAML を書くだけで、AWS リソースもセルフサービスで構築できる世界 → この思想を実現するために ACK を採⽤した 

課題 ACK — YAML で AWS リソースを管理する 

課題 • 必要な IAM 権限を policies に宣⾔するだけ • actions（許可する操作）と resources（対象 ARN）を記述 • Helm が⾃動で IAM Role + PodIdentityAssociation を⽣成 • 3つの ACK コントローラーを全環境で運⽤中 開発者が書く values.yaml 

課題 • PodIdentityAssociation は IAM Role の ARN が必要 • 現状: 命名規約から ARN を⽂字列構築している • roleARN: "arn:aws:iam::{{ accountId }}:role/{{ roleName }}" • Account ID は環境別 map の lookup に依存 → 命名規約が破綻すると、存在しない Role を参照して静かに壊れる 問題1: ARN の⽂字列構築 

課題 • S3 bucket policy 等は IAM Role の ARN を参照する必要がある ① まず base chart で IAM Role を apply → AWS に Role が作成される ② ARN が確定してから S3 chart で bucket policy を apply • chart 間に依存関係があると 1回の apply で完結しない → 依存する全リソースを同時に宣⾔して、順序は⾃動で解決してほしい 問題2: リソース間の依存で apply を分けざるを得ない 

課題 • Helm はビルドタイムのツール • リソースの status は apply 後にしか存在しない 根本原因 Helm のレンダリング時には、まだ存在しないリソースの値を参照できない → これを解決するのが kro（Kube Resource Orchestrator） 

kro とは — Helm と何が違うのか 

kro とは Helm と kro の違い 観点 Helm kro 実⾏タイミング ビルド時 （テンプレートレンダリング） ランタイム （コントローラー常駐） リソース間依存 表現不可 （同時 apply） CEL 参照で⾃動解決 status 参照 不可 （レンダリング時に未存在） 可能 （status を監視して待機） テンプレーティング 強⼒ （range, tpl, include） CEL のみ（限定的） 

kro とは kro の仕組み — ResourceGraphDefinition 

kro とは • role と pia の2つのリソースを定義 • pia の roleARN が role の status を参照 • kro が CEL 参照を解析し作成順序を⾃動決定 • Role → status 待機 → PIA の順で作成される RGD の実際のコード（PoC より） 

PoC: kro + ACK で課題を解決する 

PoC • 検証環境: kro v0.9.2 / kind / ACK CRD のみ（コントローラーなし） • 同⼀ RGD 内で ACK リソースの作成順序を制御できるか • RGD を跨いで別 chart のリソースを安全に参照できるか • Helm と kro の責務分割が実⽤的に機能するか • 開発者の values 構造を変えずに移⾏できるか PoC で検証したこと 

PoC Before / After — roleARN の解決 Before（Helm ⽂字列構築） After（kro status 参照） roleARN の 取得⽅法 命名規約 + 環境別 map からARN を⽂字列構築 ${role.status.ackResourceMetadata.arn} status から実値を取得 環境別 Account ID _helpers.tpl に環境別 map が必要 不要（ACK が status に書き込む） chart 間の 依存関係 apply を分けて⼿動で順序を管理する必要がある kro が status を監視し⾃動で順序を解決 障害リスク 命名規約の破綻で静かに壊れる 規約への依存がなく破綻リスク消滅 

PoC ① kubectl apply で kro に instance を投⼊ ② kro が IAM Role を先に作成する ③ PIA の作成は保留 — Role の ARN がまだ存在しないため ④ ACK が Role を AWS に作成し、ARN が status に反映される ⑤ kro が ARN の存在を検知し、PIA を作成する → リトライに頼らず、確実に正しい順序でリソースが作成される kro の順序制御 — 同⼀ RGD 内の依存解決 

PoC ① base chart が IAM Role を作成（RGD-A） ② S3 chart が externalRef で Role の ARN を参照（RGD-B） ③ Role が未作成の場合、kro が⾃動で待機する ④ Role が作成されると、kro が検知して RGD-B の処理を再開 ⑤ 複数の chart から同⼀リソースを参照しても競合しない → chart 間の依存関係も kro で安全に解決できる kro の順序制御 — RGD を跨いだ依存解決 

PoC Helm × kro の責務分割 

PoC • 同⼀ RGD 内の依存関係を kro が⾃動で順序制御できる • RGD を跨いだ参照も externalRef で安全に解決できる • Helm のテンプレーティングと kro の順序制御は共存できる • 開発者が書く values.yaml の構造を変えずに移⾏できる → Helm の構造的限界を kro で補完できることが実証された PoC でわかったこと 

PoC 開発者の体験は変わらない Helm は継続利⽤。kro が⽣成した CRD を Helm が内部で利⽤する構成 開発者が書く values.yaml は現⾏と完全に同⼀ サービス側の変更ゼロ 開発者（変わらない） • values.yaml の構造は同じ • policies に actions / resources を書くだけ • Helm + ArgoCD の GitOps フローはそのまま SRE 内部（変わる） • Helm の出⼒: ACK CR → kro instance • kro が ordering + drift 修正を担当 • ARN: ⽂字列構築 → status 実値参照 → 開発者は今まで通り、基盤はより堅牢に 

まとめ • ACK で AWS リソースを K8s の世界に持ち込み、開発者のセルフサービスを実現 • Helm はテンプレーティング、kro はランタイムの依存解決 — 補完関係 • ACK + kro で「⽂字列構築」から「実値参照」へ — 基盤の信頼性を向上 • 開発者体験を変えずに、内部実装を堅牢化できる • 現在 PoC 完了、Helm chart のフル移⾏に向けて推進中 → ツールの得意領域を⾒極め、組み合わせることで Platform の信頼性を⾼める まとめ 

No content