terrajet VS terraform-provider-kubernetes

And to my personal opinion they would've better spent some resources to contribute to the target providers instead of embedding or directly code-generating (https://github.com/crossplane/terrajet) from Terraform. Spreading the efforts and resources doesn't really help that much with the existing Terraform issues.

So, I find both pulumi and crossplane rather parasitic for the existing Terraform Provider Infrastructure. Actually fixing the bicycle would've been better than strapping a jet engine on top.

For me, this situation is very similar to the long resolved issue with docker multistage... with myriads of CLI tools on top obsoleting in result.

We have implemented Terrajet (https://github.com/crossplane/terrajet) that generates CRDs that's completely compliant with Kubernetes Resource Model; references, label selectors, spec/status, no TF state blob saved anywhere.

Check it out!

Crossplane comes to my mind when thinking of using the GitOps way to provision infrastructures. Unfortunately, I think there isn't a Vault Crossplane provider at the moment but there's a terrajet project that allows you to generate Crossplane providers from Terraform providers. Might be a long shot and seems overly complex for a use-case like yours, but worthwhile if you plan to let ArgoCD manage everything.

Now, to be honest, I'm not entirely sure/confident how this works. When I've used this kind of setup, I had two separate workspaces: one for setting up EKS and one for setting up Kubernetes within EKS. I'd apply the EKS workspace, first, then use its outputs for the Kubernete's workspace. You can see this pattern is specifically outlined in this EKS/k8s example. The Kubernetes provider docs also explicitly warns against creating the cluster in the same module as the Kubernetes provider. So it appears this may work, but it isn't recommended.

It is a pretty important distinction. Terraform and Kubernetes are fundamentally different in how they work. If you ever try to manage kubernetes state from terraform, it the differences become very obvious: https://github.com/hashicorp/terraform-provider-kubernetes/issues/1367

I'm using the terraform kubernetes-provider and I'd like to translate something like this kubectl command into TF:

After the resources be provisioned, you might want to run terraform apply -refresh-only to refresh your local state as the creation of some resource change the state of others within AWS. Also, state differences on metadata.resource_version of k8s resources almost always show up after an apply. This seems to be related to this issue.

You can open an issue here: https://github.com/hashicorp/terraform-provider-kubernetes/issues

We want to do that, but this issue has been a huge blocker for us. You might not hit it unless you’re using AKS, though.