Question

我正在尝试使用this，我注意到我在理解方面存在差异，即在一个pod中运行kubectl proxy与在另一个pod中运行它之间

示例配置在守护进程的同一个pod中运行kubectl proxy和需要它的容器，即

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
# ...
spec:
  template:
    metadata:
    # ...
    spec:
      containers:

      # this container needs kubectl proxy to be running:
      - name: l5d
        # ...

      # so, let's run it:
      - name: kube-proxy
        image: buoyantio/kubectl:v1.8.5
        args:
         - "proxy"
         - "-p"
         - "8001"

在我的群集上执行此操作时，我得到了预期的行为。但是，我将运行其他需要kubectl proxy的服务，因此我认为我将其合理化为自己的守护进程集以确保它在所有节点上运行。因此，我删除了kube-proxy容器并部署了以下守护程序集：

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: kube-proxy
  labels:
    app: kube-proxy
spec:
  template:
    metadata:
      labels:
        app: kube-proxy
    spec:
      containers:
      - name: kube-proxy
        image: buoyantio/kubectl:v1.8.5
        args:
        - "proxy"
        - "-p"
        - "8001"

换句话说，与先前相同的容器配置，但现在在每个节点上的独立窗格中运行，而不是在同一窗格内。使用这种配置“东西不再起作用”**。

我意识到解决方案（至少现在）只是在任何需要它的pod中运行kube-proxy容器，但我想知道为什么我需要它。为什么不只是在一个守护进程中运行它？

我试图找到有关像这样运行kubectl proxy的更多信息，但是我的搜索结果淹没了关于运行它以从本地环境访问远程群集的结果，即根本不是我所追求的

我包含这些细节不是因为我认为它们是相关的，而是因为它们可能即使我确信它们不是：

*）一个Linkerd入口控制器，但我认为这是无关紧要的

**）在这种情况下，“工作”状态是入口控制器抱怨目的地未知，因为没有匹配的入口规则，而“不工作”状态是网络超时。

Answer 1

即在一个pod中运行kubectl代理与在另一个pod中运行它之间。

假设您的群集具有软件定义的网络，例如法兰绒或印花布，则Pod具有自己的IP，并且Pod中的所有容器共享相同的网络空间。因此：

containers:
- name: c0
  command: ["curl", "127.0.0.1:8001"]
- name: c1
  command: ["kubectl", "proxy", "-p", "8001"]

会起作用，而在DaemonSet中，根据定义它们不在同一个Pod中，因此上面的假设c0需要使用DaemonSet的Pod＆＃ 39;要联系800的IP 1.由于默认情况下kubectl proxy 仅侦听127.0.0.1这一事实，故事变得更加复杂，因此您需要更改DaemonSet＆＃39; s Pod kubectl proxy包括--address='0.0.0.0' --accept-hosts='.*'甚至允许这种跨Pod通信。我相信您还需要在DaemonSet配置中声明ports:数组，因为您现在将该端口暴露给集群，但是我必须仔细检查ports:是否只是礼貌，或实际上是必需的。

从同一个pod运行kubectl代理到同一节点上的不同pod - 有什么区别？

1 个答案: