关于kubernetes:Crossplane-比-Terraform-更先进的云基础架构管理平台

👉️URL: https://crossplane.io/

📝Description:

将云基础架构和服务组成自定义平台 API

简介

在 11 月的 KCD 上海现场，听了一场阿里云的工程师对于他们本人的多云基础架构管理工具的介绍，前边的引言局部有介绍到 Terraform，还有另一款竞品就是 Crossplane，而且示意 Crossplane 在通用性 API 等方面做得比 Terraform 更好，阿里云的也参考了其架构和实现。就让我很感兴趣，同时在 2019 年应用 OpenShift 4 的时候也在其 OperatorHub 里有发现 Crossplane，过后感觉其 Logo 很有辨识度便始终有印象。所以这次抽了个周末专门体验了一下，看它是否当得起这个题目。开始~

Crossplane（跨立体，意思是能够逾越多个 私有云平台）是一个开源的 Kubernetes 插件，它容许平台团队组装来自多个供应商的基础设施，并向应用程序团队公开更高级别的自助服务 api，而不须要编写任何代码。

愿景

为更凋谢的云提供能源

构建 Crossplane 是为了帮忙组织构建他们的云，就像云供应商构建他们的云一样——通过一个管制立体。Crossplane 是一个 CNCF 我的项目，它扩大了 Kubernetes API 来治理和组合基础设施。操作人员能够在 Crossplane 生成的自定义 API 线后封装策略、权限和其余防护措施，而应用程序开发人员无需成为基础设施专家就能够从 API 自助服务。

对标产品

Terraform

价值

以下是它的价值所在：

应用 kubectl 提供和治理云基础设施和服务

Crossplane 扩大您的 Kubernetes 集群，为您提供任何基础设施或托管服务的 crd。将这些细粒度资源组合成更高级别的形象，这些形象能够应用您喜爱的工具，也能够和曾经集成到集群中的现有流程进行版本治理、治理、部署和应用。

在 Crossplane 中，每个人都有本人的基础设施

Crossplane 反对来自所有次要云提供商的基础设施，社区也在一直开发新的提供商。目前反对以下支流私有云供应商：

为你的应用程序提供简化的基础架构形象

在 CRDs Crossplane 提供的根底上构建您本人的外部基础架构形象。您的自定义 api 能够蕴含策略护栏，暗藏基础设施的复杂性，并确保应用程序能够平安地应用它。

通用云 API

Crossplane 在不同的供应商、资源和形象汇合中提供统一的 API。跨立体资源模型 (XRM，Crossplane Resource Model) 以一种果断的形式扩大了 Kubernetes 资源模型(KRM)，不论是哪个供应商或供应商构建了它们都能产生了一种对立的资源管理体验。

Run Crossplane anywhere

无论您是在 EKS、AKS、GKE、ACK、PKS 中应用单个 Kubernetes 集群，还是在 Rancher 或 Anthos 等多集群管理器中应用，Crossplane 都能很好地集成它们。Crossplane 能够装置到任何现有的集群中，跨基础设施和服务提供商公开 crd 和规范 API，使供给和治理变得轻而易举。

为什么要应用 Crossplane 来管理应用程序和基础设施?

🔘 申明式基础设施配置

Crossplane 将 kubernetes 格调的申明式和 api 驱动的配置和治理引入到任何基础设施、本地和云中。通过这种办法，通过 Crossplane 治理的基础设施能够通过 kubectl 进行拜访，能够应用 YAML 进行配置，并且能够立刻自修复。

🔗 对立应用程序和基础设施的配置和部署

Crossplane 容许应用程序和基础设施配置在雷同的 Kubernetes 集群上共存，升高了工具链和部署管道的复杂性。

⚓️ 基础设施配置和设置的繁多实在起源

Crossplane 集成了 CI/CD 管道，因而应用程序基础设施配置存储在单个管制集群中。团队能够应用曾经在应用的 GitOps 最佳实际创立、跟踪和批准变更。

🔄 应用协调控制器自动化操作工作

