kubernetes - 什么时候需要 kubectl 代理？

Question

我正在学习 Kubernetes tutorial 的第二个模块我很困惑什么时候 kubectl proxy是必要的。

我感到困惑的原因是，在本教程中，可以使用命令 kubectl run kubernetes-bootcamp --image=gcr.io/google-samples/kubernetes-bootcamp:v1 --port=8080 创建部署(即将 Docker 镜像部署为 Pod 中的容器)。在我们设置代理之前。部署镜像似乎需要访问节点。

该教程说“默认情况下，[pods，即容器组]在同一个 kubernetes 集群内的其他 pods 和服务中是可见的，但在该网络之外是不可见的。”因此，它指示我们使用 kubectl proxy 设置代理。在我们尝试之前 curl一个 pod 直接(例如使用 curl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME/proxy/ )。然而，我们已经能够在没有代理的情况下部署这些 pod。我们可以部署它们但不能查询它们似乎很奇怪。

同样，本教程还让我们在尝试使用 Kubernetes API 获取版本之前设置代理 curl http://localhost:8001/version (我相信 localhost:8001 是代理)。然而，早些时候我们可以使用 kubectl version 在没有代理的情况下查询版本。 , 返回 kubectl 的版本和 主节点上的 Kubernetes。

有人能解释一下这些明显的矛盾吗？

Answer 1

运行时 kubectl命令，CLI 正在确定 Kubernetes API 服务器的地址、用于验证服务器证书的 CA(以确保您正在与受信任的服务器对话，而不是某些中间人)和您的客户端凭据来自 kubeconfig 文件(使用 mTLS 建立到服务器的加密、经过身份验证的连接)，该文件位于 ~/.kube/config默认情况下。您可以 cat教程中的该文件以查看其中的内容:

$ cat ~/.kube/config
apiVersion: v1
clusters:
- cluster:
    certificate-authority: /root/.minikube/ca.crt
    server: https://172.17.0.26:8443
  name: minikube
contexts:
- context:
    cluster: minikube
    user: minikube
  name: minikube
current-context: minikube
kind: Config
preferences: {}
users:
- name: minikube
  user:
    client-certificate: /root/.minikube/client.crt
    client-key: /root/.minikube/client.key

您可以在没有代理的情况下执行本教程中发生的等效操作，如下所示:

$ curl \
    --cacert /root/.minikube/ca.crt \
    --cert /root/.minikube/client.crt \
    --key /root/.minikube/client.key \
    https://172.17.0.26:8443/api/v1/namespaces/default/pods/$POD_NAME/proxy/
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-6bf84cb898-5gzp5 | v=1

可以看到，运行proxy命令后，得到的需要运行的curl命令更加简单方便:

curl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME/proxy/

您无需费心计算 API 服务器的地址或处理所有这些证书和 key ，您只需连接到 localhost 并且在那里运行的本地代理处理与 API 的安全、经过身份验证的连接并代理来自API 服务器返回给您。

现在，您需要与 Kubernetes API 进行的大多数交互都可以直接通过 kubectl 完成。命令，很少需要 curl直接API。当您发出 kubectl run 时，您会看到这一点。或 kubectl version命令。事实上，你观察到你后来通过 curl 找到了版本信息。 ，但您实际上并不需要这样做，因为您可以直接运行 kubectl version .

所以你可能只会使用 kubectl proxy当您需要时 curl直接使用Kubernetes API，因为没有原生 kubectl命令，让您可以随心所欲地做您想做的事，并且在您喜欢不那么复杂的便利时 curl带有所有证书标志等的命令。

好的，但是你什么时候真的需要 curl直接API？再说一次，通常永远不会。但是，除了作为用于创建和删除 Kubernetes 资源(pod、部署、服务、pvcs 等)的 RESTful API 之外，该 API 还做的一件事是它充当内部容器网络的代理。开箱即用，无法将流量发送到您在教程中运行的容器，除非通过位于 /api/v1/namespaces/default/pods/$POD_NAME/proxy/ 的 Kubernetes API 提供的代理端点。 .

StackOverflow question您在问题的评论中链接到的答案已被接受，该答案解释了将流量发送到正在运行的容器的其他几种方法。对于实际应用程序，您可能希望使用 Kubernetes API 服务器本身上的代理端点以外的其他东西，但代理端点是通过网络与已部署容器进行交互的一种快速简便的方法，因此它在设置更强大和复杂的基础设施来处理容器的入口流量之前，您可能希望在开发生命周期的早期做一些事情。

所以把它们放在一起: 当您已将 Web 应用程序部署到 Kubernetes 和 您想向它发送请求 和 您(还)不想设置一些更复杂但更强大的方法来获取容器的入口流量，您可以使用位于 /api/v1/namespaces/default/pods/$POD_NAME/proxy/ 的容器网络代理 API。 Kubernetes API 服务器。没有 kubectl将为您命中该端点的命令，因此您必须直接 curl 它(或在浏览器中打开它)。 当您要 curl任何 Kuberentes 服务器 API 端点直接 和 您不想将一堆标志传递给您的 curl命令，然后运行 ​​ kubectl proxy让您运行更简单 curl指向该本地代理的命令，这些命令会将您的请求代理到 Kubernetes API。

最后要注意的是，这里有两个完全不同的代理。一种是本地代理，将您的请求代理到 Kuberentes API 服务器的任何端点。 Kubernetes API 服务器拥有的一个这样(类型的)端点本身就是一个代理，进入部署容器的内部网络。 (更进一步，容器网络内部有代理可以让事情在幕后工作，但为了简单起见，没有必要在这个答案中讨论它们)。不要混淆这两个代理。