By Dan Meyer
Translator: Luo Guangming
Proofread: Ma Ruofei
In English the original address: www.sdxcentral.com/articles/ne…
Reprinted from: www.servicemesher.com/blog/kong-o…
Editor’s note
On September 10, 2019, Kong officially announced open source Service Mesh: Kuma. This news, immediately in the cloud yuan community caused repercussions, the major media report. Let’s follow up with the editor in chief of SDxCentral to see what Kong’s CTO has to say about Kuma’s Service Mesh product and his thoughts on SMI. For details on Kuma’s features, see the blog and Github.
Github’s description of Kuma’s features is as follows:
- Universal control plane: easy to use, distributed, can run on any platform.
- Lightweight data plane: Envoy – based, capable of handling any type of traffic.
- Automation: Deployment on THE K8s platform requires no code changes and can be flexibly deployed on virtual machines.
- Multi-tenant: Multiple service grids can be deployed in a cluster and on the same control plane.
- Network security: automatic mTLS encryption.
- Traffic segmentation: Flexible ACL rules.
- Traffic tracking: Automatic integration with Zipkin and Jaeger.
- Traffic metrics: Automatic integration with Prometheus/Splunk/ELK.
- Proxy configuration template: Facilitates advanced (charged) user configuration Envoy.
- Tag selector: Geodesic, cloud-specific, and team-oriented strategies can be applied.
- Platform neutral: supports K8s, virtual machines and bare – metal machines.
- Powerful APIM Ingress: Integration with Kong Gateway.
Introduction to the
Kong is building its service grid platform Kuma into an increasingly complex ecosystem, with a number of new entrants and options emerging in the past few months.
The company claims Kuma is “a universal service grid”. This means that Kuma, unlike most service grid projects on the market, is designed to work both inside and outside the Kubernetes ecosystem, Kong CTO and co-founder Marco Palladino explain, This includes virtual machines (VMs), containers, legacy environments, and Kubernetes.
Kuma includes a generic control plane based on the Envoy service proxy. It combines the data plane with the advanced control plane, allowing users to set permissions, obtain indicators, and set routing rules using local custom Resource Definitions (CRDs) or RESTful apis. Palladino explained that most of the early first-generation service grid products lacked a mature control plane and required extensive secondary development or manual customization.
“We want 90% of our use cases to be easy to use and scalable quickly,” he explains. For the other 10 per cent of use cases, we have a policy that allows users to go deep, “he says, adding that while Kuma is designed for ease of use,” Kuma is designed for businesses, not amateurs.”
Kuma’s features include software-defined Security, which supports mTLS authentication for all four layer traffic; The ability to trace and log records to better analyze indicators; Provides flow control capabilities such as circuit breakers and health checks to enhance layer 4 routing.
Palladino says Kuma’s ability to secure the underlying network provides reliability and a deeper level of observability without any code changes.
“We tried to build a very smooth and gradual learning curve for Kuma,” Palladino said. Its complexity won’t overwhelm developers early on, and it won’t stop developers from going further. We do provide a policy for power users to configure the underlying proxy data plane.”
Kuma also leverages Kong’s namesake open source API gateway. The gateway manages the flow of information between organizations and various methods for deploying modern microservices.
Kuma joins the service grid race
Kuma joins a growing service grid race that claims to make it easier to support microservice deployments.
“Everyone tells us they want to use a service grid, but there is no service grid that is easy to use and really suitable for an enterprise production environment,” Palladino said. A lot of companies are focused on Kubernetes, but for them, this becomes the end of the cloud native exploration journey. We provide a product that allows them to have a service grid that they can implement earlier and support their migration.”
One service grid platform that has attracted a lot of attention is Istio. It is positioned at the network layer, using the bottom layer for microservice development and maintenance. This allows administrative operations to be separated from application development.
Palladino said Istio helped light up the sky, but it’s still “very complex, with a lot of active parts.” It works well on Kubernetes, but not everyone is running Kubernetes.”
This focus will also influence the choice of other service grids such as Linkerd and Containous, such as the recently launched Maesh platform, he said.
“Maesh, Linkerd and other control plane grids are highly focused on Kubernetes,” Palladino explains. “Kubernetes will only be adopted if companies adopt them. We made the transition to Kubernetes by establishing security and observability early in the process.”
Efforts are also needed to coordinate interoperability between service grid platforms. One is led by Microsoft, which pioneered the SERVICE Grid interface (SMI) specification earlier this year. Its goal is to provide developers with interoperability between different service grid technologies running on Kubernetes.
Palladino downplays this effort as marginalizing service grid functionality.
“We don’t believe in SMI at all,” he says. “This is another attempt to standardize the interface and make it mediocre rather than good. It takes the common denominator of a community-wide grid of services, thereby reducing their value to the end user. It’s broad, but it’s not deep.”
Palladino believes Kuma is truly interoperable across all platforms.
Kong was founded in 2009 under the name Mashape. It released the Kong platform to the open source community in 2015 and officially launched the platform name for all of its business products last year. The company has raised $69.1 million in five rounds of funding, most recently a $43 million Series C round in March.
Editor’s note
When Istio is weak because of its performance, one new player after another comes along, bringing competition and variety to the market, which is what users like to see. Kong’s involvement in Consul Service Mesh is no surprise. In addition to traditional cloud vendors and open source Service Mesh products on the market, Consul Service Mesh is also a welcome addition. The vendors behind Consul Service Mesh and Kuma are backed by proven open source products: Consul’s Service discovery and registration product and Kong’s gateway product. They each have a strong presence in the open source community, and there will be a strong following for service grid products.
It’s unclear how well Kuma performs compared to Istio and other service grid products, but its platform-neutral approach is worth learning from. At a time when K8s is not fully available and many companies are deploying their products on virtual machines or bare-metal machines, Kuma is a pleasant surprise if you want to try service grid technology.
The ServiceMesher community was launched in April 2018 by a group of volunteers who share the same values and ideals.
Community focus areas: container, microservice, Service Mesh, Serverless, embrace open source and cloud native, dedicated to promoting the vigorous development of Service Mesh in China.
The ServiceMesher community website is www.servicemesher.com