资源控制器负责资源的整个生命周期。此资源负责供给、运行状况、扩大、故障转移，并积极响应与所需配置不统一的内部更改。

➕ 具备高水平的可扩展性

Crossplane 利用了宽泛承受的 Kubernetes 模式，通过增加本人的 api 和控制器能够轻松地扩大它。通过将策略、配额和权限打包到自定义基础设施定义中来进步灵活性和安全性。

⇅ 强烈的关注点拆散

开发人员能够定义工作负载，而不用放心实现细节、环境束缚或策略。管理员能够定义环境细节和策略。反对更高水平的可重用性并升高复杂性。

Crossplane vs Terraform

Crossplane 常常被比作 HashiCorp 的 Terraform。这两个我的项目有相似之处:

• 两者都容许工程师将其基础设施建模为申明性配置
• 两者都反对应用提供商插件治理大量不同的基础设施
• 两者都是领有弱小社区的开源工具

要害的区别是 Crossplane 是一个管制立体，而 Terraform 是一个命令行工具 —— 一个管制立体的界面。上面涉及了企业在扩大 Terraform 时常常面临的几个痛点，并强调了 Crossplane 如何解决这些问题。

合作

企业通常通过运维团队采纳 Terraform。将基础设施示意为申明性配置，能够让运维团队从软件工程的最佳实际中获益 —— 将配置保留在订正管制中，以便在必要时对更改进行同行评审和复原。

当更多的工程师须要单干治理他们组织的基础设施时，Terraform 就会解体。Terraform 依赖于一个繁多的状态文件将所需的配置映射到理论运行的基础设施。在利用配置时，这个状态文件上必须有一个锁，而利用 Terraform 配置是一个阻塞过程，可能须要几分钟能力实现。在此期间，没有其余实体 —— 没有其余工程师—— 能够对配置进行更改。相似地，Terraform 应用一个繁多的 apply 过程 —— 在一个配置中，没有举荐的办法只批改一个基础设施。如果您应用雷同的配置来治理缓存和数据库，您必须始终同时更新它们 — 您不能只更新缓存。

Terraform 倡议将单个配置合成为越来越细粒度的配置。因而，尽管运维团队可能从代表「产品（production）」的 Terraform 配置开始，但他们被激励将其纳入「产品账单（production billing）」和「产品认证（production auth）」等范畴配置中。这是很难做到的，所以它可能须要大量的重构工夫，并常常导致一个简单的网格状的 Terraform 配置耦合其输出和输入。

跨立体资源模型 (Crossplane Resource Model, XRM) 促成了涣散耦合和最终的一致性。在 Crossplane 中，基础设施的每个局部都是反对创立、读取、更新和删除操作的 API 端点。Crossplane 不须要计算依赖关系图来进行更改，因而即便应用 Crossplane 治理整个生产环境，也能够轻松地对单个数据库进行操作。

自服务

古代组织正从基础设施的集中管理倒退到自助服务模型，在这种模型中，运维团队 (通常称为平台团队) 定义了他们反对的开发团队能够按需应用的基础设施形象。Terraform 曾经通过应用模块（modules）来反对这个模型。模块与软件库没有什么不同。与 Crossplane 一样，Terraform 资源也是内部 API 资源的高保真示意。模块在这些资源的更宽泛的配置之上提供了一个简化的形象 —— 例如，RDS 模块将 8 个不同的 Terraform 资源形象为一个繁多的「RDS 实例」概念。

将利用团队视为 Terraform 配置「库」的消费者，意味着他们要受制于 Terraform 的合作束缚。应用程序开发人员被邀请在他们组织的基础设施上进行合作，就如同他们是一个关注范畴较窄的运维团队。平台团队邀请利用程序开发团队共享他们的工作流，而不是向他们提供服务。这意味着利用团队必须学习一种新的、非凡用处的工具集和语言——Terraform 和 HashiCorp 配置语言(HCL)。它还进步了应用程序开发人员的配置形象级别，而不进步访问控制形象级别。尽管平台团队能够公布一个模块，容许应用程序团队治理「RDS 实例」，但访问控制依然在云提供商 API 级别，因而围绕着「数据库子网组」和「数据库参数组」开展。

