实战基于Crossplane+Terraform基础设施自动化编排方案
一 背景
Crossplane 和 Terraform 都是用于基础设施自动化编排的工具,使用它们可以实现可重复和可控的基础设施部署。当您同时使用 Crossplane 和 Terraform 时,可以借助 Crossplane 的云原生设计来管理跨云的基础设施资源,同时利用 Terraform 的广泛生态系统和提供者支持来管理特定于云或供应商的资源。
二 概述
对于基础设施管理，Crossplane 和 Terraform均有独特的应用场景，Terraform 和 Crossplane 都是强大的基础设施即代码工具，但它们的设计目标和适用场景有所不同。Terraform 适用于管理和部署各种基础设施资源，而 Crossplane 则专注于使用 Kubernetes 平台管理多个云提供商的基础设施服务。以下是它们的异同：
-
范围和生态系统：Terraform 是一个通用的基础设施编排工具，可以管理多种基础设施资源，并拥有庞大的插件生态系统。Crossplane 则专注于跨多个云提供商的云基础设施管理，基于 Kubernetes 平台进行统一的管理。
-
抽象级别：Terraform 提供了更高层次的抽象，可以通过模块化和变量来组织和管理基础设施资源。Crossplane 则更接近云提供商的原生 API，提供更细粒度的控制和定制。
-
声明式规范：Terraform 使用 HCL 或 JSON 等声明式语言来描述基础设施状态和配置。Crossplane 则使用 Kubernetes 自定义资源来定义基础设施资源的规范。
-
可观察性：Terraform 提供了一些命令和工具来查看和管理基础设施状态，但与 Kubernetes 的监控和调试能力相比较，其可观察性支持较为有限。
三 场景分析
想要利用crossplane整体管控阿里云基础设施资源编排，由于crossplane中阿里的privider对阿里基础设施资源支持有限，terraform对阿里云基础设施资源支持丰富，
- Terraform 阿里云provider
- crossplane providers对阿里云支持
跨平面编排目标云资源，依赖于供应商，目前阿里的供应商支持NAS、OSS、REDIS、SLB、SLS。但是，单独使用此提供商无法实现对其他云资源的全面控制
官方文档中的示例缺乏长期维护，并且随着官方产品的发展而失效。由于没有人维护提供程序，治理变得无效。
四 方案
方案概述：
-
利用Provider-alibaba管控支持的云资源
-
配合Crossplane+Provider-terraform 覆盖其他阿里云资源管理
发难特点：
- Crossplane配合Terraform实现全流程基础设施自动化编排
- 无论云资源是否提供 Crossplane 的原生 provider，都可以通过 Provider-Terraform 实现跨云资源管理
- 使用 Terraform 模板作为中间层，统一了云资源的管理接口，简化了跨云平台的配置和操作
- Crossplane 提供了与 Kubernetes 的集成，可以通过自定义资源进行云资源的声明和管理
需要注意的是，在某些场景中，Terraform和Crossplane可以相互补充。Terraform可用于提供和配置底层基础设施，而Crossplane可用于管理更高级别的抽象，并将基础设施资源与Kubernetes工作负载连接起来。 terraform-provider,提供程序Terraform是一个Crossplane提供程序，可以运行Terraform代码，并可以定义新的Crossplane复合资源(xr)，这些资源由“本地”Crossplane管理资源和现有的Terraform模块混合组成。 Terraform提供程序添加了对代表Terraform工作空间的工作区管理资源的支持。每个工作区的配置可以从远程源(例如git)获取，也可以简单地内联指定。
五 实战
5.1 环境准备
- Kind
- CVM
- Helm
- Kubectl
- Kubernetes
- 阿里云账号
- terraform
5.2 主机及环境准备
#!/bin/bash
# docker 部署
yum remove docker \
docker-client \
docker-client-latest \
docker-common \
docker-latest \
docker-latest-logrotate \
docker-logrotate \
docker-engine
yum install -y yum-utils \
device-mapper-persistent-data \
lvm2
yum-config-manager \
--add-repo \
https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
yum install docker-ce docker-ce-cli containerd.io -y
sudo systemctl start docker
sudo systemctl enable docker
# kubectl部署
curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.18.0/bin/linux/amd64/kubectl &&\
chmod +x ./kubectl &&\
mv ./kubectl /usr/bin/kubectl
kubectl version --client
# 将 k alias 写入系统
echo "alias k=kubectl" >> ~/.bashrc
source ~/.bashrc
source ~/.bashrc
# helm3 部署
curl -LO https://get.helm.sh/helm-v3.14.1-linux-amd64.tar.gz && \
tar -zxvf helm-v3.14.1-linux-amd64.tar.gz && \
mv linux-amd64/helm /usr/bin/helm
helm version
# kind部署
curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.11.1/kind-linux-amd64 && \
chmod +x ./kind && \
mv ./kind /usr/bin/kind
kind version
# k8s 集群创建
cat >kind-config.yaml<<EOF
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker
- role: worker
EOF
kind create cluster --name crossplane --config kind-config.yaml
kubectl get nodes
# crossplane 创建
helm repo add \
crossplane-stable https://charts.crossplane.io/stable
helm repo update
helm install crossplane \
crossplane-stable/crossplane \
--namespace crossplane-system \
--create-namespace
# 等待helm部署完成
sleep 30
helm list -n crossplane-system
kubectl get all -n crossplane-system
5.3 实现架构
5.4 provider相关配置
# terraform provider
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
name: provider-terraform
spec:
package: xpkg.upbound.io/upbound/provider-terraform:v0.14.1
controllerConfigRef:
name: terraform
apiVersion: pkg.crossplane.io/v1alpha1
kind: ControllerConfig
metadata:
name: terraform
labels:
app: crossplane-provider-terraform
spec:
args:
- -d
- --poll=5m
- --max-reconcile-rate=10
apiVersion: tf.upbound.io/v1beta1
kind: ProviderConfig
metadata:
name: azure-westeurope
spec:
configuration: |
terraform {
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = "3.78.0"
}
}
required_version = ">= 1.1.0"
backend "kubernetes" {
secret_suffix = "providerconfig-azure-westeurope"
namespace = "crossplane-system"
in_cluster_config = true
}
# backend "azurerm" {
# resource_group_name = "StorageAccount-ResourceGroup"
# storage_account_name = "abcd1234"
# container_name = "tfstate"
# key = "prod.terraform.tfstate"
# use_msi = true
# subscription_id = "00000000-0000-0000-0000-000000000000"
# tenant_id = "00000000-0000-0000-0000-000000000000"
# }
# backend "azurerm" {
# resource_group_name = "StorageAccount-ResourceGroup"
# storage_account_name = "abcd1234"
# container_name = "tfstate"
# key = "prod.terraform.tfstate"
# }
}
variable "subscriptionId" {
type = string
}
variable "tenantId" {
type = string
}
variable "clientId" {
type = string
}
variable "clientSecret" {
type = string
}
provider "azurerm" {
subscription_id = var.subscriptionId
tenant_id = var.tenantId
client_id = var.clientId
client_secret = var.clientSecret
features {}
}
credentials:
- filename: terraform.tfvars.json
secretRef:
key: credentials
name: tf-azure-secret
namespace: crossplane-system
source: Secret
5.5 实现代码
- 实现资源配置
apiVersion: tf.upbound.io/v1beta1
kind: Workspace
metadata:
name: tf-az-rg
spec:
forProvider:
source: Inline
module: >
resource "azurerm_resource_group" "rg" {
name = "xuel-test-azurerm"
location = "westus"
}
writeConnectionSecretToRef:
name: terraform-workspace-example-random-generator
namespace: default
5.6 排错
可以登陆进入控制器查看tf执行情况
- 删除资源
六 注意事项
- 由于provider-terraform不支持持久化状态存储，需要使用kubernetes远程状态后端，以确保应用容器/tf目录不回丢失。
- 如果模块运行时间超时（默认20m），底层的terraform进程将被终止，可能丢失状态并泄漏资源，workspace lock将可能留在原地，需要手动删除。
- providers在成功应用Terraform模块之前不会发出事件，这可能需要很长时间。
- 将——max-reconcile-rate设置为大于1的值可能会导致提供者使用最多相同数量的cpu。在ControllerConfig中添加一个资源部分，以根据需要限制CPU的使用。
七 总结
当需要利用crossplane管控的资源没有provider时候，Terraform和Crossplane可以相互补充。Terraform可用于提供和配置底层基础设施，而Crossplane可用于管理更高级别的抽象，并将基础设施资源与Kubernetes工作负载连接起来。当组织采用多云策略时，他们可能需要跨多个云提供商配置和管理基础设施资源。在这个用例中，Terraform可用于跨不同云提供商定义和提供底层基础设施资源，例如虚拟机、网络和存储。Terraform的与云无关的方法允许您编写一次基础架构代码，并将其应用于不同的云。
- 点赞
- 收藏
- 关注作者
评论（0）