GitLab Kubernetes Agent で実現する、モダンなKubernetesクラスタ管理

Posted at 2025-11-23

GitLab Kubernetes Agent で実現する、モダンなKubernetesクラスタ管理

GitLabとKubernetesの統合が、大きく進化しています。Infrastructure as Code（IaC）によるクラスタ作成から、GitOpsによる継続的デプロイメント、CI/CDパイプラインとの連携まで、GitLab Kubernetes Agentを中心とした包括的なエコシステムが整いました。本記事では、この統合の全体像と実践的な活用方法を解説します。

1. GitLab Kubernetes Agentとは

1.1. 概要とアーキテクチャ

GitLab Kubernetes Agentは、GitLabとKubernetesクラスタを安全に接続するためのコンポーネントです。クラスタ内で動作するagentkと、GitLab側で動作するkas（GitLab agent server for Kubernetes）の2つの要素で構成されています。

1.2. 従来方式との違い

従来の証明書ベースの接続方式と比較して、Agentは以下の利点を提供します。

項目	証明書ベース（旧方式）	Agent（新方式）
ファイアウォール越え	困難	可能（Agentから接続）
セキュリティモデル	証明書管理が必要	トークンベース、自動更新
マルチテナンシー	限定的	強力なサポート
リアルタイム性	低い	高い（双方向通信）
接続の安定性	不安定になりやすい	自動再接続

1.3. 主要な特徴

ファイアウォール/NAT対応: クラスタからGitLabへの接続を確立するため、インバウンド通信が不要
リアルタイムアクセス: クラスタのAPIエンドポイントに低レイテンシでアクセス
イベント駆動: クラスタ内のイベント情報をGitLabにプッシュ
効率的なキャッシング: Kubernetesオブジェクトのキャッシュを保持し、APIサーバーへの負荷を軽減
マルチテナンシー: 1つのAgentを複数のプロジェクト、グループで共有可能

1.4. 技術的詳細

接続仕様

各Agentは最大500の論理gRPCストリーム（アクティブ+アイドル）を維持
TCP接続数はgRPCが自動管理
接続の最大有効期間: 2時間（猶予期間1時間）
GitLab.comでは、プロキシ経由で2時間の接続制限

推奨構成

1クラスタにつき1 Agent（運用とメンテナンスの簡素化）
Agentは必ずGitLabプロジェクトに登録
登録後、他のプロジェクト/グループと接続を共有可能

2. サポート環境

2.1. Kubernetesバージョン

GitLabは以下のKubernetesバージョンをサポートしています。

バージョン	サポート終了時期
1.33	GitLab 19.2リリース時または 1.36サポート開始時
1.32	GitLab 18.10リリース時または 1.35サポート開始時
1.31	GitLab 18.7リリース時または 1.34サポート開始時

サポートポリシー

新しいKubernetesマイナーバージョンのリリースから約3ヶ月後にサポート開始
常に最低3つのプロダクション対応バージョンをサポート
Helmバージョンは、使用するKubernetesバージョンと互換性のあるものを選択

2.2. GitLabエディション

機能	Free	Premium	Ultimate
基本的なAgent機能	✓	✓	✓
GitOpsワークフロー	✓	✓	✓
CI/CDワークフロー	✓	✓	✓
ユーザーなりすまし	-	✓	✓
Receptive Agents	-	-	✓（Self-Managed）

3. デプロイメントワークフロー比較

3.1. 2つのアプローチ

GitLab Kubernetes Agentは、用途に応じて2つのデプロイメントワークフローを提供します。

3.2. 詳細比較

項目	GitOps（Flux）	CI/CD（kubectl）
デプロイ方式	Pull型（クラスタが取得）	Push型（GitLabが送信）
推奨度	★★★★★ 推奨	★★☆☆☆ 限定的
セキュリティ	高（最小権限の原則）	中（広範な権限が必要）
監査性	高（Git履歴が完全な記録）	中（パイプライン履歴に依存）
ドリフト検出	自動	なし
ドリフト修正	自動	手動
学習曲線	やや急	緩やか
本番環境	✓ 推奨	✗ 非推奨
開発/検証環境	✓ 可能	✓ 可能
マルチクラスタ	✓ 容易	△ 複雑

3.3. 使い分けの指針

GitOpsを選ぶべき場合

本番環境のデプロイメント
複数クラスタの管理
厳格な監査要件がある
インフラストラクチャをコードで完全管理したい
ドリフト検出・自動修正が必要

CI/CDを選ぶべき場合

開発環境での迅速な検証
既存のCI/CDパイプラインからの段階的移行
パイプライン駆動の一時的なタスク
GitOpsがサポートしていない特殊なユースケース

注意: CI/CDワークフローはセキュリティモデルが弱いため、本番環境での使用は推奨されません。

4. GitOpsワークフロー詳解

4.1. なぜGitOpsなのか

GitOpsは、Gitリポジトリを唯一の信頼できる情報源（Single Source of Truth）として、宣言的にインフラストラクチャを管理する手法です。

技術的な利点

宣言的管理: あるべき状態を定義し、実際の状態との差分を自動調整
イミュータブル: Git履歴により、すべての変更が追跡可能
自己修復: 手動変更を検出し、自動的にGitの状態に戻す
ロールバック: Gitの履歴を使って任意の時点に戻せる
セキュリティ: クラスタへのプッシュ権限が不要（Pull型）

4.2. Fluxとの統合

GitLabは、GitOpsツールとしてFlux（CNCF卒業プロジェクト）を推奨しています。

Fluxの役割

Gitリポジトリの変更を監視
OCIレジストリからイメージを取得
Helmチャートの管理
Kustomizeによるカスタマイズ
自動的なクラスタへの適用

AgentとFluxの協調動作

4.3. OCIレジストリの活用

Fluxのソースとして、GitリポジトリではなくOCIイメージを使用することが推奨されます。

OCIレジストリの優位性

