Kubernetes is an prominent container orchestration. In Kubernetes cluster, the master node will orchest tons of worker nodes to gear system to desired requirement. The user/devloper will input their requirements to system via manifest files (YAML format) to declare the expected state (1 load balancer, 4 replicas of auth services, 4 replicas of wordpress services …) then Kubernetes will automate all steps to drive all systems to meet that goal.
Kubernetes Network Communcation
The backbone to leverage the performace of Kubernetes are:
- Service Discovery (Data Plan Bus)
- System monitoring (Control Plan Bus)
In above figure, we can assume that pods have different color are different services. Those services must communicate with each others via Data Plan Bus. How to keep these communication fast and secure are what we are working on. That brings us to another layer named service mesh (Istio).
We can think of it as an upper layer on top of TCP/IP in OS to make sure communicate between service-to-service are accuracy. Why? Some pods maybe up and down while running so the message maybe get lost due to pods are stopped. Should we resend that message after pods are recovered? How can we say that the communication is fast enough? We need metrics, right? We need to track down all the communcation time and can get detailed information to analyse the issue, where is the bottleneck? And service mesh should provide us all the tools to do that. As of now, Istio and linkerd are active developing to support these features. Also, many commercial solutions are comming.