[Terraform] EKS 및 addon, helm, controller 등 생성

고객들의 문의가 들어오거나 다양한 오픈소스를 테스트해볼려고 팀원들이 자주 eks를 생성하고 지우곤 하는데 이 과정에서 여러번 oidc를 생성하고 alb controller나 ebs controller, helm, 플러그인 등을 설치하고 설치 도중에 명령어를 잘못 기입하는 순간에는 생성하는것도 어려워져 차라리 테라폼으로 구축을 했다.

 

즉

1. eks 및 여러 컨트롤러, 플러그인등을 반복적으로 설치하는 번거로움을 없애고자 생성

2. eks 생성 시 실수로인해 발생하는 오류 방지 위해 테라폼 생성

 

테라폼을 사용한 이유는

 

1. cloudformation은 스택 형식으로 구성되어있기 때문에 배포 시 많은 시간이 소요된다.

2. cloudformation은 aws에서만 사용가능하기 때문에 언제 타 벤더에서도 사용할 수있는 테라폼으로 구성

3. cdk는 사용해본적이 없어서 terraform으로 구축

 

구축은 단순 배포 목적이기 때문에 아래와 같이 따로 구분짓지 않고 하나의 디렉토리에 넣고 구축했다

 

코드는 eks.tf와 main.tf 만 올려본다

module "eks" {
  source = "terraform-aws-modules/eks/aws"

  cluster_name                          = var.eks_cluster_name
  cluster_version                       = var.eks_cluster_version
  cluster_endpoint_private_access       = true
  cluster_endpoint_public_access        = true
  cluster_additional_security_group_ids = [aws_security_group.security_group_eks_cluster.id]

  vpc_id     = module.vpc.vpc_id
  subnet_ids = module.vpc.private_subnets

  eks_managed_node_groups = {
    "${var.eks_cluster_node_group_name}" = {
      desired_size   = var.worker_node_desired_size
      max_size       = var.worker_node_max_size
      min_size       = var.worker_node_min_size
      instance_types = var.worker_node_instance_type
    }
  }

  manage_aws_auth_configmap = true

  aws_auth_users = [
    {
      userarn  = "iam arn"
      username = "name"
      groups   = ["system:masters"]
    }
  ]

 enable_irsa = true

  cluster_addons = {
    kube-proxy = {
      addon_version = "v1.24.7-eksbuild.2"
    }
    vpc-cni    = {
      addon_version = "v1.11.4-eksbuild.1"
    }
    coredns = {
      addon_version = "v1.8.7-eksbuild.3"
      configuration_values = jsonencode({
      })
    }
    aws-ebs-csi-driver = {
      service_account_role_arn = module.ebs_csi_irsa_role.iam_role_arn
      most_recent = true
    }
  }
}

provider "aws" {
  region  = var.aws_region
}

provider "helm" {
  kubernetes {
    host                   = module.eks.cluster_endpoint
    cluster_ca_certificate = base64decode(module.eks.cluster_certificate_authority_data)
    token                  = data.aws_eks_cluster_auth.default.token
  }
}

provider "kubernetes" {
  host                   = module.eks.cluster_endpoint
  cluster_ca_certificate = base64decode(module.eks.cluster_certificate_authority_data)
  token                  = data.aws_eks_cluster_auth.default.token
}

 

크게는 eks, ebs_csi, vpc tf파일은 모듈을 사용하였다.

아래 registry에서 모듈 확인 가능

 

https://registry.terraform.io/

Terraform Registry

 

구축하면서 겪은 문제들은 아래와 같다.

 

처음 아래 구문없이 eks.tf 파일을 배포 후 생성된 클러스터에 api를 호출하면 권한이 없다는 에러가 발생하는데 이는 aws-auth 파일에 클러스터를 사용할 사용자 관리가 되지 않아서 발생한 문제였다 

 

해결하기 위해 아래 구문을 넣어 aws-auth에 필자의 iam을 추가하여 권한을 얻을 수 있었다.

  manage_aws_auth_configmap = true

  aws_auth_users = [
    {
      userarn  = "iam arn"
      username = " name"
      groups   = ["system:masters"]
    }
  ]

 

하지만 해당 구문을 추가 후 apply를 하면 아래와 같이 에러가 발생했다.

