학습주제
박주형 강사님의 [AWS 클라우드] 특강

학습내용

복습차원 내용
IAM에 부가적인 내용
쿠버네티스

아마존 EKS

아마존 이케이에스(Amazon ECS, Elastic Container Service)는 AWS(Amazon Web Services)의 관리형 컨테이너 오케스트레이션 서비스입니다. 이는 도커(Docker) 컨테이너를 실행하고 관리하기 위한 플랫폼을 제공합니다.
이케이에스를 사용하면 개발자는 컨테이너화된 애플리케이션을 쉽게 배포하고 실행할 수 있습니다. 이케이에스는 컨테이너 클러스터를 관리하며, 컨테이너를 여러 호스트에 분산하여 실행할 수 있습니다. 이를 통해 애플리케이션의 확장성과 가용성을 높일 수 있습니다.

오아시스 비즈니스 CTO
ittang
CREMAO

github.com/joo-pe

지금까지 했던것들도 겸사겸사 복습

AWS Cloud9 - 새로운 개념

Container란

어딘가에 배포를 한다거나, 로컬에서 프로그램을 짰는데 로컬에선 잘 돌아감.
다른 OS, 환경에 가면 안돌아감.
라이브러리 깔고, 버전도 맞추고 상당히 어려운 작업이 많았음.
MSA 기업들이 대규모 서비스보단, 몇십개 몇백개의 서버들을 올려놓고 마이크로 서비스를 함.
로컬에서 잘 짜도 어디서 에러가 날지 모름
빌드된 파일만 실행시키지말고, 내 환경 채로 배포해 버리자 - container
환경을 구성해주는 가상화 기술

도커라는 엔진만 있으면 어디서든 똑같이 구현할 수 있음.
CI/CD 할때 컨테이너 기반 배포를 많이 함.

도커 허브역할을 해주는 ECR
호스팅 ec2
관리, 스케줄링 - ECS, EKS

호스팅 - 인프라가 있는 ec2 기반 서비스, 서버리스 Fargate 방식 두가지
Doker를 사용할 때 ec2 위에 설치해도 됨. ECS 자체는 Fargate를 권고하고 있음.
ECS - 이미지를 올려놓고 task로 잡아서 서비스
EKS 쿠버네티스. 컨테이너들이 많아짐. 중앙 집중 마스터 관리 체제
ECS, EKS 쓰냐 말이 나올 수 있음. 소규모 컨테이너면 ECS로 충분. 몇백개 늘어나면 EKS 가 효과적

가상화 기술, 컨테이너 기술

확장 가능한 오픈소스 플랫폼
컨테이너 오케스트레이션 툴
여러가지의 컨테이너(이미지가 올라가있는) 관리 모니터링 구성 자동화 기술

목적


AWS EKS와 k8s는 조금 다름

EC2는 인프라가 있음. -IP, 도메인 없
Fargate은 인프라가 없음. 오로지 컨테이너를 위한 서비스

Control plane - 마스터, EKS, ECS로 구성
Data plane - EC2, Fargate로 구성

데이터 노드쪽에 보낼때 지속적으로 컨트롤하게 됨.
파드? 컨테이너를 컨트롤해주는 컨트롤러

우측에 컨테이너 이미지들이 하나씩 탑재되게 됨

이걸 컨트롤해주는게 Contron plane

ectd - 저장공간, DB, 레포지토리, 서버보면 etc 디렉토리, 디스트리뷰트가 합성, acid 등으로 불림
control manager- 정보를 가지고 컨트롤
스케줄러 - CPU, 진행정보를 가짐

각각의 워크노드들이 구성됨.
워크노드들은 ec2나 fargate 중 하나로 구성함
kubectl을 통에 제어

kublet에 전달

ECS로 따지면 하나의 서비스이자 task

ELB를 통해 사용자가 접근함
직접적을 붙기 위해선 ELB 통해서
Fargate는 IP, 도메인이 없기 떄문 대상그룹을 연결해서 서비스하게됨.
프론트, 백엔드, 데이터 서버가 이미지로 배포됨. 앱이나 웹으로 접근하는 사용자는 ELB로. ELB도 주소가 있지만, route53등을 통해 도메인 구입해서 접근

데이터 노드 구성

파드 안에 컨테이너가 여러개 구성

kubectl은 쿠버네티스 클러스터와 상호 작용하기 위한 커맨드 라인 인터페이스(CLI) 도구입니다. 개발자나 시스템 관리자는 kubectl을 사용하여 쿠버네티스 클러스터 내의 리소스를 생성, 수정, 삭제, 조회 등 다양한 작업을 수행할 수 있습니다. 이를 통해 파드, 서비스, 노드 등의 리소스를 관리하고, 애플리케이션 배포, 로깅, 모니터링 등을 제어할 수 있습니다.

