eks-distro VS containers-roadmap

EKS Anywhere builds on the strengths of Amazon EKS Distro, the same open-source distribution of Kubernetes that is used by Amazon EKS on the cloud, thus fostering consistency and compatibility between clusters both on AWS as well as on-premises.

yes im aware of bmctl. however you dont have control over the kubernetes distro that's running.

is there anything similar to https://github.com/aws/eks-distro ?

EKS-A focuses on cluster management for HA environments. By default we use 3 etcd nodes, 2 control plane nodes, and 3 worker nodes. It uses cilium as the default CNI and Cluster API controllers for continual cluster state management. It has some optional configuration for a flux controller and OIDC authentication but it doesn't add default services or workloads. EKS-A also uses EKS Distro which is the open source Kubernetes distribution we run in hosted EKS.

Note: the platform flag is important if we are using a MacBook M1, since AWS Batch does not support ARM/Graviton yet.

You might try creating an issue at either https://github.com/aws/containers-roadmap or https://github.com/aws-cloudformation/cloudformation-coverage-roadmap

Naturally some integrations are out of your hand, AWS Fargate being one (https://github.com/aws/containers-roadmap/issues/1027). However, if you could get integrations up and running with the likes of Fargate, Fly.io, Render.com etc. That'd be amazing.

You do and that’s unfortunate even though it has been requested by the community :( https://github.com/aws/containers-roadmap/issues/78

This issue would solve this but its been open for a while.

There are plenty of vendor specific bugs, like no EBS in [EKS Fargate](https://github.com/aws/containers-roadmap/issues/1113), and settling a Kubernetes cluster on top of Bottlerocket and [EKS Anywhere](https://github.com/aws/eks-anywhere), on your own is somewhat impossible.

Looks like this has been requested - you can comment here and give use/business case.

Yup, the Github link I mentioned indicates this is needed to be opted into:

This is still a thing, Fargate pull times are super slow: https://github.com/aws/containers-roadmap/issues/696. We run all of our workloads on fargate, and it's really annoying when you're trying to iterate on something and you have to sit there waiting on "Provisioning..." for 1-2 minutes every time you launch a task. I don't think the control plane is that slow, as EC2 based ECS launches tasks really fast if the images are already cached on the machine.

The solution is working! Still there are some "missing" features. As already mentioned, the OR Condition in the Eventbridge rule is not working. So we're currently only filtering for CRITICAL images. Next it would be nice if we could use Docker image tag prefixes in IAM policies, so we can deny that vulnerable images are being pulled. In my solution I'm removing images with this tag prefix after 5 days.