About network ingress

This topic tells you about the components contributing to application ingress on Tanzu Platform for Kubernetes.

Tanzu Platform enables you to configure network ingress to your applications so that the interactions between the teams involved are frictionless and follow best practices. This is done by decoupling the platform engineer’s platform-specific setup from the application developer’s application-specific setup from the application operator’s environment-specific setup.

The components of application ingress on Tanzu Platform for Kubernetes are:

Domains: The DNS record through which applications are accessed.
Routes: Connects traffic in the Space to the application or service.
Domain bindings: Connects between a Space and a domain.

Diagram showing the certificate provider, DNS provider, and domain in the Tanzu control plane. The domain binding and apps are in the cluster.

Domains: platform configuration

A domain refers to the DNS record through which applications in the Project can be accessed. A Project can have multiple domains in it. A domain can be fully qualified, for example, example.com or allow an acceptable subdomain to be specified in the future, for example, foo.example.com. For how to configure domains, see Create and manage domains.

Tanzu Platform can automate the integration of other components that network ingress typically uses. The domain can use:

A DNS provider to set DNS records dynamically using Global Server Load Balancing (GSLB) or another DNS provider. For how to configure DNS providers, see Create and manage DNS providers.
A certificate provider to provide TLS encryption for traffic to the domain. For how to configure certificate providers, see Create and manage certificate providers.

Domains example

Consider a scenario where a platform engineer wants to set up a domain that developers can use to create and test applications internally.

The platform engineer has the following requirements:

Their organization uses Avi as a DNS. Avi DNS already has authority over dev.corp.com.
Their organization uses static certificates with authority over *.dev.corp.com.
Development applications must be accessible on a subdomain of dev.corp.com.

To achieve these requirements, the platform engineer must:

Create a DNS provider called Avi that contains the information needed for Tanzu Platform to communicate with the Avi GSLB and manage DNS records in the dev.corp.com zone.
Create a corresponding certificate provider called dev-app-cert that has the certificates needed to sign requests to *.dev.corp.com.
Create a domain, dev.corp.com, using the Avi DNS provider and dev-app-cert certificate provider so that DNS records in the *.dev.corp.com are dynamically created and the wildcard certificate encrypts traffic.

Routes: application configuration

Routes ensure that ingress traffic is routed to the right application, regardless of the domain it’s connected to.

Routes example

Continuing the previous scenario, an application developer has created an application composed of multiple microservices. The developer wants the homepage application to be accessible on the path /, the cart application to be accessible on the path /cart , and the checkout application to be accessible on the path /checkout.

To do this, the developer creates a route that takes traffic on / and routes it to the homepage application, specifies another route to take traffic on /cart and routes it to the cart application. To finish, the application developer creates another route, specifying the path /checkout and routes it to checkout. The routes are now ready to have a domain bound to them, enabling network traffic to flow to the applications.

Domain bindings: runtime environment configuration

Domain bindings connect a Space to a domain. This enables applications running in a Space to be accessible on that domain. When a domain is bound to a Space, Tanzu Platform creates a DNS record to route traffic from the domain to the ingress gateway on the clusters where the Space is running. For how to configure domains bindings, see Create and manage domain bindings.

Domain bindings example

Finishing the previous scenario, a development team now wants to deploy their web application on the platform. Because it’s a web application, they want it to be accessible over HTTPS on port 443.

The development team creates a Space and binds the domain retail.dev.corp.com to it. Tanzu Platform updates the Avi GSLB so that traffic at https://retail.dev.corp.com is routed to the Space. At the end of this process, the cart application is accessible at https://retail.dev.corp.com/cart and the checkout application at https://retail.dev.corp.com/checkout.

Advanced configuration

This section provides information about the advanced ingress features in Tanzu Platform.

Domains

When configuring domains, you can also configure allowable subdomains, ports, and Spaces. The following subsections provide more information about each of these settings.

Subdomains

Tanzu Platform allows you to specify how subdomains are used. You can specify a list of acceptable subdomains ahead of time, permit a system-generated subdomain to be assigned in the future, or require that applications bind directly to the fully-qualified domain.

