Convert Figma logo to code with AI

hashicorp logoterraform-provider-kubernetes

Terraform Kubernetes provider

1,576
968
1,576
176

Top Related Projects

109,710

Production-Grade Container Scheduling and Management

The Cloud Native Control Plane

17,333

Declarative Continuous Deployment for Kubernetes

6,346

Open and extensible continuous delivery solution for Kubernetes. Powered by GitOps Toolkit.

Quick Overview

The Terraform Provider for Kubernetes is an official HashiCorp-maintained provider that allows Terraform to manage resources in Kubernetes clusters. It enables users to define and manage Kubernetes resources using Terraform's declarative language, providing a consistent workflow for infrastructure management across multiple platforms.

Pros

  • Seamless integration with Terraform's ecosystem and workflow
  • Supports a wide range of Kubernetes resources and features
  • Regularly updated to keep pace with Kubernetes API changes
  • Allows for version-controlled, reproducible Kubernetes deployments

Cons

  • Learning curve for users new to Terraform or Kubernetes
  • May not support all cutting-edge Kubernetes features immediately
  • Complex Kubernetes configurations can lead to verbose Terraform code
  • Performance can be slower compared to native Kubernetes tools for large-scale deployments

Code Examples

  1. Creating a Kubernetes Namespace
resource "kubernetes_namespace" "example" {
  metadata {
    name = "my-namespace"
  }
}
  1. Deploying a simple Kubernetes Deployment
resource "kubernetes_deployment" "example" {
  metadata {
    name = "nginx-deployment"
    labels = {
      app = "nginx"
    }
  }

  spec {
    replicas = 3

    selector {
      match_labels = {
        app = "nginx"
      }
    }

    template {
      metadata {
        labels = {
          app = "nginx"
        }
      }

      spec {
        container {
          image = "nginx:1.21.6"
          name  = "nginx"
          port {
            container_port = 80
          }
        }
      }
    }
  }
}
  1. Creating a Kubernetes Service
resource "kubernetes_service" "example" {
  metadata {
    name = "nginx-service"
  }
  spec {
    selector = {
      app = kubernetes_deployment.example.metadata[0].labels.app
    }
    port {
      port        = 80
      target_port = 80
    }
    type = "LoadBalancer"
  }
}

Getting Started

  1. Install Terraform and configure your Kubernetes cluster.
  2. Add the Kubernetes provider to your Terraform configuration:
terraform {
  required_providers {
    kubernetes = {
      source  = "hashicorp/kubernetes"
      version = "~> 2.11.0"
    }
  }
}

provider "kubernetes" {
  config_path    = "~/.kube/config"
  config_context = "my-context"
}
  1. Define your Kubernetes resources using Terraform HCL.
  2. Run terraform init to initialize the provider.
  3. Use terraform plan and terraform apply to manage your Kubernetes resources.

Competitor Comparisons

109,710

Production-Grade Container Scheduling and Management

Pros of kubernetes

  • Core Kubernetes project with full functionality and features
  • Direct control over Kubernetes clusters and resources
  • Extensive community support and regular updates

Cons of kubernetes

  • Steeper learning curve for managing infrastructure
  • Requires more manual configuration and management
  • Less integration with other infrastructure-as-code tools

Code Comparison

terraform-provider-kubernetes:

resource "kubernetes_deployment" "example" {
  metadata {
    name = "example-deployment"
  }
  spec {
    replicas = 3
    selector {
      match_labels = {
        app = "example"
      }
    }
    template {
      metadata {
        labels = {
          app = "example"
        }
      }
      spec {
        container {
          image = "nginx:1.7.8"
          name  = "example"
        }
      }
    }
  }
}

kubernetes:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: example
  template:
    metadata:
      labels:
        app: example
    spec:
      containers:
      - name: example
        image: nginx:1.7.8

The terraform-provider-kubernetes allows for managing Kubernetes resources using Terraform's HCL syntax, while kubernetes uses YAML manifests for resource definitions. The provider offers integration with Terraform's state management and other infrastructure resources, whereas kubernetes provides direct control over cluster resources using kubectl or API calls.

The Cloud Native Control Plane

Pros of Crossplane

  • Provides a unified API for managing multiple cloud providers and services
  • Supports GitOps-friendly, declarative infrastructure management
  • Enables creation of custom resources and controllers for specific use cases

