[Amazon EKS STUDY] #1주차 (도전과제1~5) EKS 원클릭 배포 가이드

[도전과제1] 

EKS Cluster Endpoint - Private : 직접 구성해보고 kubectl → 제어부 연결 시 공인 도메인(IP)가 아닌, Private 도메인(EKS owned ENI) 연결 확인해보기

출처: kimalarm.tistory.com/50 (전적으로 왼쪽 블로그에 의존했음)

 

1.1 EKS Cluster Endpoint - Public

 

 

 

1.1.1 EKS Endpoint 확인 (User)

EKS를 Public 으로 구성할 시, EKS 콘솔에서 다음과 같은 화면을 확인할 수 있습니다.

 

 

 

사용자가 kubectl 명령어를 통해 통신하는 EKS의 API 서버 엔드포인트의 주소를 확인합니다.

 

 

웹 브라우저에서 API 엔드포인트 주소 검색

해당 URL 을 브라우저에 입력하면 다음과 같은 화면을 확인할 수 있습니다.

 

 

내 컴퓨터에서 EKS Endpoint 확인

Linux PC에서 EKS Endpoint IP 확인 (Windows는 nslookup)
$ dig +short <앞에 https://를 제외한 Endpoint 주소>

 

해당 엔드포인트는 Public IP 주소임을 확인할 수 있습니다.

사용자(User)는 kubectl 명령어를 통해 Control Plane의 API 서버에 Public IP로 통신하고 있음을 알 수 있습니다.

 

1.1.2 EKS Endpoint 확인 (Worker Node)

Worker Node의 External/Internal IP 확인
$ kubectl get nodes -o wide

Worker Node 접속 (bastion 서버에 등록된 Key를 활용해 접속)
$ ssh -i ~/.ssh/id_rsa ec2-user@<Worker Node의 Internal IP>

 

 

Worker Node에서 소켓 정보 확인

Worker Node의 소켓 정보 확인
$ sudo ss -tnp

 

• kubelet
  API Server에 노드 상태, Pod 상태 등을 보고할 때 Public IP 사용

kube-proxy
클러스터 내 Service의 트래픽을 올바른 Pod에게로 전달함
API 서버에게 Service 정보를 받아 라우팅 수행함
API 서버에서 Service 정보를 가져올 때 Public IP 사용

kubelet
Pod를 실행, 모니터링, 관리함
API 서버에게 명령을 받아 수행하고, 파드 상태를 보고함

 

kubelet은 API 서버로 상태 보고를 합니다.

Worker Node의 kubelet은 EKS API 서버에 Public IP로 통신하고 있음을 알 수 있습니다.

 

---

1.2 EKS Cluster Endpoint - Public Private

 

 

Bastion-ec2에서 myeks.yaml 파일 변경

Private 엔드포인트 활성화를 위해 myeks.yaml 파일을 수정합니다.

clusterEndpoints.privateAccess: false 를 true로 변경합니다.

 

# cluster endpoints update
eksctl utils update-cluster-endpoints -f myeks.yaml --approve

 

 

1.2.1 EKS Endpoint 확인 (User)

AWS 콘솔 상에서 API 서버 엔드포인트 액세스가 정상적으로 퍼블릭 및 프라이빗으로 변경되었습니다.

사용자가 kubectl 명령어를 통해 통신하는 EKS API 엔드포인트의 주소를 확인해봅니다.

 

웹 브라우저에서 API 엔드포인트 주소 검색

해당 URL 을 브라우저에 입력하면 다음과 같은 화면을 확인할 수 있습니다.

웹 브라우저에서 그대로 정보가 표출되는 모습을 확인할 수 있습니다.

 

 

내 컴퓨터에서 EKS Endpoint 확인

여전히 엔드포인트는 NLB의 Public IP 임을 알 수 있습니다.

 

사용자(User)는 kubectl 명령어를 통해 Control Plane의 API 서버에 Public IP로 통신하고 있음을 알 수 있습니다.

 

1.2.2 EKS Endpoint 확인 (Worker Node)

Bastion-ec2에서 EKS Endpoint 확인

 

Bastion-ec2에서 'kubectl 명령어 실행 안됨' 현상
API 엔드포인트 구조가 public & private으로 변경되면서
Control Plane의 AWS Managed VPC와 Data Plane의 Customer VPC 간의 Private Interface(EKS owned ENI)가 생성됨에 따라 Customer VPC에 위치한 Bastion-ec2도 Private 통신하게 됨.
고로, EKS Cluster의 SG 인바운드 규칙에 Bastion-ec2 private IP 오픈을 하면 kubectl 명령어 수행 가능

 

 

Worker Node에서 소켓 정보 확인

Worker Node의 소켓 정보 확인
$ sudo ss -tnp

 

!! 중요 !!
Endpoint 업데이트 후 kubelet & kube-proxy 가 Public Endpoint 를 바라보고 있으면 
서비스를 재시작해주면 Private으로 바라보게 됩니다.

kubelet 서비스 재시작 (Worker Node 접속 후 실행)
$ systemctl restart kubelet

kube-proxy 서비스 재시작 (Bastion-ec2에서 kubectl 사용하여 실행)
$ kubectl rollout restart daemonset/kube-proxy -n kube-system

Worker Node의 kubelet은 EKS API 서버에 Private IP로 통신하고 있음을 알 수 있습니다.

 

 

1.3 EKS Cluster Endpoint - Private

 

Bastion-ec2에서 myeks.yaml 파일 변경

... <생략> ...
vpc:
  clusterEndpoints:
    publicAccess: false
    privateAccess: true
  # publicAccessCIDRs: ["0.0.0.0/0"]    
... <생략> ...

Private 엔드포인트 활성화를 위해 myeks.yaml 파일을 수정합니다.

clusterEndpoints.publicAccess: true를 false로 변경합니다.

 

# cluster endpoints update
eksctl utils update-cluster-endpoints -f myeks.yaml --approve

 

 

1.3.1 EKS Endpoint 확인 (User)

 

AWS 콘솔 상에서 API 서버 엔드포인트 액세스가 정상적으로 프라이빗으로 변경되었습니다.

사용자가 kubectl 명령어를 통해 통신하는 EKS API 엔드포인트의 주소를 확인해봅니다.

 

웹 브라우저에서 API 엔드포인트 주소 검색

해당 URL 을 브라우저에 입력하면 검색이 되지 않는 모습을 확인할 수 있습니다.

 

 

내 컴퓨터에서 EKS Endpoint 확인

API Endpoint의 주소가 Private IP로 변경됨을 확인할 수 있습니다.

 

 

Bastion-ec2에서 EKS Endpoint 확인

 

 

Worker Node에서 소켓 정보 확인

Worker Node의 kubelet은 EKS API 서버에 Private IP로 통신하고 있음을 알 수 있습니다.

 

 

[도전과제2] 

EKS Cluster를 YAML 파일로 만들어서 배포해보기

 

아래의 링크로 대체하겠습니다.
https://jiho0735.tistory.com/321

 

[도전과제3] 

EKS Cluster를 관리형노드그룹을 Spot 인스턴스로 배포해보기

참조: https://github.com/eksctl-io/eksctl/blob/main/examples/08-spot-instances.yaml

 

Bastion-ec2에서 spot-cluster.yaml 작성

# An example of ClusterConfig showing nodegroups with mixed instances (spot and on demand):
---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
    name: cluster-2
    region: ap-northeast-2

nodeGroups:
    - name: ng2
      minSize: 2
      maxSize: 5
      instancesDistribution:
        maxPrice: 0.017
        instanceTypes: ["t3.small", "t3.medium"] # At least one instance type should be specified
        onDemandBaseCapacity: 0
        onDemandPercentageAboveBaseCapacity: 50
        spotInstancePools: 2

 

managedNodegroup의 인스턴스를 Spot으로 생성하고 배포한다.

 

# 배포
eksctl create cluster -f spot-cluster.yaml

 

 

 

Spot Instance 배포 성공

 

[도전과제4] 

EKS Cluster를 관리형 노드그룹을 Graviton(ARM) 인스턴스로 배포해보기

참조: http://themapisto.tistory.com/281

 

Bastion-ec2에서 graviton-cluster.yaml 작성

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: cluster-graviton  # 클러스터 이름
  region: ap-northeast-2  # 리전 설정


vpc:
  id: vpc-0fc48ec09c9551884  # 기존 VPC ID
  subnets:
    public:
      ap-northeast-2a:
        id: subnet-0de93b739ba18375a  # 기존 Public Subnet 1

nodeGroups:
  - name: ng-graviton
    minSize: 1
    maxSize: 3
    desiredCapacity: 1
    instanceType: "t4g.medium"  # ARM64 기반 Graviton 인스턴스 사용
    tags:
      "off": "exception"

 

아래와 같이, 기존 VPC 및 Subnet을 지정하지 않으면 eksctl을 통해 배포한 서비스는 모두 VPC와 Subnet이 새로 생성됩니다

vpc:
  id: vpc-xxxxxx  # 기존 VPC ID 입력
  subnets:
    private:
      ap-northeast-2a:
        id: subnet-xxxxxx  # 기존 Subnet ID 입력 (프라이빗 서브넷)
      ap-northeast-2b:
        id: subnet-yyyyyy  # 추가 Subnet ID (다른 서브넷을 사용할 경우)
    public:
      ap-northeast-2a:
        id: subnet-zzzzzz  # 퍼블릭 서브넷 ID 입력

 

 

# cluster 배포(nodegroup 포함 가능)
eksctl create cluster -f graviton-cluster.yaml

# nodegroup 추가 배포
eksctl create nodegroup -f <파일명>.yaml

 

 

 

배포 성공

 

 

[도전과제5] 

EKS Cluster를 노드를 AWS Fargate(서버리스)로 배포해보기

 

Bastion-ec2에서 fargate-cluster.yaml 작성

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: cluster-fargate
  region: ap-northeast-2

nodeGroups:
  - name: ng-fargate
    minSize: 0
    maxSize: 0
    desiredCapacity: 0

fargateProfiles:
  - name: fargate-profile
    selectors:
      - namespace: default  # 기본 네임스페이스의 파드만 Fargate에서 실행
      - namespace: kube-system  # kube-system 네임스페이스에서도 실행하려면 추가

 

EKS 클러스터에서 Fargate 노드를 사용하려면, eksctl를 활용하여 Fargate 프로필을 생성해야 합니다.

 

# 배포
eksctl create cluster -f graviton.yaml

 

 

 

배포 성공