Terraform을 사용하여 Kubernetes에서 일상적인 작업을 수행하는 것은 이상적이지 않을 수 있지만 새 클러스터를 배포할 때 최소한 일부 표준 애플리케이션을 처음부터 바로 실행하기를 원할 것입니다. Helm 차트를 사용하여 이러한 차트를 설치하면 매우 간편하고 많은 시간을 절약할 수 있습니다.

최근에 처음으로 Terraform으로 Helm 차트를 설정했는데 계획대로 진행되지 않았습니다. 공급자를 설정하고 나중에 차트 자체를 배포하는 데 몇 가지 문제가 있었습니다. 나중에 Helm을 통해 응용 프로그램을 제거할 때에도 모든 것이 제거되지 않아 설치 시간이 초과된 것으로 나타났습니다. 하지만 그것은 다른 날의 이야기입니다.

Terraform을 사용하여 Helm을 설정하는 연습을 작성하고 싶었던 이유는 다른 사람이 이점을 얻을 수 있도록 하기 위함이기도 하지만 어떻게 작동하게 했는지 기억하는 데 도움이 되는 연습으로도 사용하기 위함입니다.

Helm이 무엇인지 이미 알고 있고 Kubernetes 및 Terraform을 설정하는 방법을 알고 있다고 가정합니다. 나는 이것을 0.12 구문으로 작성했으며 Terraform 0.11 및 이전 버전에서 이 중 일부를 실행하면 오류가 발생할 수 있습니다.

투구 공급자 설정

먼저 항상 그렇듯이 공급자를 설정해야 합니다. 설명서에는 일반 kubeconfig를 통해 또는 자격 증명을 정적으로 정의하여 클러스터에 인증하는 방법에 대한 두 가지 예가 나와 있습니다. kubernetes 구성을 사용하면 잘 작동할 수 있지만 동일한 프로세스에서 클러스터를 설정하고 helm 차트를 설치하려고 했습니다. 또한 이것이 CI/CD 파이프라인을 통해 실행될 수 있기를 원했기 때문에 어떤 유형의 구성을 참조해도 문제가 되지 않았습니다.

documentation example은 다음과 같습니다.

provider "helm" {
  kubernetes {
    host = "https://104.196.242.174"
    username = "ClusterMaster"
    password = "MindTheGap"

    client_certificate = file("~/.kube/client-cert.pem")
    client_key = file("~/.kube/client-key.pem")
    cluster_ca_certificate = file("~/.kube/cluster-ca-cert.pem")
  }
}

괜찮아 보이지만 클러스터가 생성될 때까지는 이 모든 정보나 파일이 없습니다. 이는 클러스터를 생성하는 워크플로와 동일한 워크플로에서 실행되므로 리소스 요소를 참조해야 합니다. 또한 사용자 이름과 비밀번호는 선택 사항이므로 먼저 사용하지 않고 시도했지만 아무런 문제가 없었습니다.

provider "helm" {
  version = "~> 0.10.4"
  kubernetes {
    host = azurerm_kubernetes_cluster.k8s.kube_config.0.host
    client_certificate = base64decode(azurerm_kubernetes_cluster.k8s.kube_config.0.client_certificate)
    client_key = base64decode(azurerm_kubernetes_cluster.k8s.kube_config.0.client_key)
    cluster_ca_certificate = base64decode(azurerm_kubernetes_cluster.k8s.kube_config.0.cluster_ca_certificate)
  }
}

위의 코드는 Terraform에 대한 강연에 사용하는 Terraform 및 Kubernetes 예제에서 가져온 것입니다. 부담 없이 entire code at Github 을 살펴보십시오.

저는 AKS(Azure Kubernetes Services)로 작업해 왔기 때문에 호스트, 클라이언트 인증서, 클라이언트 키 및 클러스터 CA 인증서를 추정할 수 있는 로컬 이름 k8s로 AKS 클러스터를 만들었습니다.

이제 helm_release 리소스를 사용하여 helm 차트를 배포할 준비가 되었습니다!

주도권을 잡다

오, 농담. 꽤 장난꾸러기(해상, 알겠어?) ...

아빠는 농담을 제쳐두고 조타 장치를 통해 무언가를 설치할 때입니다. helm_release 리소스를 사용하여 이 작업을 수행합니다. 이는 다음과 같이 보일 수 있습니다.

resource "helm_release" "prometheus" {
    name = "prometheus"
    chart = "prometheus-operator"
    repository = "https://kubernetes-charts.storage.googleapis.com/"
    namespace = "monitoring"
}

이 차트는 Helm의 훌륭한 사람들이 만든 공식 Stable 차트이지만 helm CLI를 통해 지원되는 모든 것이 여기에서도 작동합니다.

대부분의 경우 투구 차트와 함께 일부 구성을 보내고 싶을 것입니다. 이를 수행하는 방법에는 값 파일을 정의하거나 값 설정 블록을 사용하는 두 가지 방법이 있습니다. 둘 중 하나의 실제 이점은 없지만 전달하려는 설정이 하나만 있는 경우 전체 값 파일을 생성할 필요가 없다고 생각합니다.

위의 예를 사용하여 값 파일을 구성하거나 값 설정 블록을 사용하는 방법은 다음과 같습니다.

resource "helm_release" "prometheus" {
    name = "prometheus"
    chart = "prometheus-operator"
    repository = "https://kubernetes-charts.storage.googleapis.com/"
    namespace = "monitoring"

    # Values file
    values = [
    file("${path.module}/values.yaml")
  ]
    # Set value block
    set {
      name = "global.rbac.create"
    value = "false"
  }
}

주목할만한 다른 설정

wait - (선택 사항) 릴리스를 성공으로 표시하기 전에 모든 리소스가 준비 상태가 될 때까지 기다립니다. 시간 초과만큼 기다립니다. 기본값은 true입니다.

timeout - (선택 사항) 개별 kubernetes 작업(예: 후크 작업)을 기다리는 시간(초)입니다. 기본값은 300초입니다.

recreate_pods - (선택 사항) 업그레이드/롤백 중에 포드를 다시 시작합니다. 기본값은 false입니다.

atomic - (선택 사항) 설정된 경우 실패 시 설치 프로세스에서 차트를 제거합니다. 원자가 사용되면 대기 플래그가 자동으로 설정됩니다. 기본값은 false입니다.