모듈 1 Kubernetes 의 기본 개념

컨테이너의 이점

• 이동 가능성
  • 컨테이너화 플랫폼을 지원하는 모든 운영 체제(OS)에서 컨테이너를 사용 가능하다.
  • 서로 다른 종속성과 서로 다른 라이브러리를 가진 여러 애플리케이션 버전을 동시에 실행할수 있다.
• 클라우드 배포 가능
  • 최신 클라우드 플랫폼에서 실행하기 적합
  • EC2, Lambda, EKS, ECS 등 ...
• 확장성
  • 원하는 만큼 컨테이너 수를 확장하거나 축소 가능하다.
• 지속적 배포
  • 지속적 배포는 애플리케이션을 자주 자동 배포하는 방법
  • 컨테이너는 자동화된 빌드, 테스트, 배포 파이프라인과 통합된다.
  • 개발환경과 프로덕션 환경 간 차이릘 최소화 시킬 수 있다.
• 마이크로 서비스에 적합
  • 컨테이너를 사용하면 컨테이너에 장애가 발생할 경우 해당 컨테이너를 종료하고 특정 서비스에 새 컨테이너를 신속하게 시작할 수 있다.

컨테이너 오케스트레이션

• 수백 개의 컨테이너가 있는 전체 프로덕션 환경이 존재한다고 가정해본다. 대규모 컨테이너를 직접 관리하는 것은 매우 복잡하고 어려운 환경이다.
• 컨테이너 오케스트레이션 도구는 컨테이너의 관리,배포, 크기 조정을 자동화하는데 사용되는 도구이다.
• kubernetes는 오픈소스이며, 강력하고 역동적인 커뮤니티의 지원을 받는다는 특징이 존재한다. 약자로 k8s 라고 불리기도한다.
• k8s는 리눅스 재단 내의 Cloud Native Computing Foundation(CNCF)에서 관리하고 있다.

Kubernets 내부

PodSpec으로 Pod 정의

• Pod: 쿠버네티스에서 생성하고 관리할 수 있는 가장 작은 배포 단위이다. 하나 이상의 컨테이너 그룹으로 구성되며, Pod 안의 컨테이너들은 네트워크와 스토리지 같은 리소스를 공유한다.
• Pod를 생성하기 위해서 YAML 형식의 매니페시트 파일을 작성한다. 이 파일은 크게 metadata와 spec 으로 구성된다.
  • metedata : Pod의 이름, 레이블 등 Pod를 식별하기 위한 정보를 포함
  • spec : Pod의 상세 명세를 정의하는 부분이다. Pod 내에서 실행될 컨테이너의 정보, 사용할 볼륨, 재시작 정책 등이 포함된다.
• PodSpec의 예시

apiVersion: v1
kind: Pod
metadata:
  name: webapp
  labels:
    app.kubernetes.io/name: webapp
spec:
  containers:
  - name: nginx
    image: nginx:1.25.1
    ports:
    - containerPort: 80

Pod : 통신

• 각 Pod는 쿠버네티스 클러스터 내에서만 통신할 수 있는 고유한 IP 주소를 할당받는다.
• Pod는 영구적인 존재가 아니라, 언제든 장애로 인해 사라지고 새로 생성될 수 있는 휘발성(ephemeral) 자원이다.
• Pod가 교체되면 할당되었던 IP 주소도 함께 변경된다. 이러한 이유로 Pod의 IP에 직접 접근하는 대신, '서비스(Service)'라는 오브젝트를 통해 Pod에 안정적으로 접근한다.

서비스(Service)

• 여러 Pod의 논리적 모음과 여기에 액세스하는 수단이다.
• 사용 가능한 Pod 세트로 지속적으로 업데이트 되며, 각 Pod IP 주소는 통신의 엔드포인트 역할을 한다.
• 각 서비스에는 ClusterIP라고 하는 고유한 가상 IP 주소가 할당된다.
• 클라이언트는 서비스의 가상 ClusterIP 주소에 연결되고, 서비스는 통신 요청을 서비스 뒤에 있는 엔드포인트 Pod 중 하나로 변환된다. 이렇게 하면 다른 Pod의 주소를 직접 추적할 필요가 없다.

