forked from pivotal-cf/docs-pks
-
Notifications
You must be signed in to change notification settings - Fork 0
/
about-lb.html.md.erb
86 lines (53 loc) · 6.65 KB
/
about-lb.html.md.erb
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
---
title: Load Balancers in PKS
owner: PKS
---
<strong><%= modified_date %></strong>
This topic describes the types of load balancers that are used in Pivotal Container Service (PKS) deployments. Load balancers differ by the type of deployment.
## <a id='without-nsx-t'></a>Load Balancers in PKS Deployments without NSX‑T
For PKS deployments on GCP, AWS, or vSphere without NSX-T, you can configure load balancers for the following:
* **PKS API**: Configuring this load balancer allows you to run PKS Command Line Interface (CLI) commands from your local workstation.
* **Kubernetes Clusters**: Configuring a load balancer for each new cluster allows you to run Kubernetes CLI (kubectl) commands on the cluster.
* **Workloads**: Configuring a load balancer for your application workloads allows external access to the services that run on your cluster.
The following diagram shows where each of the above load balancers can be used within your PKS deployment on GCP, AWS, or on vSphere without NSX-T:
<%= image_tag("pks-diagram-lb.png", :alt => "PKS diagram including all load balancer options for PKS deployments without NSX-T") %>
If you use either vSphere without NSX-T or GCP, you are expected to create your own load balancers within your cloud provider console. If your cloud provider does not offer load balancing, you can use any external TCP or HTTPS load balancer of your choice.
### <a id='pks-api'></a>About the PKS API Load Balancer
For PKS deployments on GCP, AWS, and on vSphere without NSX-T, the load balancer for the PKS API allows you to access the PKS API from outside the network.
For example, configuring a load balancer for the PKS API allows you to run PKS CLI commands from your local workstation.
For information about configuring the PKS API load balancer, see the [Configure External Load Balancer](installing-pks-vsphere.html#loadbalancer-pks-api) section of <em>Installing PKS</em> for your IaaS.
### <a id='cluster'></a>About Kubernetes Cluster Load Balancers
For PKS deployments on GCP, AWS, and on vSphere without NSX-T, when you create a cluster, you must configure external access to the cluster by creating an external TCP or HTTPS load balancer.
The load balancer allows the Kubernetes CLI to communicate with the cluster.
If you create a cluster in a non-production environment, you can choose not to use a load balancer.
To allow kubectl to access the cluster without a load balancer, you can do one of the following:
* Create a DNS entry that points to the cluster's master VM. For example: <pre>my-cluster.example.com A 10.0.0.5</pre>
* On the workstation where you run kubectl commands, add the master IP address of your cluster and `kubo.internal` to the `/etc/hosts` file. For example: <pre>10.0.0.5 kubo.internal</pre>
For more information about configuring a cluster load balancer, see the following:
* [Creating and Configuring a GCP Load Balancer for PKS Clusters](gcp-cluster-load-balancer.html)
* [Creating and Configuring an AWS Load Balancer for PKS Clusters](aws-cluster-load-balancer.html)
* [Creating and Configuring an Azure Load Balancer for PKS Clusters](azure-cluster-load-balancer.html)
### <a id='workload'></a>About Workload Load Balancers
For PKS deployments on GCP, AWS, and on vSphere without NSX-T, to allow external access to your app, you can either create a load balancer or expose a static port on your workload.
For information about configuring a load balancer for your app workload, see [Deploying and Accessing Basic Workloads](deploy-workloads.html).
If you use AWS, you must configure routing in the AWS console before you can create a load balancer for your workload.
You must create a public subnet in each availability zone (AZ) where you are deploying the workload and tag the public subnet with your cluster's unique identifier.
See the [AWS Prerequisites](deploy-workloads.html#aws) section of _Deploying and Accessing Basic Workloads_ before you create a workload load balancer.
## <a id='with-nsx-t'></a>Load Balancers in PKS Deployments on vSphere with NSX‑T
PKS deployments on vSphere with NSX-T do not require a load balancer configured to access the PKS API.
They require only a DNAT rule configured so that the PKS API host is accessible.
For more information, see [Share the PKS Endpoint](installing-nsx-t.html#retrieve-endpoint) in _Installing PKS on vSphere with NSX-T Integration_.
NSX-T handles load balancer creation, configuration, and deletion automatically as part of the Kubernetes cluster create, update, and delete process.
When a new Kubernetes cluster is created, NSX-T creates and configures a dedicated load balancer tied to it. The load balancer is a shared resource designed to provide efficient traffic distribution to master nodes as well as services deployed on worker nodes.
Each application service is mapped to a virtual server instance, carved out from the same load balancer.
For more information, see [Logical Load Balancer](https://docs.vmware.com/en/VMware-NSX-T/2.1/com.vmware.nsxt.admin.doc/GUID-46567C8D-A5C5-4793-8CDF-858E58FDE3C4.html) in the NSX-T documentation.
Virtual server instances are created on the load balancer to provide access to the following:
* **Kubernetes API and UI services on a Kubernetes cluster**. This allows requests to be load balanced across multiple master nodes.
* **Ingress controller**. This allows the virtual server instance to dispatch HTTP and HTTPS requests to services associated with Ingress rules.
* `type:loadbalancer` **services**. This allows the server to handle TCP connections or UDP flows toward exposed services.
Load balancers are deployed in high-availability mode so that they are resilient to potential failures and able to recover quickly from critical conditions.
<p class="note"><strong>Note</strong>: The <code>NodePort</code> Service type is not supported for PKS deployments on vSphere with NSX-T. Only <code>type:LoadBalancer</code>Services and Services associated with Ingress rules are supported on vSphere with NSX-T.</p>
### <a id='resize-lb'></a> Resizing Load Balancers
When a new Kubernetes cluster is provisioned using the PKS API, NSX-T creates a dedicated load balancer for that new cluster. By default, the size of the load balancer is set to Small.
With network profiles, you can change the size of the load balancer deployed by NSX-T at the time of cluster creation. For information about network profiles, see [Using Network Profiles (NSX-T Only)](network-profiles.html).
For more information about the types of load balancers NSX-T provisions and their capacities, see [Scaling Load Balancer Resources](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/2.3/com.vmware.nsxt.admin.doc/GUID-19B12230-8BF4-4AF7-9EB7-3701B0A0A439.html) in the NSX-T documentation.