Kubernetes Networking Components for C3 AI Applications Overview
This documentation is meant to be a brief overview of Kubernetes networking components that C3 AI applications use. It is not meant to explain the individual Kubernetes components comprehensively. Please refer to the Kubernetes documentation for details regarding each component.
See also App.
Pods
A Kubernetes pod acts as a basic unit of deployment in Kubernetes that encapsulates one or more containers. When scheduled to a Kubernetes node, a pod will be assigned its own internal IP address. In the event a pod is terminated, it will restart with a different IP address. All containers in a pod share the same network namespace, IP address, and port, and therefore are able to internally communicate through localhost.
ClusterIP services
Due to the ephemeral nature of pods, communicating with pods directly through their IP addresses is unreliable. As an alternative, Kubernetes services provide a stable access point to forward requests to pods.
Services have fields known as selectors, which will match on Pod labels. This match helps to determine what Pods will be backed by what service. If multiple pods match on a service, requests are properly load balanced between pods.
While various types of services exist, C3 AI applications are backed by ClusterIP services. ClusterIP services make use of an internal IP address and are not exposed to the outside world. This service can act as a stable access point as it is not a physical resource, but rather an IP table configuration applied on all Kubernetes nodes. Agents on Kubernetes nodes watch for new services and endpoints to apply new IP table configurations as necessary.
Ingresses
Pods usually need to be exposed and accessible to the outside world for practical use. Load balancers provide a fixed external IP and routes to any pods matching its label selector. These load balancers are implemented differently per cloud provider, but usually come with monetary costs for the user.
In the end, load balancers are still single services with their own label selector. If various pods need to be backed by different load balancers, costs can accumulate quickly.
Ingresses help mitigate this issue by allowing for user specified routing logic to multiple ClusterIPs using a single load balancer. Various ingress providers exist (for example, Nginx) and each provide different functionalities:
- Request limiting
- URL rewriting
- SSL termination
- Authentication
Ingresses come in two major components:
- Ingress load balancer: Performs the actual routing of packets
- Ingress controller: Enables controlled routing based on a set of predefined rules
Ingress objects retrievable using kubectl get ingress dictates what combinations of hostnames and paths match to what service. When a new ingress object is upserted, it may take time for the ingress controller to sync and apply new ingress rules to the Kubernetes cluster.
External DNS
External DNS is a pod that watches over all ingress objects. When this pod detects a new hostname specified in an ingress, it picks up the hostname and upserts an A record into a DNS service (for example, AWS Route53).