Configuring Cloud Service Mesh with Istio API
1. Configuring Cloud Service Mesh with Istio API
In this section, you learn to configure Cloud Service Mesh with Istio API resources. Cloud Service Mesh is configured in YAML files called Kubernetes Custom Resource Definitions-- CRDs. The CSM control plane component reads the CRDs and shares them with the envoy proxies via the Envoy xDS API. The Envoy xDS API is a set of protocols used by Envoy proxies or proxyless gRPC to dynamically fetch configurations from the control plane. Let's explore the Istio API resources and their CRDs. There are five primary Istio CRDs-- VirtualService, DestinationRule, Gateway, ServiceEntry, and Sidecar. This diagram displays where each of these API resources fits into the traffic management architecture. You can think of VirtualService as the where and DestinationRule as the how. VirtualService defines how requests for service are routed within an Istio service mesh, can use routing rules to determine the destination of a request, can use rules to route traffic based on elements like request headers, target hostname, and URL path, and can use target destinations as a service in the mesh registry using proxies-- a subset of the service, specific group of pods using labels to select, or a non-proxied service registered via a service entry. DestinationRule defines how traffic aimed at a particular destination gets handled, can break the single service into multiple subsets-- subcollections of pods using labels to select-- the VirtualService can then route to the subset; can specify load-balancing behavior within the destination, and can specify TLS security mode, circuit-breaker settings, and other service-level properties. A request coming from a client will be routed using both the VirtualService settings to pick a destination and DestinationRule settings to select how to connect to that destination. Next, let's define gateways. There are two types of gateways, which are used to manage inbound and outbound traffic for the mesh-- ingress gateways for managing incoming traffic and egress gateways for managing outgoing traffic. Gateway configuration settings are applied to a deployment on Envoy proxy pods running on the edge of the mesh, not as sidecars to particular workloads. The next API resource is the ServiceEntry, which is commonly used to enable requests to services outside of in Cloud Service Mesh. ServiceEntry is useful for accessing external APIs or integrating with legacy services that are not part of the mesh. Finally, sidecars are used to fine-tune Envoy proxy settings. By default, sidecar proxies are configured to accept traffic on all ports used by a workload and can reach every workload in the mesh. You can use sidecar configurations to limit protocols, ports, or accessible services in the mesh. Two other common API resources are WorkloadEntry and WorkloadGroup. WorkloadEntry configurations are used to onboard non-Kubernetes workloads. Examples of non-Kubernetes workloads include virtual machines and bare-metal servers. A WorkloadEntry uses a service entry to select workloads and provide the service definition. WorkloadGroup describes the collection of workload instances. WorkloadGroup is designed for non-Kubernetes workloads, replicating the sidecar injection and deployment model used in Kubernetes to bootstrap Istio proxies.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.