In last days I had severe trouble configuring Istio due to subtle configuration issues. One of them was providing matching rules in VirtualService where I did not use a list, just single mapping. Another one was DestinationRule where I indented trafficPolicy so that it wasn’t under spec but on root level. These are hard to spot and troublesome to debug. In the latter case the istioctl validate did not produce any warning.
What kind of validation does Istio do on the custom data types? Could it do more, failing my kubectl/oc apply with a proper message?
I know that Kiali provides a variety of validations. Not sure if it would have helped you out but you may want to give it a try. See kiali.io for more on the observability it does for Istio.
Looking at what istioctl validate currently provides, seems this cmd validates against the object schema.
I created a malformed DestinationRule with a trafficPolicy in the yaml root (not in the spec), and same - no warnings.
I created an issue to document what istioctl validate can (and can’t) do now.
Beyond this, there is an open proposal to add more validation for Istio config. In a perfect world, istioctl validate would be able to do things like: check if VirtualService traffic weights sum up to 100, check that the host in a DestinationRule exists as a kubernetes Service.
That said, a broader question is whether this “semantic validation” should exist as part of istioctl directly, or as part of an extension to Istio (eg. Kiali).
Would the validation webhook not be the better place for this? It may be we could also offer something through istioctl but it seems safer to enforce these types of validation rules as part of the deployment.
The validation logic used by the command line and the webhook is the same once the objects have been parsed. The only difference between what the webhook does and what the command line does is deserializing the input.