kubelet은 쿠버네티스 노드(Node)에서 실행되는 에이전트 프로세스입니다. 각 노드에는 kubelet이 설치되어야 하며, kubelet은 마스터 노드로부터 받은 명령을 수행하여 해당 노드에 컨테이너를 관리합니다. kubelet은 파드 정의를 이해하고 파드가 올바르게 실행되도록 유지합니다. 또한 kubelet은 노드의 상태를 마스터에 보고하고, 컨테이너의 상태를 모니터링하여 필요에 따라 재시작하거나 복구합니다.

비동기로 서로 바라보고 있음. 신호에 대기하고 있음.

ctl 통해 실행 디플로이먼트 리소스에 도달, 컨트롤 매니저에서 와치로 보게됨. 레플리카 셋 생성. 워치로 등답받아 pod 생성. pod엔 각 컨테이너가 있음. 스케줄러가 인지해서
pod를 할당함.

쿠버네티스 어려움. 학습곡선도 어려움

Pod(파드)는 쿠버네티스(Kubernetes)에서 가장 작은 배포 단위로 사용되는 개념입니다.
파드는 하나 이상의 컨테이너 그룹을 포함하는 단일 실행 가능한 단위입니다. 일반적으로 관련된 컨테이너들이 함께 실행되는 논리적인 그룹입니다. 이 그룹은 동일한 노드에서 실행되며, 공유된 네트워크 네임스페이스와 스토리지를 갖습니다.
파드는 독립적인 IP 주소를 가지며, 서로 내부 네트워크를 통해 통신할 수 있습니다. 또한 파드 내의 컨테이너들은 동일한 호스트와 포트를 공유할 수 있습니다. 이를 통해 파드 내에서 컨테이너 간의 효율적인 통신과 협업이 가능합니다.

중앙 API 서버를 통해 스케줄러를 통해 관리함
내부적인 통신이 주기적으로 많이 일어남.
와치 개념이 카프카 개념 구독을 받아서. 한쪽은 계속 떠있고 - 이해안됨

내가 이걸 생으로 하게된다면, 하나하나 다 설정해줘야함. 굉장히 복잡하고 어려움.

이걸 대체해주는게 EKS
Node Group이라고 함

EKS이용하면 설정을 다 안해도 됨. - 편리함

클라우드를 이용한다는 건 서버 하나 ec2만 잘 써도 됨.
aws가 몇백가지 서비스가 있는건 좀 더 편리하게 쓸수 있게 함에 있음

콘솔
CLI 통해서도
eksctl
Terraform 인프라로 전문적으로 코드를 관리해줌

이번엔 eksctl로 eks를 생성

CLI
AWS 콘솔에 접속해서 access 키를 받아서 제어함.

AZ 가용영역을 구성
각각의 노드를 만들어서 보여줄 예정

마스터 노드에서 다 해준다고 얘기했었는데 k8s 와 다른점은
IAM 인증을 받아 서비스
내가 만들고 다른사람이 쓰려고 하면 권한을 줘야함
RBAC에 있는 권한에 따라 역할 수행

JSON을 보면
특정 사람이 접근해야한다고 하면 맵을 할당해줘야함
어떤 컨트롤할 수 있는지

도커 컨테이너에서 나오는 포트, 외부에 있는 포트와 -p 옵션을 줘서 실행시켰음. 별도의 포트 연결작업이 있었음

컨테이너를 컨트롤할수있는 각각의 pod
VPC 할당하면, CIDR 255개의 서브넷을 잡았다고 하면 내 pod는 240여개정도 pod사용 가능. 내가 얼마나 pod를 띄울것인가, 내가 이미지 몇개 쓸것인가 계산해서 CIDR 구성해야함.

Cloud9은 클라우드 기반의 통합 개발 환경(IDE, Integrated Development Environment)입니다. 이는 웹 브라우저를 통해 접근하여 소프트웨어 개발 작업을 수행할 수 있는 도구입니다.

개발환경을 제공. 로컬에서 mac, 윈도우 환경이 클라우드에 구성되어있음. 클라우드 IDE 환경

eks 서비스 들어감

k8s 마스터 노드를 만들수 있는 화면

클러스터를 생성
iam 역할 선택

VPC, 서브넷 설정
어떤 서비스를 만들려면 VPC 먼저 만들어야함. 우리만의 서비스나 프로젝트에 맞게 VPC가 구성이 되어야 안정적, 보안적임

로깅 뭘할건지 선택

