访问集群
本主题讨论了与集群交互的多种方法。
首次使用 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,将 localhost 替换为 [::1],如下所示:
curl http://localhost:8080/api/
输出类似于这样:
{
"kind": "APIVersions",
"versions": [
"v1"
],
"serverAddressByClientCIDRs": [
{
"clientCIDR": "0.0.0.0/0",
"serverAddress": "10.0.1.149:443"
}
]
}
不使用 kubectl proxy
使用 kubectl apply
和 kubectl describe secret...
并结合 grep/cut 为默认服务账号创建一个 Token
首先,创建 Secret,为默认 ServiceAccount 请求一个 Token
kubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
name: default-token
annotations:
kubernetes.io/service-account.name: default
type: kubernetes.io/service-account-token
EOF
接下来,等待 token controller 用 Token 填充 Secret
while ! kubectl describe secret default-token | grep -E '^token' >/dev/null; do
echo "waiting for token..." >&2
sleep 1
done
捕获并使用生成的 Token
APISERVER=$(kubectl config view --minify | grep server | cut -f 2- -d ":" | tr -d " ")
TOKEN=$(kubectl describe secret default-token | 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 default-token -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@kubernetes-<kubernetes-version-number>
。详细安装说明请参阅 INSTALL.md。支持的版本请参阅 https://github.com/kubernetes-client/client-go。 - 在 client-go 客户端之上编写应用程序。请注意,client-go 定义了自己的 API 对象,因此如果需要,请从 client-go 导入 API 定义,而不是从主仓库导入,例如
import "k8s.io/client-go/kubernetes"
是正确的。
Go 客户端可以使用与 kubectl CLI 相同的 kubeconfig 文件来定位 apiserver 并进行身份验证。请参见此示例。
如果应用程序作为 Pod 部署在集群中,请参阅下一节。
Python 客户端
要使用Python 客户端,请运行以下命令:pip install kubernetes
。更多安装选项请参见Python 客户端库页面。
Python 客户端可以使用与 kubectl CLI 相同的 kubeconfig 文件来定位 apiserver 并进行身份验证。请参见此示例。
其他语言
还有用于从其他语言访问 API 的客户端库。有关它们如何进行身份验证的信息,请参阅其他库的文档。
从 Pod 访问 API
从 Pod 访问 API 时,定位 API 服务器并进行身份验证的方式有些不同。
有关更多详细信息,请查看从 Pod 内部访问 API。
访问在集群上运行的服务
前面一节介绍了如何连接到 Kubernetes API 服务器。有关连接到在 Kubernetes 集群上运行的其他服务的信息,请参阅访问集群服务。
请求重定向
重定向功能已被弃用并移除。请改用代理(见下文)。
代理种类繁多
使用 Kubernetes 时,你可能会遇到几种不同的代理
- 在用户的桌面或 Pod 中运行
- 从 localhost 地址代理到 Kubernetes apiserver
- 客户端到代理使用 HTTP
- 代理到 apiserver 使用 HTTPS
- 定位 apiserver
- 添加身份验证头部
- 是内置在 apiserver 中的一个堡垒主机
- 将集群外部用户连接到原本可能无法访问的集群 IP
- 在 apiserver 进程中运行
- 客户端到代理使用 HTTPS(如果 apiserver 配置为 HTTP 则使用 HTTP)
- 代理到目标可以使用 HTTP 或 HTTPS,由代理根据可用信息选择
- 可用于访问 Node、Pod 或 Service
- 用于访问 Service 时进行负载均衡
- 在每个节点上运行
- 代理 UDP 和 TCP
- 不理解 HTTP
- 提供负载均衡
- 仅用于访问服务
apiserver(s) 前的代理/负载均衡器
- 其存在和实现因集群而异(例如 nginx)
- 位于所有客户端与一个或多个 apiserver 之间
- 如果存在多个 apiserver,则充当负载均衡器。
外部服务上的云负载均衡器
- 由某些云提供商提供(例如 AWS ELB、Google Cloud Load Balancer)
- 当 Kubernetes Service 的类型为
LoadBalancer
时自动创建 - 仅使用 UDP/TCP
- 实现因云提供商而异。
Kubernetes 用户通常无需担心除前两种类型以外的任何代理。集群管理员通常会确保后几种类型的代理配置正确。