logo
搜索
我的图书馆

发文章

发文工具

其他工具

留言交流
搜索
分享

​调试必备！详解 HTTP 客户端调用 K8S API，建议收藏！

 滔滔江水向哪流 2022-07-12 发布于山东

后台回复【资料包】获取学习资料

使用 CLI（如 curl）或 GUI（如 postman ）HTTP 客户端调用 Kubernetes API 有很多原因。例如，您可能需要对 Kubernetes 对象进行比 kubectl 提供的更细粒度的控制，或者只是想在尝试从代码访问 API 之前进行探索。

本文不仅仅是一个方便的命令列表，而是一个深思熟虑的演练，揭示了您在从命令行调用 Kubernetes API 时可能会偶然发现的一些问题。它涵盖以下内容：

  • 如何获取 Kubernetes API Server 地址
  • 如何向客户端验证 API Server
  • 如何使用证书向 API Server 验证客户端
  • 如何使用令牌向 API Server 验证客户端
  • 如何从 Pod 内部调用 Kubernetes API
  • 如何使用 curl 对 Kubernetes 对象执行基本的 CRUD 操作
  • 如何使用 kubectl 的 raw 模式直接访问 Kubernetes API
  • 如何查看 kubectl 命令发送了哪些 API 请求（如 apply）
Image
Kubernetes API 结构

设置实验 Kubernetes 集群

如果你没有 Kubernetes 集群可以做实验，这里是你可以使用 arkade 快速创建本地实验环境：

https://github.com/alexellis/arkade

$ curl -sLS https://get.v | sudo sh
$ arkade get minikube kubectl
$ minikube start --profile cluster1

⚠️curl | sudo sh很吓人。从 Internet 获取软件包并在笔记本电脑上运行它们。由于我没有时间检查我使用的每一段开源代码，我更喜欢隔离和一次性的开发环境。

如何获取 Kubernetes API 主机和端口

要调用任何 API，您首先需要知道其服务器地址。对于 Kubernetes，每个集群都有一个 API Server。因此，查找 API 主机和端口的最简单方法是查看kubectl cluster-info输出。例如：

$ kubectl cluster-info
Kubernetes control plane is running at https://192.168.58.2:8443
...

该cluster-info命令显示在 当前上下文中选择的集群的 API 地址。

https:///docs/tasks/access-application-cluster/configure-access-multiple-clusters

但是，如果您有多个集群怎么办？查找 Kubernetes API Server 地址的另一种方法是查看 kubeconfig 内容：

https:///docs/concepts/configuration/organize-cluster-access-kubeconfig/

$ kubectl config view
apiVersion: v1
clusters:
- name: cluster1
  cluster:
    ...
    server: https://192.168.58.2:8443
- name: cluster2
  cluster:
    ...
    server: https://192.168.59.2:8443
...

默认情况下，kubectl查找目录中命名config的$HOME/.kube文件。那么，为什么不直接从这个文件中获取 API 地址呢？

原因是潜在的配置合并。KUBECONFIG通过将 env var 设置为以冒号分隔的位置列表，可以指定多个 kubeconfig 文件。kubectl在访问集群之前，会尝试将所有 kubeconfig 文件的内容合并到一个配置中。

因此，从上面的列表中选择正确的集群，让我们尝试向其 API Server 发送请求：

$ KUBE_API=$(kubectl config view -o jsonpath='{.clusters[0].cluster.server}')

如何使用 curl 调用 Kubernetes API

实际上，任何 HTTP 客户端（curl、httpie、wget 甚至 postman）都可以，但我将在本节中使用 curl。

向客户端验证 API Server

让我们从 查询 API 的/version端点开始：

$ curl $KUBE_API/version
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl./docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

🙈 上述错误实际上是有道理的。默认情况下，Kubernetes 通过 HTTPS 公开其 API，特别是为了向客户端保证 API Server 的强标识。但是，minikube 使用自签名证书引导本地集群。因此，Kubernetes API Server 的 TLS 证书原来是由 curl 未知的证书颁发机构 (CA) minikubeCA 签名的。由于 curl 无法信任它，因此请求失败。

默认情况下，curl 信任底层操作系统所信任的同一组 CA。例如，在 Ubuntu 或 Debian 上，受信任的 CA 列表可以在/etc/ssl/certs/ca-certificates.crt. 显然，minikube 不会将其证书添加到此文件中。

幸运的是，minikube 周到地将 CA 证书保存到~/.minikube/ca.crt：

