Use Bookinfo application testing Kuma Service Grid

Recently, open source API management platform Kong service suppliers recently released a new open source project Kuma. This article attempts to bookinfo Kuma grid application deployment in order to help you better understand Kuma project.


Kuma is a common control platform can be used to manage network services (Service Mesh) through seamless network traffic management layer 4-7, micro-services and the API, to solve the technical limitations of the first generation network.


Kuma emphasize its ease of use, to ensure the safety and observability of the underlying network, and even if it provides advanced simple control interface, but users can still perform more advanced configurations. Kuma rapid data collection platform and advanced control platform, allowing users using a simple command, you can set permissions, open indicators and configure routing rules.



In addition, Kuma software-defined security, enable mTLS for all Layer 4 traffic and provide traffic control high-definition, enhanced Layer 4 routing features, but Kuma can quickly achieve tracking and logging capabilities, allowing users to analyze indicators error investigation. Kuma can execute on any platform, including Kubernetes, virtual machines, containers, bare metal and traditional environments, so that the entire organization can practice a native cloud applications.


Kuma use of open-source projects Envoy was developed, and the Envoy is designed for native cloud application proxy, the official noted, Envoy is already the edge of the agency’s standard, along with the service network, has become an important realization native cloud system, because for the large-scale micro-service applications, monitoring, security, and reliability is all the more important.


  • Use the code in this article can be found ( at Github.





First, use the following command to configure the control plane, here it is the creation of a new Mesh named bookinfo in the control plane.


The following picture Bookinfo architecture application, which contains productpage, reviews, details, ratings and other services 4, service providing additional reviews three versions. In this test, we deploy one instance for each version.




In the data plane, in order to deploy all six instances of a server, in order to avoid this conflict, it is necessary to consider a reasonable distribution of inbound and outbound ports for each example, as shown below.


One thing to note, kuma-v0.1.2 version does not support deploying multiple Sidecar on the same host, but the latest master branch has been modified, so kuma-related command-line program used later in this article are the master branch the new compilation out.


Run the following command to configure ratings-v1 service.


Run the following command to configure the details-v1 service.


Here on Istio project bookinfo code has been modified to support RATINGS_PORT configuration parameters, including the following productpage service. Run the following command to configure reviews-v1 service.


Run the following command to configure reviews-v2 service.


Run the following command to configure reviews-v3 service.


Run the following command to configure productpage-v1 service.


Open your browser, type http: // $ IP: 10501 / productpage, you can see the following results, namely bookinfo application publishing success. Refresh the page, you can see the changes in review scores.


To test the dynamic update configuration data plane, as the local port updates bookinfo / reviews and services, and executed.


View the corresponding data plane services log, you can see the new configuration updates to take effect. But the problem here is that productpage instance itself is still accessible port 10504 before, but this time could not happen Sidecar forward the port will lead to abnormal service itself. On the whole, in the Universal mode Kuma’s a good practice to plan well in advance of applications, services, instances, such as the port, upgrade update may cause a brief interruption in service.



to sum up


Kuma advantage

  1. Lightweight, light-weight, light-weight, important things to say three times, several executable program will be able to deploy the service grid infrastructure are areas;

  2. By supporting multiple Mesh obvious way to provide better isolation.


Unresolved Issues


  1. Important features not supported TrafficRoute, TrafficTracing the like, so basically Kuma still unavailable state.


  2. Two-way authentication supports only the built-in self-signed certificates, and can only be configured in Mesh range.


  3. Because they do not support similar Istio of Ingress, Egress and other functions, when open two-way authentication can not be released out of service, internal services can not access external services.


  4. To support multiple simultaneous start in Universal mode Envoy, Envoy does not support hot restart. However, due to the heat xDS configurations are updated, so the impact is not significant.


  5. In Universal mode, it does not support the service registration and discovery, the user needs to configure outbound entry-by-service application-dependent, but also because there is no integrated DNS, you need to specify inter-service access to IP: Port, rather than as designated Service Name can be like Istio . In Kubernetes mode, is dependent on the mechanism of Service, or the Hostname Service Name may be resolved to ClusterIP, then initiate a HTTP / TCP requests into Sidecar later re-forwarded.


  6. Service started the process as much as possible not to rely on access to services, this case may be due to the Sidecar and the data plane is not configured, leading to service failed to start.


  7. View Envoy’s config_dump can see that the current mode is managed in a TCP connection, did not play a strong ability of Envoy.


  8. Under Universal mode configuration data plane objects, start Sidecar services, etc. are need to be manually command the operation, more convenient and user-friendly packaging is also a must.


After this test, we can see that Kuma is currently still in the initial phase of the project, but overall technical direction is good. It is not Istio suddenly on a large and functional, the learning curve is relatively flat, so that everyone can give a good understanding of grid services bring the convenience, and the technical difficulties which exist.


One of the reasons hindering the current grid technology application service is the support for legacy systems. In general, we need to reform the old system twice, the first time a container, thus enabling it to run on Kubernetes, the second is the dismantling of RPC frames or completely replaced.


If the service can support non-mesh containers scene, then at least work can be reduced by half. We know from the start Istio v1.3 version began to support the expansion of the grid, it is also about to bare metal or virtual machine to deploy Host Integration in Kubernetes in Isito cluster. Currently supports two modes, one is single-mode network, i.e., bare metal or a virtual machine host connected to the inner or the VPC via VPN Kubernetes, another communication is implemented by the ingress gateway integrated multi-network. For now, due to the dependence on Kubernetes Istio itself is relatively heavy, coupled with other functions Istio itself have been relatively complete, in order to increase the mesh extended functionality, the workload is relatively large, so it both ways still under development.


Relatively speaking, Kuma offers a new idea to use the service grid in a virtual machine host or bare metal scene, although the completion of the current function is relatively low, but still worthy of sustained attention.


Leave a Reply