而 Crossplane 相当于一个 Terraform 模块的是一个复合资源 —— 一个 XR。每个 XR 都作为 API 端点公开。平台团队能够定义和记录每个 XR (每个 API)的 OpenAPI 模式，并在 API 级别施行基于角色的访问控制(RBAC)。这意味着, 如果一个平台团队决定框架形象它们并提供给他们的开发团队「AcmeCo PostgreSQL 数据库」，他们能够授予 RBAC 拜访创立、读取、更新或删除一个 AcmeCo PostgreSQL 数据库, 而不用治理对各种潜在的云概念, 比方 RDS 实例的拜访或子网组。因为 Crossplane 建设在通过实战历练的 Kubernetes RBAC 零碎上，平台团队能够轻松地在一个管制立体内反对多个利用程序开发团队。每个团队只能被授予拜访他们须要的形象的权限 —— 一些团队可能只能治理存储桶，而另一些团队可能被容许治理缓存和数据库。

在 Crossplane 中，自助服务的规模甚至更大，因为任何一个 XR 都能够提供多种服务。Crossplane 将 XR 的输出和输入 (Kubernetes 的说法是它的 spec 和 status) 与它的实现解耦，后者由 Composition 来形容。如果应用程序开发人员被授予创立 AcmeCo PostgreSQL 数据库的权限，他们能够很容易地从任何服务类中抉择——任何组合——他们的平台团队曾经申明与上述数据库兼容。这些服务类能够代表生产、staging 和开发; AWS、Azure 和 GCP; 快和慢; 或两者的任何组合。

集成和自动化

Terraform 有很多 api，但它不提供本人的 api。这使得许多团队将他们的 Terraform 配置提交到版本控制 (git) 中，并将 Terraform 作为 CI/CD 管道的一部分执行。绝对于一个团队在他们的笔记本电脑上运行 Terraform 来说，这是一个提高，但它裸露了组织在试图扩充 Terraform 的应用时面临的一个关键问题。Terraform 是一个命令行工具 —— 不是一个管制立体。因为它是一个短暂的、一次性的过程，所以在调用它时，它只会尝试将所需的配置与理论的基础设施协调起来。无论是从 CI/CD 管道运行还是从笔记本电脑运行，Terraform 通常只在工程师心愿基础设施须要更新时才会被调用。

Terraform 的激进的、「按需」的办法与理论的基础设施状态相协调，可能会导致新的死锁。回忆一下，利用 Terraform 配置的过程是「要么全副胜利，要么全副失败」的——如果你在雷同的配置中形容你的缓存和数据库，你必须总是同时更新它们。这意味着，如果你的组织中有人绕过 Terraform，下一个触发 Terraform 运行的人将面临一个令人诧异的打算，因为他试图撤销扭转。例如，思考这样一个场景: 工程师在中午被呼叫来解决一个事件，通过 AWS 控制台对生产缓存配置进行了一些疾速编辑，却遗记在 Terraform 中反映这些更改。基础设施漂移如此之大，以至于利用 Terraform 配置成为一个有危险的、令人生畏的命题，这并非前所未闻。

而另一方面，Crossplane 是由一系列长期运行的管制循环所组成。它一直地察看和纠正组织的基础设施，以匹配其冀望的配置，无论是否冀望更改。这妨碍了团队绕过 Crossplane。当 Crossplane 被要求治理一段基础设施时，在该基础设施之外所做的任何更改都将主动且长久地复原。

组织在应用 Terraform 时面临的一个继续的问题是它没有提供 API。与 Terraform 集成是一个挑战，因为它是应用畛域特定语言(DSL，Domain Specific Language) ——(HCL) 配置的，并通过调用命令行工具来调用。Crossplane 公开了 REST API —— 自动化的通用语言。无论团队次要编写 shell 脚本、次要编写 Python，还是次要编写 Erlang common pattern 都能够调用 REST API。