Cons of Crossplane

  • Steeper learning curve due to its more complex architecture
  • Less mature ecosystem compared to Terraform's extensive provider library
  • May require more setup and configuration for simple use cases

Code Comparison

Terraform-provider-kubernetes:

resource "kubernetes_deployment" "example" {
  metadata {
    name = "example-deployment"
  }
  spec {
    replicas = 3
    selector {
      match_labels = {
        app = "example"
      }
    }
  }
}

Crossplane:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: example

Both repositories aim to manage Kubernetes resources, but Crossplane offers a more cloud-native approach with its custom resource definitions and controllers. Terraform-provider-kubernetes is more straightforward for users familiar with Terraform, while Crossplane provides greater flexibility for complex, multi-cloud environments. The code examples show that Crossplane uses native Kubernetes YAML, while Terraform-provider-kubernetes uses HCL syntax within the Terraform ecosystem.

17,333

Declarative Continuous Deployment for Kubernetes

Pros of Argo CD

  • Provides a declarative, GitOps-based approach to continuous delivery
  • Offers a user-friendly web UI for visualizing and managing deployments
  • Supports multi-cluster deployments and application synchronization

Cons of Argo CD

  • Steeper learning curve for users not familiar with GitOps principles
  • Limited infrastructure provisioning capabilities compared to Terraform
  • May require additional tools for complete infrastructure management

Code Comparison

Argo CD Application manifest:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
spec:
  destination:
    namespace: default
    server: https://kubernetes.default.svc
  project: default
  source:
    path: k8s
    repoURL: https://github.com/example/myapp.git
    targetRevision: HEAD

Terraform Kubernetes Provider configuration:

provider "kubernetes" {
  config_path = "~/.kube/config"
}

resource "kubernetes_deployment" "example" {
  metadata {
    name = "example-deployment"
  }
  spec {
    replicas = 3
    # ... additional configuration
  }
}

The Argo CD approach focuses on declarative application definitions and GitOps workflows, while the Terraform Kubernetes Provider offers more granular control over Kubernetes resources within the broader Terraform ecosystem. Argo CD excels in continuous delivery and multi-cluster management, whereas Terraform provides comprehensive infrastructure provisioning capabilities beyond just Kubernetes.

6,346

Open and extensible continuous delivery solution for Kubernetes. Powered by GitOps Toolkit.

Pros of flux2

  • Native GitOps approach for continuous delivery
  • Supports multi-tenancy and cluster management
  • Built-in support for Helm charts and Kustomize

Cons of flux2

  • Steeper learning curve for those familiar with Terraform
  • Less flexibility in managing non-Kubernetes resources
  • May require additional tools for complete infrastructure management

Code Comparison

terraform-provider-kubernetes:

resource "kubernetes_deployment" "example" {
  metadata {
    name = "example-deployment"
  }
  spec {
    replicas = 3
    selector {
      match_labels = {
        app = "example"
      }
    }
    template {
      metadata {
        labels = {
          app = "example"
        }
      }
      spec {
        container {
          image = "nginx:1.7.8"
          name  = "example"
        }
      }
    }
  }
}

flux2:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: example
  template:
    metadata:
      labels:
        app: example
    spec:
      containers:
      - name: example
        image: nginx:1.7.8

The terraform-provider-kubernetes uses HCL syntax and is integrated with Terraform's state management, while flux2 uses native Kubernetes YAML manifests and relies on Git for state management and versioning.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

Terraform logo

Kubernetes Provider for Terraform GitHub tag (latest SemVer) license

The Kubernetes provider for Terraform is a plugin that enables full lifecycle management of Kubernetes resources. This provider is maintained internally by HashiCorp.

Please note: We take Terraform's security and our users' trust very seriously. If you believe you have found a security issue in the Terraform Kubernetes Provider, please responsibly disclose by contacting us at security@hashicorp.com.

Requirements

  • Terraform 0.12.x
  • Go 1.18+ (to build the provider plugin)

Contributing to the provider

The Kubernetes Provider for Terraform is the work of many contributors. We appreciate your help!

To contribute, please read the contribution guidelines. You may also report an issue. Once you've filed an issue, it will follow the issue lifecycle.

Also available are some answers to Frequently Asked Questions.