Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

What are the nine open source service grids of kubernetes

2025-03-29 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Servers >

Share

Shulou(Shulou.com)05/31 Report--

This article introduces the knowledge of "what are the nine open source service grids of Kubernetes?". In the operation of actual cases, many people will encounter this dilemma. Next, let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

What is a service grid?

Service grid has a high degree of topic in recent years, what is the reason behind it?

Micro-service has become a flexible and rapid way of development. However, as the number of microservices grows exponentially, the development team begins to encounter deployment and scalability problems.

Container orchestration systems such as containers and Kubernetes package the runtime and services into an image, schedule the container to the appropriate node, and run the container. This solution can solve many problems encountered by the development team. However, there is still a deficiency in this operational process: how to manage communication between services.

In the scenario of service grid, the unified network communication capability between applications is enhanced in a way that is decoupled from the application code. The service grid expands the management ability of the cluster, and enhances the functions of observability, service discovery, load balancing, IT operation and maintenance monitoring and application fault recovery.

Overview of Service Grid

The service grid has always been very hot. As William Morgan, author of Linkerd, mentioned: "Service grids are essentially nothing more than user space agents bundled with applications." This statement is quite concise, he added, "if you can see the essence through the noise, the service grid can bring you real value."

Envoy is the core component of many service grid frameworks and is a general open source proxy that is often used in sidecar within Pod to intercept traffic. There are also service grids that use other proxy schemes.

In terms of the popularity of specific service grid solutions, Istio and Linkerd have gained more recognition. There are other options, including Consul Connect,Kuma,AWS App Mesh and OpenShift. The key features provided by the nine service grids are described below.

Istio

Istio is an extensible open source service grid based on Envoy. It allows development teams to connect, encrypt, control, and observe application services. Istio was open source in 2017, and IBM, Google and Lyft are still maintaining and upgrading it. Lyft donated Envoy to CNCF in 2017.

Istio spent a lot of time perfecting and enhancing its features. The key features of Istio include load balancing, traffic routing, policy creation, measurability and inter-service authentication.

Istio consists of two parts: the data plane and the control plane. The data plane handles traffic management and implements traffic routing and inter-service invocation through Envoy's sidecar proxy. The control plane is mainly used by developers to configure routing rules and observation indicators.

Istio observation metrics are fine-grained attributes that contain specific data values related to service behavior. Here is an example:

Request.path: xyz/abc request.size: 234 request.time: 12:34:56.789 04/17/2017 source.ip: [192 168 01] destination.service.name: example

Compared with other service grids, Istio is better at its platform maturity and through its Dashbaord

Focusing on service behavior observation and business management functions, however, because of these advanced features and complex configuration processes, Istio may not be as easy to use as some other alternatives.

Linkerd

According to the official website, Linkerd is a lightweight, security-first Kubernetes service grid. Its creation process is incredibly fast (it is said that it takes only 60 seconds to install on Kubernetes), which is loved by most developers. Linkerd does not adopt an Envoy-based build scheme. Instead, a high-performance Rust-based proxy, linkerd2-proxy, is written specifically for the Linkerd service grid.

Linkerd is community-driven and is a 100% Apache licensed open source project. It's also a CNCF incubation program. Linkerd started in 2016, and maintainers have spent a lot of time fixing their flaws.

Using Linkerd service grid, application services can enhance their reliability, observability and security of deployment on Kubernetes. For example, enhanced observability can help users solve the problem of latency between services. Using Linkerd does not require users to make a lot of code adjustments or spend a lot of time writing YAML configuration files. Reliable product features and positive developer feedback make Linkerd a strong competitor in the service grid.

Consul Connect

Consul Connect is a service grid from HashiCorp, which focuses on routing and segmentation, and provides network characteristics between services through application-level sidecar agents. Consult Connect focuses on application security, providing two-way TLS connections between applications for authorization and encryption.

What makes Consult Connect unique is that it provides two proxy modes. One is its built-in agent, and it also supports the Envoy scheme. Connect emphasizes observability and integrates tools such as Prometheus to monitor data from sidecar agents. Consul Connect can flexibly meet the needs of developers. For example, it provides a variety of ways to register: from the orchestration system, through configuration files, through API calls, or from command-line tools.

Kuma

Kuma comes from Kong and claims to be an easy-to-use alternative to service grid. Kuma is a platform-independent control plane based on Envoy. Kuma not only provides network features such as security, observation and routing, but also enhances the connectivity between services. Kuma supports both Kubernetes and virtual machines.

What is interesting about Kuma is that its Enterprise Edition can operate and manage multiple isolated service grids through a unified control panel. This capability can meet the security requirements of the use of scenarios. It not only meets the requirements of isolation, but also realizes centralized control.

Kuma is also a relatively easy solution to install. Because it has a lot of strategies built in in advance. These policies cover common requirements, such as routing, bi-directional TLS, fault injection, flow control, encryption and so on.

Kuma is natively compatible with Kong, and Kuma is a very natural candidate for enterprise organizations that have adopted Kong API management.

Maesh

Maesh is a container native service grid from Containous, touting itself as a lighter and easier-to-use solution than other service grids in the market. Unlike many service grids built on Envoy, Maesh uses Traefik, an open source reverse proxy and load balancer.

Instead of using sidecar as a proxy, Maesh deploys a proxy terminal on each node. The advantage of this is that there is no need to edit Kubernetes objects, while allowing users to selectively modify traffic, Maesh is less intrusive than other service grids. Configuration supported by Maesh: add annotations to user service objects or add annotations to service grid objects to achieve configuration.

