Istio

<img src="https://bestpractices.coreinfrastructure.org/projects/1395/badge" alt="CII Best Practices" class="ra0-md-img" loading="lazy" />
<img src="https://goreportcard.com/badge/github.com/istio/istio" alt="Go Report Card" class="ra0-md-img" loading="lazy" />
<img src="https://godoc.org/istio.io/istio?status.svg" alt="GoDoc" class="ra0-md-img" loading="lazy" />

Istio is an open source service mesh that layers transparently onto existing distributed applications. Istio’s powerful features provide a uniform and more efficient way to secure, connect, and monitor services. Istio is the path to load balancing, service-to-service authentication, and monitoring – with few or no service code changes.

• For in-depth information about how to use Istio, visit istio.io
• To ask questions and get assistance from our community, visit GitHub Discussions
• To learn how to participate in our overall community, visit our community page

In this README:

• Introduction
• Repositories
• Issue management

In addition, here are some other documents you may wish to read:

• Istio Community - describes how to get involved and contribute to the Istio project
• Istio Developer's Guide - explains how to set up and use an Istio development environment
• Project Conventions - describes the conventions we use within the code base
• Creating Fast and Lean Code - performance-oriented advice and guidelines for the code base

You'll find many other useful documents on our Wiki.

Introduction

Istio is an open platform for providing a uniform way to [integrate
microservices](https://istio.io/latest/docs/examples/microservices-istio/), manage traffic flow across microservices, enforce policies
and aggregate telemetry data. Istio's control plane provides an abstraction
layer over the underlying cluster management platform, such as Kubernetes.

Istio is composed of these components:

• Envoy - Sidecar proxies per microservice to handle ingress/egress traffic

between services in the cluster and from a service to external
services. The proxies form a _secure microservice mesh_ providing a rich
set of functions like discovery, rich layer-7 routing, circuit breakers,
policy enforcement and telemetry recording/reporting
functions.

> Note: The service mesh is not an overlay network. It
> simplifies and enhances how microservices in an application talk to each
> other over the network provided by the underlying platform.

• Ztunnel - A lightweight data plane proxy written in Rust,

used in Ambient mesh mode to provide secure connectivity and observability for workloads without sidecar proxies.

• Istiod - The Istio control plane. It provides service discovery, configuration and certificate management.

Repositories

The Istio project is divided across a few GitHub repositories:

• istio/api. This repository defines

component-level APIs and common configuration formats for the Istio platform.

• istio/community. This repository contains

information on the Istio community, including the various documents that govern
the Istio open source project.

• istio/istio. This is the main code repository. It hosts Istio's

core components, install artifacts, and sample programs. It includes:

• istioctl. This directory contains code for the

_istioctl_ command line utility.

• pilot. This directory

contains platform-specific code to populate the
abstract service model, dynamically reconfigure the proxies
when the application topology changes, as well as translate
routing rules into proxy specific configuration.

• security. This directory contains security related code.

• istio/proxy. The Istio proxy contains

extensions to the Envoy proxy (in the form of
Envoy filters) that support authentication, authorization, and telemetry collection.

• istio/ztunnel. The repository contains the Rust implementation of the ztunnel

component of Ambient mesh.

• istio/client-go. This repository defines

auto-generated Kubernetes clients for interacting with Istio resources programmatically.

> [!NOTE]
> Only the istio/api and istio/client-go repositories expose stable interfaces intended for direct usage as libraries.

Issue management

We use GitHub to track all of our bugs and feature requests. Each issue we track has a variety of metadata:

• Epic. An epic represents a feature area for Istio as a whole. Epics are fairly broad in scope and are basically product-level things.

Each issue is ultimately part of an epic.

• Milestone. Each issue is assigned a milestone. This is 0.1, 0.2, ..., or 'Nebulous Future'. The milestone indicates when we

think the issue should get addressed.

• Priority. Each issue has a priority which is represented by the column in the Prioritization project. Priority can be one of

P0, P1, P2, or >P2. The priority indicates how important it is to address the issue within the milestone. P0 says that the
milestone cannot be considered achieved if the issue isn't resolved.