Shift to monolith control plane
Google has been working on making Istio simpler to install, upgrade, administer and use.
Istio was built using microservices principles where it was divided into various components based on the functionality they provided. The diagram below shows various components of 1.4 version.
Istio 1.4
This component division was made with the assumption that separate teams would deploy and administer each of the components. However, in reality, there is usually one team/person maintaining and administering Istio and they don’t make use of the flexibility provided by individual components. They just want to deploy, maintain and upgrade Istio. This is one of the example scenarios where microservices architecture may not be beneficial based on client usage.
So, in order to remove this over pivoted design that tries to accommodate one potential solution and make it simple for the primary user a shift to monolith architecture has been made:
- Mixer’s capabilities have been moved to envoy sidecar and gateways. This was done for performance and efficiency
- Galley’s functionality moved to Pilot
- Injector did not receive much of traffic and hence it was also merged into Pilot
- Node agent’s functionality flattened into Pilot Agent. Now pilot agent at startup it generates a private key by negotiating with Citadel and provides it to the sidecar
- Citadel is Istio’s builtin certificate authority. Customers prefer to run their own or third-party CA infrastructure and they want to use that for security reasons. Hence, Citadel was also merged into Pilot. Pilot still provides the API’s to provide Citadel’s functionality
#kubecon #kubernetes #istio #istio-service-tutorial #service-mesh