│ Error: configmaps "aws-auth" already exists
│ 
│   with module.eks.kubernetes_config_map.aws_auth[0],
│   on .terraform/modules/eks/main.tf line 411, in resource "kubernetes_config_map" "aws_auth":
│  411: resource "kubernetes_config_map" "aws_auth" {

 

아래 깃허브를 참고하면 많은 사람들한테도 필자와 같은 문제가 빈번하게 발생하는것 같다.

그에 대한 해결문도 정리가 잘돼있다.

 

https://github.com/terraform-aws-modules/terraform-aws-eks/issues/2009

`Error: The configmap "aws-auth" does not exist` when deploying an EKS cluster with `manage_aws_auth_configmap = true` · Issue

 

즉

클러스터에서 EKS 기본 사용자가 되는 AWS provider의 역할을 사용하고 있지만 kubernetes provider에서는 IAM 공급자의 역할과 다를 수 있는 defualt profile을 사용하고 있으므로 해당 자격 증명에 클러스터 액세스 권한이 없다고 한다.

 

결론적으로는 kubernetes provider를 추가해주면 해결할 수 있다.

data "aws_eks_cluster_auth" "default" {
  name = module.eks.cluster_id
}

provider "kubernetes" {
  host                   = module.eks.cluster_endpoint
  cluster_ca_certificate = base64decode(module.eks.cluster_certificate_authority_data)
  token                  = data.aws_eks_cluster_auth.default.token
}

 

또한 kubernets 뿐만 아니라 다양한 플러그인들을 생성하기 위하여 user_data에 shell을 넣었는데

kubectl 보다 k로 별칭 주고 사용을 많이해서 /etc/profile에 넣어 커널 시작할때 바로 실행되도록 설정하려했지만 구성 시에는 별칭이 먹히지 않았다 중간에 source를 사용하여 리부팅 시켜도 똑같이 k로 주어진 별칭이 먹히지 않았다

왜 안되는지 다시 생각해봐야겠다.

echo 'source <(kubectl completion bash)' >> /etc/profile
echo 'alias k=kubectl' >> /etc/profile
echo 'complete -F __start_kubectl k' >> /etc/profile

 

그 외 eks.tf 파일에 addon을 추가 해줬다

기본적으로 kube-proxy, vpc-cni, coredns는 eks를 생성할때 default로 설치되는것으로 아는데 ebs-csi-driver를 생성해주면서 addon으로 설치해줬다

 enable_irsa = true

  cluster_addons = {
    kube-proxy = {
      addon_version = "v1.24.7-eksbuild.2"
    }
    vpc-cni    = {
      addon_version = "v1.11.4-eksbuild.1"
    }
    coredns = {
      addon_version = "v1.8.7-eksbuild.3"
      configuration_values = jsonencode({
      })
    }
    aws-ebs-csi-driver = {
      service_account_role_arn = module.ebs_csi_irsa_role.iam_role_arn
      most_recent = true
    }
  }

 

ebs-csi-driver 같은 경우 irsa에 대한 module이 존재했기 때문에 쉽게 생성했지만

AWSLoadBalancerController 같은 경우 aws에서 제공하는 module을 찾지 못해서 구글 찾아보면서 생성했다.

LoadBalancerController, argocd 둘다 helm으로 배포했고 배포하기 위해서는 helm provider를 추가 해줘야한다.

provider "helm" {
  kubernetes {
    host                   = module.eks.cluster_endpoint
    cluster_ca_certificate = base64decode(module.eks.cluster_certificate_authority_data)
    token                  = data.aws_eks_cluster_auth.default.token
  }

 

LoadBalancer 경우 로컬에서도 values.yaml 파일보다는 set 명령어로 override했어서 set을 사용했으며 argo는 당장 사용하지 않을거라 생각해 ingress 및 values 파일은 생성하지 않았다.

 

끝으로 테라폼을 사용하다 보면 모든 것을 자동화해야 하는 고민이 많이 든다.

그래서 테라폼이 어느범위까지 자동화를 다룰 것인가를 여러 경력자 분들과 커뮤니티에 여쭤보면 대부분이 kubernetes 내부의 리소스는 helm chart로 구성, 관리하는것을 추천했다.

 

하지만 eks 리소스 및 인프라 구축은 편하지만 helm에서 다른 컨트롤러 등을 사용하기 위한 irsa 등을 생성하는게 생각보다 귀찮은 작업 같아 그 외 작업에서 terraform을 사용하는것은 고민을 해봐야겠다