웹사이트 검색

Terraform과 Helm을 사용하여 Kubernetes 대시보드를 배포하는 방법

Terraform은 Helm 차트를 배포할 수 있습니다. 당신에게 적합합니까?

클라우드 인프라 프로비저닝이 필요한 프로젝트를 진행할 때 내 워크플로에는 두 가지 서로 다른 구성 요소가 있습니다. 하나는 인프라(예: 새 EKS 클러스터)를 가져오는 Terraform을 포함하는 인프라 오케스트레이션이고, 두 번째는 프로비저닝 구성 요소입니다. 여기에는 새로운 배포를 수용하기 위해 해당 인프라를 인스턴스화하고 초기화하는 Ansible 또는 Bash 스크립트가 포함되어 있습니다(예: Cluster Autoscaler, kube-state-metrics 설치 등).

그 이유는 간단합니다. 오케스트레이션과 프로비저닝 측면을 모두 교차하고 처리할 수 있는 도구가 거의 없기 때문입니다. Terraform용 Helm 공급자를 우연히 발견했을 때 하나의 도구를 사용하여 양쪽을 모두 처리할 수 있는 가능성을 탐구하고 싶었습니다. Terraform을 사용하여 새로운 EKS 클러스터를 가져오고 이를 Prometheus, Loki, Grafana, Cluster Autoscaler 등과 함께 프로비저닝하는 것입니다. 깔끔하고 깔끔한 배포가 모두 가능합니다. 하지만 이 작업은 제가 어떻게 사용하는지 알아내기 전까지는 일어나지 않습니다. 따라서 아래는 간단한 작업인 Kubernetes 대시보드 배포를 위해 Terraform과 Helm을 사용한 저의 경험입니다.

투구 공급자

Helm 공급자는 다른 클라우드 공급자처럼 작동합니다. KUBECONFIG 또는 기타 자격 증명의 경로를 지정하고 terraform init를 실행하면 Helm 공급자가 초기화됩니다.

Kubernetes 대시보드 배포

이 테스트에는 Minikube를 사용할 예정입니다.

내 main.tf 파일에는 다음이 포함되어 있습니다.

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

resource "helm_release" "my-kubernetes-dashboard" {

  name = "my-kubernetes-dashboard"

  repository = "https://kubernetes.github.io/dashboard/"
  chart      = "kubernetes-dashboard"
  namespace  = "default"

  set {
    name  = "service.type"
    value = "LoadBalancer"
  }

  set {
    name  = "protocolHttp"
    value = "true"
  }

  set {
    name  = "service.externalPort"
    value = 80
  }

  set {
    name  = "replicaCount"
    value = 2
  }

  set {
    name  = "rbac.clusterReadOnlyRole"
    value = "true"
  }
}

위 Terraform에서는 https://kubernetes.github.io/dashboard/의 kubernetes-dashboard 차트를 default. 또한 차트의 기본값을 재정의하기 위해 set 변수를 사용하고 있습니다.

  1. service.type: 변경 사항을 로컬에서 검토하기 위해 이를 LoadBalancer로 변경합니다. 별도의 창에서 minikube 터널을 실행해야 한다는 점을 기억하세요. 그렇지 않으면 작동하지 않습니다.
  2. protocolHttp: localhost에서 HTTPS 경고를 억제하기 위해 비보안 버전을 배포하고 있습니다.
  3. service.externalPort: 비보안의 경우 80이어야 합니다.
  4. replicaCount: 이러한 변경 사항이 제대로 작동하는지 확인하기 위해 이 값을 2로 변경하겠습니다. :)
  5. rbac.clusterReadOnlyRole: 대시보드가 올바른 권한을 가지려면 true여야 합니다.

Terraform 실행

terraform init를 사용하여 Terraform을 초기화하는 것부터 시작해 보겠습니다.

Initializing the backend...

Initializing provider plugins...
- Finding latest version of hashicorp/helm...
- Installing hashicorp/helm v2.2.0...
- Installed hashicorp/helm v2.2.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

여태까지는 그런대로 잘됐다. Terraform이 Helm 제공자를 성공적으로 초기화했습니다. 이제 terraform 적용을 수행하세요.

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # helm_release.my-kubernetes-dashboard will be created
  + resource "helm_release" "my-kubernetes-dashboard" {
      + atomic                     = false
      + chart                      = "kubernetes-dashboard"
      + cleanup_on_fail            = false
      [...]
      + set {
          + name  = "service.type"
          + value = "LoadBalancer"
        }
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

helm_release.my-kubernetes-dashboard: Creating...
helm_release.my-kubernetes-dashboard: Still creating... [10s elapsed]
helm_release.my-kubernetes-dashboard: Creation complete after 14s [id=my-kubernetes-dashboard]

(다른 터미널 창에서 minikube 터널을 실행해야 한다는 점을 기억하세요. 그렇지 않으면 apply가 작동하지 않습니다).

변경 사항 확인

kubectl get po 및 kubectl get svc를 사용하여 Pod가 작동하는지 확인해 보겠습니다.

~ kubectl get po
NAME                                       READY   STATUS    RESTARTS   AGE
my-kubernetes-dashboard-7bc7ccfbd9-56w56   1/1     Running   0          18m
my-kubernetes-dashboard-7bc7ccfbd9-f6jc4   1/1     Running   0          18m

~ kubectl get svc
NAME                      TYPE           CLUSTER-IP       EXTERNAL-IP      PORT(S)        AGE
kubernetes                ClusterIP      10.96.0.1        <none>           443/TCP        20m
my-kubernetes-dashboard   LoadBalancer   10.104.144.125   10.104.144.125   80:32066/TCP   19m

포드가 배포되었고 로드 밸런서가 작동 중입니다. 이제 UI를 확인하세요.

그림 2: Kubernetes 워크로드 대시보드

결론

내 Gitlab 저장소에서 이 기사의 예제를 찾을 수 있습니다.

이제 Helm 프로비저닝이 Terraform의 일부가 되면서 업무 생활이 훨씬 쉬워졌습니다. 저는 인프라와 프로비저닝 간의 분리가 다른 목적에 부합한다는 것을 알고 있습니다. 인프라 변경은 일반적으로 일회성이거나 빈번한 업데이트가 필요하지 않았으며 조직의 거버넌스 또는 보안 규칙이 변경될 때 몇 차례 업데이트되었을 수도 있습니다. 반면에 프로비저닝 변경은 자주 발생했으며 때로는 모든 릴리스에서 발생했습니다. 따라서 두 개의 서로 다른 도구와 두 개의 서로 다른 검토 워크플로를 사용하여 두 개의 서로 다른 저장소에 Terraform(인프라) 및 Helm 차트(프로비저닝)를 갖는 것이 합리적이었습니다. 단일 도구를 사용하여 병합하는 것이 최선의 아이디어인지는 확신할 수 없지만, 도구 체인에서 도구를 하나 줄이는 것은 항상 큰 승리입니다. 나는 이것의 장단점이 프로젝트마다, 팀마다 다를 것이라고 생각합니다.

관련기사: