It's up to you to decide where the "cursor" is on the "cloud agnostic spectrum". As an example, let's say you can deploy your app as containers orchestrated wi

It's up to you to decide where the "cursor" is on the "cloud agnostic spectrum". As an example, let's say you can deploy your app as containers orchestrated with SystemD on an Amazon EC2 instance. Switching providers will require you to rewrite your whole deployment procedure but not the containerized application code. Your application is cloud agnostic, but not your deployment pipeline. Now, let's say instead, you have an Helm chart to deploy to k8s, you can move from Google GKE, to Azure AKS, to Amazon EKS, to baremetal k8s, without modifying your Helm chart. Your package is cloud agnostic, but not your infrastructure. If your application requires a PostgreSQL database, you can provide it with Amazon RDS, or by self-hosting it with KubeDB in a k8s cluster, or any other solutions. To your application, it would be changing the `DATABASE_URL` environment variable and running a migration script from the old DB to the new one. There is no true lock-in in that specific case. In other words: - yes, using Kubernetes can facilitate the deployment of your app on your infra in a "cloud agnostic" way - no, using Kubernetes does not mean your whole infra is "cloud agnostic" - it's ok if parts of your infra is not "cloud agnostic", that does not mean you're "vendor locked"