Schedule (English)

Atlassian has been deploying Envoy to the compute nodes of its internal PaaS over the past 2 years to simplify service-to-service communication for internal developers. Today we deploy Envoy with static configuration and we want to take advantage of dynamic features like client-side routing, direct communication, and fault injection. We decided Istio was the best choice to deliver this over the next year. We’ll talk through Atlassian’s journey with service-to-service communication, Envoy and the evolution of our home-grown control planes, then walk through the analysis that led to Istio being the best decision for Atlassian’s business moving forward.

This is a story of struggle, tradeoffs, and triumphs. Istio, as you may know, is a mission-critical piece of software for securing and connecting microservices across platforms. However, it can be daunting to introduce, operationalize, or adopt it successfully. In this talk, we dig into T-Mobile’s journey of adopting Istio across 100+ clusters to support microservices for fraud detection, billing, sales and APIs across many teams. The journey was not all rainbows and unicorns.

Istio documentation covers many scenarios how you can start up Istio and get your hands dirty with its offerings. Things become a bit more tricky when it involves multiple clusters, and even more complicated when there are other Open Source projects you need to deal with. The presentation will be mainly driven by demos. The first demo will be based on simply starting multiple KinD clusters locally, and get Istio offerings in action.

WebAssembly filters allow users the power to extend and customize Istio to their liking. But how do organizations actually develop them? Tooling exists for traditional software development, but established methods and tooling are difficult to come by in the emerging WebAssembly ecosystem. In this talk we will attempt to answer the following, based on our experience working Istio + WebAssembly in customer environments for over one year: How do we write WebAssembly filters?

This talk will share the experience of building a data lake using Istio / Envoy. This talk will cover why we selected Istio for building a data lake in early 2019. Our journey with Istio and go in depth the challenges we ran into scaling the ingestion pipeline to scale to process several hundred tera bytes a day.

This workshop is based on Istio and Gloo Mesh. Each participant will have a dedicated VM and we will go through diferent labs.

This talk is for every engineer interested in creating traffic management and telemetry capabilities for the mesh itself. Istio has offered extensibility through WebAssembly since 1.5. User code, running in the sidecar, can implement custom traffic management and telemetry. No Istio control plane access or special builds of the sidecar are needed. C++ and JavaScript developers can write, compile, deploy and test extensions quickly, with just a bit of Istio EnvoyFilter YAML on their clusters.

This talk will walk through how to run Istio locally to improve development velocity, where “local” includes various combinations of local Kubernetes cluster, local docker registry, running Istiod as a local binary (and in a debugger), and running the proxy locally.

At SimilarWeb we use Istio in all of our Kubernetes clusters and utilize Istio’s Authorization and Authentication policies for each service. As a small production engineering team, we wanted to let our developer’s full autonomy for writing new services with Helm without needing to know Istio internals. To solve that problem we abstracted Istio completely inside a generic Helm chart for common use cases. For more complex cases create a MutatingWebhook in k8s that reads annotations from the deployments and configures the deployment to support all Istio related logic.

We introduced Istio on our microservices. Istio’s logs, metrics and features are very helpful for us to investigate in detail in case of failures. One day we had big trouble due to a node failure, and it was very hard to find the root cause about why our application had not been recovered automatically. At that time, we finally found the root cause of it on our application logic thanks to Istio and we could reproduce the same failure on development environment with Istio as well.

There are numerous environmental variables that can be used to control the behavior of Istio. Environmental variables in Istio are considered experimental and there are no guarantees they won’t be removed in future versions of Istio. In this talk, we will explore a few related to certificates used for inter-workload communication within your service mesh: Some of the pilot-agent environmental variables related to certificates How to toggle them during installation using istioctl and helm

Neeraj Poddar and Louis Ryan from the Istio technical oversight committee, lead an update on the development of the project and the roadmap for 2021.

