Consider using ArgoCD to manage cluster state instead of kubectl

[upodroid]

We are deploying rather complicated applications to the prow-build clusters and would benefit greatly from using ArgoCD to deploy apps that are bundled as Helm charts instead of manually generating a yaml file from Helm chart.

I already do this today for the prow clusters that I managed for knative:

• Switch to using ArgoCD to deploy cluster manifests instead of kubectl knative/test-infra#3363 argocd vs kubectl
• typical application deployment: Enable ArgoCD for managing cluster state knative/test-infra#3399
• grafana stack: Deploy Grafana knative/test-infra#3500

A list of apps that we plan on running on K8s clusters:

• ESO: Deploy ESO on EKS k8s.io#4930
• Kyverno
• Grafana
• and more

/sig testing
/sig k8s-infra

[BenTheElder]

We are deploying rather complicated applications to the prow-build clusters and would benefit greatly from using ArgoCD to deploy apps that are bundled as Helm charts instead of manually generating a yaml file from Helm chart.

Eh, I greatly prefer the visibility of seeing exactly what manifests we're deploying checked into the repo and the ability to git revert those versus depending on external charts. You will find that the Kubernetes organization very rarely has anything helm related.

If we need to template things, we prefer declarative patches (e.g. kustomize).

Lack of prune is a valid issue, though rarely encountered. Moving to plain kubectl vs rules_k8s is a recent move that has not addressed this.

Kyverno

I'm not sold that we should be deploying this in k8s prow yet tbh. Mutating admission webhooks should generally be avoided and are not the only way we can accomplish using mirrors.

EKS supports configuring containerd AFAIK we can relatively easily inject mirror config at the node level instead, which is generally a safer approach.

Currently aside from prow itself we depend on Grafana and ESO in the services cluster. These relatively rarely require updates.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.