-
Notifications
You must be signed in to change notification settings - Fork 68
/
Copy pathabout-lb.html.md.erb
125 lines (84 loc) · 9.41 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
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
---
title: Load Balancers in Tanzu Kubernetes Grid Integrated Edition
owner: TKGI
---
This topic describes the VMware Tanzu Kubernetes Grid Integrated Edition (TKGI) load balancers for the TKGI API and TKGI clusters and workloads.
<br>
<br>
## <a id='overview'></a>Overview
Load balancers used with TKGI differ by the type of deployment:
* [Load Balancers in Tanzu Kubernetes Grid Integrated Edition Deployments without NSX](#without-nsx-t)
* [Load Balancers in Tanzu Kubernetes Grid Integrated Edition Deployments on vSphere with NSX](#with-nsx-t)
<br>
<br>
## <a id='without-nsx-t'></a>Load Balancers in Tanzu Kubernetes Grid Integrated Edition Deployments without NSX
For Tanzu Kubernetes Grid Integrated Edition deployments on AWS or vSphere without NSX, you can configure load balancers for the following:
* **[TKGI API Load Balancer](#tkgi-api)**: Configuring this load balancer enables you to run TKGI Command Line Interface (TKGI CLI) commands from your local workstation.
* **[Kubernetes Cluster Load Balancers](#cluster)**: Configuring a load balancer for each new cluster enables you to run Kubernetes CLI (kubectl) commands on the cluster.
* **[Workload Load Balancers)](#workload)**: Configuring a load balancer for your application workloads enables external access to the services that run on your cluster.
The following diagram, applicable to AWS and vSphere without NSX, shows where each of the above load balancers can be used
within your Tanzu Kubernetes Grid Integrated Edition deployment.
<%= image_tag("images/lb-diagram.png", :alt => "TKGI load balancer diagram including all load balancer options for TKGI deployments without NSX") %>
<%#= Image source: https://docs.google.com/drawings/d/17Zzznn0J8j3sEICByPnAF1mSKg0pisqtrZNWi8KbOh8/edit %>
If you use vSphere without NSX, 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.
<br>
### <a id='tkgi-api'></a>TKGI API Load Balancer
The TKGI API load balancer enables you to access the TKGI API from outside the network on Tanzu Kubernetes Grid Integrated Edition deployments on AWS or vSphere without NSX.
For example, configuring a load balancer for the TKGI API enables you to run TKGI CLI commands from your local workstation.
For information about configuring the TKGI API load balancer on vSphere without NSX, see [Configuring TKGI API Load Balancer](./vsphere-configure-api.html).
<br>
### <a id='cluster'></a>Kubernetes Cluster Load Balancers
When you create an Tanzu Kubernetes Grid Integrated Edition cluster on AWS or vSphere without NSX,
you must configure external access to the cluster by creating an external TCP or HTTPS load balancer.
The load balancer enables 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 enable 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 control plane VM. For example: `my-cluster.example.com A 10.0.0.5`
* On the workstation where you run kubectl commands, add the control plane IP address of your cluster and `kubo.internal` to the `/etc/hosts` file. For example: `10.0.0.5 kubo.internal`
For more information about configuring a cluster load balancer, see the following:
* [Creating and Configuring an AWS Load Balancer for Tanzu Kubernetes Grid Integrated Edition Clusters](aws-cluster-load-balancer.html)
* [Creating and Configuring an Azure Load Balancer for Tanzu Kubernetes Grid Integrated Edition Clusters](azure-cluster-load-balancer.html)
<br>
### <a id='workload'></a>Workload Load Balancers
To enable external access to your Tanzu Kubernetes Grid Integrated Edition app on AWS or vSphere without NSX, 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 Exposing Basic Linux 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 Exposing Basic Linux Workloads_ before you create a workload load balancer.
#### <a id='with-ingress'></a>Deploy Your Workload Load Balancer with an Ingress Controller
A Kubernetes ingress controller sits behind a load balancer, routing HTTP and HTTPS requests from outside the cluster to services within the cluster.
Kubernetes ingress resources can be configured to load balance traffic, provide externally reachable URLs to services, and manage other aspects of network traffic.
If you add an ingress controller to your Tanzu Kubernetes Grid Integrated Edition deployment, traffic routing is controlled by the ingress resource rules you define.
<%= vars.recommended_by %> recommends configuring Tanzu Kubernetes Grid Integrated Edition deployments with both a workload load balancer and an ingress controller.
The following diagram shows how the ingress routing can be used
within your Tanzu Kubernetes Grid Integrated Edition deployment.
<%= image_tag("images/ingress-routing.png", :alt => "TKGI diagram that shows ingress routing for both Istio and NSX") %>
<%#= Image source: https://docs.google.com/drawings/d/1IB2juuTQlwJ4QpRaMmjFvGAC3cS7irFy3OII-pb6GGE/edit %>
The load balancer on Tanzu Kubernetes Grid Integrated Edition on vSphere with NSX is automatically provisioned with Kubernetes ingress resources
without the need to deploy and configure an additional ingress controller.
For information about deploying a load balancer configured with ingress routing on AWS, Azure, and vSphere without NSX, see [Configuring Ingress Routing](configure-ingress.html).
For information about ingress routing on vSphere with NSX, see [Configuring Ingress Resources and Load Balancer Services](nsxt-ingress-srvc-lb.html).
<br>
<br>
## <a id='with-nsx-t'></a>Load Balancers in Tanzu Kubernetes Grid Integrated Edition Deployments on vSphere with NSX
Tanzu Kubernetes Grid Integrated Edition deployments on vSphere with NSX in high-availability mode require you configure a load balancer to access the TKGI API.
To configure an NSX load balancer for TKGI API traffic, see [Provisioning an NSX Load Balancer for the TKGI API Server](nsxt-lb-tkgi-api.html).
TKGI deployments on vSphere with NSX in singleton mode require you configure only a DNAT rule so that the TKGI API host is accessible.
These TKGI deployments do not require you to configure a load balancer to access the TKGI API.
For more information, see [Share the Tanzu Kubernetes Grid Integrated Edition Endpoint](installing-nsx-t.html#retrieve-endpoint) in _Installing Tanzu Kubernetes Grid Integrated Edition on vSphere with NSX Integration_.
At runtime, NSX automatically handles load balancer creation, configuration, and deletion as part of the Kubernetes cluster create, update, and delete process.
When a new Kubernetes cluster is created, NSX creates and configures a dedicated load balancer tied to it. The load balancer is a shared resource designed to provide efficient traffic distribution to control plane 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://techdocs.broadcom.com/us/en/vmware-cis/nsx/vmware-nsx/4-2/administration-guide/manager-mode/advanced-load-balancing.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 enables requests to be load balanced across multiple control plane nodes.
* **Ingress controller**. This enables the virtual server instance to dispatch HTTP and HTTPS requests to services associated with Ingress rules.
* `type:loadbalancer` **services**. This enables 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 Tanzu Kubernetes Grid Integrated Edition deployments on vSphere with NSX. Only <code>type:LoadBalancer</code>Services and Services associated with Ingress rules are supported on vSphere with NSX.</p>
<br>
### <a id='resize-lb'></a> Resizing Load Balancers
When a new Kubernetes cluster is provisioned using the TKGI API, NSX 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 at the time of cluster creation. For information about network profiles, see [Using Network Profiles (NSX Only)](network-profiles.html).
For more information about the types of load balancers NSX provisions and their capacities, see [Scaling Load Balancer Resources](https://techdocs.broadcom.com/us/en/vmware-cis/nsx/vmware-nsx/4-2/administration-guide/load-balancer/key-load-balancer-concepts/scaling-load-balancer-resources.html) in the NSX-T documentation.