【ITニュース解説】Ship small, ship often: Practical Kubernetes CI/CD on a budget (GitHub Actions + Helm)

この記事は、Kubernetesへのデプロイを自動化するための実践的なCI/CD（継続的インテグレーション/継続的デリバリー）パイプラインの構築方法を、特にフリーランサーや小規模チーム向けに解説している。

まず、GitHub ActionsとGitHub Container Registry (GHCR) を利用するメリットとして、コード、CI、コンテナレジストリ、権限管理がGitHub内で完結し、インフラストラクチャの複雑さを軽減できる点を挙げている。また、Helmを使用することで、Kubernetesの設定をテンプレート化し、環境ごとに異なる値を簡単に適用できる。KubernetesのDeploymentリソースを活用することで、ローリングアップデートを容易に実現し、アプリケーションのダウンタイムを最小限に抑えることができる。

次に、具体的なアーキテクチャとして、GitHub ActionsでDockerイメージをビルドし、コミットSHAをタグとして付与してGHCRにプッシュする。その後、Helmを用いてKubernetesにデプロイする。重要な点として、パイプラインはDeploymentが正常に起動し、アプリケーションが正常な状態になるまで待機する。これにより、パイプラインの成功がアプリケーションの正常な状態を保証する。

初期設定として、kubectlとHelmを適切なバージョンでインストールする必要がある。kubectlのバージョンはKubernetesクラスタのバージョンとの互換性を保つ必要がある。GHCRを有効にし、DockerfileにOCIラベルを追加することで、GHCRがイメージとリポジトリを自動的に関連付ける。

サンプルアプリケーションとして、Node.jsで記述された簡単なWebアプリケーションを使用する。このアプリケーションは、/livezと/healthzという2つのエンドポイントを提供する。/livezはliveness probeとして、/healthzはreadiness probeとして使用される。liveness probeはコンテナが正常に動作しているかを確認し、readiness probeはコンテナがトラフィックを受け入れる準備ができているかを確認する。

Dockerfileは、マルチステージビルドを採用している。これにより、ビルドに必要なツールを最終的なイメージに含めずに、イメージサイズを削減できる。

Helm chartは、Kubernetesリソースの設定を記述したテンプレートの集まりである。values.yamlにはデフォルト値が定義されており、CIパイプラインでこれらの値を上書きすることができる。deployment.yamlにはDeploymentリソースの設定が記述されており、readiness probeとliveness probeの設定が含まれている。

CIパイプラインは、GitHub Actionsで定義される。このパイプラインは、Dockerイメージをビルドし、タグを付与してGHCRにプッシュする。Dockerの公式Actionsを使用して、ビルドとプッシュを効率的に行う。

CD（継続的デリバリー）パイプラインは、CIパイプラインの成功後に実行される。このパイプラインは、Helmを用いてKubernetesにアプリケーションをデプロイする。helm upgrade --installコマンドは、アプリケーションの初回デプロイと更新の両方を処理する。--wait、--timeout、--atomicフラグを使用することで、デプロイの安全性を高める。

アプリケーションの正常性を確認するために、readiness probeとliveness probeを設定する。readiness probeは、アプリケーションがトラフィックを受け入れる準備ができるまで、サービスのエンドポイントをゲートする。liveness probeは、アプリケーションがフリーズした場合にコンテナを再起動する。

よくある間違いとして、:latestタグの使用、ローリングアップデートの完了を待たないこと、CIに過剰な権限を与えることが挙げられる。これらの問題を解決するために、コミットSHAまたはダイジェストでイメージにタグ付けし、--waitフラグを使用してローリングアップデートの完了を待ち、RBAC（Role-Based Access Control）を使用してCIの権限を制限する。

RBACを設定することで、CIがアクセスできるリソースと操作を制限できる。これにより、トークンが漏洩した場合のセキュリティリスクを軽減できる。

プライベートレジストリを使用する場合は、imagePullSecretsを設定する必要がある。これにより、Kubernetesはプライベートレジストリからイメージをプルするための認証情報を使用できる。

ロールバックを行うには、Helmのリリース履歴を使用するか、KubernetesのDeployment履歴を使用する。helm historyコマンドは、Helmのリリース履歴を表示し、helm rollbackコマンドは、以前のリリースにロールバックする。kubectl rollout statusコマンドは、Deploymentのステータスを表示する。

リポジトリのレイアウトを整理し、シークレットを適切に管理することで、CI/CDパイプラインの保守性を高めることができる。

Kustomizeを使用することもできるが、Helmの方がパッケージ化やクライアントが既にチャートを使用している場合に便利である。

記事の最後には、テスト、同時実行、スモークチェックなどの追加のCIステップについて簡単に触れられている。