add service mesh

content/sre/service-mesh/01-introduction.md

@@ -0,0 +1,82 @@
+## What is Service Mesh and why we need it?
+
+The term service mesh is used to describe the network of microservices that make up such applications and the interactions between them. As a service mesh grows in size and complexity, it can become harder to understand and manage. Its requirements can include discovery, load balancing, failure recovery, metrics, and monitoring. A service mesh also often has more complex operational requirements, like A/B testing, canary releases, rate limiting, access control, and end-to-end authentication.
+
+Red Hat Service Mesh, based on the open source Istio project, provides behavioral insights and operational control over the service mesh as a whole, offering a complete solution to satisfy the diverse requirements of microservice applications. It provides a number of key capabilities uniformly across a network of services:
+
+- **Traffic Management** Control the flow of traffic and API calls between services, make calls more reliable, and make the network more robust in the face of adverse conditions.
+- **Observability** Gain understanding of the dependencies between services and the nature and flow of traffic between them, providing the ability to quickly identify issues.
+- **Policy Enforcement** Apply organizational policy to the interaction between services, ensure access policies are enforced and resources are fairly distributed among consumers. Policy changes are made by configuring the mesh, not by changing application code.
+- **Service Identity and Security** Provide services in the mesh with a verifiable identity and provide the ability to protect service traffic as it flows over networks of varying degrees of trustability.
+
+In addition to these behaviors, Istio is designed for extensibility to meet diverse deployment needs:
+
+- **Platform Support** Istio is designed to run in a variety of environments including ones that span Cloud, on-premise, Kubernetes, Mesos etc. We’re initially focused on Kubernetes but are working to support other environments soon.
+- **Integration and Customization** The policy enforcement component can be extended and customized to integrate with existing solutions for ACLs, logging, monitoring, quotas, auditing and more.
+
+These capabilities greatly decrease the coupling between application code, the underlying platform, and policy. This decreased coupling not only makes services easier to implement, but also makes it simpler for operators to move application deployments between environments or to new policy schemes. Applications become inherently more portable as a result.
+
+## What is Traffic?
+
+Using Istio’s traffic management model essentially decouples traffic flow and infrastructure scaling, letting operators specify via Pilot what rules they want traffic to follow rather than which specific pods/VMs should receive traffic - Pilot and intelligent Envoy proxies look after the rest. So, for example, you can specify via Pilot that you want 5% of traffic for a particular service to go to a canary version irrespective of the size of the canary deployment, or send traffic to a particular version depending on the content of the request.
+
+## Service Mesh Details
+
+A service mesh is the network of microservices that make up applications in a distributed microservice architecture and the interactions between those microservices. When a Service Mesh grows in size and complexity, it can become harder to understand and manage.
+
+Based on the open source Istio project, Red Hat OpenShift Service Mesh adds a transparent layer on existing distributed applications without requiring any changes to the service code. You add Red Hat OpenShift Service Mesh support to services by deploying a special sidecar proxy to relevant services in the mesh that intercepts all network communication between microservices. You configure and manage the Service Mesh using the control plane features.
+
+Red Hat OpenShift Service Mesh gives you an easy way to create a network of deployed services that provide:
+
+- Discovery
+- Load balancing
+- Service-to-service authentication
+- Failure recovery
+- Metrics
+- Monitoring
+
+Red Hat OpenShift Service Mesh also provides more complex operational functions including:
+
+- A/B testing
+- Canary releases
+- Rate limiting
+- Access control
+- End-to-end authentication
+
+## Red Hat OpenShift Service Mesh Architecture
+
+Red Hat OpenShift Service Mesh is logically split into a data plane and a control plane:
+
+__ TODO: Add diagram __
+
+### Istio
+
+As mentioned, Istio drives the service mesh and the data plane used withn the mesh is a set of intelligent proxies deployed as sidecars. These proxies intercept and control all inbound and outbound network communication between microservices in the service mesh.
+
+Envoy proxy intercepts all inbound and outbound traffic for all services in the service mesh. Envoy is deployed as a sidecar to the relevant service in the same pod.
+
+The control plane manages and configures Istiod to enforce proxies to route traffic.
+
+Istiod provides service discovery, configuration and certificate management. It converts high-level routing rules to Envoy configurations and propagates them to the sidecars at runtime.
+
+Secret Discovery Service (SDS) distributes certificates and keys to sidecars directly from Istiod.
+
+Red Hat OpenShift Service Mesh also uses the istio-operator to manage the installation of the control plane. An Operator is a piece of software that enables you to implement and automate common activities in your OpenShift cluster. It acts as a controller, allowing you to set or change the desired state of objects in your cluster.
+
+### Kiali
+
+Kiali provides observability into the Service Mesh running on OpenShift Container Platform. Kiali helps you define, validate, and observe your Istio service mesh. It helps you to understand the structure of your service mesh by inferring the topology, and also provides information about the health of your service mesh.
+
+Kiali provides an interactive graph view of your namespace in real time that provides visibility into features like circuit breakers, request rates, latency, and even graphs of traffic flows. Kiali offers insights about components at different levels, from Applications to Services and Workloads, and can display the interactions with contextual information and charts on the selected graph node or edge. Kiali also provides the ability to validate your Istio configurations, such as gateways, destination rules, virtual services, mesh policies, and more. Kiali provides detailed metrics, and a basic Grafana integration is available for advanced queries. Distributed tracing is provided by integrating Jaeger into the Kiali console.
+
+Kiali is installed by default as part of the Red Hat OpenShift Service Mesh.
+
+### Jaeger
+
+Every time a user takes an action in an application, a request is executed by the architecture that may require dozens of different services to participate to produce a response. The path of this request is a distributed transaction. Jaeger lets you perform distributed tracing, which follows the path of a request through various microservices that make up an application.
+
+Distributed tracing is a technique that is used to tie the information about different units of work together—usually executed in different processes or hosts—to understand a whole chain of events in a distributed transaction. Distributed tracing lets developers visualize call flows in large service oriented architectures. It can be invaluable in understanding serialization, parallelism, and sources of latency.
+
+Jaeger records the execution of individual requests across the whole stack of microservices, and presents them as traces. A trace is a data/execution path through the system. An end-to-end trace is comprised of one or more spans.
+
+A span represents a logical unit of work in Jaeger that has an operation name, the start time of the operation, and the duration. Spans may be nested and ordered to model causal relationships.

content/sre/service-mesh/02-scenarios.md

@@ -0,0 +1,10 @@
+## Scenarios
+
+Few list of scenarios:
+
+1. **Advanced Route Rules:** Learn about Istio’s smart routing, access control, load balancing, and rate limiting.
+2. **Fault injection with Istio:** Understand failure scenarios of distributed computing by working through HTTP errors and network delays, applying chaos engineering to repair the environment.
+3. **Circuit Breaker with Istio:** Install Siege to stress test URLs, fail fast, and achieve the ultimate back-end resilience using retries, circuit breaker, and pool ejection.
+4. **Egress with Istio:** Use Egress routes to apply rules to how internal services interact with external APIs and services.
+5. **Observing Istio with Kiali:** Explore Kiali’s ability to give a big picture of the mesh and show the whole flow of requests and data.
+6. **Mutual TLS with Istio:** Create an Istio Gateway and VirtualService, then get a closer look at mutual TLS (mTLS) to learn its settings.