Terraform-provider-kubernetes: Ability to deploy CRD's

[lawrencegripper]

As much of the Kubernetes world moves to using CRD's is the provider planning to support a CRD resource?

cc: @scottguymer

[bukzor]

The answer is here: https://github.com/terraform-providers/terraform-provider-kubernetes/issues/215#issuecomment-438762846

@alexsomesan commented on Nov 14, 2018
We do want to support custom resources (and generic resources in general). We've been discussing various ways to approach this for a while. The main challenge with the current state of things in Terraform is achieving a diff-ing behaviour that is consistent with current Terraform resource diffs. The plan is to wait for Terraform 0.12 to land first and try to make use of some of its upcoming enhancements in implementing such a resource.

[glesperance]

Any updates on this?

[HipsterZipster]

Any updates @alexsomesan? Istio and others require this

[lesv]

It's difficult to install istio & knative. Istio works w/ Helm, so that can be done, though difficult as one needs to first install the CRD's, wait for them to become stable, then install real Istio.

For kNative, install requires using kubectl apply <url>. Then updating some installed resources. Then if you want a few preinstalled things, use kubectl apply to install some non-standard resources. For kNative, since it's a big deal, one can create its own provider, but as this becomes a standard, it's going to create a situation that doesn't scale.

I don't know if you have any plans, but as a thought, it might make sense to have resource that triggers from a file or url, and if that file's hash, or URL address changes, remove the old if present, and applies the new. (for big multi-resource things like kNative).

For individual custom resources, it would be nice to have a data that returns them as a string (probably JSON), with enough tools to extract things from them. And resources that can detect changes on an input string and either apply (if new), patch (if changed), or delete / apply (if the user asks for that).

[orefalo]

same issue here. using tf to deploy arangodb operators. next, is to provision resources tied to the operator nomenclature. those can't be deployed with the current provide features.

operators are becoming more and more common in k8s world. openfaas also comes with its own operator.

[lawrencegripper]

I built something out here: https://github.com/lawrencegripper/terraform-provider-kubernetes-yaml

It's now being supported on a fork which may be of use to people.

[orefalo]

Thank you @lawrencegripper found it a few days ago. Works like a charm! Cheers

[ryuheechul]

I found a workaround that works for me.

1. helm provider can help you install whatever yaml that Kubernetes will accept.
2. you can create simple chart holds your crds as template yaml in your terraform code repository.
3. install it via helm_release pointing at your local chart

And of course this method is not only for CRDs but for any yaml manifests.

[digitalkaoz]

@ryuheechul any example?

i tried it, but the helm provider complained about the char not be gzipped (its a plain yaml file)

[rubenv]

Here's two:

https://github.com/rubenv/helm-cert-manager-crds
https://github.com/rubenv/helm-cert-manager-issuers-letsencrypt

[ryuheechul]

@digitalkaoz If you made a chart locally, you should use relative path in chart

[aareet]

Closing this in favour of https://github.com/terraform-providers/terraform-provider-kubernetes/issues/215 since we are tracking this issue there.

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!