Feature Status

This page lists the relative maturity and support level of every Istio feature. Please note that the phases are applied to individual features within the project, not to the project as a whole. Here is a high level description of what these labels mean.

Feature phase definitions

ExperimentalAlphaBetaStable
PurposeFeature is under active development and user facing APIs may change. Users should deploy experimental features with extreme caution, preferably in non-production environments as experimental versions may require a migration effort.Used to get feedback on a design or feature or see how a tentative design performs, etc. Targeted at developers and expert users.Used to vet a solution in production without committing to it in the long term, to assess its viability, performance, usability, etc. Targeted at all users.Dependable, production hardened.
StabilityMay be buggy. Using the feature may expose bugs. Not active by default.May be buggy. Using the feature may expose bugs. Not active by default.Code is well tested. The feature is safe for production use.Code is well tested and stable. Safe for widespread deployment in production.
SecurityUsing the feature may have obvious security vulnerabilities. Discovered vulnerabilities may not be communicated broadly.Using the feature may have obvious security vulnerabilities. Discovered vulnerabilities may not be communicated broadly.Any discovered security vulnerabilities will be publicly disclosed and patched.Any discovered security vulnerabilities will be publicly disclosed and patched.
PerformancePerformance characteristics are unknown. Enabling the experimental feature may adversely affect performance.Performance requirements are assessed as part of design.Performance and scalability are characterized, but may have caveats.Performance (latency/scale) is quantified and documented, with guarantees against regression.
SupportNo guarantees on backward compatibility. There is no commitment from the Istio community to improve, maintain or complete the feature and the feature may be dropped entirely in a later software release at any time without notice.No guarantees on backward compatibility. There is no commitment from Istio to complete the feature. The feature may be dropped entirely in a later software release at any time without notice.The overall feature will not be dropped, though details may change. Istio commits to complete the feature, in some form, in a subsequent Stable version. Typically this will happen within 3 months, but sometimes longer. Releases should simultaneously support two consecutive versions (e.g. v1alpha1 and v1beta1; or v1beta1 and v1) for at least one supported release cycle (typically 3 months) so that users have enough time to upgrade and migrate resources.The feature will continue to be present for many subsequent releases.
Deprecation PolicyNone, feature can be removed at any time.None, feature can be removed at any time.Weak, feature can be removed with 3 months of advanced notice.Strong, feature can be removed with 1 year of advanced notice, but there will usually be a supported upgrade path to a replacement feature.
VersioningThe API version name contains dev (e.g. v1dev1).The API version name contains alpha (e.g. v1alpha1).The API version name contains beta (e.g. v1beta1).The API version is vX where X is an integer (e.g. v1).
AvailabilityThe feature may or may not be available in the main Istio repository. The feature may or may not appear in an Istio release. If it does appear in an Istio release it will be disabled by default. The feature requires an explicit flag to enable in addition to any configuration required to use the feature, in order to turn on dev features.The feature is committed to the Istio repository. The feature appears in an official Istio release. The feature requires explicit user action to use, e.g. a flag flip, use of a config resource, an explicit installation action, or an API being called. When a feature is disabled it must not affect system stability.In official Istio releases Enabled by default.Same as Beta.
AudienceOther developers closely collaborating on a feature or proof-of-concept.The feature is targeted at developers and expert users interested in giving early feedback.Users interested in providing feedback on features.All users.
CompletenessFeature has limited capabilities. This feature may act as a proof of concept.Some API operations or CLI commands may not be implemented. The feature need not have had an API review (an intensive and targeted review of the API, on top of a normal code review).All API operations and CLI commands should be implemented. End-to-end tests are complete and reliable. The API has had a thorough API review and is thought to be complete, though use during beta frequently turns up API issues not thought of during review.Same as Beta.
DocumentationExperimental features are marked as experimental in auto-generated reference docs or they are not exposed.Alpha features are marked alpha in auto-generated reference docs. Basic documentation describing what the feature does, how to enable it, the restrictions and caveats, and a pointer to the issue or design doc the feature is based on.Complete feature documentation published to istio.io. In addition to the basic alpha-level documentation, beta documentation includes samples, tutorials, glossary entries, etc.Same as Beta.
UpgradeabilityThe schema and semantics of an experimental feature may change in newer versions without any guarantees of preserving backwards compatibility requiring configuration changes during upgrades. API versions may increment faster than the release cadence and developers are not required to maintain multiple versions for backwards compatibility. Developers are encouraged to increment the API version when schema or semantics change in an incompatible way.The schema and semantics of an alpha feature may change in a later software release, without any provision for preserving configuration objects in an existing Istio installation. API versions may increment faster than the release cadence and the developer need not maintain multiple versions. Developers should increment the API version when schema or semantics change in an incompatible way.The schema and semantics may change in a later software release. When this happens, an upgrade path will be documented. In some cases, objects will be automatically converted to the new version. In other cases, a manual upgrade may be necessary. A manual upgrade may require downtime for anything relying on the new feature, and may require manual conversion of objects to the new version. When manual conversion is necessary, the project will provide documentation on the process.Only strictly compatible changes are allowed in subsequent software releases.
TestingThe presence of the feature must not affect any released features.The feature is covered by unit tests and integration tests where the feature is enabled and the tests are non-flaky. Tests may not cover all corner cases, but the most common cases have been covered. Testing code coverage >= 70%. When the feature is disabled it does not regress performance of the system.Integration tests cover edge cases as well as common use cases. Integration tests cover all issues reported on the feature. The feature has end-to-end tests covering the samples/tutorials for the feature. Test code coverage is >= 80%.Superset of Beta, including tests for any issues discovered during Beta. Test code coverage is >= 90%.
ReliabilityThe user should not expect the feature to be reliable may be untested.Because the feature is relatively new, and may lack complete end-to-end tests, enabling the feature via a flag might expose bugs which destabilize Istio (e.g. a bug in a control loop might rapidly create excessive numbers of objects, exhausting API storage).Because the feature has e2e tests, enabling the feature should not create new bugs in unrelated features. Because the feature is relatively new, it may have minor bugs.High. The feature is well tested and stable and reliable for all uses.
Recommended Use CasesIn short-lived development or testing environments, geared towards soliciting early feedback from users to shape development efforts.In short-lived development or testing environments, due to complexity of upgradeability and lack of long-term support.In development or testing environments. In production environments as part of an evaluation of the feature in order to provide feedback.Any.

