A
application pod once created need to be accessed outside. The
application running inside this container can be accessed directly by
the Pod ip address and Port number ( if the pod is exposed by a port ) but there is one problem over here. What is the a pod is dead, k8s engine will create a new pod with different Ip address. So we need a consistent way of accessing the pod though it recreates multiple times. This is where service comes into picture.
A
Kubernetes service works in a different way. Let's say we have five
application pods running on different nodes. A Service once created will
load balance requests to these 5 pods that runs on a different node. The service created will expose a IP address and Port. users can access this ip
address and port by which the requests will be routed to any of the 5
application pods. The routing will be taken care by the service. The
Service when created will be assigned to a unique IP address which will
have the lifespan of a service
There are different ways to get external traffic into the kubernetes cluster by nodePort, ClusterIP, Load Balancer and Ingress
ClusterIP – ClusterIP
Is the default type of service created. Using Cluster IP other
application running inside the cluster can access. This will not provide
any external access.
[root@manja17-I13330 kubenetes-config]# cat clusterIP-service-pod.yml
apiVersion: v1
kind: Service
metadata:
name: simpleservice
spec:
type: ClusterIP
ports:
- port: 80
targetPort: 9876
protocol: TCP
selector:
app: testingService-service
The ClusterIP will be working as below,
[root@manja17-I13330 kubenetes-config]# kubectl get svc | grep simpleservice
simpleservice ClusterIP 10.96.212.109 80/TCP 2m
[root@manja17-I13330 kubenetes-config]# curl 10.96.212.109:80/info
{"host": "10.96.212.109", "version": "0.5.0", "from": "10.32.0.1"}
Node Port - NodePort works in a different way. NodePort opens a specific port on all nodes and any traffic that is sent to this port is forwarded to the service. This will work some thing like below,
As
shown in the above image, Ports are opened on each node, and once a
user access the ports on that nodes those requests are then forwarded to
the service from where there are sent to the actual pods.
[root@manja17-I13330 kubenetes-config]# cat nodePort-service-pod.yml
apiVersion: v1
kind: Service
metadata:
name: simpleservice
spec:
type: NodePort
ports:
- port: 80
targetPort: 9876
nodePort: 30036
protocol: TCP
selector:
app: testingService-service
The NodePort definition
will have a New port declared, which is the port that will opened on
the Node as above. If no Port is defined a random will be taken.
Page Break
[root@manja17-I13330 kubenetes-config]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
simpleservice NodePort 10.109.124.21 80:30036/TCP 4m
[root@manja17-I13330 kubenetes-config]# curl 10.109.124.21:80/info
{"host": "10.109.124.21", "version": "0.5.0", "from": "10.32.0.1"}
Load Balancer - A
load balancer is a traditional way of exposing the service to the
external world. All traffic on the port you specify will be forwarded
to this service. The only drawback with this is when we configure a load balancer from a Aws etc, there will be additional charges
Ingress – Unlike all above, Ingress is actually not a type of service. It is router that sits before multiple services that routes requests into the cluster. An
Ingress Controller can sit in front of many services within our
cluster, routing traffic to them and depending on the implementation,
can also add functionality like SSL , path rewrites, or name based virtual hosts. This
is most useful if we want to expose multiple services under the same IP
address and these services all use the Same L7 protocol (http). Since Ingress is said to be a smart router we can get many features like SSL, Authentication, Routing etc ).
No comments :
Post a Comment