How to access kubernetes service from external world / outside the world ?
Means that wordpress I would like to hit from the external world.
In docker host, container ip address is reachable within the cluster they run behind the bridge network, same applicable over here in k8s too. By default publicly we cannot access the pod ip address.
K8s overlay network is cluster level network , it works inside the cluster. It means we cannot container ip address outside the cluster.
In docker we use port forwarding concept. K8s says I can also use that approach but that is not recommended as they are lot of container we cannot do port forwarding for each container.
But suppose if you wanted to use older approach can we use ? Basically there are three method:
- Host port: container port
- Service IP exposed as node port
- Ingress controller.
- Nodeport:containerport
Now hit on worker node ip and port 8080
Means if we change the content of the container we can immediately see the changes.
What is drawback then ?
Drawback is for this deployment if we increase the replica, it cannot be run on worker node1 because worker node1 port 8080 is blocked already by first container.
So this is not recommended..
- Node port
We always expose the pod id via serviceip , service ip is by default clusterIP means it is accessible within the cluster.
So now we will be exposing service ip port forwarding. It says don't do individual port forwarding a and instead of do service ip port forwarding.
When we bind service ip to base system port that we call node port. It means it is reachable within the cluster , also outside the cluster too.
Kubectl create deploy test - -image=nginx
Kubectl expose deploy test - -port=8080 - -target-port=80 --type=NodePort
This nodeport means I will bind this service ip with every base system random port (range from 30000+ whatever port is free)
See within the cluster.
If you wanted to see the port in base system do netstart –tnlp | grep –w proxy
Now suppose to be hit from external world.
So what's the difference between older port forwarding and this ?
In initial port forwarding we were directly exposing the container and one base system port is bind to one container and cannot be bind to another container.
However here we haven't expose the container and instead of that we expose the service ip and service ip says just have one limitation any new application cannot use 32163 port
But existing problem like one deployment of two replicas cannot be run on one node because we haven't expose the container here. We expose the service ip only.
How traffic flows ?
End user ---- land on ---> base system ip: base system port ( here Iptables –L via kubeproxy is configured) ---->kernel got to know from iptables this node port is bind to which service ip(by checking iptables –l)----> service ip ---> pod.
All the nodes having same Iptables –L is running because all is having kube-proxy , once we hit the command but in backend it is updating database of all the three nodes. it doesn't matter pod is running on specific node or not , every node is maintaining iptables and it knows where to send the traffic.
In CKA and it is upto there.
Drawback ?
- If we have more microservices then limited number of node port can also cause the issue
- Right now you are giving nodeip: node port but suppose that node got down then ? Also we don't give node ip to enduser so we will be needing a endpoints.
So what we will do we will take a load balancer and add node into it.
End user --> DNS --> ALB --> Node IP:Nodeport ---> kubeproxy (serviceip)----> pod ip
Integrate external load balancer on aws:
Target group:
Now hit this on browser..
Before doing that check on target group, target is healthy or not ?
So if I change the content of the pod then it will reflect.
But node port is also limited , if we have more microservices then these limit can breach.. So now we have a concept of ingress controller.
- Ingress controller.