Crossplane 不公开任何旧的 REST API。在 Kubernetes API 上构建意味着团队能够应用 kubectl 这样的工具来编排他们所有的基础设施 —— 云或者其余。他们应用雷同的工具来编排他们的容器化应用程序。Crossplane 甚至能够将应用程序须要连贯到基础设施的细节作为 Kubernetes Secret 公开，以简化集成。它能够与 ArgoCD、Gatekeeper 或 Velero 等我的项目搭配应用，以启用 GitOps、高级策略和备份。须要定制的自动化? 构建本人的 Kubernetes Operator，来与 Crossplane 集成。

两者一起？

Crossplane 和 Terraform 都能够协调一个组织的基础设施。两者之间有相似之处，但每个我的项目的编排办法不同。Terraform 提供了一个命令行接口来管制立体 api，而 Crossplane 自身就是一个管制立体，能够用来在其余管制立体上构建形象。因为 Crossplane 让平台团队可能提供本人的管制立体，所以它防止了平台团队在缩放 Terraform 时所面临的许多挑战。

精明的读者可能会留神到，这两个我的项目能够互相补充——Terraform 是一个管制立体的接口，它的 Kubernetes 提供商容许编排 Kubernetes 管制立体! 这意味着能够将 Terraform 与 Crossplane 配对，例如，如果您的组织更喜爱 HCL 而不是 YAML，那么您的平台团队就能够应用 Terraform 来定义 xr 和 composition，对于您的利用团队来说，能够应用 Terraform 来布局并利用 Crossplane 所需状态的更改!

咱们认为，对于平台团队来说，Crossplane 是一种很好的形式，能够帮忙他们反对的开发人员自助服务他们的基础设施需要。

装置配置

心愿取得更多灵活性的用户能够将 Crossplane 装置到本人的 Kubernetes 集群中。

Crossplane 将应用定期公布的 Helm Chart 装置。Helm 图表蕴含部署和配置 Crossplane 所需的所有自定义资源和控制器。

将 Crossplane 装置到现有的 Kubernetes 集群中须要更多的设置，然而能够为须要它的用户提供更多的灵活性。

前提

• Kubernetes 集群
• Helm 3

装置 Crossplane

kubectl create namespace crossplane-system

helm repo add crossplane-master https://charts.crossplane.io/master/
helm repo update
helm search repo crossplane-master --devel

helm install crossplane --namespace crossplane-system crossplane-master/crossplane \
  --devel --version <version>

查看 Crossplane 状态

helm list -n crossplane-system

kubectl get all -n crossplane-system

装置 Crossplane CLI

Crossplane CLI 扩大了 kubectl 的性能，能够构建、推送和装置 Crossplane 包:

curl -sL https://raw.githubusercontent.com/crossplane/crossplane/release-1.5/install.sh | CHANNEL=master sh

抉择一个入门配置

Crossplane 超过了简略地将基础设施原语建模为自定义资源 —— 它使您可能应用您抉择的模式定义新的自定义资源。咱们称之为“复合资源”(XRs, composite resources)。复合资源组合托管资源 —— Kubernetes 自定义资源，提供基础设施原语的高保真示意，如 SQL 实例或防火墙规定.

咱们应用两个非凡的 Crossplane 资源来定义和配置这些新的自定义资源:

• 一个是 CompositeResourceDefinition (XRD) 它定义了一种新的复合资源，包含它的 schema。XRD 能够选择性地提供一项申明(XRC)。
• Composition 指定复合资源将由哪些资源组成，以及应该如何配置它们。您能够为每个复合资源创立多个 Composition 选项。

XRD 和 Composition 能够打包并作为 configuration 装置。Configuration 是一个组合配置 package，能够通过创立申明性配置资源或应用 kubectl crossplane install configuration 轻松地装置到 Crossplane。

