01. 관리 콘솔에서 AWS EKS 배포
EKS 실습을 진행하기 위해서 사용자 커스텀 VPC(192.168.0.0/16)를 생성하고, 2개의 가용영역(AZ)와 2개의 퍼블릭, 프라이빗 서브넷을 생성하였다. 이제 기본 인프라는 구성 되었으니, AWS 관리 콘솔에서 EKS 클러스터를 생성한다.
01-1. EKS 클러스터 생성
우선 AWS 관리 콘솔로 접속해서 EKS 클러스터를 생성하는 작업을 진행한다. EKS 클러스터를 생성하는 경우 컨트롤 플레인(Control Plane)이 AWS가 관리하는 관리형 VPC(Managed VPC)에 위치하게 된다. 이때, Auto Scaling Group, ELB, EC2 등이 자동으로 생성이 되는데, 이렇게 자동으로 생성이 되게 하려면 EKS Control Plane에게 IAM Role(역할) 권한이 부여되어 있어야 한다. 하여, EKS Cluster가 AWS 리소스를 제어하기 위한 IAM Role을 먼저 생성하고 시작해야 한다.
01-2. EKS Cluster IAM Role 생성
EKS 클러스터의 컨트롤 플레인(Control Plane)을 위해 IAM 역할(Role)을 먼저 생성해야 한다. eksClusterRole이라는 이름으로 역할을 만들며, 이 역할에는 AmazonEKSClusterPolicy 정책을 연결한다. 이 정책을 통해 컨트롤 플레인이 Auto Scaling Group이나 EC2 등의 AWS 리소스를 제어할 수 있는 권한을 갖게 된다.
- IAM > 역할 > 역할 생성 이동
- 신뢰할 수 있는 엔터티 유형 : AWS 서비스 선택
- 서비스 또는 사용 사례 : EKS
- 사용 사례 : EKS - Cluster
- 정책 이름 : AmazonEKSClusterPolicy
EKS 컨트롤 플레인을 위한 IAM 역할을 생성하였으니, 이제 콘솔에서 EKS 클러스터를 생성한다.
02. 1단계 : EKS 클러스터 생성 시작
02-1. EKS 구성 옵션 - 신규
EKS 구성 옵션에는 빠른 구성과 사용자 지정 옵션이 존재한다. 빠른 구성은 EKS 클러스터의 대부분의 설정을 자동 구성할지를 정하는 부분이다. 또한, 사용자 지정은 네트워크, 보안 등등에 대한 세부 설정을 사용자가 직접 하는 경우 사용한다.
✅ 1. 빠른 구성
- 빠른 구성을 사용하면 VPC, Subnet, Security Group, Node Group, IAM 등에 대한 옵션을 자동으로 구성하고, 클릭 몇번으로 EKS 인프라를 만들 수 있다. 그렇기에 실습 or 테스트 환경에 적합하다
- 단점으로는 세부 설정을 직접 조정할 수 없다 (예 : 서브넷 CIDR, 노드 그룹 설정, 태그 등등)
✅ 2. 사용자 지정 구성
- 사용자 지정 옵션 시, VPC, Subnet, Security Group, Node Group, IAM 등의 인프라를 세밀하게 컨트롤할 수 있다. 사용자 지정 옵션은 주로, 상용 or 운영 환경에서 사용이 된다
- 예를 들어, 기존에 만든 VPC/Subnet을 재사용하거나, 특정 인스턴스 타입의 노드 그룹 사용, Spot 인스턴스 혼합 구성 등등이 존재한다
02-2. EKS 자율 모드 - 신규
EKS 자율 모드 사용은 AWS에서 제공하는 완전관리형 노드 실행 환경으로, 사용자가 k8s 워크로드를 실행하기 위해 노드그룹인 EC2나 Fargate를 직접 구성할 필요가 없는 옵션을 의미한다. 즉, 클러스터에 파드를 배포할 워커 노드가 없더라도, EKS가 자동으로 가상 노드를 생성하여 해당 워크로드를 실행할 수 있게 도와준다. 사용자는 오직 k8s의 리소스(yaml) 작성에만 집중하면 된다.
02-3. 클러스터 구성
클러스터 구성 옵션은, 클러스터의 이름과 해당 EKS 클러스터가 사용할 IAM Role을 지정하는 란이다. 여기서 지정하는 IAM Role은, 사용자를 대신하여 EKS Control Plane이 AWS 리소스를 관리하기 위한 역할이다. 우선 아래 역할(eksClusterRole)을 생성하고, 해당 역할에 AmazonEKSClusterPolicy 라는 정책을 추가한다.
eksClusterRole
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
- EKS 서비스가 Assume을 받을 수 있도록 신뢰관계 정책을 설정한다.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AmazonEKSClusterPolicy",
"Effect": "Allow",
"Action": [
"autoscaling:DescribeAutoScalingGroups",
"autoscaling:UpdateAutoScalingGroup",
"ec2:AttachVolume",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:CreateRoute",
"ec2:CreateSecurityGroup",
"ec2:CreateTags",
"ec2:CreateVolume",
"ec2:DeleteRoute",
"ec2:DeleteSecurityGroup",
"ec2:DeleteVolume",
"ec2:DescribeInstances",
"ec2:DescribeRouteTables",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVolumes",
"ec2:DescribeVolumesModifications",
"ec2:DescribeVpcs",
"ec2:DescribeDhcpOptions",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeAvailabilityZones",
"ec2:DetachVolume",
"ec2:ModifyInstanceAttribute",
"ec2:ModifyVolume",
"ec2:RevokeSecurityGroupIngress",
"ec2:DescribeAccountAttributes",
"ec2:DescribeAddresses",
"ec2:DescribeInternetGateways",
"ec2:DescribeInstanceTopology",
"elasticloadbalancing:AddTags",
"elasticloadbalancing:ApplySecurityGroupsToLoadBalancer",
"elasticloadbalancing:AttachLoadBalancerToSubnets",
"elasticloadbalancing:ConfigureHealthCheck",
"elasticloadbalancing:CreateListener",
"elasticloadbalancing:CreateLoadBalancer",
"elasticloadbalancing:CreateLoadBalancerListeners",
"elasticloadbalancing:CreateLoadBalancerPolicy",
"elasticloadbalancing:CreateTargetGroup",
"elasticloadbalancing:DeleteListener",
"elasticloadbalancing:DeleteLoadBalancer",
"elasticloadbalancing:DeleteLoadBalancerListeners",
"elasticloadbalancing:DeleteTargetGroup",
"elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
"elasticloadbalancing:DeregisterTargets",
"elasticloadbalancing:DescribeListeners",
"elasticloadbalancing:DescribeLoadBalancerAttributes",
"elasticloadbalancing:DescribeLoadBalancerPolicies",
"elasticloadbalancing:DescribeLoadBalancers",
"elasticloadbalancing:DescribeTargetGroupAttributes",
"elasticloadbalancing:DescribeTargetGroups",
"elasticloadbalancing:DescribeTargetHealth",
"elasticloadbalancing:DetachLoadBalancerFromSubnets",
"elasticloadbalancing:ModifyListener",
"elasticloadbalancing:ModifyLoadBalancerAttributes",
"elasticloadbalancing:ModifyTargetGroup",
"elasticloadbalancing:ModifyTargetGroupAttributes",
"elasticloadbalancing:RegisterInstancesWithLoadBalancer",
"elasticloadbalancing:RegisterTargets",
"elasticloadbalancing:SetLoadBalancerPoliciesForBackendServer",
"elasticloadbalancing:SetLoadBalancerPoliciesOfListener",
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Sid": "AmazonEKSClusterPolicySLRCreate",
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:AWSServiceName": "elasticloadbalancing.amazonaws.com"
}
}
},
{
"Sid": "AmazonEKSClusterPolicyENIDelete",
"Effect": "Allow",
"Action": "ec2:DeleteNetworkInterface",
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/eks:eni:owner": "amazon-vpc-cni"
}
}
}
]
}
- 위에서 신규 역할을 생성하였으니, 해당 역할(eksClusterRole)에 위 AmazonEKSClusterPolicy 정책을 추가한다. 추가가 완료되면, 클러스터 구성 화면의 “클러스터 IAM 역할”에 해당 역할(Role)을 추가해준다.
Kubernetes 버전 설정이란, EKS 클러스터를 생성할 때 사용할 k8s의 버전을 지정하는 옵션이다. 이는, 컨트롤 플레 (Control Plane)에 적용되는 버전이며, AWS는 특정 k8s 버전만 지원하기 때문에 잘 선택을 해야 한다. 또한, API와 Helm 등의 호환성을 고려해야 하며, 오래된 버전은 지원이 종료되기에, 최신 버전 사용을 권장한다.
✅ 1. 표준 옵션
- 지원 기간 : 출시일로부터 14개월 지원
- 비용 : 추가 비용 없음
- 자동 업그레이드 여부 : 지원 기간 끝나면, 다음 버전으로 자동 업그레이드 됨
- 용도 : 테스트, 운영 환경
✅ 2. 확장됨 옵션
- 지원 기간 : 26개월 지원
- 비용 : 표준 기간 이후 시간당 비용 발생
- 자동 업그레이드 여부 : 표준과 동일하나, 추가 지원 기간 포함
- 용도 : 장기 지원이 필요한 운영 환경
02-5. 자율 모드 컴퓨팅 - 신규
해당 옵션은, “EKS 자율 모드 사용 버튼”을 활성화 시킨 경우에만 사용이 되는 옵션이다. 즉, 클러스터 생성 시 노드 그룹을 자동으로 생성하지 않고, 이후에 사용자가 직접 EC2 or Fargate 프로파일을 구성해야 하는 경우에 대한 안내 문구다. 지금은 “사용자 지정 구성”을 선택했기에 넘어간다.
02-6. 클러스터 엑세스
클러스터 엑세스 옵션은, EKS 클러스터에 “누가 접근 할 수 있는지?”를 설정하는 항목이다. 클러스터를 최초로 생성한 사용자(AWS 계정)은 기본적으로 관리자 권한을 갖는다. 다른 사용자나 역할이 접근하려면 “aws-auth ConfigMap”에 해당 IAM 사용자 또는 역할을 추가해야 하며, 이를 통해 kubectl로 클러스터를 조작할 수 있는 권한을 부여할 수 있다.
✅ 1. 클러스터 관리자 엑세스 허용
- EKS 클러스터를 만든 AWS 계정 사용자에게 kubectl 접근 권한을 자동 부여 한다
- 즉, ConfigMap을 따로 수정하지 않아도, 바로 접근 가능함
✅ 2. 클러스터 관리자 엑세스 허용 안함
- EKS 클러스터를 만든 AWS 계정 사용자라도, 기본 권한도 부여하지 않는다
- 수동으로 ConfigMap 파일에 IAM 사용자 or 역할(Role)을 직접 등록해야 한다
✅ 3. 클러스터 인증 모드
클러스터 인증 모드란, 어떤 방식으로 인증할지 설정하는 항목
- EKS API : kubectl 접근 시 IAM 인증만 통과하면 접근 허용, ConfigMap 체크 안함
- EKS API 및 ConfigMap : IAM 인증 + ConfigMap 둘다 체크
02-7. 봉투 암호화
Kubernetes API 데이터(예: Secrets)는 Kubernetes API를 통해 저장되고, 관리되는 데이터를 의미한다.
- Secrets : 비밀번호, 토큰, 인증서 등 민감 데이터 저장
- ConfigMaps : 애플리케이션 설정 값 (환경 변수)
- ServiceAccount Token : Pod(파드)가 API에 접근할 때 사용하는 토큰
- PodSpec, Deployment : 워크로드에 정의된 정보 (image, volume 등)
[ 사용자 ] ---> [ API Server ] ---> [ etcd ]
kubectl, CI Kubernetes REST API 영구 저장소Kubernetes의 Secret, ConfigMap, Deployment 같은 리소스들은 etcd에 저장되며, 특히 비밀번호나 토큰처럼 민감한 정보도 포함된다. 이러한 정보가 암호화되지 않으면 보안에 취약하므로, Kubernetes는 외부 KMS 키를 받아 암호화한 뒤 저장하는 봉투 암호화(Envelope Encryption) 방식을 제공한다. 이 방식은 기본적으로 Secret에만 적용되며, ConfigMap 등 다른 리소스도 암호화 대상에 포함시킬 수 있지만, 실제로는 Secret에만 사용하는 것이 일반적이다.
자체 KMS 키를 사용하는건 AWS 제공 키가 아닌 내가 만든 키를 사용하는 것이고, AWS 제공 키를 사용하면 AWS에서 완전 관리해주나, 로깅은 불가능하다.
02-8. ARC 영역 전환
ARC(Availability-aware Resource Control)는, EKS 클러스터에 장애가 발생하는 경우, 트래픽을 문제가 없는 다른 가용영역(AZ)로 자동 부하/분산 하는 옵션이다. 또한, 클러스터를 장애로 판단하는 기준은, AWS가 자동으로 수행하며, 애플리케이션 수준의 에러(예: HTTP 4xx, 5xx)은 고려되지 않고, 인프라 수준의 장애만 인식한다.
03. 2단계 : EKS 네트워크 구성
🗂️ 03-1. 네트워킹
✅ 1. VPC
VPC를 지정하는 이유는, 워커 노드, ELB, Pod와 같은 데이터 플레인 리소스가 활동할 최상위 네트워크 경계를 정하기 위해서이다. 클러스터 생성 후에 VPC 변경은 불가능하다.
✅ 2. 서브넷
VPC 안에서 컨트롤 플레인(Control Plane)과 노드를 연결하는 EKS-owned ENI가 실제로 배치될 위치를 지정한다.
- kubectl or AWS CLI과 통신하기 위해
- 로그를 Cloudwatch로 전송하기 위해
- ELB 같은 기능과 통신하기 위해
✅ 3. 보안그룹
컨트롤 플레인(Control Plane)의 ENI에 적용될 보안 그룹을 지정한다. 보안 규정상 Ingress IP 범위 제어가 필요하거나, kubectl 접속 등을 허용할 IP 범위를 제어할 때 사용된다.
✅ 4. 클러스터 IP 주소 패밀리 선택
Pod(파드)와 Service(서비스)가 사용할 IP 주소 체계 선택한다.
✅ 5. Kubernetes 서비스 IP 주소 블록 구성
k8s의 ClusterIP 타입을 갖는 서비스에 할당할 내부 IP 범위(CIDR)를 수동으로 지정하는 옵션이다. 예를 들어 10.100.0.0/16 같은 대역으로 CIDR 범위를 지정할 수 있다.
✅ 6. 하이브리드 노드를 활성화하도록 원격 네트워크 구성
하이브리드 노드는 AWS 외부 환경(예: IDC, Outpost)에 있는 노드를 EKS 클러스터에 연결 시 사용하는 옵션이다.
🗂️ 03-2. 클러스터 엔드포인트 엑세스
클러스터 엔드포인트 엑세스는 EKS의 API Server에 접근하기 위한 엔드포인트 주소이다.
04. 3단계 : 관찰성 구성
04-1. 지표
✅ 1. Prometheus
Prometheus 옵션은 AWS에서 제공하는 Managed Prometheus로 지표를 전송 시 사용한다. 주로, EKS에 구동되고 있는 Pod에 대한 지표(CPU, Mem, 요청 수, 지연 시간)를 수집하며, 에이전트 없는 모드를 사용하려면 API 엔드포인트는 프라이빗 or 프라이빗 + 퍼블릭으로 설정되어야 한다.
✅ 2. Cloudwatch
Cloudwatch 옵션은 AWS Cloudwatch로 지표 전송 시 사용되는 옵션이다. 주로 EKS의 워커 노드(Worker Node)와 컨테이너(Container)를 모니터링을 할 때 사용이 된다. 또한, Cloudwatch 옵션을 통해 Container Insight에서 시각화가 가능해진다.
04-2. 컨트롤 플레인 로그
컨트롤 플레인에 대한 로깅 모니터링을 위해 사용되는 옵션으로 AWS Cloudwatch로 로그가 전송된다. API Server, 스케쥴러 등에 대한 모든 메트릭 수집 시 사용한다.
05. 4단계 : 추가 기능 선택
AWS EKS에서 지원하는 플러그인 선택
05-1. 추가 기능 선택
✅ 1. Amazon VPC CNI(Container Network Interface)
Amazon VPC CNI(Container Network Interface)는, EKS에서 Pod가 구동될 때, EC2에 ENI(Elastic Network Interface)를 할당하고, 해당 ENI에 할당된 IP 주소를 Pod에 매핑하는 방식으로 동작하게 된다. 이를 통해, Pod들은 VPC 내 다른 리소스들과 통신이 가능해진다.
✅ 2. CoreDNS
CoreDNS는 EKS 클러스터 내부에서 동작하는 DNS 서버로, my-service.default.svc.cluster.local과 같은 서비스 이름을 해당 IP 주소로 변환해준다. 이를 통해 Pod와 Service가 도메인 이름 기반으로 서로 통신이 가능해진다.
✅ 3. kube-proxy
Kube-proxy는 워커 노드(worker node)마다 배치가 되며, DaemonSet을 통해, 노드에 하나 씩 자동 배포되도록 구성됨
kube-proxy는 클러스터의 각 워커 노드(worker node)에서 실행되며, Service로 들어온 네트워크 요청을 실제 Pod로 전달해주는 역할을 한다. 이를 위해 kube-proxy는 “iptables” 또는 “IPVS”와 같은 Linux 네트워크 기능을 사용해 트래픽 라우팅 규칙을 설정하고, k8s API Server로부터 Service와 Endpoints 정보를 실시간으로 감지하여, 그에 맞는 트래픽 전달 경로를 자동으로 구성한다.
✅ 4. 노드 모니터링 에이전트
노드 모니터링 에이전트 플러그인은, EKS 클러스터에서 구동되고 있는 노드(EC2 or Fargate)의 리소스(CPU, Mem..) 지표를 모니터링 하기 위해 설치되는 에이전트(Agent Pod)이며, 주로 EC2(워커 노드)에 설치가 된다. 해당 에이전트를 통해 Cloudwatch와 연동하여 메트릭 수집이 가능해진다.
✅ 5. Amazon EKS Pod Identity 에이전트
EKS Pod Identity 에이전트는 특정 Pod에 IAM 역할을 자동으로 주입해주는 역할을 한다. 즉, 애플리케이션(Pod)가 S3, DynamonDB 등의 AWS 리소스에 접근해야 하는 경우가 있을 수 있기에, IAM 권한을 Pod 실행 시 자동으로 연결 해준다.
💡 서비스 어카운트(service account)
Service Account는 k8s가 API Server를 통해 k8s 클러스터의 내부 자원에 접근할 때 사용되는 내부 계정이다.
AWS에서는 이러한 Service Account에 IAM 권한을 연결해서 AWS 리소스에 접근한다.
대표적인 방법은 아래와 같다.
1. IRSA (IAM Roles form Service Accounts)
-> k8s Service Account에 IAM Role을 연결해, Pod가 AWS 리소스 접근
흐름
1. EKS 클러스터 생성 시, AWS는 자동으로 OIDC 엔드포인트 생성
2. EKS OIDC 엔드포인트를, IAM 신뢰 주체로 등록
3. Pod가 사용할 IAM Role 생성, 신뢰 정책에 OIDC와 특정 ServiceAccount를 지정
4. k8s yaml service account 생성
5. Pod에 ServiceAccount 연결
2. EKS Pod Identity (신규 방식)
-> Pod에 IAM 역할을 더 간편하게 주입- 작동 방식
- EKS Pod Identity 에이전트가 각 노드에 설치됨 (Daemonset)
- Pod가 실행될 때 에이전트가 해당 Pod에 IAM 역할 주입
- Pod는 해당 권한을 사용
✅ 6. CSI 스냅샷 컨트롤러
CSI(Container Storage Interface) 스냅샷 컨트롤러는, k8s의 Persistent Volume(PV)을 기준으로 스냅샷을 생성하는 기능이다. 해당 PV가 EBS 기반인 경우, 실제로는 EBS 스냅샷이 생성된다.
05-2. 커뮤니티 추가 기능
✅ 1. External DNS
External DNS는 EKS에서 Ingress, Service가 생성되면, 도메인 이름(예: myapp.example.com)을 자동으로 Route53에 등록해주는 기능이다. 즉, 사용자가 DNS 설정을 수동으로 하지 않아도, k8s 리소스에 따라 DNS 레코드가 자동으로 만들어지고 삭제된다.
✅ 2. 지표 서버
지표 서버(Metric Server)는 k8s 클러스터 내에서, Pod와 노드의 CPU 및 Mem 정보를 수집하여, HPA(Horizontal Pod AutoScaler)나 kubectl top 명령어 등이 실시간 리소스 정보를 조회할 수 있도록 지원하는 경량 메트릭 수집 서버다.
✅ 3. Cert Manager
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: myapp
annotations:
cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
tls:
- hosts:
- myapp.example.com
secretName: myapp-tlsHTTPS를 적용할 때 인증서를 수동으로 만들 필요 없이, Cert-Manager가 자동으로 발급·갱신해주기 때문에 Ingress에서 바로 HTTPS를 쓸 수 있다.
- Cert Manager 흐름
- 인증서 요청
- HTTPS 인증 수행 후 발급 성공 시 Secrets 생성
- Ingress에 연결
✅ 4. Prometheus Node Exporter
Prometheus Node Exporter는 EKS의 워커 노드(EC2)의 CPU, Mem, Disk, Network를 수집하고, 이를 Prometheus가 가져갈 수 있도록 노출하는 에이전트다. Node Exporter는 각 노드에 설치되며, Prometheus가 해당 메트릭을 수집해간다.
✅ 5. Kube State Metrics
Kube State Metrics는 Kubernetes 리소스의 상태를 숫자로 바꿔 보여주는 지표 수집기이며, Prometheus가 이를 자동으로 가져가서 모니터링에 활용한다.
06. 5단계 : 선택한 추가 기능 설정 구성
선택한 플러그인에 대한 설정인데, IAM Role(AmazonRoute53FullAccess, AmazonEKS_CNI_Policy, )만 권장 역할로 잘 생성하고 넘어가면 될 것 같다.
07. 6단계 검토 및 생성
모든 항목을 마지막으로 검토 하고 EKS Cluster를 생성한다.
07-1. 배포되는 자원 구성도
EKS 클러스터를 생성하면 Control Plane 자원이 AWS 관리용 VPC에 생성된다. 이러한 AWS 자원을 생성할 수 있도록 IAM 역할(eksClusterRole)을 생성하고 EKS 클러스터에 연결 해주었다. 또한, 우리가 설정한 서브넷에 따라 2개의 가용영역에서 서브넷 4개가 생성이 되는데, 클러스터 엔드포인트 엑세스가 퍼블릭으로 설정되었기에 인터넷 게이트웨이도 구성이 된다.
이렇게 2개의 가용영역에서 Control Plane 자원인 API 서버, 컨트롤러, 스케쥴러가 각각 생성되고, 또 다른 서브넷에 etcd가 생성된다. 또한, 부하분산을 위해 ELB가 구성이 되고 오토 스케일링 서비스도 구성이 된다.
그럼 이제 myeks-host EC2 서버에서 EKS 클러스터 정보를 업데이트 해보자.
즉, kubectl이 해당 클러스터와 통신할 수 있도록 kubeconfig를 등록한다는 의미다.
[root@myeks-host ~]# kubectl get nodes
E0805 22:32:35.580381 2179 memcache.go:265] "Unhandled Error" err="couldn't get current server API group list: Get \"http://localhost:8080/api?timeout=32s\": dial tcp 127.0.0.1:8080: connect: connection refused"
The connection to the server localhost:8080 was refused - did you specify the right host or port?07-2. EKS 클러스터 정보를 kubeconfig에 등록
# eks kubeconfig 정보 업데이트
aws eks update-kubeconfig \
--region $AWS_DEFAULT_REGION \
--name $CLUSTER_NAMEEKS 클러스터 생성 후, Bastion Host에서 kubeconfig를 등록해야 kubectl을 사용할 수 있다. 위 AWS CLI로 kubeconfig를 업데이트하면 ~/.kube/config에 클러스터 컨텍스트가 추가된다.
# kube config 내용 확인
cat ~/.kube/config | yh
# kube config 내용
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: Lxxxxxxxxxxxxxxxxxxxx.. # EKS 클러스터의 CA 인증서(Base 64 encoding)
server: https://9xxxxxxxxxxxxxxxxxxxx.sk1.ap-northeast-2.eks.amazonaws.com # EKS API 서버의 엔드포인트 (클러스터와 통신할 주소)
name: arn:aws:eks:ap-northeast-2:8xxxxxxxx:cluster/myeks # 클러스터의 ARN
contexts:
- context:
cluster: arn:aws:eks:ap-northeast-2:8xxxxxxxx:cluster/myeks # 사용할 클러스터명
user: arn:aws:eks:ap-northeast-2:8xxxxxxxx:cluster/myeks # 사용할 사용자 지정
name: arn:aws:eks:ap-northeast-2:8xxxxxxxx:cluster/myeks # Context 이름 -> kubectl에서 사용할 컨텍스트
current-context: arn:aws:eks:ap-northeast-2:8xxxxxxxx:cluster/myeks # 현재 사용중인 Context
kind: Config
preferences: {}
users:
- name: arn:aws:eks:ap-northeast-2:8xxxxxxxx:cluster/myeks # 클러스터에 접글할 사용자 정보
user:
exec:
apiVersion: client.authentication.k8s.io/v1beta1
args:
- --region
- ap-northeast-2 # 클러스터가 위치한 AWS 리전
- eks
- get-token # EKS 인증 토큰을 가져오는 명령
- --cluster-name
- myeks # 클러스터 이름
- --output
- json # 출력을 JSON 형식으로 반환
command: aws # AWS CLI를 사용하여 EKS 인증 수행kubeoff[root@myeks-host .kube]# k get no
E0805 22:54:24.653720 3224 memcache.go:265] "Unhandled Error" err="couldn't get current server API group list: the server has asked for the client to provide credentials"
E0805 22:54:25.484829 3224 memcache.go:265] "Unhandled Error" err="couldn't get current server API group list: the server has asked for the client to provide credentials"
E0805 22:54:26.281619 3224 memcache.go:265] "Unhandled Error" err="couldn't get current server API group list: the server has asked for the client to provide credentials"
E0805 22:54:27.083599 3224 memcache.go:265] "Unhandled Error" err="couldn't get current server API group list: the server has asked for the client to provide credentials"
E0805 22:54:27.894724 3224 memcache.go:265] "Unhandled Error" err="couldn't get current server API group list: the server has asked for the client to provide credentials"
error: You must be logged in to the server (the server has asked for the client to provide credentials)
[root@myeks-host .kube]# [EKS] "Unhandled Error" err="couldn't get current server API group list: the server has asked for the client to provide credenti
테스트용 EC2에서 EKS 쪽 작업할 게 생겨 IAM Role 할당 -> ~/.kube/config 설정 후API 요청을 보냈더니 에러가 났다. 평소 쿠버네티스 세팅은EC2에 IAM Role 할당 (Administrator 혹은 최소한의 Node Role)aws eks update
public-cloud.tistory.com
08. EKS 관리형 노드 그룹 생성
Control Plane과 마찬가지로 EKS 관리형 노드 그룹이 AWS 리소스를 동적으로 생성하기 위해 IAM Role(역할)이 필요하다. 우선 Role(역할)을 먼저 만들고 정책을 역할에 연결한 다음에 노드 그룹을 생성하는 과정으로 진행한다.
08-1. Node Group을 위한 IAM Role 생성
cat <<EOT > node-role-trust-policy.json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
EOT# EKS 노드 IAM 역할 생성(eksNodeRole)
aws iam create-role \
--role-name eksNodeRole \
--assume-role-policy-document file://"node-role-trust-policy.json"
# EKS 노드 IAM 역할에 정책 연결
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy \
--role-name eksNodeRole
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly \
--role-name eksNodeRole
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy \
--role-name eksNodeRole
# EKS 노드 IAM Role 확인
aws iam get-role --role-name eksNodeRole | jq
# EKS 노드 IAM 역할에 연결된 정책 확인
aws iam list-attached-role-policies --role-name eksNodeRole | jq08-2. EKS 노드 그룹 생성
✅ 1. 노드 그룹 구성
- AWS EKS > 클러스터 > myeks > 컴퓨팅 탭 이동 > 노드 그룹 추가 버튼 클릭
- 노드 그룹 구성
- 이름: myeks-nodegroup
- 노드 IAM 역할: eksNodeRole (aws cli로 생성한 role로 지정)
- 시작 템플릿: 기본 값
- Kubernetes 레이블: 기본 값
- Kubernetes 테인트: 기본 값
- 태그: 기본 값
✅ 2. 컴퓨팅 및 조정 구성 설정
- 노드 그룹 컴퓨팅 구성
- AMI 유형: Amazon Linux 2(AL2_x86_64)
- 용량 유형: On-Demand (Spot)
- 인스턴스 유형: t3.medium
- 디스크 크기: 20Gib
- 노드 그룹 조정 구성
- 원하는 크기: 2 노드
- 최소 크기: 2 노드
- 최대 크기: 2 노드
- 노드 그룹 업데이트 구성
- 최대 사용 불가: 수 or 백분율
- 값: 1 노드
- 노드 자동 복구 구성: 활성화
- 다음 클릭
✅ 3. 네트워킹 지정
- 서브넷: 기존에 선택한 퍼블릭 서브넷 2개 선택
- 노드에 대한 원격 엑세스 허용: 활성화
- EC2 키페어: 이전에 생성한 EC2 키페어 등록
- 원격 엑세스 권한 허용 대상: 생성되는 EKS 보안그룹 설정
- 다음 클릭 > 생성 > 3분 후 생성 완료됨
99. 참고 자료
실습 개요 | CloudNet@와 함께하는 Amazon EKS 기본 강의
실습 개요
www.inflearn.com
'Public Cloud > AWS - EKS CloudNet@' 카테고리의 다른 글
| [EKS] eksctl에서 AWS EKS 확인 및 설정 (0) | 2025.09.09 |
|---|---|
| [EKS] eksctl에서 EKS 배포 (0) | 2025.09.09 |
| [EKS] CloudFormation 기본 인프라 배포 (0) | 2025.09.09 |
| [EKS] AWS EKS 소개 및 배포, Control Plane과 Data Plan 그리고 Cluster Endpoint Access (0) | 2025.09.09 |
| [EKS] 가상머신 vs 컨테이너? (0) | 2025.09.09 |