Kubernets 내부

제어 영역 및 데이터 영역

• 쿠버네티스 클러스터는 하나 이상의 노드(Node)로 이루어지며, 노드는 역할에 따라 제어 영역(Control Plane)과 데이터 영역(Worker Nodes)으로 나뉜다.
  • 제어 영역(Control-Plane) 구성 요소는 클러스터에 관해 스케쥴링과 같은 전역 결정을 내린다.
  • 데이터 영역(Work Node)은 컨테이너 애프릴케이션을 실행하는 노드로 구성된다.

컨트롤러

• 컨트롤러는 쿠버네티스의 핵심 원칙을 구현하는 요소이다.
• 제어 루프 (Control Loop): 컨트롤러는 사용자가 정의한 '원하는 상태(Desired State)'와 클러스터의 '현재 상태(Current State)'를 지속적으로 비교하고 감시한다.
• 만약 두 상태가 다르다면, 컨트롤러는 현재 상태를 원하는 상태와 일치시키기 위한 작업을 수행합니다. 상태가 동일하다면 아무 작업도 하지 않습니다.

제어 영역의 구성 요소

• 제어 영역은 클러스터를 관리하기 위한 여러 핵심 컴포넌트로 구성된다.
• 컨트롤러 관리자
  • 핵심 kubernets 제어 루프인 컨트롤러를 실행하고 클러스터 이벤트를 감지하고 이에 대응한다.
• 클라우드 컨트롤러
  • AWS, GCP, Azure 등 특정 클라우드 플랫폼과 상호작용하는 컨트롤러를 실행한다.
  • 클라우드의 로드밸런서나 스토리지 같은 자원을 쿠버네티스 오브젝트와 연결하는 역할한다.
• 스케줄러
  • 새로 생성된 Pod를 감시하고, 리소스 현황 등 여러 조건을 고려하여 해당 Pod를 실행할 최적의 워커 노드를 찾아 배정한다.
• API 서버
  • 제어 영역의 프론트엔드(Front-end) 역할을 하며, 클러스터의 모든 내부/외부 통신을 처리하고 검증하는 중심 허브다.
  • kubectl, 워커 노드 등 모든 구성 요소는 API 서버를 통해서만 상호작용한다.
• etcd
  • 제어 영역의 핵심 구성 요소로, 쿠버네티스 클러스터의 모든 설정 데이터와 상태(어떤 Pod가 어느 노드에 있는지 등)를 저장하는 고가용성 분산 키-값 저장소이다.

데이터 영역

• 노드는 kubernetes 런타임 환경을 지원한다.
• 노드는 Pod를 실행하는 데 필요한 서비스를 포함하고,제어 영역 구성 요소에서 관리된다.
• 컨테이너 런타임
  • 노드는 컨테이너 런타임도 실행한다.
  • kubernetes는 Docker 엔진 및 containerd와 같은 인기 있는 런타임을 비롯하여 여러 런타임을 지원한다.
• kubelet
  • 노드에서 실행되는 기본 에이전트
• kube-proxy
  • 각 노드에는 Pod 외에 네트워킹에 도움이 되는 kube-proxy가 포함된다.
  • 호스트에서 네트워크 규칙을 유지 관리하고, 필요할 수 있는 모든 연결을 전달한다.

제어 영역과 데이터 영역 간 통신

• 제어 영역과 데이터 영역이 함께 작동할 때 제어 영역 노드는 컨트롤러와 스케줄러를 사용하여 노드의 상태가 원하는 상태가 되도록 한다.
• 제어 영역과 노드 간의 통신읜 API 서버를 통해 kubelet으로 전달된다.
• kubelet은 Pod에 올바른 컨테이너가 실행되도록 하고 그 컨테이너가 정상 상태가 되도록 한다.
• kubelet은 다음 활동을 수행한다.
  1. (제어 영역의 API 서버 또는 로컬 구성 파일에 의해) 해당 노드에 할당된 Pod를 감시한다.
  2. 필요한 볼륨 탑재
  3. Secret 다운로드
  4. 컨테이너 런타임을 사용하여 Pod의 컨테이너 실행
  5. 요청된 컨테이너 활성 프로브 또는 상태 검사 주기적 실행
  6. 노드의 상태를 시스템의 나머지 부분에 다시 보고

