Istio Version Control On Kubernetes
Istio has been adopted as a common implementation of service mesh, since more and more companies want to bring Istio into production, the version control of Istio seems a significant problem to solve.
Version control is necessary as Istio components can be treated as the equivalent RPC services like our business services, we need to have an understanding of which version we are using now and what does the next version bring. And some Istio components can cooperate with the others, if we need to upgrade one component we need to upgrade the other components too.
Although the Istio community provides the Istio upgrade method, we don’t actually want to upgrade such a whole thing in one move, it influences so much that we don’t want to risk.
Helm
Helm is package control system for Kubernetes, it’s more like the complicated version of brew on Mac.
It uses Yaml and Golang templates to formulate a complete application configuration on Kubernetes. A lot of applications are packaged as Helm charts, we can build a complicated application by declaring the dependencies between these charts.
Istio + Helm
Istio project contains the Helm configuration itself, I recommend the users to extract the Helm brought by Istio into a standalone Git repository.
Like the other services, we use Git to control each component’s configuration and track every modification.
CI/CD
As more and more people advocate infrastructure as code, we not only store the Istio Helm as a Git repository, we bring the CI/CD to the infrastructure.
If three Kubernetes clusters: test, stage, production exist, we can setup CI/CD to test cluster based on the specified Git test branch, each commit will trigger the generation of the latest Istio K8S Yaml config and apply them to the test cluster, after the tests on test environment, we brought the Istio updates to the stage and production in order.
Still worried about Production?
Although we have tested in the test environment, we still worry if it works in the production and a method to let you know what actually changes is to diff the K8S configuration between the latest config and the current K8S config.
I recommend the kubediff tool to distinguish the differences.
Conclusion
- Every updates to Istio configuration need to be tracked by Git.
- Like the common services, deploy the change to
testenvironment as soon as possible to fail fast. - Use
kubediffto show the changes.