JAWS-UG CDK Conference 2026 cdk8sとHelm 、 どちらを選ぶべきか？ EKS実地検証から導くレイヤ別の使い分け Soushi Hiruta 20分 ＝ 説明15分 ＋ デモ3分 ＋ 冒頭・締め2分 

01 — INTRODUCTION 自己紹介 蛭田 聡司 Kuberetes、マイクロサービス基盤構築。laCとしてAWS CDK 高トラフィックなコンテナ基盤設計、構築、運用 cdk8s × Helm — JAWS-UG CDK 2026 0.5分 AWS Community Builder 2025- X web_se GitHub clouddev-code 

01 — INTRODUCTION cdk8s × Helm — JAWS-UG CDK 2026 0.5分 

02 — 導入 導入 

02 — 導入 KubernetesのCDとYAML管理の現実 kubectl apply の限界 手動適用は再現性がない 「いま何が動いているか」が追えない レビュー・ロールバックの仕組みが必要 素のYAMLの可読性 apiVersion: apps/v1 kind: Deployment metadata: name: api # …数百行つづく。重複・インデント地獄 環境差分・重複をコピペで管理する消耗戦 cdk8s × Helm — JAWS-UG CDK 2026 1.5分 共通モジュールの組み込みしづらさ 

02 — 導入 実際のYAML — これで「1つのDeployment」 インデント揺れ 5スペース・9スペース混在。validに はなるが、レビューで気づけるか？ 深すぎるネスト affinityは8段。1階層ずれても気づけ ない cdk8s × Helm — JAWS-UG CDK 2026 導入補足 共通コンポーネント Pod配置ルール 

02 — 導入 非機能要件という重荷 01 OpenTelemetry 計装・トレース 02 ログ・メトリクス 収集の標準化 03 セキュリティ基準 Pod Security 等 04 リソース管理 requests / limits ↓ これらをすべてのワークロードに、漏れなく・一貫して提供したい cdk8s × Helm — JAWS-UG CDK 2026 1分 01 Istio sideca サービスメッシュ 02 ガバナンス 収統制 ↓ 

03 — 課題整理 課題整理 

03 — 課題整理 解決アプローチは2系統 プログラミング型 cdk8s 汎用プログラミング言語で マニフェストを合成する テンプレート型 Helm YAMLテンプレート＋values.yamlで 差分をパラメータ 化する cdk8s × Helm — JAWS-UG CDK 2026 1分 

03 — 課題整理 前提整理 — 4つのツールの関係 AWS CDK コードでインフラ定義 ↓ synth CloudFormation → AWSリソース cdk8s+ ＝ 高レベルAPI cdk8s 同じ開発体験をK8sへ ↓ synth K8sマニフェスト （純粋なYAML） Helm chart + values.yaml ↓ template / install K8sマニフェスト ＋ リリース管理 cdk8s × Helm — JAWS-UG CDK 2026 1分 

04 — cdk8s cdk8s 

04 — cdk8s cdk8sとは 汎用プログラミング言語で Kubernetesマニフェスト を合成するツールキット TypeScript / Python / Java / Go に対応 出力は純粋なYAML — kubectl / GitOpsにそのまま乗る AWS CDKと同じConstructモデル CNCFにおける位置づけ Sandbox 合成コマンド cdk8s synth cdk8s × Helm — JAWS-UG CDK 2026 1分 

04 — cdk8s TypeScript → YAML → sync 1.TypeScriptで定義 // main.ts newkplus.Deployment( chart,'web-app', { replicas:3, containers: [{ image:'api:1.2.0', }], }); npm run synth:app → 2.YAML生成 ＋ push # app/dist/*.k8s.yaml kind: Deployment metadata: name: web-app spec: replicas:3 $ git push OutOfSync → 3.Argo CDへsync指示 $ kubectl patch \ application web-app \ -n argocd \ --type merge \ -p'{"operation": {"sync":{}}}' # 適用はArgo CDが実行 cdk8s × Helm — JAWS-UG CDK 2026 デモ補足 

