安全AI代理部署到GKE

本指南介绍如何使用GitLab的AI驱动DevSecOps平台，轻松安全地将基于ADK的AI代理部署到Google Kubernetes Engine。

构建AI代理令人兴奋，但将其安全部署到生产环境不应复杂。在本教程中，您将学习GitLab的原生Google Cloud集成如何简化AI代理到Google Kubernetes Engine（GKE）的部署——具备内置扫描和零服务账户密钥。

为什么选择GKE部署AI代理？

GKE提供企业级编排，通过OIDC认证与GitLab CI/CD管道无缝连接。您的开发团队可以在部署AI代理的同时，保持对云基础设施的完全可见性、合规性和控制。本指南使用Google的Agent Development Kit（ADK）构建应用程序，因此您可以在使用GitLab部署时获得更高的无缝性。

三个关键优势：

完整基础设施控制 - 您的数据、您的规则、您的环境。您完全控制AI代理的运行位置和配置方式。
原生GitLab集成 - 无需复杂的变通方案。由于GitLab与Google Cloud的原生集成，您现有的管道可以开箱即用。
生产级扩展 - 随着AI工作负载的增长，GKE自动处理扩展和内部编排的重任。

关键点是，GitLab与GKE结合提供了AI部署所需的企业可靠性，同时不牺牲团队期望的开发人员体验。

先决条件

在开始之前，请确保已启用这些API：

GKE API
Artifact Registry API
Vertex AI API

还要确保您有：

已创建的GitLab项目
已配置的GKE集群
已创建的Artifact Registry仓库

部署流程

1. 在GitLab上设置IAM和权限

导航到您的GitLab集成以配置Google Cloud身份验证（IAM）。

转到设置 > 集成并配置Google Cloud集成。如果您使用组级集成，请注意项目已继承默认设置。这意味着您在组级配置一次，所有项目都会受益并继承此设置。

要从头开始设置，请提供：

项目ID
项目编号
工作负载身份池ID
提供者ID

配置后，GitLab提供一个在Google Cloud Console中通过Cloud Shell运行的脚本。运行此脚本的结果是一个工作负载身份联邦池，具有启用适当访问所需的服务主体。

2. 配置Artifact Registry集成

仍在GitLab的集成设置中，配置Artifact Management：

单击Artifact Management
选择Google Artifact Registry
提供：
- 项目ID
- 仓库名称（预先创建）
- 仓库位置

GitLab提供另一个在Google Cloud Console中运行的脚本。

重要：在继续之前，向工作负载身份联邦池添加这些额外角色：

Service Account User
Kubernetes Developer
Kubernetes Cluster Viewer

这些权限允许GitLab在后续步骤中部署到GKE。

3. 创建CI/CD管道

现在是关键部分——为部署创建CI/CD管道。

转到构建 > 管道编辑器，定义具有四个阶段的管道：

构建 - Docker创建容器镜像
测试 - GitLab Auto DevOps提供内置安全扫描，确保没有漏洞
上传 - 使用GitLab的内置CI/CD组件推送到Google Artifact Registry
部署 - 使用Kubernetes配置部署到GKE

以下是完整的.gitlab-ci.yml：

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116


default:
  tags: [ saas-linux-2xlarge-amd64 ]

stages:
  - build
  - test
  - upload
  - deploy

variables:
  GITLAB_IMAGE: $CI_REGISTRY_IMAGE/main:$CI_COMMIT_SHORT_SHA
  AR_IMAGE: $GOOGLE_ARTIFACT_REGISTRY_REPOSITORY_LOCATION-docker.pkg.dev/$GOOGLE_ARTIFACT_REGISTRY_PROJECT_ID/$GOOGLE_ARTIFACT_REGISTRY_REPOSITORY_NAME/main:$CI_COMMIT_SHORT_SHA
  GCP_PROJECT_ID: "your-project-id"
  GKE_CLUSTER: "your-cluster"
  GKE_REGION: "us-central1"
  KSA_NAME: "ai-agent-ksa"

build:
  image: docker:24.0.5
  stage: build
  services:
    - docker:24.0.5-dind
  before_script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
  script:
    - docker build -t $GITLAB_IMAGE .
    - docker push $GITLAB_IMAGE

include:
  - template: Jobs/Dependency-Scanning.gitlab-ci.yml
  - template: Jobs/Container-Scanning.gitlab-ci.yml
  - template: Jobs/Secret-Detection.gitlab-ci.yml
  - component: gitlab.com/google-gitlab-components/artifact-registry/upload-artifact-registry@main
    inputs:
      stage: upload
      source: $GITLAB_IMAGE
      target: $AR_IMAGE

