库伯内特斯的真正负载平衡？

Question

什么是负载均衡器？

负载平衡改进了跨多个计算资源（如计算机、计算机群集、网络链路、中央处理器或磁盘驱动器）的工作负载分布

NodePort不是负载平衡器。（我知道一旦流量在集群内，kube proxy就会在pod之间进行负载平衡）我的意思是，最终用户点击http://NODEIP:30111（例如）访问应用程序的URL。即使POD之间的流量是负载平衡的，用户仍然会点击一个节点，即“节点”，它是K8s的仆从，但却是一个真正的负载平衡器，对吗？

这里也一样，想象入口控制器和入口服务也被部署了。我们在入口服务中指定的子域应该指向K8s集群中的“a”节点，然后入口控制器负载平衡Pod之间的流量。这里还有最终用户访问单个节点，它是K8s的小弟，但却是真正的负载均衡器，对吗？

我有一个疑问，云提供商的LB如何进行负载平衡？这些是真的将流量分配到部署PODS的适当节点，还是只是将流量转发到主节点或小节点？

如果上述点为真。真正的负载平衡pod/适当节点之间的流量在哪里。

我可以在K8s中实现真正的负载平衡吗？我在这里问了一个相关的问题

Answer 1

从你所说的和我用K8S研究了2个月的情况来看。当您只运行1个实例时，这里似乎没有负载平衡器。当我们扩展工作负载时，我们需要扩展包括POD在内的所有内容。

• 这里我们有Service，默认情况下它会LOAD-BALANCE（Round-Robin）Replica-Set of Pods之间的流量。这是真正的重任务卸载。就高可用性而言，每个节点应至少包含1个副本Pod。
• 对于入口控制器，例如：NGINX。从本质上讲，NGINX在到达其目的地的网络流量上启用负载平衡。但您只将1个入口规则指向1个特定服务。比如，谁会把这个带有入口规则的NGINX指向具有相同功能的2个服务？？？你不能！！！因为入口控制器只会获取每1条规则只有一个服务的详细信息。并将服务endpoint用于Pods负载平衡。这是入口控制器启用的负载平衡功能。
• 对于云提供商环境中的服务[Type=LoadBalancer]。它将创建负载均衡器实例，并使用来自Cluster Service的信息（包括所有pod详细信息）因此，为集群中的每个Pods启用负载平衡。
• 入口控制器[Type=LoadBalancer]怎么样。好吧，因为您的入口控制器可以在多个节点内运行。对外部负载均衡器的每个请求都将Load-Balance对入口控制器的所有Pods的请求。这些入口控制器将继续Load-Balance对所有服务endpoint的请求，也称为pods。

Answer 2

NodePort不是负载均衡器。

在某种程度上，您是对的，是的，它不是为负载平衡器而设计的。

用户仍然会访问单个节点，即“节点”，它是K8s的仆从，但却是真正的负载平衡器，对吗？

使用NodePort，您必须在任何时候命中单个节点，但您必须记住，kube代理正在所有节点上运行。因此，您可以点击集群中任何节点上的NodePort（即使没有运行工作负载的节点），但仍然会点击要点击的endpoint。这在以后变得很重要。

我们在入口服务中指定的子域应该指向K8s集群中的“a”节点

不，事情不是这样的。

您的入口控制器仍然需要在外部公开。如果您使用的是云提供商，一种常用的模式是使用Service ofType=LoadBalancer公开您的入口控制器。服务仍然会发生负载平衡，但入口允许您以更用户友好的方式使用该服务。不要混淆入口和负载平衡。

我怀疑云提供商LB如何进行负载平衡？这些是真的将流量分配到部署PODS的适当节点，还是只是将流量转发到主节点或小节点？

如果您查看Kubernetes中的配置服务，就会明白为什么它是有意义的。

以下是LoadBalancer类型的服务：

