r/ArgoCD

▲ 40 r/ArgoCD+14 crossposts

I added dedicated AWS / EKS support to KubeShark.

Mini recap:

KubeShark is my Kubernetes skill for Claude Code and Codex.

It helps AI agents generate, review, and refactor Kubernetes manifests without falling into the usual LLM traps: missing security contexts, deprecated API versions, broken selectors, wildcard RBAC, unsafe probes, missing resource requests, and rollout configs that look okay but fail under real traffic.

The important part is that KubeShark is failure-mode-first. It does not just tell the model “write good Kubernetes”. It forces the model to reason about what can go wrong before it generates YAML, and then return validation and rollback guidance as part of the answer.

That matters a lot with Kubernetes, because many bad manifests are accepted by the API server and only fail later at runtime.

Repo: https://github.com/LukasNiessen/kubernetes-skill

---

Now what’s new:

KubeShark now has special dedicated AWS / EKS support.

When the task involves EKS, AWS, IRSA, EKS Pod Identity, AWS Load Balancer Controller, EBS/EFS CSI, AWS VPC CNI, or Karpenter, KubeShark switches into EKS-aware guidance.

That matters because EKS is “just Kubernetes” until identity, load balancing, storage, pod networking, and node provisioning enter the picture.

Common LLM mistakes include:

  • putting AWS access keys into Kubernetes Secrets
  • mixing IRSA and EKS Pod Identity assumptions
  • using nginx annotations with AWS Load Balancer Controller
  • treating EBS like ReadWriteMany storage
  • recommending Karpenter while omitting resource requests
  • assuming NetworkPolicy works without checking the CNI/policy engine

Example guidance KubeShark now keeps in mind:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: app
  namespace: payments
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/payments-app

It also knows that EBS is usually RWO and zone-sensitive, EFS is the RWX option, and Karpenter depends heavily on good workload requests.

So instead of generic Kubernetes advice, you get EKS-aware manifest generation and review.

u/trolleid — 5 days ago
▲ 70 r/ArgoCD+1 crossposts

Helm charts with gitops, what's the best approach?

what is the standard way of dealing with helm charts in a gitops like scenario. do people use the CLI + flags, or CLI + values.yaml or any other way that i am not aware of. Is there a way to track stuff like the helm chart metadata + values.yaml in git and have ArgoCD sync it automatically as this seems a lot cleaner. my purpose for asking is only to learn what the best practices are, I'm hosting a single k3s node on an old laptop and wanted to set up kube-prometheus-stack. kindly forgive any gaps in my knowledge :p

reddit.com
u/Mr_infiknight — 7 days ago
▲ 8 r/ArgoCD

Multi-source Application to deploy two helm chart with CRDs and chart with controller

I'm looking the best method to deploy an application that consists of chart with CRDs and chart with Controller deployment in multi-cluster environment. Of course CRDs should be installed/updated first.

Karpenter is one of such examples, has two charts.

I'm evaluating multiple possibilities.
ApplicationSet is the best option for me and already have 99% of deployments using "smart" ApplicationSets.
I don't like App-of-Apps approach with Application health-checks for sync waves. I can create ApplicationSet to generate App-of-Apps but then I still have to create two Apps manually.

I even prefer to just create 2 distinct AppSets. Workflow: Manually Sync CRDs App for a cluster, wait for it, then manually Sync Controller App for the same cluster.

Is it possible to have multi-source Application with installation of two helm charts?
How are they rendered? What if I apply sync-wave annotation to CRDs resources. Are they then combined with the second charts resources and applied in proper order?
Or ArgoCD still would treat resources from two helm charts separately without waiting when first chart finishes installation? That way it will be easy to create a single AppSet to generate such Apps.

Maybe there is easier approach and I'm overthinking?

reddit.com
u/i_Den — 6 days ago
▲ 19 r/ArgoCD

GitOps and Secrets

When discussing secrets management in Argo CD, there are two important questions every team should ask:

  • Should changing a secret require an Argo CD sync?
  • Should your secrets solution be coupled to Argo CD?

The answer to both is: definitely not.

Tomorrow on Argo Unpacked we’re having an open discussion about secrets management best practices in Argo CD: (https://www.linkedin.com/events/7454090384584118272)

  • different approaches and tradeoffs
  • decoupling secrets from deployment workflows
  • operational considerations
  • what works well in real environments (and what usually doesn’t)

Curious how others here think about this too:
How are you handling secrets with Argo CD today?

reddit.com
u/Physical_Growth7566 — 12 days ago
▲ 22 r/ArgoCD

TUI for ArgoCD and Argo rollouts? argonaut can do both ;)

Thanks to a recent community contribution, it is now possible to manage not just Argo CD apps but also Argo Rollouts in argonaut!

Go check it out: https://github.com/darksworm/argonaut

u/darksworm — 12 days ago