design question: shelling out versus k8s REST API

[diemonster]

First off, thanks for your work on this project, it's far more useful than the default k8s terraform provider.

Anyway, I'm curious why you chose to shell out to kubectl versus using the kubernetes REST API. You describe why a bit in the README, but I'm curious why you can't use raw manifests w the REST API in a similar fashion? What's the advantage of working with "any Kubernetes resource natively"?

[cosmopetrich]

I recently came across this provider and was wondering about this exact issue. It might be because using the API directly would be quite a bit more work. There's some discussion around this in hashicorp/terraform-provider-kubernetes#141 and the other issues linked there. In summary:

• Kube's API doesn't currently provide a way to determine the desired state of a resource.
• A live config retrieved from the Kube API (kubectl get) will contain a number of extra fields that weren't originally in the config submitted to kube (kubectl apply).
• This makes declarative config difficult. It's hard to determine if a change needs to be applied without including logic for each different resource type since.

The points above are also a problem for kubectl itself. It deals with them by saving the entire yaml/json config passed to kubectl apply into the kubectl.kubernetes.io/last-applied-configuration annotation on the resource.

There's some discussion around updating the Kube API to support this kind of use case in kubernetes/kubernetes#17333.

[ericchiang]

Kubeconfig loading, especially the auth options, is kind of black magic best left up to kubectl. The apply code also isn't straight forward, since apply has a lot of merge logic that's not easy to replicate. Overall, I like to avoid importing kubernetes code whenever I can.

[ericchiang]

Closing since this was a question and I think it's been answered. If there are technical concerns around exec'ing kubectl instead of re-implementing the apply logic, feel free to open an issue for that.