正式なドキュメントは英語版であり、この日本語訳はAI支援翻訳により作成された参考用のものです。日本語訳の一部の内容は人間によるレビューがまだ行われていないため、翻訳のタイミングにより英語版との間に差異が生じることがあります。最新かつ正確な情報については、英語版をご参照ください。

Kubernetes向けGitLabエージェントへの移行

  • プラン: Free、Premium、Ultimate
  • 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated

GitLabとKubernetesクラスターを接続するには、以下を使用できます:

証明書ベースのインテグレーションはGitLab 14.5で非推奨です。サービス終了計画は以下に記載されています:

証明書ベースのインテグレーションを使用している場合は、できるだけ早く別のワークフローに移行する必要があります。

一般的なルールとして、GitLab CI/CDに依存するクラスターを移行する移行するには、CI/CDワークフローを使用できます。このワークフローは、エージェントを使用してクラスターに接続します。エージェント:

  • インターネットに公開されません。
  • GitLabへの完全なcluster-adminアクセスを必要としません。

証明書ベースのインテグレーションは、GitLabマネージドApp、GitLabマネージドクラスター、Auto DevOpsなどの一般的なGitLab機能に使用されていました。

証明書ベースのクラスターを検索

GitLabインスタンスまたはグループ内にあるすべての証明書ベースのクラスター(サブグループやプロジェクトを含む)は、専用のAPIを使用して検索できます。グループIDでAPIをクエリすると、指定されたグループまたはその下に定義されているすべての証明書ベースのクラスターが返されます。

この場合、親グループに定義されているクラスターは返されません。この動作により、グループオーナーは移行する必要のあるすべてのクラスターを見つけることができます。

誤ってクラスターが残されることを避けるため、無効化されたクラスターも返されます。

クラスター検出APIは個人ネームスペースでは動作しません。

一般的なデプロイを移行する

一般的なデプロイを移行するには:

  1. Kubernetes向けGitLabエージェントをインストールします。
  2. CI/CDワークフローに従って、エージェントにグループとプロジェクトへのアクセスを許可するか、代理でアクセスを保護します。
  3. 左サイドバーで、操作 > Kubernetesクラスターを選択します。
  4. 証明書ベースのクラスターセクションから、同じ環境スコープを提供するクラスターを開きます。
  5. 詳細タブを選択し、クラスターをオフにします。

GitLabマネージドクラスターからKubernetesリソースへの移行する

  • プラン: Premium、Ultimate

GitLabマネージドクラスターを使用すると、GitLabはブランチごとに個別のサービスアカウントとネームスペースを作成し、これらのリソースを使用してデプロイします。

これで、GitLabマネージドKubernetesリソースを使用して、強化されたセキュリティ制御でリソースをセルフサービスで利用できます。

GitLabマネージドKubernetesリソースを使用すると、以下のことが可能です:

  • 手動での介入なしに、安全に環境を設定できます。
  • デベロッパーに管理クラスター権限を与えることなく、リソースの作成とアクセスを制御できます。
  • 新しいプロジェクトや環境を作成する際に、デベロッパーにセルフサービス機能を提供します。
  • デベロッパーが専用または共有のネームスペースにテストおよび開発バージョンをデプロイできるようにします。

前提条件:

