Introduction

The first thing to clarify is that you usually do not expose a pod directly to the internet. Pods are ephemeral, their IPs are not stable, and they can be recreated at any time. The normal Kubernetes pattern is to expose a stable Service, and then, if internet traffic is needed, put a LoadBalancer or Ingress in front of that Service.

Start with a Service, Not the Pod IP

A pod IP is only meaningful inside the cluster network. If you point internet clients directly at a pod, the address can disappear on reschedule and you lose load balancing and health-based routing.

The minimum stable object is a Service:

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: web-app
5spec:
6  replicas: 2
7  selector:
8    matchLabels:
9      app: web-app
10  template:
11    metadata:
12      labels:
13        app: web-app
14    spec:
15      containers:
16        - name: web-app
17          image: nginx:stable
18          ports:
19            - containerPort: 80
20---
21apiVersion: v1
22kind: Service
23metadata:
24  name: web-app-service
25spec:
26  selector:
27    app: web-app
28  ports:
29    - port: 80
30      targetPort: 80
31  type: ClusterIP

This still does not expose the app to the internet, but it gives you a stable internal endpoint to build on.

Internet Exposure Options

There are three main patterns.

NodePort opens a port on every node. It works, but it is usually the least polished option for internet traffic because you must manage node addresses, firewall rules, and TLS yourself.

LoadBalancer asks the cloud provider to provision an external load balancer for the Service. This is the simplest direct internet path on managed Kubernetes.

1apiVersion: v1
2kind: Service
3metadata:
4  name: web-app-service
5spec:
6  selector:
7    app: web-app
8  ports:
9    - port: 80
10      targetPort: 80
11  type: LoadBalancer

Ingress is usually the better option when you need HTTP or HTTPS routing for several services behind one external entry point.

1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: web-app-ingress
5spec:
6  ingressClassName: nginx
7  rules:
8    - host: app.example.com
9      http:
10        paths:
11          - path: /
12            pathType: Prefix
13            backend:
14              service:
15                name: web-app-service
16                port:
17                  number: 80

An Ingress resource requires an Ingress controller, such as NGINX Ingress, Traefik, or a cloud-specific controller.

Security Matters More Than Reachability

Making a pod reachable is easy compared with making it safe to expose. Internet-facing workloads should usually include:

• TLS termination
• authentication when appropriate
• rate limiting or WAF controls if needed
• network policy inside the cluster
• health checks and readiness probes

If the service is only for internal systems, do not expose it publicly just because it is technically convenient.

Debugging the Path

When exposure fails, check each layer separately:

• are the pods running and ready
• does the Service select the correct pods
• does the Ingress or LoadBalancer point to the correct Service port
• do DNS and TLS match the external hostname
• are cloud firewalls or security groups allowing the traffic

Many "Kubernetes networking" issues are actually selector mismatches or external firewall rules.

Common Pitfalls

• Trying to expose a pod IP directly instead of using a Service.
• Using NodePort for production internet traffic when an Ingress or LoadBalancer would be cleaner.
• Creating an Ingress resource without installing an Ingress controller.
• Forgetting TLS and exposing plain HTTP unnecessarily.
• Debugging from the outside only, without first verifying the pod and Service path inside the cluster.

Summary

• Do not expose a pod directly; expose a Service that fronts the pods.
• Use LoadBalancer for simple external access or Ingress for HTTP and HTTPS routing.
• 'NodePort works, but it is usually not the best internet-facing default.'
• Check readiness, selectors, controller setup, DNS, and firewalls when debugging.
• Reachability is only one part of the job; secure exposure matters just as much.