Pod 스케쥴링

• kubernetes 스케줄러를 사용하여 Pod를 스케쥴링 할 수 있다.
• 스케줄러는 Pod에 필요한 리소스를 확인하고 그 정보를 사용하여 스케쥴링 결정에 영향을 준다. 스케줄러는 필터를 사용하여 pod 배치에 부적격한 노드를 제외한 다음, 체계에 따라 최종 노드를 결정한다.

필터링 : 리소스 요구사항

• 리소스 필터를 사용하는 경우 스케줄러는 Pod에 필요한 리소스가 어떤 노드에 있는지 고려한다.
• 여기에는 CPU, 메모리, 디스크 공간, 사용 가능한 포트 등이 포함된다.
• limits 파라미터는 Pod가 실행된 후에 리소스에 대한 한도를 정의한다. 실행 중인 컨테이너는 리소스 사용량을 원래 요청량에서 정의된 한도까지 버스트할 수 있다.
• 컨테이너가 메모리 한도를 초과하면 해당 컨테이너가 실행중인 노드의 Kubelet이 컨테이너를 종료시킨다.
• 리소스 요구 사항은 컨테이너 레벨에서 정의되므로 모든 컨테이너에 대해 요청된 리소스의 합계에 따라 Pod의 리소스가 정의된다.

필터링 : 토폴로지 - Taint 및 Toleration

• 볼륨 및 리소스 제약 조건을 충족한 후에는 스케줄러가 pod 배치를 미세조정하도록 설정된 제약 조건을 고려한다.
• 사용자는 노드 수준과 Pod 수준에서 스케쥴링 제약 조건을 설정할 수 있다.
• Taint 및 Toleration 은 특정 노드에 배치할 수 있는 노드를 제어하기 위해 함께 작동하는 설정
• Taint
  • Taint는 Pod 배치를 방지하는 노드의 속성
  • 테인트된 노드는 해당 Taint를 허용하는 Pod만 수락한다.
  • 노드를 테인트하려면 키=값 쌍 ex)spot =true 을 지정한 다음, Taint가 고려되는 경우를 정의하는 작업을 추가한다.
• Toleration
  • Toleration은 Pod가 테인트된 노드에서 실행될 수 있도록 지정해주는 Pod 속성
  • Toleration은 특정 Taint와 일치해야 한다.

스코어링 : 토폴로지-선호도

• 경우에 따라 Pod가 특정 노드에서 스케쥴링되도록 해야 할수 있다.
• Pod에 특정 하드웨어 리소스가 필요하다고 가정해본다. Pod가 특정 노드 또는 인스턴스 유형에서 실행되도록 하려면 선호도 설정을 사용하면 된다.
• 선호도 설정은 Taint 및 Toleration과 함께 사용할 경우 올바른 Toleration이 있는 Pod만 노드로 스케쥴링할 수 있도록 한다.

필터링 : 볼륨 요구 사항

• 스케줄러는 Pod가 요청한 볼륨(PersistentVolume)을 특정 노드에서 사용할 수 있는지 확인한다. 예를 들어, 특정 클라우드 공급자의 스토리지 볼륨은 특정 지역이나 가용 영역(Availability Zone)에 있는 노드에서만 연결할 수 있다.
• 스케줄러는 이러한 볼륨 토폴로지(topology) 제약 조건을 만족하지 못하는 노드를 필터링 단계에서 제외한다.

Kubectl 유틸리티(데모)

Kubectl 도구

