Istio sidecars in Kyma and why you want them
Purpose of Istio sidecars
By default, Istio installed as part of Kyma is configured with automatic Istio proxy sidecar injection disabled. This means that none of Pods of your workloads (such as deployments and StatefulSets; except any workloads in the kyma-system
Namespace) get their own sidecar proxy container running next to your application.
With an Istio sidecar, the resource becomes part of Istio service mesh, which brings the following benefits that would be complex to manage otherwise.
Secure communication
In Kyma's default Istio configuration, peer authentication is set to cluster-wide STRICT
mode. This ensures that your workload only accepts mutual TLS traffic where both, client and server certificates, are validated to have all traffic encrypted. This provides each service with a strong identity, with reliable key and certificate management system.
Another security benefit of having a sidecar proxy is that you can perform request authentication for your service. Istio enables request authentication with JSON Web Token (JWT) validation using a custom authentication provider. Learn how to secure your workload using JWT.
Observability
Furthermore, Istio proxies improve tracing: Istio performs global tracing and forwards the data to Kyma's tracing component using the Zipkin protocol. Learn more about the process in Tracing Architecture.
Kiali is another tool to monitor the service mesh; and Kyma configures Istio to export metrics necessary to support Kiali features that facilitate managing, visualizing, and troubleshooting your service mesh. Learn more about deploying Kiali to your Kyma cluster in our Kiali example.
Moreover, Kyma provides Istio-specific Grafana dashboards for the monitoring component. Together with metrics exposed by the Istio sidecar, you get better visibility into workloads and the mesh control plane performance.
Being part of Istio service mesh enables all these advanced observability features, which would not be possible without advanced instrumentation code within your application.
Traffic management
Traffic management is an important feature of service mesh. If you have the sidecar injected into every workload, you can use this traffic management without additional configuration.
With traffic shifting and request routing, developers can use techniques like canary releases and A/B testing to make their software release process faster and more reliable.
To improve the resiliency of your applications, you can use mirroring and fault injection for testing and audit purposes.
Resiliency
Application resiliency is an important topic within traffic management. Traditionally, resiliency features like timeouts, retries, and circuit breakers were implemented by application libraries. However, with service mesh, you can delegate such tasks to the mesh, and the same configuration options will work regardless of the programming language of your application. You can read more about it in Network resilience and testing.
Sidecar proxy behavior during Kyma upgrade
For Kyma upgrades, it's a priority to have full compatibility of existing workloads with the upgraded version of Istio. To ensure that the newest version of sidecar proxy is injected into the Pods, the upgrade performs a rollout restart
of the workloads whenever possible. To learn more about exceptions when it's impossible to restart workloads, read the troubleshooting guide Pods stuck in Pending/Failed/Unknown
state after upgrade.