amazon-web-services - Kubernetes 中的真正负载平衡？

Question

什么是负载均衡器？

Load balancing improves the distribution of workloads across multiple computing resources, such as computers, a computer cluster, network links, central processing units, or disk drives

节点端口

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

入口服务

同样，假设部署了入口 Controller 和入口服务。我们在 ingress-service 中指定的子域应该指向 K8s 集群中的“a”节点，然后 ingress-controller 负载均衡 pod 之间的流量。这里也有最终用户使用单个节点，它是 K8s 的仆从，但一个真正的负载均衡器，对吧？

来自云提供商的负载均衡器(例如 AWS ELB)

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

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

我可以在 K8s 中实现真正的负载均衡吗？我问了相关 question here

Answer 1

NodePort is not load balancer.

从某种意义上说，您是对的，是的，它并非旨在成为负载均衡器。

users still hits a single node i.e. the "Node" which is K8s's minion but a real Load Balancer, right?

使用 NodePort，您必须在任何时间访问单个节点，但您必须记住 kube-proxy正在所有节点上运行。因此，您可以访问集群中任何节点上的 NodePort(即使是工作负载未在其上运行的节点)，并且您仍然会访问您想要访问的端点。这在以后变得很重要。

The sub-domain that we specify in ingress-service should points to "a" node in K8s cluster

不，这不是它的工作方式。

您的入口 Controller 仍然需要对外公开。如果您使用的是云提供商，则常用的模式是使用 Type=LoadBalancer 的服务公开您的入口 Controller 。 .负载平衡仍然发生在服务中，但 Ingress 允许您以更用户友好的方式使用该服务。不要将入口与负载平衡混淆。

I'm having a doubt how cloud provider LB does the load balancing? Are those really distribute the traffic to appropriate Node which PODS are deployed or just forwarding the traffic to master node or minion?

如果您查看 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 的入口 Controller 。这已经创建了一个 AWS ELB，但也请注意，例如 NodePort它将入口 Controller pod 上的端口 80 映射到端口 32394 .

那么，让我们看看 AWS 中实际的 LoadBalancer:

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 映射到 NodePort:

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

您还会看到有多个目标 Instances ， 不是一个:

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 确实使用服务(无论是 NodePort 还是 LoadBalancer 类型)实现了真正的负载均衡，并且入口只是使该服务更容易被外界访问