GitLabマネージドクラスターからGitLabマネージドKubernetesリソースへ移行するには:

  1. 既存の環境を移行する場合は、Kubernetes用ダッシュボードまたは環境APIのいずれかを使用して、環境用のエージェントを設定します。

  2. エージェント設定ファイルでリソース管理を有効にするようにエージェントを設定します:

    ci_access:
       projects:
         - id: <your_group/your_project>
           access_as:
             ci_job: {}
           resource_management:
             enabled: true
       groups:
         - id: <your_other_group>
           access_as:
             ci_job: {}
           resource_management:
             enabled: true
  3. .gitlab/agents/<agent-name>/environment_templates/default.yamlの下に環境テンプレートを作成します。証明書ベースのクラスターインテグレーションページで、環境ごとのネームスペースチェックボックスのステータスを確認します。

    環境ごとのネームスペースがチェックされていた場合は、以下のテンプレートを使用します:

    objects:
      - apiVersion: v1
        kind: Namespace
        metadata:
          # the `.legacy_namespace` produces something like:
          # '{{ .project.slug }}-{{ .project.id }}-{{ .environment.slug }}'
          # that is compatible with what the certificate-based cluster integration
          # would have generated.
          name: '{{ .legacy_namespace }}'
      - apiVersion: rbac.authorization.k8s.io/v1
        kind: RoleBinding
        metadata:
          name: 'bind-{{ .agent.id }}-{{ .project.id }}-{{ .environment.slug }}'
          namespace: '{{ .legacy_namespace }}'
        subjects:
          - kind: Group
            apiGroup: rbac.authorization.k8s.io
            name: 'gitlab:project_env:{{ .project.id }}:{{ .environment.slug }}'
        roleRef:
          apiGroup: rbac.authorization.k8s.io
          kind: ClusterRole
          name: admin

    環境ごとのネームスペースがチェックされていなかった場合は、以下のテンプレートを使用します:

    objects:
      - apiVersion: v1
        kind: Namespace
        metadata:
          name: '{{ .project.slug | slugify }}-{{ .project.id }}'
      - apiVersion: rbac.authorization.k8s.io/v1
        kind: RoleBinding
        metadata:
          name: 'bind-{{ .agent.id }}-{{ .project.id }}-{{ .environment.slug }}'
          namespace: '{{ .project.slug | slugify }}-{{ .project.id }}'
        subjects:
          - kind: Group
            apiGroup: rbac.authorization.k8s.io
            name: 'gitlab:project_env:{{ .project.id }}:{{ .environment.slug }}'
        roleRef:
          apiGroup: rbac.authorization.k8s.io
          kind: ClusterRole
          name: admin
  4. CI/CDの設定で、environment.kubernetes.agent: <path/to/agent/project:agent-name>構文を使用してエージェントを使用します。

  5. 左サイドバーで、操作 > Kubernetesクラスターを選択します。

  6. 証明書ベースのクラスターセクションから、同じ環境スコープを提供するクラスターを開きます。

  7. 詳細タブを選択し、クラスターをオフにします。

Auto DevOpsからの移行する

Auto DevOpsプロジェクトで、Kubernetes向けGitLabエージェントを使用してKubernetesクラスターに接続できます。

前提条件

Auto DevOpsから移行するには:

  1. GitLabで、Auto DevOpsを使用しているプロジェクトに移動します。

  2. 3つの変数を追加します。左サイドバーで、設定 > CI/CDを選択し、変数を展開するします。

    • アプリケーションデプロイドメインを値として、KUBE_INGRESS_BASE_DOMAINというキーを追加します。

    • path/to/agent/project:agent-nameのような値を持つKUBE_CONTEXTというキーを追加します。任意の環境スコープを選択します。エージェントのコンテキストがわからない場合は、.gitlab-ci.ymlファイルを編集し、利用可能なコンテキストを確認するためのジョブを追加します:

      deploy:
        image: debian:13-slim
        variables:
          KUBECTL_VERSION: v1.34
          DEBIAN_FRONTEND: noninteractive
        script:
          # Follows https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/#install-using-native-package-management
          - 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
    • ターゲットとするデプロイ用のKubernetesネームスペースの値を、KUBE_NAMESPACEというキーに追加します。同じ環境スコープを設定します。

  3. 変数を追加を選択します。

  4. 左サイドバーで、操作 > Kubernetesクラスターを選択します。

  5. 証明書ベースのクラスターセクションから、同じ環境スコープを提供するクラスターを開きます。

  6. 詳細タブを選択し、クラスターを無効にします。

  7. .gitlab-ci.ymlファイルを編集し、Auto DevOpsテンプレートを使用していることを確認します。例:

    include:
      template: Auto-DevOps.gitlab-ci.yml
    
    variables:
      KUBE_INGRESS_BASE_DOMAIN: 74.220.23.215.nip.io
      KUBE_CONTEXT: "gitlab-examples/ops/gitops-demo/k8s-agents:demo-agent"
      KUBE_NAMESPACE: "demo-agent"
  8. パイプラインをテストするには、左サイドバーでビルド > パイプライン、そして新しいパイプラインを選択します。

例として、このプロジェクトをご覧ください。

GitLabマネージドアプリケーションからの移行する

GitLabマネージドApp (GMA) はGitLab 14.0で非推奨となり、GitLab 15.0で削除されました。Kubernetes用エージェントはそれらをサポートしていません。GMAからエージェントへ移行するには、以下の手順を実行します:

  1. GitLabマネージドAppからクラスター管理プロジェクトへ移行する
  2. クラスター管理プロジェクトをエージェントを使用するように移行する

クラスター管理プロジェクトを移行する

Kubernetes向けGitLabエージェントでクラスター管理プロジェクトを使用する方法をご覧ください。

クラスターモニタリング機能の移行する

KubernetesクラスターをKubernetes用エージェントを使用してGitLabに接続すると、ユーザーアクセスを有効にした後、Kubernetes用ダッシュボードを使用できます。