Whats up with istiod in 1.5?

Documentation says:
### Istiod
In Istio 1.5, there will be a new deployment, istiod . This component is the core of the control plane, and will handle configuration and certificate distribution, sidecar injection, and more.

except istio-pilot deployment is still there after an upgrade to 1.5 and the istiod deployment is nowhere to be seen.

Can someone explain what/why the documentation says so?

Architecture adjustment

This section mainly analyzes the architectural changes of Istio 1.5, which is also the core change of this version. It mainly includes the reconstruction of the control plane, the integration of the original multiple components into a single structure istiod; meanwhile, the long-acclaimed Mixer components have been abandoned. It also explains whether it is backward compatible. If you are upgrading from 1.4.x to 1.5, you must be aware of these changes.

Rebuild control plane

The official use of the term Restructuring rather than Refactoring shows how much it has changed. In Istio 1.5, the control plane will use the new deployment model to integrate the original components together.


Istio 1.5 uses a new deployment mode: istiod. This component is the core of the control plane and is responsible for various functions such as configuration, certificate distribution, and sidecar injection. istiod is the biggest change in the new version. It replaces the original architecture with a single component, which reduces the complexity and maintenance difficulty while improving the ease of use. It should be noted that the original multi-components are not completely removed, but are integrated into modules to form istiod after refactoring.

Sidecar injection

Previous versions of sidecar injection were implemented by the istio-sidecar-injector webhook. The webhook is retained in the new version, but integrated into istiod, the injection logic remains the same.


Configuration verification-functionality is retained and incorporated into istiod.
MCP Server-changed to shutdown by default. It’s just an implementation detail for most users. If you decide to depend on it, you need to deploy istio-galley and start its process.
Experimental features (such as configuration analysis)-istio-galley also needs to be deployed.


Previously, Citadel’s two functions were to generate a certificate and provide the key to nodeagent in gRPC mode when SDS was turned on. In version 1.5, keys are no longer written to every namespace and are only provided through gRPC. This feature has also been incorporated into istiod.

SDS node agent

nodeagent is removed.


Previously, sidecars could access certificates in two ways: keys mounted as files; and SDS. All keys in the new version are stored locally on the SDS server. For most users, it only needs to be obtained from istiod. For users of custom CAs, file keys can still be mounted, but they are still provided by the local SDS server. This means that certificate polling will no longer require Envoy to restart.


CNI has not changed and is still in istio-cni.


istio-pilot’s independent components and processes have been removed and replaced by istiod, which contains all its features. For backward compatibility, there are still a few references to Pilot.

Obsolete Mixer

Mixer is deprecated in Istio 1.5. The mixer is completely turned off by default. The V2 version of Telemetry is the default feature in the new version and does not require a mixer. If you rely on special features of Mixer, such as out-of-process adapters, you need to turn Mixer back on. Mixer will continue to fix bugs and security holes until Istio 1.7. Many features of the mixer are described in the Mixer Deprecation documentation, including alternative in-proxy extensions based on the Wasm sandbox API.

The new version of HTTP telemetry is based on the in-proxy Stats filter by default. This saves 50% of CPU usage. The main differences between Telemetry V2 and older versions in 1.5 are:

If the source and destination of the traffic are not injected into the sidecar, some telemetry information will not be collected.

Egress telemetry is no longer supported.

Histogram bucketization is very different from the V1 version.

TCP telemetry supports only mTLS.

More Prometheus instances are needed to collect data for all agents.
If developers have previously used Istio’s default HTTP telemetry, migrating to the new version is fine. You can automatically upgrade to V2 directly through istioctl upgrade.

Mixer, the most spurned by community developers, has finally been abandoned, and it can be said that it is the culprit that affects the performance of old versions. Everyone is happy now, and even the most vocal Wasm plan is on the agenda. Of course, we can also see that the Istio team did not kill Mixer across the board in order to ensure that the upgrade dependency of the old version. The deep meaning of continuing to fix the bug to version 1.7 is that it will be completely removed in 1.7?

Control plane security

In older versions, when values.global.controlPlaneSecurityEnabled = true was set, the agent would safely interact with the control plane, which is the default configuration in version 1.4. Each control plane component has a sidecar with a Citadel certificate, and the agent connects to Pilot through port 15011.

In the new version, it is no longer recommended or connected to the control plane by default. Instead, use a DNS certificate issued by Kubernetes or Istiod. The agent connects to Pilot through port 15012.

Feature update

Istio 1.5 not only does subtraction, but also many additions, including new features, performance optimizations, and bug fixes. This section lists improvements in the new version in terms of traffic management, security, and telemetry.

