Which two of the following statements accurately describe how networking functions within a Kubernetes cluster?
Select all correct answers, then click Submit.
Short Explanation and Infographic
Okay, let's dive into Kubernetes networking. First off, if you've got pods running, they need to talk to each other. How do they find one another? Do we manually type in IP addresses or rely on environment variables like it's 1999? No way! Kubernetes has a built-in DNS service (like CoreDNS) that handles service discovery by name. You just call my-service and boom, it resolves. Now, what about traffic coming from the outside world? That's where the Ingress resource comes in. Think of Ingress as the front door or receptionist for your cluster. It intercepts external HTTP/HTTPS requests, checks the URL path, and routes them to the correct internal service while handling load balancing. Watch out for exam traps here: NetworkPolicies work at Layers 3 and 4 (IPs and ports), not Layer 7 (application level), and Kubernetes can handle UDP just fine—which is a good thing, because DNS itself runs on UDP! Got it? Sweet.
Full explanation below image
Full Explanation
Kubernetes networking is based on a set of core principles that govern how pods, services, and external clients communicate. Two of the most critical components of this networking model are internal service discovery and external traffic management.
First, Kubernetes provides an internal DNS service (typically CoreDNS) that runs as a cluster add-on. Whenever a Service is created, it is automatically assigned a DNS entry. Pods within the cluster can then perform standard DNS queries to resolve the Service name to its ClusterIP. This abstracts away the dynamic, ephemeral nature of pod IP addresses, providing a stable name-based discovery mechanism.
Second, an Ingress is an API object that manages external access to the services in a cluster, typically HTTP and HTTPS. It provides routing rules (such as path-based or host-based routing), SSL/TLS termination, and load-balancing capabilities. This allows external clients to access applications running inside the cluster securely and efficiently.
Let’s review why the other options are incorrect: - Service discovery is not limited to environment variables; the DNS service is the standard and recommended way to locate services. - Kubernetes supports both TCP and UDP protocols, allowing a wide variety of workloads to run. - NetworkPolicies are implemented at the network layer (Layer 3 and Layer 4), filtering traffic based on IP addresses, ports, and selectors. They do not operate at the application layer (Layer 7) and cannot inspect application payloads or HTTP headers. - While advanced networking features often require a Container Network Interface (CNI) plugin (like Calico or Flannel), Kubernetes includes basic networking capabilities (like the host-local provider or kubenet) that allow the cluster to boot and perform basic functions without requiring a third-party CNI out of the box.