Helm. It’s not just for installation anymore! In this session, we re-introduce Helm as a powerful tool for automating Istio day-two administrative tasks. Using Helm, we can completely rethink Istio management by creating a domain specific language for Istio configuration. Helm lets us build a simplified facade over Istio, allowing developers to more naturally express their intentions as code instead of forcing them to think in Istio CRDs. In this session we will look at four common Istio configuration patterns, and explore how Helm dramatically simplifies their use.

It’s lonely in your pod, but finally, you receive that long-awaited knock on the port… but can you trust that inbound request? This session dives into an essential aspect of a service mesh: trust. We’ll dive into how certificates work into Istio, use peer authentication, and explain concepts like SPIFFE identifiers. Peer thrust can also be leveraged in the application architecture. A mesh is not only for cluster administrators but also for architects and developers, making it well worth to highlight those patterns.

50+ On-Premise Kubernetes Clusters in a Private Cloud, 500+ Compute Nodes, 10+ Istio Meshes, and 2 years of joint efforts with IBM. This is Sberbank’s journey from the technology preview stage to a production-grade Istio mesh installation. Joint speech from IBM and Sberbank representatives will cover the history of their collaboration in detail: key faced problems and solutions, main architectural decisions, and plans for the future.

One of the primary benefits of using Istio is its comprehensive security model, which enables users to express complex authentication and authorization policies for the services running within their mesh. While these security features are commonly used, they can cause confusion and are frequently misunderstood. This talk will explore the security mechanisms available in Istio and will dive into how these policies are translated from high-level user-facing configuration to runtime policies in the various Envoy proxies that comprise the Istio data plane.

A first commit to Istio.io can be daunting and there is a large amount of learning and commitment required to contribute to Istio.io. By presenting my experiences, I want to encourage both people familiar and unfamiliar to Istio, to contribute. I also hope to give some insight on the PR process for contributing to Istio.io, and show some relatively easy first commit examples. I found a home in the Docs WG, and I hope to help introduce others to this community by helping with their first commit.

In this talk, we will show how we used Istio’s EnvoyFilter to dynamically route requests from our QA cluster to a developer’s laptop and back. This networking hack significantly eased development, especially when running end-to-end tests and helped us reduce infrastructure costs.

Wouldn’t it be great to have an easy way to dynamically, via istio, limit the traffic to a service in Kubernetes? Figure out you have one or more ingress gateways for the incoming requests, and you want to limit the requests from a single IP, or to limit requests with an specific http header in an specific amount of time. With this operator you just have to create and deploy a simple Custom Resource (CR) with your desired rate limit configuration.

Another Istio release is out! You may be nervous, but we have been continuously improving our release qualification process to hopefully ease your concerns. In 2020, we collected feedback and used it to focus on producing higher quality and more consistent releases. We created a Definition of Done to determine what it means for releases and features to be considered stable. This has led to release notes tooling, standardized feature maturity levels and release gates.

In this presentation, we will walk through Airbnb’s Istio Journey - why we needed a modern service mesh, how we vetted Istio as the solution, where we are today, the lessons we learnt along the way, and our future plans. We will cover topics including: Airbnb’s multicluster/cell setup, problems we ran into/ideas for UX improvements Airbnb’s upgrade setup for gradual rollout of newer versions of Istio Airbnb’s test pipeline for vetting features we care about How we handled k8s & mesh expansion in a consistent philosophy How we approached migration (zero downtime, no regression) Airbnb’s learnings/pain points/future expectation with Istio Current areas of open discussion - come talk to us more about this

Istio and Envoy are foundational building blocks of the Salesforce Service Mesh. This presentation walks you through our service mesh journey. I will briefly talk about why we chose the service mesh design pattern, how we initially built it using envoy and our in-house control plane and our subsequent pivot to Istio. I will discuss how we are currently leveraging Istio and our plan to increase adoption of Istio to further enhance our Service Mesh platform.

