当您使用 minikube 时，它会自动创建本地配置，因此可以随时使用。根据kubectl config的参考，kubectl命令似乎支持多个集群。
在设置集群的文档中，有一个关于将相关文件复制到本地机器以访问集群的参考。我还发现了一个关于编辑 .kube/config 以远程利用 azure的SO Q&A，其中谈到了编辑 kube/config 文件。
看起来环境变量$KUBECONFIG可以引用这些配置文件的多个位置，内置默认值~/.kube/config（这是 minikube 创建的）。
如果我希望能够使用 kubectl 对多个集群调用命令，我是否应该将相关配置文件下载到新位置（例如 into ~/gcloud/config，将KUBECONFIG环境变量设置为引用两个位置？
还是--kubeconfig在调用 kubectl 为集群指定配置时直接使用该选项更好？
我不确定是否有某种方法可以更好地合并配置文件，并改用kubectl config set-contextorkubectl config set-cluster命令。Kubernetes 上关于“配置对多个集群的访问”的文档似乎暗示了--kubeconfig与这些kubectl config命令一起使用的不同方式。
简而言之，与多个单独的 kubernetes 集群交互的最佳方式是什么，权衡是什么？
\n\n\n如果我希望能够调用
\n\nkubectl多个\n 集群的命令，是否应该将相关配置文件下载到新的\n 位置（例如~/gcloud/config，将KUBECONFIG\n 环境变量设置为引用这两个位置？或者在调用 kubectl 指定集群配置时显式使用 --kubeconfig 选项是否更好？
\n
这可能取决于您发现更简单、更方便的方法，以及是否需要考虑安全和访问管理问题。
\n\n根据我们的经验，合并各种kubeconfig文件对于多集群操作非常有用，以便在一组集群（上下文和命名空间）上执行维护任务和事件管理，基于比较配置、清单、资源的可能性简化故障排除问题以及 K8s 服务、pod、卷、命名空间、rs 等的状态。
然而，当涉及自动化和部署（使用 Jenkins、Spinnaker 或 Helm 等工具）时，拥有单独的kubeconfig文件很可能是一个好主意。混合方法可以kubeconfig基于按服务层划分来合并文件-> 使用文件来分区开发环境（dev、qa、stg、prod）集群或团队-> 企业中的角色和职责（teamA、teamB、\xe2） \x80\xa6, teamN) 也可以在好的替代方案中被理解。
对于多集群合并kubeconfig文件场景，请考虑kubectx + kubens，它们是非常强大的工具，可kubectlt让您查看当前上下文（集群）和命名空间，同样可以在它们之间进行切换。
\n\n\n简而言之，与多个独立的 kubernetes 集群交互的最佳方式是什么以及权衡是什么？
\n
应该考虑对您的项目最重要的因素来分析权衡。拥有单个合并kubeconfig文件似乎更简单，如果您将其合并~/.kube/config为默认使用的文件，kubectl并且只需使用标志在集群/命名空间之间切换，则甚至更简单--context kubectl。另一方面，如果必须限制范围kubeconfig，那么将它们隔离并使用--kubeconfig=file1听起来是最好的方法。
可能没有适合每种情况和场景的最佳方法，但了解如何配置kubeconfig文件并了解其优先级会有所帮助。
在本文 -> https://www.nrmitchi.com/2019/01/managing-kubeconfig-files/中，您将找到补充且有价值的意见：
\n\n虽然在一个文件中包含您可能需要的所有上下文固然很好，但维护起来却很困难，并且很少出现默认情况。为您提供访问凭据的多个工具将为您提供全新的kubeconfig使用体验。虽然您可以将配置合并到\n中~/.kube/config，但它是手动的，并且使删除上下文变得更加困难（必须显式删除上下文、集群和用户）。Kubernetes 跟踪此问题存在一个悬而未决的问题。但是，通过将每个提供的配置文件分开，然后加载所有配置文件，删除就容易得多（只需删除文件）。对我来说，这似乎是一种更易于管理的方法。
我更喜欢将所有单独的配置文件保存在 ~/.kube/configs 下，并且通过利用 $KUBECONFIG 环境变量选项的多路径方面，我们可以实现这一点。
如果您\xe2\x80\x99正在使用，则此处\xe2\x80\x99是在确定使用哪个kubeconfigkubectl文件时生效的首选项。
--kubeconfig标志（如果指定）KUBECONFIG环境变量（如果指定）$HOME/.kube/config文件这样，您可以轻松地覆盖每个命令使用的kubeconfigkubectl文件：
#\n# using --kubeconfig flag\n#\nkubectl get pods --kubeconfig=file1\nkubectl get pods --kubeconfig=file2\n\n#\n# or \n# using `KUBECONFIG` environment variable\n#\nKUBECONFIG=file1 kubectl get pods\nKUBECONFIG=file2 kubectl get pods\n\n#\n# or \n# merging your kubeconfig file w/ $HOME/.kube/config (w/ cp backup)\n#\ncp $HOME/.kube/config $HOME/.kube/config.backup.$(date +%Y-%m-%d.%H:%M:%S)\nKUBECONFIG= $HOME/.kube/config:file2:file3 kubectl config view --merge --flatten > \\\n~/.kube/merged_kubeconfig && mv ~/.kube/merged_kubeconfig ~/.kube/config\nkubectl get pods --context=cluster-1\nkubectl get pods --context=cluster-2\n注意：该--minify标志允许我们仅提取有关该上下文的信息，并且--flatten标志允许我们保持凭证不被编辑。
您可以将 AKS（Azure 容器服务）、AWS EKS（K8s 弹性容器服务）或 GKE（Google 容器引擎）集群上下文保存到单独的文件中，并设置KUBECONFIG为引用这两个文件位置。
例如，当您通过gcloud命令创建 GKE 集群（或检索其凭据）时，它通常会修改您的默认~/.kube/config文件。不过，您可以设置$KUBECONFIG为gcloud集群凭据保存到文件中：
KUBECONFIG=c1.yaml gcloud container clusters get-credentials "cluster-1"\n正如我们之前提到的，一次使用多个kubeconfigs对于同时处理多个上下文非常有用。
为此，您需要一个 \xe2\x80\x9cmerged\xe2\x80\x9d kubeconfig文件。在下面的“合并 kubeconfig 文件”部分中，我们解释了如何将kubeconfig合并到单个文件中，但您也可以在内存中合并它们。
\n\n通过在环境变量中指定多个文件KUBECONFIG，您可以临时将kubeconfig文件拼接在一起并在kubectl.
KUBECONFIG=c1.yaml gcloud container clusters get-credentials "cluster-1"\n由于kubeconfig文件是结构化 YAML 文件，因此您可以\xe2\x80\x99 不只是附加它们来获得一个大kubeconfig文件，但kubectl可以帮助您合并这些文件：
#\n# Kubeconfig in-memory merge\n#\nexport KUBECONFIG=file1:file2\nkubectl get pods --context=cluster-1\nkubectl get pods --context=cluster-2\n\n#\n# For your example\n# merging your kubeconfig file w/ $HOME/.kube/config (w/ cp backup)\n#\ncp $HOME/.kube/config $HOME/.kube/config.backup.$(date +%Y-%m-%d.%H:%M:%S)\nKUBECONFIG= $HOME/.kube/config:file2: kubectl config view --merge --flatten > \\\n~/.kube/merged_kubeconfig && mv ~/.kube/merged_kubeconfig ~/.kube/config\nkubectl get pods --context=cluster-1\nkubectl get pods --context=cluster-2\n| 归档时间： |
|
| 查看次数： |
2132 次 |
| 最近记录： |