Istio features

Below is our list of existing features and their current phases. This information will be updated after every release.

Traffic management

FeaturePhase
Protocols:HTTP1.1/HTTP2/gRPC/TCPStable
Protocols:Websockets/MongoDBStable
Traffic Control: label/content based routing, traffic shiftingStable
Resilience features: timeouts, retries, connection pools, outlier detectionStable
Gateway: Ingress, Egress for all protocolsStable
Gateway InjectionBeta
TLS termination and SNI Support in GatewaysStable
SNI (multiple certs) at ingressStable
Locality load balancingBeta
Enabling custom filters in EnvoyAlpha
Sidecar APIBeta
DNS ProxyingBeta
Kubernetes Gateway APIs for ingress (`Gateway` `parentRef`)Stable
Kubernetes Gateway APIs for mesh (`Service` `parentRef`)Beta
Gateway Network Topology ConfigurationAlpha
Kubernetes Multi-Cluster Service (MCS) DiscoveryExperimental

Observability

FeaturePhase
Prometheus IntegrationStable
Service Dashboard in GrafanaStable
Distributed TracingStable
Stackdriver IntegrationStable
Distributed Tracing to Zipkin/JaegerBeta
Trace SamplingBeta
Request ClassificationBeta
Configurable Telemetry ProductionAlpha

Extensibility

FeaturePhase
WebAssembly ExtensionAlpha

Security and policy enforcement

FeaturePhase
Service-to-service Mutual TLSStable
Kubernetes: Service Credential DistributionStable
Certificate management on Ingress GatewayStable
Pluggable Key/Cert Support for istio CAStable
AuthorizationStable
End User (JWT) AuthenticationStable
Peer AuthenticationBeta
Automatic mutual TLSBeta
VM: Service Credential DistributionBeta
External AuthorizationBeta
Authorization Dry RunAlpha
JWT Claim Based RoutingAlpha
Copy JWT Claims to HTTP HeadersExperimental

Core

FeaturePhase
In-Cluster OperatorBeta
Kubernetes: Envoy Installation and Traffic InterceptionStable
Kubernetes: Istio Control Plane InstallationStable
Multicluster MeshBeta
External Control PlaneBeta
Kubernetes: Istio In-Place Control Plane UpgradeBeta
Basic Configuration Resource ValidationBeta
Istio CNI PluginBeta
IPv6 Support for KubernetesAlpha
Distroless Base Images for IstioStable
Virtual Machine IntegrationBeta
Helm Based InstallationBeta
Revision Based UpgradeBeta
Revision TagsBeta
Dual Stack Support in IstioExperimental

Ambient

FeaturePhase
Ztunnel CoreBeta
Waypoints CoreBeta
Authorization PoliciesBeta
Gateway API (HTTPRoute)Beta
Sidecar InteropAlpha
DNS ProxyingAlpha
Multi-clusterAlpha
Multi-networkExperimental
Dual Stack, IPv6Experimental
Was this information useful?
Do you have any suggestions for improvement?

Thanks for your feedback!