GitHub user sshiv012 added a comment to the discussion: Approach: unifying AWS (EKS) and on-premise Kubernetes deployment under bin/k8s — Helm-only vs eksctl vs Terraform
I'm still getting familiar with the AWS side of the deployment, but here's what stood out reading through bin/k8s. @chenlica standard eksctl does not support on-prem. It's the **AWS-only** CLI for provisioning Amazon EKS clusters as @aicam mentioned. What should be common for both flavors of deployment is Helm. Not sure if we use [EKS ANYWHERE](https://anywhere.eks.amazonaws.com/) or just barebones k8s on prem, if its eks anywhere then we can maybe reuse it. One thing I wasn't sure was fully captured in the framing: it might help to separate the application chart from the substrate, because as far as I can tell only the substrate is really in question. On the chart side, texera-helm already looks closer to cloud-agnostic than I expected, the persistence templates only create hostPath PVs when the storage class is local-path (minio-persistence.yaml, postgresql-persistence.yaml), so other classes fall through to dynamic provisioning, and LakeFS already targets blockstore.type: s3 rather than MinIO-specific APIs. If I'm reading that right, moving to EBS + real S3 is mostly a values change, not a template change. That leaves the substrate i.e cluster, node pools, IRSA, S3, EIP, DNS, cert-manager as the only layer the eksctl-vs-Terraform question is actually about. On eksctl: I agree it's the right tool for the cluster layer (node groups, Pod Identity). My one hesitation is that it doesn't get us all the way to "one path to reproduce the deployment" — as @aicam noted, S3/EIP/DNS are out of scpe for it, so if those stay manual we may partly recreate the undocumented-setup problem we're trying to solve. That's where Terraform's plan is appealing: it warns before it deletes a data bucket or changes IAM, detects drift if someone clicks around in the console, and the code doubles as documentation. But I think it really comes down to who owns the deployment: - Project maintainers (keep-it-simple, rotating contributors): eksctl + Helm + a committed bootstrap script is probably the lighter path. - General adopters (integrating into a real org/projects): Terraform is the better thing to offer — portable, composable into existing IaC, self-documenting, and usually the tool they already speak. So maybe it isn't either/or. We can consider (eventually) shipping a thin, optional Terraform module (or even just documented .tf for S3/IAM/IRSA plus a reference eksctl cluster config), so maintainers stay on the simple path while adopters get something that drops into their stack. GitHub link: https://github.com/apache/texera/discussions/5641#discussioncomment-17301158 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
