Service

Service Types

A service can be defined as a logical set of pods. It can be defined as an abstraction on the top of the
pod which provides a single IP address and DNS name by which pods can be accessed.

Service is a named abstraction of software service (for example, mysql) consisting of local port (for
example 3306) that the proxy listens on, and the selector that determines which pods will answer
requests sent through the proxy.

With Service, it is very easy to manage load balancing configuration. It helps pods to scale very easily.

A service is a REST object in Kubernetes whose definition can be posted to KubernetesapiServer on the
Kubernetes master to create a new instance.

Kubernetes supports different types of services for different use cases:

 A ClusterIP service makes it accessible from any of the Kubernetes cluster’s nodes. The use of
virtual IP addresses for this purpose makes it possible to have several pods expose the same
port on the same node – All of these pods will be accessible via a unique IP address.

Cluster IP----Accessing PODs from Master Machine

 For a NodePort service, Kubernetes allocates a port from a configured range (default is 30000-
32767), and each node forwards that port, which is the same on each node, to the service. It is
possible to define a specific port number, but you should take care to avoid potential port
conflicts.
  For a LoadBalancer service, Kubernetes provisions an external load balancer. The type of
service depends on how the specific Kubernetes cluster is configured.
 An ExternalIP service uses an IP address from the predefined pool of external IP addresses
routed to the cluster’s nodes. These external IP addresses are not managed by Kubernetes; they
are the responsibility of the cluster administrator.
 It is also possible to create and use services without selectors. A user can manually map the
service to specific endpoints, and the service works as if it had a selector. The traffic is routed
to endpoints defined by the user
 ExternalName is a special case of service that does not have selectors. It does not define any
ports or endpoints. Instead, it returns the name of an external service that resides outside the
cluster. Such a service works in the same way as others, with the only difference being that the
redirection happens at the DNS level without proxying or forwarding. Later, you may decide to
replace an external service with an internal one. In this case, you will need to replace a service
definition in your application.

Service v1 core

https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/#service-v1-core

Field Description
APIVersion defines the versioned schema of this representation of an object.
apiVersion
Servers should convert recognized schemas to the latest internal value, and may
string
reject unrecognized values.
Kind is a string value representing the REST resource this object represents.
kind
Servers may infer this from the endpoint the client submits requests to. Cannot
string
be updated.
metadata
Standard object's metadata.
ObjectMeta
spec
Spec defines the behavior of a service.
ServiceSpec
status Most recently observed status of the service. Populated by the system. Read-
ServiceStatus only.
Service Discovery

Kubernetes supports two modes of finding a service: through environment variables and DNS.

Environment Variables

Kubernetes injects a set of environment variables into pods for each active service. The order is
important: the service should be created before, for example, the replication controller or replica set
creates a pod’s replicas. Such environment variables contain service host and port, for example:

MYSQL_SERVICE_HOST=10.0.150.150
MYSQL_SERVICE_PORT=3306

An application in the pod can use these variables to establish a connection to the service.

DNS

Kubernetes automatically assigns DNS names to services. A special DNS record can be used to specify
port numbers as well. To use DNS for service discovery, a Kubernetes cluster should be properly
configured to support it.

Kubernetes Services for Real Applications

For real applications, you may want more granular control of services. Kubernetes allows creating
services, as well as other building blocks, using a definition from a file. For example, a definition for a
MySQL service might look like this:

apiVersion: v1
kind: Service
metadata:
name:mysql
spec:
ports:
- port:3306
protocol: TCP
targetPort:3306
selector:
app:mysql

This YAML file contains a definition of a ClusterIP service (ClusterIP is the default service type), that
exposes the pods’ port 3306 to the same port on a cluster’s internal IP address. A database backend
usually should not be accessible for external clients, but it should be accessible for other pods, running
in the same cluster, so the ClusterIP type fits well with this use case.

For an application that should be accessible from the outside, you can use, for example, a NodePort
service:
apiVersion: v1
kind: Service
metadata:
name:wordpress
labels:
app:wordpress
spec:
type:NodePort
ports:
- port:80
nodePort:30080
selector:
app:wordpress

This YAML file contains a definition of a NodePort service that exposes the pods’ port 80 to the port
30080 on each node of the Kubernetes cluster.

A Kubernetes service is another building block that provides an additional level of abstraction to
configure access to a set of pods. A service is required because pods in the set are ephemeral, for
example, they can be replaced when a replication controller or replica set scales the set of pods up or
down, running new pods or terminating existing pods accordingly.

A service requires a label selector to define a set of pods and it defines a policy to access that set.
Kubernetes supports several types of services, such as ClusterIP (a service accessible internally through a
virtual IP address), NodePort (a service accessible through a specific port on each cluster’s node),
LoadBalancer (a service that uses an external load balancer), and so on. Kubernetes also supports
service discovery, allowing other pods to dynamically find active services and their parameters, such as
an IP address and port to connect to. A Kubernetes cluster should be properly configured to support, for
example, external load balancers, external IP addresses, and DLabNS for service discovery.