入门

简介

当我们本地运行 kubectl 时，需要一种方式来确定如何与我们的 Kubernetes 集群进行通信。我们还需要连接到多个不同的集群。例如，我们可能使用本地集群进行测试，一个在 Google Cloud 上运行的预发布集群，以及一个部署在 AWS 上的生产集群。

每次运行 kubectl 时，它都会查找一个配置文件以获取这些信息。默认情况下，该文件会创建在 ~/.kube/config，通常被称为 kubeconfig。

kubeconfig 的结构

以下是一个示例配置：

1apiVersion: v1
2kind: Config
3current-context: docker-for-desktop
4
5clusters:
6- cluster:
7    insecure-skip-tls-verify: true
8    server: https://localhost:6443
9  name: docker-for-desktop-cluster
10
11users:
12- name: docker-for-desktop
13  user:
14    client-certificate-data: LS0tL...
15    client-key-data: LS0tL...
16
17contexts:
18- context:
19    cluster: docker-for-desktop-cluster
20    user: docker-for-desktop
21  name: docker-for-desktop

我们可以看到，它包含三个主要部分：Clusters（集群）、Users（用户）和 Contexts（上下文）。这是一个标准的 YAML 文件，每个部分都包含一个值列表，因此我们可以定义多个集群、用户和上下文。

我们首先定义 kubectl 可以连接的所有集群。在本例中，我们只有一个本地运行的集群，地址为 https://localhost:6443。如果我们还有另一个运行在 AWS 上的集群，配置可能如下所示：

1clusters:
2- cluster:
3    insecure-skip-tls-verify: true
4    server: https://localhost:6443
5  name: docker-for-desktop-cluster
6
7- cluster:
8    server: https://7150E27E.us-east-1.eks.amazonaws.com
9  name: production

每个集群定义的 name 可以是任何有助于识别该集群的名称。这个名称仅在此配置文件中使用，无需与集群中实际运行的内容有任何关联。它只是提供一种更便于用户识别的方式来引用集群。

接下来是 users 部分，用于定义我们如何对集群进行身份验证。在本例中，我们只有一个用户，使用的是 X509 证书进行认证。同样，我们可以为该用户指定一个友好的名称，这里命名为 docker-for-desktop。

最后，我们定义 contexts（上下文）。一个上下文是集群和用户的组合。在本例中，我们有一个名为 docker-for-desktop 的上下文，它通过用户 docker-for-desktop 连接到名为 docker-for-desktop-cluster 的集群。