I’ve run across this weird state for a new 1.18 cluster where helm template istio/manifests/charts/istio-operator/ --set hub=docker.io/istio --set tag=1.8.1 --set operatorNamespace=istio-operator --set istioNamespace=istio-system applied using kubectl apply results in an istio-operator pod logging deletions for CRs in istio-system, but, won’t deploy anything using CRs; no errors logged (see log over in slack user-lounge) 
But if I remove what was applied, and then use istioctl operator init, the unprocessed CRs suddenly all get deployed immediately?
Deleting the istio-operator Deployment and then retrying via kubectl reproduces the behavior every time, where CRs are ignored for deployment, not sure where else to look having spent the whole day diffing everything, and finding no differences as a result of what istioctl operator init did. It seems to be doing something that I am not seeing Even applying the manifest logged via --log_output_level=all:debug directly does not help 
Tried so many different ways for a gitops managed cluster to establish the operator via manifest only while avoiding the use of istioctl operator init, but cannot find any way to do so 
Where else should I be looking to get the operator deployed via gitops?