Ports

Tanzu Platform allows you to specify the ports that can allow traffic on a domain. For example, a platform Engineer is preparing a production environment and decides that only HTTPS traffic is allowed on prod.corp.com, they can configure the domain to only accept traffic on port 443.

Spaces

Tanzu Platform allows you to configure the list of Spaces that can bind to a domain. For example, if a platform engineer is preparing a production environment and decides that only Spaces billing-space and checkout-space can access transaction.corp.com, they can specify those Spaces on the domain as Allowed Spaces ahead of time.

Domain bindings

When configuring domain bindings, you can also configure entry points, protocols, and ports. The following subsections provide more information about each of these settings.

Entry points

As explained earlier, the domain binding ensures that traffic is routed to a Space, and the route ensures that traffic is routed from the Space to the correct application.

Tanzu Platform connects the domain binding and route through an entrypoint, which is like a contract between the application operator and development teams. This is an optional configuration. The entrypoint is a parameter that can remain constant across all instances of the application or across all environments.

Consider the scenario where a developer wants to deploy their application into a development environment and then promote the same artifact to staging and production environments. Even though the domain is different in each environment, for example, dev.corp.com, staging.corp.com and prod.corp.com, the entrypoint to each for those domains can remain constant. The route configuration can remain in code because it does not depend on the environment.

Diagram showing artifacts promoted from dev to staging.

However, there are scenarios where the same application must serve traffic from different domains, for example, when debugging the application. In this case, you must have two domain bindings, each with a different entrypoint. Another route is created to connect to the new entrypoint.

Example: routing two kinds of traffic to your application

Consider the scenario where the application Cart is running on retail.prod.corp.com and needs to be debugged. However, debug traffic is sent on a different domain, debug-retail.prod.corp.com.

Diagram showing management of two kinds of traffic to an application.

To meet this requirement, the application operator creates a domain binding called retail-debug-db on Space retail with the domain retail-debug.prod.corp.com (the subdomain retail-debug is provided at this time), and the entrypoint debug. The application developer creates a new route called cart-route-debug, with path /cart, and entrypoint debug. Now, two kinds of traffic, regular and debug, are being served by the same application.

Protocols and ports

When creating a domain binding, the application operator or developer can specify the protocol and ports they anticipate serving with that application. By default, the applications are exposed as HTTPS on port 443. However, consider a scenario where an application developer is working on a streaming service that serves TCP traffic on port 9092. To meet this requirement, they can configure the domain binding to accept TCP traffic on port 9092.

Auto-assignment

When configuring domains, you can also configure the auto-assignment of subdomains and ports. The following subsections provide more information about each of these settings.

Auto-assigning subdomains

When creating a domain on Tanzu Platform, platform engineers can make subdomains auto-assignable. This means that they are permitting the auto-assignment of a subdomain in the future, by an application operator or developer.

Consider a scenario where the platform engineer is preparing a development environment. In this environment they want to empower developers to create many spaces in a self-service fashion, each bound to a subdomain of dev.corp.com.

For simplicity and speed, and to assist in avoiding naming collisions, the platform engineer configures the domain so that the subdomains are auto-assignable. When a developer decides to bind their space to dev.corp.com, because the auto-assignment of subdomains is permitted, they leave the system to provide a subdomain. A random subdomain is generated and prepended to the domain when the domain binding is created, with the new FQDN being acoustic-narhwal.dev.corp.com.

Auto-assigning ports

When creating a domain on Tanzu Platform, platform engineers can make ports auto-assignable. This means that the platform engineer is permitting the auto-assignment of a port in the future, by an application operator or developer.

Consider a scenario where the platform engineer is preparing a development environment at a company primarily developing TCP applications. In this environment, they anticipate that developers will create thousands of Spaces, each bound to domain dev.corp.com but on different ports.

Because TCP applications cannot share ports on the same IP, the platform engineer configures ports to be auto-assignable. When a developer decides to bind their space to dev.corp.com, because the auto-assignment of ports is permitted, they leave the system to generate a port. When the domain binding is created, the Space is now accessible on dev.corp.com:5020.