KT AIVLE [14주차] - 가상화 클라우드

이 분야는 아~예 모른다. 생초보. AWS든 뭐든...써보지도 않았다.
그러나 써보니 왜 써야할진 알 것 같은.....
작은 사이드 프로젝트를 하나 기획해서 AWS 배포까지 마쳐보는게 올해의 버킷리스트.

---

이론

가상화

기존 환경은 극도로 복잡하고 빈약한 인프라에 의존중
그래서 IT 예산 대부분이 현상유지에 사용됨
이걸 가상화 기술을 통해 해결함

** 하이퍼바이저를 통해 물리적인 코어들을 가상 아키텍쳐로 분리해서 할당
클라이언트 하이퍼바이저 > 서버 하이퍼바이저 > 가상 인프라 > 클라우드

** 하이퍼바이저 : 시스템에서 다수의 운영 체제를 동시에 실행할 수 있게 해주는 논리적 플랫폼 (Type 1(Native 또는 Bare-metal) 또는 Type2 (Hosted))

네트워크도 가상화를 통해서 구현이 됨

클라우드

• 클라우드란? PC데이터를 PC에 보관하는 것이 아니라 인터넷을 통해 중앙 PC 또는 서버에 저장하는 공간

• 클라우드 컴퓨팅: 인터넷을 통해 IT 리소스를 원할 때 언제든지 사용하고 사용한 만큼 비용을 지불하는 서비스

• 퍼블릭 클라우드: 업체에게 자원들을 대여해서 사용

• 프라이빗 클라우드: 기업이 직접 클라우드 구축, 기업내부에서 활용

• 하이브리드 유형: 기존 On-premise에 구성되어있는 인프라(프라이빗 클라우드)와 퍼블릭 클라우드를 혼용

• 멀티 클라우드 : 2개 이상 서로 다른 클라우드를 함께 사용하는 방식

EC2

• 가상 서버 서비스
  엘라스틱 컴퓨트 클라우드: 트래픽에 맞춰 운용가능한 서비스

VPC

사용자가 정의한 가상의 네트워크 환경
네트워크 관련으로 빌려줌. ip나 라우터 등등...

region 설정, IP대역 결정 > 가용영역에 서브넷 생성 > 라우팅 설정 > 트래픽 통제

VPC 구성시 가장 먼저 고려하는건 IP대역폭
CIDR로 IP 개수를 관리
숫자가 커질수록 네트워크 내 할당 가능한 호스트 개수가 줄어듬
VPC CIDR 설정: VPC 내 위치한 서버들이 사용할 프라이빗 IP의 범위를 지정하는 것
생성 이후 변경 불가. 16~28 bit 사이로 가능

서비스의 규모와 IP소모률과 추후 서비스 확장 가능성, 타 시스템과 연계 가능성 등을 따져서 CIDR 결정

서브넷도 CIDR를 이용해 IP 범위를 지정
브로드캐스팅 영역 분리를 위해 서브넷을 사용

VPC는 외부 통신 단절, 통신하려면 인터넷 게이트웨이를 통해야만 함

스토리지

• 블록: 아마존 EBS
  AWS에서 제공하는 블록 스토리지 서비스, EC2용 (VM)
  볼륨과 인스턴스는 같은 어빌리티 존에 있는 경우 연결 가능
  EBS 볼륨을 스냅샷 생성 후 다른 AZ(또는 리전)에 EBS 생성 가능
• 파일: 아마존 EFS
• 오브젝트: 아마존 S3

고가용성

가용성?워크로드를 사용할 수 있는 시간의 비율

AWS는 리전과 AZ로 이루어져 있음

컨테이너

쿠버네티스

마스터노드

• API Server : 통신 다리역할
• Scheduler : Pod의 생성 명령이 있을경우 어떤 Node에 배포할지 결정
• Controller Managers : 클러스터의 상태를 조절 하는 컨트롤러들을 생성, 배포
• etcd : 모든 클러스터의 구성 데이터를 저장하는 저장소

