A Terraform provider for deploying any Kubernetes resource using raw manifests, leveraging controller-runtime and the Unstructured API.
The Kubernetes Terraform Provider is a Terraform plugin that allows users to deploy and manage Kubernetes resources using raw YAML or JSON manifests. It solves the limitation of the official Kubernetes provider by supporting any Kubernetes resource type natively, without requiring predefined schemas. This makes it ideal for teams with complex or custom Kubernetes configurations.
DevOps engineers, platform teams, and infrastructure developers who use Terraform for infrastructure as code and need to manage Kubernetes resources with existing manifests or Helm charts.
Developers choose this provider for its flexibility in handling any Kubernetes resource, seamless integration with Helm workflows, and adherence to Terraform's infrastructure-as-code principles without sacrificing compatibility with native Kubernetes tooling.
Kubernetes Terraform provider with support for raw manifests
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Deploys any Kubernetes resource using YAML or JSON via the `k8s_manifest` resource, enabling seamless use of custom resources and existing manifests without schema limitations, as demonstrated in the nginx deployment example.
Supports Helm workflows by templating charts into manifests for Terraform application, allowing teams to bridge Helm and Terraform, with clear examples for both Helm 2 and 3 in the README.
Offers multiple authentication methods including kubeconfig files, in-cluster service accounts, and static credentials, matching Kubernetes-native tools for easy adoption in various environments.
Integrates with Terraform's plan, apply, and destroy cycles, providing familiar infrastructure-as-code management for Kubernetes, shown in the terminal output examples for updates and teardowns.
Only parses the first non-empty document in YAML files with multiple resources, requiring workarounds like manual splitting, which complicates deployment of multi-resource manifests.
Lacks built-in validation for Kubernetes resources, meaning errors in manifests might only surface at apply time, increasing the risk of runtime failures compared to the official provider.
For Helm integration, relies on external Helm CLI for templating, adding an extra step and potential version compatibility issues to the workflow, as noted in the requirements section.