Introduction

Kubernetes Ingress resources are defined for HTTP and HTTPS routing, so pure TCP exposure requires controller-specific extensions. Many teams discover this when they need to publish databases, message brokers, or custom binary protocols. A stable setup depends on choosing the right controller feature, mapping ports carefully, and validating network policy boundaries.

Core Topic Sections

HTTP Ingress versus TCP forwarding

Native Kubernetes Ingress focuses on Layer 7 routing rules such as host and path. TCP services operate at Layer 4, where packets are forwarded by port instead of HTTP semantics. Because of this, TCP is usually configured through the ingress controller itself, not the standard Ingress object.

A common pattern with NGINX Ingress Controller is a dedicated ConfigMap that maps external ports to backend services.

Example with NGINX Ingress Controller

Create a ConfigMap that maps port 9000 on the ingress controller to a service in your namespace.

1apiVersion: v1
2kind: ConfigMap
3metadata:
4  name: tcp-services
5  namespace: ingress-nginx
6data:
7  "9000": "default/my-tcp-app:9000"

Then ensure the ingress controller deployment references that map and exposes the port on its Service.

1apiVersion: v1
2kind: Service
3metadata:
4  name: ingress-nginx-controller
5  namespace: ingress-nginx
6spec:
7  type: LoadBalancer
8  ports:
9    - name: http
10      port: 80
11      targetPort: 80
12    - name: https
13      port: 443
14      targetPort: 443
15    - name: tcp-9000
16      port: 9000
17      targetPort: 9000
18  selector:
19    app.kubernetes.io/name: ingress-nginx

Controller documentation for your installed version should be the source of truth for exact flags and chart values.

Backend service and pod readiness

Expose your TCP application as a regular ClusterIP service. Readiness probes are still important so the controller forwards only to healthy pods.

1apiVersion: v1
2kind: Service
3metadata:
4  name: my-tcp-app
5  namespace: default
6spec:
7  selector:
8    app: my-tcp-app
9  ports:
10    - name: tcp
11      port: 9000
12      targetPort: 9000

If readiness is missing or too permissive, you may see intermittent connection resets under rollout conditions.

Test end-to-end connectivity

After applying manifests, validate from outside and inside the cluster.

1kubectl -n ingress-nginx get svc ingress-nginx-controller
2
3# from a client machine
4nc -vz <load-balancer-hostname> 9000
5
6# from inside cluster
7kubectl run net-debug --rm -it --restart=Never --image=busybox -- sh
8nc -vz my-tcp-app.default.svc.cluster.local 9000

Testing both paths isolates whether failures are in service routing, external load balancer configuration, or pod-level listeners.

Security and policy controls

Exposing TCP ports can broaden attack surface quickly. Lock down access with security groups, firewall rules, and Kubernetes NetworkPolicy where supported. If traffic contains sensitive data, enforce TLS at the application layer or terminate TLS where your protocol allows.

Also document ownership per exposed port. Port mapping drift becomes difficult to audit when multiple teams share one ingress controller.

Alternatives to TCP ingress extension

For some workloads, a dedicated Service of type LoadBalancer is simpler and clearer than controller-level TCP maps. This is often better when a single service needs direct exposure and no shared ingress behavior. Gateway API implementations can also provide cleaner multi-protocol routing in modern clusters.

Common Pitfalls

• Expecting standard Ingress resources to route raw TCP without controller-specific configuration.
• Forgetting to expose the mapped TCP port on the ingress controller Service.
• Mapping to the wrong namespace or service name in the TCP ConfigMap.
• Skipping readiness checks, which causes transient resets during rollouts.
• Opening external TCP ports without network policy, firewall, or ownership controls.

Summary

• Kubernetes HTTP Ingress does not directly cover generic TCP forwarding.
• Use ingress-controller TCP extension features or a dedicated LoadBalancer service.
• Keep TCP port maps, controller service ports, and backend service ports consistent.
• Validate connectivity from both external and in-cluster paths.
• Treat exposed TCP ports as security-sensitive infrastructure with explicit policy.