This chapter is from the book
This chapter is from the book
This chapter is from the book
Service Mesh
As we become more accustomed to microservice-based architectures and distributed applications, we start seeing applications as consisting of services that communicate with each other and forming a network of services that implement the application. This design paradigm of creating a network of services affords us a lot of advantages in flexibility, development velocity, and resiliency. However, as applications evolve, the network of microservices grows and the complexity of managing the entire application also increases. The task of ensuring reliable and secure service-to-service communication and implementing observability can have a significant impact on the development of the services. Building these features directly into the services makes them more brittle, impedes their capability to change, and slows the development of features because the application code now needs to take on additional responsibilities. In a cloud native environment, a service mesh is a tool that can be used to add cross-cutting functionality, such as security or observability, to a set of microservices.
A service mesh operates by inserting proxies between services into the network of microservices. These network proxies are typically deployed as a set of sidecar containers, or containers that are deployed alongside microservice containers. They handle the service-to-service communication between the microservices and can transparently implement security, observability, and patterns for resiliency.
Oracle Cloud Infrastructure Service Mesh is a fully managed service mesh implementation that provides security, observability, and traffic management to cloud native applications without any application changes or dependencies. OCI Service Mesh creates proxies that are containers deployed alongside your applications, in the same Kubernetes cluster. The proxies handle traffic to the application and provide telemetry, security, and load balancing across pods. The proxies communicate with each other and are aware of policies that govern communications so that they allow only permissible communications between services. Figure 3-7 shows how the proxies deployed as sidecars to microservice containers communicate with the managed components of the service mesh to provide features such as telemetry and security.
)
FIGURE 3-7 OCI Service Mesh Is Based on Proxies That Are Injected as Sidecar Containers to Your Pods
The service mesh has managed components that include an IngressGateway, VirtualServices, and VirtualDeployments, along with policy management to support customized and secure traffic routing. These are mapped to an application’s services and provide abstractions for those services. When using the OCI service mesh, the applications services are mapped to virtual services and virtual deployments and associated policies. These virtual services are then bound to the existing services using binding objects. The applications are exposed using the IngressGateway, which routes traffic to the various VirtualServices. VirtualServices are in turn bound to Kubernetes services that the application exposes. A virtual service represents a customer-managed microservice in the mesh. Each virtual service has its own configuration for the service hostname, Transport Layer Security (TLS) certificates (for both client and server), and Certificate Authority (CA) bundles. A virtual deployment represents a version of a virtual service; each virtual service has up to five virtual deployments. Route tables are a virtual service feature that routes ingress traffic to specific versions of the virtual service. A virtual deployment binding associates the pods in an application cluster with a virtual deployment in your mesh. The virtual deployment binding resource allows service mesh to discover pods, backing the virtual deployment for service discovery.
The service mesh components and custom resources are installed on a Kubernetes cluster using the OCI Service Operator for Kubernetes (OSOK). OSOK is a collection of operators for OCI services that includes the operator for the service mesh. This operator provides the CRDs, roles, and other resources required to allow users to perform actions on the OCI service mesh using the Kubernetes API. With the operator installed, users can interact with the service mesh using standard tools such as kubectl.
When using the service mesh with the operator, users can apply annotations at the namespace level to enable sidecar injection for all pods in the namespace. The effect of these namespace-level annotations can be overridden at a pod level by specifying the sidecar injection on a per-pod basis.