観点	OCIレジストリ	Gitリポジトリ
設計目的	コンテナイメージの大規模配信	ソースコードのバージョン管理
イミュータビリティ	✓ 完全	△ タグは変更可能
セキュリティスキャン	✓ ネイティブサポート	-
配信パフォーマンス	✓ 高速（CDN対応）	△ 通常
ストレージ効率	✓ レイヤーキャッシング	△ 全体を保存
同期トリガー	デフォルトブランチでも制御可能	デフォルトブランチで自動トリガー

GitLabコンテナレジストリの活用

GitLabの組み込みコンテナレジストリは、OCIイメージを完全サポートしています。

# Flux OCIRepository の例
apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: OCIRepository
metadata:
  name: my-app
  namespace: flux-system
spec:
  interval: 5m
  url: oci://registry.gitlab.com/my-group/my-project/manifests
  ref:
    tag: latest

4.4. 即時Git調整の仕組み

通常、Fluxは設定された間隔（例: 5分）でGitリポジトリをポーリングします。GitLab Agentは、この遅延を最小化する機能を提供します。

動作原理

AgentがFluxのGitRepositoryオブジェクトを検出
該当プロジェクトへのReceiver Webhookを自動設定
git pushを検出すると、即座にFluxに通知
Fluxが即時調整を実行

制限事項

Agentは、Agent設定プロジェクトとパブリックプロジェクトのみアクセス可能
プライベートプロジェクトは即時調整の対象外（Agent設定プロジェクトを除く）
すべてのgit pushの受信は保証されないため、interval設定は必須

カスタムWebhookエンドポイント

デフォルトのWebhook URL（http://webhook-receiver.flux-system.svc.cluster.local）を変更できます。

# .gitlab/agents/my-agent/config.yaml
flux:
  webhook_receiver_url: http://webhook-receiver.custom-namespace.svc.cluster.local

サービスプロキシURL形式もサポートされています。

flux:
  webhook_receiver_url: /api/v1/namespaces/flux-system/services/http:webhook-receiver:80/proxy

注意: サービスプロキシURLを使用する場合、Agentは認証情報を含むKubernetes APIリクエストを送信します。信頼できるURLのみを設定してください。

4.5. リポジトリ構造のベストプラクティス

推奨構成

チームごとに1つのデリバリーリポジトリ
アプリケーションごとに複数のOCIイメージにパッケージ化
環境ごとにディレクトリを分離

my-delivery-repo/
├── base/                    # 共通マニフェスト
│   ├── app1/
│   └── app2/
├── environments/
│   ├── development/         # 開発環境
│   │   ├── kustomization.yaml
│   │   └── patches/
│   ├── staging/             # ステージング環境
│   │   ├── kustomization.yaml
│   │   └── patches/
│   └── production/          # 本番環境
│       ├── kustomization.yaml
│       └── patches/
└── flux-config/             # Flux設定
    ├── sources/
    └── kustomizations/

4.6. トークン管理戦略

Fluxの運用には、複数のアクセストークンが必要になる場合があります。

FluxによるGitLabアクセス

トークンタイプ	用途	推奨度	必要スコープ
プロジェクトデプロイトークン	HTTP経由のリポジトリアクセス	★★★★★	`read_repository`
デプロイキー	SSH経由のリポジトリアクセス	★★★★☆	-
プロジェクトアクセストークン	API経由のアクセス	★★★☆☆	`read_repository`
パーソナルアクセストークン	個人アカウント経由	★☆☆☆☆	`read_repository`

推奨: HTTP アクセスが可能な場合は、プロジェクトデプロイトークンを使用してください。

FluxからGitLabへの通知

Fluxは、GitLabパイプラインに外部ジョブステータスを登録できます。

必要スコープ: api
推奨: プロジェクトアクセストークン（漏洩時の影響範囲を最小化）

5. CI/CDワークフロー詳解

5.1. 基本構成

CI/CDワークフローでは、GitLab CI/CDパイプラインからkubectlコマンドを使用してクラスタを操作します。

前提条件

GitLab CI/CDが有効
クラスタにAgentがインストール済み
GitLabにRunnerが登録済み（クラスタ内である必要はない）

5.2. `.gitlab-ci.yml`の実装例

基本パターン

deploy:
  image: debian:13-slim
  variables:
    KUBECTL_VERSION: v1.34
    DEBIAN_FRONTEND: noninteractive
  script:
    # kubectl のインストール
    - apt-get update
    - apt-get install -y --no-install-recommends apt-transport-https ca-certificates curl gnupg
    - curl --fail --silent --show-error --location "https://pkgs.k8s.io/core:/stable:/${KUBECTL_VERSION}/deb/Release.key" | gpg --dearmor --output /etc/apt/keyrings/kubernetes-apt-keyring.gpg
    - chmod 644 /etc/apt/keyrings/kubernetes-apt-keyring.gpg
    - echo "deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/${KUBECTL_VERSION}/deb/ /" | tee /etc/apt/sources.list.d/kubernetes.list
    - chmod 644 /etc/apt/sources.list.d/kubernetes.list
    - apt-get update
    - apt-get install -y --no-install-recommends kubectl
    
    # コンテキストの確認と選択
    - kubectl config get-contexts
    - kubectl config use-context path/to/agent/project:agent-name
    
    # デプロイメント実行
    - kubectl apply -f manifests/
    - kubectl rollout status deployment/my-app

最適化パターン（kubectlプリインストール済みイメージ）

deploy:
  image: bitnami/kubectl:latest
  script:
    - kubectl config use-context path/to/agent/project:agent-name
    - kubectl apply -f manifests/
    - kubectl rollout status deployment/my-app

5.3. Auto DevOps環境での設定

Auto DevOpsを使用する場合、KUBE_CONTEXT変数を定義します。

単一環境

variables:
  KUBE_CONTEXT: path/to/agent/project:agent-name

複数環境（環境スコープ変数）

変数名	値	環境スコープ
`KUBE_CONTEXT`	`path/to/agent/project:staging-agent`	`staging`
`KUBE_CONTEXT`	`path/to/agent/project:production-agent`	`production`

5.4. 証明書ベース接続との共存

証明書ベースクラスタとAgent接続が両方存在する場合の対処法です。

