Skip to main content

Kubernetes: 5. Services

  • A service is a stable endpoint to connect to "something"
  • An abstract way to expose an application running on a set of pods as a network service.
  • Services enable communication between various components within and outside of the application
  • With Kubernetes Services there is no need to configure the application for service discovery
  • Kubernetes Service is an object just like Pod, ReplicaSet etc
  • There is always a service running when Kubernetes is installed, Kubernetes API itself
  • When a service is created, kubernetes creates the endpoints (kubectl get endpoints)
  • The endpoints has all the pods associated with that service

Headless Service
  • A headless service is obtained by setting clusterIP  field to None
  • Since there is no virtual IP address, there is no load balancer either
  • The DNS service will return the pods' IP addresses as multiple A records
  • This gives us an easy way to discover all the replicas for a deployment
  • This is useful for creating stateful services like DB, ElasticCache which requires persistent connection with a pod
What is Service Discovery
This is the process of making a client aware to which server to connect to.
In good old ways we used to store the server information in a configuration file in Web application to which the client connects.
But now with Cloud and Micro Services architecture, the nodes are created/destroyed depending on the load. So we cannot have a Static IP to connect to. To overcome this a Service Registry is maintained, which holds the information of each node, when it comes alive and updates the information based on the heart beat. There are 2 types of service discovery

1. Client Side Service Discovery. Client connects to the registry and gets the information for which 
    node to connect to.
2. Server Side Service Discovery. Client connects to LB which then talks to service registry to get the 
    information. Eg AWS ELB
  • The default type (ClusterIP) only works for internal traffic
  • If we want to accept external traffic, we can use one of these:
    • NodePort (expose a service on a TCP port between 30000-32768)
    • LoadBalancer (provision a cloud load balancer for our service)
    • ExternalIP (use one node's external IP address)
    • Ingress (a special mechanism for HTTP services)
Service Types:
  1. NodePort
  2. Cluster IP
  3. Load Balancer
Node Port Service
  • A node port service listens to traffic on a host-node port and forwards it to a port on the pod port
  • This is called node port service, as the service is listening on the node port
  • Node Ports can only be between 30000 - 32767
  • Service gets an IP called clusterIP, but this is not used in NodePort
    1. NodePort -> Port exposed on the node. This is not mandatory, if not specified Kubernetes automatically allocates this.
    2. Port -> The port exposed on the sevice, nodePort forwards traffic to this port. This is mandatory.
    3. TargetPort -> The port exposed on the container, service port forwards traffic to this port. This is not mandatory, if not specified Kubernetes allocates the same port as mentioned in the service
  • When we execute kubectl get services, we can see that the Type is NodePort, the PORT(S) will specify the service port and the node port using which the application is accessed
 
 
service-nodeport-definition.yaml
apiVersion: v1
kind: Service
metadata:
    name: myapp-service

spec:
    type: NodePort
    ports:
    - targetPort: 80
      port: 80
      nodePort: 30008
selector:
    app: myapp
    type: front-end


ClusterIP
  • In this service, Kubernetes creates a Virtual IP inside the cluster to enable communication between different services
  • When we execute kubectl get services, we can see that the Type is clusterIP, the CLUSTER-IP address has to be used to access the application
service-clusterip-definition.yaml
apiVersion: v1
kind: Service
metadata:
    name: backend-service

spec:
    type: clusterIP
    ports:
    - targetPort: 80      --container-port
      port: 80            --service-port
    selector:
        app: myapp
        type: front-end


LoadBalancer
  • In this service a LB is created in the selected Cloud Platform
  • LB distributes the traffic across different services
kubectl create -f service-nodeport-definition.yaml 
-> Create service definition

kubectl get services 
-> Get the list of existing services

kubectl get endpoints
-> Get the list of endpoints associated with the services
Labels:

Comments

Post a Comment

Popular posts from this blog

Kubernetes: 15. Multiple Schedulers

Custom Scheduler Kubernetes allows to create custom schedulers There can be multiple schedulers running at a same time apart from the default scheduler or A custom scheduler can replace the default kube-scheduler to become the default one So a few pods that requires additional checks apart from taints and toleration, node affinity can go through the custom scheduler before getting scheduled on the node Whereas the rest of the pods can go through the default kube-scheduler Create Custom Scheduler We can either download the kube-scheduler and run it as a service or alternatively create it using a static pod Below here we are downloading the binaries to run it The property scheduler-name is used to define the name of the scheduler, if not set then it will be defaulted to default-scheduler For your custom schedulers, update this property name to set a custom name for your scheduler For Static pods, the name can be updated directly in the pod-definition file Use kubectl create -f <pod-de...
Post a Comment
Read more

Kubernetes: 19. Configure Application

Configuring application consists of Configuring commands and arguments on applications Configuring environment variables Configuring secrets Docker Commands docker run ubuntu  -> Runs ubuntu container and exit, container CMD is set to [bash], so the container quitely exits docker run ubuntu echo "Hello World" -> Runs ubuntu container, prints "Hello World" exits quitely. To update the default settings, create your own image from the base image lets call this ubuntu-sleeper image FROM ubuntu CMD sleep 5 CMD can also be mentioned in the JSON format like CMD ["sleep", "5"] Note that with JSON format the first element should always be the command to execute,  for eg, it CANNOT be ["sleep 5"] Run build the new ubuntu-sleeper image and run the new image docker build -t ubuntu-sleeper .  -> Build the image docker run ubuntu-sleeper -> Run the new image So the new image will launch ubuntu container, sleep for 5 seconds and quitely ex...
Post a Comment
Read more

Kubernetes: 8. Labels & Selectors

Labels Labels are a way of grouping the objects While Kubernetes understands the objects it create, it is easier to identify the objects by using custom labels With labels you group the objects by types (Pods, Services, ReplicaSet etc) or by Applications For a pod, labels are defined under the metadata section Selectors Selectors are used to filter the objects using labels defined on them Using kubectl and selector pods can be listed by filtering on the labels attached to them If a Selector has multiple labels, they are understood as logical AND, which means pods must match all labels. pod-definition.yaml apiVersion: v1 kind: Pod metadata:      name: myapp-pod      labels:           app: myapp           location: IN spec:      containers:      - name: nginx-container        image: nginx kubectl get pods ...
Post a Comment
Read more