An Open-Source Platform to Connect, Manage, and Secure Microservices

Editor's Notes

• #12: Flannel allows inter-pod communication between different hosts by providing an overlay software-defined network (SDN). This solves the main issue we had the Docker networking model. As I said before, when using Docker, each container has an IP address that allows it to communicate with other containers on the same host. When pods are placed in different hosts, they rely on their host IP address. Therefore, communication between them is possible by port-mapping. This is fine at a container-level, but applications running inside these containers can have a hard time if they need to advertise their external IP and port to everyone else. Flannel helps by giving each host a different IP subnet range. The Docker daemon will then assign IPs from this range to containers. Then containers can talk to each user using these unique IP addresses by means of packet encapsulation. Imagine that you have two containers, Container A and Container B. Container A is placed on Host Machine A, and Container B is placed on Host Machine B. When Container A wants to talk to Container B, it will use container B’s IP address as the destination address of his packet. This packet will then be encapsulated with an outer UDP packet between Host Machine A and Host Machine B, which will be sent by Host Machine A, and that will have Host Machine B’s IP address as the destination address. Once the packet arrives to Host Machine B, the encapsulation is removed and the packet is routed to the container using the inner IP address. The flannel configuration regarding the container/Host Machine mapping is stored in etcd. The routing is done by a flannel daemon called flanneld.
• #13: Managing this runtime behavior is important because, while we have tools like Docker and Kubernetes to manage deployment and execution of service code, that’s not enough to make applications resilient and manageable. The way that microservices interact with each other at runtime—how traffic load flows through the system—needs to be monitored, managed, and controlled.
• #14: Managing this runtime behavior is important because, while we have tools like Docker and Kubernetes to manage deployment and execution of service code, that’s not enough to make applications resilient and manageable. The way that microservices interact with each other at runtime—how traffic load flows through the system—needs to be monitored, managed, and controlled.
• #15: Istio is described as: “an open platform to connect, manage, and secure microservices. Istio provides an easy way to create a network of deployed services with load balancing, service-to-service authentication, monitoring, and more, without requiring any changes in service code. You add Istio support to services by deploying a special sidecar proxy throughout your environment that intercepts all network communication between microservices, configured and managed using Istio’s control plane functionality”
• #16: Istio is described as: “an open platform to connect, manage, and secure microservices. Istio provides an easy way to create a network of deployed services with load balancing, service-to-service authentication, monitoring, and more, without requiring any changes in service code. You add Istio support to services by deploying a special sidecar proxy throughout your environment that intercepts all network communication between microservices, configured and managed using Istio’s control plane functionality”
• #26: Mixer is a highly modular and extensible component. One of it’s key functions is to abstract away the details of different policy and telemetry backend systems, allowing Envoy and Istio-based services to be agnostic of those backends, which keeps them portable. Mixer’s flexibility in dealing with different infrastructure backends is achieved by having a general-purpose plug-in model. Individual plug-ins are known as adapters and they allow Mixer to interface to different infrastructure backends that deliver core functionality, such as logging, monitoring, quotas, ACL checking, and more. Adapters enable Mixer to expose a single consistent API, independent of the backends in use. The exact set of adapters used at runtime is determined through configuration and can easily be extended to target new or custom infrastructure backends.
• #27: Traffic Management: The core component used for traffic management in Istio is Pilot, which manages and configures all the Envoy proxy instances deployed in a particular Istio service mesh. It lets you specify what rules you want to use to route traffic between Envoy proxies and configure failure recovery features such as timeouts, retries, and circuit breakers. It also maintains a canonical model of all the services in the mesh and uses this to let Envoys know about the other instances in the mesh via its discovery service. Each Envoy instance maintains load balancing information based on the information it gets from Pilot and periodic health-checks of other instances in its load-balancing pool, allowing it to intelligently distribute traffic between destination instances while following its specified routing rules.
• #28: Pilot is responsible for collecting and validating configuration and propagating it to the various Istio components. It abstracts environment-specific implementation details from Mixer and Envoy, providing them with an abstract representation of the user’s services that is independent of the underlying platform. In addition, traffic management rules (i.e. generic layer-4 rules and layer-7 HTTP/gRPC routing rules) can be programmed at runtime via Pilot.
• #31: Failures happen, and operators need tools to stay on top of the health of clusters and their graphs of microservices.
• #36: https://github.com/spiffe/svid/blob/master/SPECIFICATION.md
• #38: Traffic Management: The core component used for traffic management in Istio is Pilot, which manages and configures all the Envoy proxy instances deployed in a particular Istio service mesh. It lets you specify what rules you want to use to route traffic between Envoy proxies and configure failure recovery features such as timeouts, retries, and circuit breakers. It also maintains a canonical model of all the services in the mesh and uses this to let Envoys know about the other instances in the mesh via its discovery service. Each Envoy instance maintains load balancing information based on the information it gets from Pilot and periodic health-checks of other instances in its load-balancing pool, allowing it to intelligently distribute traffic between destination instances while following its specified routing rules.
• #39: 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.
• #44: While Envoy sidecar/proxy provides a host of failure recovery mechanisms to services running on Istio, it is still imperative to test the end-to-end failure recovery capability of the application as a whole. Misconfigured failure recovery policies (e.g., incompatible/restrictive timeouts across service calls) could result in continued unavailability of critical services in the application, resulting in poor user experience. Istio enables protocol-specific fault injection into the network, instead of killing pods, delaying or corrupting packets at TCP layer.Failures observed by the application layer are the same regardless of network level failures, and that more meaningful failures can be injected at the application layer (e.g., HTTP error codes) to exercise the resilience of an application. Operators can configure faults to be injected into requests that match specific criteria. Operators can further restrict the percentage of requests that should be subjected to faults. Two types of faults can be injected: delays and aborts. Delays are timing failures, mimicking increased network latency, or an overloaded upstream service. Aborts are crash failures that mimic failures in upstream services. Aborts usually manifest in the form of HTTP error codes, or TCP connection failures.