• kubectl을 사용하여 제어 영역 노드와 통신할 수 있다.
• kubectl은 특정 클러스터에서 kubernetes API 서버와 통신하기 위한 명령줄 인터페이스(CLI)이다.
• kubectl은 리소스를 생성하고, 클러스터와 리소스에 대한 세부 정보를 확인하고, 문제 해결 도구에 액세스하는 명령을 제공한다.
  kubectl [명령] [유형] [이름] [플래그]
  • 명령 : 수행할 작업 지정
  • 유형 : 리소스 유형 지정
  • 이름 : 리소스 이름 지정
  • 플래그 : 선택적 플래그 지정

kubernetes 객체

Namespace

• kubernetes의 또 다른 기본 객체는 Namespace이다.
• 일반적으로 동일한 클러스터 안의 리소스 이름들은 고유해야 한다.
• 하지만 Namespace에서는 동일한 물리적 클러스터내에 가상 클러스터를 생성할 수 있다. 물리적 클러스터는 서로 다른 Namespace에 있는 동일한 이름의 리소스를 지닐 수 있다.
• Namespace는 여러 팀이나 프로젝트에서 동일한 클러스터를 사용하는 경우에 유용하게 사용된다.

ConfigMap 과 Secret

• kubernets에서 ConfigMap는 데이터를 키-값 쌍으로 저장하는 API 객체이다.
• configMap 데이터는 환경 변수, 명령줄 인수 또는 볼륨의 구성 파일로 사용할 수 있다.
• Secret은 민간함 기밀 정보가 포함된 kubernetes 객체이다. 이를 보호하기 위해서는 클러스터에 대한 추가 구성이 필요하다.

모듈 2 : Amazon EKS 기본 사항

Amazon EKS 소개

• 모듈 1에서 kubernetes가 컨테이너 워크로드를 관리하는데 효과적인 방법임을 알게 되었다. 어렵지는 않지만 kubernetes를 시작하고 실행하는 것은 복잡할 수 있다.
• Amazon EKS는 AWS에서 kubernets를 사용하여 컨테이너식 애플리케이션을 배포, 관리, 크기 조정할 수 있는 관리형 kubernetes 제어 영역 서비스다.
• Amazon EKS는 kubernets 클러스터를 위한 제어 영역을 생성하고 관리한다. 또한 여러 AWS 가용 영역에 걸쳐 kubernets 관리 인프라를 실행하여 단일 장애 지점을 제거한다.
• Amazon EKS는 사용자가 원할 경우 데이터 영역(노드)의 요소를 관리할 수도 있다.
• Amazon EKS는 다음과 같은 AWS 서비스와 긴밀하게 통합되어 있다.
  • 로드 분산을 위한 Application Load Balancer
  • 역할 기반 액세스 제어를 위한 AWS (IAM)
  • Pod 네트워킹을 위한 Amazon VPC

Amazon EKS 제어 영역

Amazon EKS : 관리형 Kubernets 제어 영역

• 표준 kubernetes 배포에서 사용자는 제어 영역의 모든 요소를 설계, 구현, 유지, 관리 하고 노드를 관리해야 한다. 이 모든 관리는 Pod에서 실행되는 애플리케이션을 생성하고 컨테이너화하는 작업이 추가되게 된다.
• Amazon EKS는 각 클러스터의 etcd 지속성 계층과 kubernets API 서버의 가용성과 확장성을 자동으로 관리한다. Amazon EKS를 이용하면 데이터 영역과 Pod를 실행하는 데 온전한 시간을 부여할 수 있다.

Amazon EKS 제어 영역 내부

• kubernetes 제어 영역 구성요소 외에도 Amazon EKS 관리형 제어 영역에는 kubernetes 제어 영역에 대한 몇가지 추가 기능이 포함되어있다.
  • kubernetes 용 AWS IAM Authenticator
  • AWS Fargate 스케줄러
• kubernets 데이터 영역을 호스팅하는 방법도 선택가능하다.
  • Amazon EC2 인스턴스를 사용하는 self managed 노드
  • Amazon EC2 Auto Scaling 그룹을 사용하여 Amazon EC2 인스턴스를 관리하는 Amazon EKS 관리형 그룹
  • 노드당 1개의 Pod의 서버리스 호스팅을 위한 AWS Fargate

가용성 유지 관리

