← CKA: Kubernetes administration and troubleshooting
04 / 7 · 28 MIN

Services, policies, and names

Follow backend selection and the path to the application.

Concept and mechanism

A Service offers an access point and, when using a selector, selects Pods by labels. Corresponding EndpointSlices help observe available destinations. Check selector, readiness, and ports before changing exposure. port is the Service-facing port; targetPort is the backend destination. Service DNS includes name, namespace, and cluster domain, so a short name may resolve differently in another namespace. Ingress and Gateway API describe routing but need compatible implementations observing resources and configuring the data plane. Creating YAML does not automatically install the controller.

Guided application

NetworkPolicy requires a plugin enforcing its rules. Read Pod and namespace selection with attention to YAML structure: both selectors in one entry jointly restrict, while separate entries represent allowed alternatives. Policies are additive and a path may require source egress and destination ingress. When introducing default deny, inventory DNS and other dependencies. DNS architecture may include a local cache, so do not copy IPs and labels from another cluster without confirmation. Validate allowed and denied access to demonstrate effective control enforcement.

IN PRACTICE

In an example with cluster.local domain, api.funds.svc.cluster.local identifies Service api in funds. Use kubectl get endpointslices -n funds and compare destinations with Pod labels and readiness.

Common pitfalls

Changing to NodePort to fix a selector; confusing port and targetPort; assuming enforcement from Policy creation; installing any controller without compatibility checks.

Related topics: Volumes and data lifecycle · Diagnose workloads with evidence

Take this idea with you

Confirm intent, implementation, and observed traffic at every layer.

Create account

Reference: Services · CKA Kubernetes v1.35