You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 27, 2023. It is now read-only.
I tried to upgrade Istio in my cluster and got "kubectl apply" timeouts because deployments were hanging. It's my fault but I think this might make a good vetter.
kubectl delete namespace istio-system"
...wait for pods, deployments, services, namespace to be cleaned up...
kubectl apply -f istio-auth.yaml (for istio 0.4.0)
... timeouts creating deployments ...
... no new timeouts can be created ...
The problem is that "kubectl delete namespace istio-system" only deleted objects in that namespace. I had an InitializerConfiguration named "istio-sidecar" that was still around (unnamespaced):
But, I did not have the istio-initializer deployment any more, so there was no running pod that was able to implement the admissionregistration and respond to new deployments. Thus, all my deployments hung.
It's my fault: I should have "kubectl delete -f" instead of just deleting the namespace or done some other upgrade. However, it took me a while to figure out what had happened - it'd be cool if Istio Vet could tell me. I think the vetter would do:
If there is no InitializerConfiguration for sidecar.initializer.istio.io, vetter is done, no warnings.
Find the istio-initializer deployment that is handling sidecar.initializer.istio.io. If it does not have any pods running, then report a warning like:
Warning: Cluster has a sidecar InitializerConfiguration for sidecar.initializer.istio.io but no running controller pods. This means new deployments, statefulsets, jobs and daemonsets will hang in the uninitialized state.
If that warning was rendered, go and check for any deployments, ... that are uninitialized (like kubectl get deployment -n istio-system --include-uninitialized=true). Render a warning like:
Warning: Deployment foo-depl is in the uninitialized state. This may be because there are InitializerConfigurations that have no running controller pods.
It would be great if this vetter could be generic for any hanging deployments. This would require understanding what controllers should be handling what InitializerConfigurations; it wasn't immediately obvious to me how to do that (it looks like the controllers call back to the API server, see all the new deployments, and then just retire whatever initializers they handled?).
Here's an example backtrace from kube-apiserver (1.7.10) for a hanging deployment:
I tried to upgrade Istio in my cluster and got "kubectl apply" timeouts because deployments were hanging. It's my fault but I think this might make a good vetter.
Here's what I did:
Original Install
Upgrade:
...wait for pods, deployments, services, namespace to be cleaned up...
... timeouts creating deployments ...
... no new timeouts can be created ...
The problem is that "kubectl delete namespace istio-system" only deleted objects in that namespace. I had an InitializerConfiguration named "istio-sidecar" that was still around (unnamespaced):
But, I did not have the istio-initializer deployment any more, so there was no running pod that was able to implement the admissionregistration and respond to new deployments. Thus, all my deployments hung.
It's my fault: I should have "kubectl delete -f" instead of just deleting the namespace or done some other upgrade. However, it took me a while to figure out what had happened - it'd be cool if Istio Vet could tell me. I think the vetter would do:
Warning: Cluster has a sidecar InitializerConfiguration for sidecar.initializer.istio.io but no running controller pods. This means new deployments, statefulsets, jobs and daemonsets will hang in the uninitialized state.
kubectl get deployment -n istio-system --include-uninitialized=true
). Render a warning like:Warning: Deployment foo-depl is in the uninitialized state. This may be because there are InitializerConfigurations that have no running controller pods.
It would be great if this vetter could be generic for any hanging deployments. This would require understanding what controllers should be handling what InitializerConfigurations; it wasn't immediately obvious to me how to do that (it looks like the controllers call back to the API server, see all the new deployments, and then just retire whatever initializers they handled?).
Here's an example backtrace from kube-apiserver (1.7.10) for a hanging deployment:
The text was updated successfully, but these errors were encountered: