bcdurden
commented
5 months ago I wanted to provide some extra info after a colleague asked me to run a test.
It seems I did not realize there are two containers in the controller, rookie mistake. It seems the other container is the culprit, though the path to fixing it I am not sure.
the kube-rbac-proxy container throws a cli error when this crash happens. It seems that whatever image is being used here is either not the correct one or the version is wrong.
flag provided but not defined: -secure-listen-address
Usage of /manager:
-health-probe-bind-address string
The address the probe endpoint binds to. (default ":9440")
-kubeconfig string
Paths to a kubeconfig. Only required if out-of-cluster.
-leader-elect
Enable leader election for controller manager. Enabling this will ensure there is only one active controller manager.
-metrics-bind-address string
The address the metric endpoint binds to. (default ":8080")
-zap-devel
Development Mode defaults(encoder=consoleEncoder,logLevel=Debug,stackTraceLevel=Warn). Production Mode defaults(encoder=jsonEncoder,logLevel=Info,stackTraceLevel=Error) (default true)
-zap-encoder value
Zap log encoding (one of 'json' or 'console')
-zap-log-level value
Zap Level to configure the verbosity of logging. Can be one of 'debug', 'info', 'error', or any integer value > 0 which corresponds to custom debug levels of increasing verbosity
-zap-stacktrace-level value
Zap Level at and above which stacktraces are captured (one of 'info', 'error', 'panic').
-zap-time-encoding value
Zap time encoding (one of 'epoch', 'millis', 'nano', 'iso8601', 'rfc3339' or 'rfc3339nano'). Defaults to 'epoch'.Here are the args in the deployment:
- args:
- --secure-listen-address=0.0.0.0:8443
- --upstream=http://127.0.0.1:8080/
- --logtostderr=true
- --v=0I tried editing the args in place, but all of them cause an error of some sort and removing them altogether causes a conflict with the other container sharing the 8080 port:
2024-04-26T18:51:58Z INFO controller-runtime.metrics Metrics server is starting to listen {"addr": "127.0.0.1:8080"}
2024-04-26T18:51:58Z ERROR controller-runtime.metrics metrics server failed to listen. You may want to disable the metrics server or use another port if it is due to conflicts {"error": "error listening on 127.0.0.1:8080: listen tcp 127.0.0.1:8080: bind: address already in use"}
sigs.k8s.io/controller-runtime/pkg/metrics.NewListener
/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.15.1/pkg/metrics/listener.go:48
sigs.k8s.io/controller-runtime/pkg/manager.New
/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.15.1/pkg/manager/manager.go:464
main.main
/workspace/main.go:83
runtime.main
/usr/local/go/src/runtime/proc.go:250
2024-04-26T18:51:58Z ERROR setup unable to start manager {"error": "error listening on 127.0.0.1:8080: listen tcp 127.0.0.1:8080: bind: address already in use"}
main.main
/workspace/main.go:92
runtime.main
/usr/local/go/src/runtime/proc.go:250
belgaied2
What happened: When installing cluster-api resources on to the bootstrap KinD cluster, the resulting caphv-controller pod will crash-loop without showing any particular error.
What did you expect to happen: Expected to see a running cluster-api infrastructure in the bootstrap KinD cluster as shown in the README.
How to reproduce it: Follow the README as described.
Anything else you would like to add: Have tried on KinD latest and 1.26.3. Also have tried on K3D. vSphere provider works fine.
Environment:
/etc/os-release):Logs of caphv-controller