Skaffold

解決する課題

Kubernetes 向けの開発では、コードを 1 行直すたびに「イメージをビルドし、レジストリへプッシュし、マニフェストを書き換えて、クラスタへ適用し、ログを確認する」という長い手順を踏みます。この「内側の開発ループ（inner dev loop）」が手作業だと、変更から動作確認までに毎回数分かかり、試行錯誤のリズムが崩れます。Skaffold はこの一連の流れを 1 コマンドへまとめ、ファイル変更を検知して自動で回します。

• ソースを保存するたびにビルドからデプロイまでを自動再実行し、即座に挙動を確認したい
• ビルド・タグ付け・デプロイ先の定義を宣言的なファイル 1 つに集約し、各人の手順差をなくしたい
• 開発・CI・本番で同じ設定を使い回し、環境ごとにスクリプトを書き分けたくない
• Docker / Jib / Buildpacks など複数のビルド方式や、kubectl / Helm / Kustomize など複数のデプロイ方式を統一的に扱いたい
• デプロイ後のログ追従やポートフォワードまで含めて、開発体験をひとまとめにしたい

主要概念と用語

• skaffold.yaml: ビルド・テスト・デプロイの構成を宣言的に記述する設定ファイル。プロジェクトのルートに置き、各環境で共有する
• build（ビルド）: ソースからコンテナイメージを作る工程。Docker、Jib（Java 向け）、Cloud Native Buildpacks、自前スクリプトなど複数のビルダーを選べる
• tagging（タグ付け）: 生成イメージへ付与する識別子の方針。Git コミット、内容のダイジェスト、日時などのタグポリシーを指定できる
• deploy（デプロイ）: ビルドしたイメージをクラスタへ適用する工程。kubectl、Helm、Kustomize などのデプロイヤを利用する
• render（レンダリング）: マニフェストへ実イメージ参照を埋め込み、適用直前の具体的な定義を生成する処理。適用と分離して扱える
• dev モード: ファイル変更を監視し、変わるたびにビルド・デプロイを自動で回し続ける開発向けの実行モード
• プロファイル（profile）: 同一の skaffold.yaml 内で、環境ごと（dev／本番など）に設定の一部を上書きする仕組み
• artifact（アーティファクト）: ビルド対象の単位。1 つのリポジトリで複数のアーティファクトを並行してビルドできる

仕様・制限・クォータ

• OSS の CLI ツール: Skaffold は Google が主導するオープンソースのコマンドラインツールで、それ自体は課金対象のマネージドサービスではない。ローカルや CI 上で実行する
• ビルダーの多様性: Docker、Jib、Cloud Native Buildpacks、bazel、カスタムビルドに対応する。対応範囲の最新は公式ドキュメントで確認する
• デプロイヤの多様性: kubectl（素のマニフェスト）、Helm、Kustomize などに対応し、レンダリングと適用を組み合わせられる
• 対象は Kubernetes 中心: クラスタ（ローカルの minikube / kind から GKE まで）へのデプロイを主眼にする
• 状態を持たない: Skaffold は実行のたびに skaffold.yaml を解釈して動くツールであり、サーバー側に常駐するコンポーネントを持たない
• GCP との関係: Cloud Deploy がマニフェストのレンダリングと適用に Skaffold を内部利用する。Cloud Build や Cloud Code からも呼び出せる

内部の仕組み

Skaffold は skaffold.yaml を読み取り、ビルド → タグ付け → テスト → デプロイという工程を順に実行するオーケストレーターです。dev モードではこの一連をファイル監視と結びつけ、変更のたびに必要な部分だけを回します。

• 各アーティファクトを指定のビルダーでビルドし、タグポリシーに沿ってタグ付けしたうえでレジストリへプッシュする
• マニフェストに対し、ビルドで確定したイメージ参照を埋め込んでレンダリングし、適用する定義を具体化する
• レンダリング結果をデプロイヤ（kubectl／Helm／Kustomize）経由でクラスタへ適用する
• dev モードではファイル変更を監視し、変わったアーティファクトのみを再ビルド・再デプロイして反復を短縮する
• デプロイ後は対象 Pod のログ追従やポートフォワードをまとめて提供し、動作確認をしやすくする
• skaffold render と skaffold apply を分けることで、レンダリングと適用を別工程として CD パイプラインへ組み込める

設計パターン / ベストプラクティス