간단하게 생성 가능
아까의 복잡한 개념들을 하나씩 할 필요가 없음

세부설정을 cloud9에서 해본다

나만의 id를 만듦
얘도 결국 ec2 위에 만들어짐

하단에 콘솔
나만의 로컬 PC라고 생각하면 됨.

인스턴스에 역할을 부여할 수 있음
ec2에 역할을 부여하고 싶다면
작업 - 보안 - IAM 역할 수정


클라우드9에서 eks에 대해 전체적인 권한을 갖게 됨.

짧은시간에 전체를 알 수 는 없음. 이렇게 진행한다 정도로 이해하기.
AWS CLI로 작업할 예쩡

AWS CLI 설치

대시보에서 컨토를하는게 아닌 CLI로 사용

kubectl 설치

실행 권한 부여

eksctl 설치

환경변수를 잡아줘야함
리전 선택, 내 계정 ID, AWS CLI 통해서 해야함.

내 계정 ID. 매번 치기 번거롭기 때문

eks, ecs 도커파일로 만든 이미지를 사용한다는 것
ECR에 이를 올려야함

도커파일이 있음
이를 빌드해서 이미지 만드는것을 함.
이를 ECR에 올림

ECR에 있는걸 끌어다가 하드로 올려서 서비스할 예정
이번에 저 ECR 레포 있는걸 지우고 만드는 것도 시연.

지난 수업때 s3를 CLI로 만들었던 것처럼 ECR도 만들 수 있음



이 레포에 푸시명령보기

저 명령어대로 PUSH 할 수 있음

로그인 해주고

빌드를 해준다
도커 파일이 있는 위치로 가야함


비용이 들고 하다보니 Credit이 없이는 연습하기가 어려움

모르면 GPT에게 물어보면서 하자

CLI로 배포된 것을 확인할 수 있다

이제 클러스터를 만들어본다