Traffic management is probably the most used feature of Istio. However, handling layer-7 traffic other than HTTP and gRPC can become challenging in an Istio service mesh. In this session, I’ll discuss a few possible approaches to extend Istio’s traffic management capability to other layer-7 protocols such as Dubbo, Thrift, TARS, Redis, MySql, MongoDB, etc. I’ll introduce Aeraki, an open-source project that provides a framework to allow Istio to support more layer 7 protocols than just HTTP and gRPC.

Istio has some basic tooling to facilitate request troubleshooting, but it has something much more powerful at its core: Envoy proxy. When requests in the mesh start failing, Envoy is the definitive source for debugging information as it has a wealth of telemetry and logging that can be enabled to pinpoint problems along the request path. Trouble with certificates? Incorrect headers? Connection pooling or upstream errors? Un-routable request? In this talk, we’ll look at how to build a repeatable and automatable set of tools to quickly debug a request path across multiple hops and potentially across multiple clusters and Istio control planes.

As service mesh gains wider adoption, more and more companies are looking to bring Istio to their organization. Istio will impact many teams, from operations to developers, and it’s important that they are well equipped. First you’ll hear a success story from the Square Cash team, who decided to move to Istio from Square’s homegrown Envoy service mesh. They’ll discuss why it was the right move for them, how they executed the move, and what they’d do differently if they were to do it a second time.

Kiali is a management console for Istio. It provides dashboards, observability, configuration and validation capabilities. This workshop will walk you through practical examples of Istio using Kiali.

The Istio Product Security Working Group operates behind a bit of secrecy given the nature of the group’s work; mostly triaging security reports and threats. In 2020, there were over 11 security bulletins released that spanned from Istio 1.3 to Istio 1.8. In this talk, we will explain why the group was created, how it operates, and its mission to make Istio more secure. Namely, we will discuss: A brief history of how the group was formed Why it was necessary for the group to be created A look at Istio security vulnerabilities in 2020 How we triage security reports and fix them Pro-active measures the group is working on to make Istio more secure Please join us to learn about the responsibilities of the Product Security Working Group and how to stay informed about the security of your environments.

Istio is the most popular Service Mesh. But API Gateways are also very important components in the Cloud Native mix. But if you go for a completely separate tool for API Gateway requirements and for other stuff use Istio, then you effectively have to maintain two different tool and build the expertise in your team for two different disciplines. But Istio can take care of almost all your API Gateway requirements(except for a few).

This talk will describe the new Kubernetes Gateway API being developed by the Kubernetes SIG Network as “an evolution of the Ingress API”, and how this will impact Istio.

One of our main goals in GoPay is to automate mutual TLS communication between GoPay and our partner. We will share how we decide to use and manage Istio, change the configuration to suit our mTLS use cases, how we adapt Istio changes related to mutual TLS, and how our central certificate is managed, and how to set up automatic mutual TLS communication with Istio Egress TLS origination and Istio Gateway.

So you’ve actually done security well and are using an external Redis provider that only allows TLS to talk to it. You could simply configure each of your applications to use TLS from the application pod or you can use Istio to handle the TLS part. This lightning talk demonstrates how to use Istio to do TLS origination for Redis (TCP) using the sidecar instead of the egress gateway.

FICO started it’s mesh journey in 2019, picking up Istio at 0.8. It’s been a bumpy road! Istio has matured a lot in that time, and the organization’s deployment and usage of Istio has matured significantly too. Jeet, a VP of Engineering at FICO, will walk through FICO’s journey with Istio from 2019 to today, discussing why they chose Istio initially, some of the growing pains they experienced, and what business goals they’ve been able to achieve because of Istio.

Managing a service mesh that spans hundreds of thousands of containers across the globe is no easy feat. At high scale, achieving fast configuration convergence time to thousands of proxies, while limiting the CPU & memory utilization of control-plane & proxies is a challenging problem. This talk describes eBay’s initial journey into building a scalable service mesh that provides the traffic management, load-balancing, security and observability features at scale leveraging Istio.

