And hello again!.. In anticipation of the start of the course we have prepared another useful translation.
Service Mesh is a low-latency, configurable infrastructure layer that is needed to handle a large amount of network inter-process communications between application programming interfaces (APIs). Service Mesh provides fast, reliable, and secure communication between containerized and often ephemeral application infrastructure services. Service Mesh provides features such as service discovery, load balancing, encryption, transparency, traceability, authentication and authorization, and support for the auto shutdown pattern (circuit breakers).
Service Mesh is typically implemented by providing each service instance with a proxy instance called sidecar. side car handle communications between services, monitor and fix security issues, that is, everything that can be abstracted from individual services. Thus, developers can write, maintain, and maintain application code in services, and system administrators can work with the Service Mesh and run the application.
Istio, from Google, IBM, and Lyft, is currently the most well-known Service Mesh architecture. And Kubernetes, originally developed by Google, is now the only container orchestration framework supported by Istio. Vendors are trying to create commercially supported versions of Istio. I wonder what new they will be able to bring to the open source project.
However, Istio is not the only option, as other Service Mesh implementations are being developed. pattern sidecar proxy is the most popular implementation, as can be seen from projects by Buoyant, HashiCorp, Solo.io and others. There are also alternative architectures: the Netflix technology toolkit is one of the approaches where the Service Mesh functionality is implemented through the Ribbon, Hysterix, Eureka, Archaius libraries, as well as platforms such as Azure Service Fabric.
Service Mesh also has its own terminology for service components and functions:
- Container orchestration framework. As more and more containers are added to the application infrastructure, there is a need for a separate tool for monitoring and managing containers - a container orchestration framework. Kubernetes has taken this niche tightly, so much so that even its main competitors Docker Swarm and Mesosphere DC / OS offer integration with Kubernetes as an alternative.
- Services and Instances (Kubernetes Pods). An instance is a single running copy of a microservice. Sometimes one instance is one container. In Kubernetes, an instance consists of a small group of independent containers called a Pod. Clients rarely access an instance or pod directly, more often they access a service, which is a set of identical, scalable and fault-tolerant instances or pods (replicas).
- Sidecar Proxy. Sidecar Proxy works with a single instance or pod. The purpose of the Sidecar Proxy is to direct or proxy traffic coming from the container with which it works, and return traffic. Sidecar communicates with other Sidecar Proxies and is controlled by an orchestration framework. Many Service Mesh implementations use Sidecar Proxy to intercept and manage all traffic in and out of an instance or pod.
- Service discovery. When an instance needs to interact with another service, it needs to find (discover) a healthy and available instance of the other service. Typically, the instance performs DNS lookups. The container orchestration framework keeps a list of instances that are ready to receive queries and provides an interface for DNS queries.
- Load balancing. Most container orchestration frameworks provide load balancing at layer 4 (transport). Service Mesh implements more sophisticated layer 7 (application) load balancing, rich in algorithms and more efficient in terms of traffic management. The load balancing settings can be changed using the API, allowing you to orchestrate a blue-green or canary deployment.
- Encryption. Service Mesh can encrypt and decrypt requests and responses, removing this burden from services. Service Mesh can also improve performance by prioritizing or reusing existing persistent connections, which reduces the need for expensive computation to create new connections. The most common implementation of traffic encryption is mutual TLS (mTLS)where a public key infrastructure (PKI) generates and distributes certificates and keys for use by the Sidecar Proxy.
- Authentication and Authorization. Service Mesh can authorize and authenticate requests made from outside or inside the application, sending only validated requests to instances.
- Support auto power off pattern. Service Mesh supports , which isolates unhealthy instances and then gradually returns them to the pool of healthy instances as needed.
The part of the Service Mesh application that manages network traffic between instances is called data plane. Create and deploy a configuration that controls behavior data plane, is performed using a separate Control plane. Control plane usually includes or is designed to connect to an API, CLI, or GUI to control the application.
The Control Plane in the Service Mesh distributes the configuration between the Sidecar Proxy and the Data Plane.
Often, the Service Mesh architecture is used to solve complex operational problems using containers and microservices. Pioneers in the field are companies such as Lyft, Netflix and Twitter that provide stable services to millions of users around the world. (). For less demanding applications, simpler architectures are likely to suffice.
Service Mesh architecture is unlikely to ever be the answer to all questions related to the operation of applications and their delivery. Architects and developers have a huge arsenal of tools, and only one of them is a hammer, which, among many tasks, should solve only one thing - hammering nails. , for example, includes several different models that provide a continuum of approaches to problem solving using microservices.
The elements that come together in a Service Mesh architecture, such as NGINX, containers, Kubernetes, and microservices as an architectural approach, can be used just as productively in non-Service Mesh implementations. For example, Istio was designed as a complete Service Mesh architecture, but the modularity means that developers can choose and apply only the technology components they need. With this in mind, it's important to develop a solid understanding of the Service Mesh concept, even if you're not sure you'll ever be able to fully implement it in an application.
Source: habr.com