$ cat ~/.minikube/ca.crt | openssl x509 -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = minikubeCA
        Validity
            Not Before: Dec 15 20:46:36 2021 GMT
            Not After : Dec 14 20:46:36 2031 GMT
        Subject: CN = minikubeCA
        Subject Public Key Info:

因此，要修复GET /version请求，只需要通过手动将其指向 minikubeCA 证书来使 curl 信任 API Server 证书的颁发者：

$ curl --cacert ~/.minikube/ca.crt $KUBE_API/version
{
  'major': '1',
  'minor': '22',
  'gitVersion': 'v1.22.3',
  'gitCommit': 'c92036820499fedefec0f847e2054d824aea6cd1',
  'gitTreeState': 'clean',
  'buildDate': '2021-10-27T18:35:25Z',
  'goVersion': 'go1.16.9',
  'compiler': 'gc',
  'platform': 'linux/amd64'
}

耶！🎉

💡提示：在安全的环境中，我更喜欢不安全模式--insecure -k，它比试图找到颁发者证书更简单。

使用证书向 API Server 验证客户端

好的，让我们尝试一些更复杂的东西。列出集群中的所有 Deployment？

$ curl --cacert ~/.minikube/ca.crt $KUBE_API/apis/apps/v1/deployments
{
  'kind': 'Status',
  'apiVersion': 'v1',
  'metadata': {

  },
  'status': 'Failure',
  'message': 'deployments.apps is forbidden: User \'system:anonymous\' cannot list resource \'deployments\' in API group \'apps\' at the cluster scope',
  'reason': 'Forbidden',
  'details': {
    'group': 'apps',
    'kind': 'deployments'
  },
  'code': 403
}

但没有获取到数据。

与明显未受保护的/version端点不同，Kubernetes 通常会限制对其 API 端点的访问。

从错误消息中可以清楚地看出，该请求已通过身份验证User 'system:anonymous'，显然，该用户未授权列出 deployment 资源。

失败的请求不包括任何身份验证方式（尽管如此，它已经过身份验证，但作为匿名用户），所以我需要提供一些额外的信息来获得所需的访问级别。

Kubernetes 支持 多种身份验证机制，下面将从使用客户端证书对请求进行身份验证开始。

https:///docs/reference/access-authn-authz/authentication/

什么是客户证书？

当 minikube 引导集群时，它还创建了一个user。该用户获得了由同一个 minikubeCA 颁发机构签署的证书。由于 Kubernetes API Server 信任此 CA，因此在请求中提供此证书将使其作为所述用户进行身份验证。

Kubernetes 没有代表user的对象。即不能通过 API 调用将用户添加到集群中。但是，任何提供由集群的证书颁发机构签名的有效证书的用户，都被视为已通过身份验证。Kubernetes 从证书subject中的通用名称字段中获取用户名（例如，CN = minikube-user）。然后，Kubernetes RBAC 子系统判断用户是否有权对资源执行特定操作。

用户证书通常可以在我们已经熟悉的kubectl config view输出中找到：

$ kubectl config view -o jsonpath='{.users[0]}' | python -m json.tool
{
  'name': 'cluster1',
  'user': {
    'client-certificate': '/home/vagrant/.minikube/profiles/cluster1/client.crt',
    'client-key': '/home/vagrant/.minikube/profiles/cluster1/client.key'
  }
}

让我们快速检查证书内容以确保它是由同一个 CA 签名的：

$ cat ~/.minikube/profiles/cluster1/client.crt | openssl x509 -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 2 (0x2)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = minikubeCA
        Validity
            Not Before: Dec 26 06:35:56 2021 GMT
            Not After : Dec 26 06:35:56 2024 GMT
        Subject: O = system:masters, CN = minikube-user

以下是如何使用curl向 Kubernetes API Server 发送由该证书认证的请求：

$ curl $KUBE_API/apis/apps/v1/deployments \
  --cacert ~/.minikube/ca.crt \
  --cert ~/.minikube/profiles/cluster1/client.crt \
  --key ~/.minikube/profiles/cluster1/client.key
{
  'kind': 'DeploymentList',
  'apiVersion': 'apps/v1',
  'metadata': {
    'resourceVersion': '654514'
  },
  'items': [...]
}

使用服务帐户 token 向 API Server 验证客户端

另一种验证 API 请求的方法是使用包含有效服务帐户 JWT 令牌的 header 头。

⚠️ 从 Kubernetes 1.24 开始，不再为每个 ServiceAccount 对象自动生成包含 Service Account 令牌的 Secret API 对象。现在获取服务帐户令牌的推荐方法是使用专用的 TokenRequest API 或相应的kubectl create token命令。。

