What happened?
Summary
Init Container Service Account (SA) token Secrets created by the operator remain empty, preventing init containers from authenticating with the Kubernetes API server. This is caused by using the deprecated automatic token generation mechanism that was disabled by default in Kubernetes 1.24 and feature gate removed by 1.28 apparently. This doesn't quite make sense though as start ordering end to end tests are passing with k3s 1.28. Seems likely to me that various distrobutions might have been keeping this functionality around. Regardless we should update the the SA token setup.
Current Behavior
- The operator creates a Secret of type
kubernetes.io/service-account-token with the previousluy appropriate annotation for auto populating it
- The Secret remains empty - no
token, ca.crt, or namespace data is populated
- Init containers attempt to mount this empty Secret at
/var/run/secrets/kubernetes.io/serviceaccount
- Init containers fail to authenticate with the Kubernetes API server due to missing credentials
What happened?
Summary
Init Container Service Account (SA) token Secrets created by the operator remain empty, preventing init containers from authenticating with the Kubernetes API server. This is caused by using the deprecated automatic token generation mechanism that was disabled by default in Kubernetes 1.24 and feature gate removed by 1.28 apparently. This doesn't quite make sense though as start ordering end to end tests are passing with k3s 1.28. Seems likely to me that various distrobutions might have been keeping this functionality around. Regardless we should update the the SA token setup.
Current Behavior
kubernetes.io/service-account-tokenwith the previousluy appropriate annotation for auto populating ittoken,ca.crt, ornamespacedata is populated/var/run/secrets/kubernetes.io/serviceaccount