04 — cdk8s TypeScript → Cloud Formation→ deploy 1.TypeScriptで定義 // main.ts Const bucket = new s3.Bucket( this, “MyBucket”, { }); cdk synth → synth *.yaml Resources: Type: AWS::S3::Bucket Properties: BucketName: MyBucket UpdateReplacePolicy: Retain DeletionPolicy: Retain cdk deply → deploy $ cdk deploy \ Cdk deploy S3 cdk8s × Helm — JAWS-UG CDK 2026 デモ補足 bucketName: “MyBucket” Metadata: CDKMetadata: Type: AWS::CDK::Metadata Metadata: aws:cdk:path: S3/CDKMetadata/Default Parameters: BootstrapVersion: Type: AWS::SSM::Parameter::Value Default: /cdk-bootstrap/hnb659fds/version 

04 — cdk8s cdk8sの強み 1 型安全性 apply前にコンパイルエラーで気づける 2 フィードバックループの短縮 IDE補完・単体テスト・スナップショットテスト 3 cdk8s+の高レベルAPI 数行でDeployment＋Service＋良い既定値 constapp =new App(); constchart =new Chart(app,'web'); newkplus.Deployment(chart,'api', { replicas:3, containers: [{ image:'registry/api:1.2.0', portNumber:8080, }], }); app.synth();// → dist/*.k8s.yaml cdk8s × Helm — JAWS-UG CDK 2026 1.5分 

