Routing to Kubernetes APIs
Page last updated:
This topic explains how Pivotal Ingress Router routes traffic to the API server on the master node of a Kubernetes cluster.
For information about how to use this feature after you have installed Ingress Router, see Creating and Accessing Clusters.
When you install Pivotal Ingress Router alongside Pivotal Container Service (PKS), you automatically get HTTP routing to the master node of a Kubernetes cluster whenever a new cluster is created.
In vSphere environments without NSX-T and in public clouds, Pivotal Ingress Router helps reduce cost in the following ways:
- Reduces operator workload: The operator does not have to set up networking for every new cluster before cluster administrators and developers can begin using them.
- Increases speed of access to new clusters: Cluster administrators can immediately access new clusters and begin managing them with
kubectl. And cluster users can begin deploying their workloads.
- Saves infrastructure resources: The operator does not have to create an additional load balancer for every new cluster.
To understand how Pivotal Ingress Router works, see Automatically Configuring Routing for New Clusters and Routing Traffic to the API Server on the Master Node in the How it Works section below.
This section provides a detailed explanation of how Pivotal Ingress Router configures routing for new clusters and routes traffic to those clusters.
The following diagram provides an overview of the components in Pivotal Ingress Router. To understand what these components do to make this feature work, see the sections below.
Whenever a PKS user creates a new cluster, Pivotal Ingress Router automatically configures routing for it. The following table explains how Pivotal Ingress Router does this:
|1||A PKS User creates a cluster.|
|2||The Cluster Registrar, which regularly polls the PKS API, does the following:
|3||The Master Routing Controller, which uses the Kubernetes API to watch for new cluster objects, does the following:
|4||Pilot, which watches for new Istio configuration, does the following:
After Pivotal Ingress Router configures routing for a new cluster, the users of the cluster can begin executing
kubectl commands against it. This request flows from the user’s machine, to the load balancer in front of the Ingress Gateway, to the Ingress Gateway, and finally to the Kubernetes API of the cluster they are accessing.
The following table describes what happens in more detail:
|1||A PKS user sets their context to the Kubernetes cluster they want to access by running the following command:
kubectl config use-context CLUSTER-NAME
|2||The user runs a
|4||DNS resolves the server address to the IP address for the load balancer in front of the Ingress Gateway. This load balancer is created when installing Pivotal Ingress Router. See Configure gateway DNS and load balancer.|
|6||The load balancer forwards the request to the Ingress Gateway.|
|7||The Ingress Gateway inspects the hostname in the Server Name Indication (SNI) of the request and forwards the request to an IP address of one of the master nodes of the cluster.|
|8||The API server responds with its certificate and terminates the TLS connection.|