在上面的示例中，咱们将装置一个配置，该配置定义一个新的 XPostgreSQLInstance XR 和一个承受单个 storageGB 参数的 PostgreSQLInstance XRC，并创立一个连贯 Secret，其中蕴含用户名、明码和端点的密钥。每个提供程序都有一个 Configuration，它能够满足 PostgreSQLInstance。让咱们开始吧!

装置 Configuration Package

如果您想理解这个配置包的内容以及在装置之前如何结构它，请跳到创立 Configuration 局部。

kubectl crossplane install configuration registry.upbound.io/xp/getting-started-with-aws:v1.5.1

等到所有的 package 都变得衰弱:

watch kubectl get pkg

获取 AWS 帐户密钥文件

应用 AWS 帐号治理 RDS 数据库:

AWS_PROFILE=default && echo -e "[default]\naws_access_key_id = $(aws configure get aws_access_key_id --profile $AWS_PROFILE)\naws_secret_access_key = $(aws configure get aws_secret_access_key --profile $AWS_PROFILE)" > creds.conf

创立一个 云提供商 Secret

kubectl create secret generic aws-creds -n crossplane-system --from-file=creds=./creds.conf

配置云提供商

咱们将创立以下 ProviderConfig 对象来为 AWS Provider 配置凭证:

apiVersion: aws.crossplane.io/v1beta1
kind: ProviderConfig
metadata:
  name: default
spec:
  credentials:
    source: Secret
    secretRef:
      namespace: crossplane-system
      name: aws-creds
      key: creds

kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-1.5/docs/snippets/configure/aws/providerconfig.yaml

当初您曾经配置了反对 PostgreSQLInstance 的 Crossplane，当初能够提供基础设施了。

提供基础设施

组合资源 (XRs，Composite resources) 总是在集群范畴内 — 它们存在于任何名称空间之外。这容许 XR 示意可能来自几个不同 namespace 的基础设施。对于 VPC 网络来说，这通常是正确的 —— 基础设施管理员可能心愿定义一个 VPC 网络 XR 和一个 SQL 实例 XR，只有后者可能由应用程序操作员治理。应用程序操作员只能应用其团队的 namespace，然而他们的 SQL 实例都应该连贯到基础架构操作员治理的 VPC 网络。Crossplane 容许基础设施操作人员向其应用程序操作人员提供复合资源申明(XRC，composite resource claim)，从而实现这样的场景。XRC 是 XR 的命名空间代理; XRC 的 schema 与其对应的 XR 的 schema 是雷同的。当应用程序操作员创立一个 XRC 时，会主动创立一个相应的后备 XR。这个模型与 Kubernetes 中的长久卷(PV) 和长久卷申明 (PVC) 类似

申明基础设施

咱们在上一节中装置的 Configuration 包:

• 定义一个XPostgreSQLInstance XR。
• 提供一个对应 XR 的 PostgreSQLInstance 申明(XRC)。
• 创立一个能够满足 XR 的 Composition。

这意味着咱们能够在 default 的命名空间中创立一个 PostgreSQLInstance XRC 来提供一个 PostgreSQL 实例和它可能须要的所有反对基础设施(vpc、防火墙规定、资源组等)!

留神，该资源将应用您的默认 VPC 创立一个 RDS 实例，该实例可能容许也可能不容许来自互联网的连贯，这取决于它的配置形式。

apiVersion: database.example.org/v1alpha1
kind: PostgreSQLInstance
metadata:
  name: my-db
  namespace: default
spec:
  parameters:
    storageGB: 20
  compositionSelector:
    matchLabels:
      provider: aws
      vpc: default
  writeConnectionSecretToRef:
    name: db-conn

kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-1.5/docs/snippets/compose/claim-aws.yaml

创立 PostgreSQLInstance Crossplane 后，将开始在您抉择的云供应商上提供一个数据库实例。一旦配置实现，当你运行时，你应该在输入中看到READY: True:

kubectl get postgresqlinstance my-db

留神：

在期待 PostgreSQLInstance 就绪时，您可能想查看集群中的其余资源。通过以下命令能够查看 Crossplane 资源组:

