kured VS karpenter-provider-aws

Maaaaybe, but it's not really what it's suited for. For the Kubernetes host, I'd recommend you enable auto-updates, and then deploy https://github.com/kubereboot/kured to perform reboots as required (you can have it check alertmanager for current alerts, and only do a reboot during a maintenance window if there are no alerts)

OS patches, which are installed automatically by AKS. If restarts are required, we let https://github.com/weaveworks/kured handle it

kured : automatic restarts of kubernetes nodes

See https://github.com/weaveworks/kured or https://github.com/MnrGreg/kubectl-node-restart

You may want to check this https://github.com/weaveworks/kured It is very useful when updating underlying OS on nodes - allows you detect and restart gracefuly

If you’re not familiar with Karpenter — watch my quick intro. But in a nutshell, Karpenter is a better node autoscaler for Kubernetes (say goodbye to wasted compute resources). It is open-source and built by the AWS team. Qovery is an Internal Developer Platform I’m a co-founder) that we’ll use to spin up our EKS cluster with Karpenter.

Karpenter

Here are a few reference links about the previous services and tools: What is Amazon EKS? Cluster Mesh Karpenter

Autoscaling over EKS can be accomplished using either the cluster-autoscaler project or Karpenter. If you want to use Spot instances, consider using Karpenter, as it has better integrations with AWS for optimizing spot pricing and availability, minimizing interruptions, and falling back to on-demand nodes if no spot instances are available.

Kubernetes has its own learning curve, but when tools like Karpenter exist it's kinda hard to beat for "auto-scaled compute" that is vendor agnostic. We leverage Karpenter for burst in our vSphere environment as well as our EC2 environment. Karpenter is invoking roughly the same Terraform code in both cases, just using different modules for the particular virtualization. Say we want to go to Azure and GCP -- we add an Azure and GCP module to the same Terraform codebase, and not much else needs to change from the "scale up / scale down" perspective.

Also https://github.com/aws/karpenter/issues/331

Why don't you stick to the KubernetesPodOperator though? I fail to see a benefit in using the ECS operator considering you're already running Airflow in EKS. You can look into something like karpenter to manage your nodes.

We use the Kubernetes runner and Karpenter.