This page describes the different types of KubernetesServices and how Google Kubernetes Engine (GKE) uses Services to group Pod endpoints.

You learn how to create Services by using YAMLexamples. Each Service type uses the Service's stable IP address to reduce thecomplexity of specific networking and communication tasks. For example, you learnhow to use multiple ports and endpoints, as well as how to configure single- ordual-stack options that support IPv4 and IPv6.

To learn how to create a Service, seeExposing applications using services.

This page is for Operators and Developers whoprovision and configure cloud resources and deploy apps and services. To learnmore about common roles and example tasks referenced in Google Cloudcontent, seeCommon GKE user roles and tasks.

What is a Kubernetes Service?

The idea of a Service is to group a set of Pod endpoints into a single resource.You can configure various ways to access the grouping. By default, you get astable cluster IP address that clients inside the cluster can use to contactPods in the Service. A client sends a request to the stable IP address, and therequest is routed to one of the Pods in the Service.

A Service identifies its member Pods with a selector. For a Pod to be a memberof the Service, the Pod must have all of the labels specified in the selector.Alabel is an arbitrary key/value pair that is attached to an object.

The following Service manifest has a selector that specifies two labels. Theselector field says any Pod that has both theapp: metrics label and thedepartment:engineering label is a member of this Service.

apiVersion:v1kind:Servicemetadata:name:my-servicespec:# Use labels to select the member Pods of the Service.selector:app:metricsdepartment:engineeringports:...

Why use a Kubernetes Service?

In a Kubernetes cluster, each Pod has an internal IP address. But the Pods in aDeployment come and go, and their IP addresses change. So it doesn't make senseto use Pod IP addresses directly. With a Service, you get a stable IP addressthat lasts for the life of the Service, even as the IP addresses of the memberPods change.

A Service also provides load balancing. Clients call a single, stable IPaddress, and their requests are balanced across the Pods that are members ofthe Service.

Types of Kubernetes Services

There are five types of Services:

• ClusterIP (default): Internal clients send requests to a stable internalIP address.

• NodePort: Clients send requests to the IP address of a node on one ormorenodePort values that are specified by the Service.

• LoadBalancer: Clients send requests to the IP address of a network loadbalancer.

• ExternalName: Internal clients use the DNS name of a Service as an aliasfor an external DNS name.

• Headless: You can use aheadless service when you want a Pod grouping, but don't need a stable IP address.

TheNodePort type is an extension of theClusterIP type. So a Service oftypeNodePort has a cluster IP address.

TheLoadBalancer type is an extension of theNodePort type. So a Service oftypeLoadBalancer has a cluster IP address and one or morenodePort values.

Services of type ClusterIP

When you create a Service of typeClusterIP, Kubernetes creates a stable IPaddress that is accessible from nodes in the cluster.

Here is a manifest for a Service of type ClusterIP:

apiVersion:v1kind:Servicemetadata:name:my-cip-servicespec:selector:app:metricsdepartment:sales# Create a ClusterIP Service. Kubernetes dynamically allocates an IP address# to the Service.type:ClusterIPports:-protocol:TCPport:80targetPort:8080

You cancreate the Serviceby usingkubectl apply -f [MANIFEST_FILE]. After you create the Service, youcan usekubectl get service to see the stable IP address:

NAME             TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)my-cip-service   ClusterIP   10.11.247.213   none          80/TCP

Clients in the cluster call the Service by using the cluster IP address and theTCP port specified in theport field of the Service manifest. The request isforwarded to one of the member Pods on the TCP port specified in thetargetPortfield. For the preceding example, a client calls the Service at10.11.247.213on TCP port 80. The request is forwarded to one of the member Pods on TCP port8080. The member Pod must have a container that is listening on TCPport 8080. If there is no container listening on port 8080, clients will seea message like "Failed to connect" or "This site can't be reached".

Service of type NodePort

When you create a Service of typeNodePort, Kubernetes gives you anodePortvalue. Then the Service is accessible by using the IP address of any node alongwith thenodePort value.

Here is a manifest for a Service of typeNodePort:

apiVersion:v1kind:Servicemetadata:name:my-np-servicespec:selector:app:productsdepartment:sales# Kubernetes allocates a nodePort between 30000 and 32767 for external traffic# that reaches the node IP address. Additionally, Kubernetes dynamically# allocates a clusterIP IP address for internal traffic.type:NodePortports:-protocol:TCPport:80# Route internal traffic that reaches the clusterIP IP address on this port.targetPort:8080

After you create the Service, you can usekubectl get service -o yaml to viewits specification and see thenodePort value.

spec:  clusterIP: 10.11.254.114  externalTrafficPolicy: Cluster  ports:  - nodePort: 32675    port: 80    protocol: TCP    targetPort: 8080

External clients call the Service by using the external IP address of a nodealong with the TCP port specified bynodePort. The request is forwarded toone of the member Pods on the TCP port specified by thetargetPort field.

For example, suppose the external IP address of one of the cluster nodes is203.0.113.2. Then for the preceding example, the external client calls theService at203.0.113.2 on TCP port 32675. The request is forwarded to one ofthe member Pods on TCP port 8080. The member Pod must have a containerlistening on TCP port 8080.

TheNodePort Service type is an extension of theClusterIP Service type. Sointernal clients have two ways to call the Service:

• UseclusterIP andport.
• Use a node's IP address andnodePort.

For some cluster configurations, theexternal Application Load Balanceruses a Service of typeNodePort.

An external Application Load Balancer is a proxy server, and is fundamentallydifferent from theexternal passthrough Network Load Balancerdescribed in this topic underService of type LoadBalancer.