• kubectl get claim: 获取所有申明类型的所有资源，如 PostgreSQLInstance。
• kubectl get composite: 获取所有复合类型的资源，如 XPostgreSQLInstance。
• kubectl get managed：获取代表一个内部基础设施单元的所有资源。
• kubectl get <name-of-provider>：获取与云供应商相干的所有资源。
• kubectl get crossplane：取得所有与 Crossplane 相干的资源。

试试上面的命令，以察看您筹备好的资源:

kubectl get crossplane -l crossplane.io/claim-name=my-db

一旦筹备好 PostgreSQLInstance，您应该在 default 命名空间中看到一个名为 db-conn 的 Secret，它蕴含咱们在 XRD 中定义的 key。如果它们是由 composition 填充的，那么它们应该呈现:

$ kubectl describe secrets db-conn
Name:         db-conn
Namespace:    default
...

Type:  connection.crossplane.io/v1alpha1

Data
====
password:  27 bytes
port:      4 bytes
username:  25 bytes
endpoint:  45 bytes

这里我创立好了一个 RDS，endpoint 是：my-db-lfcp2-v792d.cbijsmocclgy.us-east-1.rds.amazonaws.com

生产基础设施

因为连贯机密信息被写成 Kubernetes Secret，它们很容易被 Kubernetes 原语应用。Kubernetes 中最根本的构建块是 Pod。让咱们定义一个 Pod，它将显示咱们可能连贯到新供给的数据库。

apiVersion: v1
kind: Pod
metadata:
  name: see-db
  namespace: default
spec:
  containers:
  - name: see-db
    image: postgres:12
    command: ['psql']
    args: ['-c', 'SELECT current_database();']
    env:
    - name: PGDATABASE
      value: postgres
    - name: PGHOST
      valueFrom:
        secretKeyRef:
          name: db-conn
          key: endpoint
    - name: PGUSER
      valueFrom:
        secretKeyRef:
          name: db-conn
          key: username
    - name: PGPASSWORD
      valueFrom:
        secretKeyRef:
          name: db-conn
          key: password
    - name: PGPORT
      valueFrom:
        secretKeyRef:
          name: db-conn
          key: port

kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-1.5/docs/snippets/compose/pod.yaml

这个 Pod 只是连贯到一个 PostgreSQL 数据库并打印它的名字，所以如果你运行 kubectl logs see-db，你应该在创立它之后看到以下输入(或相似的):

 current_database
------------------
 postgres
(1 row)

清理

要清理 Pod，运行:

kubectl delete pod see-db

为了清理筹备好的基础设施，你能够删除 PostgreSQLInstance XRC:

kubectl delete postgresqlinstance my-db

当我执行这个的时候，对应的 Crossplane 状态为 deleting：

$ kubectl get crossplane -l crossplane.io/claim-name=my-db
NAME                                                       READY   SYNCED   STATE      ENGINE     VERSION   AGE
rdsinstance.database.aws.crossplane.io/my-db-lfcp2-v792d   False   True     deleting   postgres   12.7      14m

查看 AWS 控制台，也正在删除：

删除结束后，2 边也是状态统一的：

下一步

当初您曾经理解了如何通过组合来供给和应用简单的基础设施。在下一节中，您将学习如何编写和打包您本人的基础设施 api。

卸载

See Uninstall docs for cleaning up resources, packages, and Crossplane itself.

总结

联合后面章节《Crossplane vs Terraform》里提到的，Crossplane 的确在云基础设施治理这块更进一步，仅从下面这个简略的「疾速上手」环节，就能感觉到，相比 Terraform，Crossplane 在这些方面更有劣势：

• 🔘 申明式基础设施配置（Kubernetes 一脉相承）
• 🔗 对立应用程序和基础设施的配置和部署（都用 Kubernetes）
• 🔄 应用协调控制器自动化操作工作（这点体验真的不错）
• ⇅ 强烈的关注点拆散

以上。