Thursday, May 17, 2018

kubernetes - Services

we Know that container running in pod will share same network space. Every pod will have an IP
address. Once the Pod is killed or destroyed a new pod is created by replication controller which
will get new IP address. How can an user still access the application with changing IP address
( Container getting killed and recreated )?

This is where service comes to help. Service provides a single name for a set of pods.They
basically act as a load balancer to a set of same application running in different pods. Each
service will be assigned with a virtual IP address which remains constant until the service life
time.

The service created is attached to the application/pods. User will be accessing the service
address rather the pod address/IP address. The service will keep track of the pds being created
and destroyed and the load will be shared with them.

Create a Service yml file for the pod that we created earlier using,
[root@manja17-I13330 kubenetes-config]# cat testing-service-pod.yml
apiVersion: v1
kind: ReplicationController
metadata:
 name: testing-service
spec:
 replicas: 1
 selector:
   app: testingService-service
 template:
   metadata:
     name: testingService
     labels:
       app: testingService-service
   spec:
     containers:
     - name: test-ser
       image: docker.io/jagadesh1982/testing-service
       ports:
       - containerPort: 9876

Create the service using the
[root@manja17-I13330 kubenetes-config]# cat testingService-service.yml
apiVersion: v1
kind: Service
metadata:
 name: simpleservice
spec:
 ports:
   - port: 80
     targetPort: 9876
 selector:
   app: testingService-service

In the above service we are actually creating a service or endpoint to access for the pod with label set as “app=testingService-service”. Though the pod endpoint to access the application is 9876, we created a service with endpoint 80. So when we access the service on port 80 ,it will
routes to the application on port 9876.

Check if the Replication Controller are created,
[root@manja17-I13330 kubenetes-config]# kubectl get rc
NAME              DESIRED CURRENT   READY AGE
testing-service   1 1       1         9s

Check for the pods are created,
[root@manja17-I13330 kubenetes-config]# kubectl get pods
NAME                         READY STATUS RESTARTS  AGE
testing-service-v2kk4   1/1 Running 0                51s

Now lets see if the service is created are not,
[root@manja17-I13330 kubenetes-config]# kubectl get svc
NAME              TYPE CLUSTER-IP     EXTERNAL-IP PORT(S) AGE
kubernetes      ClusterIP 10.96.0.1         <none> 443/TCP 13d
simpleservice   ClusterIP 10.97.14.179   <none> 80/TCP 4s

Now we can access the application using,
[root@manja17-I13330 kubenetes-config]# curl 10.97.14.179:80/info
{"host": "10.97.14.179", "version": "0.5.0", "from": "10.32.0.1"}

Because every node in a Kubernetes cluster runs a kube-proxy, the kube-proxy watches the
Kubernetes API server for the addition and removal of services. For each new service,
kube-proxy opens a (randomly chosen) port on the local node. Any connections made to that
port are proxied to one of the corresponding backend pods.

More to come. Happy learning :-)

No comments :

Post a Comment