feat: add aws for omni with manifests

[rothgar]

Templates configuration and requires an AWS infrastructure provider.

[Copilot]

Pull request overview

Adds a new examples/omni/aws/ “Omni on AWS” example that provisions a Talos-based Kubernetes cluster via Omni using the community AWS infra provider, and installs an EKS-like addon set via Omni Manifest Sync.

Changes:

• Introduces an AWS Omni cluster template (cluster.yaml) plus MachineClass templates and Talos patches for control-plane/worker nodes.
• Adds a rendered manifests/ bundle for core AWS/Kubernetes controllers (CNI, CCM, CSI, autoscaler, etc.) intended to be synced declaratively by Omni.
• Documents prerequisites, AWS setup, and regeneration instructions in a new README.

Reviewed changes

Copilot reviewed 17 out of 18 changed files in this pull request and generated 8 comments.

Show a summary per file

File	Description
examples/omni/aws/README.md	End-to-end instructions for deploying the AWS example and regenerating manifests.
examples/omni/aws/cluster.yaml	Omni cluster template wiring Talos/Kubernetes versions, patches, and manifest sync entries.
examples/omni/aws/aws-controlplane.yaml	MachineClass template for AWS control-plane nodes (templated via envsubst).
examples/omni/aws/aws-worker.yaml	MachineClass template for AWS worker nodes (templated via envsubst).
examples/omni/aws/machineconfig.yaml	SideroLink join configuration template baked into the Talos AMI/user-data.
examples/omni/aws/.gitignore	Prevents rendered outputs and .envrc from being committed.
examples/omni/aws/patches/cluster.yaml	Cluster-wide Talos patch disabling flannel and configuring ECR credential provider + external CCM.
examples/omni/aws/patches/controlplane.yaml	Control-plane Talos patch (kubespan off, kubelet settings).
examples/omni/aws/patches/worker.yaml	Worker Talos patch (kubespan off, kubelet settings).
examples/omni/aws/manifests/vpc-cni.yaml	Rendered AWS VPC CNI resources to replace flannel.
examples/omni/aws/manifests/ccm.yaml	Rendered AWS Cloud Controller Manager manifest.
examples/omni/aws/manifests/ebs-csi.yaml	Rendered AWS EBS CSI driver manifests.
examples/omni/aws/manifests/snapshot-controller.yaml	Rendered VolumeSnapshot CRDs/controller bundle.
examples/omni/aws/manifests/storageclass-gp3.yaml	Default encrypted gp3 StorageClass.
examples/omni/aws/manifests/lb-controller.yaml	Rendered AWS Load Balancer Controller bundle.
examples/omni/aws/manifests/metrics-server.yaml	Rendered metrics-server deployment/APIService bundle.
examples/omni/aws/manifests/external-dns.yaml	Rendered external-dns deployment configured for AWS.
examples/omni/aws/manifests/cluster-autoscaler.yaml	Rendered cluster-autoscaler deployment configured for AWS ASG discovery.

Suppressed comments (3)

examples/omni/aws/README.md:22

• The "What you get" table says metrics-server comes from a release YAML, but manifests/metrics-server.yaml is Helm-rendered (it contains # Source: metrics-server/templates/...). The table should match the actual artifact source so regeneration steps are accurate.

| `cluster-autoscaler` | `cluster-autoscaler` Helm chart | Scales worker MachineSets on demand |
| `metrics-server` | `metrics-server` release YAML | `kubectl top` and HPA metrics |

examples/omni/aws/README.md:214

• manifests/vpc-cni.yaml appears to be Helm-rendered, but the regeneration recipe downloads the release YAML via curl. Regenerating via curl will produce a different file (and likely different defaults) than what’s committed here.

# vpc-cni — pin to the desired release
curl -sL https://github.com/aws/amazon-vpc-cni-k8s/releases/download/v1.19.5/aws-k8s-cni.yaml \
  > manifests/vpc-cni.yaml

examples/omni/aws/README.md:237

• manifests/metrics-server.yaml is Helm-rendered, but the regeneration recipe uses curl to download components.yaml. That will not reproduce the committed manifest structure and can lead to drift.

# metrics-server
curl -sL https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml \
  > manifests/metrics-server.yaml

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Iheanacho-ai]

@rothgar

i used claude to review this PR, and this is the output:

1. Single control-plane node (ControlPlane.size: 1) — for an example explicitly framed as "EKS-like," a 1-node CP has no HA and is a single point of failure. Worth at least a callout in the README that this is a
   minimal/dev topology, or bumping to 3 for anything resembling a real EKS-equivalent.
2. metrics-server runs with --kubelet-insecure-tls and insecureSkipTLSVerify: true (manifests/metrics-server.yaml, lines ~4841/4893) — disables kubelet TLS verification. Common in quickstart charts, but since
   this repo positions itself as a real infra example, a one-line security note (or a pointer to configuring kubelet serving certs properly) would be appropriate.
3. Region/account coupling isn't validated at render time — vpc-cni.yaml's ECR image references (602401143452.dkr.ecr.us-east-2.amazonaws.com/...) and lb-controller.yaml's --aws-region=us-east-2 flag are
   hardcoded and not part of the envsubst templating pass, unlike the MachineClass/machineconfig files. The README documents this clearly, but it's an inconsistency in the example's "templates use ${VAR},
   everything else needs manual edits" model — someone following only the "Render templates" section could deploy successfully to us-east-1 with a broken CNI image pull. Consider either templating these too, or
   making the inconsistency more prominent (e.g., a preflight check script).
4. Version currency: kubernetes.version: v1.36.2 and talos.version: v1.13.7 in cluster.yaml — worth confirming these are real, currently-supported releases at merge time (and that the Talos/K8s combination is
   within Talos's supported skew) since example repos tend to bit-rot quickly if versions are wrong from day one.
5. cluster-autoscaler container has empty resources: {} (line 980) and other addon containers likely inherit their chart defaults — not a blocker for an example, but since CP nodes here run every AWS controller
   (per the README's design), unbounded/undefined resource requests on t3.medium control-plane instances could lead to noisy-neighbor problems between etcd/kube-apiserver and the addon pods. A short note
   recommending a larger instance type or resource requests would help users avoid this by trial and error.
6. No CI/lint validation observed for the YAML in this PR (e.g., kubeconform/yamllint over the manifests, or a dry-run of omnictl cluster template validate) — reasonable for a docs-heavy example directory, but
   if the repo has such tooling for other examples/, confirm it also covers this one.

now claude is probably wrong but maybe you'd like to read through it

[rothgar]

I think I addressed all of the points in this latest commit