[Amazon EKS STUDY] #1주차 (도전과제6~9)

[도전과제6] 

EKS Cluster를 관리형노드그룹에 Bottlerocket AMI 사용해보고, Amazon Linux2 AMI와 차이점을 알아봅시다.

 

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

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

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

nodeGroups:
  - name: ng-bottlerocket
    minSize: 1
    maxSize: 2
    desiredCapacity: 1
    instanceType: "t3.medium"  
    amiFamily: Bottlerocket  # Bottlerocket AMI Family 지정
    bottlerocket:
      enableAdminContainer: true  # 관리용 컨테이너 활성화 (선택사항)
    tags:
      "off": "exception"

 

# 배포
eksctl create cluster -f myeks.yaml

 

 

 

배포 성공

 

Bottlerocket AMI vs Amazon Linux 2
모두 Linux 기반 및 컨테이너 지원이 되는 OS이나,
일반적인 서버 용도로는 AL2, 컨테이너 실행 환경이면 Bottlerocket이 좋습니다.

Bottlerocket AMI
ㆍ컨테이너 실행을 위한 OS
ㆍ더 강화된 보안 (불필요한 프로그램 없음)
ㆍSSH 접속 기본 차단
ㆍ자동 업데이트 기능 존재
ㆍyum, dnf 같은 패키지 매니저 없음
ㆍ시스템 변경 불가능
ㆍ롤백 기능
ㆍ모니터링은 AWS 통합 도구 사용 가능
ㆍ문제 해결: Admin Container 필요 

Amazon Linux 2
ㆍ일반 리눅스 OS
ㆍ다양한 sw를 설치하고 실행 가능
ㆍSSH 접속하여 직접 서버 관리 가능
ㆍ수동/자동 업데이트 기능 선택 
ㆍyum, dnf 같은 패키지 매니저로 필요한 프로그램 설치 가능
ㆍ시스템 변경 가능
ㆍ모니터링은 다양한 도구 사용 가능
ㆍ문제 해결: 직접 접근 가능

 

[도전과제7] 

Private ECR Repo 생성 및 이미지 업로드 및 파드 사용(이미지 다운로드)해보기

 

7.1 CloudFormation을 활용하여 ECR 생성

AWSTemplateFormatVersion: "2010-09-09"
Description: "CloudFormation template to create a Private ECR repository"

Resources:
  MyECRRepository:
    Type: AWS::ECR::Repository
    Properties:
      RepositoryName: my-private-ecr
      ImageScanningConfiguration:
        ScanOnPush: true

 

 

7.2 EC2 Shell Script를 활용하여 ECR 인증

# private ECR 로그인
aws ecr get-login-password --region ap-northeast-2 | docker login --username AWS --password-stdin 855855905896.dkr.ecr.ap-northeast-2.amazonaws.com

# nginx 이미지 pull
docker pull nginx:latest

# ECR용 태그 설정
docker tag nginx:latest <계정ID>.dkr.ecr.ap-northeast-2.amazonaws.com/test8/my-nginx:latest

# ECR에 이미지 push
docker push <계정ID>.dkr.ecr.ap-northeast-2.amazonaws.com/test8/my-nginx:latest

 

Docker hub에서 nginx 이미지를 가져와서 ECR에 푸시했습니다.

 

7.3 Private ECR에서 이미지 가져와서 Pod 배포

# Private ECR 이미지 가져와서 배포
apiVersion: v1
kind: Pod
metadata:
  name: my-nginx-pod3
  namespace: test8
spec:
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 1
          preference:
            matchExpressions:
              - key: node-type
                operator: In
                values:
                  - public1
  containers:
  - name: nginx
    image: 855855905896.dkr.ecr.ap-northeast-2.amazonaws.com/test8/my-nginx:latest
    ports:
    - containerPort: 80

 

 

배포 성공

 

 

[도전과제8] 

Place Kubernetes Pods on Amazon EKS by using node affinity, taints, and tolerations

 