Traffic management

  • Improved the performance of ServiceEntry.
  • Fixed readiness probe inconsistencies.
  • Improved the performance of configuration updates by directing local updates.
  • Added option to set the load balancer where host is set.
  • Fixed an issue where Pod crashes would trigger over-configuration pushes.
  • Fixed an issue where apps called themselves.
  • Added detection of iptables when using Istio CNI.
  • Added consecutive_5xx and gateway_errors as outlier detection options.
  • Improved EnvoyFilter matching performance optimization.
  • Added support for the HTTP_PROXY protocol.
  • Improved iptables settings, using iptables-restore by default.
  • Automatic protocol detection is enabled by default.


*Add Beta Certification API. The new API is divided into PeerAuthentication and RequestAuthenticaiton for workloads.

  • Add authentication policies to support deny operations and semantic exclusion.
  • The beta version has automatic mTLS turned on by default.
  • Added SDS to stable version.
  • The merger of Node agent and Pilot agent removes the need for Pod security policies and improves security.
  • Incorporate Citadel’s certificate issuing function into Pilot.
  • Support Kubernetes first-party-jwt as a backup token for CSR authentication in the cluster.
  • Provide keys and certificates to Prometheus through the Istio Agent.
  • Support Citadel to provide certificates to the control plane.


*Added TCP protocol support for v2 telemetry.

  • Support for adding gRPC response status codes to metrics and logs.
  • Support Istio Canonical Service
  • Improved the stability of the v2 telemetry process.
  • Alpha level support for configurability of v2 telemetry.
  • Support for adding AWS platform metadata to the metadata of Envoy nodes.
  • Updated Mixer’s Stackdriver adapter to support configurable refresh intervals to track data.
  • Supports headless collection services for Jaeger plugins.
  • Fixed kubernetesenv adapter to provide support for Pods with. In the name.
  • Improved Fluentd adapter to provide millisecond output in exported timestamps.


  • IstioOperator API replaced IstioControlPlane API.
  • Added istioctl operator init and istioctl operator remove commands.
  • Adding cache improves reconciliation speed.
  • Performance and scalability
  • Ignore useless services when generating a cluster for the gateway.
  • Skip calling updateEDS for the headless service.
  • SNI-DNAT is turned off by default in the ingress gateway.
  • Error coverage statement.
  • When the capacity is known, create a slice based on the capacity.
  • Test and release
  • Created a Docker image for istioctl.


  • Add the mTLS analyzer.
  • Add JwtAnalyzer.
  • Add ServiceAssociationAnalyzer.
  • Add SercretAnalyaer.
  • Add sidecar ImageAnalyzer.
  • Add PortNameAnalyzer.
  • Add Policy DeprecatedAnalyzer.
  • Added more authentication rules to RequestAuthentication.
  • istioctl analyze from experimental to formal.
  • Add a new tag -A | --all-namespaces to istioctl analyze to analyze the entire cluster.
  • Added content analysis via stdin to istioctl analyze.
  • Adding istioctl analyze -L displays a list of all available analyses.
  • Added ability to suppress information from istioctl analyze.
  • Added structured format options for istioctl analyze.
  • Add corresponding documentation links to the output of istioctl analyze.
  • Annotation methods are provided in the analyzer through the Istio API.
  • istioctl analyze can load files based on directories.
  • istioctl analyze attempts to associate messages with their source file names.
  • istioctl analyze printable namespace.
  • istioctl analyze analyzes resources in the cluster by default.
  • Fixed a bug where the analyzer suppressed cluster-level resource messages.
  • Added multi-file support for istioctl manifest.
  • Replace IstioControlPlane API with IstioOperator API.
  • Add selector for istioctl dashboard.
  • Added slicing and list support for the istioctl manifest --set flag.

to sum up

Istio 1.5 is a version that fully embraces change. Rebuilding the entire control plane and creating a new deployment mode istiod; abandoning the Mixer that is dragging down system performance; ensuring compatibility without forgetting to continuously optimize and introduce new features. While completely abandoning the historical burden, the Istio team also used their courage to practice the true meaning of agile development. With a stable quarterly release, I believe Istio will become more mature in the future. let us wait and see.

@catman002 i am having problems understanding what question you answered. Certainly not the one i asked above. ( i really dont need a re-paste of istio docs; and even less a “summary” that sounds like wishful thinking and plans) I am not trying to be mean. Your answer is just completely “off”.

I asked - why after installing istio v1.5 there is no “istiod” deployment?
(documentation specifically says it should be there)
and why the istio-pilot deployment is there?
(when documenation says that it shouldnt be there, except for certain backwards compat references)

I am experiencing the same issue when using helm template to update the cluster. I tried using istioctl to generate the manifests and was able to verify that istiod would be created. Still working on a plan to re-install istio using istioctl though. As there doesn’t seem to be an easy way to migrate to it from helm.