Skip to article
Containers Kubernetes networking

Kubernetes Service

Microsoft Learn explains that Kubernetes Services in AKS expose applications through service types such as ClusterIP, NodePort, LoadBalancer, and ExternalName. LoadBalancer Services can create Azure load balancer resources, while internal load balancers use private IP addresses for restricted access. in production AKS clusters.

Source: Microsoft Learn - Kubernetes Services in Azure Kubernetes Service Reviewed 2026-05-30

Exam trap
Creating a public LoadBalancer Service when the workload should only be reachable inside a virtual network.
Production check
Run kubectl get service --all-namespaces and identify unexpected LoadBalancer or NodePort Services.
Practice this topic Microsoft Learn
Article details and learning context
Aliases
Kubernetes Service, aks-cluster, aks-ingress-controller, aks-network-policy, azure-kubernetes-service, ingress, kubernetes service, kubernetes-deployment, kubernetes-namespace, kubernetes-service, load-balancer, load-balancer-backend-pool, node-pool
Difficulty
intermediate
CLI mappings
5
Last verified
2026-05-30
Article depth
field-manual-complete
Compare related concepts Search related resources Browse the glossary

Understand the concept

In plain English

A Kubernetes Service is the stable network front door for a changing set of pods. Pods come and go, get new IP addresses, and move between nodes, but a Service gives other workloads a consistent name and port to use. In AKS, a Service can be internal to the cluster, exposed through a node port, connected to an Azure Load Balancer, or mapped to an external DNS name. It is one of the main ways traffic reaches applications running in Kubernetes.

Why it matters

Kubernetes Services matter because they decide whether application traffic reaches the right pods, stays private, scales cleanly, and survives pod replacement. A wrong selector can route to nothing; a LoadBalancer service can expose an internal app publicly; a port mismatch can break health checks; and too many service rules can exhaust load balancer limits. Services also form the vocabulary developers, platform engineers, and network teams use to discuss application access. In AKS, understanding Services prevents accidental internet exposure, confusing DNS failures, broken microservice calls, and expensive troubleshooting when pods are healthy but traffic still fails. That boundary deserves review. That clarity prevents accidental exposure during scaling and upgrades.

Technical context

Technically, a Kubernetes Service is an API object in the Kubernetes data plane, usually matched to pods through selectors and labels. It creates stable virtual IP and DNS behavior inside the cluster, and certain service types cause AKS to coordinate Azure networking resources such as Standard Load Balancer rules, frontend IPs, backend pools, and health probes. Services interact with namespaces, endpoints, EndpointSlices, kube-proxy or eBPF routing, network policies, ingress controllers, private load balancers, and Azure CNI or overlay networking choices.

Exam context

What to know

operator-ready

Compare with

Kubernetes Deployment Ingress Load balancer backend pool

Where it is used

Where you see it

  1. In kubectl get service output, you see service type, cluster IP, external IP, ports, and age for each namespace during traffic triage. during routing reviews.
  2. In kubectl describe service events, selectors, annotations, endpoints, and load balancer provisioning messages explain why a Service is reachable or broken. during deployment routing reviews.
  3. In Azure networking resources, AKS-created load balancer rules, frontend IPs, backend pools, and probes reflect LoadBalancer Services exposed from the cluster. during Azure exposure reviews.

Common situations

  • Give internal microservices a stable DNS name even as pods roll during deployments or autoscaling.
  • Expose an AKS workload through an internal load balancer for private enterprise applications.
  • Publish a public application through an Azure Load Balancer when ingress is unnecessary or not appropriate.
  • Troubleshoot traffic failures by comparing Service selectors, endpoints, pod labels, and load balancer events.
  • Control exposure policy so developers cannot accidentally create public LoadBalancer Services in sensitive namespaces.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Research platform fixes zero-endpoint outage Scenario, objectives, solution, measured impact, and takeaway.
Scenario

A genomics research platform moved analysis pods to a new Helm chart and lost internal API traffic, even though every pod appeared healthy in the AKS cluster.

Goals
  • Restore internal API traffic before overnight sequencing jobs completed.
  • Identify whether failure belonged to pods, DNS, network policy, or Service selectors.
  • Prevent future chart releases from producing zero-endpoint Services.
  • Document a support runbook developers could run without Azure portal access.
Approach using Kubernetes Service

Operators used kubectl get service, describe service, and get endpoints to show that the ClusterIP Service selected zero ready pods. The Helm chart had renamed an app label from analysis-api to analysis-service, but the Service selector still used the old value. Instead of restarting healthy pods, the team patched the selector in a hotfix chart and confirmed EndpointSlices populated within seconds. They also added a CI check that rendered Helm templates and compared Service selectors against Deployment pod labels before merge. Azure CLI was used only to confirm the AKS cluster context and capture the exact cluster and namespace for the incident record.

