EKS modules: rvn-eks composite, selectable add-ons, services, and observability

[mabadir]

Summary

The module-side half of EKS deployment support (pairs with ravionhq/flightcontrol#6973).

Cluster and add-ons

• compute/eks composite with the rvn-eks module definition
• Selectable add-ons stack (compute/eks/addons): Karpenter (controller + default node pool), EBS CSI, AWS Load Balancer Controller (installed automatically with any shared load balancer), shared load balancers
• Runner authenticates to the cluster via EKS access entries: self-registered Terraform runner entry plus an assumable Ravion Runner role with cluster-admin; orphaned Helm releases adopted via upgrade_install
• Ravion Beacon agent shipped through the add-ons chart, defaulting to the public a8z1i1r2 registry (rvn-eks-addons 0.6.1)

Services

• EKS service modules with container image builds

Observability

• Workload metrics: Amazon Managed Prometheus + OTel collector + Grafana role in rvn-eks-addons
• Logs: in-cluster Loki on S3 (replacing Container Insights), covered in tests, docs, and the module definition
• UI wiring: workload and cluster metrics to AMP, logs to Loki

Greptile Summary

The PR adds a composite EKS platform, selectable cluster add-ons, AWS-side EKS workload infrastructure, reusable Helm charts, observability integrations, module definitions, and integration tests.

• Provisions EKS clusters, node capacity, runner access, and optional Karpenter, storage, load-balancing, secrets, metrics, logs, and Beacon components.
• Adds web, worker, and cron workload definitions with image builds and Helm deployments.
• Adds shared ALB target-group routing and chart-based Kubernetes workload resources.
• Adds chart CI and AWS/Terraform test coverage.

Confidence Score: 4/5

The target-group naming collision should be fixed before merging because two valid web workload names can make infrastructure creation fail.

Load-balanced workloads whose names share the retained 24-character prefix resolve to the same account-and-region target group name, while the workflow action pinning issue is independently non-blocking.

Files Needing Attention: compute/eks_service/locals.tf and .github/workflows/helm-charts.yml

Security Review

The new Helm workflow uses mutable action tags. Its permissions are limited to repository read access, but pinning these actions to full commit SHAs would prevent upstream tag movement from changing executed CI code.

Important Files Changed

Filename	Overview
compute/eks_service/locals.tf	Enables optional load balancing and derives target group names, but truncation can collide for workloads sharing a long prefix.
compute/eks_service/target_group.tf	Creates an IP-mode target group consumed by the chart's TargetGroupBinding.
compute/eks/addons/beacon.tf	Provisions Beacon credentials and deployment configuration; no changed-code blocking defect was established.
charts/rvn-eks-web/templates/targetgroupbinding.yaml	Renders one TargetGroupBinding per supplied target group ARN for pod-IP registration.
.github/workflows/helm-charts.yml	Adds chart lint/template CI with minimal permissions, but its action dependencies are referenced through mutable tags.
compute/eks/eks_cluster.tf	Composes the cluster module and forwards networking, authentication, encryption, add-on, and Pod Identity settings.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  Definition["Ravion EKS module definitions"] --> Cluster["compute/eks composite"]
  Cluster --> EKS["EKS control plane"]
  Cluster --> Nodes["System and optional node groups"]
  Cluster --> Addons["compute/eks/addons"]
  Addons --> Controllers["Karpenter, EBS CSI, LB controller, ESO"]
  Addons --> Observability["AMP, OTel, Loki, Alloy, Grafana"]
  Definition --> Service["compute/eks_service"]
  Service --> ECR["Optional ECR repository"]
  Service --> TG["ALB target group and listener rule"]
  Definition --> Charts["Web, worker, and cron Helm charts"]
  Charts --> Workloads["Kubernetes workloads"]
  Workloads --> TG

Loading

Prompt To Fix All With AI

### Issue 1
compute/eks_service/locals.tf:24
**Truncated target-group names collide**

When two load-balanced EKS workloads in the same account and region share the first 24 characters of their names, both resolve to the same target-group name, causing AWS to reject creation of the second target group because that name already exists.

### Issue 2
.github/workflows/helm-charts.yml:26-36
**Action tags remain mutable**

The new workflow references `actions/checkout`, `azure/setup-helm`, and `mikefarah/yq` through mutable tags, allowing upstream tag movement to change the code executed on the runner with access to the checked-out source and read-only repository token. Pin each action to a full commit SHA, matching the repository's existing workflows.

**How this was verified:** Every pre-existing workflow pins action references to full commit SHAs, while these three new references use tags.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

_{Reviews (1): Last reviewed commit: "Wire EKS workload and cluster UI metrics..." | Re-trigger Greptile}

Greptile also left 2 inline comments on this PR.

Context used (4)

• Knowledge Base — EKS Compute Platform
• Knowledge Base — Terraform Stack module and shared partials
• Knowledge Base — Networking modules: VPC, load balancers, DNS, security groups, EIPs
• Knowledge Base — Test Suite (test/)

[greptile-apps]

Truncated target-group names collide

When two load-balanced EKS workloads in the same account and region share the first 24 characters of their names, both resolve to the same target-group name, causing AWS to reject creation of the second target group because that name already exists.

Knowledge Base Used: Networking modules: VPC, load balancers, DNS, security groups, EIPs

Prompt To Fix With AI

This is a comment left during a code review.
Path: compute/eks_service/locals.tf
Line: 24

Comment:
**Truncated target-group names collide**

When two load-balanced EKS workloads in the same account and region share the first 24 characters of their names, both resolve to the same target-group name, causing AWS to reject creation of the second target group because that name already exists.

**Knowledge Base Used:** [Networking modules: VPC, load balancers, DNS, security groups, EIPs](https://app.greptile.com/flightcontrol/-/custom-context/knowledge-base/ravionhq/modules/-/docs/networking.md)

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[greptile-apps]

Action tags remain mutable

The new workflow references actions/checkout, azure/setup-helm, and mikefarah/yq through mutable tags, allowing upstream tag movement to change the code executed on the runner with access to the checked-out source and read-only repository token. Pin each action to a full commit SHA, matching the repository's existing workflows.

How this was verified: Every pre-existing workflow pins action references to full commit SHAs, while these three new references use tags.

Prompt To Fix With AI

This is a comment left during a code review.
Path: .github/workflows/helm-charts.yml
Line: 26-36

Comment:
**Action tags remain mutable**

The new workflow references `actions/checkout`, `azure/setup-helm`, and `mikefarah/yq` through mutable tags, allowing upstream tag movement to change the code executed on the runner with access to the checked-out source and read-only repository token. Pin each action to a full commit SHA, matching the repository's existing workflows.

**How this was verified:** Every pre-existing workflow pins action references to full commit SHAs, while these three new references use tags.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.