deploy:
  variables:
    KUBE_CONTEXT: my-context
    AGENT_ID: 1234
    K8S_PROXY_URL: https://kas.gitlab.com/k8s-proxy/  # GitLab.com の場合
    # K8S_PROXY_URL: https://gitlab.example.com/-/kubernetes-agent/k8s-proxy/  # Self-Managed の場合
  before_script:
    - kubectl config set-credentials agent:$AGENT_ID --token="ci:${AGENT_ID}:${CI_JOB_TOKEN}"
    - kubectl config set-cluster gitlab --server="${K8S_PROXY_URL}"
    - kubectl config set-context "$KUBE_CONTEXT" --cluster=gitlab --user="agent:${AGENT_ID}"
    - kubectl config use-context "$KUBE_CONTEXT"
  script:
    - kubectl apply -f manifests/

5.5. 自己署名証明書環境での設定

KASが自己署名証明書を使用している場合、証明書の信頼設定が必要です。

方法1: CI/CD変数で証明書を設定

variables:
  SSL_CERT_FILE: $KAS_CERTIFICATE  # PEM形式の証明書

方法2: kubectlコマンドで指定

script:
  - kubectl --certificate-authority=$KAS_CERTIFICATE get pods

方法3: コンテナイメージに証明書を配置

Dockerfile内で証明書を適切な場所に配置します。

非推奨: TLS検証のスキップ

script:
  - kubectl --insecure-skip-tls-verify=true get pods

セキュリティリスクがあるため、本番環境では使用しないでください。

6. Infrastructure as Codeによるクラスタ作成

6.1. 対応クラウドプロバイダー概要

GitLabは、主要クラウドプロバイダーでのクラスタ作成をTerraformで自動化するサンプルプロジェクトを提供しています。

プロバイダー	サンプルプロジェクト	特典
Google GKE	`gitlab-org/configure/examples/gitlab-terraform-gke`	新規アカウント$300 + GitLab経由$200
Amazon EKS	`gitlab-org/configure/examples/gitlab-terraform-eks`	-
Azure AKS	`gitlab-org/ci-cd/deploy-stage/environments-group/examples/gitlab-terraform-aks`	-
Civo	`civocloud/gitlab-terraform-civo`	新規アカウント$250

6.2. 共通の作成フロー

どのクラウドプロバイダーでも、以下の4ステップで完了します。

6.3. クラウドプロバイダー別詳細

6.3.1. Google Kubernetes Engine（GKE）

必要な準備

GCPサービスアカウント（以下のロールが必要）
- Compute Network Viewer
- Kubernetes Engine Admin
- Service Account User
- Service Account Admin
GitLab Runner

必須CI/CD変数

変数名	説明	取得方法
`BASE64_GOOGLE_CREDENTIALS`	サービスアカウントキー（Base64エンコード）	`base64 -i /path/to/sa-key.json \| tr -d \\n`
`TF_VAR_gcp_project`	GCPプロジェクトID	GCPコンソールで確認
`TF_VAR_agent_token`	Agentトークン	GitLabで生成
`TF_VAR_kas_address`	KASアドレス	GitLabで生成

オプション変数

TF_VAR_gcp_region: リージョン（デフォルト: us-central1）
TF_VAR_cluster_name: クラスタ名
TF_VAR_cluster_description: 説明（$CI_PROJECT_URL推奨）
TF_VAR_machine_type: ノードのマシンタイプ
TF_VAR_node_count: ノード数
TF_VAR_agent_namespace: Agent用名前空間

追加手順

GCP コンソールで Kubernetes Engine API を有効化してください。

6.3.2. Amazon Elastic Kubernetes Service（EKS）

必要な準備

AWSアカウント
IAMユーザーまたはロール（必要な権限は広範囲のため、サンプルプロジェクトのドキュメント参照）
GitLab Runner

必須CI/CD変数

変数名	説明
`AWS_ACCESS_KEY_ID`	AWSアクセスキーID
`AWS_SECRET_ACCESS_KEY`	AWSシークレットアクセスキー
`TF_VAR_agent_token`	Agentトークン
`TF_VAR_kas_address`	KASアドレス

オプション変数

TF_VAR_region: リージョン
TF_VAR_cluster_name: クラスタ名
TF_VAR_cluster_version: Kubernetesバージョン
TF_VAR_instance_type: ノードのインスタンスタイプ
TF_VAR_instance_count: ノード数
TF_VAR_agent_namespace: Agent用名前空間

作成されるリソース

VPC（Virtual Private Cloud）
EKSクラスタ
GitLab Kubernetes Agent

6.3.3. Azure Kubernetes Service（AKS）

必要な準備

Microsoft Azureアカウント
サービスプリンシパル
GitLab Runner

必須CI/CD変数

変数名	説明
`ARM_CLIENT_ID`	Azureクライアント ID
`ARM_CLIENT_SECRET`	Azureクライアントシークレット
`ARM_TENANT_ID`	サービスプリンシパル
`TF_VAR_agent_token`	Agentトークン
`TF_VAR_kas_address`	KASアドレス

オプション変数

TF_VAR_location: リージョン
TF_VAR_cluster_name: クラスタ名
TF_VAR_kubernetes_version: Kubernetesバージョン
TF_VAR_create_resource_group: リソースグループ作成フラグ（デフォルト: true）
TF_VAR_resource_group_name: リソースグループ名
TF_VAR_agent_namespace: Agent用名前空間

6.3.4. Civo Kubernetes

必要な準備

Civoアカウント（新規アカウントに$250クレジット）
GitLab Runner

必須CI/CD変数

変数名	説明
`CIVO_TOKEN`	Civoアカウントトークン
`TF_VAR_agent_token`	Agentトークン
`TF_VAR_kas_address`	KASアドレス

オプション変数

TF_VAR_civo_region: リージョン（デフォルト: lon1）
TF_VAR_cluster_name: クラスタ名
TF_VAR_cluster_description: 説明
TF_VAR_target_nodes_size: ノードサイズ
TF_VAR_num_target_nodes: ノード数
TF_VAR_agent_version: Agentバージョン
TF_VAR_agent_namespace: Agent用名前空間

特徴

クリーンアップジョブがデフォルトで含まれる
サポートはCivo社が提供

6.4. クラスタの削除

