Introduce
Deploying the microservices system on the server is always a big challenge, and when Kubernetes was born, it made it somewhat easier to deploy the microservices system on the server. But we will face the next challenge is how to communicate between services inside Kubernetes, because Kubernetes was not born as a networking solution, so Istio was born, Istio was developed based on Service Mesh .
With K8S, we will use Pods to deploy services, before learning about Service Mesh, we will see how the default communication between Pods inside K8S is and what is it restricted?
Internal Pod Communication
In K8S so that Pods located in different worker nodes can communicate with each other, K8S uses Container Network Interface (CNI) , and inside a worker node so that Pods can communicate with each other, K8S uses Container Network Interface (CNI). use kube-proxy .
When we create a Pod or Service, kube-proxy will update the iptables rules so that the Pods can communicate with each other, for example as follows.
When we create a Service named B, the Kubernetes API Server will notify the kube-proxy at the worker node to update the iptables rules and add the rule for Service B, then if there is a Pod that calls Service B, its request will be first. First, it will go through iptables, now iptables will see what Service B this guy really IP will include, next iptables will send a request to one of the IPs it finds in a random way.
This is how kube-proxy works, but it has the following limitations:
- The request it sends to the Pods is random.
- Traffic cannot be divided by percentage.
- Canary releases or blue-green releases cannot be performed.
- Difficult to monitor and catch errors.
Especially in the microservices system, the communication between services needs to be secure, be able to monitor and track errors, measure the time of each request, and to perform these functions, we must install it ourselves. library inside our application, for example as follows.
There is nothing wrong with this, but these processes are clearly taking up resources of the main application, and when a developer writes code, it is also necessary to write more code for this part, when often we just want the developer to focus. into the logic of the application.
Thus the service mesh was born.
Service Mesh
Service Mesh is a tool that will add a separate network layer (dedicated network layer) in front of the application, this network layer will provide additional features such as security, network layer monitoring for the application instead of having to do it. show it in the app, illustration.
Service Mesh consists of two main components: control plane and data plane :
- The control plane will perform the role of managing all services.
- The data plane will play the role of handling the communication between services.
When we deploy the service mesh on K8S, then the data plane will be the proxy sidecar container deployed with the application container, and the control plane will be deployed as a separate Pod.
Now instead of managing communication through kube-proxy, our application will communicate with the proxy container, and the proxy container will perform the communication between the Pods. All functions such as security, monitoring, measurement, the proxy container will do all, and our application only needs to focus on the application logic .
Then the two most popular service mesh tools at the time of writing are Istio and Consul, and we will talk about Istio.
Istio
Istio is a service mesh engine built to run on Kubernetes, Istio also consists of two main parts, the control plane and the data plane . With control plane using Istiod container and data plane will be deployed to Pod as a proxy sidecar using Envoy container.
Istiod will manage and configure the proxy sidecar container, acting as a service discovery for the entire proxy. Istiod will convert the entire routing rules configuration to the Envoy configuration and pass it on to the entire Envoy container.
Envoy container will perform communication between Pods, Envoy’s outstanding features:
- Dynamic service discovery
- Load balancing
- TLS termination
- HTTP/2 and gRPC proxies
- Circuit breakers
- Health checks
- Staged rollouts with %-based traffic split
- Fault injection
- Rich metrics
When we install Istio on Kubernetes, when we create a Pod, the Envoy container will automatically be added to our Pod, so we don’t need to manually declare the Envoy container when writing the manifest file for the Pod.
Currently, Istio has been accepted as a project of the Cloud Native Computing Foundation (CNCF), this is the organization that develops Kubernetes, so Istio will continue to develop a lot in the future and will not be abandoned, so you are welcome. roof used.
Please like DevOps VN page to receive notification of the earliest post.
Conclusion
So we have found out why we should use Service Mesh in microservices system and what is Istio. The next lesson we will learn about how to install Istio and how to do some basic things.