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.

Overview

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.

How It Works

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.

For a detailed description of how Pivotal Ingress Router works as illustrated by this diagram, read the sections below. View a larger version of this image

Automatically Configuring Routing for New Clusters

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:

Stage Description
1 A PKS User creates a cluster.
2 The Cluster Registrar, which regularly polls the PKS API, does the following:

  1. Detects that a new cluster has been created.
  2. Creates a cluster object using the Kubernetes API of the cluster on which Pivotal Ingress Router is installed.
3 The Master Routing Controller, which uses the Kubernetes API to watch for new cluster objects, does the following:

  1. Detects that a new cluster object has been created.
  2. Creates Istio configuration that consists of:
    • A VirtualService that specifies a SNI host equal to the FQDN of the cluster. This is used to match requests.
    • A ServiceEntry with the IP addresses of the master nodes of the destination Kubernetes cluster.
4 Pilot, which watches for new Istio configuration, does the following:

  1. Detects that new Istio configuration has been created.
  2. Configures the Ingress Gateway (Envoy) to route traffic to the master node on the new cluster.

Routing Traffic to the API Server on the Master Node

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:

Stage Description
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 kubectl command against the cluster.
3 kubectl makes a request to the server address stored in the cluster context. The server address is the FQDN that was passed in as the host parameter when the cluster was created with PKS.
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.
5 kubetcl initiates a TLS connection to the IP address of the 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.