google-compute-engine - Google Container Engine Kubernetes服务LoadBalancer是否将流量发送到无响应的主机？

Question

问题:由Kubernetes(通过Google Container Engine)创建的Google Cloud网络LoadBalancer是否将流量发送到未监听的主机？ “此目标池没有运行状况检查，因此流量将发送到所有实例，无论其状态如何。”

我有一个针对特定容器的服务(NGINX反向代理)，并使TCP:80，443可用。在我的示例中，实例池中仅运行1个NGINX Pod。服务类型为“LoadBalancer”。使用Google Container Engine，这将创建一个新的LoadBalancer(LB)，以指定目标池，特定的VM实例。然后，创建LB的临时外部IP地址以及允许传入流量的关联防火墙规则。

我的问题是，Kubernetes自动生成的防火墙规则描述为“KubernetesAutoGenerated_OnlyAllowTrafficForDestinationIP_1.1.1.1”(IP是LB外部IP)。在测试中，我注意到即使每个VM实例都具有一个外部IP地址，我也无法通过任一实例IP地址(仅LB IP)的端口80或443与它联系。这对于外部用户流量来说还不错，但是当我尝试为LB创建运行状况检查时，我发现当单独检查每个VM实例时，该服务始终会显示服务不可用。

我有正确的防火墙规则，以便任何IP地址都可以与我池中任何实例上的TCP 443、80联系，所以这不是问题。

有人可以向我解释一下，因为这使我认为LB正在将HTTP请求传递给两个实例，尽管其中只有一个实例正在运行NGINX pod。

Answer 1

Is the Google Cloud network LoadBalancer that's created by Kubernetes (via Google Container Engine) sending traffic to hosts that aren't listening?

所有主机(当前正在运行功能性kube-proxy进程)都能够接收和处理对外部化服务的传入请求。这些请求将落在集群中的任意节点VM上，与iptables规则匹配，然后转发(通过kube-proxy进程)到具有与服务匹配的标签选择器的pod。

因此，运行状况检查器可以防止请求被丢弃的情况是，如果节点VM运行于损坏状态。 VM仍将具有与转发规则匹配的目标标签，但将无法处理传入的数据包。

In testing I've noticed that even though each VM Instance has a external IP address I cannot contact it on port 80 or 443 on either of the instance IP addresses, only the LB IP.

这按预期工作。每个服务都可以使用所需的任何端口，这意味着多个服务可以使用端口80和443。如果数据包到达端口80上的主机IP，则主机无法知道使用端口中的哪个(可能很多)服务80数据包应转发到。服务的iptables规则处理发往虚拟内部群集服务IP和外部服务IP而不是主机IP的数据包。

This isn't bad for external user traffic but when I tried to create a Health Check for my LB I found that it always saw the services as unavailable when it checked each VM Instance individually.

如果要设置运行状况检查以验证节点是否正常运行，则可以通过安装防火墙规则对运行在 10250端口上的kubelet进程进行运行状况检查:

$ gcloud compute firewall-rules create kubelet-healthchecks \
  --source-ranges 130.211.0.0/22 \
  --target-tags $TAG \
  --allow tcp:10250

(查看 Container Engine HTTP Load Balancer文档，以帮助查找 $TAG应该使用的内容)。

最好直接对kube-proxy进程进行健康检查，但只检查 binds to localhost，而kubelet进程 binds to all interfaces则可以被健康检查程序访问，因此它可以很好地指示节点是否足够健康以服务于请求您的服务。