如何使用Crossplane的provider-helm向其他集群安装Helm charts

你的核心思路没有错误，通过托管集群的Crossplane实例调度资源到新开通的业务集群是Crossplane非常典型的多集群管理使用场景，你遇到的问题属于配置环节遗漏和流程可优化的问题，并非方向错误。

• 第一种使用InjectedIdentity作为凭证源的ProviderConfig，本质是调用Crossplane所在集群内Pod的服务账号身份访问Kubernetes API，因此只能操作当前集群，属于该配置的正常表现。
• 第二种通过Secret传入目标集群kubeconfig的方式本身是官方推荐的标准方案，你遇到的两个问题可以分别独立解决：
  1. 部署时报PodUnschedulable Cannot schedule pods: gvisor错误：该报错和Crossplane、Helm Provider的配置完全无关，属于你新创建的GKE集群本身的配置缺陷——要么集群没有启用gvisor运行时，要么对应节点池不支持gvisor调度。你可以先手动使用该kubeconfig往目标集群部署测试Pod验证集群可用性，排除集群本身问题后再走Crossplane部署流程即可。
  2. kubeconfig生成流程复杂需要外部脚本：你不需要自己编写Makefile等外部脚本来生成kubeconfig，Crossplane本身可实现从新集群创建到kubeconfig自动生成、存入Secret的全链路自动化，你遗漏了GCP Provider和Kubernetes Provider的搭配使用逻辑：
     • 你通过Crossplane创建GKE集群时，GCP Provider生成的container.gcp.upbound.io/v1beta1/Cluster自定义资源，其status.atProvider.endpoint、status.atProvider.caCertificate字段已经包含了集群接入所需的核心信息
     • 搭配Crossplane的kubernetes.crossplane.io/v1alpha1/Object资源，可自动将上述字段拼接为符合要求的kubeconfig，直接存入crossplane-system命名空间下的Secret，无需人工或外部脚本介入
     • 自动生成的Secret可直接被Helm Provider的ProviderConfig引用，做到集群创建完成后自动拉起对应ProviderConfig，后续的Helm Release资源只要指定providerConfigRef.name为对应目标集群的ProviderConfig名称，即可自动部署到目标集群

如果需要简化认证逻辑，也可以在创建GKE集群的时候同步创建有权限的ServiceAccount，把对应的token直接拼入kubeconfig，避免依赖gcloud命令行做身份认证。

内容的提问来源于stack exchange，提问作者camme