Terraform getting started - replace gavinbunney/kubectl with hashicorp/kubernetes provider

[GregCKrause]

1. Issue, if available:
None

2. Description of changes:
Replaces gavinbunney/kubectl provider with hashicorp/kubernetes provider

3. How was this change tested?
Locally

4. Does this change impact docs?

• Yes, PR includes docs updates
• Yes, issue opened: link to issue
• No

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[netlify]

✅ Deploy Preview for karpenter-docs-prod ready!

Name	Link
🔨 Latest commit	fd87a09
🔍 Latest deploy log	https://app.netlify.com/sites/karpenter-docs-prod/deploys/6291033e3b02180009d930f9
😎 Deploy Preview	https://deploy-preview-1867--karpenter-docs-prod.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[bryantbiggs]

Thanks for the PR @GregCKrause ! Would you mind sharing a bit of the motivation around changing from the kubectl provider to the kubernetes provider for this getting started guide?

[GregCKrause]

Thanks for the PR @GregCKrause ! Would you mind sharing a bit of the motivation around changing from the kubectl provider to the kubernetes provider for this getting started guide?

Hi @bryantbiggs! The biggest motivation is that terraform-provider-kubernetes is the official Kubernetes provider from Hashicorp. I do not believe there is a net difference in functionality, but I was a little surprised when following the "Getting Started with Terraform" guide and seeing an alternative provider.

It also seems that there is more activity/support behind the official provider when comparing the two.

[bryantbiggs]

Thanks for sharing @GregCKrause - while I agree that it would be great to use the official K8s provider, it currently suffers from a number of issues for the manifest resource and the one that affects us the most is hashicorp/terraform-provider-kubernetes#1380 which is a very old issue. The issue is that the provider will make dry-run API calls to Kubernetes during the plan/apply step and for this getting started guide, the cluster does not exist yet and fails. The kubectl provider does not suffer from this same issue and allows the getting started example to deploy successful in one terraform apply.

Therefore I think its ok if we use the kubectl provider. This is just one example of how a Karpenter provisioner can be deployed, there are various ways that it can be accomplished and this is left up to users to choose. But for an easy to use getting started guide that works without any additional fuss, I think its ok as is. What do you think?

[bryantbiggs]

@GregCKrause let me know if we're ok to close this or not, thank you!

[suket22]

Closing this PR based on the discussion above.