Kubernetes Cluster: Internal Networking
Setting up networking within a Kubernetes Cluster is automated through K8s Services, with the Container Networking Interface (CNI) plugin handling the creation and configuration of an overlay network to assign unique IP addresses to each pod.
Kubernetes simplifies service access by allowing direct access to services using their names. For instance, if your application needs to connect to a database, you can use the database’s DNS name, which Kubernetes resolves to the appropriate internal IP address automatically. To enable this, you simply need to create a service object in Kubernetes with the correct selector.
By default, a Kubernetes Cluster comes with a Hello World deployment, service, and ingress (unless a custom deployment option was selected during installation).
Exploring this default application can provide a practical understanding of Kubernetes services and networking concepts.
Platform DNS Name Resolution inside PODs
DNS name resolution within Kubernetes pods is managed by CoreDNS, which is automatically configured in the /etc/resolv.conf file of each pod. CoreDNS uses platform nameservers to facilitate direct communication between the Kubernetes Cluster and other containers within the platform.
For example, suppose you have a database deployed in the platform and want to connect to it from a Kubernetes pod. You can use the “${nodeId}-${envName}.${platformDomain}” hostname along with the default port for the database (e.g., 3306 for MySQL, 5432 for PostgreSQL).
However, to connect to a database deployed outside the platform from within a Kubernetes pod, you would need to create an endpoint or ingress resource to facilitate external access.
This involves configuring networking policies and possibly exposing the service using NodePort, LoadBalancer, or Ingress resources, depending on the use case and infrastructure setup.