与用户非常相似，不同的服务帐户将具有不同级别的访问权限。让我们看看使用默认命名空间中的默认服务帐户可以实现什么：

# Kubernetes <1.24
$ JWT_TOKEN_DEFAULT_DEFAULT=$(kubectl get secrets \
    $(kubectl get serviceaccounts/default -o jsonpath='{.secrets[0].name}') \
    -o jsonpath='{.data.token}' | base64 --decode)

# Kubernetes 1.24+
$ JWT_TOKEN_DEFAULT_DEFAULT=$(kubectl create token default)

从一个简单的任务开始，列出apps/v1组中已知的 API 资源类型：

$ curl $KUBE_API/apis/apps/v1/ \
  --cacert ~/.minikube/ca.crt  \
  --header 'Authorization: Bearer $JWT_TOKEN_DEFAULT_DEFAULT'
{
  'kind': 'APIResourceList',
  'apiVersion': 'v1',
  'groupVersion': 'apps/v1',
  'resources': [...]
}

让我们尝试在默认命名空间中列出实际的部署对象：

$ curl $KUBE_API/apis/apps/v1/namespaces/default/deployments \
  --cacert ~/.minikube/ca.crt  \
  --header 'Authorization: Bearer $JWT_TOKEN_DEFAULT_DEFAULT'
{
  'kind': 'Status',
  'apiVersion': 'v1',
  'metadata': {

  },
  'status': 'Failure',
  'message': 'deployments.apps is forbidden: User \'system:serviceaccount:default:default\' cannot list resource \'deployments\' in API group \'apps\' in the namespace \'default\'',
  'reason': 'Forbidden',
  'details': {
    'group': 'apps',
    'kind': 'deployments'
  },
  'code': 403
}

显然，用户system:serviceaccount:default:default甚至没有足够的能力在自己的命名空间中列出 Kubernetes 对象。

让我们尝试kube-system服务帐户：

# Kubernetes <1.24
$ JWT_TOKEN_KUBESYSTEM_DEFAULT=$(kubectl -n kube-system get secrets \
    $(kubectl -n kube-system get serviceaccounts/default -o jsonpath='{.secrets[0].name}') \
    -o jsonpath='{.data.token}' | base64 --decode)

# Kubernetes 1.24+
$ JWT_TOKEN_KUBESYSTEM_DEFAULT=$(kubectl -n kube-system create token default)

是可以列出集群级资源的：

$ curl $KUBE_API/apis/apps/v1/deployments \
  --cacert ~/.minikube/ca.crt  \
  --header 'Authorization: Bearer $JWT_TOKEN_KUBESYSTEM_DEFAULT'
{
  'kind': 'DeploymentList',
  'apiVersion': 'apps/v1',
  'metadata': {
    'resourceVersion': '656580'
  },
  'items': [...]
}

是的，按预期工作 👌

如何从 Pod 内部调用 Kubernetes API

与任何其他 Kubernetes 服务非常相似，Kubernetes API 服务地址可通过环境变量提供给 Pod：

$ kubectl run -it --image curlimages/curl --restart=Never mypod -- sh
$ env | grep KUBERNETES
KUBERNETES_SERVICE_PORT=443
KUBERNETES_PORT=tcp://10.96.0.1:443
KUBERNETES_PORT_443_TCP_ADDR=10.96.0.1
KUBERNETES_PORT_443_TCP_PORT=443
KUBERNETES_PORT_443_TCP_PROTO=tcp
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_PORT_443_TCP=tcp://10.96.0.1:443
KUBERNETES_SERVICE_HOST=10.96.0.1

Pod 通常还会将 Kubernetes CA 证书和服务帐户机密材料安装在/var/run/secrets//serviceaccount/. 因此，应用以上部分的知识，curl从 Pod 调用 Kubernetes API Server 的命令如下所示：

$ curl https://${KUBERNETES_SERVICE_HOST}:${KUBERNETES_SERVICE_PORT}/apis/apps/v1 \
  --cacert /var/run/secrets//serviceaccount/ca.crt \
  --header 'Authorization: Bearer $(cat /var/run/secrets//serviceaccount/token)'

创建、读取、查看、更新、修补和删除对象

Kubernetes API 支持对 Kubernetes Objects 进行以下操作：

GET /<resourcePlural> - Retrieve a list of type <resourceName>.


POST /<resourcePlural> - Create a new resource from the JSON
object provided by the client.

GET /<resourcePlural>/<name> - Retrieves a single resource with the
given name.

DELETE /<resourcePlural>/<name> - Delete the single resource with the
given name.

