-
Notifications
You must be signed in to change notification settings - Fork 5.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to add 1.24.0 Kubernetes cluster #9422
Comments
This may be related to changes for serviceaccount token in 1.24:
The error is coming from here in code: argo-cd/util/clusterauth/clusterauth.go Line 244 in 8cd7d47
|
So to support 1.24 @danielhelfand : Do you think that argocd to create a secret and then annotate with argocd-manager service account? I guess not. |
@danielhelfand What I tried on my two clusters supports your comment: On the 1.24.0 cluster:
On the 1.23.6 cluster:
|
I think the goal should be to support the TokenRequest API, but that will be a bigger change. The short term solution may be to have the token controller populate a secret created when adding clusters. I haven't weighed the pros/cons of this quite yet. |
Just want to share my (hacky) work around on this.
With that, to fix this by the 'short term solution', we may need to not only create a service account token Secret, but also add the secret to the |
In reviewing this a bit further, I am wondering if the clusterauth package's GetBearerToken function can be altered to always create the secret, bind it to the serviceaccount, and wait for the token controller to appropriately populate the secret. The downside of this is creating an additional token in previous k8s versions. |
It turns out the TokenRequest API is pretty straight forward to use. Here's a hacky WIP commit to show what it looks like. I have tried both approaches (creating secret and using token request API), and the TokenRequest API seems to resolve the issue. Still need to work through the best approach for maintaining backwards compatibility with the Secret approach for older versions of k8s. |
Adding in a research doc I have been throwing together. |
Also i was wondering, that other service account eg: argocd-application-controller will not have secret mounted, so how argocd controller is able to do api call to kube-api server without token and ca.crt |
I do confirm . Issue appeared in OCP 4.11 which is based on kubernetes 1.24 So this means that parsing the token of an SA has been changed since k8s 1.24 resolutionns=kube-system
sa_token=$(kubectl -n $ns get secret | grep argocd-manager-token | awk '{print $1}')
kubectl -n $ns patch sa argocd-manager -p '{"secrets": [{"name": "'"${sa_token}"'"}]}'
# then run "argocd cluster add" command again |
Hello! Please could someone let me know what version of Argocd we are looking at with the fix for this issue? I am presuming the only work around for now is to go with what @waltforme has suggested above? Thanks! |
Currently we are using argocd 2.3.1 and are facing same issue. Which version of Argocd is suitable to add and register 1.24 Kubernetes cluster? Thanks |
+1 on this, has anyone fixed this? |
The fix was released in 2.3.7 and 2.4.0 onward. |
can confirm, |
i am using 2.6.1 argocd version but still issue is there |
I am using 2.7.1 but same issue there, Is there any workaround for this ? argocd: v2.7.1+5e54351.dirty argocd-server: v2.7.1+5e54351.dirty |
@ravindraprasad85 workaround already shared above |
Make sure your client is updated also not just your argocd server
On Sun, Jun 18, 2023 at 1:26 PM abdennour ***@***.***> wrote:
I am using 2.7.1 but same issue there, Is there any workaround for this ?
@ravindraprasad85 <https://github.com/ravindraprasad85> workaround
already shared above
—
Reply to this email directly, view it on GitHub
<#9422 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/APQGOA6GC4USB634VP4DPMLXL5I4PANCNFSM5WCCKCRA>
.
You are receiving this because you commented.Message ID:
***@***.***>
--
*Dejo Oyelese*
*Helcim - Senior DevOps Developer*
Email: ***@***.***
Web: https://www.helcim.com
Calgary Office: Suite 400 - 440 2 Avenue SW, Calgary, AB T2P 5E9.
Seattle Office: Suite 4200 - 701 5th Avenue, Seattle, WA 98104
<https://helcim.com/emailfooter/index.php>
|
Hey @crenshaw-dev we're facing this issue even in Is the fix not stable? |
I experienced this issue on Argo CD v2.7.2 The workaround was as described above in two separate posts. For completeness here is my solution. My context was for local testing multiple clusters
Steps to solve Create a kind cluster with an kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
name: dev-cluster
networking:
# WARNING: It is _strongly_ recommended that you keep this the default
# (127.0.0.1) for security reasons. However it is possible to change this.
apiServerAddress: "<your-local-ip>"
# By default the API server listens on a random open port.
# You may choose a specific port but probably don't need to in most cases.
# Using a random port makes it easier to spin up multiple clusters.
apiServerPort: 8443
Run the argocd command to add a cluster
It will fail with a timeout. That's when have to switch to the kind dev cluster context and create the additional secret for the service account and associate the In your dev-cluster context
Create service account secret apiVersion: v1
kind: Secret
type: kubernetes.io/service-account-token
metadata:
annotations:
kubernetes.io/service-account.name: argocd-manager
name: argocd-manager-token
namespace: kube-system Add secret to service account apiVersion: v1
kind: ServiceAccount
metadata:
creationTimestamp: "2023-10-10T15:02:41Z"
name: argocd-manager
namespace: kube-system
resourceVersion: "1526"
uid: 89721095-63b2-42d0-8dd9-29c2f9fe0379
secrets:
- name: argocd-manager-token |
Same here! Try workaround |
Checklist:
argocd version
.Describe the bug
When I tried to add a freshly created v1.24.0 Kubernetes cluster to argocd, I got timeout (see the Logs for details). The cluster can't be added.
Then I created a fresh v1.23.6 cluster, I can add it successfully.
I'm using kubeadm to create my Kubernetes clusters. The only difference between the two creation is one single parameter passed to
kubeadm init
, which is--kubernetes-version
.Version
Logs
The text was updated successfully, but these errors were encountered: