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 }}
Repository navigation
Knative operator is active while knative-serving installation failed #278
The knative-serving charm is in active state while the logs indicate there is an unsupported version of K8s in the cluster. It might be a bad UX design, because nothing is deployed and the charm does not complain about it.
To Reproduce
Deploy Kubeflow charm 1.9 in EKS cluster with K8s version 1.25
Environment
Deploy Kubeflow charm 1.9 in EKS cluster with K8s version 1.25
Relevant Log Output
2025-01-15T11:10:37.013Z [knative-operator] {"severity":"EMERGENCY","timestamp":"2025-01-15T11:10:37.013411678Z","logger":"knative-operator","caller":"sharedmain/main.go:386","message":"Version check failed","commit":"fbc6e15","knative.dev/pod":"knative-operator","error":"kubernetes version \"1.25.16-eks-2d5f260\" is not compatible, need at least \"1.26.0-0\" (this can be overridden with the env var \"KUBERNETES_MIN_VERSION\")","stacktrace":"knative.dev/pkg/injection/sharedmain.CheckK8sClientMinimumVersionOrDie\n\t/root/parts/operator/build/vendor/knative.dev/pkg/injection/sharedmain/main.go:386\nknative.dev/pkg/injection/sharedmain.MainWithConfig\n\t/root/parts/operator/build/vendor/knative.dev/pkg/injection/sharedmain/main.go:256\nknative.dev/pkg/injection/sharedmain.MainWithContext\n\t/root/parts/operator/build/vendor/knative.dev/pkg/injection/sharedmain/main.go:210\nknative.dev/pkg/injection/sharedmain.Main\n\t/root/parts/operator/build/vendor/knative.dev/pkg/injection/sharedmain/main.go:140\nmain.main\n\t/root/parts/operator/build/cmd/operator/main.go:26\nruntime.main\n\t/snap/go/10335/src/runtime/proc.go:250"}
Discussed with the team, we should evaluate what is the expected behaviour of the upstream controller when it logs a SEVERITY message? In this case, we 'll be able to know better if this is something that we need pebble or charm to handle.
I tried to look into the behaviour of the upstream images.
The following are the case in the upstream image:
We see the same logs on the upstream knative-operator Deployment, when we use an incompatible version of K8s
The container crashes and the Pod goes to Error state
kubectl get pods -n knative-operator knative-operator-7b5d6b545f-4hk5c
NAME READY STATUS RESTARTS AGE
knative-operator-7b5d6b545f-4hk5c 0/1 CrashLoopBackOff 6 (94s ago) 7m28s
And the logs are:
kubectl logs -n knative-operator knative-operator-7b5d6b545f-4hk5c
2025/01/30 10:45:48 Registering 2 clients
2025/01/30 10:45:48 Registering 3 informer factories
2025/01/30 10:45:48 Registering 3 informers
2025/01/30 10:45:48 Registering 2 controllers
{"severity":"INFO","timestamp":"2025-01-30T10:45:48.884580007Z","logger":"knative-operator","caller":"profiling/server.go:65","message":"Profiling enabled: false","commit":"4959713-dirty","knative.dev/pod":"knative-operator-7b5d6b545f-4hk5c"}
{"severity":"EMERGENCY","timestamp":"2025-01-30T10:45:48.885154491Z","logger":"knative-operator","caller":"sharedmain/main.go:390","message":"Version check failed","commit":"4959713-dirty","knative.dev/pod":"knative-operator-7b5d6b545f-4hk5c","error":"kubernetes version \"1.25.16\" is not compatible, need at least \"1.30.0-0\" (this can be overridden with the env var \"KUBERNETES_MIN_VERSION\")","stacktrace":"knative.dev/pkg/injection/sharedmain.CheckK8sClientMinimumVersionOrDie\n\tknative.dev/pkg@v0.0.0-20250117084104-c43477f0052b/injection/sharedmain/main.go:390\nknative.dev/pkg/injection/sharedmain.MainWithConfig\n\tknative.dev/pkg@v0.0.0-20250117084104-c43477f0052b/injection/sharedmain/main.go:255\nknative.dev/pkg/injection/sharedmain.MainWithContext\n\tknative.dev/pkg@v0.0.0-20250117084104-c43477f0052b/injection/sharedmain/main.go:209\nknative.dev/pkg/injection/sharedmain.Main\n\tknative.dev/pkg@v0.0.0-20250117084104-c43477f0052b/injection/sharedmain/main.go:140\nmain.main\n\tknative.dev/operator/cmd/operator/main.go:26\nruntime.main\n\truntime/proc.go:272"}
Tested with 3.6 and it looks like the service keeps restarting every 30 seconds (the restart issue was fixed in 3.6.1). What I 'd suggest here would be to add a health check to ensure the service is up and running and leverage PebbleCheckFailedEvent to put the charm in Error state.
Activity
syncronize-issues-to-jira commentedon Jan 28, 2025
Thank you for reporting your feedback to us!
The internal ticket has been created: https://warthogs.atlassian.net/browse/KF-6794.
orfeas-k commentedon Jan 29, 2025
Discussed with the team, we should evaluate what is the expected behaviour of the upstream controller when it logs a
SEVERITYmessage? In this case, we 'll be able to know better if this is something that we need pebble or charm to handle.kimwnasptd commentedon Jan 30, 2025
I tried to look into the behaviour of the upstream images.
The following are the case in the upstream image:
knative-operatorDeployment, when we use an incompatible version of K8sErrorstateAnd the logs are:
kubectl logs -n knative-operator knative-operator-7b5d6b545f-4hk5c 2025/01/30 10:45:48 Registering 2 clients 2025/01/30 10:45:48 Registering 3 informer factories 2025/01/30 10:45:48 Registering 3 informers 2025/01/30 10:45:48 Registering 2 controllers {"severity":"INFO","timestamp":"2025-01-30T10:45:48.884580007Z","logger":"knative-operator","caller":"profiling/server.go:65","message":"Profiling enabled: false","commit":"4959713-dirty","knative.dev/pod":"knative-operator-7b5d6b545f-4hk5c"} {"severity":"EMERGENCY","timestamp":"2025-01-30T10:45:48.885154491Z","logger":"knative-operator","caller":"sharedmain/main.go:390","message":"Version check failed","commit":"4959713-dirty","knative.dev/pod":"knative-operator-7b5d6b545f-4hk5c","error":"kubernetes version \"1.25.16\" is not compatible, need at least \"1.30.0-0\" (this can be overridden with the env var \"KUBERNETES_MIN_VERSION\")","stacktrace":"knative.dev/pkg/injection/sharedmain.CheckK8sClientMinimumVersionOrDie\n\tknative.dev/pkg@v0.0.0-20250117084104-c43477f0052b/injection/sharedmain/main.go:390\nknative.dev/pkg/injection/sharedmain.MainWithConfig\n\tknative.dev/pkg@v0.0.0-20250117084104-c43477f0052b/injection/sharedmain/main.go:255\nknative.dev/pkg/injection/sharedmain.MainWithContext\n\tknative.dev/pkg@v0.0.0-20250117084104-c43477f0052b/injection/sharedmain/main.go:209\nknative.dev/pkg/injection/sharedmain.Main\n\tknative.dev/pkg@v0.0.0-20250117084104-c43477f0052b/injection/sharedmain/main.go:140\nmain.main\n\tknative.dev/operator/cmd/operator/main.go:26\nruntime.main\n\truntime/proc.go:272"}kimwnasptd commentedon Jan 30, 2025
We can reproduce the issue with the following:
kimwnasptd commentedon Jan 30, 2025
In the charm, I see that the process fails and Pebble never starts it again. Most probably because it failed in less that 1 second
orfeas-k commentedon Feb 13, 2025
Tested with 3.6 and it looks like the service keeps restarting every 30 seconds (the restart issue was fixed in 3.6.1). What I 'd suggest here would be to add a health check to ensure the service is up and running and leverage PebbleCheckFailedEvent to put the charm in Error state.