DELETE /<resourcePlural> - Deletes a list of type <resourceName>.


PUT /<resourcePlural>/<name> - Update or create the resource with the given
name with the JSON object provided by client.

PATCH /<resourcePlural>/<name> - Selectively modify the specified fields of
the resource.

GET /<resourcePlural>?watch=true - Receive a stream of JSON objects
corresponding to changes made to any
resource of the given kind over time.

API 是 RESTful 的，因此上述 HTTP 方法在资源操作上的映射应该看起来很熟悉。

即使文档仅提及JSON 对象，如果Content-Type标头设置为application/yaml.

以下是使用curl和 YAML 清单创建新对象的方法：

$ curl $KUBE_API/apis/apps/v1/namespaces/default/deployments \
  --cacert ~/.minikube/ca.crt \
  --cert ~/.minikube/profiles/cluster1/client.crt \
  --key ~/.minikube/profiles/cluster1/client.key \
  -X POST \
  -H 'Content-Type: application/yaml' \
  -d '---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sleep
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sleep
  template:
    metadata:
      labels:
        app: sleep
    spec:
      containers:
      - name: sleep
        image: curlimages/curl
        command: ['/bin/sleep', '365d']
'

以下是如何获取默认命名空间中的所有对象：

$ curl $KUBE_API/apis/apps/v1/namespaces/default/deployments \
  --cacert ~/.minikube/ca.crt \
  --cert ~/.minikube/profiles/cluster1/client.crt \
  --key ~/.minikube/profiles/cluster1/client.key

以及如何通过名称和命名空间获取对象：

$ curl $KUBE_API/apis/apps/v1/namespaces/default/deployments/sleep \
  --cacert ~/.minikube/ca.crt \
  --cert ~/.minikube/profiles/cluster1/client.crt \
  --key ~/.minikube/profiles/cluster1/client.key

一种更高级的检索 Kubernetes 资源的方法是持续观察它们的变化：

$ curl $KUBE_API/apis/apps/v1/namespaces/default/deployments?watch=true \
  --cacert ~/.minikube/ca.crt \
  --cert ~/.minikube/profiles/cluster1/client.crt \
  --key ~/.minikube/profiles/cluster1/client.key

请注意，只能监视一组资源。但是，您可以通过提供标签或字段选择器将结果集缩小到单个资源。

以下是更新现有对象的方法：

$ curl $KUBE_API/apis/apps/v1/namespaces/default/deployments/sleep \
  --cacert ~/.minikube/ca.crt \
  --cert ~/.minikube/profiles/cluster1/client.crt \
  --key ~/.minikube/profiles/cluster1/client.key \
  -X PUT \
  -H 'Content-Type: application/yaml' \
  -d '---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sleep
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sleep
  template:
    metadata:
      labels:
        app: sleep
    spec:
      containers:
      - name: sleep
        image: curlimages/curl
        command: ['/bin/sleep', '730d']  # <-- Making it sleep twice longer
'

以下是如何修补现有对象：

$ curl $KUBE_API/apis/apps/v1/namespaces/default/deployments/sleep \
  --cacert ~/.minikube/ca.crt \
  --cert ~/.minikube/profiles/cluster1/client.crt \
  --key ~/.minikube/profiles/cluster1/client.key \
  -X PATCH \
  -H 'Content-Type: application/merge-patch+json' \
  -d '{
  'spec': {
    'template': {
      'spec': {
        'containers': [
          {
            'name': 'sleep',
            'image': 'curlimages/curl',
            'command': ['/bin/sleep', '1d']
          }
        ]
      }
    }
  }
}'

请注意UPDATE和PATCH是相当棘手的操作。第一个受到各种版本冲突的影响，第二个的行为因使用的补丁策略而异。

以下是如何删除对象集合：

$ curl $KUBE_API/apis/apps/v1/namespaces/default/deployments \
  --cacert ~/.minikube/ca.crt \
  --cert ~/.minikube/profiles/cluster1/client.crt \
  --key ~/.minikube/profiles/cluster1/client.key \
  -X DELETE

以下是如何删除单个对象：

$ curl $KUBE_API/apis/apps/v1/namespaces/default/deployments/sleep \
  --cacert ~/.minikube/ca.crt \
  --cert ~/.minikube/profiles/cluster1/client.crt \
  --key ~/.minikube/profiles/cluster1/client.key \
  -X DELETE

如何使用 kubectl 调用 Kubernetes API

上面带有证书和 token 的方法很有趣。通过上面的练习，可以巩固对客户端和服务端的理解。

使用 kubectl proxy 调用 Kubernetes API

使用正确配置的kubectl工具，您可以通过使用kubectl proxy命令大大简化 API 访问。

为什么还要直接调用 Kubernetes API？🤔

原因很多。例如，您可能正在开发一个控制器并希望在不编写额外代码的情况下使用 API 查询。或者，您可能对kubectl操纵资源时的幕后操作不满意，您希望对 Kubernetes 对象上的操作进行更细粒度的控制。

kubectl proxy命令在您的 localhost 和 Kubernetes API Server 之间创建一个代理服务器（或应用程序级网关） 。但它所做的并不止于此。不然怎么会这么方便？

kubectl proxy 从调用者那里接管了相互的客户端~服务器身份验证责任。由于调用者和代理之间的通信是通过localhost进行的，因此它被认为是安全的。代理本身使用 kubeconfig 文件中选择的当前上下文中的信息来处理客户端~服务器身份验证。

$ kubectl config current-context
cluster1

$ kubectl proxy --port=8080 &

启动代理服务器后，调用 Kubernetes API Server 就变得简单多了：

$ curl localhost:8080/apis/apps/v1/deployments
{
  'kind': 'DeploymentList',
  'apiVersion': 'apps/v1',
  'metadata': {
    'resourceVersion': '660883'
  },
  'items': [...]
}

使用 kubectl raw 模式调用 Kubernetes API

我最近学到的另一个很酷的技巧是kubectl命令支持的raw 模式：

# Sends HTTP GET request
$ kubectl get --raw /api/v1/namespaces/default/pods

# Sends HTTP POST request
$ kubectl create --raw /api/v1/namespaces/default/pods -f file.yaml

# Sends HTTP PUT request
$ kubectl replace --raw /api/v1/namespaces/default/pods/mypod -f file.json

# Sends HTTP DELETE request
$ kubectl delete --raw /api/v1/namespaces/default/pods

kubectl 是一个非常先进的工具，即使是简单的命令，比如kubectl get背后也有大量的代码。但是，当使用该--raw标志时，实现归结为将唯一的参数转换为 API 端点 URL 并调用原始 REST API 客户端。

这种方法的一些优点是：

  • 意味着命令将使用原始 REST API 客户端，使用相同的身份验证（在 kubeconfig 文件中配置的任何内容）
  • -f这些命令通过标志支持传统的基于文件的清单输入。

但也有一个缺点：我找不到任何PATCH或WATCH支持，因此curl访问为您提供了更多功能。

Kubernetes API 调用等效于 kubectl 命令

我已经多次提到您可能对特定kubectl命令发出的实际请求序列不满意。但是你不读代码怎么能知道这个序列呢？

这是一个不错的技巧：您可以将-v 6标志添加到任何kubectl命令，日志将变得如此冗长，以至于您将开始看到向 Kubernetes API Server 发出的 HTTP 请求。

例如，您可以通过这种方式了解到该kubectl scale deployment命令是通过对子资源的PATCH请求实现的/deployments/<name>/scale：

$ kubectl scale deployment sleep --replicas=2 -v 6
I0116 ... loader.go:372] Config loaded from file:  /home/vagrant/.kube/config
I0116 ... cert_rotation.go:137] Starting client certificate rotation controller
I0116 ... round_trippers.go:454] GET https://192.168.58.2:8443/apis/apps/v1/namespaces/default/deployments/sleep 200 OK in 14 milliseconds
I0116 ... round_trippers.go:454] PATCH https://192.168.58.2:8443/apis/apps/v1/namespaces/default/deployments/sleep/scale 200 OK in 12 milliseconds
deployment.apps/sleep scaled

看看kubectl apply -v 6，结果可能非常有见地 😉

想查看实际的请求和响应主体吗？将日志级别增加到8。

总结

第一次访问 Kubernetes API 的需求可能很头疼，有很多新概念，如资源、API 组、种类、对象、集群、上下文、证书！但是一旦你在构建块上分解它并通过执行一些琐碎的任务（比如找出 API Server 地址或使用 curl 调用一堆端点）获得一些实践经验，你很快就会意识到这并不是新的东西，它只是多年来为我们服务的众所周知的 REST 架构风格、TLS 证书、JWT 令牌、对象方案等机制的组合。

原文：

https:///en/posts/kubernetes-api-call-simple-http-client/

    本站是提供个人知识管理的网络存储空间，所有内容均由用户发布，不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息，谨防诈骗。如发现有害或侵权内容，请点击一键举报。
    转藏 分享 献花（0）

    来自： 滔滔江水向哪流 > 《电脑》

    举报/认领

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多