Potential outcomes
  • Internal API traffic recovered in twenty-six minutes after the correct failure layer was identified.
  • No sequencing jobs were cancelled or rerun overnight.
  • Zero-endpoint Service defects dropped to zero across the next eleven chart releases.
  • Developers resolved the follow-up drill using the new runbook in under eight minutes.
What to learn

A Kubernetes Service can look present while selecting nothing, so endpoint checks are the fastest path to the truth.

Scenario 02 City portal removes accidental public exposure Scenario, objectives, solution, measured impact, and takeaway.
Scenario

A municipal services portal discovered that an internal permit-processing API had a public IP because a developer created a LoadBalancer Service without the internal annotation.

Goals
  • Remove public exposure without breaking internal case-worker access.
  • Prove which Services in the cluster had external IP addresses.
  • Create a policy guardrail for sensitive namespaces.
  • Reduce network review time for future AKS releases.
Approach using Kubernetes Service

The platform team inventoried all Services with kubectl and exported type, namespace, external IP, annotations, and owner labels. For the permit API, they changed the manifest to use an internal Azure load balancer annotation and redeployed during a maintenance window. Azure networking checks confirmed the new private IP, backend pool, and health probe were created correctly. Firewall rules were updated for case-worker networks, and the previous public IP was removed. The team then introduced admission policy guidance requiring internal load balancer annotations for designated namespaces and alerting on unexpected public external IPs.

Potential outcomes
  • The permit API public IP was removed in one maintenance window with no case-worker outage.
  • Security inventory identified three additional Services needing exposure review.
  • Network review for AKS service changes fell from four days to one day.
  • Unexpected public LoadBalancer Services triggered alerts within five minutes in later tests.
What to learn

Kubernetes Service type and annotations are security controls when AKS is allowed to create Azure load balancers.

Scenario 03 Streaming company plans load balancer scale Scenario, objectives, solution, measured impact, and takeaway.
Scenario

A live-streaming analytics team added many port-specific LoadBalancer Services for regional collectors and began hitting Azure load balancer rule limits during event onboarding.

Goals
  • Identify which Services consumed load balancer rules and public IPs.
  • Reduce port-heavy exposure without disrupting collector traffic.
  • Improve onboarding time for new event regions.
  • Create a cost and limit review before service manifests merged.
Approach using Kubernetes Service

Platform engineers exported every LoadBalancer Service with namespace, ports, annotations, external IP, and owning team. They correlated the inventory with Azure Load Balancer rules and found several collectors exposing separate Services where one shared ingress pattern would work better. The team consolidated collectors behind fewer Services, reused approved static IPs, and moved internal processing paths to ClusterIP Services. CI checks started flagging new LoadBalancer manifests that exceeded port thresholds or lacked owner labels. Operators also documented when multiple Standard Load Balancers would be considered for future growth instead of silently exhausting the default cluster load balancer.

Potential outcomes
  • Load balancer rule usage dropped 41 percent after collector consolidation.
  • Public IP count for analytics collectors fell from twenty-four to nine.
  • New event-region onboarding time decreased from two days to four hours.
  • Monthly networking cost for the collector layer decreased 18 percent.
What to learn

Kubernetes Services are part of AKS capacity planning because LoadBalancer choices consume Azure networking limits and money.

Azure CLI

As an Azure engineer, I use CLI and kubectl checks for Kubernetes Services because service problems cross Kubernetes and Azure networking. The Azure portal may show a load balancer, while kubectl shows selectors, endpoints, ports, annotations, and events that explain why traffic is broken. Azure CLI gets credentials, runs command invoke for private clusters, and inspects the AKS cluster and load balancer resources. Together, these commands produce repeatable evidence: which Service exists, which pods it selects, which IP was assigned, which health probe was created, and whether exposure is internal or public. That split view prevents guesswork during urgent routing incidents.

Useful for

  • List Services across namespaces and identify public, internal, ClusterIP, or NodePort exposure patterns.
  • Describe a Service to review selectors, annotations, endpoints, ports, events, and assigned load balancer details.
  • Check EndpointSlices and pod labels to confirm the Service selects ready pods before blaming the application.
  • Use Azure CLI to inspect AKS credentials, command invoke access, and load balancer resources tied to Services.
  • Export service inventory for security review, IP planning, cost cleanup, and platform policy enforcement.

Before you run a command

  • Confirm tenant, subscription, AKS resource group, cluster name, namespace, and kubeconfig context before running kubectl.
  • Check whether the cluster is private and whether command invoke or a jump host is needed for access.
  • Use read-only commands first because deleting or patching Services can immediately cut application traffic.
  • Verify your Kubernetes RBAC and Azure RBAC rights, especially when inspecting load balancer resources.
  • Know whether the expected Service should be internal, public, ClusterIP-only, or behind an ingress controller.

