Linux Networking & TCP/IP for Developers · Lección

Detección de servicios y DNS en Kubernetes

Aprenda cómo se encuentran los contenedores entre sí: el DNS del clúster, los objetos Service y el flujo de resolución que permite direccionar los microservicios por nombre.

Lección 4 de 413 pasos

Detección de servicios y DNS en Kubernetes es una lección gratuita de Linux Networking & TCP/IP for Developers en CoddyKit. Esta es la lección 4 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de Linux Networking & TCP/IP for Developers, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de Linux Networking & TCP/IP for Developers incluye 4 lecciones en total.

Partes de esta lección aún no han sido traducidas y se muestran en inglés.

The Discovery Problem

Container IPs are ephemeral — pods restart and get new addresses constantly. Hardcoding IPs is impossible.

Service discovery lets workloads find each other by stable names instead of changing IPs.

The Service Abstraction

A Kubernetes Service provides a stable virtual IP (ClusterIP) and DNS name that load-balances across a set of pods selected by labels.

apiVersion: v1
kind: Service
metadata:
  name: orders
spec:
  selector:
    app: orders
  ports:
    - port: 80

Cluster DNS

Every cluster runs a DNS server (CoreDNS). It automatically creates records for each Service so workloads can resolve them by name.

The DNS Naming Scheme

Services follow a predictable FQDN pattern:

service.namespace.svc.cluster.local

Within the same namespace, just orders works. Across namespaces use orders.payments.

curl http://orders.payments.svc.cluster.local

How a Pod Resolves Names

Each pod's /etc/resolv.conf points at the cluster DNS and includes search domains, so short names expand to full Service FQDNs automatically.

cat /etc/resolv.conf

ClusterIP Load Balancing

A ClusterIP is virtual — kube-proxy programs iptables or IPVS rules so traffic to it is distributed across the healthy backing pods. Clients never see individual pod IPs.

Headless Services

Set clusterIP: None for a headless Service. DNS then returns the individual pod IPs directly, which is ideal for stateful sets and client-side load balancing.

spec:
  clusterIP: None
  selector:
    app: db

Endpoints and EndpointSlices

Behind each Service, Kubernetes maintains EndpointSlices listing the ready pod IPs. As pods come and go, these update so DNS and routing stay current.

kubectl get endpointslices

Resolving from Inside a Pod

You can debug discovery by running nslookup from a pod to verify a Service name resolves to its ClusterIP.

kubectl exec -it shell -- nslookup orders

External Name Services

An ExternalName Service maps a cluster DNS name to an outside hostname via a CNAME, letting you reference external systems with cluster-internal names.

spec:
  type: ExternalName
  externalName: api.example.com

Common Discovery Failures

When name resolution fails, check:

  • Label selector mismatch (no endpoints)
  • Wrong namespace in the FQDN
  • CoreDNS pods unhealthy
  • NetworkPolicy blocking DNS (port 53)

Quick Check

Test your service discovery knowledge.

Recap

You now understand container service discovery:

  • Services give stable ClusterIPs and DNS names
  • CoreDNS resolves service.namespace.svc.cluster.local
  • EndpointSlices track ready pods
  • Headless and ExternalName Services for special cases
  • Debug with nslookup from inside pods

This builds on your Docker network modes and Kubernetes networking basics.

Gratis para empezar

Aprende Linux Networking & TCP/IP for Developers con un tutor de IA — gratis

Escribe y ejecuta código real en tu navegador, obtén ayuda instantánea de un tutor de IA disponible 24/7 y continúa donde lo dejaste en la web o en la aplicación.

Cursos
12
Lecciones
48

Preguntas frecuentes

¿La lección «Detección de servicios y DNS en Kubernetes» es gratis?

Sí — el texto completo de «Detección de servicios y DNS en Kubernetes» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de Linux Networking & TCP/IP for Developers, actualiza a CoddyKit PRO. El curso de Linux Networking & TCP/IP for Developers incluye 4 lecciones en total.

¿Qué aprenderé en «Detección de servicios y DNS en Kubernetes»?

Aprenda cómo se encuentran los contenedores entre sí: el DNS del clúster, los objetos Service y el flujo de resolución que permite direccionar los microservicios por nombre. Practicas Linux Networking & TCP/IP for Developers con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.

¿Necesito experiencia previa para empezar Linux Networking & TCP/IP for Developers?

No se requiere experiencia previa. Linux Networking & TCP/IP for Developers en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 4 de 4.

¿Cuánto tiempo toma la lección «Detección de servicios y DNS en Kubernetes»?

La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.

¿Puedo escribir y ejecutar código en esta lección de Linux Networking & TCP/IP for Developers?

Sí. Cada lección de Linux Networking & TCP/IP for Developers incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.

Todas las lecciones de este curso

  1. Modos de red de Docker
  2. Fundamentos de redes en Kubernetes
  3. Políticas de red en contenedores
  4. Detección de servicios y DNS en Kubernetes
← Volver a Linux Networking & TCP/IP for Developers