• skaffold.yaml を Git で管理し、ビルド・デプロイ手順をコードレビューと履歴管理の対象にする
• プロファイルで環境差を吸収し、dev と本番で別ファイルを作らず 1 つの定義を上書きで使い回す
• タグポリシーを内容ベース（ダイジェスト）に寄せ、同じ成果物には同じタグが付くようにして再現性を確保する
• 開発は dev モードで反復し、CI では skaffold build、CD では render／apply と用途ごとにサブコマンドを使い分ける
• Java など言語特性に合う場合は Jib や Buildpacks を使い、Dockerfile の保守を減らす
• Cloud Deploy と組み合わせる前提で skaffold.yaml を書き、ローカルの開発ループと本番デリバリで同じ定義を共有する
• ビルド前にユニットテストやコンテナ構造テストを差し込み、壊れた成果物がデプロイへ進まないようにする

運用・監視

• dev モードのコンソール出力でビルド・デプロイの進行と Pod ログをまとめて追い、変更の反映を即時に確認する
• 失敗時はどの工程（ビルド／レンダリング／適用）で止まったかを出力から切り分け、原因を特定する
• CI/CD では Skaffold の終了コードとログをパイプラインの判定材料にし、失敗を後続へ流さない
• Cloud Deploy 経由で動かす場合は、レンダリング・適用のログが Cloud Build／Cloud Logging 側に出るため、そちらで追跡する
• デプロイ先アプリの稼働状況（エラー率・レイテンシ）は Cloud Monitoring/Logging など別系統で観測し、ツールの責務と分けて捉える

コスト

Skaffold 自体は OSS の CLI ツールであり、ツールの利用に対する課金は発生しません。一方で、実行に伴って動く周辺リソースには費用がかかり得ます。具体的にはイメージのビルド実行（CI 環境や Cloud Build）、レジストリ（Artifact Registry）の保管・転送、デプロイ先クラスタ（GKE など）の稼働費用です。Skaffold は「どこで・何回ビルドしデプロイするか」を通じて、これら周辺コストに間接的に影響します。

具体的な料金体系は周辺サービス側で変動し得るため、断定的な金額ではなく上記の構造で捉え、最新は各サービスの公式料金ページで確認してください。

セキュリティ

• ビルドとデプロイの認証情報は実行環境に依存する。ローカルや CI のサービスアカウント権限が、そのまま作用範囲の上限になるため最小権限にする
• レジストリへのプッシュ権限とクラスタへの適用権限を役割ごとに分離し、開発用と本番用の資格情報を混在させない
• 機密値はマニフェストへ直書きせず、Secret Manager や Kubernetes Secret を参照する形にして平文の散在を避ける
• Cloud Deploy 経由で本番へ届ける構成にすれば、承認ゲートや Binary Authorization と組み合わせ、検査済みイメージのみを適用できる
• skaffold.yaml とマニフェストの格納先（Git／Artifact Registry）へのアクセスを保護し、ビルド定義の改ざんを防ぐ

関連サービス・比較

Skaffold は単体では「内側の開発ループを回す CLI」に徹し、本番へ段階的に届ける統制は Cloud Deploy が担います。Cloud Deploy は Skaffold を内部で利用しつつ、承認・プロモーション・ロールバックといったマネージドな CD 機能を上に重ねます。開発者が手元で回すのが Skaffold、組織として本番へ統制して届けるのが Cloud Deploy、という役割分担で捉えると整理しやすくなります。

ハンズオン / CLI例

# Skaffold は OSS の CLI。インストール後、プロジェクト直下の skaffold.yaml を使う
skaffold version

# 既存のプロジェクトから skaffold.yaml の雛形を生成する
skaffold init

# dev モード: ファイル変更を監視し、ビルド・デプロイを自動で回し続ける
skaffold dev

# 一度だけビルドして、生成イメージのタグ情報を JSON へ書き出す（CI 向け）
skaffold build --file-output build.json

# マニフェストへ実イメージ参照を埋め込んでレンダリングする（適用とは分離）
skaffold render --build-artifacts build.json --output rendered.yaml

# レンダリング済みの定義をクラスタへ適用する
skaffold apply rendered.yaml

# Cloud Deploy から呼び出す場合は、同じ skaffold.yaml をリリース作成時に指定する
gcloud deploy releases create rel-001 \
  --delivery-pipeline my-app-pipeline \
  --region asia-northeast1 \
  --skaffold-file skaffold.yaml