To learn more about Services of type LoadBalancer, seeLoadBalancer Service concepts.

Service of type ExternalName

A Service of typeExternalName provides an internal alias for an external DNSname. Internal clients make requests using the internal DNS name, and therequests are redirected to the external name.

Here is a manifest for a Service of typeExternalName:

apiVersion:v1kind:Servicemetadata:name:my-xn-servicespec:type:ExternalNameexternalName:example.com

When you create a Service, Kubernetes creates a DNS name that internal clientscan use to call the Service. For the preceding example, the DNS name ismy-xn-service.default.svc.cluster.local. When an internal client makes a requestto my-xn-service.default.svc.cluster.local, the request gets redirected toexample.com.

TheExternalName Service type is fundamentally different from the otherService types. In fact, a Service of typeExternalName does not fit thedefinition of Service given at the beginning of this topic. A Service of typeExternalName is not associated with a set of Pods, and it does not have astable IP address. Instead, a Service of typeExternalName is a mapping froman internal DNS name to an external DNS name.

Headless Service

A headless Service is a type of Kubernetes Service that does not allocate a cluster IP address. Instead, a headless Service uses DNS to expose the IP addresses of the Pods that are associated with the Service. This allows you to connect directly to the Pods, instead of going through a proxy.

Headless Services are useful for a variety of scenarios, including:

• Service discovery: You can use a headless Service to implement Service discovery. To implement this, create a Service with a name and a selector. DNS record for the headless service contains all the IPs of the Pods behind the Service that match the selector. Clients can use these DNS records to find the IP addresses of the Pods that are associated with the Service.

• Direct Pod access: Clients can connect directly to the Pods that are associated with a headless Service, which can be useful for Services that require direct access to the underlying Pods, such as load balancers and DNS servers.

• Flexibility: Headless services can be used to create a variety of different topologies, such as load balancers, DNS servers, and distributed databases.

If you have special network requirements for your workloads that can not be solved using headless Services with selectors, there is also the possibility of using headless Services without selectors. Headless Services are a useful tool for accessing Services that are not located within the Kubernetes cluster itself, as the control plane does not create EndpointSlice objects, you can read more about it inService without selectors

The following example is a manifest for a Headless Service:

apiVersion:v1kind:Servicemetadata:name:nginxspec:# Prevent Kubernetes from allocating an IP address to the Service.clusterIP:Noneselector:app:nginxports:-name:httpport:80targetPort:80

Once you have created a headless Service, you can find the IP addresses of the Pods that are associated with the Service by querying the DNS. For example, the following command lists the IP addresses of the Pods that are associated with the nginx Service:

dig +short nginx.default.svc.cluster.local

dig +short +search nginx

kubectl create service clusterip my-svc --clusterip="None" --dry-run=client -o yaml > [file.yaml]

A Service is an abstraction in the sense that it is not a process that listenson some network interface. Part of the abstraction is implemented in theiptables rulesof the cluster nodes. Depending on the type of the Service, other parts of theabstraction are implemented by either anexternal passthrough Network Load Balancer or anexternal Application Load Balancer.

Arbitrary Service ports

The value of theport field in a Service manifest is arbitrary. However,the value oftargetPort is not arbitrary. Each member Pod must have acontainer listening ontargetPort.

Here's a Service, of typeLoadBalancer, that has aport value of 50000:

apiVersion:v1kind:Servicemetadata:name:my-ap-servicespec:# Set your own IP address for internal traffic instead of letting Kubernetes# select one for you.clusterIP:10.11.241.93externalTrafficPolicy:Clusterports:-nodePort:30641# Set a port for external traffic that reaches the node IP address.port:50000# Set a port for internal traffic that reaches the clusterIP IP address.protocol:TCPtargetPort:8080selector:app:partsdepartment:engineeringsessionAffinity:Nonetype:LoadBalancerstatus:loadBalancer:ingress:-ip:203.0.113.200

A client calls the Service at203.0.113.200 on TCP port 50000. The request isforwarded to one of the member Pods on TCP port 8080.

Multiple ports

Theports field of a Service is an array ofServicePort objects. The ServicePort object has these fields:

• name
• protocol
• port
• targetPort
• nodePort

If you have more than one ServicePort, each ServicePort must have a uniquename.

Here is a Service, of typeLoadBalancer, that has twoServicePort objects:

apiVersion:v1kind:Servicemetadata:name:my-tp-servicespec:clusterIP:10.11.242.196externalTrafficPolicy:Clusterports:# Forward traffic that reaches port 31233 on the node IP address, or port# 60000 on the clusterIP IP address, to port 50000 on a member Pod.-name:my-first-service-portnodePort:31233port:60000protocol:TCPtargetPort:50000# Forward traffic that reaches port 31081 on the node IP address, or port# 60001 on the clusterIP IP address, to port 8080 on a member Pod.-name:my-second-service-portnodePort:31081port:60001protocol:TCPtargetPort:8080selector:app:testsdepartment:engineeringsessionAffinity:Nonetype:LoadBalancerstatus:loadBalancer:ingress:-ip:203.0.113.201

When you create a Service, Kubernetes creates anEndpoints object that has the same name as your Service. Kubernetes uses the Endpointsobject to keep track of which Pods are members of the Service.

Single-stack and dual-stack Services

You can create an IPv6 Service of typeClusterIPorNodePort.

For each of these Service types, you can defineipFamilies andipFamilyPolicy fields as either IPv4, IPv6, or adual-stack Service.

What's next

• Learn more aboutKubernetes Services
• Expose Applications using Services
• Learn more aboutStatefulSets
• Learn more aboutIngress