Istio

Istio as an Example of When Not to Do Microservices

Monitoring blocked and passthrough external service traffic

What are BlackHole and Passthrough clusters? Understanding, controlling and securing your external service access is one of the key benefits that you get from a service mesh like Istio. From a security and operations point of view, it is critical to monitor what external service traffic is getting blocked as they might surface possible misconfigurations or a security vulnerability if an application is attempting to communicate with a service that it should not be allowed to.

Mixer out-of-process adapter for Knative

Demonstrates a Mixer out-of-process adapter which implements the Knative scale-from-zero logic. This post demonstrates how you can use Mixer to push application logic into Istio. It describes a Mixer adapter which implements the Knative scale-from-zero logic with simple code and similar performance to the original implementation.

The Evolution of Istio’s APIs

One of Istio’s main goals has always been, and continues to be, enabling teams to develop abstractions that work best for their specific organization and workloads. Istio provides robust and powerful building blocks for service-to-service networking. Since version 0.1, the Istio team has been learning from production users about how they map their own architectures, workloads, and constraints to Istio’s capabilities, and we’ve been evolving Istio’s APIs to make them work better for you.

Secure Control of Egress Traffic in Istio, part 3

Welcome to part 3 in our series about secure control of egress traffic in Istio. In the first part in the series, I presented the attacks involving egress traffic and the requirements we collected for a secure control system for egress traffic. In the second part in the series, I presented the Istio way of securing egress traffic and showed how you can prevent the attacks using Istio.

Secure your service mesh with Istio and keep an eye on it with Kiali

Benchmarking Service Mesh Performance

Service meshes add a lot of functionality to application deployments, including traffic policies, observability, and secure communication. But adding a service mesh to your environment comes at a cost, whether that’s time (added latency) or resources (CPU cycles). To make an informed decision on whether a service mesh is right for your use case, it’s important to evaluate how your application performs when deployed with a service mesh.

Visualizing Istio external traffic with Kiali

Suppose that you have an application using several third party services to store files, send messages, write tweets, etc. It is useful to know how much traffic is going off your mesh to these services, for example, you might want to know how many requests are directed to twitter or how much data is being sent to Dropbox. Also knowing if these requests are successful or if they fail.

Secure Control of Egress Traffic in Istio, part 1

This is part 1 in a new series about secure control of egress traffic in Istio that I am going to publish. In this installment, I explain why you should apply egress traffic control to your cluster, the attacks involving egress traffic you want to prevent, and the requirements for your system to do so. Once you agree that you should control the egress traffic coming from your cluster, the following questions arise: What requirements does a system have for secure control of egress traffic?

Linkerd or Istio?

This week I set out to write a post comparing Istio and Linkerd, and I told myself: I’m going to create tables comparing features, and it’s going to be great and people will love and the world will be happier for a few seconds. I promised myself It was going to be a fair comparison without bias from any end. While the ‘comparison table’ is still here, I shifted the focus of the article: the goal is not on which is better, but which is better for you, for your applications, for your organization.

Using Gloo as an ingress gateway with Istio and mTLS (updated for Istio 1.1!)

Announcing Istio 1.1

Since we released 1.0 back in July, we’ve done a lot of work to help people get into production. Not surprisingly, we had to do some patch releases (6 so far!), but we’ve also been hard at work adding new features to the product. The theme for 1.1 is Enterprise Ready.

Architecting Istio 1.1 for Performance

Hyper-scale, microservice-based cloud environments have been exciting to build but challenging to manage. Along came Kubernetes (container orchestration) in 2014, followed by Istio (container service management) in 2017. Both open-source projects enable developers to scale container-based applications without spending too much time on administration tasks.

How to automatically generate a new metric and a new log stream in Service Mesh

Use Istio traffic mirroring for quicker debugging

Often when an error occurs, especially in production, one needs to debug the application to create a fix. Unfortunately the input that created the issue is gone. And the test data on file does not trigger the error (otherwise it would have been fixed before delivery).

Istio and Kubernetes in production. Part 2. Tracing

In the previous post, we took a look at the building blocks of Service Mesh Istio, got familiar with the system, and went through the questions that new Istio users often ask. In this post, we will look at how to organize the collection of tracing information over the network. The first thing that developers and system administrators think about when they hear the term Service Mesh is tracing.

Jaeger integration in Kiali

Kiali has the ability to show traces obtained from Istio. Jaeger collects traces for monitoring and troubleshooting microservices-based distributed systems, and both Istio and Kiali use the data that Jaeger provides. Originally this was done via a separate tab in the UI.

Sidestepping Dependency Ordering with AppSwitch

We are going through an interesting cycle of application decomposition and recomposition. While the microservice paradigm is driving monolithic applications to be broken into separate individual services, the service mesh approach is helping them to be connected back together into well-structured applications. As such, microservices are logically separate but not independent.

Combining Federation V2 and Istio Multicluster

In a previous post, we saw how to leverage Istio Multicluster to deploy an application (bookinfo) on multiple Red Hat OpenShift clusters and apply mesh policies on all of the deployed services. We also saw that the deployment process was relatively complex. In this post we are going to see how Federation V2 can help simplify the process of deploying an application to multiple clusters.

A Crash Course For Running Istio

At Namely we’ve been running with Istio for a year now. Yes, that’s pretty much when it first came out. We had a major performance regression with a Kubernetes cluster, we wanted distributed tracing, and used Istio to bootstrap Jaeger to investigate.

Understanding How Envoy Sidecar Intercept and Route Traffic in Istio Service Mesh

Istio Multicluster

Istio Multicluster is a feature of Istio–the basis of Red Hat OpenShift Service Mesh–that allows for the extension of the service mesh across multiple Kubernetes or Red Hat OpenShift clusters. The primary goal of this feature is to enable control of services deployed across multiple clusters with a single control plane. The main requirement for Istio multicluster to work is that the pods in the mesh and the Istio control plane can talk to each other.