YAML(YAML Ain't Markup Language)은 사람이 읽기 쉽고 기계가 해석하기 쉬운 형식의 데이터 직렬화 언어입니다. YAML은 데이터를 계층적 구조로 표현하고, 들여쓰기를 통해 구조를 표현합니다.
YAML 파일은 일반적으로 설정 파일이나 데이터 파일로 사용됩니다. 다양한 소프트웨어와 도구에서 YAML을 지원하며, 특히 컨테이너 오케스트레이션 시스템인 쿠버네티스(Kubernetes)에서 YAML 파일을 사용하여 애플리케이션의 구성과 배포를 정의합니다.
YAML 파일은 키-값 쌍으로 구성된 맵이나 배열의 형태로 데이터를 표현합니다. 예를 들어, YAML 파일에서는 다음과 같은 형식으로 데이터를 작성할 수 있습니다:

CLI로 알아서 설정값을 넣어줄 수 있음.

IAM

AWS 이용하게 되면 가장 많이 발생하는 에러가 IAM에러.

대시보드가 워낙 잘되어 있음.
CLI는 복잡해보임

현업은 대부분 CLI 사용
웹 화면을 통해 IAM 작업을 하게 되면
권한없음. 실행권한 없음.

IAM 사용자
IAM 역할 - 정책. ec2에 접근할 수 있는 정책 . RDS 접근할 수 있는 정책.
정책은 사용자가 가질 수도 있고, 역할이 가질 수 도 있음.
사용자는 정책을 갖게되면 상시 갖게됨 보통 GROUP 으로 관리
역할은 임시자격증 1시간

PRINCIPAL - ACCOUNT 요청 주체
역할은 정책의 묶음
보통은 기본 역할을 만들어주고 그거 써도 되긴 하는데, 나중에 권한 에러가 많이 남.

기본적인 root 계정이 있음

이 5가지로 JSON 부여
하나하나의 계정을 ARN

Action ec2, rds, s3등
Resource-목적지가 되는 서비스
Condition-CURD외에 세부적인 조건들. 도메인, IP에 대해 컨터롤해야한다

실질적으로 서비스를 하게되면
권한에러가 남. 그 인스턴스에 할당되어 있는 정책이 허가를 안하고 있다는 뜻

예를들어
코드 빌드를 한개 만든다고 하면
역할을 넣어주게 되어있음
새로 만들어준거 넣고 넘어가기도 함
s3에 대해 파일, dynamoDB에서 받아온다고 하면, 그 역할이 없을 수 있음
인스턴스 만들때마다 역할은 무조건 선택하게 되어있음
권한 에러가 나면 IAM 에 가서 정책을 추가해줘야 함

만일 내가 dynamoDB를 쓰고 싶다면 권한을 주어야함


이런식으로 추가해줄 수 있음

정책은 크게 두가지

두번째는 이번 수업때 Redshift가 S3에 대해 접근 권한 갖게 할때.
Resource-based 정책

컨테이너 이미지가 들어가는 포드
포드를 하기 위해선 레플리카셋

레플리카셋은 파드의 가용성과 확장성을 관리하며, 필요에 따라 파드의 수를 자동으로 조정합니다. 레플리카셋은 또한 롤링 업데이트를 통해 애플리케이션의 업그레이드를 수행하고, 장애 발생 시 자동으로 파드를 복구하는 기능을 제공합니다. 따라서 레플리카셋은 안정적이고 신뢰할 수 있는 애플리케이션 배포와 관리를 위해 중요한 역할을 합니다.

모니터링에 대해 다양한 도구들이 있음
AWS에선 Cloud Watch 사용

관리하고 있는 것들을 한눈에 볼 수 있다
클러스터가 1개 만들어지고 각각의 노드를 확인
쿠버네티스 자체에서도 모니터링 할수 있음
네임스페이스가 만들어지고
각각의 서비스들을 볼 수 있음


cpu나 네트워크를 볼 수 있음

실무에선 굉장히 많은 노드를 띄워서 사용

컨테이너 내에서 클러스터는 여러 개의 노드로 구성된 컴퓨팅 환경을 나타내며, 노드는 클러스터 내에서 애플리케이션을 실행하고 관리하는 실제 컴퓨팅 인스턴스입니다. 클러스터와 노드는 컨테이너 기반의 애플리케이션을 실행하기 위한 중요한 개념이며, 확장성과 가용성을 제공하는 데 중요한 역할을 합니다.

CloudFormation

클러스터 노드, ec2, 빈스톡 만든 기록도 다 나옴
대시보드로 뭔가를 만들었는데, delete을 했는데 안없어지는 경우 있음
빈스톡에서 환경을 생성하고 삭제를 했음 - 환경 종료
다시 구성하고 싶어서 해당 이름으로 만들려고 하면, 이미 존재하는 프로젝트라고 하는 경우가 있음
화면에선 삭제해서 안나오지만
다시 만드려고 하면 이미 만들어진환경이라고 함
CloudFormation 와서

삭제 해주면됨

도커 이미지 컨테이너. 이미지를 ECR 클러스터 서비스에서 끌고와서 서비스
ELB를 통해 서비스를 연계


Worker Node - ec2 Fargate

배민, 넷플릭스 등 트래픽이 많고 큰 기업들은 EKS를 이용해 클러스터를 관리함.
GCP 등도 별도 서비스 존재
오픈소스이다보니 하나씩 설치해서 컨트롤

EKS 기술 자체가 난이도가 상당함.

취업 목표라면
데모 성격으로 한번 돌려보는것도 좋음 쿠버네티스는 너무 큰 시스템이라 주니어에게 요구하는 스택까진 아님.

처음부터 바로 쿠버네티스 운용하진 않음
스타트업이라면 바로 무겁게 시작 하지 않음.
본격적으로 대기업, 연차높은 팀이 결성했을 때는 생각해볼 수 있음

면접 정보
작은 스타트업
이력서가 굉장히 많이옴. 특히 신입
불과 2~3년 전만해도, 채용시장이 많이 얼었음
1. 안좋은 이력서: 이것저것 다했다는 이력서. 신뢰가 안감. 신입인데 - 풀스택. ? 개발자 입장에선 굉장히 안좋은 이력서. 경력이 있어도 다 해보기 어려움. 아 인프런강의만 보고 깔짝이구나. 이력서는 오히려 딥하게 파본 이력서가 좋음.
2. 데이터 사이언티스트. 개발자는 학과를 보게 되는 것 같음. 통계, 전산학과. 아무래도 석사전공을 선호하게 됨. 개발자는 적음. 논문에 대해 연구를 했거나, 인턴을 간단하게 했던게 도움이 됨.
3. 프로그래머스 프로젝트도 도움이 되겠지만, 차별적으로 한다고 하면 인턴, 논문 참여해서 해봤다. - best
4. 처음부터 좋은 기업 가려고 하지 않았으면 좋겠음. 작은 회사라도 3~4년 쌓이면 가고싶어 하는 회사 잘 가는것 같음.

충분히 기회들은 있음. 2~3년 꾸준히 공부하면. 어차피 이쪽 개발자직군은 평생 공부해야하는 직군. 기술 바뀌는 속도가 굉장히 빠름.

비용측면에서 로컬에서 최대한 한다음 AWS에 올리기. AWS 올린다는건 24시간 돌아간다는 걸 보려고 하는거기 때문.

어느정도 내가 답변할수 있어야하는 기술이어야 함.