Service Mesh Demo with Istio & SockShop

A modern cloud-native application is built up of many micro-service written in multiple languages where multiple services talk to each other forming a mesh. This network of micro-services has common concerns like service Discovery, traffic routing, canary deployments, metrics and monitoring, failure recovery, etc. Instead of embedding these concerns into applications and duplicating the same logic across potentially multiple languages, it makes sense to take care of this functionality at the network level. Service mesh such as Istio tries to solve this common problem centrally so that developers focus on developing their applications and rely on Istio for the above features. One of the main design goals of Istio is to have complete transparency so that minimum rework is required from the application side to integrate it with Istio. Istio can automatically inject itself between all network paths between services and mediate/control the traffic.

#kubernetes #istio #devops

What is GEEK

Buddha Community

From Service Mess to Service Mesh

Introduction

Over the last 10 years, the rapid adoption of microservices architecture has resulted in enterprises with hundreds or (sometimes even thousands) of services. With the growth of containerization technologies like Docker and Kubernetes, microservice patterns have seen the strongest growth; resulting in a complex dependency matrix between these micro-services. For teams to monitor, support, and to maintain these services is becoming a challenge so most enterprises have invested in some kind of microservices management tool.

This article will explore some of the common aspects of microservice management. Then we’ll take a closer look at the centralized gateway pattern, as well as its limitations (most enterprises have started with or currently still use this pattern). Then we will look into a new pattern called “Service Mesh” which has gained a lot of attention in the last 3–4 years. Often this pattern is also referred to as the “Side Car Proxy”. So lets get started!

Micro-Services Management

As enterprises start building more and more microservices, it’s becoming clear that some of the aspects of microservices are common across all microservices. So it makes sense to provide a common platform for managing these common aspects. Below are some of the key common aspects:

Service Registration and Discovery: A commonplace to register, document, search and discover microservices

Service Version Management: Ability to run multiple versions of a microservice.

**Authentication and Authorization: **Handle authentication and authorization including Mutual TLS (MTLS) between services.

Service Observability: Ability to monitor end to end traffic between services, response times, and quickly identify failures and bottlenecks.

**Rate Limiting: **Define threshold limits that traffic services can handle.

Circuit Breaker: Ability to configure and introduce a circuit breaker in case of failure scenarios (to avoid flooding downstream services with requests).

**Retry Logic: **Ability to configure and introduce retry logic dynamically in services.

So it’s a good idea to build these concerns as part of a common framework or service management tool. As a result, micro-service development teams don’t have to build these aspects in the service itself.

#service-mesh #istio-service-mesh #microservices #gateway-service #envoy-proxy

Open Service Mesh — Microsoft’s SMI based Open Source Service Mesh Implementation

Microsoft’s Open Service Mesh is an SMI-compliant, lightweight service mesh being run as an open source project. Backed by service-mesh partners including HashiCorp, Solo.io, and Buoyant, Microsoft introduced the Service Mesh Interface last year with the goal of helping end users and software vendors work with the myriad choices presented by service mesh technology by providing a set of specification standards. OSM can be considered as a reference implementation of SMI, one that builds on existing service mesh components and concepts.

Open Service Mesh data plane is architecturally based on the Envoy proxy and implements the go-control-plane xDS v3 API. However, despite the fact that Envoy comes with OSM by default, using standard interfaces allows it to be integrated with other reverse proxies (compatible with xDS).

SMI follows in the footsteps of existing Kubernetes resources, like Ingress and Network Policy, which also do not provide an implementation where required interfaces to interact with Kubernetes are facilitated for providers to plug their products. The SMI specification instead defines a set of common APIs that allow mesh providers to deliver their own implementations. This means mesh providers can either use SMI APIs directly or build operators to translate SMI to native APIs.

SMI Implementation

With OSM, users can use SMI and Envoy on Kubernetes and get a simplified service-mesh implementation. The SMI ecosystem already has multiple providers like Istio, Linkerd, Consul Connect, now Open Service Mesh etc. some of them have implemented SMI compatibility using adaptors (Istio, Consul Connect) and others (OSM, Linkerd etc.) consume the SMI APIs directly.

OSM implementation is very similar to Linkerd which also directly consumes SMI APIs without any need for an adaptor like Istio, but one key difference is that OSM uses Envoy for its proxy and communication bus, whereas Linkerd uses linkerd2-proxy (rust based — lighter than Envoy).