GKE、EKS、AKS の場合

.gitlab-ci.ymlに以下を追加します。

stages:
  - init
  - validate
  - build
  - test
  - deploy
  - cleanup

destroy:
  extends: .terraform:destroy
  needs: []

パイプラインでdestroyジョブを手動実行します。

Civoの場合

デフォルトでdestroy-environmentジョブが含まれているため、パイプラインで手動実行するだけです。

7. Agentアクセスの認可

7.1. 認可の概念

Agentは、登録されたプロジェクト以外からもアクセス可能です。セキュリティを保ちながら、複数のプロジェクト/グループでAgentを共有するための認可設定を行います。

認可の伝播時間: 設定変更後、1〜2分で反映されます。

7.2. プロジェクト単位の認可

設定例

# .gitlab/agents/my-agent/config.yaml
ci_access:
  projects:
    - id: group1/project1
    - id: group1/project2
    - id: group2/project3

制限事項

最大500プロジェクトまで認可可能
認可されたプロジェクトは、Agentの設定プロジェクトと同じトップレベルグループまたはユーザー名前空間が必要（インスタンスレベル認可が無効の場合）

効果

認可されたプロジェクトのすべてのCI/CDジョブで、$KUBECONFIG環境変数が自動設定される
kubectl config get-contextsでAgentのコンテキストが表示される

7.3. グループ単位の認可

設定例

ci_access:
  groups:
    - id: group1
    - id: group1/subgroup1

特徴

最大500グループまで認可可能
サブグループは自動的に含まれる（個別指定不要）
認可されたグループは、Agentの設定プロジェクトと同じトップレベルグループが必要（インスタンスレベル認可が無効の場合）

ユースケース

大規模な組織で、部門ごとにグループを分けている場合に有効です。

ci_access:
  groups:
    - id: engineering        # engineering配下のすべてのプロジェクト
    - id: engineering/backend  # backend配下のすべてのプロジェクト
    - id: engineering/frontend # frontend配下のすべてのプロジェクト

7.4. インスタンス全体への認可（Self-Managed限定）

前提条件

GitLab Self-Managed または Dedicated
管理者権限

有効化手順

管理エリア > Settings > General
GitLab agent for Kubernetesセクションを展開
Enable instance level authorizationを選択
Save changes

Agent設定

ci_access:
  instance: {}

注意事項

インスタンス内のすべてのプロジェクトがAgentにアクセス可能になる
RBACとなりすましを組み合わせて、適切なアクセス制御を実装すること

8. アクセス制御の高度な設定

8.1. なりすまし（Impersonation）の概要

デフォルトでは、CI/CDジョブはAgentのサービスアカウントの権限をすべて継承します。これは過剰な権限付与につながる可能性があります。

なりすましの利点

最小権限の原則を実現
Kubernetes RBACとの統合
監査ログでの識別が容易
セキュリティインシデント時の影響範囲を限定

8.2. なりすまし対象の選択

8.3. CI/CDジョブのなりすまし（推奨）

設定例

ci_access:
  projects:
    - id: group1/project1
      access_as:
        ci_job: {}

なりすまし時の識別情報

Agentが Kubernetes API にリクエストする際、以下の情報が設定されます。

UserName

gitlab:ci_job:<job_id>

例: gitlab:ci_job:1074499489

Groups

以下のグループに自動的に所属します。

gitlab:ci_job                              # すべてのCI/CDジョブ
gitlab:group:<group_id>                    # プロジェクトが属するグループ
gitlab:group_env_tier:<group_id>:<tier>    # グループ+環境ティア
gitlab:project:<project_id>                # プロジェクト
gitlab:project_env:<project_id>:<env>      # プロジェクト+環境
gitlab:project_env_tier:<project_id>:<tier> # プロジェクト+環境ティア

具体例

プロジェクト構成:

グループ: engineering (ID: 100)
サブグループ: engineering/backend (ID: 200)
プロジェクト: engineering/backend/api (ID: 300)
環境: production (ティア: production)

この場合のGroups:

gitlab:ci_job
gitlab:group:100
gitlab:group_env_tier:100:production
gitlab:group:200
gitlab:group_env_tier:200:production
gitlab:project:300
gitlab:project_env:300:production
gitlab:project_env_tier:300:production

Extra属性

プロパティ	内容
`agent.gitlab.com/id`	Agent ID
`agent.gitlab.com/config_project_id`	Agent設定プロジェクトID
`agent.gitlab.com/project_id`	CI/CDプロジェクトID
`agent.gitlab.com/ci_pipeline_id`	パイプラインID
`agent.gitlab.com/ci_job_id`	ジョブID
`agent.gitlab.com/username`	実行ユーザー名
`agent.gitlab.com/environment_slug`	環境スラッグ（環境実行時のみ）
`agent.gitlab.com/environment_tier`	環境ティア（環境実行時のみ）

8.4. RBAC設定例

8.4.1. すべてのCI/CDジョブに読み取り専用権限

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: gitlab-ci-view
roleRef:
  name: view
  kind: ClusterRole
  apiGroup: rbac.authorization.k8s.io
subjects:
  - name: gitlab:ci_job
    kind: Group

8.4.2. 特定プロジェクトに名前空間への書き込み権限

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: project-300-deploy
  namespace: production
roleRef:
  name: edit
  kind: ClusterRole
  apiGroup: rbac.authorization.k8s.io
subjects:
  - name: gitlab:project:300
    kind: Group

8.4.3. 本番環境のみ特定グループに権限付与

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: backend-production-deploy
  namespace: production
roleRef:
  name: admin
  kind: ClusterRole
  apiGroup: rbac.authorization.k8s.io
subjects:
  - name: gitlab:group_env_tier:200:production
    kind: Group

8.4.4. 段階的な権限設定（開発→ステージング→本番）

---
# 開発環境: すべてのCI/CDジョブがアクセス可能
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-all-access
  namespace: development
roleRef:
  name: edit
  kind: ClusterRole
  apiGroup: rbac.authorization.k8s.io
subjects:
  - name: gitlab:ci_job
    kind: Group
---
# ステージング環境: 特定グループのみ
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: staging-backend-access
  namespace: staging