04 — cdk8s cdk8s import — CRDから型を生成 CRD定義 crd.yaml $ cdk8s import crd.yaml → 型付きコンストラクト imports/*.ts k8sコアAPIもサードパーティCRDも、同じ型安全な書き味で扱える cdk8s × Helm — JAWS-UG CDK 2026 1分 

05 — helm helm 

05 — Helm Helmとは Kubernetesの デファクト・パッケージマネー ジャ chart（テンプレート）＋ values.yaml（パラメータ） 巨大なOSSチャート資産をそのまま導入できる リリース管理（install / upgrade / rollback）内蔵 CNCFにおける位置づけ Graduated 最新メジャー Helm 4.0 cdk8s × Helm — JAWS-UG CDK 2026 1分 

05 — Helm Helmの強み 1 基盤とアプリの境界分離 chartは基盤チーム、values.yamlはアプリチーム 2 ガバナンスの共通適用 共通chartに非機能要件を織り込み全体へ配布 3 エコシステムの厚み 主要OSSはほぼchartが公式提供される # values.yaml — アプリチームが触るのはここだけ image: tag:"1.2.0" replicas:3 resources: requests: cpu:250m # 非機能はchart側に内蔵 → 全アプリに共通適用 cdk8s × Helm — JAWS-UG CDK 2026 1.5分 

05 — Helm Helmの強み 1 Helm diff helm diff upgrade myapp ./helm -f helm/values.yaml 2 Dru run helm install myapp ./helm --dry-run --debug 3 helm外で作成されたリソースをhelm管理下 helm install myapp ./helm --take-ownership cdk8s × Helm — JAWS-UG CDK 2026 1.5分 

06 — 比較 比較 

06 — 比較 正面比較 観点 cdk8s Helm 型安全性 ◎ コンパイル時に検出 △ lint / schema 頼み テスト容易性 ◎ 単体・スナップショット △ helm test / 外部ツール OSS資産の再利用 △ Helm construct経由 ◎ 公式chartが豊富 ガバナンス適用 ○ 共通コンストラクト ○ 共通chart + values GitOps親和性 ○ 純YAML出力 ○ ArgoCD / Flux対応 学習コスト △ 言語＋Constructの学習 ○ 利用だけなら低い cdk8s × Helm — JAWS-UG CDK 2026 2分（調整弁） 

07 — EKS実機検証 EKS実機検証 

07 — EKS実地検証 EKS実地検証 — 3層構成 Workload層 アプリのDeployment / Service / Ingress 変更頻度：高 担当： アプリ Platform層 AWS Load Balancer Controller、 変更頻度：中 担当： 基盤 Cluster層 EKS Cluster / VPC / IAM（AWS CDKの領分） 変更頻度：低 担当： 基盤 cdk8s × Helm — JAWS-UG CDK 2026 1.5分 

09 — DEMO デモ環境の全体アーキテクチャ GitHub — GitOpsのsource of truth Kubernetesリソース — cdk8s + cdk8s-plus-33 で 定義 cdk8s × Helm — JAWS-UG CDK 2026 デモ補足 

07 — EKS実地検証 AWS CDKとの統合の勘所 2 マニフェスト適用はArgoCD経由のk8s API通信 EKS APIエンドポイント。ネットワーク到達性が前提になる 3 dualstack Cluster ＋ NAT Gatewayなし構成の注意点 外向き経路がない分、必要なAWSサービスへのinterface endpointを明示的に設計する cdk8s × Helm — JAWS-UG CDK 2026 1.5分 1 CDKからマニフェスト操作もできるが、別途Lambdaが必要になる kubectlLayerというLambdaが作られる 

07 — EKS実地検証 cdk8s × Helm — JAWS-UG CDK 2026 1.5分 

08 — ハイブリッド ハイブリッド型という選択 Workload層 変更が多く、型とテストが効く領域 cdk8s Platform層 OSSの公式chartをそのまま使う領域 Helm Cluster層 AWS CDKが土台。chartの導入もここから AWS CDK ＋ Helm Helm constructを使えば、cdk8sのコードから既存chartも取り込める — 二者択一ではない cdk8s × Helm — JAWS-UG CDK 2026 1.5分 

09 — DEMO デモ — 設定変更 Workload層をcdk8sで変更してリリースするまで コード変更 → cdk8s synth → デプロイ → 動作確認 backup: 録画・スクリーンショットをこのスライドの裏に用意 

09 — DEMO デモの実際の流れ — 適用するのはArgo CD 1 cdk8s synth— YAMLを再生成 app/dist/*.k8s.yaml を生成するだけ。「適用」ではない 2 git push— GitOpsのsource of truthを更新 生成済みYAMLを含めてpush → Argo CDが検知し OutOfSync に 3 kubectl patch— 同期トリガー（直接パッチではない） Application CRD に operation.sync を書き込むだけ。Deployment等には触れない ※argocd app sync でも同じ操作が可能 4 実際に適用するのは Argo CD コントローラ sync operationを検知し、reconcileループでEKS上のリソースを収束させる cdk8s × Helm — JAWS-UG CDK 2026 デモ補足 

09 — DEMO リリース手順 — 変更から反映確認まで 1 プロパティを変更 // a. デフォルト値を変える readonlycpuMillis?:number; // @default 100 ← ここ // b. 呼び出し側で上書き new WebApp(app,'web-app', { cpuMillis:500, replicas:3, }); 既定動作を変えるならa、個別上書きならb 2 synthして差分確認 $ npm run synth:app $ git diff app/dist/ 意図した箇所だけ変わったかをdiffで必ず確認 3 コミット & push $ git add app/src/ app/dist/ $ git push origin main app/dist/はsource of truth — 必ずコミットに含める 4·5 Argo CDを手動sync # refresh（任意・自動検知も可） $ kubectl annotate application web-app \ -n argocd argocd.argoproj.io/refresh=hard # sync実行 $ kubectl patch application web-app \ -n argocd --type=merge -p \ '{"operation":{"sync": {"revision":"main","prune":true}}}' 方法A: kubectlのみで完結（推奨）／方法B: argocd CLIでも 同じsyncを発行可 6 反映結果を確認 # Sync / Health ステータス $ kubectl get application web-app -n argocd # Podの実体 $ kubectl get pods -n web-app # 変更値の反映（例: CPU） $ kubectl get pod -n web-app \ -o jsonpath='{.items[0].spec .containers[0].resources}' Synced / Healthyになれば完了 cdk8s × Helm — JAWS-UG CDK 2026 デモ補足 

09 — DEMO 1 今、Nginx 1.30.2で動いている。Nginx 1.30.4にイメージを上げる 2 Replica 台数を変える 3 Ksecurity contextを変える cdk8s × Helm — JAWS-UG CDK 2026 デモ補足 デモ想定 

10 — 結論 結論 — 判断フローとレイヤ別推奨 OSSチャートをそのまま使いたい？ Yes Helm No 型・テスト・IDE補完を重視？ Yes cdk8s No チームの 得意な方 レイヤ別推奨 Workload層 cdk8s Platform層 Helm Cluster層 Helm 二者択一ではなく、層で使い分ける cdk8s × Helm — JAWS-UG CDK 2026 1.5分 

Appendix エコシステム俯瞰 — kro / ACK kro Kube Resource Orchestrator ACK S3、DynamoDBのリソースをKubernetes リソース定義 cdk8s × Helm — JAWS-UG CDK 2026 時間外 

Appendix 比較軸の各論 テスト容易性の実例 スナップショットテストのコード例（プレースホルダー） ArgoCD / Flux との連携 リポジトリ構成・synth artifactの扱い（プレースホルダー） cdk8s × Helm — JAWS-UG CDK 2026 時間外 

Appendix VPAによる自動 in-place リサイズ — 構成 metrics-server 実測CPU / メモリ → VPA recommender 推奨値を計算 → status へ 確実・即座 admission-controller — 新規Pod作成時 Mutating WebhookがPod作成を横取りし、Gitの値ではなく推奨値で起動 タイミングに幅 updater — 稼働中Podを定期評価（約1分周期） CPU等 → in-placeリサイズ（再起動なし）／memory削減 → Pod再作成 にフォールバック updateMode: InPlaceOrRecreate／ VPAはPodだけを書き換えるためDeploymentに差分が出ず、Argo CDがOutOfSyncにならない — GitOpsとVPAは競 合しない設計 cdk8s × Helm — JAWS-UG CDK 2026 時間外 

Appendix VPAデモ — 2つの動作パス A — 確実・即座 新規Pod作成時に補正 cpuMillisを過大値（100→800m）に変更してpush → sync。ローリングアップ デートの新規Podをadmission-controllerが推奨値で起動 $ kubectl get pod -n web-app -o jsonpath=\ '{.items[0]...resources.requests.cpu}' # Git上は800m → 実際は推奨値(例:50m)で起動 Deploymentのtemplateは800mのまま＝OutOfSyncにならない B — タイミングに幅 稼働中Podをin-place補正 kubectl patch --subresource resize で意図的に乖離させ、updaterの補正 をログ監視（再起動なし＝restartCount不変） $ kubectl logs -n vpa deploy/vpa-updater -f # "Not updating a short-lived pod..." 注意: 作成直後のPodはヒステリシス制御（既定12h）で保護され補正されない。確実 に見せるならAを使う cdk8s × Helm — JAWS-UG CDK 2026 時間外 

Appendix 想定QA Hlem 4.0でmulti-documenta yaml、WASM プラグイン、リリースステータス管理 dualstackですが、NAT Gatewayを使ったのは、GitHubがAAAAに対応していないので、IPv6 Podからだと通信不可 CDK/Cloudformationだとデプロイの遅さが気になる cdk8s × Helm — JAWS-UG CDK 2026 時間外 CDKからk8s マニフェスト扱うこともできたが、GitHub Actions経由にしたのは、KubectlLayerのLambda依存を無くしたかった laC管理下にインポートするのはhelmの方がしやすい印象。論理IDとか気をつける点 

Appendix 参考資料 cdk8s.io — 公式ドキュメント helm.sh — 公式ドキュメント TypeScript 7.0でのJS API未対応 cdk8s × Helm — JAWS-UG CDK 2026 時間外 jsii VPA Kro https://docs.aws.amazon.com/eks/latest/userguide/kro.html ACK https://docs.aws.amazon.com/eks/latest/userguide/ack.html https://qiita.com/watany/items/daf433338de5b6858ed6