In fact, SMI is a new service grid specification format, a unique highlight of Maesh support for SMI. As SMI is gradually adopted in the industry, it can improve scalability and ease vendor binding concerns.

Maesh requires Kubernetes version 1.11 or later, and CoreDNS/KubeDNS is installed in the cluster. This installation guide demonstrates how to quickly install Maesh through Helm v3.

Helm repo add maesh https://containous.github.io/maesh/charts helm repo update helm install maesh maesh/maesh

ServiceComb-mesher

The Apache Software Foundation describes its ServiceComb-mesher as "a high-performance service grid implemented in the Go language". Mesher is designed and implemented based on Go Chassis, a very popular Go language micro-service development framework. Therefore, it follows some of the features of Go Chassis, such as service discovery, load balancing, error tolerance, route management and distributed tracking.

Mesher uses the sidecar approach; each service has a Mesher sidecar proxy. Developers interact with Mesher through Admin API to view runtime information. Mesher supports both HTTP and gRPC and can be quickly ported to different infrastructure environments, including Docker, Kubernetes, virtual machines, and bare metal machine environments.

Network Service Mesh (NSM)

Network Service Mesh (NSM) is a service grid specially designed for telcos and ISPs. It provides a layer to enhance the low-level network capabilities of services in Kubernetes. NSM is currently CNCF's sandbox project.

According to NSM's documentation, "network operators who often come into contact with the L2/L3 layer complain that there are few container network solutions suitable for their next-generation architecture."

Therefore, NSM is designed to take into account some different usage scenarios, especially those with different network protocols and mixed network configurations. This makes NSM attractive to some special scenarios, such as edge computing, 5G networks, and IOT devices. NSM uses a simple and straightforward API interface to communicate between the container and the external endpoint.

NSM works at a different network layer than other service grids. VMware describes NSM as "focused on connectivity". GitHub's documentation demonstrates how NSM works with Envoy.

AWS App Mesh

AWS APP Mesh provides developers with a "network for the application layer of different services". It takes over all the network traffic of the service and uses the open source Envoy proxy to control the flow of traffic into and out of the container. AWS App Mesh supports HTTP/2 gRPC.

AWS App Mesh can be a good service grid solution for companies that have deeply bound the container platform to AWS. AWS platforms including AWS Fargate,Amazon Elastic Container Service,Amazon Elastic Kubernetes Service (EKS), Amazon Elastic Compute Cloud (EC2), Kubernetes on EC2, including AWS App Mesh are free of charge.

The monitoring tools within the AWS App Mesh and AWS ecology are seamlessly compatible. These tools include CloudWatch and AWS X-Ray, as well as some tools from third-party vendors. Because the AWS computing service supports AWS Outposts,AWS App Mesh, it is well compatible with hybrid clouds and deployed applications.

The disadvantage of AWS App Mesh may be that developers are deeply bound to a single vendor solution, relatively closed source, and lack of scalability.

OpenShift Service Mesh by Red Hat

OpenShift is a container management platform from Red Hat that helps users "connect, manage and observe microservice applications". OpenShift comes with a number of pre-installed components to enhance enterprise capabilities, and is also described as an enterprise-class hybrid cloud Kubernetes platform.

OpenShift Service Mesh is built on open source Istio and has the control plane and data plane features of Isito. OpenShift uses two open source tools to enhance the traceability and observability of Isito. OpenShift uses Jaeger for distributed tracking to better track how requests are invoked between services.

On the other hand, OpenShift uses Kiali to enhance the observability of micro-service configuration, traffic monitoring, tracking analysis, and so on.

How to choose

As mentioned in this article, there are many service grid solutions to choose from, and new ones are emerging at the same time. Of course, each solution is slightly different in terms of technical implementation. The main considerations for choosing an appropriate service grid include how intrusive you can accept it, how secure it is, and the maturity of the platform.

The following points can help the DevOps team choose a service grid that suits their scenario:

Whether to rely on Envoy. Envoy has an active community ecology. Open source is also the base of many service grids. The rich features of Envoy make it a difficult factor to bypass.

Specific usage scenarios. Service grid is created for micro-services. If your application is a monolithic behemoth, your investment in the service grid may not achieve the expected return. If not all applications are deployed in Kubernetes, platform-independent solutions should be given priority.

Existing container management platform. Some companies have used vendor-specific ecology to solve container orchestration problems, such as AWS's EKS and Red Hat's OpenShift,Consul. Following the original ecology, we can inherit and expand the original characteristics. And these may not be provided by open source solutions.

In the industry. Many service grids are not specifically designed for specific industries. Kuma's ability to uniformly manage multiple isolated service grids may be more suitable for highly regulated financial industries. The underlying network telcos and ISPs should consider Network Service Mesh more.

The need for visualization. Observability is one of the core competencies of service grid. Teams considering further customization and deeper capabilities should give priority to Istio or Consul.

Whether to follow the development standards. Following development standards makes your platform more forward-looking and scalable. This makes companies tend to adopt solutions that support SMI, Maesh or other projects incubated by foundations such as Linkerd.

Whether to attach importance to user experience. Considering the ease of use of operation and maintenance personnel is the key index to judge the new tool. This side of Linkerd seems to have a good reputation among developers.

Team ready. Evaluate the resources and technology reserves your team has, and decide that you are suitable for using Envoy-based Istio or vendor abstractly encapsulated solutions, such as OpenShift.

These considerations do not cover all scenarios. This is just throwing a brick to attract jade and arousing the thinking of readers. It is hoped that after reading the list of service grids listed above and the relevant decision factors, your team will find new ways to improve the network characteristics of micro-service applications.

This is the end of the content of "what are the nine open source service grids of Kubernetes". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Servers

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report