roleRef:
  name: edit
  kind: ClusterRole
  apiGroup: rbac.authorization.k8s.io
subjects:
  - name: gitlab:group:200
    kind: Group
---
# 本番環境: 本番環境ティアのジョブのみ
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: production-restricted
  namespace: production
roleRef:
  name: admin
  kind: ClusterRole
  apiGroup: rbac.authorization.k8s.io
subjects:
  - name: gitlab:group_env_tier:200:production
    kind: Group

8.5. 静的IDのなりすまし

特殊な要件がある場合、固定のユーザーまたはサービスアカウントでなりすますことができます。

設定例

ci_access:
  projects:
    - id: group1/project1
      access_as:
        impersonate:
          username: "system:serviceaccount:default:deployer"
          groups:
            - "system:authenticated"
          uid: "12345"

ユースケース

既存のRBAC設定を変更せずに統合したい場合
特定のサービスアカウントの権限を使用する必要がある場合

8.6. 環境による制限

特定の環境でのみAgentへのアクセスを許可できます。

設定例

ci_access:
  projects:
    - id: group1/project1
      # すべての環境でアクセス可能
    - id: group1/project2
      environments:
        - staging
        - review/*
  groups:
    - id: group2
      environments:
        - production

動作

project1: すべてのCI/CDジョブがアクセス可能
project2: staging環境またはreview/*環境のジョブのみアクセス可能
group2配下のプロジェクト: production環境のジョブのみアクセス可能

ワイルドカード

*を使用して、パターンマッチングが可能です。

environments:
  - review/*        # review/feature-a, review/feature-b など
  - staging-*       # staging-eu, staging-us など

8.7. 保護されたブランチによる制限（Self-Managed/Dedicated）

保護されたブランチからのジョブのみにアクセスを制限できます。

設定例

ci_access:
  projects:
    - id: group1/project1
      protected_branches_only: true
  groups:
    - id: group2
      protected_branches_only: true
      environments:
        - production

デフォルト値: false（保護されていないブランチからもアクセス可能）

セキュリティ強化

環境制限と組み合わせることで、より強固なアクセス制御が実現できます。

ci_access:
  projects:
    - id: group1/critical-app
      protected_branches_only: true
      environments:
        - production
      access_as:
        ci_job: {}

この設定により、以下の条件をすべて満たすジョブのみがアクセス可能になります。

保護されたブランチから実行
production環境で実行
CI/CDジョブとしてなりすまし（RBAC制御可能）

優先順位

複数の設定がある場合、最も具体的な設定が適用されます。

ci_access:
  projects:
    - id: group1/project1
      protected_branches_only: false  # この設定が優先される
      environments:
        - dev
  groups:
    - id: group1
      protected_branches_only: true
      environments:
        - dev

9. クイックスタートガイド

9.1. 前提条件の確認

以下が揃っていることを確認してください。

kubectlでアクセス可能なKubernetesクラスタ
サポートされているKubernetesバージョン（1.31以上）
GitLabアカウント（Free以上）
GitLab Runner（クラスタ内または外部）

クラスタ接続の確認

kubectl cluster-info
kubectl version --short

9.2. Flux CLIのインストール

macOS（Homebrew）

brew install fluxcd/tap/flux

Linux

curl -s https://fluxcd.io/install.sh | sudo bash

確認

flux --version

9.3. GitLab CLIのインストール

macOS（Homebrew）

brew install glab

Linux

# バイナリをダウンロード
curl -L https://gitlab.com/gitlab-org/cli/-/releases/permalink/latest/downloads/glab_Linux_x86_64.tar.gz | tar xz
sudo mv bin/glab /usr/local/bin/

確認

glab version

認証

glab auth login

9.4. パーソナルアクセストークンの作成

GitLabでアバターをクリック
Edit profile > Personal access tokens
トークン名を入力（例: flux-bootstrap）
スコープ: apiを選択
Create personal access tokenをクリック
トークンをコピーして安全に保管

9.5. Fluxのブートストラップ

環境変数の設定

export GITLAB_TOKEN=<your-personal-access-token>
export GITLAB_HOSTNAME=gitlab.com  # Self-Managedの場合は自分のホスト名
export GITLAB_OWNER=my-group       # グループまたはユーザー名
export GITLAB_REPO=my-flux-repo    # リポジトリ名（自動作成される）

ブートストラップ実行

flux bootstrap gitlab \
  --hostname=${GITLAB_HOSTNAME} \
  --owner=${GITLAB_OWNER} \
  --repository=${GITLAB_REPO} \
  --branch=main \
  --path=clusters/my-cluster \
  --deploy-token-auth \
  --personal

実行内容

GitLabに新しいプロジェクト${GITLAB_OWNER}/${GITLAB_REPO}を作成（存在しない場合）
デプロイトークンを生成し、Kubernetes Secretとして保存
Flux定義ファイルをclusters/my-clusterに生成
mainブランチにコミット
クラスタにFluxをインストール

確認

flux check
kubectl get pods -n flux-system

9.6. GitLab Agentのブートストラップ

Fluxリポジトリに移動

cd /path/to/${GITLAB_REPO}

Agentのブートストラップ

glab cluster agent bootstrap \
  --manifest-path clusters/my-cluster \
  my-agent

実行内容

GitLabでAgent my-agentを登録
Agent設定ファイル.gitlab/agents/my-agent/config.yamlを作成
Agentトークンを生成
Kubernetes SecretにAgentトークンを保存
Flux HelmReleaseを生成してコミット
Flux調整をトリガー

確認

kubectl get pods -n gitlab-agent-my-agent
glab cluster agent list

9.7. ダッシュボードの確認

GitLabプロジェクトを開く
サイドバー: Operate > Environments
環境flux-system/gitlab-agentを選択
Kubernetes overviewタブをクリック

リアルタイムでクラスタの状態が表示されます。

9.8. ユーザーなりすましの設定（Premium/Ultimate）

Agent設定の変更

.gitlab/agents/my-agent/config.yamlを編集します。

# 変更前
user_access:
  access_as:
    agent: {}

# 変更後
user_access:
  access_as:
    user: {}

RBAC設定の追加

clusters/my-cluster/gitlab-user-rbac.yamlを作成します。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: gitlab-user-view
roleRef:
  name: view
  kind: ClusterRole
  apiGroup: rbac.authorization.k8s.io
subjects:
  - name: gitlab:user
    kind: Group

コミットとプッシュ

git add .
git commit -m "Enable user impersonation"
git push

数秒後、Fluxが変更を適用し、ダッシュボードが正常に表示されます。

9.9. 最初のアプリケーションのデプロイ

マニフェストの作成

clusters/my-cluster/apps/nginx.yamlを作成します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
  namespace: default
spec:
  selector:
    app: nginx
  ports:
  - port: 80
    targetPort: 80
  type: ClusterIP

コミットとプッシュ

git add clusters/my-cluster/apps/nginx.yaml
git commit -m "Add nginx deployment"
git push

確認

# Fluxの調整を待つ（最大5分）
flux reconcile source git flux-system

# デプロイメントの確認
kubectl get deployments
kubectl get pods
kubectl get services

10. ユースケース別推奨構成

10.1. 小規模チーム（1〜5人）

構成

単一クラスタ
GitOpsワークフロー
環境ごとに名前空間を分離

Agent設定

# .gitlab/agents/team-agent/config.yaml
ci_access:
  groups:
    - id: my-team

user_access:
  access_as:
    user: {}
  projects:
    - id: my-team/infrastructure

リポジトリ構造

my-team/infrastructure/
├── .gitlab/
│   └── agents/
│       └── team-agent/
│           └── config.yaml
└── clusters/
    └── production/
        ├── apps/
        │   ├── app1/
        │   └── app2/
        └── infrastructure/
            ├── ingress/
            └── monitoring/

10.2. 中規模組織（複数チーム）

構成

環境ごとにクラスタを分離（dev、staging、production）
チームごとにAgent認可
環境ティアによるアクセス制御

Agent設定（本番クラスタ）

# .gitlab/agents/production-agent/config.yaml
ci_access:
  groups:
    - id: engineering
      environments:
        - production
      access_as:
        ci_job: {}
      protected_branches_only: true

user_access:
  access_as:
    user: {}
  groups:
    - id: engineering/sre

RBAC設定

# 本番環境: SREチームのみフルアクセス
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: sre-admin
roleRef:
  name: cluster-admin
  kind: ClusterRole
  apiGroup: rbac.authorization.k8s.io
subjects:
  - name: gitlab:group:123  # SREグループID
    kind: Group
---
# 開発チーム: 読み取り専用
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: developers-view
roleRef:
  name: view
  kind: ClusterRole
  apiGroup: rbac.authorization.k8s.io
subjects:
  - name: gitlab:group:456  # 開発グループID
    kind: Group

10.3. エンタープライズ（マルチクラスタ、マルチリージョン）

構成

リージョンごとにクラスタ
環境ごとにクラスタ
Agentは環境+リージョンで分離
インスタンスレベル認可 + RBAC

Agent設定（本番・US East）

# .gitlab/agents/prod-us-east-agent/config.yaml
ci_access:
  instance: {}

flux:
  webhook_receiver_url: http://webhook-receiver.flux-system.svc.cluster.local

RBAC設定（階層的権限）

---
# レベル1: プラットフォームチーム（すべてのクラスタ）
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: platform-admin
roleRef:
  name: cluster-admin
  kind: ClusterRole
  apiGroup: rbac.authorization.k8s.io
subjects:
  - name: gitlab:group:100  # platformグループ
    kind: Group
---
# レベル2: アプリケーションチーム（特定名前空間）
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: app-team-deploy
  namespace: app-production
roleRef:
  name: edit
  kind: ClusterRole
  apiGroup: rbac.authorization.k8s.io
subjects:
  - name: gitlab:project_env_tier:300:production
    kind: Group
---
# レベル3: 読み取り専用（すべての開発者）
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: all-developers-view
roleRef:
  name: view
  kind: ClusterRole
  apiGroup: rbac.authorization.k8s.io
subjects:
  - name: gitlab:group:200  # engineeringグループ
    kind: Group

リポジトリ構造

platform/gitops/
├── clusters/
│   ├── prod-us-east/
│   │   ├── infrastructure/
│   │   └── tenants/
│   │       ├── team-a/
│   │       └── team-b/
│   ├── prod-eu-west/
│   └── staging-us-east/
└── .gitlab/
    └── agents/
        ├── prod-us-east-agent/
        ├── prod-eu-west-agent/
        └── staging-us-east-agent/

11. トラブルシューティング

11.1. Agent接続の問題

11.1.1. Agentがオンラインにならない

症状

kubectl get pods -n gitlab-agent-my-agent
# Pod が CrashLoopBackOff または ImagePullBackOff

確認事項

トークンの確認

kubectl get secret -n gitlab-agent-my-agent gitlab-agent-token -o jsonpath='{.data.token}' | base64 -d

GitLabで生成されたトークンと一致するか確認します。

KASアドレスの確認

kubectl get deployment -n gitlab-agent-my-agent gitlab-agent -o yaml | grep kas-address

ネットワーク接続の確認

kubectl run -it --rm debug --image=curlimages/curl --restart=Never -- \
  curl -v https://kas.gitlab.com  # または自分のKASアドレス

解決策

トークンが間違っている場合: Secretを更新
KASアドレスが間違っている場合: Helmリリースを更新
ネットワーク問題: ファイアウォール設定を確認

11.1.2. 接続が頻繁に切れる

症状

GitLabのAgent一覧で、接続ステータスが頻繁に「オフライン」になる。

原因

プロキシのタイムアウト設定が短い
ネットワークの不安定性

解決策

プロキシのタイムアウトを2時間以上に設定します。

# Nginx の例
proxy_read_timeout 7200s;
proxy_send_timeout 7200s;

11.2. CI/CDからのアクセス問題

11.2.1. `kubectl`コマンドが認証エラー

症状

error: You must be logged in to the server (the server has asked for the client to provide credentials)

確認事項

コンテキストの確認

script:
  - kubectl config get-contexts
  - kubectl config current-context

$KUBECONFIGの確認

script:
  - echo $KUBECONFIG
  - cat $KUBECONFIG

解決策

コンテキストが正しく設定されていない場合: kubectl config use-contextを実行
$KUBECONFIGが空の場合: Agent認可設定を確認

11.2.2. 証明書エラー

症状

x509: certificate signed by unknown authority

原因

KASが自己署名証明書を使用している。

解決策

CI/CD変数SSL_CERT_FILEを設定します。

variables:
  SSL_CERT_FILE: $KAS_CERTIFICATE  # PEM形式の証明書

11.2.3. 権限エラー

症状

Error from server (Forbidden): pods is forbidden: User "gitlab:ci_job:123" cannot list resource "pods"

原因

RBACで適切な権限が付与されていない。

解決策

必要な権限を持つRoleBindingを作成します。

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ci-job-access
  namespace: default
roleRef:
  name: edit
  kind: ClusterRole
  apiGroup: rbac.authorization.k8s.io
subjects:
  - name: gitlab:ci_job
    kind: Group

11.3. Flux関連の問題

11.3.1. Fluxが変更を検出しない

症状

Gitにプッシュしても、クラスタに反映されない。

確認事項

flux get sources git
flux get kustomizations

解決策

手動調整

flux reconcile source git flux-system
flux reconcile kustomization flux-system

Webhookの確認

kubectl logs -n flux-system deployment/notification-controller

間隔の短縮（一時的）

apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: flux-system
  namespace: flux-system
spec:
  interval: 1m  # デフォルトは5m

11.3.2. OCIレジストリからのプルエラー

症状

failed to pull artifact: authentication required

原因

デプロイトークンの権限不足または有効期限切れ。

解決策

トークンの確認

kubectl get secret -n flux-system flux-system -o yaml

新しいトークンの作成

GitLabでデプロイトークンを再作成し、Secretを更新します。

kubectl create secret docker-registry flux-system \
  --docker-server=registry.gitlab.com \
  --docker-username=<deploy-token-username> \
  --docker-password=<deploy-token-password> \
  -n flux-system \
  --dry-run=client -o yaml | kubectl apply -f -

11.4. パフォーマンス問題

11.4.1. `kubectl`が遅い

症状

CI/CDジョブでkubectlコマンドの実行が非常に遅い。

原因

~/.kube/cacheが書き込み不可。

解決策

Dockerfileでキャッシュディレクトリを書き込み可能にします。

FROM bitnami/kubectl:latest
RUN mkdir -p /home/kubectl/.kube/cache && \
    chmod -R 777 /home/kubectl/.kube
USER kubectl

または、CI/CDジョブで設定します。

before_script:
  - mkdir -p ~/.kube/cache
  - chmod -R 777 ~/.kube/cache

11.4.2. Agentのメモリ使用量が高い

症状

Agentポッドのメモリ使用量が増加し続ける。

原因

大量のKubernetesリソースをキャッシュしている
メモリリークの可能性

解決策

リソース制限の設定

# Helm values
resources:
  limits:
    memory: 512Mi
  requests:
    memory: 256Mi

Agentのアップグレード

glab cluster agent bootstrap --manifest-path clusters/my-cluster my-agent

不要なリソースの監視を停止

Agent設定で、監視対象を限定します。

12. 運用のベストプラクティス

12.1. セキュリティ

最小権限の原則
- CI/CDジョブのなりすましを有効化
- RBACで必要最小限の権限のみ付与
- 本番環境は保護されたブランチのみに制限
トークン管理
- デプロイトークンを使用（パーソナルアクセストークンは避ける）
- 定期的なローテーション
- 有効期限の設定
監査
- Kubernetes監査ログの有効化
- GitLabのアクセスログを定期的に確認
- なりすまし情報を活用した追跡

12.2. 可用性

Agent の冗長化
- 本番環境では複数のAgentレプリカを実行
- 異なるノードに配置（Pod Anti-Affinity）

# Helm values
replicas: 3
affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
    - labelSelector:
        matchExpressions:
        - key: app
          operator: In
          values:
          - gitlab-agent
      topologyKey: kubernetes.io/hostname

Flux の冗長化
- 重要なコントローラーは複数レプリカ

flux install --components-extra=image-reflector-controller,image-automation-controller

バックアップ
- Agent設定のバックアップ（Gitで管理）
- クラスタ状態のバックアップ（Veleroなど）

12.3. 監視とアラート

Agent の監視

# Prometheus ServiceMonitor
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: gitlab-agent
  namespace: gitlab-agent-my-agent
spec:
  selector:
    matchLabels:
      app: gitlab-agent
  endpoints:
  - port: metrics

Flux の監視

flux check --pre
flux get all

アラート設定

# PrometheusRule
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: gitlab-agent-alerts
spec:
  groups:
  - name: gitlab-agent
    rules:
    - alert: GitLabAgentDown
      expr: up{job="gitlab-agent"} == 0
      for: 5m
      annotations:
        summary: "GitLab Agent is down"

12.4. アップグレード戦略

定期的なアップグレード
- 月次でFluxとAgentをアップグレード
- リリースノートを確認
段階的ロールアウト
- 開発環境 → ステージング → 本番の順にアップグレード
- 各環境で動作確認
ロールバック計画
- Gitの履歴を使った即座のロールバック
- Helmリリースのロールバック

helm rollback gitlab-agent -n gitlab-agent-my-agent

12.5. コスト最適化

リソース制限の適切な設定

# 小規模クラスタ
resources:
  requests:
    cpu: 50m
    memory: 128Mi
  limits:
    cpu: 200m
    memory: 256Mi

# 大規模クラスタ
resources:
  requests:
    cpu: 200m
    memory: 512Mi
  limits:
    cpu: 1000m
    memory: 1Gi

不要なリソースの削除
- 使用していないAgentの削除
- 古いFlux定義の整理
クラスタの統合
- 小規模環境は1つのクラスタに統合
- 名前空間で分離

13. 用語集

用語	定義	スコープ
GitLab agent for Kubernetes	GitLabとKubernetesを接続する統合ソリューション。`agentk`と`kas`で構成	GitLab、Kubernetes
`agentk`	クラスタ内で動作するAgent。GitLabとの接続を維持	Kubernetes
`kas` (GitLab agent server for Kubernetes)	GitLab側で動作するサーバー。Agentとの通信を管理	GitLab
プルベースデプロイメント	クラスタがGitリポジトリから変更を取得して適用する方式	GitOps
プッシュベースデプロイメント	CI/CDパイプラインからクラスタに変更を送信する方式	CI/CD
Flux	CNCF卒業プロジェクト。GitOpsを実現するツール	GitOps、Kubernetes
GitOps	Gitを唯一の信頼できる情報源として、宣言的にインフラを管理する手法	DevOps
なりすまし (Impersonation)	CI/CDジョブが特定のユーザー/グループとしてKubernetes APIにアクセスする仕組み	Kubernetes、セキュリティ
OCIレジストリ	Open Container Initiative準拠のコンテナイメージレジストリ	コンテナ
Receptive Agent	GitLabから接続を受け付けるAgent（通常は逆）	GitLab、Kubernetes

14. まとめ

GitLab Kubernetes Agentは、Kubernetesクラスタの管理とデプロイメントを統合的に実現する強力なソリューションです。本記事で解説した内容をまとめます。

14.1. 主要な利点

セキュリティ: なりすましとRBACによる細かなアクセス制御
柔軟性: GitOpsとCI/CDの両方のワークフローをサポート
スケーラビリティ: マルチテナンシー、マルチクラスタに対応
自動化: Infrastructure as Codeによるクラスタ作成
可視性: リアルタイムダッシュボードと監査ログ

14.2. 推奨アプローチ

本番環境

GitOpsワークフロー（Flux）を採用
OCIレジストリをソースとして使用
CI/CDジョブのなりすましを有効化
保護されたブランチのみに制限
環境ティアによるアクセス制御

開発/検証環境

GitOpsまたはCI/CDワークフロー
柔軟なアクセス制御
迅速なイテレーション

14.3. 次のステップ

クイックスタート（セクション9）で基本的なセットアップを実施
ユースケース別構成（セクション10）で自分の環境に合った設定を選択
アクセス制御（セクション8）でセキュリティを強化
運用ベストプラクティス（セクション12）で安定運用を実現

GitLab Kubernetes Agentを活用することで、開発チームはKubernetesの複雑さを抽象化しながら、安全で効率的なクラウドネイティブアプリケーションのデリバリーを実現できます。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

GitLab Kubernetes Agent で実現する、モダンなKubernetesクラスタ管理

GitLab Kubernetes Agent で実現する、モダンなKubernetesクラスタ管理

1. GitLab Kubernetes Agentとは

1.1. 概要とアーキテクチャ

1.2. 従来方式との違い

1.3. 主要な特徴

1.4. 技術的詳細

2. サポート環境

2.1. Kubernetesバージョン

2.2. GitLabエディション

3. デプロイメントワークフロー比較

3.1. 2つのアプローチ

3.2. 詳細比較

3.3. 使い分けの指針

4. GitOpsワークフロー詳解

4.1. なぜGitOpsなのか

4.2. Fluxとの統合

4.3. OCIレジストリの活用

4.4. 即時Git調整の仕組み

4.5. リポジトリ構造のベストプラクティス

4.6. トークン管理戦略

5. CI/CDワークフロー詳解

5.1. 基本構成

5.2. .gitlab-ci.ymlの実装例

5.3. Auto DevOps環境での設定

5.4. 証明書ベース接続との共存

5.5. 自己署名証明書環境での設定

6. Infrastructure as Codeによるクラスタ作成

6.1. 対応クラウドプロバイダー概要

6.2. 共通の作成フロー

6.3. クラウドプロバイダー別詳細

6.3.1. Google Kubernetes Engine（GKE）

6.3.2. Amazon Elastic Kubernetes Service（EKS）

6.3.3. Azure Kubernetes Service（AKS）

6.3.4. Civo Kubernetes

6.4. クラスタの削除

7. Agentアクセスの認可

7.1. 認可の概念

7.2. プロジェクト単位の認可

7.3. グループ単位の認可

7.4. インスタンス全体への認可（Self-Managed限定）

8. アクセス制御の高度な設定

8.1. なりすまし（Impersonation）の概要

8.2. なりすまし対象の選択

8.3. CI/CDジョブのなりすまし（推奨）

8.4. RBAC設定例

8.4.1. すべてのCI/CDジョブに読み取り専用権限

8.4.2. 特定プロジェクトに名前空間への書き込み権限

8.4.3. 本番環境のみ特定グループに権限付与

8.4.4. 段階的な権限設定（開発→ステージング→本番）

8.5. 静的IDのなりすまし

8.6. 環境による制限

8.7. 保護されたブランチによる制限（Self-Managed/Dedicated）

9. クイックスタートガイド

9.1. 前提条件の確認

9.2. Flux CLIのインストール

9.3. GitLab CLIのインストール

9.4. パーソナルアクセストークンの作成

9.5. Fluxのブートストラップ

9.6. GitLab Agentのブートストラップ

9.7. ダッシュボードの確認

9.8. ユーザーなりすましの設定（Premium/Ultimate）

9.9. 最初のアプリケーションのデプロイ

10. ユースケース別推奨構成

10.1. 小規模チーム（1〜5人）

10.2. 中規模組織（複数チーム）

10.3. エンタープライズ（マルチクラスタ、マルチリージョン）

11. トラブルシューティング

11.1. Agent接続の問題

11.1.1. Agentがオンラインにならない

11.1.2. 接続が頻繁に切れる

11.2. CI/CDからのアクセス問題

11.2.1. kubectlコマンドが認証エラー

11.2.2. 証明書エラー

11.2.3. 権限エラー

11.3. Flux関連の問題

11.3.1. Fluxが変更を検出しない

11.3.2. OCIレジストリからのプルエラー

11.4. パフォーマンス問題

11.4.1. kubectlが遅い

5.2. `.gitlab-ci.yml`の実装例

11.2.1. `kubectl`コマンドが認証エラー

11.4.1. `kubectl`が遅い