Since the release of Istio 1.0, a major development effort has been spent on making it easier to use. Whether you are already running Istio in production or trying it out for the first time, it’s important that you know about the latest and greatest when it comes to debugging and maintaining istio. Adam Toy from the Department of Defense will walk you through how the USAF’s Platform One program is utilizing Istio to establish a zero-trust PaaS infrastructure, as well as some of the new things Istio has to offer in terms of debugging and maintainability he has learned along the way.

During the past several years Apache Kafka emerged as the default enterprise message bus. With Istio on its own way to becoming the service mesh “standard” within the enterprise, running a Kafka cluster inside a mesh became a frequent requirement. We’ve been running Kafka over Istio for a few years now, and in this talk, we’d like to share our experience, the common problems and eventually the benefits that led us to make this integration possible.

In this session we will cover Previous Setup: High level overview of setup focussing on external and inter-service/component communication where we mainly used Nginx, HAProxy and Envoyproxy. Challenges and Improvements: Briefly cover the challenges and improvements which essentially was translated into set of requirements Istio Onboarding and Integration: How Istio covered our requirements and steps we took and tools we built/used to on-board micro-services and manage the mesh setup. We will also cover the challenges involved in migrating, solutions derived and learnings gained.

At Mercari, we have few hundreds of services running in Kubernetes. We spent the last year and a half trying to integrate Istio in our microservices infrastructure at scale, with many trial-and-error and lessons learned. This presentation will explain what is making Istio a long wild river and how we managed to navigate it. It will focus on several aspects: Stabilizing Istio Adopting Istio Running Istio By sharing our learnings, we hope to make Istio a long quiet river for the community.

Microservices applications rely on complex interactions among services. Engineering teams must create API tests with API mocks to shift testing left. Current approaches to mock creation are manual, which is expensive and inefficient. We illustrate how Istio can be leveraged to significantly reduce engineering effort necessary for API testing. API tests can be built using the following Istio capabilities: Dynamic deployment of Envoy filters to capture relevant examples of API requests and responses.

I will talk about the better external authorization feature in 1.9 that allows users to easily integrate Istio with external authorization system (e.g. OPA, OAuth2). The better external authorization is the latest improvement that solves a much wanted customer request for better extensibility in the authorization policy. This feature makes it possible and greatly improves the user experience of many critical use cases, for example, integrate with industry standard auth mechanism (e.

This talk will walk through canary deployments process and how to achieve the same using Kubernetes service orchestration or Spring Cloud Gateway focusing on the limitations of these approaches and how Istio overcomes these limitations. Spring cloud Gateway or Kubernetes LoadBalancer service or Ingress controllers only supports the edge service routing and not Internal routing from edge service to another service in cluster. This is where Istio virtual services and destination rules come to rescue – this talk with elaborate further on how Istio provides an optimal solution for canary releases in this scenario.

Istio allows users to enable Envoy access logs. These logs provide extensive information and are one of the first steps in diagnosing networking problems in a service mesh. Engarde is a tool which parses Istio access logs into easily readable JSON objects. With Engarde, you get the log field names, but to the average user there are still some knowledge gaps that require a hop over to Envoy’s website to understand what is shown in the logs.

Istio’s Virtual Service API provides a language agnostic way of implementing graceful retries on failures until a timeout budget is exhausted. Precise timeouts and retries per endpoint result in better performance. Having hundreds of gRPC services means there will be as many YAML files to be configured, tested and managed, however. I will explain how we built a scalable way of managing retries and timeouts across the service mesh per service per RPC.

Optum is one of the early adopters of Istio and its been used in a number of use-cases within the organization. In this presentation, Murugappan Chetty of Optum will go over the platform that they built with kubernetes, Istio and knative, where internal users run their workloads. Audience attending this session will get to know about Istio features leveraged by the platform like, security, observability, traffic routing, client libraries, external dns etc.

Closing remarks for IstioCon with Lin Sun.