A quick walk through k8s service discovery.
There is a need for background service discovery mechanism due to the dynamic nature of the cluster.
k8s assigns domain names for all the pods and services to communicate with them. It runs the infrastructure required for resolving the domain names of the microservices to locate each other.
kubelet - A k8s component in each minion node - configures the DN server location for each container when creating it, using "--cluster-dns="/ "--resolv-conf=" - the IP? it's statically assigned.
Whenever the IP of the service or Pod changes, kubelet sends the updated IP to the API server running in the master.
kubedns - The DN server (with static IP known to pods) listens to the k8s API server for pod or service change and updates its DN records.
And thus, each microservice can communicate with each other via DNs.
The k8s native mechanism runs kube2sky, etcd and skyDNS for DN resolution. kube2sky gets the pod IP changes from API server and stores it in etcd. skyDNS DN server is configured for the pods, looks up etcd and returns the IP addresses.
References:
https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/
http://microservices.io/patterns/3rd-party-registration.html
https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/
https://kubernetes.io/docs/concepts/services-networking/dns-pod-service
https://blog.sophaskins.net/blog/misadventures-with-kube-dns/
https://sysdig.com/blog/understanding-how-kubernetes-services-dns-work/
https://www.projectatomic.io/blog/2015/10/setting-up-skydns/
https://rsmitty.github.io/Manually-Checking-Out-KubeDNS/
https://github.com/coreos/coreos-kubernetes/issues/625
https://thenewstack.io/hackers-guide-kubernetes-networking/
https://www.stratoscale.com/blog/kubernetes/networking-in-kubernetes/
There is a need for background service discovery mechanism due to the dynamic nature of the cluster.
k8s addon kube-dns provide a domain name (DN) based third party service discovery mechanism (pattern) for all the microservices (aka pods in k8s - good idea to keep one microservice in each pod) in the cluster.
k8s assigns domain names for all the pods and services to communicate with them. It runs the infrastructure required for resolving the domain names of the microservices to locate each other.
kubelet - A k8s component in each minion node - configures the DN server location for each container when creating it, using "--cluster-dns="/ "--resolv-conf=" - the IP? it's statically assigned.
Whenever the IP of the service or Pod changes, kubelet sends the updated IP to the API server running in the master.
kubedns - The DN server (with static IP known to pods) listens to the k8s API server for pod or service change and updates its DN records.
And thus, each microservice can communicate with each other via DNs.
The k8s native mechanism runs kube2sky, etcd and skyDNS for DN resolution. kube2sky gets the pod IP changes from API server and stores it in etcd. skyDNS DN server is configured for the pods, looks up etcd and returns the IP addresses.
References:
https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/
http://microservices.io/patterns/3rd-party-registration.html
https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/
https://kubernetes.io/docs/concepts/services-networking/dns-pod-service
https://blog.sophaskins.net/blog/misadventures-with-kube-dns/
https://sysdig.com/blog/understanding-how-kubernetes-services-dns-work/
https://www.projectatomic.io/blog/2015/10/setting-up-skydns/
https://rsmitty.github.io/Manually-Checking-Out-KubeDNS/
https://github.com/coreos/coreos-kubernetes/issues/625
https://thenewstack.io/hackers-guide-kubernetes-networking/
https://www.stratoscale.com/blog/kubernetes/networking-in-kubernetes/




