我如何使用 Terraform 和 Helm 部署 Kubernetes 仪表板

当我在需要配置云基础设施的项目上工作时，我的工作流程有两个不同的组成部分：一个是基础设施编排，包括使用 Terraform 来启动基础设施（例如，新的 EKS 集群），第二个是配置组件，包括使用 Ansible 或 Bash 脚本来实例化和初始化该基础设施以接受新的部署（例如，安装 Cluster Autoscaler、kube-state-metrics 等等）。

这样做的原因很简单：很少有工具可以跨越并处理编排和配置方面。当我偶然发现 Terraform 的 Helm provider 时，我想探索使用一个工具来处理两方面的可能性：使用 Terraform 来启动一个新的 EKS 集群，并使用 Prometheus、Loki、Grafana、Cluster Autoscaler 等进行配置，所有这些都在一个简洁干净的部署中完成。但在我弄清楚如何使用这个东西之前，这一切都不会发生，所以下面是我使用 Terraform 和 Helm 做一些简单的事情的经验：部署 Kubernetes 仪表板。

Helm provider

Helm provider 的工作方式与其他云 provider 类似。你可以指定 KUBECONFIG 的路径或其他凭据，运行 terraform init，Helm provider 就会被初始化。

部署 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 Chart 部署到命名空间 default 中。我还使用 set 变量来覆盖 Chart 的默认值

1. service.type：我将其更改为 LoadBalancer 以本地查看我的更改。请记住在单独的窗口中运行 minikube tunnel，否则这将不起作用。
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 provider。现在进行 terraform apply

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 tunnel，否则 apply 将无法工作）。

验证我们的更改

让我们检查一下我们的 pod 是否已启动，使用 kubectl get po 和 kubectl get svc

~ 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

我们的 pod 已部署，负载均衡器正在工作。现在检查 UI： 

图片来源：

图 2：Kubernetes 工作负载仪表板

结论

你可以在我的 Gitlab 仓库中找到本文的示例：find the examples from this article in my Gitlab repo。

随着 Helm 配置现在成为 Terraform 的一部分，我的工作生活变得轻松多了。我确实意识到基础设施和配置之间的分离有不同的目的：基础设施更改通常是一次性的，或者不需要频繁更新，也许只有在我的组织的治理或安全规则发生变化时才会进行几次更新。另一方面，配置更改经常发生，有时每次发布都会发生。因此，将 Terraform（基础设施）和 Helm Chart（配置）放在两个不同的仓库中，使用两个不同的工具和两个不同的审查工作流程是有道理的。我不确定使用单个工具合并它们是否是最好的主意，但是工具链中少一个工具始终是一个巨大的胜利。我认为这种做法的优点和缺点会因项目和团队而异。