AWS EKS 를 통해 클러스터를 구축하면 Data Plane (이하 Node) 를 다양한 방식으로 구축할 수 있습니다.
Managed Node Group, Fargate 그리고 이러한 리소스를 유연하게 관리할 수 있게 해주는 AWS Auto Scaling, Karpenter 가 있습니다.
이번 글에서는 Karpenter 를 통해 AWS Auto Scaling 보다 유연하게 Node 를 관리하는 방법을 알아보고자 합니다.
우선 간단하게 알아보도록 하죠.
렛츠두더코드!
Karpenter 가 뭐죠?
여기서 말하는 노드 == 인스턴스 == 서버 는 모두 같은 개념입니다.
Karpenter 를 알아보기 전에 AWS Auto Scaling 에 대해 먼저 알아보죠.
AWS Auto Scaling 은 Auto Scaling Group 으로 묶인 인스턴스를 유연하게 동작시킬 수 있도록 도와줍니다.
실행되는 최소 갯수와 최대 갯수를 지정할 수 있죠.
음식 배달 앱에서 밤 10시에 만원 할인되는 치킨 할인 쿠폰을 1시간 동안 1000 장을 선착순으로 받을 수 있는 이벤트를 진행한다고 가정해봅시다.
밤 10시전에는 트래픽이 평온하다가~ 10시가 되는 순간 음식 배달 앱은 평소 같지 않는 트래픽에 놀라 죽어버릴 겁니다.
앱이 실행되고 있는 서버에는 이를 감당할 만한 리소스가 없는거죠.
이때 AWS Auto Scaling 을 사용하면 이런 상황에 대처하기 수월합니다.
앱이 실행되고 있는 인스턴스를 Auto Scaling Group 으로 묶어서 최소 갯수 1개, 최대 갯수 3개를 지정하고 인스턴스의 리소싱이 50% 이상 사용되면 자동으로 스케일 아웃을 해버리면 되죠.
그럼 알아서 인스턴스가 증가하게 될 것이고, 추가된 인스턴스에 대해서는 로드 밸런싱 처리를 해버리면 됩니다.
Karpenter 또한 AWS Auto Scaling 처럼 유동적으로 인스턴스의 갯수를 늘리고, 줄일 수 있습니다. 다만 차이점이 있다면 Karpenter 가 훨씬 유연하다는 것입니다.
Karpenter 는 쿠버네티스 환경에서 할당할 수 있는 노드가 없어 pending 상태에 있는 파드가 있을 경우 이를 감지하여 자동으로 노드를 늘려줍니다. 여기까지는 비슷해보이지만 필살기가 있습니다.
AWS Auto Scaling 은 사용자가 지정한 인스턴스 유형 내에서만 동작하게 되는데 Karpenter 는 파드를 배포하는데 있어 필요한 리소스를 계산하여 본인이 알아서 노드를 프로비저닝 합니다. 이 뿐만 아니라 Karpenter 는 위 그림처럼 서로 다른 노드에 배포된 파드들의 리소스를 계산하여 하나의 노드에 재배치 해줍니다.
이게 무슨 말이냐면, 4개의 파드를 배포 할 수 있는 인스턴스가 2개 있습니다. 그리고 8개의 파드가 이미 잘 실행되고 있죠.
이때 추가적으로 3개의 파드를 더 배포하려고 합니다. 배포할 인스턴스가 없으므로 파드들은 pending 상태가 될 것이고, 이를 Karpenter 가 감지하여 새로운 인스턴스를 만들 것입니다. 추가적인 인스턴스가 프로비저닝되고 pending 상태에 빠져있는 파드들은 추가된 인스턴스에 배포가 될 것입니다.
그런데 위에서 언급했듯이 한 인스턴스를 총 4개의 파드를 배포할 수 있는데 3개의 파드만 추가 배포를 했으므로 1개의 파드를 배포할 수 있는 만큼의 리소스가 여기서는 놀고 있는 겁니다. 리소스 또한 비용으로 이어지게 때문에 최대한 활용하는 것이 좋겠죠?
이때 Karpenter 를 이용하면 리소스를 최대한 사용할 수 있습니다. 빈공간을 억지로 채워주는 것은 아니고, 애초에 이 3개의 인스턴스를 합쳐버립니다. 즉, 최대 11개의 파드를 배포할 수 있는 인스턴스를 새롭게 만들고 여기에 다시 재배치해줍니다.
프로비저닝 속도 때문에 스케일 아웃이 느릴 거라고 생각했는데 생각보다 빨랐습니다
이런 기능 말고도 Karpenter 를 이용하면 AWS Auto Scaling 를 이용했을 때보다 더 많은 이점을 가져갈 수 있습니다.
Karpenter 를 사용해보자
그럼 이제 Karpenter 가 무엇인지 알아봤으니 EKS 에 환경에서 설치해서 한번 사용해보죠!
진행된 환경은 다음과 같습니다
- EKS v1.23
- Terraform v1.2.7
Terraform 이 아닌 다른 방법으로 진행하려면 여기를 참고해주세요!
Terraform 으로 작성된 Karpenter 코드는 여기를 참고해주세요!
eks_managed_node_groups = {
karpenter = {
instance_types = ["t3.medium"]
min_size = 1
max_size = 2
desired_size = 1
iam_role_additional_policies = [
# Required by Karpenter
"arn:${local.partition}:iam::aws:policy/AmazonSSMManagedInstanceCore"
]
}
}
...
resource "aws_iam_instance_profile" "karpenter" {
name = "KarpenterNodeInstanceProfile-${local.name}"
role = module.eks.eks_managed_node_groups["karpenter"].iam_role_name
}Kapenter 를 실행할 관리형 노드 그룹을 생성합니다. 관리형 노드 그룹 뿐만 아니라 파게이트로도 배포가 가능합니다.
Karpenter 를 Karpenter 로 관리되는 노드에 배포하는 것은 권장되지 않습니다
코드를 보면 iam_role_additional_policies 부분에 AmazonSSMManagedInstanceCore 라는 AWS 관리형 정책이 추가됩니다.
AmazonSSMManagedInstanceCore
이 정책을 EC2 인스턴스에 연결하면, 인스턴스가 Systems Manager 의 핵심 기능과 추가 기능을 사용할 수 있습니다. 예를 들어, Session Manager, CloudWatch, S3 등의 기능을 사용할 수 있습니다. 이 정책은 인스턴스에 대한 최소한의 권한을 부여하므로, 보안적으로 좋습니다.
관리형 노드 그룹으로 관리되는 EC2 인스턴스에는 자동적으로 IAM Profile 이 지정되는데 기본 정책으로는 AmazonEKSWorkerNodePolicy, AmazonEC2ContainerRegistryReadOnly, AmazonEKS_CNI_Policy 가 선택되는데 AmazonSSMManagedInstanceCore 또한 추가적으로 필요하기 때문에 추가해줍니다.
aws_iam_instance_profile 을 통해서 Karpenter 가 생성하는 인스턴스의 IAM Profile 을 지정합니다.
node_security_group_additional_rules = {
# Control plane invoke Karpenter webhook
ingress_karpenter_webhook_tcp = {
description = "Control plane invoke Karpenter webhook"
protocol = "tcp"
from_port = 8443
to_port = 8443
type = "ingress"
source_cluster_security_group = true
}
}
Karpenter Webhook 을 클러스터가 할 수 있게 허용해줍니다.
Terraform 으로 EKS 를 생성하면 기본으로 클러스터 보안 그룹과 추가 보안 그룹이 생성됩니다.
클러스터 보안 그룹 : 관리형 노드 그룹, 파게이트를 포함한 클러스터 내 통신을 제어하는 보안 그룹
추가 보안 그룹 : 클러스터 보안 그룹 외 규칙을 지정할 수 있는 보안 그룹
추가 보안 그룹에는 다시 한번 클러스터용 보안 그룹과 노드용 보안 그룹이 존재합니다. 그리고 실질적으로 클러스터에 필요한 추가적인 보안 그룹 규칙은 추가 보안 그룹에서 이뤄집니다. (이 부분은 정확하지 않습니다)
이러한 규칙들이 생성되는 이유는 Karpenter 가 인스턴스를 추가로 생성했다고 해서 곧바로 EKS 클러스터와 통신할 수 없기 때문입니다.
한가지 눈 여겨볼 부분은 첫번째 규칙입니다. 설명에 "Cluster API to node groups" 라고 나와있는데 이 규칙으로 인해 클러스터가 Karpenter 로 생성된 인스턴스에 API 통신을 보낼 수 있게 됩니다. 즉, kubelet 과 통신을 가능케 해주는 규칙인거죠.
또한 노드용 추가 보안 그룹 말고 클러스터용 추가 보안 그룹을 살펴보면 규칙이 반대로 되어있는 것을 확인할 수 있습니다.
클러스터용 추가 보안 그룹의 첫번째 규칙은 "Node groups to cluster API" 입니다.
진행하기 앞서 보안 그룹 소스라는 필드에는 192.168.0.10/24 와 같은 CIDR 가 아닌 보안 그룹이 지정이 되어 있는데 이에 대해 잠깐 설명드리겠습니다.
보안그룹 인바운드 룰에서 소스로 다른 보안그룹을 지정하는 의미 (여기 참고)
AWS 보안그룹에서 소스를 지정할 때 다른 보안그룹을 지정하면, 해당 보안그룹에 연결된 리소스들이 트래픽을 보낼 수 있게 됩니다.
예를 들어, EC2 인스턴스의 인바운드 룰에서 소스로 RDS 보안그룹을 지정하면, RDS 보안그룹에 연결된 DB 인스턴스들이 EC2 인스턴스로 트래픽을 보낼 수 있습니다. 이렇게 하면, IP 주소나 CIDR 블록을 사용하는 것보다 보안그룹의 리소스들이 변경되어도 룰을 수정할 필요가 없습니다. 다만, 다른 AWS 계정의 보안그룹을 지정할 때는 계정 번호도 함께 지정해야 하고, 다른 리전의 보안그룹은 지정할 수 없습니다.
보안그룹 인바운드 룰에서 소스로 자기 자신을 지정하는 의미 (여기 참고)
AWS 보안그룹에서 소스를 지정할 때 자기 자신을 지정하면, 해당 보안그룹에 연결된 모든 리소스들이 서로 트래픽을 주고받을 수 있게 됩니다.
예를 들어, EC2 인스턴스의 인바운드 룰에서 소스로 자기 자신을 지정하면, 같은 보안그룹에 연결된 다른 EC2 인스턴스들이 트래픽을 보낼 수 있습니다. 이렇게 하면, 리소스들의 IP 주소가 변경되어도 룰을 수정할 필요가 없습니다. 다만, 자기 자신을 지정할 때는 보안그룹의 ID를 사용해야 하고, 이름이나 태그를 사용할 수 없습니다.
node_security_group_additional_rules 에서 source_cluster_security_group = true 인 것을 볼 수 있는데 이 규칙의 소스를 cluster 가 가지고 있는 보안 그룹으로 지정하겠다는 겁니다. 즉, 소스로 클러스터용 보안 그룹을 지정함으로써 클러스터와 노드 간 통신을 허용해주는 것이지요.
module "vpc" {
source = "terraform-aws-modules/vpc/aws"
version = "~> 3.0"
name = local.name
cidr = "10.0.0.0/16"
azs = ["${local.region}a", "${local.region}b", "${local.region}c"]
private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
public_subnets = ["10.0.4.0/24", "10.0.5.0/24", "10.0.6.0/24"]
enable_nat_gateway = true
single_nat_gateway = true
enable_dns_hostnames = true
public_subnet_tags = {
"kubernetes.io/cluster/${local.name}" = "shared"
"kubernetes.io/role/elb" = 1
}
private_subnet_tags = {
"kubernetes.io/cluster/${local.name}" = "shared"
"kubernetes.io/role/internal-elb" = 1
# Tags subnets for Karpenter auto-discovery
"karpenter.sh/discovery" = local.name
}
tags = local.tags
}Karpenter 는 프라이빗 서브넷에서만 동작합니다. 그리고 어느 프라이빗 서브넷을 사용할 것인지 지정을 해주어야하기 때문에 private_subnet_tags 에 karpenter.sh/discovery 를 추가합니다. local.name 은 eks 이름입니다.
또한 이렇게 추가된 부분은 이후 K8S Karpenter Provisioner 리소스에서 subnetSelector 부분에서 사용됩니다.
지금까지 karpenter 가 생성한 인스턴스에서 필요한 부분들을 Terraform 으로 생성했다면, 이번에는 karpenter pod 에서 필요한 부분을 설정합니다.
karpenter pod 는 위에서 지정한 관리형 노드 그룹에 생성이 됩니다. 이후 필요한 리소스가 있을 경우 karpenter pod 에 의해 작업이 실행이 되는데, karpenter pod 는 AWS 에 접근할 자격이 당연히 없습니다.
따라서 karpenter pod 가 AWS 에 접근할 수 있도록 IRSA 를 생성합니다. (IRSA 가 궁금하다면 여기 참고)
module "karpenter_irsa" {
source = "terraform-aws-modules/iam/aws//modules/iam-role-for-service-accounts-eks"
version = "~> 4.21.1"
role_name = "karpenter-controller-${local.name}"
attach_karpenter_controller_policy = true
karpenter_controller_cluster_id = module.eks.cluster_id
karpenter_controller_ssm_parameter_arns = [
"arn:${local.partition}:ssm:*:*:parameter/aws/service/*"
]
karpenter_controller_node_iam_role_arns = [
module.eks.eks_managed_node_groups["karpenter"].iam_role_arn
]
oidc_providers = {
ex = {
provider_arn = module.eks.oidc_provider_arn
namespace_service_accounts = ["karpenter:karpenter"]
}
}
}
Terraform 에서 설정이 필요한 부분은 모두 끝났습니다. 그럼 EKS 를 적용을 하고, 추가적으로 Helm 을 통해 Karpenter 를 설치해보죠.
#!/bin/bash
set -e
KARPENTER_VERSION="v0.27.0"
CLUSTER_NAME="<cluster name>"
KARPENTER_IAM_ROLE_ARN="arn:aws:iam::<id>:role/karpenter-controller-<cluster name>"
docker logout public.ecr.aws
helm upgrade --install karpenter oci://public.ecr.aws/karpenter/karpenter --version ${KARPENTER_VERSION} --namespace karpenter --create-namespace \
--set serviceAccount.annotations."eks\.amazonaws\.com/role-arn"=${KARPENTER_IAM_ROLE_ARN} \
--set settings.aws.clusterName=${CLUSTER_NAME} \
--set settings.aws.defaultInstanceProfile=KarpenterNodeInstanceProfile-${CLUSTER_NAME} \
--set settings.aws.interruptionQueueName=${CLUSTER_NAME} \
--wait
그럼 이제 Karpenter 가 성공적으로 설치되었는지 한번 확인해보죠.
아래 리소스를 배포해줍니다.
apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
name: provisioner
spec:
# 생성할 인스턴스 유형을 구체적으로 정의
requirements:
- key: "node.kubernetes.io/instance-type"
operator: In
values: [ "g4dn.xlarge" ]
- key: "topology.kubernetes.io/zone"
operator: In
values: [ "ap-northeast-2a", "ap-northeast-2b", "ap-northeast-2c", "ap-northeast-2d" ]
- key: "karpenter.sh/capacity-type"
operator: In
values: [ "on-demand"]
- key: "kubernetes.io/arch"
operator: In
values: [ "amd64" ]
# 생성할 인스턴스의 최대 리소스
limits:
resources:
cpu: "100"
memory: 100Gi
nvidia.com/gpu: 16
# karpenter 프로비저닝 메커니즘 사용
# ttlSecondsAfterEmpty 와 consolidation 은 동시에 사용 불가
consolidation:
enabled: true
# ttlSecondsUntilExpired: 2592000 # 30 Days = 60 * 60 * 24 * 30 Seconds;
# ttlSecondsAfterEmpty: 30
# 생성된 인스턴스(worker node)에 지정되는 label
labels:
role: ops
provision: karpenter
# 생성된 인스턴스(worker node)에 지정되는 taints
taints:
- key: nvidia.com/gpu
value: "true"
effect: NoSchedule
provider:
# 생성한 인스턴스에 어느 보안 그룹을 적용할 것인지 보안 그룹의 태그로 지정
securityGroupSelector:
Name: eks-node
kubernetes.io/cluster/eks: owned
# 어느 서브넷에 인스턴스를 생성할 것인지 태그로 지정
subnetSelector:
karpenter.sh/discovery: eks
# 생성된 인스턴스의 태그를 지정
tags:
karpenter.sh/discovery: eks
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: inflate
spec:
replicas: 0
selector:
matchLabels:
app: inflate
template:
metadata:
labels:
app: inflate
spec:
terminationGracePeriodSeconds: 10
containers:
- name: inflate
image: public.ecr.aws/eks-distro/kubernetes/pause:3.2
resources:
limits:
nvidia.com/gpu: "1"
tolerations:
- key: nvidia.com/gpu
value: "true"
effect: NoSchedule
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions: # OR
- key: "topology.kubernetes.io/zone" # AND
operator: "In"
values: [ "ap-northeast-2a", "ap-northeast-2b", "ap-northeast-2c", "ap-northeast-2d" ]
- key: "karpenter.sh/capacity-type" # AND
operator: "In"
values: [ "on-demand" ]
- key: "kubernetes.io/arch" # AND
operator: In
values: [ "amd64" ]
- key: "node.kubernetes.io/instance-type" # AND
operator: In
values: [ "g4dn.xlarge" ]limits 부분은 karpenter가 생성할 수 있는 노드의 최대 리소스를 설정하는 부분입니다.
예를 들어, limits.resources.cpu: "1000"은 karpenter가 생성할 수 있는 노드의 최대 CPU 코어 수를 1000개로 제한한다는 의미입니다.
마찬가지로 limits.resources.memory: 1000Gi는 karpenter가 생성할 수 있는 노드의 최대 메모리 용량을 1000Gi로 제한한다는 의미입니다.
이러한 제한은 karpenter가 너무 많은 노드를 생성하여 비용이 증가하는 것을 방지하고, 적절한 크기의 노드를 선택하도록 돕습니다.
눈여겨 볼 옵션은 바로 Karpenter 의 핵심 기능과 관련된 ttlSecondsAfterEmpty 입니다.
ttlSecondsAfterEmpty 말고도 관련된 기능 옵션으로는 ttlSecondsUntilExpired, consolidation 가 있습니다.
karpenter에서 ttlSecondsAfterEmpty와 ttlSecondsUntilExpired의 차이는 다음과 같습니다.
ttlSecondsAfterEmpty는 노드가 비어있을 때 karpenter가 노드를 종료하도록 설정하는 값입니다. 이 기능은 값을 정의하지 않으면 비활성화됩니다.
ttlSecondsUntilExpired는 노드가 최대 나이에 도달했을 때 karpenter가 노드를 종료하도록 설정하는 값입니다. 이 기능은 값을 정의하지 않으면 비활성화됩니다. 이 옵션 같은 경우 오래된 인스턴스를 자동으로 업데이트 하려고 할 때 사용됩니다.
consolidation 에 대해서
karpenter에서 consolidation은 노드의 리소스 활용도를 높이고 비용을 절감하기 위해 작업 부하를 다른 노드로 이동시키는 기능입니다. karpenter는 consolidation을 위해 두 가지 방법을 제공합니다.
노드 삭제: karpenter는 노드에 있는 모든 파드가 다른 노드로 옮겨질 수 있는지 확인하고, 그렇다면 해당 노드를 삭제합니다. 이 방법은 ttlSecondsAfterEmpty 값으로 설정할 수 있습니다.
노드 교체: karpenter는 새로운 인스턴스 타입이나 용량 유형으로 적합한 노드를 생성하고, 기존의 비효율적인 노드에 있는 파드를 새로운 노드로 옮긴 후, 기존의 노드를 삭제합니다. 이 방법은 consolidation.enabled 값으로 설정할 수 있습니다.
consolidation 기능은 클러스터의 안정성과 성능을 향상시키고, 스팟 인스턴스나 온디맨드 인스턴스와 같은 다양한 용량 유형을 혼합하여 사용할 수 있게 해줍니다.
consolidation 와 ttlSecondsAfterEmpty 같이 사용 할 수 있을까?
consolidation과 ttlSecondsAfterEmpty는 같이 사용할 수 없습니다.
두 기능은 서로 배타적인 방식으로 노드를 삭제하기 때문입니다. consolidation은 새로운 노드를 생성하고 기존의 노드에 있는 파드를 옮긴 후에 노드를 삭제합니다.
반면에 ttlSecondsAfterEmpty은 노드가 비어있는 상태에서 일정 시간이 지나면 바로 노드를 삭제합니다.
따라서 consolidation과 ttlSecondsAfterEmpty을 같이 사용하면 충돌이 발생할 수 있습니다. karpenter는 provisioner 단위로 consolidation과 ttlSecondsAfterEmpty 중 하나만 설정할 수 있도록 제한하고 있습니다.
karpenter pod 의 로그를 확인해보죠.
2023-03-16T06:35:03.384Z INFO controller.provisioner computed new node(s) to fit pod(s) {"commit": "dc3af1a", "nodes": 1, "pods": 1}
2023-03-16T06:35:03.384Z INFO controller.provisioner launching machine with 1 pods requesting {"cpu":"1155m","memory":"120Mi","pods":"6"} from types t3.xlarge, t3.medium, t3.large {"commit": "dc3af1a", "provisioner": "karpenter-provisioner"}
2023-03-16T06:35:03.509Z DEBUG controller.provisioner.cloudprovider discovered security groups {"commit": "dc3af1a", "provisioner": "karpenter-provisioner", "security-groups": ["sg-0b874fd0cb8b74351"]}
2023-03-16T06:35:03.708Z DEBUG controller.provisioner.cloudprovider created launch template {"commit": "dc3af1a", "provisioner": "karpenter-provisioner", "launch-template-name": "Karpenter-csg-sd-dev-eks-8333440626470183087", "launch-template-id": "lt-084967c0de086c425"}
2023-03-16T06:35:05.780Z INFO controller.provisioner.cloudprovider launched new instance {"commit": "dc3af1a", "provisioner": "karpenter-provisioner", "id": "i-0c206dbe4cb2d08e1", "hostname": "ip-10-146-5-13.ap-northeast-2.compute.internal", "instance-type": "t3.medium", "zone": "ap-northeast-2c", "capacity-type": "on-demand"}
2023-03-16T06:36:12.275Z ERROR controller.interruption getting messages from queue, discovering queue url, fetching queue url, AWS.SimpleQueueService.NonExistentQueue: The specified queue does not exist for this wsdl version.문제 없이 잘 실행되고 있습니다.
이후 deployment 의 replica 를 0 으로 설정하면 ttlSeocondsAfterEmpty: 30 로 했기 때문에 해당 인스턴스는 30초 뒤 삭제됩니다.
트러블 슈팅
k logs -f -n karpenter karpenter-xxxx-xxxx 를 통해서 로그 확인이 가능합니다.
eks:DescribeCluster 권한문제
iam-role-for-service-accounts-eks 테라폼 모듈을 가장 최신 버전으로 업데이트 합니다.
구 버전에는 이 권한이 추가되어있지 않아 발생하는 에러입니다.
Karpenter 로 생성한 인스턴스 상태가 계속 NotReady
아무리 기다려도 Ready 로 바뀌지 않는다면 생성된 인스턴스의 보안그룹을 확인합니다. 클러스터와 karpenter web hook 을 통신할 수 있는 규칙이 있어야 합니다.
securityGroupSelector 부분에서 어느 보안 그룹이 선택되었는지 확인하고, 어느 규칙을 허용하고 있는지도 확인합니다.
마무리
이상 EKS 에서 Karpenter 를 설치해보고 동작하는 지 확인해보았습니다.
Terraform 으로 EKS 를 생성했을 때 생성된 보안 그룹에 대해서는 자세히 들여다 보지 않았는데 이번에 Karpenter 를 설치하면서 어떤 보안 그룹이 생성되고 어느 규칙 덕분에 클러스터와 노드들이 통신이 가능한지 알 수 있었습니다.
또한 Karpenter 를 이용하면 비용을 훨씬 더 효율적으로 사용할 수 있을 거 같습니다.
그러면 오늘은 여기까지!
'DevOps > Karpenter' 카테고리의 다른 글
| [Karpenter] 노드의 Deprovisioning 을 좀 더 아름답게~ (0) | 2023.05.17 |
|---|
