EKS 성능, 부하 테스트 및 Metric 테스트를 AWS EKS 환경에서 진행
환경구성
EKS 1.28
Terraform
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.7.0"
}
http = {
source = "hashicorp/http"
version = "~> 3.3"
}
tls = {
source = "hashicorp/tls"
version = "~> 4.0.5"
}
helm = {
source = "hashicorp/helm"
version = "~> 2.9"
}
}
}
provider "aws" {
region = var.region
}
provider "http" {
}
provider "helm" {
kubernetes {
host = aws_eks_cluster.app_cluster.endpoint
cluster_ca_certificate = base64decode(aws_eks_cluster.app_cluster.certificate_authority[0].data)
token = data.aws_eks_cluster_auth.app_cluster.token
}
설치 리소스
조치 1 : 설치 도중 화면 잠금으로 인한 에러 발생으로 설치 한번 중단 후 재설치를 진행했기 때문에 destroy 후 재설치 진행. - 해결되지 않음
조치 2 : Nodegroup_role 추가
resource "aws_iam_role_policy_attachment" "eks-AmazonSSMManagedInstanceCore" {
policy_arn = "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"
role = aws_iam_role.eks_nodegroup_role.name
}
설치 완료
SSM이란? (SSH 상위호환?)
SSM을 사용해서 호스트에 접속하는 방법은 상대적으로 아래와 같은 장점이 있습니다.
- Bastion Host가 필요없음
- Key Pair가 필요없음
- Security Group + Rule이 필요 없음
- 그럼에도 불구하고, SSH로 할 수 있는 건 다 가능
- Private Subnet에 있는 EC2 인스턴스에 바로 접속할 수 있음 (마치 VPN에 있는 것처럼)
- AWS Client VPN을 사용하는 것에 비해서 비용이 적게 듬
ssh 명령으로 Bastion Host에 접속하는 대신, AWS CLI의 ssm 서비스의 start-session
명령으로 AWS Systems Manager에 연결합니다. (생각에 따라서 SSM이 Bastion Host를 대신한다고 볼 수도 있습니다.)
SSM은 HTTPS 프로토콜을 사용합니다. 따라서 Key Pair도 만들 필요가 없고, 포트 허용을 위해 Security Group을 만들 필요도 없습니다.
그럼 인증은 뭘로 하느냐? AWS CLI를 사용하기 위해 등록한 AWS Credentials를 사용합니다.
SSM 정책
AmazonSSMManagedInstanceCore
정책을 EKS 노드 그룹의 IAM 역할에 추가함으로써 문제가 해결된 것은, 이 정책이 AWS Systems Manager (SSM)를 통한 인스턴스 관리를 가능하게 해주기 때문입니다. 이 정책은 AWS 리소스에 대한 세부적인 관리 및 운영 작업을 수행할 수 있는 권한을 제공합니다. 구체적으로, AmazonSSMManagedInstanceCore
정책이 제공하는 권한에는 다음과 같은 것들이 포함됩니다:
- 인스턴스 정보 접근: SSM을 통해 EC2 인스턴스의 메타데이터, 구성, 그리고 상태 정보에 접근할 수 있게 해줍니다.
- 패치 관리: 인스턴스에 보안 패치와 업데이트를 자동으로 적용할 수 있게 해줍니다. 이는 인스턴스가 최신 상태로 유지되도록 하여 보안 취약점에 대한 노출을 줄여줍니다.
- 원격 관리: SSM을 통해 EC2 인스턴스에 대한 원격 명령 실행이 가능하게 해줍니다. 이를 통해 관리자는 인스턴스에 직접 로그인하지 않고도 관리 작업을 수행할 수 있습니다.
- 구성 관리: 인스턴스의 소프트웨어 설치 상태, 시스템 구성 등을 관리하고, 필요한 변경 사항을 적용할 수 있게 해줍니다.
EKS 노드가 Kubernetes 클러스터에 성공적으로 가입하지 못한 원인 중 하나는, 인스턴스 관리 및 구성에 필요한 권한이 부족하여 인스턴스가 제대로 구성되지 않거나 필요한 소프트웨어 업데이트를 받지 못했기 때문일 수 있습니다. AmazonSSMManagedInstanceCore
정책을 IAM 역할에 추가함으로써, 해당 노드들이 AWS Systems Manager를 통해 필요한 관리 및 구성 작업을 수행할 수 있는 권한을 얻게 되었으며, 이는 노드가 Kubernetes 클러스터에 성공적으로 가입하는 데 필요한 조건을 충족시킬 수 있었던 것으로 보입니다.
'Engineering' 카테고리의 다른 글
Prometheus란? helm을 이용해 EKS에 설치 (0) | 2024.04.02 |
---|---|
Performance Test Metric 도구 간단 정리 (Promethus, Thanos, Cortex, Mimir, Victoria Metrics) (0) | 2024.04.01 |
Grafana Mimir란? && 설치 테스트 (1) | 2024.03.08 |
AWS External ALB, Internal ALB, EKS Targetgroupbinding 구성 (0) | 2024.03.08 |
AWS EKS ALB 하나로 여러 Ingress 구성 ( Ingress Group, TargetGroupBinding) (0) | 2024.02.06 |