EKS 6탄-4. Amazon EKS 마이그레이션 요점
온프레미스 쿠버 네티스를 Amazone EKS로 마이그레이션 하는 법과 EKS 전반적인 부분에 대해 설명해준다.
<1> 3단계의 마이그레이션 방법론
<2> 평가 및 진단
<3> 전환 계획 수립
<4> 전환 수행 및 최적화
<5> EKS 특징
<6> EKS API 접근 제어
<7> 데이터 플래인 구성 방법?
<8> 클러스터 오토 스케일러
<9> POD별 IAM 할당 (IRSA)
<10> 네트워크
<11> 네트워크 로드 밸런서 생성
<12> 애플리케이션 로드 밸런서 생성
<13> 비용 효율적인 클러스터 만들기
<1> 3단계의 마이그레이션 방법론
평가 및 진단
전환 계획 수립
전환 수행 및 최적화
<2> 평가 및 진단
1
현재 클러스터 환경 조사 - 개발, 스테이징, 운영 조사 , 운영 툴, 데이터 베이스, CDN
2
애플리케이션 구성 파악 - 제약사항 (Stateless and Stateful App), CD/CD 환경 , 배포 파이프 라인, 배포 주기, 인그래스, 모니터링, 트레이스, 로깅
3
배포 방안 리뷰 - VPC 디자인, 시크린 매니지먼트 , 아이디 관리, 네트워크, DNS
4
복제 관련 도구 리뷰
k8s 리소스 , Persist volume 복제 방안 Velero, Portworx 등
<3> 전환 계획 수립
1
클라우드 환경 구성 - 랜딩존 구축
2
EKS 아키텍처 정의
3
인프라 구성 - Infra As a Code
<4> 전환 수행 및 최적화
1
컨테이너 이미지 마이그레이션 - 퍼블릭 컨테이너 이미지, 프라이빗 컨테이너 레지스트리 이전
2
데이터 복제
3
애플리 케이션 배포
CI , CD
4
데스트 및 전환
5
최적화
<5> EKS 특징
1
EKS는 4개의 마이너 버전을 14개월 지원
2
컨트롤 플레인?
AWS 가 관리한다.
3
데이터 플레인?
AWS와 고객이 책임 공유 모델로 같이 관리한다.
<6> EKS API 접근 제어
1
EKS API에 접근할 수 있는 엔트 포인트를 EKS Cluser Endpoint라고 한다.
2
퍼블릭 엔드포인트.?
인터넷 게이트웨이를 통해 접근한다.
3
프라이빗과 퍼블릭이 같이 있을 때?
퍼블릭은 인터넷 게이트웨이를 통해 접근한다.
VPC내부에 Route53 프리이빗 엔드포인트가 생성되어 ENI의 IP를 가져 내부 통신한다.
4
프라이빗 엔드포인트 사용 시?
프라이빗 클러스터 내부에서 다른 서비스 연계하려면 , 반드시 VPC 엔드포인트를 추가해야 한다.
예를 들어 S3나 ECR 연결을 위해서는 VPC 엔드포인트를 추가해야 한다.
퍼블릭 엔드포인트 사용하는 경우는 접근을 하는 서버의 IP를 제한해야 한다.
<7> 데이터 플래인 구성 방법 3가지
1
Self-Managed 노드 그룹 사용
고객이 직접 구현하고 관리
구성과 패치도 고객이 함.
2
Managed 노드 그룹 사용
3
AWS Fargate 사용
사용자가 EC2 인스턴스 관리할 필요가 없다.
Pod별로 VM을 할당.
<8> 클러스터 오토 스케일러
프라이빗 클러스터에서 구축할 경우 주의점?
리전마다 가용한 인스턴스 리스트를 호출하는 외부 API CALL이 디폴트로 설정되어 있다.
외부 호출 없이 미리 정의된 인스턴스 리스트에서 찾도록 하는 옵션을 사용해야 한다!!
<9> POD별 IAM 할당 (IRSA)
1
Pod별로 서비스 어카운트 IAM Role을 바인딩 하자.
파드 별로 권한을 다르게 가지게 하는 것이 IAM Role For Service Account (IRSA)
2
RDS에 접근하는 서비스 어카운트
ElastiCache에 접근하는 서비스 어카운트를 만들 수 있다.
<10> 네트워크
1
쿠버 네티스 네트워크는 워커 노드의 IP 대역과 각 POD가 별개로 IP 대역을 가진다.
노드 내부에 파드는 브리지를 이용해 통신을 한다.
다른 노드에 Pod와 통신은 오버레이 네트워크를 이용해 ENI를 통해 통신한다.
2
EKS는 워커 노드의 IP 대역을 같이 사용한다.
Amazon VPC CNI는 오버레이 네트워크를 사용하지 않는다.
EKS설치 시 VPC CNI가 같이 설치된다.
노드 내부에 파드는 브리지를 이용해 통신을 한다.
다른 노드에 Pod와 통신은 일반 VPC통신을 통해서 통신한다.
VPC Flow-log 나 보안 그룹 적용이 가능하다.
3
VPC CNI를 통한 최대 카드수는 인스턴스 유형에 따라 IP 수가 제한되어 있어서
노드에 할당할 수 있는 POD수가 제한된다.
m5.large 서버는 최대 3개의 인터페이스 가짐, 인터페이스당 IP는 10개까지 가능
파드는 3*(10-1) +2 = 29개 가능하다.
4
더 많은 IP를 할당할 수 있는 접두사 위임 기능?
Prefix Delegation 기능
이 기능은 Nitro 계열의 인스턴스만 지원한다.
m5.large = 432개 를 가진다.
30 VCPU 미만 인스턴스는 110개로 제한하고 있다.
이외 모든 인스턴스는 250이 최대 값.
Nitro 계열의 인스턴스 + 접두사 위임 기능 사용하라.
적은 서버에서도 파드를 많이 사용할 수 있다!!!
<11> 네트워크 로드 밸런서 생성
1
타입을 로드밸런서로 설정?
annotaion에 로드밸런서 타입을 external로 설정하면
EKS 컨트롤 플레인 외부에 있는 Pod로 실행되는 AWS Load Balancer Controller 가 네트워크 로드밸런서가 생성하도록 한다.
internal로 설정하면 Control Plane에 있는 Cloud Controller Manager가 해당 NLB를 생성한다.
2
타깃 타입을 인스턴스로 설정?
NLB의 타깃 그룹이 노드 포트로 생성된다. 큐브 프락시를 거친다.
타깃 타입을 IP로 설정하시면 해당 Pod의 IP로 생성하게 된다. 직접 Pod로 통신한다.
3
internet-facing을 설정하면 퍼블릭 서브넷에 생성된다. 인터넷 로드밸런서로 동작한다.
설정하지 않거나 인터벌로 설정하면 프라이빗에 생성된다. 내부 트래픽의 로드밸런서로 동작한다.
4
로드밸런서 타입을 External로 설정하면
워커 노드의 파드로 실행되는 AWS Load Balancer Controller 가 NLB를 생성한다.
해당 파드가 쿠버 네티스 서비스 목록을 검색하거나 AWS API를 호출할 수 있도록 하는 권한이 필요하다.
<12> 애플리케이션 로드 밸런서 생성
1
인그래스를 생성하면, ALB를 생성해서 서비스하게 된다.
1.19 이전 버전에서는 어너테이션으로 인그레스 클래스를 ALB로 선언해 줬어야 했다.
1.19 이후에서는 Spac에 포함되어 별도의 설정을 추가할 수 있다.
2
인그래스를 생성하며 실수가 별도의 ALB를 각각 만드는데,
group name을 설정하면 컨트롤러가 여러 인그래스를 다 취합해서 하나의 ALB를 생성한다.
각각의 인그레스 룰마다 타깃 그룹을 생성한다.
NLB와 마찬가지로 인그래스를 추가하면, 컨트롤러가 ALB를 생성하고 리스너와 하나의 타깃 그룹이 추가된다.
<13> 비용 효율적인 클러스터 만들기
스폿 인스턴스 활용.
최대 90% 절감
2분 전 경고
# 같이 볼 만한 자료
1
https://brunch.co.kr/@topasvga/2466
