Kubernetes - Services [Part 6]

 Labels & Annotation:

We can list the deployments along with labels:

#kubectl get deployments --show-labels

List the version with selector flag:

#kubectl get pods --selector="ver=2"

#kubectl get pods --selector="app in (test1,test2)"

Annotations provide a place to store additional metadata for the Kubernetes objects with the sole purpose of assisting tools and libraries. Labels are used to identify and group the objects whereas annotations are used to provide extra information about where an object came from, how to use it or policy around that object. Annotation used to track a rollout status and provide a necessary information require for rollback.

Annotation can be used to hold configuration data for the external tool such as third-party schedulers and configuration tools.

Services :

The DNS is a traditional system of service discovery on the Internet.

kubectl run is an easy way to create a deployment and kubectl expose is used to create a service.

ClusterIP:

A ClusterIP service is the default Kubernetes service. It gives you a service inside your cluster that other apps inside your cluster can access. There is no external access. This is a special IP address the system will load-balance across all of the Pods that are identified by the selector.

The YAML for a ClusterIP follow like this.

apiVersion: v1
kind: Service
metadata:
name: my-internal-service
spec:
selector:
app: my-app
type: ClusterIP
ports:
- name: http
port: 80
targetPort: 80
protocol: TCP

The customer request flow through as:

request -> proxy -> service -> Pod

Start the proxy to access the URL:

#kubectl proxy --port=8080

We can able to navigate this service as blow after enabled the proxy.

http://localhost:8080/api/v1/proxy/namespaces/default/services/my-internal-service:http/

P.S: We should not expose your service to the internet or any of production services.

NodePort:

A NodePort service is a most primitive way to get a external traffic directly to your service. NodePort as name implies open a specific port on all the nodes and traffic that sent to this port is forwarded to the service.

The Yaml file for NodePort setup as follows:

apiVersion: v1
kind: Service
metadata:
name: my-nodeport-service
spec:
selector:
app: my-app
type: NodePort
ports:
- name: http
port: 80
targetPort: 80
nodePort: 30036
protocol: TCP

The main difference between NodePort and ClusterIP is allocated additional port called the NodePort that specifies which port to open on all nodes, It will take a random port if we are not specific in the configuration file.

LoadBalancer:

A LoadBalancer is a standard way to expose your application to the internet. 

This is a default method if you want to expose directly to your service with safeway. All traffic on the port you specify will be forward to the service. but each service will get an own ip address while routing through loadbalancer. We have a to pay for the loadbalancer per exposed service.

Ingress:

It is not a type of service but it will act as smart router Infront of your application.

This will allow us to perform the path based and subdomain based routing into backend services.

The Yaml file for the Kubernetes object as follows:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: my-ingress
spec:
backend:
serviceName: other
servicePort: 8080
rules:
- host: foo.mydomain.com
http:
paths:
- backend:
serviceName: foo
servicePort: 8080
- host: mydomain.com
http:
paths:
- path: /bar/*
backend:
serviceName: bar
servicePort: 8080

Ingress is a most useful if you want to expose multiple services under the same IP address and all the services are use the same L7 protocol [http]. We can buy a single loadbalance and optimal use the services through Ingress with low cost.