You are more likely to get locked in with kubernetes than with AWS. It’s easier to migrate out of highly decoupled, well documented systems piece by piece (AWS) than out of monolithic frameworks like k8s.
I don't see what the problem is with being locked into a "monolithic framework" as long as you can run your own copy of it.
You can take as much time as you like to migrate yourself away from k8s if you don't like it any more (physically migrate your system to your own site; pin the k8s version to prevent API changes; then start changing your code to be less coupled to k8s.)
Whereas, if AWS changes and deprecates a feature, you're on their schedule as to how long you have before your service will break.
That makes no sense. Kubernetes leveraged aws primitives (elb) if needed, and at its core, it deploys containers. As long as your application runs in a container, you aren't locked in.
I think we can agree that Kubernetes does far more than schedule containers, even if “at its core” that’s what it does. How many lines of the 2e6 lines of code k8s project are directly related to scheduling containers? Very few. If a scheduler is all that is needed and you want to use any of the 3 different types of load balancers provided by AWS, a simpler architecture might be just to use AWS ECS. 500 lines of declarative Cloudformation or Terraform will do the job.
What features are you referring to specifically that lock you in? Sure, it's a large project. But most LOC are around being modular and pluggable, and adhering to standards (OCI, CNI, CSI). I can't think of anything that would be particularly difficult to move out of if needed.
There isn’t sufficient separation between components within Kubernetes for ease of migrating piece by piece away from kubernetes. Documentation also plays an important role in migrations. I once counted the pages of documentation for Kubernetes vs AWS for equivalent functionality (VPC, ECS, Route53, etc) and AWS had 20 pages for every page of Kubernetes.
By “lock in” I should have clarified I meant locked in to a proprietary ecosystem. Certainly being dependent on open source can be problematic if you’re not an active member of the community (or if the “community” is really just one company)
You can take as much time as you like to migrate yourself away from k8s if you don't like it any more (physically migrate your system to your own site; pin the k8s version to prevent API changes; then start changing your code to be less coupled to k8s.)
Whereas, if AWS changes and deprecates a feature, you're on their schedule as to how long you have before your service will break.