워커머신

• 컨테이너 런타임: 컨테이너를 실행하고 노드에서 컨테이너 이미지를 관리
  ex. 도커, 크라이오, rkt 등

• kubelet: 각 노드의 에이전트 (컨테이너 런타임이 만든 컨테이너가 잘 동작하는지 감시, 감시내용을 api 서버에게 주기적으로 보고, api가 etcd에 저장)

• kube-proxy: 클러스터 각 노드마다 실행, 각 노드간 통신 담당(외부)

쿠버네티스 컨테이너 배포,통신,볼륨 관리

오브젝트(가장 기본 구성단위)라는 객체를 가지고 클러스터 상태를 관리
오브젝트는 두 가지 필드로 구성되어 있다.
Spec(정의 상태)과 Status(현재 상태)

• 컨트롤러: 클러스터의 상태를 관찰, 필요한 경우 오브젝트(pod나 svc 등등..) 생성,변경을 요청

• 컨트롤러가 오토 핸들링(어디서 pod가 삭제되면 재생성해서 Spec과 맞춤), 오토 스케일링(리소스 부하가 커지면 pod 추가 등 비용관련으로 컨트롤)을 해줌

• Update&Rolback: ???????????

• Job: 한번 실행되고 종료되어야 할 기능

• Pod: 컨테이너를 담는 통, 쿠버네티스는 파드를 만들고 컨테이너를 담는다는 느낌 (컨테이너를 구성하는 가장 작은 단위)
  컨테이너 여러개 넣을 수 있고, 그들끼리 네트워크와 볼륨 공유
  파드는 yaml파일이 있음 > 이거 사용해서 pod 생성 명령어를 침

• NameSpace: 단일 클러스터 내 리소스 그룹 격리를 위한 오브젝트
  사용자가 여러 팀으로 구성하는 경우, 프로젝트를 진행함에 있어 환경을 분리 해야 하는 경우 사용

• ReplicaSet: Pod 개수 유지역할, yaml 작성 시 replicas 개수 지정하면 그 개수에 따라 유지

• Deployment: ReplicaSet을 관리,즉...Pod를 관리!!!!!
  get deploy해서 3/3뜨면 이게 그 pod 개수임

• 롤백...리비전...뭐가 많음

• Service: 쿠버네티스 외부 or 내부에서 Pod에 접근하기 위한 오브텍트
  파드안의 애플리케이션을 네트워크 서비스로 노출시키는 오브젝트
  셀렉터 라벨, 포트 설정 둘 다 있어야함 (고정된 주소를 이용하여 접근)
  이 서비스의 유형에는 ClusterIP, NodePort, Load Balancer가 있음

  • ClusterIP: 서비스가 기본적으로 갖고있음
  • NodePort: 모든 노드에 포트를 할당해서 접근, 노드IP와 port필요
  • Load Balancer: 로드밸런서플러그인을 설치해서 접근

서비스가 일단 포트를 뚫어 길을 만듦,근데 포트로 갔다고 바로 파드로 연결되진 않고 서비스로 먼저 감, 서비스에서 target port랑 selector(pod label)가 있음, 셀럭터 라벨기반 포트 포워드로 연결을 함(target port로 감) 즉 그래서 worker1로 가든 2로 가든 서비스 먼저 거쳐서 포워딩 되기 때문에 지정된 파드로 접속이 됨.

• FQDN: 이건 또 뭔제??????

• Volume: Pod 컨테이너에서 접근할 수 있는 디렉터리, 컨테이너들이 공유해서 사용

• Emptydir: Pod가 생성 시 생성, 삭제 시 삭제, 파드 야믈에서 관리

• HostPath: 볼륨으로 사용할 디렉터리를 지정하고 그걸 마운트하여 사용

• PV/PVC: 영구볼륨, 파드에 직접 연결X, PVC를 통해 사용

실습

정리하기...