本页介绍了舰队软件包、FleetPackage
API 以及它们与 Config Sync 的关系。
FleetPackage
是一种声明式 API,可让您管理整个车队中的软件包。车队软件包是一组用于定义集群配置的 Kubernetes YAML 清单。通过使用舰队软件包,您可以通过一次性或渐进式发布将软件包部署到已注册到舰队的集群。
您只需定义每个 FleetPackage
对象一次,然后就可以使用新修订版本更新该软件包。当您应用新修订版本时,舰队软件包服务会提取这些更改并将其部署到您的集群。
优势
使用舰队软件包跨已注册到舰队的集群部署 Kubernetes 资源。创建并应用舰队软件包后,舰队软件包会自动将 Git 代码库中的 Kubernetes 配置文件部署到新集群。舰队软件包基于 Config Sync 的优势(例如自动偏差修正)构建,并提供以下独特优势:
自动部署资源:设置舰队软件包后,舰队软件包服务会在所有集群上自动部署其指向的 Kubernetes 资源。
自动配置新集群:如果您配置了舰队软件包,然后稍后向舰队添加了新集群,则舰队软件包定义的任何资源都会自动部署到新集群。
大规模管理 Kubernetes 配置:使用舰队软件包将资源部署到整个舰队集群,而不是逐个管理集群。
最大限度地减少错误更改的影响:选择一次最多部署到多少个集群。您可以密切监控每个集群的更改,确保不正确的更改不会影响整个车队。
简化了 Config Sync 配置:舰队软件包使用 Cloud Build 向 Git 进行身份验证,这意味着您只需为每个项目进行一次身份验证,而不是为每个
RootSync
或RepoSync
对象进行一次身份验证。
如果您遇到以下一种或多种情况,则可能更倾向于将 Config Sync 与 RootSync
或 RepoSync
对象搭配使用,而不是与舰队软件包搭配使用:
您管理的集群数量较少。
除了使用标签和变体通过车队软件包 API 部署资源之外,您还需要更好地控制资源部署到集群的方式。
要求和限制
在配置舰队软件包时,仅支持将 Git 代码库用作可靠来源。
存储在 Git 中的 Kubernetes 资源必须代表资源的最终状态。不支持用于转换存储在 Git 中的资源的其他叠加层。如需详细了解这些资源之间的差异,请参阅最佳实践:创建 WET 代码库。
FleetPackage
API 仅在us-central1
区域提供。您仍然可以部署到不同区域中的集群,但必须在us-central1
中设置 Cloud Build 并配置 gcloud CLI。
架构
您可以使用 FleetPackage
API 将 Kubernetes 清单部署到集群舰队。FleetPackage
API 使用 Cloud Build 从您的 Git 代码库同步和提取 Kubernetes 资源。然后,舰队软件包服务会将这些资源部署到您的集群。
应用场景示例
您可以使用舰队软件包将资源从 Git 代码库部署到整个舰队集群。您还可以配置舰队软件包,以控制资源的部署方式、部署位置和类型。
以下部分显示了不同 FleetPackage
配置的示例。如需详细了解如何应用车队软件包,请参阅部署车队软件包。
部署到舰队中的所有集群
以下 FleetPackage
使用滚动策略一次将 Kubernetes 资源部署到三个集群,并定位到舰队中的所有集群:
resourceBundleSelector:
cloudBuildRepository:
name: projects/my-project/locations/us-central1/connections/my-connection/repositories/my-repo
tag: v1.0.0
serviceAccount: projects/my-project/serviceAccounts/my-service-account@my-project.iam.gserviceaccount.com
target:
fleet:
project: projects/my-project
rolloutStrategy:
rolling:
maxConcurrent: 3
部署到部分集群
以下 FleetPackage
使用标签选择器仅将 Kubernetes 资源部署到舰队中成员资格标签 country
与 "us"
匹配的集群:
resourceBundleSelector:
cloudBuildRepository:
name: projects/my-project/locations/us-central1/connections/my-connection/repositories/my-repo
tag: v1.0.0
serviceAccount: projects/my-project/serviceAccounts/my-service-account@my-project.iam.gserviceaccount.com
target:
fleet:
project: projects/my-project
selector:
matchLabels:
country: "us"
rolloutStrategy:
rolling:
maxConcurrent: 3
将变体资源部署到集群
在本示例中,您的 Git 代码库中有一个名为“deployments”的文件夹,其中包含两个不同的部署规范:
副本:3
# small.yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80
副本:10
# large.yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: replicas: 10 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80
您可以使用变体将“小型”或“大型”部署部署到不同的集群。每个集群都有一个标签,该标签为 nginx-size=small
或 nginx-size=large
。
此示例中的 FleetPackage
将类似于以下内容:
resourceBundleSelector:
cloudBuildRepository:
name: projects/my-project/locations/us-central1/connections/my-connection/repositories/my-repo
tag: v1.0.0
serviceAccount: projects/my-project/serviceAccounts/my-service-account@my-project.iam.gserviceaccount.com
path: deployments
variantsPattern: "*.yaml"
rolloutStrategy:
rolling:
maxConcurrent: 2
target:
fleet:
project: projects/my-project
variantSelector:
variantNameTemplate: ${membership.labels['nginx-size']}