Open sl1pm4t opened 1 month ago
My current setup is based on the said components:
NAME NAMESPACE TYPE CURRENT VERSION NEXT VERSION
bootstrap-kubeadm capi-kubeadm-bootstrap-system BootstrapProvider v1.7.3 v1.7.4
control-plane-kamaji kamaji-system ControlPlaneProvider v0.10.1 Already up to date
control-plane-kubeadm capi-kubeadm-control-plane-system ControlPlaneProvider v1.7.3 v1.7.4
cluster-api capi-system CoreProvider v1.7.4 Already up to date
infrastructure-kubevirt capk-system InfrastructureProvider v0.1.8 Already up to date
My current clusters:
$: kubectl get clusters
NAME CLUSTERCLASS PHASE AGE VERSION
capi-quickstart Provisioned 4m22s
Retrieving the kubeconfig
seems fine to me:
$: clusterctl get kubeconfig capi-quickstart | wc -l
sigs.k8s.io/cluster-api
20
I suspect something is related to #92, it would be great if you could provide a detailed report on how to reproducing. Infrastructure providers are not important, here, since it's just a matter of how we replicate Cluster API resources.
This provider generates a kubeconfig secret with the name
<cluster>-admin-kubeconfig
, with the data keyssuper-admin.conf
etc. However, other providers create an admin levelkubeconfig
secret with the name:<cluster>-kubeconfig
with the kubeconfig stored in a data key namedvalue
. This is documented here: https://cluster-api.sigs.k8s.io/developer/architecture/controllers/cluster#secretsIt would be great if the kamaji provided matched the existing pattern, so external operators and tools could work seamlessly.
For example, after creating a Kamaji CAPI cluster, the
clusterctl get kubeconfig ...
command fails because the secret is not in the expected format.