Introduction to Service Mesh and Istio Deployment (Part 3)

Introduction to Service Mesh and Istio Deployment (Part 3)

Extended Readings:
Introduction to Service Mesh and Istio Deployment (Part 1)
Introduction to Service Mesh and Istio Deployment (Part 2)

Zipkin Deployment

Istio provide zipin’s yaml addon to quickly deploy zipkin to namespace=istio-system and execute the following command.

For testing purposes, set the node port to allow external access to zipkin and change type:ClusterIP to type: NodePort

After finishing with the above instructions, run it again to see how many node ports there are.

Query which node zipkin is deployed on

On ubuntu3, make sure the corresponding ip is 10.0.11.13, then use the browser to open 10.0.11.13:32229. Refresh the Bookinfor page to let zipkin grab the data, as shown below in Figure 14.

Deploying Prometheus

With the zipkin deployment method, execute the following command and modify the svc to the node port and query the deployment node to open the corresponding URL. The result is shown in Figure 15.

Prometheus with Grafana

After deploying Prometheus, execute the following command and open the URL shown in Figure 16 using the same method.

Prometheus with Servicegraph

After Prometheus is deployed, execute the following command and open http://192.168.56.12:30835/dotviz and refresh the Bookinfo page. This will allow the service graph to dynamically generate traffic topology as shown in Figure 17

Service Mesh and Container Security

Due to the frequent IP changes the container/pod, the network firewalls for L3/L4 couldn’t effectively function in the container environment. Therefore, in the container security products, container firewalls are mentioned to filter the container’s demand for L7. Compared to the structure and ideas of Service Mesh, it can be said that these two tools are exactly the same. In addition, these products have similar structure to the cilium architecture, but the cilium has higher requirements for the kernel and deployment of it is relatively complicated.

For the firewall policies, Service Mesh’s concept is the same as current container security products. The main focus of these products are the establishment and execution of the white-list. Of course, a black-list can also be set to reject specific connections. Additionally, Service Mesh mainly deals the L7 connection. In regards to service discovery and TLS two-way communication, it can be said that currently the Service Mesh Project/Product has implemented many container security products. Not only does Service Mesh make it easier to manage online connections, the introduction of Service mesh also fulfills the needs for containerized service connection and security requirements of the product environment.

Istio vs. Linkerd

參考資料:A sidecar for your service mesh

As seen in Table 1, whatever features Linker has, Istio also has. Istio also has more Access Control to help each container set a whitelist/blacklist, functioning as the container firewall. Under the support of Istio’s Service Mesh, Linkerd is also integrating with Istio, replacing the Sidecar Role in Envoy. Linkerd will be operated by Istio’s Control Plane, but according to official documents, the latest Istio version was not able to successfully deploy Pilot. Since the documents only describe support for Istio 0.1.6 and not the most updated version, so the problem may be version compatibility.

Written By 呂威廷 迎棧科技工程師

EDM

Select list(s)*

 

Loading