본 시리즈는 가시다님의 AEWS(AWS EKS Workshop) 1기 진행 내용입니다. (가시다님 노션)
CloudNet@ Blog
CloudNet@ 팀에서 Cloud Infra & Network 기술에 대한 정보를 공유하는 블로그 입니다.
gasidaseo.notion.site
스터디에 사용되는 링크 (AWS EKS Workshop)
EKS Workshop | EKS Workshop
Amazon Web Services workshop for Elastic Kubernetes Service
www.eksworkshop.com
목차
1. Amazon EKS 소개
2. eksctl로 EKS 배포
이번 스터디부터는 조금 나눠서 글을 쓰려한다.
너무 스크롤 압박인 것도 가독성이 좋지 않고, 내용이 길어지면 임시 저장도 제대로 안먹기 때문...
이번 스터디는 AWS의 Kubernetes Managed Service인 EKS를 알아본다.
1. Amazon EKS 소개
Amazon EKS란?
Kubernetes의 Control Plane에 대한 운영 및 유지 관리할 필요 없이 Kubernetes를 사용할 수 있는
Amazon의 관리형 쿠버네티스 서비스이다.
- Amazon Elastic Kubernetes Service는 자체 Kubernetes 컨트롤 플레인 또는 노드를 설치
- 여러 AWS 가용 영역에 걸쳐 Kubernetes 컨트롤 플레인을 실행하고 크기를 조정하여 높은 가용성을 보장
- 컨트롤 플레인은 제어 영역 인스턴스의 크기를 자동으로 조정하고, 비정상 제어 영역 인스턴스를 감지하고 교체하며, 자동화된 버전 업데이트 및 패치를 제공
- 여러 AWS 서비스와 통합 : 컨테이너 이미지 저장소 Amazon ECR, 로드 분산을 위한 ELB(NLB, ALB), 인증 IAM, 격리를 위한 Amazon VPC
- 오픈 소스 Kubernetes 소프트웨어의 최신 버전을 실행하므로 Kubernetes 커뮤니티에서 모든 기존 플러그인과 도구 지원
- 이 부분은 특히나 빠르게 진화하는 쿠버네티스 생태계의 여러 툴들을 네이티브하게 지원하는 것으로 굉장한 이점
- 필요한 코드를 수정하지 않고 표준 Kubernetes 애플리케이션을 Amazon EKS로 쉽게 마이그레이션
- 지원 버전 : 보통 4개의 마이너 버전 지원(현재 1.22~1.26), 평균 3개월마다 새 버전 제공, 각 버전은 12개월 정도 지원 - 링크
- v1.24.2 → Major.Minor.Patch ⇒ Major(Breaking Changes) . Minor(New Features) . Patch(Bug fixes Security)
EKS 아키텍처
- EKS 컨트롤 플레인 : AWS Managed VPC - 3개 AZ, API NLB, ETCD ELB - 링크
Managed Service 즉, AWS에서 관리하는 영역인 API Server, ETCD는 위와 같은 구성으로 동작한다.
(만약 Worker Node를 가용 영역1과 3에만 배포한다면 가용 영역2에는 API Server 및 ETCD가 할당되지 않는다)
EKS를 Public으로 배포한 경우 public endpoint가 생기며, 관리자가 외부에서 kubectl 명령으로 쿠버네티스 클러스터를 제어 가능하다.
- EKS 데이터 플레인 : Customer VPC - EKS owned ENI?, 노드 유형(Managed node groups, Self-managed nodes, AWS Fargate) - 링크
자원 관리에 따른 배포 형태
- 전통적인 Container (자원 격리)
- 경량 VM으로 HW 가상화를 통해 Workload를 분리하여 보안이 강화된 컨테이너 제공
- 특징 : 보안(개별적인 전용 kernel), 분리된 (Network I/O Memory) 제공 → 하드웨어 강제격리 제공, VM처럼 성능의 소모 없이 분리된 환경을 제공
- 예시 : Kata Container
EKS Cluster Endpoint - Public : 제어부 → (EKS owned ENI) 워커노드 kubelet, 워커노드 → (퍼블릭 도메인) 제어부, 사용자 kubectl → (퍼블릭 도메인) 제어부
EKS Cluster Endpoint - Public Private : 제어부 → (EKS owned ENI) 워커노드 kubelet, 워커노드 → (프라이빗 도메인, EKS owned ENI) 제어부, 사용자 kubectl → (퍼블릭 도메인) 제어부
EKS Cluster Endpoint - Private : 제어부 → (EKS owned ENI) 워커노드 kubelet, 워커노드,사용자 kubectl → (프라이빗 도메인, EKS owned ENI) 제어부
결론
AWS를 공부하다보면 익숙하게 사용해왔던 Azure와 계속 비교하게 되는 부분이 있다.
Private과 Public Subnet, 그리고 둘의 혼합인 구성도 가능하다는 점이 아주 신기했다.
사실 AWS Console에서 EKS 단독으로 배포하다가 몇번 실패를 했다.
아마 제대로 구조를 모르고 배포하려다보니 안된 것이리라...
2. eksctl로 EKS 배포
EKS 배포 방식 : 웹 관리 콘솔, eksctl, IaC(CDK, CloudFormation, Terraform 등)
- eksctl : EKS 클러스터 구축 및 관리를 하기 위한 오프소스 명령줄 도구 - 링크
현재 스터디에서는 Terraform이 아닌 CloudFormation과 eksctl로 배포하지만, 실무에서 사용하려면 Terraform으로 자체 구축해야 한다.
이번에도 역시 가시다님의 CloudFormation 코드를 통해 배포한다. (작업용 EC2 배포 - 링크)
모든 작업이 자동화되어 있는 건 아닌 상태라 eksctl을 통해 배포하기 전에 변수화하는 과정을 거친다.
1. aws configure
aws configure
AWS Access Key ID [None]: AWEF...
AWS Secret Access Key [None]: SDvw...
Default region name [None]: ap-northeast-2
Default output format [None]: json
2. 변수 설정
## VPCID 확인
export VPCID=$(aws ec2 describe-vpcs --filters "Name=tag:Name,Values=$CLUSTER_NAME-VPC" | jq -r .Vpcs[].VpcId)
echo "export VPCID=$VPCID" >> /etc/profile
## Public Subnet 확인
aws ec2 describe-subnets --filters Name=tag:Name,Values="$CLUSTER_NAME-PublicSubnet1" | jq
aws ec2 describe-subnets --filters Name=tag:Name,Values="$CLUSTER_NAME-PublicSubnet1" --query "Subnets[0].[SubnetId]" --output text
export PubSubnet1=$(aws ec2 describe-subnets --filters Name=tag:Name,Values="$CLUSTER_NAME-PublicSubnet1" --query "Subnets[0].[SubnetId]" --output text)
export PubSubnet2=$(aws ec2 describe-subnets --filters Name=tag:Name,Values="$CLUSTER_NAME-PublicSubnet2" --query "Subnets[0].[SubnetId]" --output text)
echo "export PubSubnet1=$PubSubnet1" >> /etc/profile
echo "export PubSubnet2=$PubSubnet2" >> /etc/profile
echo $PubSubnet1
echo $PubSubnet2
## 변수 확인
echo $AWS_DEFAULT_REGION
echo $CLUSTER_NAME
echo $VPCID
echo $PubSubnet1,$PubSubnet2
3. EKS 배포
# eks 클러스터 & 관리형노드그룹 배포 전 정보 확인
eksctl create cluster --name $CLUSTER_NAME --region=$AWS_DEFAULT_REGION --nodegroup-name=$CLUSTER_NAME-nodegroup --node-type=t3.medium \
--node-volume-size=30 --vpc-public-subnets "$PubSubnet1,$PubSubnet2" --version 1.24 --ssh-access --external-dns-access --dry-run | yh
...
vpc:
autoAllocateIPv6: false
cidr: 192.168.0.0/16
clusterEndpoints:
privateAccess: false
publicAccess: true
...
# eks 클러스터 & 관리형노드그룹 배포: 총 16분(13분+3분) 소요
eksctl create cluster --name $CLUSTER_NAME --region=$AWS_DEFAULT_REGION --nodegroup-name=$CLUSTER_NAME-nodegroup --node-type=t3.medium \
--node-volume-size=30 --vpc-public-subnets "$PubSubnet1,$PubSubnet2" --version 1.24 --ssh-access --external-dns-access --verbose 4
AWS EKS 에서 배포 상태 확인
실습 자료와 다르게 파드가 보이지 않는다.(물론 클러스터나 서비스도 마찬가지)
친절하게 위에 빨간 테두리친 부분을 보고 해결해 나가보자.
링크를 따라가다 보면 EKS를 관리하려면 특정 정책들을 부여해야 한다고 나온다.
aews 사용자를 만들어서 AdminAccess 정책만 부여해서 사용하고 있었는데, 아래 EKS와 같은 정책을 추가 해야한다.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks:ListFargateProfiles",
"eks:DescribeNodegroup",
"eks:ListNodegroups",
"eks:ListUpdates",
"eks:AccessKubernetesApi",
"eks:ListAddons",
"eks:DescribeCluster",
"eks:DescribeAddonVersions",
"eks:ListClusters",
"eks:ListIdentityProviderConfigs",
"iam:ListRoles"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "ssm:GetParameter",
"Resource": "arn:aws:ssm:*:<ACCOUNT_ID>:parameter/*"
}
]
}※ ACCOUNT_ID 주의
정책 부여 후 해당 계정으로 로그인
정상적으로 보이는 것 확인!
덤으로 늘 배포하는 마리오 배포하여 LB연동 확인
External-IP가 빨리 뜬다...!
결론
점점 AWS의 IAM과도 친해지고 있고, EKS와도 친해지고 있다.
다음 게시물에서는 도전과제들을 해보자!
'Tech > Kubernetes' 카테고리의 다른 글
| [AEWS_1기] 1주차 - Amazon EKS 도전과제 (2/2) (0) | 2023.05.03 |
|---|---|
| [AEWS_1기] 2주차 - EKS Networking (1/2) (0) | 2023.05.03 |
| [PKOS_2기] 5주차 보안 (0) | 2023.04.07 |
| [PKOS_2기] 4주차 쿠버네티스 모니터링 (2) | 2023.04.01 |
| [PKOS_2기] 3주차 GitOps (0) | 2023.03.25 |
댓글