Hi @blake,
The features of various infrastructure products are not entirely equivalent, and Terraform’s providers to expose all of the details of the underlying systems so that you can decide for yourself how to abstract over them – if you need to do that at all – to create a platform that meets your needs.
Terraform’s modules concept allows you to create and share abstractions to allow similar usage patterns across multiple platforms, but Terraform does not provide those abstractions itself because creating abstractions requires deciding which functionality is important and which functionality is unimportant in order to present a common set of functionality.
The module composition techniques are the primary way to create your own abstractions. The section of that guide titled Multi-cloud Abstractions illustrates that using DNS as an example: there are lots of vendors providing managed DNS services with different combinations of value-add features, but as module authors we can pick a common core of standard DNS functionality that all of these vendors can offer and then users of those modules can switch between DNS vendors just by swapping to a different module with a similar interface.
The virtual compute level of abstraction (EC2, in Amazon’s world) is generally not a good level to create an abstraction because at that layer there are still many vendor-specific implementation details visible. For example, the EC2 VPC model of networking and the Google Cloud Platform model of networking are similar but not fully compatible, making it hard to create a usable abstraction at that level. In order to be able to switch easily between vendors or use multiple vendors together we will generally need to raise the level of abstraction to hide those differing details, and a Kubernetes cluster is a good example of an abstraction over compute resources: there are many hosted and self-managed implementations of it on different platforms, all of which offer a common API and common set of capabilities.
Therefore you could choose to create your abstraction layer in terms of Kubernetes by writing a set of modules that each deploy a Kubernetes cluster with one particular vendor, and then write the rest of your configurations to work with the Kubernetes provider against the API hostname produced by any of those vendor-specific Kubernetes modules.
In the end though, that decision to use Kubernetes has consequences of its own, and so Terraform won’t make it for you. You might prefer to design your abstractions a different way to make different tradeoffs. Terraform is unopinionated about these decisions, instead just aiming to give you a language to express those abstractions and a common workflow regardless of which specific technology choices you make.