liveBook · Manning

Internal service

As explained in Kubernetes for Developers

An internal service is a Kubernetes Service addressed through a private cluster IP for communication among workloads inside the cluster.

Suppose your frontend needs an avatar generator, but users should reach only the frontend. Run the generator behind an internal Kubernetes Service. Other Pods can call it through a cluster-local IP address; it needs no public IP. section 7.1 section 7.1.2

A Service of type ClusterIP gives its backing Pods a virtual IP that Pods throughout the cluster can address. Kubernetes proxies requests to the Pods behind the Service. This lets application components run separately—and, when useful, scale independently—without making every component public. section 7.1 section 6.4.2

Choose the access method to match the job:

  • ClusterIP is the usual choice for communication between Pods. Its cluster IP is not directly reachable from outside the cluster. section 7.1 section 7.1.2
  • NodePort also has a cluster IP, but reserves a port on each node for access from outside. LoadBalancer adds a public-facing access method. section 7.1
  • Ingress can route HTTP requests by path or hostname to multiple internal services through one external IP. In the supplied Ingress configuration, a backend Service uses NodePort. section 7.2

An internal avatar service

Create a Deployment for the avatar generator and a ClusterIP Service whose selector matches its Pods. Inspect the assigned address with `kubectl get service`; another Pod can then send an HTTP request to that cluster IP. For a local test without giving the Service an external IP, run `kubectl port-forward service/robohash-internal 8080:80` and open `http://localhost:8080/example`. Environment variables and DNS are also available to discover internal services. section 7.1.2 section 7.3

Listing 7.2 Chapter07/7.1_InternalServices/robohash-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: robohash-internal
spec:
  selector:
    app: robohash
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
  type: ClusterIP      #1
#1 Defines a local service

The Service manifest shows the two essential links: `type: ClusterIP` keeps the access method internal, while the selector identifies the Pods that receive requests. section 7.1.2

How Kubernetes for Developers covers it

How deep it goes
Works through a Deployment, ClusterIP Service manifest, IP lookup, and port-forward test, while describing proxy routing at a practical level.
Examples
Uses an avatar generator behind a ClusterIP Service and Ingress paths that route to avatar and time services.
What it assumes
Assumes a containerized workload and introduces internal Service configuration through a concrete Deployment and manifest.
What you can do after
Build it from scratch with a Deployment and ClusterIP Service, then inspect its IP and test it with kubectl port-forward.
How it connects
Links ClusterIP and Pods to microservices, independent scaling, NodePort, and Ingress routing.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Kubernetes for Developers. The section links point to the parts of the book it draws on.