访问集群

• 使用 kubectl 完成集群的第一次访问
• • 使用 kubectl proxy
• 以编程方式访问 API
  • Python 客户端
  • 从 Pod 中访问 API
• • 连接的方法
  • 使用 web 浏览器访问运行在集群上的服务
• 多种代理

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

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

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

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

直接访问 REST API

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

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

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

kubectl proxy --port=8080 &

参阅 获取更多详细信息。

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

curl http://localhost:8080/api/

不使用 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 " ")
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 方法实现：

{
  "kind": "APIVersions",
  "versions": [
    "v1"
  ],
  "serverAddressByClientCIDRs": [
    {
      "serverAddress": "10.0.1.149:443"
    }
  ]
}

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

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

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

Go 客户端

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

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

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

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 中，节点、 和 服务 都有自己的 IP。 在许多情况下，集群上的节点 IP、Pod IP 和某些服务 IP 将无法路由， 因此无法从集群外部的计算机（例如桌面计算机）访问它们。

有多种方式可以从集群外部连接节点、Pod 和服务：

• 通过公共 IP 访问服务。

  • 类型为 NodePort 或 LoadBalancer 的服务，集群外部可以访问。 请参阅 和 kubectl expose 文档。
  • 取决于你的集群环境，该服务可能仅暴露给你的公司网络，或者也可能暴露给 整个互联网。 请考虑公开该服务是否安全。它是否进行自己的身份验证？
  • 在服务后端放置 Pod。要从一组副本中访问一个特定的 Pod，例如进行调试， 请在 Pod 上设置一个唯一的标签，然后创建一个选择此标签的新服务。
  • 在大多数情况下，应用程序开发人员不应该通过其 nodeIP 直接访问节点。

• 使用 proxy 动词访问服务、节点或者 Pod。

  • 在访问远程服务之前进行 apiserver 身份验证和授权。 如果服务不能够安全地暴露到互联网，或者服务不能获得节点 IP 端口的 访问权限，或者是为了调试，那么请使用此选项。
  • 代理可能会给一些 web 应用带来问题。
  • 只适用于 HTTP/HTTPS。
  • 更多详细信息在。

• 从集群中的节点或者 Pod 中访问。

  • 运行一个 Pod，然后使用 kubectl exec 来连接 Pod 里的 Shell。 然后从 Shell 中连接其它的节点、Pod 和服务。
  • 有些集群可能允许你通过 SSH 连接到节点，从那你可能可以访问集群的服务。 这是一个非正式的方式，可能可以运行在个别的集群上。 浏览器和其它一些工具可能没有被安装。集群的 DNS 可能无法使用。

发现内建服务

通过 kubectl cluster-info 命令获得这些服务列表：

kubectl cluster-info

这展示了访问每个服务的 proxy-verb URL。 例如，如果集群启动了集群级别的日志（使用 Elasticsearch），并且传递合适的凭证， 那么可以通过 https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/ 进行访问。日志也能通过 kubectl 代理获取，例如： http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/。 （参阅使用 Kubernetes API 访问集群 了解如何传递凭据，或者使用 kubectl proxy）

手动构建 apiserver 代理 URL

如上所述，你可以使用 kubectl cluster-info 命令来获得服务的代理 URL。 要创建包含服务端点、后缀和参数的代理 URL，需添加到服务的代理 URL： http://kubernetes_master_address/api/v1/namespaces/namespace_name/services//proxy

如果尚未为端口指定名称，则不必在 URL 中指定 port_name。 对于已命名和未命名的端口，也可以使用端口号代替 port_name。

默认情况下，API server 使用 HTTP 代理你的服务。 要使用 HTTPS，请在服务名称前加上 https:： http://kubernetes_master_address/api/v1/namespaces/namespace_name/services/https:service_name:[port_name]/proxy

URL 名称段支持的格式为：

• <service_name> - 使用 http 代理到默认或未命名的端口
• <service_name>:<port_name> - 使用 http 代理到指定的端口名称或端口号
• https:<service_name>:<port_name> - 使用 https 代理到指定的端口名称或端口号

示例

• 要访问 Elasticsearch 服务端点 _search?q=user:kimchy，你需要使用： http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy
• 要访问 Elasticsearch 集群健康信息 _cluster/health?pretty=true，你需要使用： https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true

  {
    "cluster_name" : "kubernetes_logging",
    "status" : "yellow",
    "timed_out" : false,
    "number_of_nodes" : 1,
    "number_of_data_nodes" : 1,
    "active_primary_shards" : 5,
    "active_shards" : 5,
    "relocating_shards" : 0,
    "initializing_shards" : 0,
    "unassigned_shards" : 5

使用 web 浏览器访问运行在集群上的服务

你可以在浏览器地址栏中输入 apiserver 代理 URL。但是：

• Web 浏览器通常不能传递令牌，因此你可能需要使用基本（密码）身份验证。 Apiserver 可以配置为接受基本身份验证，但你的集群可能未进行配置。
• 某些 Web 应用程序可能无法运行，尤其是那些使用客户端 javascript 以不知道代理路径前缀的方式构建 URL 的应用程序。

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

多种代理

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

1. ：

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

2. apiserver 代理：

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

3. ：

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

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

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

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

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

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