访问集群

本文阐述多种与集群交互的方法。

使用 kubectl 完成集群的第一次访问

当你第一次访问 Kubernetes API 的时候，我们建议你使用 Kubernetes CLI，kubectl。

访问集群时，你需要知道集群的地址并且拥有访问的凭证。通常，这些在你通过 启动安装安装集群时都是自动安装好的，或者其他人安装时 也应该提供了凭证和集群地址。

通过以下命令检查 kubectl 是否知道集群地址及凭证：

kubectl config view

有许多 例子 介绍了如何使用 kubectl， 可以在 kubectl手册 中找到更完整的文档。

直接访问 REST API

Kubectl 处理 apiserver 的定位和身份验证。 如果要使用 curl 或 wget 等 http 客户端或浏览器直接访问 REST API，可以通过 多种方式查找和验证：

  • 以代理模式运行 kubectl。
    • 推荐此方式。
    • 使用已存储的 apiserver 地址。
    • 使用自签名的证书来验证 apiserver 的身份。杜绝 MITM 攻击。
    • 对 apiserver 进行身份验证。
    • 未来可能会实现智能化的客户端负载均衡和故障恢复。
  • 直接向 http 客户端提供位置和凭据。
    • 可选的方案。
    • 适用于代理可能引起混淆的某些客户端类型。
    • 需要引入根证书到你的浏览器以防止 MITM 攻击。

使用 kubectl proxy

以下命令以反向代理的模式运行 kubectl。它处理 apiserver 的定位和验证。 像这样运行：

kubectl proxy --port=8080 &

参阅 kubectl proxy 获取更多详细信息。

然后，你可以使用 curl、wget 或浏览器访问 API，如果是 IPv6 则用 [::1] 替换 localhost， 如下所示：

curl http://localhost:8080/api/

{
  "kind": "APIVersions",
  "versions": [
    "v1"
  ],
  "serverAddressByClientCIDRs": [
    {
      "clientCIDR": "0.0.0.0/0",
      "serverAddress": "10.0.1.149:443"
    }
  ]
}

不使用 kubectl proxy

在 Kubernetes 1.3 或更高版本中，kubectl config view 不再显示 token。 使用 kubectl describe secret ... 来获取默认服务帐户的 token，如下所示：

grep/cut 方法实现：

APISERVER=$(kubectl config view | grep server | cut -f 2- -d ":" | tr -d " ")
TOKEN=$(kubectl describe secret $(kubectl get secrets | grep default | cut -f1 -d ' ') | grep -E '^token' | cut -f2 -d':' | tr -d ' ')
curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure

{
  "kind": "APIVersions",
  "versions": [
    "v1"
  ],
  "serverAddressByClientCIDRs": [
    {
      "clientCIDR": "0.0.0.0/0",
      "serverAddress": "10.0.1.149:443"
    }
  ]
}

jsonpath 方法实现：

APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
TOKEN=$(kubectl get secret $(kubectl get serviceaccount default -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.token}' | base64 --decode )
curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure

{
  "kind": "APIVersions",
  "versions": [
    "v1"
  ],
  "serverAddressByClientCIDRs": [
    {
      "clientCIDR": "0.0.0.0/0",
      "serverAddress": "10.0.1.149:443"
    }
  ]
}

上面的例子使用了 --insecure 参数，这使得它很容易受到 MITM 攻击。 当 kubectl 访问集群时，它使用存储的根证书和客户端证书来访问服务器 （它们安装在 ~/.kube 目录中）。 由于集群证书通常是自签名的，因此可能需要特殊配置才能让你的 http 客户端使用根证书。

在一些集群中，apiserver 不需要身份验证；它可能只服务于 localhost，或者被防火墙保护， 这个没有一定的标准。 配置对 API 的访问 描述了集群管理员如何进行配置。此类方法可能与未来的高可用性支持相冲突。

以编程方式访问 API

Kubernetes 官方提供对 Go 和 Python 的客户端库支持。

Go 客户端

  • 想要获得这个库，请运行命令：go get k8s.io/client-go/<version number>/kubernetes。 参阅 https://github.com/kubernetes/client-go 来查看目前支持哪些版本。
  • 基于这个 client-go 客户端库编写应用程序。 请注意，client-go 定义了自己的 API 对象，因此如果需要，请从 client-go 而不是从主存储库 导入 API 定义，例如，import "k8s.io/client-go/1.4/pkg/api/v1" 才是对的。

Go 客户端可以像 kubectl CLI 一样使用相同的 kubeconfig 文件 来定位和验证 apiserver。可参阅 示例。

如果应用程序以 Pod 的形式部署在集群中，那么请参阅 下一章。

Python 客户端

如果想要使用 Python 客户端， 请运行命令：pip install kubernetes。参阅 Python Client Library page 以获得更详细的安装参数。

Python 客户端可以像 kubectl CLI 一样使用相同的 kubeconfig 文件 来定位和验证 apiserver，可参阅 示例。

其它语言

目前有多个客户端库 为其它语言提供访问 API 的方法。 参阅其它库的相关文档以获取他们是如何验证的。

从 Pod 中访问 API

当你从 Pod 中访问 API 时，定位和验证 apiserver 会有些许不同。

在 Pod 中定位 apiserver 的推荐方式是通过 kubernetes.default.svc 这个 DNS 名称，该名称将会解析为服务 IP，然后服务 IP 将会路由到 apiserver。

向 apiserver 进行身份验证的推荐方法是使用 服务帐户 凭据。 通过 kube-system，Pod 与服务帐户相关联，并且该服务帐户的凭证（token） 被放置在该 Pod 中每个容器的文件系统中，位于 /var/run/secrets/kubernetes.io/serviceaccount/token。

如果可用，则将证书放入每个容器的文件系统中的 /var/run/secrets/kubernetes.io/serviceaccount/ca.crt， 并且应该用于验证 apiserver 的服务证书。

最后，名字空间作用域的 API 操作所使用的 default 名字空间将被放置在 每个容器的 /var/run/secrets/kubernetes.io/serviceaccount/namespace 文件中。

在 Pod 中，建议连接 API 的方法是：

  • 在 Pod 的边车容器中运行 kubectl proxy，或者以后台进程的形式运行。 这将把 Kubernetes API 代理到当前 Pod 的 localhost 接口， 所以 Pod 中的所有容器中的进程都能访问它。
  • 使用 Go 客户端库，并使用 rest.InClusterConfig() 和 kubernetes.NewForConfig() 函数创建一个客户端。 他们处理 apiserver 的定位和身份验证。 示例

在每种情况下，Pod 的凭证都是为了与 apiserver 安全地通信。

访问集群上运行的服务

上一节介绍了如何连接到 Kubernetes API 服务器。 有关连接到 Kubernetes 集群上运行的其他服务的信息，请参阅访问集群服务。

请求重定向

重定向功能已弃用并被删除。请改用代理（见下文）。

多种代理

使用 Kubernetes 时可能会遇到几种不同的代理：

  1. kubectl 代理：

    • 在用户的桌面或 Pod 中运行
    • 代理从本地主机地址到 Kubernetes apiserver
    • 客户端到代理将使用 HTTP
    • 代理到 apiserver 使用 HTTPS
    • 定位 apiserver
    • 添加身份验证头部

  1. apiserver 代理：

    • 内置于 apiserver 中
    • 将集群外部的用户连接到集群 IP，否则这些 IP 可能无法访问
    • 运行在 apiserver 进程中
    • 客户端代理使用 HTTPS（也可配置为 http）
    • 代理将根据可用的信息决定使用 HTTP 或者 HTTPS 代理到目标
    • 可用于访问节点、Pod 或服务
    • 在访问服务时进行负载平衡

  1. kube proxy：

    • 运行在每个节点上
    • 代理 UDP 和 TCP
    • 不能代理 HTTP
    • 提供负载均衡
    • 只能用来访问服务

  1. 位于 apiserver 之前的 Proxy/Load-balancer：

    • 存在和实现因集群而异（例如 nginx）
    • 位于所有客户和一个或多个 apiserver 之间
    • 如果有多个 apiserver，则充当负载均衡器

  1. 外部服务上的云负载均衡器：

    • 由一些云提供商提供（例如 AWS ELB，Google Cloud Load Balancer）
    • 当 Kubernetes 服务类型为 LoadBalancer 时自动创建
    • 只使用 UDP/TCP
    • 具体实现因云提供商而异。

除了前两种类型之外，Kubernetes 用户通常不需要担心任何其他问题。 集群管理员通常会确保后者的正确配置。

最后修改 January 05, 2022 at 6:38 PM PST : [zh] synchronize translate access-cluster.md (8ed0eb3e4)