monkey VS karpenter-provider-aws

Code that's hard to test is just bad code. And unlike most dynamic languages you can't just override some internals in Go (though there are some arcane hacks you can pull of but only at full moon https://github.com/bouk/monkey).

This person did not read the license of the original library https://github.com/bouk/monkey/blob/master/LICENSE.md

I am a new gopher. I was looking into the Monkey Patching module and it is archived now. I was wondering if there is an alternative for that.

Here is an example of this in Go - but as he says, don't actually do this. https://github.com/bouk/monkey

I discovered this lib a few days ago. https://github.com/bouk/monkey it allows you to monkey patch entire functions, replacing them by whatever you want. Perfect for mocking. It's simple to use. The program is hard patching the code using assembly to replace the function address at runtime. You should not use this lib out of your tests since it's absolutely not safe. It's only compatible with linux and windows. But it works great!

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.