kubectl get svc nginx-ingress-controller -n kube-system                                                                    
NAME                       TYPE           CLUSTER-IP      EXTERNAL-IP        PORT(S)                      AGE
nginx-ingress-controller   LoadBalancer   <redacted>   internal-a4c8...   80:32394/TCP,443:31281/TCP   147d

您可以看到，我部署了一个类型为LoadBalancer的入口控制器。这创建了一个AWS ELB，但也需要注意，例如，它将入口控制器pod上的端口80映射到端口32394。

那么，让我们看看AWS中的实际负载平衡器：

aws elb describe-load-balancers --load-balancer-names a4c80f4eb1d7c11e886d80652b702125

{
    "LoadBalancerDescriptions": [
        {
            "LoadBalancerName": "a4c80f4eb1d7c11e886d80652b702125",
            "DNSName": "internal-a4c8<redacted>",
            "CanonicalHostedZoneNameID": "<redacted>",
            "ListenerDescriptions": [
                {
                    "Listener": {
                        "Protocol": "TCP",
                        "LoadBalancerPort": 443,
                        "InstanceProtocol": "TCP",
                        "InstancePort": 31281
                    },
                    "PolicyNames": []
                },
                {
                    "Listener": {
                        "Protocol": "HTTP",
                        "LoadBalancerPort": 80,
                        "InstanceProtocol": "HTTP",
                        "InstancePort": 32394
                    },
                    "PolicyNames": []
                }
            ],
            "Policies": {
                "AppCookieStickinessPolicies": [],
                "LBCookieStickinessPolicies": [],
                "OtherPolicies": []
            },
            "BackendServerDescriptions": [],
            "AvailabilityZones": [
                "us-west-2a",
                "us-west-2b",
                "us-west-2c"
            ],
            "Subnets": [
                "<redacted>",
                "<redacted>",
                "<redacted>"
            ],
            "VPCId": "<redacted>",
            "Instances": [
                {
                    "InstanceId": "<redacted>"
                },
                {
                    "InstanceId": "<redacted>"
                },
                {
                    "InstanceId": "<redacted>"
                },
                {
                    "InstanceId": "<redacted>"
                },
                {
                    "InstanceId": "<redacted>"
                },
                {
                    "InstanceId": "<redacted>"
                },
                {
                    "InstanceId": "<redacted>"
                },
                {
                    "InstanceId": "<redacted>"
                }
            ],
            "HealthCheck": {
                "Target": "TCP:32394",
                "Interval": 10,
                "Timeout": 5,
                "UnhealthyThreshold": 6,
                "HealthyThreshold": 2
            },
            "SourceSecurityGroup": {
                "OwnerAlias": "337287630927",
                "GroupName": "k8s-elb-a4c80f4eb1d7c11e886d80652b702125"
            },
            "SecurityGroups": [
                "sg-8e0749f1"
            ],
            "CreatedTime": "2018-03-01T18:13:53.990Z",
            "Scheme": "internal"
        }
    ]
}

这里需要注意的最重要的事情是：

LoadBalancer正在将ELB中的端口80映射到节点端口：

{
                "Listener": {
                    "Protocol": "HTTP",
                    "LoadBalancerPort": 80,
                    "InstanceProtocol": "HTTP",
                    "InstancePort": 32394
                },
                "PolicyNames": []
 }

您还将看到有多个目标实例，而不是一个：

aws elb describe-load-balancers --load-balancer-names a4c80f4eb1d7c11e886d80652b702125 | jq '.LoadBalancerDescriptions[].Instances | length'
8

最后，如果您查看我的集群中的节点数量，您会看到它实际上是添加到LoadBalancer的所有节点：

kubectl get nodes -l "node-role.kubernetes.io/node=" --no-headers=true | wc -l                                             
8

因此，总之，Kubernetes确实使用服务（无论是节点端口还是负载平衡器类型）实现了真正的负载平衡，而入口只是让外部世界更容易访问该服务