Architecture & Components

OSM control plane comprise four core components. All these four components are implemented as a single controller entity (Kubernetes pod/deployment), this is much lighter in weight when compared with older versions of Istio where there are 4 control plane components (Istio-1.6 introduced istiod which unifies all the control plane components into one binary).

OSM Architecture — Components

OSM Data Plane — Uses Envoy as reverse-proxy by default — similar to most other Service Mesh providers (Linkerd is unique in this case which uses ultralight transparent proxy written in Rust). While by default OSM ships with Envoy, the design utilizes interfaces (An interface type in Go is kind of definition. It defines and describes the exact methods that some other type must have), which enable integrations with any xDS compatible reverse-proxy. The dynamic configuration of all the proxies is handled by OSM controller using Envoy xDS go-control-plane.

#service-mesh #istio-service-mesh #kubernetes #azure #microsoft

Service Mesh Demo with Istio & SockShop

A modern cloud-native application is built up of many micro-service written in multiple languages where multiple services talk to each other forming a mesh. This network of micro-services has common concerns like service Discovery, traffic routing, canary deployments, metrics and monitoring, failure recovery, etc. Instead of embedding these concerns into applications and duplicating the same logic across potentially multiple languages, it makes sense to take care of this functionality at the network level. Service mesh such as Istio tries to solve this common problem centrally so that developers focus on developing their applications and rely on Istio for the above features. One of the main design goals of Istio is to have complete transparency so that minimum rework is required from the application side to integrate it with Istio. Istio can automatically inject itself between all network paths between services and mediate/control the traffic.

#cloudnative #istio #sockshop #servicemesh

Deploying Citrix ADC with Service Mesh on Rancher

Introduction

As a network of microservices changes and grows, the interactions between them can be difficult to manage and understand. That’s why it’s handy to have a service mesh as a separate infrastructure layer. A service mesh is an approach to solving microservices at scale. It handles routing and terminating traffic, monitoring and tracing, service delivery and routing, load balancing, circuit breaking and mutual authentication. A service mesh takes these components and makes them part of the underlying infrastructure layer, eliminating the need for developers to write specific code to enable these capabilities.

Istio is a popular open-source service mesh that is built into the Rancher Kubernetes management platform. This integration allows developers to focus on their business logic and leave the rest to Kubernetes and Istio.

Citrix ADC is a comprehensive application delivery and load balancing solution for monolithic and microservices-based applications. Its advanced traffic management capabilities enhance application performance and provide comprehensive security. Citrix ADC integrates with Istio as an ingress gateway to the service mesh environment and as a sidecar proxy to control inter-microservice communication. This integration allows you to tightly secure and optimize traffic into and within your microservice-based application environment. Citrix ADC’s Ingress deployment is configured as a load balancer for your Kubernetes services. As a sidecar proxy, Citrix ADC handles service-to-service communication and makes this communication reliable, secure, observable, and manageable.

#service mesh #rancher #istio service mesh #microservices and containers

Kubecon 2020: Istio Simplified

Shift to monolith control plane

Google has been working on making Istio simpler to install, upgrade, administer and use.

Istio was built using microservices principles where it was divided into various components based on the functionality they provided. The diagram below shows various components of 1.4 version.

Istio 1.4

This component division was made with the assumption that separate teams would deploy and administer each of the components. However, in reality, there is usually one team/person maintaining and administering Istio and they don’t make use of the flexibility provided by individual components. They just want to deploy, maintain and upgrade Istio. This is one of the example scenarios where microservices architecture may not be beneficial based on client usage.

So, in order to remove this over pivoted design that tries to accommodate one potential solution and make it simple for the primary user a shift to monolith architecture has been made:

1. Mixer’s capabilities have been moved to envoy sidecar and gateways. This was done for performance and efficiency
2. Galley’s functionality moved to Pilot
3. Injector did not receive much of traffic and hence it was also merged into Pilot
4. Node agent’s functionality flattened into Pilot Agent. Now pilot agent at startup it generates a private key by negotiating with Citadel and provides it to the sidecar
5. Citadel is Istio’s builtin certificate authority. Customers prefer to run their own or third-party CA infrastructure and they want to use that for security reasons. Hence, Citadel was also merged into Pilot. Pilot still provides the API’s to provide Citadel’s functionality

#kubecon #kubernetes #istio #istio-service-tutorial #service-mesh