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?
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.
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.
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.
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.
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.
Histogram bucketization is very different from the V1 version.
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?
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.
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.
*Add Beta Certification API. The new API is divided into PeerAuthentication and RequestAuthenticaiton for workloads.
*Added TCP protocol support for v2 telemetry.
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.