• Amazon EKS는 Kubernets 제어 영역을 실행한다. 비정상 제어 영역 노드를 자동으로 탐지하여 교체하므로 kubernetes 실행에 따른 운영 부담이 대폭 제거된다.
• Amazon EKS를 시작하려면 노드 클러스터를 프로비저닝해야 한다.
• Amazon EKS는 가용성이 높고 안전한 구성으로 kubernetes 제어 영역의 프로비저닝, 크기 조정, 관리를 처리한다. 사용자의 경우 GUI 또는 CLI를 사용하여 Amazon EKS 클러스터에 연결한다. 이후 애플리케이션을 Amazon EKS 클러스터에 배포 할 수 있다.

Amazon EKS 데이터 영역

Amazon EKS 데이터 영역 관리

• 노드가 많은 복잡한 인프라를 관리하고 자동 크기 조정 및 업데이트를 신경 쓰는 일은 쉽지 않다. 또한 클러스터에 노드를 프로비저닝하는 여러 팀이 있는 경우, 프로비저닝 방식이 각각 달라 이를 표준화 하기 어렵다.
• Amazon EKS를 통해 데이터 영역의 일부 또는 전부를 관리하면 인프라를 간소화 하고 표준화를 유지 할수 있다.

데이터 영역 옵션

• kubernetes 제어 영역은 Amazon EKS가 전적으로 관리하지만 데이터 영역의 경우 3가지 유형의 노드를 관리할 수 있다.
  • 전적으로 사용자가 관리하는 self managed 노드
  • Amazon EKS가 부분으로 관리하고 사용자가 리소스에 대한 제어를 할 수 있는 관리형 노드 그룹
  • Amazon EKS에서 전적으로 관리하는 Fargate 노드

관리형 노드 그룹

• 관리형 노드 그룹은 Amazon EKS API를 사용하여 Amazon EKS 클러스터용 컨테이너를 실행하는 Amazon EC2 인스턴스를 시작하고 관리한다.
• 특징
  • 프로비저닝 지원 : Amazon EKS에 최적화되고 Auto Scaling 그룹이 지원하는 최신 AMI를 사용하여 멀티가용영역 그룹을 한번에 배포 가능
  • 관리 지원 : 관리형 노드 그룹의 상태 모니터링을 처리
  • 업데이트 지원 : 하나의 명령으로 관리형 노드 그룹을 클러스터에 맞는 최신 AMI 버전으로 업데이트 가능
  • 크기 조정 제어 : 관리형 노드 그룹은 노드 크기 조정을 처리한다.
  • eksctl와 함께 작용 : eksctl을 사용하여 관리형 노드 그룹을 프로비저닝 할 수 있다.

AWS Fargate

• Amazon EKS가 데이터 영역을 완전히 관리하도록 한다.
• AWS Fargate는 kubernetes 데이터 영역의 전체 인프라를 관리하기 때문에 사용자는 Pod 실행에 대해서만 신경 쓰면 된다.
• 특징
  • 네이티브 : AWS Fargate는 네이티브 Kubernetes Pod를 실행한다.
  • 적정 규모 : AWS Fargate는 Pod 및 리소스에 필요한 리소스를 동적으로 프로비저닝한다.
  • 빠르고 간단함 : AWS Fargate는 빠르게 크기 조정이 가능하다.
  • 비용 최적화 : 실행한 Pod 비용만 지불한다.

실습 1 : Kubernetes Pod 배포

• 실습 1에서는 아래 과제를 수행한다.
  1. Kubernetes 애플리케이션을 생성하고 배포한다.
  2. 배포, 서비스 및 네임스페이스 리소스를 생성한다.
  3. 네임스페이스에서 리소스를 본다.
  4. 서비스 및 배포의 세부 정보를 이해한다.
  5. Pod의 세부 정보를 이해한다.
  6. Pod에서 명령을 실행한다.
  7. 애플리케이션을 삭제한다.
• 실습환경

과제 1 : Kubernetes 애플리케이션 배포

• 제공되어있는 EC2 인스턴스 중 bastion Host에 접속 수행(Session Manager 이용)