deploy:
  stage: deploy
  image: google/cloud-sdk:slim
  identity: google_cloud
  before_script:
    - apt-get update && apt-get install -y kubectl google-cloud-sdk-gke-gcloud-auth-plugin
    - gcloud container clusters get-credentials $GKE_CLUSTER --region $GKE_REGION --project $GCP_PROJECT_ID
  script:
    - |
      kubectl apply -f - <<EOF
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: ai-agent
        namespace: default
      spec:
        replicas: 2
        selector:
          matchLabels:
            app: ai-agent
        template:
          metadata:
            labels:
              app: ai-agent
          spec:
            serviceAccountName: $KSA_NAME
            containers:
            - name: ai-agent
              image: $AR_IMAGE
              ports:
              - containerPort: 8080
              resources:
                requests: {cpu: 500m, memory: 1Gi}
                limits: {cpu: 2000m, memory: 4Gi}
              livenessProbe:
                httpGet: {path: /health, port: 8080}
                initialDelaySeconds: 60
              readinessProbe:
                httpGet: {path: /health, port: 8080}
                initialDelaySeconds: 30
      ---
      apiVersion: v1
      kind: Service
      metadata:
        name: ai-agent-service
        namespace: default
      spec:
        type: LoadBalancer
        ports:
        - port: 80
          targetPort: 8080
        selector:
          app: ai-agent
      ---
      apiVersion: autoscaling/v2
      kind: HorizontalPodAutoscaler
      metadata:
        name: ai-agent-hpa
        namespace: default
      spec:
        scaleTargetRef:
          apiVersion: apps/v1
          kind: Deployment
          name: ai-agent
        minReplicas: 2
        maxReplicas: 10
        metrics:
        - type: Resource
          resource:
            name: cpu
            target: {type: Utilization, averageUtilization: 70}
      EOF
      
      kubectl rollout status deployment/ai-agent -n default --timeout=5m
      EXTERNAL_IP=$(kubectl get service ai-agent-service -n default -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
      echo "Deployed at: http://$EXTERNAL_IP"
  only:
    - main

GKE的关键配置

使这一切工作的原因——以及为什么我们需要为GKE进行这种额外配置——是我们必须在集群中有一个可以与Vertex AI配合使用的Kubernetes服务账户。我们需要该服务账户被允许访问Google Cloud的AI功能。

没有这个，我们可以部署应用程序，但AI代理将无法工作。我们需要创建一个可以访问Vertex AI的Kubernetes服务账户。

运行这个一次性设置：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34


#!/bin/bash

PROJECT_ID="your-project-id"
GSA_NAME="ai-agent-vertex"
GSA_EMAIL="${GSA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com"
KSA_NAME="ai-agent-ksa"
CLUSTER_NAME="your-cluster"
REGION="us-central1"

# 创建GCP服务账户
gcloud iam service-accounts create $GSA_NAME \
    --display-name="AI Agent Vertex AI" \
    --project=$PROJECT_ID

# 授予Vertex AI权限
gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:${GSA_EMAIL}" \
    --role="roles/aiplatform.user"

# 获取集群凭据
gcloud container clusters get-credentials $CLUSTER_NAME \
    --region $REGION --project $PROJECT_ID

# 创建Kubernetes服务账户
kubectl create serviceaccount $KSA_NAME -n default

# 链接账户
kubectl annotate serviceaccount $KSA_NAME -n default \
    iam.gke.io/gcp-service-account=${GSA_EMAIL}

gcloud iam service-accounts add-iam-policy-binding ${GSA_EMAIL} \
    --role=roles/iam.workloadIdentityUser \
    --member="serviceAccount:${PROJECT_ID}.svc.id.goog[default/${KSA_NAME}]" \
    --project=$PROJECT_ID

4. 部署到GKE

完成后，将此更改推送到管道，您就可以开始了。

您可以看到管道刚刚部署。转到CI/CD > 管道，您将看到四个阶段：

构建
测试（包含所有定义的安全扫描）
上传到Artifact Registry（成功）
部署到GKE中的Kubernetes（成功）

总结

通过GitLab和Google Cloud的结合，您能够轻松安全地将AI代理部署到GKE。我们不必经历很多步骤——这得益于GitLab与Google Cloud的原生集成。

使用本教程的完整代码示例立即开始。还不是GitLab客户？通过免费试用探索DevSecOps平台。托管在Google Cloud上的初创公司有特殊福利可以试用和使用GitLab。

安全部署AI代理到Google Kubernetes引擎全指南

本指南详细讲解如何使用GitLab的AI驱动DevSecOps平台将基于ADK的AI代理安全部署到Google Kubernetes引擎，涵盖IAM配置、Artifact Registry集成和CI/CD管道设置，实现零服务账户密钥的安全部署。