Crossplane初装失败主因是未安装Provider CRD；须先部署Provider（如helm install），再apply ProviderConfig，且CRD需先于Provider实例创建。

crossplane install 失败：kubectl apply 报错 no matches for kind "Provider"

这是初装 Crossplane 最常卡住的地方——不是权限或网络问题，而是没装 Provider 的 CRD。Crossplane 核心只管抽象资源（CompositeResource、Claim），云厂商能力全靠 Provider 提供，而 Provider 本身依赖自己的 CRD。

实操建议：

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• 先确认是否已部署 Provider：运行 kubectl get crd | grep provider，空输出说明 Provider 没装
• 别跳过 crossplane install provider 步骤，比如 AWS 需要 helm install crossplane-provider-aws crossplane-community/provider-aws --version v1.17.0
• Provider 的 Provider 资源（注意大小写）必须手动 apply，例如 kubectl apply -f provider-config.yaml，其中 providerConfigRef 字段才能生效
• CRD 安装顺序不能乱：Provider Helm chart 会自动处理 CRD，但若手动 kubectl apply YAML，必须先 apply CRD 清单，再 apply Provider 实例

定义 RDS 实例时，composition 中的 resources 始终不创建

现象是 CompositeResourceClaim 状态为 Bound，但底层 CompositeResource 的 status.phase 卡在 Pending，AWS 控制台也看不到 RDS 启动。

核心原因：Composition 指向的 CompositeResourceDefinition（XRD）未被识别，或 Provider 未关联到对应资源类型。

立即学习“go语言免费学习笔记（深入）”；

实操建议：

• 检查 XRD 的 spec.claimNames.kind 是否与你 kubectl apply 的 Claim 类型一致，比如 AwsRdsInstance 必须和 XRD 中声明的完全匹配（区分大小写）
• 确认 Composition 中 revisions 的 revision 字段值是否正确；若用 revision=1，但实际最新 revision 是 2，则跳过渲染
• Provider 的 ProviderConfig 必须有 spec.credentials.source: Secret，且 Secret 名字、key（如 credentials）需和 Composition 里 providerConfigRef.name 对应
• 查日志最直接：运行 kubectl logs -n crossplane-system deploy/crossplane | grep -i rds，看是否报 no matching provider config 或 failed to resolve reference

Go 项目中调用 Crossplane API 创建 Claim：用 client-go 还是 xpkg？

如果你的 Go 服务需要动态发 Claim（比如用户提交表单后触发云资源申请），不要自己手写 YAML + kubectl apply，也不推荐直接用 client-go 操作自定义资源——缺少类型安全和版本适配。

实操建议：

• 用 xpkg（Crossplane 的官方 Go SDK）：它基于 controller-runtime client 封装，自动处理 GroupVersion、Scheme 注册，支持 Apply 和 Patch
• 关键点：初始化 client 时必须注册 XRD 对应的 Scheme，否则 client.Create() 会报 no kind is registered for the type
• 示例片段：

  cfg, _ := config.GetConfig()
  c, _ := client.New(cfg, client.Options{Scheme: runtime.NewScheme()})
  // 必须显式 add your XRD's scheme here
  myclaim.AddToScheme(c.Scheme())

• 避免在 Go 代码里硬编码 apiVersion: database.example.org/v1alpha1，应从 XRD 的 spec.versions[0].name 动态读取

Provider 配置凭据泄露：Secret 写死在 Git 里怎么办

本地测试随手把 ProviderConfig 里的 credentials Secret 写进仓库，上线就等于把云账号密码公之于众。

这不是 Crossplane 特有风险，但它的 ProviderConfig 结构让误操作更隐蔽。

实操建议：

• 永远用 external-secrets 或 aws-secret-manager 注入凭据，ProviderConfig 中只保留引用：

  spec:
    credentials:
      source: Secret
      secretRef:
        namespace: crossplane-system
        name: aws-creds
        key: credentials

• 禁止在 CI/CD 流水线中 kubectl apply -f provider-config.yaml，改用 envsubst 或 Kustomize secretGenerator 动态生成
• 加 Git 钩子校验：用 git-secrets 扫描 credentials、accessKeyId、secretAccessKey 等关键词，CI 阶段失败阻断
• ProviderConfig 的 spec.credentials.source 支持 InjectedIdentity（IRSA），EKS 上优先用这个，彻底规避 Secret 管理

Crossplane 的“抽象层”越厚，配置链路就越长：Claim → XRD → Composition → Provider → Cloud API。任何一个环节的字段名、版本、引用关系出错，都不会报明确错误，只会静默卡住。调试时别猜，先盯死 kubectl get 三级对象的状态字段，再翻 crossplane-system 日志里那条带 uid 的 trace line。