• kubectl이 설치되어 있는지 확인 kubectl version --output=yaml
  

• kubectl 이 생성된 것을 확인했기 때문에 생성된 네임스페이스를 보기 위해 아래 명령어를 입력한다. : kubectl get namespaces
  

• 현재 workshop 네임스페이스에 배포된 리소스를 보기 위해 다음 명령어를 입력한다. : kubectl get deploy,svc,pod -n workshop

  • 실습 예시 페이지에서는 pod 부분이 정상적으로 running되어 있는데 여기서는 이미지를 찾을수 없는 오류(ImagePullBackOff)가 발생했다. 아마 기간이 좀 지난 실습이라서 태그가 삭제되어있을 가능성이 존재한다. 하지만 실습에 지장이 없을 것 같아 그대로 수행한다.

• 해당 실습에는 3개의 마이크로 서비스로 구성된다.

  • 프런트엔드 : 프런트엔드 서비스는 애플리케이션 UI를 표시
  • Product Catalog : 카탈로그에 제품을 추가하고 제품 세부 정보를 검색
  • Catalog Detail : 공급업체 이름 및 버전 번호를 반환

• 프런트엔드 마이크로서비스와 백엔드 마이크로서비스 중 하나는 이미 클러스터에 배포되어 있다. 이번 단계에서는 Catalog Detail 마이크로서비스를 배포하고 노출하고자 한다.

  • 이 실습에 필요한 모든 이미지는 미리 빌드되어 있다. 공개 ECR에서 가져오는 대신 다음 명령을 실행하여 이미지 경로를 업데이트하면 된다.

    export AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
    aws configure set region $(curl -s http://169.254.169.254/latest/meta-data/placement/region)
    export AWS_REGION=$(aws configure get region)

• Catalog Detail 마이크로서비스를 배포하기 위해서 먼저 프런트엔드 배포를 수행하는 매니페스트부터 생성한다.

  cat << EOF > ~/proddetail-deployment.yaml
  apiVersion: apps/v1
  kind: Deployment
  metadata:
  name:  proddetail
  namespace: workshop
  spec:
  replicas: 1
  selector:
   matchLabels:
     app: proddetail
  template:
   metadata:
     labels:
       app: proddetail
   spec:
     containers:
       - name: proddetail
         image: "$AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/eks-workshop-demo/catalog_detail:1.0"
         imagePullPolicy: Always
         ports:
           - name: http
             containerPort: 3000
             protocol: TCP
         resources: {}
  EOF

  • EOF 라인까지 ~/proddetail-deployment.yaml 파일로 복사 붙여 넣는다.
  • v1 APIVersion을 참조하여 Kubernetes deployment 객체를 생성 한다. deployment는 매니페스트에 정의된 애플리케이션 상태를 유지하려고 시도할 때 Pod를 동적으로 생성 및 삭제를 수행한다.
  • metadata 레이블은 배포에 이름을 할당하고 배포가 배포될 네임스페이스를 선택하는 데 사용된다. 네임스페이스를 선택하지 않으면 default에 배포된다.
  • kind 레이블은 생성하려는 kubernetes 객체의 선택하고 spec은 레이블은 해당 상태를 정의한다.
  • ReplicaSet는 특정 수의 Pod 인스턴스가 항상 실행되고 있는지 확인하는 데 사용된다. 이번 실습에는 1로 설정해 두었는데 이 경우, 한 개의 Pod 인스턴스가 항상 생성되어야 한다. 만약 3으로 값을 변경하게 된다면 복제본 2개가 추가 생성되고 관리된다.
  • selector 필드는 Kubernetes에게 ReplicaSet가 획득해야 할 Pod를 알려준다.

    cat << EOF > ~/proddetail-service.yaml
    apiVersion: v1
    kind: Service
    metadata:
    name: proddetail
    namespace: workshop
    labels:
     app: proddetail
    annotations:
     owner: student
    spec:
    type: ClusterIP
    ports:
     - port: 3000
       name: http
    selector:
     app: proddetail
    EOF

  • pps/v1 APIVersion을 참조하여 Kubernetes Service 객체를 생성
  • 서비스는 Pod를 네트워크 서비스로 노출하는 데 사용
  • spec 필드는 서비스 상태를 정의한다. 이번 실습에는 ClusterIP 서비스를 생성한다. 이는 기본 서비스 유형이며 클러스터 내부에서만 액세스할 수 있다.
  • NodePort 또는 LoadBalancer 유형으로 설정된 서비스를 이용해야만 클러스터 외부로부터의 요청을 수락할 수 있다. 또한 이 서비스는 포트 3000에서 HTTP 트래픽을 수락하도록 설정한다.

• workshop 네임스페이스에 존재하는 frontend 와 prodcatlog 디플로이먼트 컨테이너 이미지를 업데이트 한다.

  kubectl set image deployment/frontend frontend=$AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/eks-workshop-demo/frontend_node:2.0 -n workshop
  kubectl set image deployment/prodcatalog prodcatalog=$AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/eks-workshop-demo/product_catalog:1.0 -n workshop

• 매니패스트 파일을 클러스터에 적용하기 위해 명령어를 입력한다.

  kubectl apply -f ~/proddetail-deployment.yaml
  kubectl apply -f ~/proddetail-service.yaml

• 생성 결과

• kubectl get service 명령어를 이용해실행되고 있는 로드밸런서를 확인하고, 이를 이용해 웹 페이지 접근

• proddetail 배포 및 서비스에 대한 매니페스트를 생성하고 배포해보았다.

모듈 3 : Amazon EKS 클러스터 구축 및 유지 관리

Amazon EKS 클러스터 생성

• 클러스터를 생성하기 전 클러스터에 액세스 하는데 사용할 시스템에 필요한 도구
  • eksctl : Amazon EKS에서 kubernetes 클러스터를 생성하고 관리하는 간단한 명령줄 유틸리티
  • aws CLI
  • kubectl
• 이 때, 클러스터 생성은 Amazon EKS에 의해 관리되는 제어 영역을 배포하는 프로세스를 의미 한다.

eksctl

• eksctl은 클러스터 및 노드 생성에 필요한 많은 단계를 자동화 한다.
  • 클러스터 및 노드에 대한 AWS IAM 역할을 생성
  • CIDR 192.168.0.0/16을 사용하여 전용 VPC를 생성
  • 클러스터 및 노드 그룹 생성
  • API 엔드포인트에 대한 액세스를 구성
  • 클러스터의 kubeconfig 파일을 작성

노드 배포

• Amazon EKS는 다양한 유형의 Amazon Machine Image(AMI)를 지원한다.
• Amazon EKS에 최적화된 AMI는 Amazon Linux이다.
• HashiCorp Packer로 사용자 정의 Amazon EKS AMI를 구축을 수행할 수도 있다.
• Bottlerocket는 Linux 기반 오픈 소스 운영체제이다. 이를 이용해서도 Amazon EKS를 구축 가능하다.
• 마지막으로 Winodw 운영체제에서도 동작시킬수 있다.

클러스터 생성을 위한 선언적 옵션

• Amazon EKS 클러스터 작업을 위한 콘솔 및 명령줄 옵션(AWS CLI, eksctl)외에도 AWS CloudFormation, AMazon EKS Blueprints, 코드형 인프라(IaC)와 같은 선언형 옵션ㅇ르 사용할 수도 있다.
• AWS CloudFormation을 사용하면 인프라를 코드로 취급하여 리소스를 스택으로 빠르고 일관성 있게 프로비저닝, 시작, 구성할 수 있다.
• EKS Blueprints는 워크로드를 배포 및 운영하는 데 필요한 운영 소프트웨어로 완전히 부트스트래핑된 전체 Amazon EKS 클러스터를 구성하는데 도움이 된다. EKS Blueprints는 AWS CDK를 사용하여 구축되었다.
• AWS SDK 및 Terraform, ClusterAPI 등 여러 서드파티 IaC 소프트웨어 도구도 사용할 수 있다.