Configure internal load balancers

Internal load balancers (ILB) expose services within the organization from an internal IP pool assigned to the organization. An ILB service is never accessible from any endpoint outside of the organization.

By default, you can access ILB services within the same project from any cluster in the organization. The default project network policy doesn't let you access any project resources from outside the project, and this restriction applies to ILB services as well. If the Platform Administrator (PA) configures project network policies that allow access to your project from other projects, then the ILB service is also accessible from those other projects in the same organization.

Create internal load balancers in GDC by creating a Kubernetes Service of type LoadBalancer in a user cluster.

To create an ILB service, do the following:

Create a YAML file for the Service definition of type LoadBalancer. You must design the ILB service as internal using the networking.gke.io/load-balancer-type: internal annotation.

The following Service object is an example of an ILB service:
```
apiVersion: v1
kind: Service
metadata:
  annotations:
    networking.gke.io/load-balancer-type: internal
  name: ILB_SERVICE_NAME
  namespace: PROJECT
spec:
  ports:
  - port: 1234
    protocol: TCP
    targetPort: 1234
  selector:
    k8s-app: my-app
  type: LoadBalancer
```
Replace the following:
- ILB_SERVICE_NAME: the name of the ILB service.
- PROJECT: the namespace of your project that contains the backend workloads.
The port field configures the frontend port you expose on the VIP address. The targetPort field configures the backend port to which you want to forward the traffic on the backend workloads. The load balancer supports Network Address Translation (NAT). The frontend and backend ports can be different.
On the selector field of the Service definition, specify pods or virtual machines as the backend workloads.

The selector defines which workloads to take as backend workloads for this service, based on matching the labels you specify with labels on the workloads. The Service can only select backend workloads in the same project and same cluster where you define the Service.

For more information about service selection, see https://kubernetes.io/docs/concepts/services-networking/service/
Save the Service definition file in the same project as the backend workloads. The ILB service can only select workloads that are in the same cluster as the Service definition.
Apply the Service definition file to the cluster:
```
kubectl apply -f ILB_FILE
```
Replace ILB_FILE with the name of the Service definition file for the ILB service.

When you create an ILB service, the service gets an IP address. You can obtain the IP address of the ILB service by viewing the service status:

kubectl -n PROJECT get svc ILB_SERVICE_NAME

Replace the following:

PROJECT: the namespace of your project that contains the backend workloads.
ILB_SERVICE_NAME: the name of the ILB service.

You must obtain an output similar to the following example:

NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
ilb-service             LoadBalancer   10.0.0.1      10.0.0.1        1234:31930/TCP   22h

The CLUSTER-IP and EXTERNAL-IP fields must show the same value, which is the IP of the ILB service. This IP address is now accessible from other clusters in the organization, in accordance with the project network policies that the project has.

If you don't obtain an output, ensure that you created the ILB service successfully.

GDC supports Domain Name System (DNS) names for services. However, those names only work in the same cluster for ILB services. From other clusters, you must use the IP address to access the ILB service.