What the output tells you

  • Service type explains whether traffic stays inside the cluster or asks Azure to provision external networking.
  • Cluster IP, external IP, and port mappings show what clients should target and how traffic enters the workload.
  • Selectors and endpoints reveal whether the Service is actually connected to ready pods.
  • Annotations indicate provider-specific behavior such as internal load balancer placement or static IP selection.
  • Events and load balancer fields show provisioning failures, quota issues, IP conflicts, or health probe problems.

Mapped commands

Kubernetes Service CLI commands

direct 
az aks get-credentials --resource-group <resource-group> --name <cluster-name>
az akssecureContainers
security-impacting Microsoft Learn 
kubectl get service --all-namespaces -o wide
read-only Microsoft Learn 
kubectl describe service <service-name> --namespace <namespace>
read-only Microsoft Learn 
kubectl get endpoints,endpointslices --namespace <namespace>
read-only Microsoft Learn 
az network lb rule list --resource-group <node-resource-group> --lb-name <load-balancer-name> --output table
az network lb rulediscoverContainers
read-only Microsoft Learn

Architecture context

In architecture reviews, I treat a Kubernetes Service as the contract between a workload and its callers. ClusterIP supports internal service-to-service communication. LoadBalancer exposes workloads through Azure networking and must be reviewed with IP, DNS, firewall, and cost ownership. Internal LoadBalancer services support private applications reachable only from approved networks. NodePort is usually a lower-level building block, not the default production interface. Architects should define naming, namespace ownership, selector labels, private versus public exposure, ingress relationship, network policy, health probes, and limits before teams create Services freely in shared AKS clusters. Make the exposure choice explicit in manifests, diagrams, and policy rules.

Security
Security impact is direct whenever a Service exposes traffic beyond a pod boundary. Review service type, annotations, public IP assignment, internal load balancer settings, namespace ownership, labels, network policies, ingress rules, TLS termination, and firewall path. A LoadBalancer service can create internet-reachable infrastructure quickly, sometimes before security teams notice. ClusterIP services still need network policy and identity-aware controls when sensitive workloads share a cluster. Strong RBAC, policy enforcement, approved annotations, and admission controls reduce the chance that a simple YAML file publishes a private application to the wrong audience. Review each Service type because the wrong one can publish private workloads.
Cost
Cost appears mainly when Services create Azure networking resources. LoadBalancer services can consume frontend IPs, rules, health probes, outbound behavior, data processed, and public IP resources. Multiple Services may share the AKS Standard Load Balancer, but rule limits and IP planning still matter. Cost also comes from accidental public exposure, duplicate services, unnecessary dedicated load balancers, noisy monitoring, and troubleshooting time. FinOps and platform teams should inventory LoadBalancer Services, identify unused public IPs, review internal versus external exposure, and align service ownership with application teams. Ownership matters. Inventory load balancers because public IPs, rules, and traffic have ownership costs too.
Reliability
Reliability depends on selectors, endpoint readiness, DNS, kube-proxy or dataplane health, node availability, and Azure Load Balancer behavior. A Service can exist while selecting zero pods, pointing to not-ready endpoints, or using a port that the containers do not serve. LoadBalancer Services also rely on frontend IPs, backend pools, health probes, and rule capacity. Operators should verify endpoints, events, pod readiness, service annotations, load balancer provisioning, and DNS resolution during incidents. Reliable services make pod replacement invisible to callers; unreliable services turn normal deployment churn into outages. Check endpoints first because missing backends often masquerade as network outages during releases.
Performance
Performance depends on routing path, endpoint count, load balancer behavior, DNS caching, health probes, network policy, and how evenly traffic spreads across ready pods. A Service with poor selectors or uneven readiness can overload a small subset of pods. External LoadBalancer paths add Azure networking hops, while internal ClusterIP communication usually stays inside the cluster network. Operators should measure request latency, connection failures, retries, endpoint distribution, load balancer probe health, and pod readiness. Service tuning is most useful when it is tied to the application traffic pattern, not only YAML syntax. Measure endpoint readiness because uneven backends can distort latency quickly.
Operations
Operations teams inspect Kubernetes Services when an app is unreachable, unexpectedly public, missing an IP, failing health probes, or routing to the wrong pods. Runbooks should include kubectl get service, describe service, get endpoints or EndpointSlices, check pod labels, review events, and inspect Azure Load Balancer resources when type LoadBalancer is involved. Operators also document namespace ownership, DNS names, firewall rules, and ingress relationships. Good operations separate service-level symptoms from pod-level failures so developers do not restart healthy pods while the selector or load balancer remains broken. Both must respond. Keep selectors documented because label drift is a common outage source.

Common mistakes

  • Creating a public LoadBalancer Service when the workload should only be reachable inside a virtual network.
  • Changing pod labels during deployment and leaving the Service selector pointing to zero endpoints.
  • Confusing an ingress rule with a Service and troubleshooting the wrong layer during an outage.
  • Forgetting Azure Load Balancer rule limits when many port-heavy Services share one AKS cluster.
  • Deleting a Service without understanding the DNS name, IP address, firewall rules, and dependent clients.