Container Orchestration practice questions

Kubernetes Services default to internal-only exposure unless a different type is requested.

When the type field is omitted on a Service manifest, Kubernetes defaults to ClusterIP, which allocates an internal virtual IP reachable only from within the cluster.

1. Recall that the Service spec.type field is optional.
2. Recall Kubernetes' default behavior for an omitted type field.
3. Confirm ClusterIP as the internal-only default, distinct from NodePort, LoadBalancer, and ExternalName which all require explicit configuration.

Exam tip: If you do not set spec.type, a Service is a ClusterIP Service, internal to the cluster only.

NodePort Services reserve a static port from a defined high-port range on every cluster node.

Kubernetes' default NodePort range is 30000-32767, and a NodePort Service opens the same port number on every node, forwarding to the Service's backing Pods.

1. Recall that NodePort builds on top of ClusterIP by additionally opening a port on every node.
2. Recall the default reserved range configured on the API server for NodePort allocation.
3. Match 30000-32767 as the correct default range.

Exam tip: NodePort Services use a high port, by default 30000-32767, opened identically on every node.

LoadBalancer Services layer a cloud provider's external load balancer on top of the NodePort mechanism.

When a Service is type LoadBalancer, Kubernetes allocates a NodePort as usual, and a cloud-integration controller provisions an external load balancer that forwards traffic to that NodePort across the nodes.

1. Recall the layering: ClusterIP is the base, NodePort adds a per-node port, LoadBalancer adds a cloud LB on top of NodePort.
2. Rule out the option claiming direct Pod IP exposure from the internet, which skips the Service layer entirely.
3. Rule out the option claiming LoadBalancer is internal-only, which contradicts its purpose.
4. Confirm LoadBalancer still carries a ClusterIP underneath.

Exam tip: LoadBalancer Services are NodePort Services with an external cloud load balancer layered on top.

Headless Services skip virtual IP allocation so clients can discover individual Pod IPs directly, useful for stateful workloads.

clusterIP: None instructs Kubernetes not to assign a virtual cluster IP; CoreDNS then answers queries for the Service name with the IPs of the individual backing Pods instead of one shared IP.

1. Recall that a normal ClusterIP Service load-balances behind a single virtual IP.
2. Recall that clusterIP: None removes that virtual IP allocation, producing a headless Service.
3. Confirm that DNS resolution for a headless Service returns the set of Pod IPs directly.

Exam tip: clusterIP: None makes a Service headless, DNS returns individual Pod IPs instead of one virtual IP.

ExternalName Services provide an in-cluster DNS alias for an external hostname, with no Pod selection or proxying involved.

An ExternalName Service maps its name to an externalName value via a CNAME DNS record, so in-cluster clients can use a stable internal name that resolves to an external service.

1. Recall that ExternalName Services have no selector and no Endpoints/EndpointSlices.
2. Rule out load-balancing and static-node-port behaviors, which belong to other Service types.
3. Confirm the CNAME redirection behavior as the defining feature of ExternalName.

Exam tip: ExternalName gives Pods a stable internal DNS name that actually resolves, via CNAME, to something outside the cluster.

EndpointSlices are the mechanism Kubernetes uses to record which Pods currently back a given Service.

As Pods matching a Service's label selector are created, become ready, or are removed, the EndpointSlice controller keeps the corresponding EndpointSlice objects updated with the current, ready Pod IPs.

1. Recall that a Service selects Pods by label, but needs somewhere to record the resulting IPs.
2. Recall that EndpointSlices (the successor to the older Endpoints object) hold that list, split into slices for scalability.
3. Rule out ConfigMap, NetworkPolicy, and Ingress, none of which track Pod backend membership.

Exam tip: EndpointSlices are the live record of which Pod IPs currently back a Service.