一、概述
1.1 背景介绍
在云原生时代，企业的基础设施管理面临着前所未有的挑战。传统的手工配置和脚本化运维方式已经无法满足多云、多集群环境下的快速迭代需求。GitOps作为一种声明式的基础设施管理理念，通过Git作为单一事实来源（Single Source of Truth），实现了基础设施的版本化、可追溯和自动化。
在实际生产环境中，我们发现单纯使用Kubernetes原生资源管理应用已经不够了。当需要管理云服务商的RDS、S3、VPC等资源时，传统的Terraform虽然强大，但缺乏与Kubernetes生态的深度集成。这就是Crossplane诞生的背景——它将云资源抽象为Kubernetes CRD，让我们可以用统一的方式管理应用和基础设施。
ArgoCD则是GitOps工具链中的佼佼者，它提供了强大的多集群管理能力、灵活的同步策略和完善的RBAC机制。将ArgoCD与Crossplane结合，我们就能构建一套完整的GitOps 2.0体系：不仅管理应用部署，还能管理底层的云基础设施。
1.2 技术特点
- 声明式管理：所有基础设施和应用配置都以YAML形式存储在Git仓库中，通过声明期望状态而非执行命令来管理资源
- 自动化同步：ArgoCD持续监控Git仓库变化，自动将变更同步到目标集群，实现真正的持续部署
- 多云抽象：Crossplane提供统一的API抽象层，屏蔽不同云服务商的差异，支持AWS、Azure、GCP等主流云平台
- 漂移检测：自动检测实际状态与期望状态的偏差，并提供自动修复或告警机制
- 审计追溯：所有变更都通过Git提交记录，天然具备完整的审计日志和回滚能力
- 多租户隔离：通过Kubernetes RBAC和ArgoCD Projects实现细粒度的权限控制
1.3 适用场景
- 多云环境管理：企业同时使用AWS、Azure、GCP等多个云平台，需要统一的管理界面和工作流程。在我们的实践中，通过Crossplane管理跨云资源，避免了维护多套Terraform代码的复杂性。
- 大规模集群编排：管理数十个甚至上百个Kubernetes集群，需要统一的应用分发和配置管理。ArgoCD的ApplicationSet功能可以通过模板化方式批量管理集群。
- 自服务基础设施：开发团队需要自助申请数据库、缓存、存储等云资源，但运维团队希望保持控制权。通过Crossplane的Composition机制，可以定义标准化的资源模板，开发团队只需声明需求即可。
- 灾难恢复和环境复制：需要快速在不同区域或云平台复制整套环境。所有配置都在Git中，只需调整少量参数即可在新环境重建。
- 合规性要求：金融、医疗等行业对变更审计有严格要求。GitOps天然提供完整的变更历史和审批流程集成能力。
1.4 环境要求
| 组件 |
版本要求 |
说明 |
| Kubernetes |
1.24+ |
管理集群建议使用1.26+，需要支持CRD v1 |
| ArgoCD |
2.8+ |
建议使用2.9+以获得更好的ApplicationSet支持 |
| Crossplane |
1.14+ |
核心组件，需要安装对应的Provider |
| Helm |
3.10+ |
用于安装ArgoCD和Crossplane |
| kubectl |
1.24+ |
与Kubernetes版本匹配 |
| Git |
2.30+ |
代码仓库，支持GitHub、GitLab、Bitbucket |
| 云平台账号 |
- |
AWS/Azure/GCP账号及相应的IAM权限 |
硬件配置建议：
| 环境类型 |
控制平面节点 |
工作节点 |
说明 |
| 开发环境 |
2C4G × 1 |
4C8G × 2 |
可使用Minikube或Kind |
| 测试环境 |
4C8G × 3 |
8C16G × 3 |
建议使用托管Kubernetes |
| 生产环境 |
8C16G × 3 |
16C32G × 5+ |
高可用配置，跨AZ部署 |
网络要求：
- 集群节点之间需要互通（Pod网络和Service网络）
- 控制平面需要访问Git仓库（HTTPS 443端口）
- Crossplane需要访问云服务商API（HTTPS 443端口）
- ArgoCD UI访问端口（默认80/443）
二、详细步骤
2.1 准备工作
2.1.1 系统检查
# 检查Kubernetes集群状态
kubectl cluster-info
kubectl get nodes
# 检查集群版本
kubectl version --short
# 检查可用资源
kubectl top nodes
kubectl get pods -A
# 验证存储类
kubectl get storageclass
2.1.2 安装依赖工具
# 安装Helm（如果未安装）
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
# 验证Helm版本
helm version
# 添加必要的Helm仓库
helm repo add argo https://argoproj.github.io/argo-helm
helm repo add crossplane-stable https://charts.crossplane.io/stable
helm repo update
# 安装kubectl插件（可选）
kubectl krew install crossplane
2.1.3 准备Git仓库
# 创建GitOps仓库结构
mkdir -p gitops-infra/{apps,infrastructure,clusters}
cd gitops-infra
# 初始化Git仓库
git init
git remote add origin https://github.com/your-org/gitops-infra.git
# 创建目录结构
cat > README.md <<EOF
# GitOps Infrastructure Repository
## 目录结构
- apps/: 应用配置
- infrastructure/: 基础设施资源（Crossplane）
- clusters/: 集群配置
EOF
git add .
git commit -m "Initial commit"
git push -u origin main
2.2 核心配置
2.2.1 安装ArgoCD
# 创建命名空间
kubectl create namespace argocd
# 使用Helm安装ArgoCD
helm install argocd argo/argo-cd \
--namespace argocd \
--version 5.51.0 \
--set server.service.type=LoadBalancer \
--set configs.params.”application.namespaces”=”*” \
--set server.extraArgs[0]=”--insecure”
# 等待Pod就绪
kubectl wait --for=condition=Ready pods --all -n argocd --timeout=300s
# 获取初始密码
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath=”{.data.password}” | base64 -d
配置说明：
server.service.type=LoadBalancer：生产环境建议使用Ingressapplication.namespaces=”*”：允许ArgoCD管理所有命名空间--insecure：禁用TLS，生产环境需配置证书
2.2.2 安装Crossplane
# 安装Crossplane核心组件
helm install crossplane \
--namespace crossplane-system \
--create-namespace \
crossplane-stable/crossplane \
--version 1.14.5 \
--set args[0]=”--enable-composition-revisions”
# 验证安装
kubectl get pods -n crossplane-system
kubectl api-resources | grep crossplane
2.2.3 配置Crossplane Provider
AWS Provider配置：
# 文件路径：infrastructure/providers/aws-provider.yaml
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
name: provider-aws
spec:
package: xpkg.upbound.io/upbound/provider-aws:v0.41.0
packagePullPolicy: IfNotPresent
---
apiVersion: v1
kind: Secret
metadata:
name: aws-credentials
namespace: crossplane-system
type: Opaque
stringData:
credentials: |
[default]
aws_access_key_id = YOUR_ACCESS_KEY
aws_secret_access_key = YOUR_SECRET_KEY
---
apiVersion: aws.upbound.io/v1beta1
kind: ProviderConfig
metadata:
name: default
spec:
credentials:
source: Secret
secretRef:
namespace: crossplane-system
name: aws-credentials
key: credentials
应用Provider配置：
# 应用Provider配置
kubectl apply -f infrastructure/providers/aws-provider.yaml
# 等待Provider就绪
kubectl wait --for=condition=Healthy provider.pkg.crossplane.io/provider-aws --timeout=300s
# 查看Provider状态
kubectl get providers
kubectl get providerconfigs
2.2.4 配置ArgoCD Application
# 文件路径：apps/argocd-apps/infrastructure-app.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: infrastructure
namespace: argocd
finalizers:
- resources-finalizer.argocd.argoproj.io
spec:
project: default
source:
repoURL: https://github.com/your-org/gitops-infra.git
targetRevision: main
path: infrastructure
destination:
server: https://kubernetes.default.svc
namespace: default
syncPolicy:
automated:
prune: true
selfHeal: true
allowEmpty: false
syncOptions:
- CreateNamespace=true
- PrunePropagationPolicy=foreground
retry:
limit: 5
backoff:
duration: 5s
factor: 2
maxDuration: 3m
参数说明：
prune: true：自动删除Git中不存在的资源selfHeal: true：自动修复漂移allowEmpty: false：防止误删除所有资源CreateNamespace=true：自动创建命名空间
2.3 启动和验证
2.3.1 启动服务
# 应用ArgoCD Application
kubectl apply -f apps/argocd-apps/infrastructure-app.yaml
# 查看Application状态
kubectl get applications -n argocd
# 查看同步状态
argocd app get infrastructure --refresh
# 访问ArgoCD UI
kubectl port-forward svc/argocd-server -n argocd 8080:443
# 浏览器访问 https://localhost:8080
2.3.2 功能验证
验证ArgoCD同步：
# 查看Application详情
argocd app get infrastructure
# 查看同步历史
argocd app history infrastructure
# 手动触发同步
argocd app sync infrastructure
# 预期输出：
# Name: infrastructure
# Project: default
# Server: https://kubernetes.default.svc
# Namespace: default
# URL: https://argocd.example.com/applications/infrastructure
# Repo: https://github.com/your-org/gitops-infra.git
# Target: main
# Path: infrastructure
# SyncWindow: Sync Allowed
# Sync Policy: Automated (Prune)
# Sync Status: Synced to main (abc1234)
# Health Status: Healthy
验证Crossplane资源创建：
# 创建测试S3 Bucket
cat > infrastructure/test-bucket.yaml <<EOF
apiVersion: s3.aws.upbound.io/v1beta1
kind: Bucket
metadata:
name: test-gitops-bucket-$(date +%s)
spec:
forProvider:
region: us-east-1
providerConfigRef:
name: default
EOF
# 提交到Git
git add infrastructure/test-bucket.yaml
git commit -m “Add test S3 bucket”
git push
# 等待ArgoCD同步（约30秒）
sleep 30
# 查看资源状态
kubectl get buckets
kubectl describe bucket test-gitops-bucket-*
# 预期输出：
# NAME READY SYNCED EXTERNAL-NAME AGE
# test-gitops-bucket-1234567 True True test-gitops-bucket-1234567 2m
验证多集群管理：
# 添加远程集群到ArgoCD
argocd cluster add prod-cluster-context --name prod-cluster
# 查看已注册集群
argocd cluster list
# 创建多集群Application
cat > apps/argocd-apps/multi-cluster-app.yaml <<EOF
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: multi-cluster-apps
namespace: argocd
spec:
generators:
- list:
elements:
- cluster: prod-cluster
url: https://prod-cluster-api.example.com
- cluster: staging-cluster
url: https://staging-cluster-api.example.com
template:
metadata:
name: '{{cluster}}-app'
spec:
project: default
source:
repoURL: https://github.com/your-org/gitops-infra.git
targetRevision: main
path: apps/{{cluster}}
destination:
server: '{{url}}'
namespace: default
syncPolicy:
automated:
prune: true
selfHeal: true
EOF
kubectl apply -f apps/argocd-apps/multi-cluster-app.yaml
三、示例代码和配置
3.1 完整配置示例
3.1.1 Crossplane Composition配置
Composition是Crossplane的核心概念，允许我们定义可复用的基础设施模板。下面是一个完整的RDS数据库Composition示例：
# 文件路径：infrastructure/compositions/rds-composition.yaml
apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition
metadata:
name: xpostgresqlinstances.database.example.com
spec:
group: database.example.com
names:
kind: XPostgreSQLInstance
plural: xpostgresqlinstances
claimNames:
kind: PostgreSQLInstance
plural: postgresqlinstances
versions:
- name: v1alpha1
served: true
referenceable: true
schema:
openAPIV3Schema:
type: object
properties:
spec:
type: object
properties:
parameters:
type: object
properties:
storageGB:
type: integer
default: 20
instanceClass:
type: string
default: db.t3.micro
engine:
type: string
default: “13.7”
required:
- storageGB
required:
- parameters
---
apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
name: xpostgresqlinstances.aws.database.example.com
labels:
provider: aws
spec:
writeConnectionSecretsToNamespace: crossplane-system
compositeTypeRef:
apiVersion: database.example.com/v1alpha1
kind: XPostgreSQLInstance
resources:
- name: rdsinstance
base:
apiVersion: rds.aws.upbound.io/v1beta1
kind: Instance
spec:
forProvider:
region: us-east-1
engine: postgres
instanceClass: db.t3.micro
allocatedStorage: 20
skipFinalSnapshot: true
publiclyAccessible: false
dbSubnetGroupNameSelector:
matchControllerRef: true
vpcSecurityGroupIdSelector:
matchControllerRef: true
writeConnectionSecretToRef:
namespace: crossplane-system
patches:
- fromFieldPath: “spec.parameters.storageGB”
toFieldPath: “spec.forProvider.allocatedStorage”
- fromFieldPath: “spec.parameters.instanceClass”
toFieldPath: “spec.forProvider.instanceClass”
- fromFieldPath: “spec.parameters.engine”
toFieldPath: “spec.forProvider.engineVersion”
- fromFieldPath: “metadata.uid”
toFieldPath: “spec.writeConnectionSecretToRef.name”
transforms:
- type: string
string:
fmt: “%s-postgresql”
connectionDetails:
- fromConnectionSecretKey: username
- fromConnectionSecretKey: password
- fromConnectionSecretKey: endpoint
- fromConnectionSecretKey: port
- name: dbsubnetgroup
base:
apiVersion: rds.aws.upbound.io/v1beta1
kind: SubnetGroup
spec:
forProvider:
region: us-east-1
description: “Subnet group for RDS instance”
subnetIdSelector:
matchLabels:
type: private
- name: securitygroup
base:
apiVersion: ec2.aws.upbound.io/v1beta1
kind: SecurityGroup
spec:
forProvider:
region: us-east-1
description: “Security group for RDS instance”
vpcIdSelector:
matchLabels:
type: main
- name: securitygrouprule
base:
apiVersion: ec2.aws.upbound.io/v1beta1
kind: SecurityGroupRule
spec:
forProvider:
region: us-east-1
type: ingress
fromPort: 5432
toPort: 5432
protocol: tcp
cidrBlocks:
- 10.0.0.0/16
securityGroupIdSelector:
matchControllerRef: true
3.1.2 ArgoCD Project配置
# 文件路径：apps/argocd-apps/project-config.yaml
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: infrastructure
namespace: argocd
spec:
description: Infrastructure resources managed by Crossplane
sourceRepos:
- 'https://github.com/your-org/gitops-infra.git'
destinations:
- namespace: '*'
server: '*'
clusterResourceWhitelist:
- group: '*'
kind: '*'
namespaceResourceWhitelist:
- group: '*'
kind: '*'
roles:
- name: infrastructure-admin
description: Full access to infrastructure resources
policies:
- p, proj:infrastructure:infrastructure-admin, applications, *, infrastructure/*, allow
groups:
- infrastructure-team
- name: infrastructure-readonly
description: Read-only access to infrastructure resources
policies:
- p, proj:infrastructure:infrastructure-readonly, applications, get, infrastructure/*, allow
groups:
- developers
3.1.3 多云资源编排脚本
#!/bin/bash
# 文件名：deploy-multi-cloud-infra.sh
# 功能：部署多云基础设施资源
set -e
REPO_ROOT=$(git rev-parse --show-toplevel)
INFRA_DIR=”${REPO_ROOT}/infrastructure”
echo “==> 部署多云基础设施资源”
# 1. 部署AWS资源
echo “==> 部署AWS资源”
kubectl apply -f ${INFRA_DIR}/aws/vpc.yaml
kubectl apply -f ${INFRA_DIR}/aws/subnets.yaml
kubectl apply -f ${INFRA_DIR}/aws/rds.yaml
kubectl apply -f ${INFRA_DIR}/aws/s3.yaml
# 2. 部署Azure资源
echo “==> 部署Azure资源”
kubectl apply -f ${INFRA_DIR}/azure/resource-group.yaml
kubectl apply -f ${INFRA_DIR}/azure/vnet.yaml
kubectl apply -f ${INFRA_DIR}/azure/postgresql.yaml
kubectl apply -f ${INFRA_DIR}/azure/storage-account.yaml
# 3. 等待资源就绪
echo “==> 等待资源就绪”
kubectl wait --for=condition=Ready \
--timeout=600s \
-l crossplane.io/claim-namespace=default \
managed
# 4. 验证资源状态
echo “==> 验证资源状态”
kubectl get managed -o wide
echo “==> 部署完成”
3.2 实际应用案例
案例一：自服务数据库申请
场景描述：开发团队需要为新项目申请PostgreSQL数据库，通过声明式方式自助申请，运维团队通过Composition控制资源规格和安全策略。
实现步骤：
- 开发团队创建数据库申请：
# 文件路径：apps/my-app/database-claim.yaml
apiVersion: database.example.com/v1alpha1
kind: PostgreSQLInstance
metadata:
name: my-app-db
namespace: my-app
spec:
parameters:
storageGB: 50
instanceClass: db.t3.medium
engine: “14.5”
writeConnectionSecretToRef:
name: my-app-db-conn
- 提交到Git并等待ArgoCD同步：
git add apps/my-app/database-claim.yaml
git commit -m “Add database for my-app”
git push
# ArgoCD自动同步后，Crossplane创建实际的RDS实例
- 应用读取连接信息：
# 文件路径：apps/my-app/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
namespace: my-app
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: app
image: my-app:v1.0.0
env:
- name: DB_HOST
valueFrom:
secretKeyRef:
name: my-app-db-conn
key: endpoint
- name: DB_PORT
valueFrom:
secretKeyRef:
name: my-app-db-conn
key: port
- name: DB_USER
valueFrom:
secretKeyRef:
name: my-app-db-conn
key: username
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: my-app-db-conn
key: password
运行结果：
# 查看数据库实例状态
$ kubectl get postgresqlinstance -n my-app
NAME READY CONNECTION-SECRET AGE
my-app-db True my-app-db-conn 5m
# 查看底层AWS资源
$ kubectl get instance.rds.aws.upbound.io
NAME READY SYNCED EXTERNAL-NAME AGE
my-app-db-rdsinstance True True my-app-db-20240115 5m
# 应用成功连接数据库
$ kubectl logs -n my-app deployment/my-app
2024-01-15 10:30:15 INFO Connected to database: my-app-db-20240115.xxxxx.us-east-1.rds.amazonaws.com:5432
案例二：多集群应用分发
场景描述：需要将同一应用部署到10个不同的Kubernetes集群，每个集群使用不同的配置参数。
实现代码：
# 文件路径：apps/argocd-apps/multi-cluster-deployment.yaml
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: nginx-multi-cluster
namespace: argocd
spec:
generators:
- matrix:
generators:
- git:
repoURL: https://github.com/your-org/gitops-infra.git
revision: main
directories:
- path: apps/nginx/overlays/*
- list:
elements:
- cluster: prod-us-east-1
url: https://prod-us-east-1.k8s.local
replicas: “5”
- cluster: prod-us-west-2
url: https://prod-us-west-2.k8s.local
replicas: “5”
- cluster: prod-eu-west-1
url: https://prod-eu-west-1.k8s.local
replicas: “3”
- cluster: staging-us-east-1
url: https://staging-us-east-1.k8s.local
replicas: “2”
template:
metadata:
name: 'nginx-{{cluster}}'
labels:
app: nginx
cluster: '{{cluster}}'
spec:
project: default
source:
repoURL: https://github.com/your-org/gitops-infra.git
targetRevision: main
path: '{{path}}'
kustomize:
commonLabels:
cluster: '{{cluster}}'
replicas:
- name: nginx
count: '{{replicas}}'
destination:
server: '{{url}}'
namespace: nginx
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
- CreateNamespace=true
ignoreDifferences:
- group: apps
kind: Deployment
jsonPointers:
- /spec/replicas
运行结果：
$ argocd app list | grep nginx
nginx-prod-us-east-1 https://prod-us-east-1.k8s.local nginx Synced Healthy
nginx-prod-us-west-2 https://prod-us-west-2.k8s.local nginx Synced Healthy
nginx-prod-eu-west-1 https://prod-eu-west-1.k8s.local nginx Synced Healthy
nginx-staging-us-east-1 https://staging-us-east-1.k8s.local nginx Synced Healthy
# 所有集群的nginx应用都已成功部署并保持同步
四、最佳实践和注意事项
4.1 最佳实践
4.1.1 性能优化
-
优化点一：ArgoCD同步性能优化
在实际生产环境中，我们发现当管理的Application数量超过100个时，ArgoCD的同步性能会明显下降。通过以下优化可以显著提升性能：
# 文件路径：argocd-config/argocd-cm.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: argocd-cm
namespace: argocd
data:
# 增加并发同步数量
application.sync.concurrency: “20”
# 减少资源缓存刷新频率
timeout.reconciliation: “300s”
# 启用资源缓存
resource.customizations.health.argoproj.io_Application: |
hs = {}
hs.status = “Progressing”
hs.message = “”
if obj.status ~= nil then
if obj.status.health ~= nil then
hs.status = obj.status.health.status
if obj.status.health.message ~= nil then
hs.message = obj.status.health.message
end
end
end
return hs
# 调整ArgoCD Server资源限制
kubectl patch deployment argocd-server -n argocd --patch '
spec:
template:
spec:
containers:
- name: argocd-server
resources:
requests:
cpu: “1000m”
memory: “2Gi”
limits:
cpu: “2000m”
memory: “4Gi”
'
-
优化点二：Crossplane Provider资源优化
Crossplane Provider在管理大量资源时会消耗较多内存，需要合理配置资源限制：
# 文件路径：infrastructure/providers/provider-config.yaml
apiVersion: pkg.crossplane.io/v1alpha1
kind: ControllerConfig
metadata:
name: aws-provider-config
spec:
resources:
limits:
cpu: “1000m”
memory: “2Gi”
requests:
cpu: “500m”
memory: “1Gi”
args:
- --poll=5m
- --max-reconcile-rate=50
---
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
name: provider-aws
spec:
package: xpkg.upbound.io/upbound/provider-aws:v0.41.0
controllerConfigRef:
name: aws-provider-config
-
优化点三：Git仓库结构优化
合理的仓库结构可以提升ArgoCD的同步效率和团队协作效率：
gitops-infra/
├── apps/
│ ├── base/ # 基础配置
│ ├── overlays/
│ │ ├── dev/ # 开发环境
│ │ ├── staging/ # 测试环境
│ │ └── prod/ # 生产环境
│ └── argocd-apps/ # ArgoCD Application定义
├── infrastructure/
│ ├── compositions/ # Crossplane Composition
│ ├── providers/ # Provider配置
│ ├── aws/ # AWS资源
│ ├── azure/ # Azure资源
│ └── gcp/ # GCP资源
└── clusters/
├── prod-us-east-1/ # 集群特定配置
├── prod-us-west-2/
└── staging/
4.1.2 安全加固
-
安全措施一：密钥管理
使用Sealed Secrets或External Secrets Operator管理敏感信息，避免明文存储在Git中：
# 安装Sealed Secrets
kubectl apply -f https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.24.0/controller.yaml
# 创建加密的Secret
echo -n “my-secret-password” | kubectl create secret generic db-password \
--dry-run=client \
--from-file=password=/dev/stdin \
-o yaml | \
kubeseal -o yaml > sealed-db-password.yaml
# 提交加密后的Secret到Git
git add sealed-db-password.yaml
git commit -m “Add sealed database password”
git push
# 文件路径：infrastructure/providers/aws-provider-sealed.yaml
apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
name: aws-credentials
namespace: crossplane-system
spec:
encryptedData:
credentials: AgBxxx...encrypted-data...xxx
template:
metadata:
name: aws-credentials
namespace: crossplane-system
type: Opaque
-
安全措施二：RBAC权限最小化
为不同团队配置最小权限原则：
# 文件路径：apps/argocd-apps/rbac-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: argocd-rbac-cm
namespace: argocd
data:
policy.csv: |
# 基础设施团队：完全访问权限
p, role:infra-admin, applications, *, */*, allow
p, role:infra-admin, clusters, *, *, allow
p, role:infra-admin, repositories, *, *, allow
g, infra-team, role:infra-admin
# 开发团队：只能管理应用，不能修改基础设施
p, role:developer, applications, get, */*, allow
p, role:developer, applications, sync, apps/*, allow
p, role:developer, applications, create, apps/*, allow
p, role:developer, applications, update, apps/*, allow
g, dev-team, role:developer
# 只读用户：只能查看
p, role:readonly, applications, get, */*, allow
p, role:readonly, clusters, get, *, allow
g, readonly-users, role:readonly
policy.default: role:readonly
-
安全措施三：网络策略隔离
# 文件路径：infrastructure/network-policies/crossplane-netpol.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: crossplane-system-netpol
namespace: crossplane-system
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
ingress:
- from:
- namespaceSelector:
matchLabels:
name: argocd
egress:
- to:
- namespaceSelector: {}
ports:
- protocol: TCP
port: 443 # 允许访问云服务商API
- to:
- namespaceSelector:
matchLabels:
name: kube-system
ports:
- protocol: TCP
port: 53 # 允许DNS查询
4.1.3 高可用配置
-
HA方案一：ArgoCD高可用部署
# 文件路径：argocd-config/argocd-ha-values.yaml
# Helm values for HA deployment
redis-ha:
enabled: true
haproxy:
enabled: true
replicas: 3
controller:
replicas: 2
resources:
requests:
cpu: 1000m
memory: 2Gi
limits:
cpu: 2000m
memory: 4Gi
server:
replicas: 3
autoscaling:
enabled: true
minReplicas: 3
maxReplicas: 10
targetCPUUtilizationPercentage: 70
resources:
requests:
cpu: 500m
memory: 1Gi
limits:
cpu: 1000m
memory: 2Gi
repoServer:
replicas: 3
autoscaling:
enabled: true
minReplicas: 3
maxReplicas: 10
targetCPUUtilizationPercentage: 70
resources:
requests:
cpu: 500m
memory: 1Gi
limits:
cpu: 1000m
memory: 2Gi
-
HA方案二：Crossplane多副本部署
# 升级Crossplane为HA模式
helm upgrade crossplane \
--namespace crossplane-system \
crossplane-stable/crossplane \
--set replicas=3 \
--set leaderElection=true \
--set args[0]=”--enable-composition-revisions” \
--set args[1]=”--enable-leader-election”
-
备份策略：定期备份关键资源
#!/bin/bash
# 文件名：backup-gitops.sh
# 功能：备份GitOps关键资源
BACKUP_DIR=”/backup/gitops/$(date +%Y%m%d)”
mkdir -p ${BACKUP_DIR}
# 备份ArgoCD Applications
kubectl get applications -n argocd -o yaml > ${BACKUP_DIR}/argocd-apps.yaml
# 备份Crossplane资源
kubectl get compositeresourcedefinitions -o yaml > ${BACKUP_DIR}/xrds.yaml
kubectl get compositions -o yaml > ${BACKUP_DIR}/compositions.yaml
kubectl get providers -o yaml > ${BACKUP_DIR}/providers.yaml
# 备份到S3
aws s3 sync ${BACKUP_DIR} s3://my-backup-bucket/gitops/$(date +%Y%m%d)/
echo “Backup completed: ${BACKUP_DIR}”
4.2 注意事项
4.2.1 配置注意事项
⚠️ 警告：以下配置错误可能导致生产环境故障，请务必注意！
-
❗ 注意事项一：避免自动Prune误删资源
在生产环境中，我们曾遇到过因为Git仓库误删文件导致ArgoCD自动删除生产数据库的事故。建议：
# 对于关键资源，禁用自动prune
syncPolicy:
automated:
prune: false # 手动确认删除
selfHeal: true
syncOptions:
- PruneLast=true # 最后删除资源，避免依赖问题
-
❗ 注意事项二：Crossplane资源删除保护
Crossplane默认会在删除Kubernetes资源时同步删除云资源，这在生产环境非常危险：
# 为关键资源添加删除保护
apiVersion: rds.aws.upbound.io/v1beta1
kind: Instance
metadata:
name: prod-database
annotations:
crossplane.io/external-name: prod-db-instance
spec:
deletionPolicy: Orphan # 删除K8s资源时保留云资源
forProvider:
skipFinalSnapshot: false # 删除前创建快照
finalSnapshotIdentifier: prod-db-final-snapshot
-
❗ 注意事项三：Git仓库权限控制
Git仓库是基础设施的单一事实来源，必须严格控制权限：
- 启用分支保护，main分支只允许通过PR合并
- 要求至少2人Review才能合并
- 启用Commit签名验证
- 定期审计Git访问日志
4.2.2 常见错误
| 错误现象 |
原因分析 |
解决方案 |
| ArgoCD同步卡在Progressing状态 |
资源健康检查配置不正确或资源依赖未就绪 |
检查资源状态：kubectl describe app <app-name> -n argocd，调整健康检查配置或添加sync waves |
| Crossplane资源一直处于Creating状态 |
Provider权限不足或云API限流 |
检查Provider日志：kubectl logs -n crossplane-system -l pkg.crossplane.io/provider=provider-aws，验证IAM权限 |
| Application显示OutOfSync但实际已同步 |
ignoreDifferences配置不当或资源被外部修改 |
添加ignoreDifferences规则或启用selfHeal自动修复 |
| Git仓库无法访问 |
SSH密钥过期或网络问题 |
更新Git凭证：argocd repo add <repo-url> --ssh-private-key-path ~/.ssh/id_rsa |
| Crossplane Provider安装失败 |
镜像拉取失败或CRD冲突 |
检查镜像仓库访问，清理旧版本CRD：kubectl delete crd -l crossplane.io/provider=provider-aws |
4.2.3 兼容性问题
- 版本兼容：
- ArgoCD 2.8+ 需要 Kubernetes 1.24+
- Crossplane 1.14+ 需要 Kubernetes 1.21+
- 不同Provider版本对云API的支持不同，升级前需查看Release Notes
- ArgoCD ApplicationSet需要ArgoCD 2.6+
- 平台兼容：
- AWS Provider在中国区域需要特殊配置endpoint
- Azure Provider需要注意订阅配额限制
- GCP Provider需要启用相应的API服务
- 某些云资源（如RDS）创建时间较长（10-30分钟），需要调整超时时间
- 组件依赖：
- Crossplane依赖cert-manager进行Webhook证书管理
- ArgoCD Notifications需要额外安装通知服务
- 使用ApplicationSet的Git Generator需要配置Git访问权限
- Sealed Secrets需要在集群中安装controller
五、故障排查和监控
5.1 故障排查
5.1.1 日志查看
# 查看ArgoCD Application Controller日志
kubectl logs -n argocd -l app.kubernetes.io/name=argocd-application-controller --tail=100 -f
# 查看ArgoCD Server日志
kubectl logs -n argocd -l app.kubernetes.io/name=argocd-server --tail=100 -f
# 查看Crossplane核心组件日志
kubectl logs -n crossplane-system deployment/crossplane --tail=100 -f
# 查看特定Provider日志
kubectl logs -n crossplane-system -l pkg.crossplane.io/provider=provider-aws --tail=100 -f
# 查看特定资源的事件
kubectl describe application infrastructure -n argocd
kubectl describe bucket my-bucket
# 导出完整日志用于分析
kubectl logs -n argocd -l app.kubernetes.io/name=argocd-application-controller --since=1h > argocd-controller.log
5.1.2 常见问题排查
问题一：ArgoCD Application一直处于Progressing状态
# 诊断步骤
# 1. 查看Application详细状态
kubectl get application infrastructure -n argocd -o yaml
# 2. 查看同步操作历史
argocd app get infrastructure --show-operation
# 3. 检查资源健康状态
kubectl get application infrastructure -n argocd -o jsonpath='{.status.resources.health.status}'
# 4. 查看具体失败的资源
argocd app resources infrastructure | grep -v Synced
解决方案：
-
如果是资源依赖问题，使用Sync Waves控制顺序：
metadata:
annotations:
argocd.argoproj.io/sync-wave: “1” # 数字越小越先同步
-
如果是健康检查问题，自定义健康检查逻辑：
# argocd-cm ConfigMap
resource.customizations.health.rds.aws.upbound.io_Instance: |
hs = {}
if obj.status ~= nil then
if obj.status.conditions ~= nil then
for i, condition in ipairs(obj.status.conditions) do
if condition.type == “Ready” and condition.status == “True” then
hs.status = “Healthy”
hs.message = “RDS instance is ready”
return hs
end
end
end
end
hs.status = “Progressing”
hs.message = “Waiting for RDS instance”
return hs
问题二：Crossplane资源创建失败
# 诊断命令
# 1. 查看资源状态
kubectl get managed -o wide
# 2. 查看资源详细信息
kubectl describe bucket my-bucket
# 3. 查看Provider日志
kubectl logs -n crossplane-system -l pkg.crossplane.io/provider=provider-aws | grep -i error
# 4. 检查Provider配置
kubectl get providerconfig default -o yaml
解决方案：
常见错误及处理：
- 权限不足：检查IAM角色权限，确保包含所需的API权限
- 配额限制：联系云服务商提升配额或删除不用的资源
- 资源命名冲突：检查是否已存在同名资源
- 网络问题：验证集群到云API的网络连通性
# 验证AWS凭证
kubectl exec -n crossplane-system deployment/provider-aws-xxx -- aws sts get-caller-identity
# 测试API访问
kubectl exec -n crossplane-system deployment/provider-aws-xxx -- aws s3 ls
问题三：Git同步失败
# 诊断命令
# 1. 测试Git连接
argocd repo get https://github.com/your-org/gitops-infra.git
# 2. 查看仓库凭证
kubectl get secret -n argocd -l argocd.argoproj.io/secret-type=repository
# 3. 手动触发同步并查看错误
argocd app sync infrastructure --prune --force
解决方案：
# 更新Git凭证（SSH方式）
argocd repo add git@github.com:your-org/gitops-infra.git \
--ssh-private-key-path ~/.ssh/id_rsa
# 更新Git凭证（HTTPS方式）
argocd repo add https://github.com/your-org/gitops-infra.git \
--username your-username \
--password your-token
# 如果是自签名证书问题
argocd repo add https://gitlab.internal.com/gitops-infra.git \
--insecure-skip-server-verification
5.1.3 调试模式
# 启用ArgoCD调试日志
kubectl patch configmap argocd-cmd-params-cm -n argocd --patch '
data:
application.controller.log.level: “debug”
server.log.level: “debug”
'
# 重启组件使配置生效
kubectl rollout restart deployment argocd-application-controller -n argocd
kubectl rollout restart deployment argocd-server -n argocd
# 启用Crossplane调试日志
kubectl patch deployment crossplane -n crossplane-system --patch '
spec:
template:
spec:
containers:
- name: crossplane
args:
- --debug
- --enable-composition-revisions
'
# 查看详细的reconcile日志
kubectl logs -n crossplane-system deployment/crossplane -f | grep -i “reconcile”
5.2 性能监控
5.2.1 关键指标监控
# ArgoCD性能指标
kubectl port-forward -n argocd svc/argocd-metrics 8082:8082
curl http://localhost:8082/metrics | grep argocd
# Crossplane性能指标
kubectl port-forward -n crossplane-system svc/crossplane 8080:8080
curl http://localhost:8080/metrics | grep crossplane
# 查看资源使用情况
kubectl top pods -n argocd
kubectl top pods -n crossplane-system
# 查看Application同步时间
argocd app list -o json | jq '.[] | {name: .metadata.name, syncTime: .status.operationState.finishedAt}'
5.2.2 监控指标说明
| 指标名称 |
正常范围 |
告警阈值 |
说明 |
| argocd_app_sync_total |
- |
- |
Application同步总次数 |
| argocd_app_reconcile_duration_seconds |
< 30s |
> 60s |
Application reconcile耗时 |
| crossplane_managed_resource_exists |
1 |
0 |
托管资源是否存在 |
| crossplane_managed_resource_ready |
1 |
0 |
托管资源是否就绪 |
| argocd_redis_request_duration |
< 100ms |
> 500ms |
Redis请求延迟 |
| controller_runtime_reconcile_errors_total |
0 |
> 10/min |
Reconcile错误数 |
5.2.3 Prometheus监控配置
# 文件路径：monitoring/servicemonitor.yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: argocd-metrics
namespace: argocd
spec:
selector:
matchLabels:
app.kubernetes.io/name: argocd-metrics
endpoints:
- port: metrics
interval: 30s
---
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: crossplane-metrics
namespace: crossplane-system
spec:
selector:
matchLabels:
app: crossplane
endpoints:
- port: metrics
interval: 30s
---
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: gitops-alerts
namespace: monitoring
spec:
groups:
- name: argocd
interval: 30s
rules:
- alert: ArgoCDAppSyncFailed
expr: argocd_app_sync_total{phase=”Failed”} > 0
for: 5m
labels:
severity: warning
annotations:
summary: “ArgoCD Application同步失败”
description: “Application {{ $labels.name }} 同步失败”
- alert: ArgoCDAppOutOfSync
expr: argocd_app_info{sync_status=”OutOfSync”} > 0
for: 15m
labels:
severity: warning
annotations:
summary: “ArgoCD Application未同步”
description: “Application {{ $labels.name }} 已15分钟未同步”
- name: crossplane
interval: 30s
rules:
- alert: CrossplaneResourceNotReady
expr: crossplane_managed_resource_ready == 0
for: 10m
labels:
severity: critical
annotations:
summary: “Crossplane资源未就绪”
description: “资源 {{ $labels.name }} 已10分钟未就绪”
5.3 备份与恢复
5.3.1 备份策略
#!/bin/bash
# 文件名：backup-gitops-full.sh
# 功能：完整备份GitOps环境
set -e
BACKUP_ROOT=”/backup/gitops”
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
BACKUP_DIR=”${BACKUP_ROOT}/${TIMESTAMP}”
mkdir -p ${BACKUP_DIR}/{argocd,crossplane,git}
echo “==> 开始备份 GitOps 环境: ${TIMESTAMP}”
# 1. 备份ArgoCD配置
echo “==> 备份ArgoCD配置”
kubectl get applications -n argocd -o yaml > ${BACKUP_DIR}/argocd/applications.yaml
kubectl get appprojects -n argocd -o yaml > ${BACKUP_DIR}/argocd/appprojects.yaml
kubectl get configmaps -n argocd -o yaml > ${BACKUP_DIR}/argocd/configmaps.yaml
kubectl get secrets -n argocd -o yaml > ${BACKUP_DIR}/argocd/secrets.yaml
# 2. 备份Crossplane资源
echo “==> 备份Crossplane资源”
kubectl get providers -o yaml > ${BACKUP_DIR}/crossplane/providers.yaml
kubectl get providerconfigs -o yaml > ${BACKUP_DIR}/crossplane/providerconfigs.yaml
kubectl get compositeresourcedefinitions -o yaml > ${BACKUP_DIR}/crossplane/xrds.yaml
kubectl get compositions -o yaml > ${BACKUP_DIR}/crossplane/compositions.yaml
kubectl get managed -o yaml > ${BACKUP_DIR}/crossplane/managed-resources.yaml
# 3. 备份Git仓库
echo “==> 备份Git仓库”
cd /tmp
git clone --mirror https://github.com/your-org/gitops-infra.git ${BACKUP_DIR}/git/gitops-infra.git
# 4. 压缩备份
echo “==> 压缩备份文件”
cd ${BACKUP_ROOT}
tar -czf gitops-backup-${TIMESTAMP}.tar.gz ${TIMESTAMP}/
# 5. 上传到S3
echo “==> 上传到S3”
aws s3 cp gitops-backup-${TIMESTAMP}.tar.gz s3://my-backup-bucket/gitops/
# 6. 清理本地旧备份（保留最近7天）
find ${BACKUP_ROOT} -name “gitops-backup-*.tar.gz” -mtime +7 -delete
find ${BACKUP_ROOT} -maxdepth 1 -type d -mtime +7 -exec rm -rf {} \;
echo “==> 备份完成: ${BACKUP_DIR}”
5.3.2 恢复流程
-
停止服务：
# 停止ArgoCD自动同步
kubectl patch application infrastructure -n argocd --type merge -p '{"spec":{"syncPolicy":{"automated":null}}}'
# 缩容Crossplane（可选）
kubectl scale deployment crossplane -n crossplane-system --replicas=0
-
恢复数据：
# 下载备份
aws s3 cp s3://my-backup-bucket/gitops/gitops-backup-20240115-120000.tar.gz .
tar -xzf gitops-backup-20240115-120000.tar.gz
# 恢复ArgoCD配置
kubectl apply -f 20240115-120000/argocd/applications.yaml
kubectl apply -f 20240115-120000/argocd/appprojects.yaml
# 恢复Crossplane资源
kubectl apply -f 20240115-120000/crossplane/providers.yaml
kubectl apply -f 20240115-120000/crossplane/providerconfigs.yaml
kubectl apply -f 20240115-120000/crossplane/xrds.yaml
kubectl apply -f 20240115-120000/crossplane/compositions.yaml
-
验证完整性：
# 验证ArgoCD Applications
kubectl get applications -n argocd
argocd app list
# 验证Crossplane资源
kubectl get providers
kubectl get managed
# 验证云资源状态
kubectl describe bucket my-bucket
-
重启服务：
# 恢复Crossplane
kubectl scale deployment crossplane -n crossplane-system --replicas=1
# 恢复ArgoCD自动同步
kubectl patch application infrastructure -n argocd --type merge -p '{"spec":{"syncPolicy":{"automated":{"prune":true,"selfHeal":true}}}}'
六、总结
6.1 技术要点回顾
- ✅ GitOps核心理念：通过Git作为单一事实来源，实现基础设施和应用的声明式管理，所有变更都通过Git提交和PR流程，确保可追溯性和审计能力
- ✅ ArgoCD多集群管理：利用ApplicationSet实现大规模集群的统一管理，通过自动同步和自愈机制保证集群状态与Git仓库一致，支持灵活的同步策略和健康检查
- ✅ Crossplane资源抽象：将云资源抽象为Kubernetes CRD，通过Composition实现可复用的基础设施模板，开发团队可以自助申请资源而运维团队保持控制权
- ✅ 安全最佳实践：使用Sealed Secrets管理敏感信息，实施RBAC权限最小化原则，为关键资源配置删除保护，通过网络策略实现组件隔离
- ✅ 高可用架构：ArgoCD和Crossplane都支持多副本部署和Leader Election，配合定期备份策略确保系统的可靠性和可恢复性
- ✅ 监控和告警：通过Prometheus采集关键指标，配置合理的告警规则，及时发现同步失败、资源未就绪等问题，保障系统稳定运行
6.2 进阶学习方向
-
方向一：高级GitOps模式
深入学习GitOps的高级实践，包括：
学习资源：
- ArgoCD官方文档 - Best Practices
- GitOps Working Group
实践建议：在测试环境搭建完整的Progressive Delivery流水线，体验自动化的金丝雀发布流程
- Progressive Delivery（渐进式交付）：结合Flagger实现金丝雀发布和蓝绿部署
- Multi-tenancy（多租户）：使用ArgoCD Projects和Kubernetes Namespaces实现租户隔离
- Policy as Code：集成OPA（Open Policy Agent）实现策略即代码
-
方向二：Crossplane高级特性
掌握Crossplane的企业级应用：
学习资源：
- Crossplane官方文档
- Upbound官方博客
实践建议：尝试为公司内部的CMDB或工单系统开发Crossplane Provider
- Composition Functions：使用Go或Python编写自定义的Composition逻辑
- Provider开发：为内部系统开发自定义Provider
- Configuration Packages：打包和分发可复用的基础设施配置
-
方向三：云原生安全加固
提升GitOps环境的安全性：
学习资源：
- CNCF Security TAG
- Kubernetes Security Best Practices
实践建议：在生产环境实施完整的镜像签名验证流程
- Supply Chain Security：使用Sigstore/Cosign对容器镜像和Helm Chart进行签名验证
- Secret Management：集成HashiCorp Vault或AWS Secrets Manager
- Compliance Automation：使用Kyverno或OPA Gatekeeper实现合规性自动化检查
6.3 参考资料
附录
A. 命令速查表
# ArgoCD常用命令
argocd login <server-url> # 登录ArgoCD
argocd app list # 列出所有Application
argocd app get <app-name> # 查看Application详情
argocd app sync <app-name> # 手动同步Application
argocd app history <app-name> # 查看同步历史
argocd app rollback <app-name> <revision> # 回滚到指定版本
argocd app diff <app-name> # 查看差异
argocd app set <app-name> --sync-policy automated # 设置自动同步
argocd cluster add <context-name> # 添加集群
argocd cluster list # 列出所有集群
argocd repo add <repo-url> # 添加Git仓库
# Crossplane常用命令
kubectl get providers # 查看已安装的Provider
kubectl get providerconfigs # 查看Provider配置
kubectl get compositeresourcedefinitions # 查看XRD定义
kubectl get compositions # 查看Composition
kubectl get managed # 查看所有托管资源
kubectl get <resource-type> # 查看特定类型资源
kubectl describe <resource-type> <name> # 查看资源详情
kubectl crossplane install provider <provider-name> # 安装Provider（需要kubectl插件）
# Kubernetes常用命令
kubectl get pods -n <namespace> # 查看Pod
kubectl logs -n <namespace> <pod-name> -f # 查看日志
kubectl describe <resource-type> <name> # 查看资源详情
kubectl get events -n <namespace> --sort-by=’.lastTimestamp’ # 查看事件
kubectl top pods -n <namespace> # 查看资源使用
B. 配置参数详解
ArgoCD Application核心参数：
| 参数路径 |
类型 |
默认值 |
说明 |
| spec.source.repoURL |
string |
- |
Git仓库URL |
| spec.source.targetRevision |
string |
HEAD |
目标分支或Tag |
| spec.source.path |
string |
- |
仓库中的路径 |
| spec.destination.server |
string |
- |
目标集群API地址 |
| spec.destination.namespace |
string |
- |
目标命名空间 |
| spec.syncPolicy.automated.prune |
boolean |
false |
自动删除Git中不存在的资源 |
| spec.syncPolicy.automated.selfHeal |
boolean |
false |
自动修复漂移 |
| spec.syncPolicy.automated.allowEmpty |
boolean |
false |
允许空目录同步 |
| spec.syncPolicy.syncOptions |
array |
[] |
同步选项（CreateNamespace等） |
| spec.syncPolicy.retry.limit |
integer |
5 |
同步失败重试次数 |
Crossplane Composition核心参数：
| 参数路径 |
类型 |
说明 |
| spec.compositeTypeRef |
object |
引用的XRD类型 |
| spec.resources[].name |
string |
资源名称（内部标识） |
| spec.resources[].base |
object |
资源基础配置 |
| spec.resources[].patches |
array |
字段映射和转换规则 |
| spec.resources[].connectionDetails |
array |
连接信息导出配置 |
| spec.writeConnectionSecretsToNamespace |
string |
Secret写入的命名空间 |
C. 术语表
| 术语 |
英文 |
解释 |
| GitOps |
GitOps |
一种持续交付方式，使用Git作为声明式基础设施和应用的单一事实来源 |
| 声明式 |
Declarative |
描述期望的最终状态，而非执行步骤 |
| 漂移检测 |
Drift Detection |
检测实际状态与期望状态的偏差 |
| 自愈 |
Self-Healing |
自动修复检测到的漂移，使实际状态回归期望状态 |
| 同步策略 |
Sync Policy |
定义如何将Git中的配置同步到集群 |
| 托管资源 |
Managed Resource |
Crossplane管理的云资源，对应云服务商的实际资源 |
| 组合资源 |
Composite Resource |
由多个托管资源组合而成的高级抽象 |
| 资源声明 |
Claim |
用户申请资源的声明，类似PVC |
| Provider |
Provider |
Crossplane中连接云服务商的组件 |
| Composition |
Composition |
定义如何将XRD转换为实际的托管资源 |
| XRD |
Composite Resource Definition |
组合资源定义，类似Kubernetes的CRD |
| ApplicationSet |
ApplicationSet |
ArgoCD中用于批量管理Application的资源 |
| Sync Wave |
Sync Wave |
控制资源同步顺序的机制 |
| Health Check |
Health Check |
检查资源是否健康的逻辑 |
| Prune |
Prune |
删除Git中不存在但集群中存在的资源 |
本文详细介绍了基于ArgoCD与Crossplane的GitOps 2.0实践，涵盖了从概念、部署、配置到运维监控的完整流程。希望这份指南能帮助您在复杂的云原生/IaaS环境中构建稳定、高效的基础设施即代码体系。想了解更多关于运维/DevOps/SRE的最佳实践，欢迎访问云栈社区交流探讨。
发表于 15 小时前
|
查看: 2|
回复: 0
