Codecov Report

Attention: 23 lines in your changes are missing coverage. Please review.

Comparison is base (02bf903) 45.75% compared to head (582d59f) 45.71%.
Report is 1689 commits behind head on master.

❗ Current head 582d59f differs from pull request most recent head 91d373f. Consider uploading reports for the commit 91d373f to get more accurate results

@@            Coverage Diff             @@
##           master    #9496      +/-   ##
==========================================
- Coverage   45.75%   45.71%   -0.04%     
==========================================
  Files         236      236              
  Lines       28527    28550      +23     
==========================================
  Hits        13053    13053              
- Misses      13669    13691      +22     
- Partials     1805     1806       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

This branch does not contain the latest commit. we have implemented the feature in our test env.
I can continue to work on it if this feature is considered @crenshaw-dev

same issue: #7887

I think this change is reasonable. Added a couple more reviewers.

any udpate, we need this feature, all of our k8s behind a proxy

any update?

any chance to merge at v2.5 @crenshaw-dev

Apologies for missing your pings @jinnjwu! @ls0f are you still able to push this PR? Looks like it needs a make codegen.

I'm definitely going to need some external help on the review. I'm going to add this PR to the topics for the next contributor experience meeting so I can get help.

yep, i can push this PR @crenshaw-dev

@ls0f can you run codegen and push?

I'm also curious if you have reproduction/test steps handy? I don't tinker with proxies often, so if you have particular tools or steps you've used, that would help me test. :-)

any update?

https://github.com/zhang-xuebin/argo-helm/tree/host-on-gke is an example to let Argo manage private GKE clusters. It doesn't matter if the cluster is public or private. it works for Argo 2.4.1+.

any update?

https://github.com/zhang-xuebin/argo-helm/tree/host-on-gke is an example to let Argo manage private GKE clusters. It doesn't matter if the cluster is public or private. it works for Argo 2.4.1+.

looks like we are talking different scenaio.

@ls0f can you run codegen and push?

I'm also curious if you have reproduction/test steps handy? I don't tinker with proxies often, so if you have particular tools or steps you've used, that would help me test. :-)

@ls0f would you help it？

@ls0f any chance for pr?

@crenshaw-dev The code is updated.
The related PR should be merge first. argoproj/gitops-engine#466

@ls0f one question， Does it support multi proxy. our each k8s cluster has different proxy

@ls0f one question， Does it support multi proxy. our each k8s cluster has different proxy

every cluster manged by argo can specify proxy

@crenshaw-dev The code is updated. The related PR should be merge first. argoproj/gitops-engine#466

@crenshaw-dev would you help it?

hope it will be ready in 2.5 . all of our k8s cluster behind a proxy.

This patch branch has been running in our pro env for half a year and no problems have been found.

if this argoproj/gitops-engine#466 is merged, i will update this PR

Hello @ls0f, now it is :)

Hi,

As i had the doubt about to miss a thing, i continued to search and yes, i missed a thing ^^, it was finally about this commit and the make codegen step ! So guys, if you build your own for testing purposes, take care to check all the steps !

So, i confirm that it now works as expected ! i mean creating a cluster through a secret as well as creating the cluster through the argocd add cluster --proxy-url command, and in both case, i am able to see the field on this command output :

argocd cluster list -o json | jq .[].config.proxyUrl

the link seems not accessible.

Hi,
As i had the doubt about to miss a thing, i continued to search and yes, i missed a thing ^^, it was finally about this commit and the make codegen step ! So guys, if you build your own for testing purposes, take care to check all the steps !
So, i confirm that it now works as expected ! i mean creating a cluster through a secret as well as creating the cluster through the argocd add cluster --proxy-url command, and in both case, i am able to see the field on this command output :
argocd cluster list -o json | jq .[].config.proxyUrl

the link seems not accessible.

Hello, i fixed it, here is the link : 582d59f

@ls0f hi,any updates on this feature?

I have been using this change about a half year without any issues.

Is there a timeline to get this merged? We need to rebuild argocd/run this as a local patch right now to be able to manage some of our deployments.

@ls0f are you still willing to push this in?

Sorry for the long delay in responding, but I haven't had time to work on this lately, is there anyone willing to develop this feature. @dje4om @manuelstein

I found a way to make workaround

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: argocd

secretGenerator:
  - name: cluster-xxx-xxx
    files:
      - config=secrets/config.json
      - name=secrets/name
      - server=secrets/server

generatorOptions:
  disableNameSuffixHash: true
  labels:
    type: generated
    argocd.argoproj.io/secret-type: cluster
  annotations:
    note: generated
    managed-by: argocd.argoproj.io

So this makes sense

Is there much remaining to do on this? Seems like a pretty critical feature?

any news? Would be super cool!

any movement on this?

@crenshaw-dev what's the best way to get this merged? We've been using a patched ArgoCD for 6 months with this and working great.

The workaround of @qixiaobo did not work for us. We were also unable to patch and compile argocd ourselves, so we got creative. We came up with a different solution. We did it with a deployment of a kubectl container which generates kubeconfig for EKS and runs this command:

kubectl proxy --port=your-port --address=0.0.0.0 --accept-hosts='.*' --api-prefix=/

Then the ArgoCD cluster secret points to the service of the pod with http (https, wouldn't work). We use cilium, so traffic is still encrypted.

Don't know about the stability of the solution yet. We just build a cronjob to redeploy it every hour...

This is also "insecure", since it has no authentication, so any pod could run kubectl commands on the target cluster. Our cluster is not easily reachable, so it should be fine, but still...

We would greatly appreciate it if the proper solution of this pull-request provides could finally be merged, because we don't want to work with janky workarounds. This was pretty frustrating, since we have no good alternative in an on-premise environment that needs to communicate with an external cluster.

Hey together,
i would offer to write some test to get this merged.
From my understanding the e2e test currently require and run only on one cluster and the process of adding a cluster is also just tested with the one instance, which makes a test with 2 clusters + http proxy a bit hard. Should this behaviour be changed or did you intend other kind of tests for this feature?
cc. @crenshaw-dev

We need this too, I guess we'll have to compile our own...

Hey together, i would offer to write some test to get this merged. From my understanding the e2e test currently require and run only on one cluster and the process of adding a cluster is also just tested with the one instance, which makes a test with 2 clusters + http proxy a bit hard. Should this behaviour be changed or did you intend other kind of tests for this feature? cc. @crenshaw-dev

#push a hint on the test requirement would be great to be able to contribute the tests needed for a merge @crenshaw-dev

Reopened PR here #20374
Will work on comments and tests.

Huge thanks to @ls0f for initial work. Really appreciate it

Merged #20374