node affinity, taints, and tolerations

Node Affinity
ㆍ"이 Pod는 특정 Node에 실행되고 싶어요!" 신호
ㆍ노드 선호도 지정

Taints
ㆍ"이 Node는 아무나 받아주지 않아요!"
ㆍNode가 특정 Pod들은 거부하는 속성

Tolerations 
ㆍ"저는 Taints가 있어도 괜찮아요!"
ㆍPod가 Taints가 있는 Node에도 할당(스케줄링) 되도록 허용

 

 

7.2 Worker Node 2ea 준비 (1)

# ng-public-1
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

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


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

nodeGroups:
  - name: ng-public
    minSize: 1
    maxSize: 2
    desiredCapacity: 1
    instanceType: "t3.medium"
    tags:
      "off": "exception"
      "node-type": "public1"

 

 

7.2 Worker Node 2ea 준비 (2)

# ng-public-2
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

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


vpc:
  id: vpc-4  # 기존 VPC ID
  subnets:
    public:
      ap-northeast-2b:
        id: subnet-

nodeGroups:
  - name: ng-public-2
    minSize: 1
    maxSize: 2
    desiredCapacity: 1
    instanceType: "t3.medium"
    tags:
      "off": "exception"
      "node-type": "public2"

 

 

7.3 Node Affinity 사용한 Pod

# Node Affinity 사용
apiVersion: v1
kind: Pod
metadata:
  name: my-nginx-pod3
  namespace: test8
spec:
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 1
          preference:
            matchExpressions:
              - key: node-type
                operator: In
                values:
                  - public1
  containers:
  - name: nginx
    image: 855855905896.dkr.ecr.ap-northeast-2.amazonaws.com/test8/my-nginx:latest
    ports:
    - containerPort: 80

label이 node-type: public1 이 붙어있는 node에 스케줄링하도록 Pod.yaml을 작성하였습니다.

 

Node에 Label 할당
kubectl label nodes <node-name> node-type=public1

 

정상적으로 node-type public1 label이 할당된 노드에 파드가 스케줄링 됩니다.

 

 

7.3 taint와 tolerations를 활용한 Pod 배포

# node에 taint 설정
kubectl taint nodes ip-192-168-1-42.ap-northeast-2.compute.internal node-type=public1:NoSchedule

node-type=public1 이라는 label이 달린 192.168.1.42 Node에게 taint를 설정합니다.

 

# tolerations 사용
apiVersion: v1
kind: Pod
metadata:
  name: my-nginx-pod
  namespace: test8
spec:
  tolerations:
    - key: "node-type"
      operator: "Equal"
      value: "public1"
      effect: "NoSchedule"
  containers:
  - name: nginx
    image: 855855905896.dkr.ecr.ap-northeast-2.amazonaws.com/test8/my-nginx:latest
    ports:
    - containerPort: 80

 

taint 설정한 label(node-type=public1)과 동일한 tolerations를 설정한 pod를 배포합니다.

 

일반 Node에 정상 배포 되고, taint가 있는 Node 또한 NoSchedule 되지 않고, 정상적으로 배포됩니다.

 

taint 설정을 주석 처리하고 pod, pod2, pod3를 배포해보았습니다.

taint 설정한 label(node-type=public1)이 달린 Node에는 스케줄링이 되지 않는 모습을 볼 수 있습니다.

 

 

배포 성공

 

 

[도전과제9] 

Enhanced VPC flexibility: modify subnets and security groups in Amazon EKS

 

# ng-public-3
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

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


vpc:
  id: vpc-
  subnets:
    public:
      ap-northeast-2a:
        id: subnet-

nodeGroups:
  - name: ng-public3
    minSize: 1
    maxSize: 2
    desiredCapacity: 1
    instanceType: "t3.medium"
    tags:
      "off": "exception"
      "node-type": "public1"
    securityGroups:
      attachIDs:
        - sg-06b

 

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

 

 

배포 성공