[AI] KT AIVLE(KT 에이블스쿨) 3기 AI 개발자 트랙 가상화 클라우드(2) -14주차-

- 컨테이너

: OS 가상화 기술 / 프로세스 격리 / 리눅스 커널 공유

 

구분	가상머신	컨테이너
게스트 OS	Windows, Linux 등	X
시작시간	길다 (분)	짧다 (초)
이미지 사이즈	큼 (GB)	작다(MB)
환경관리	각 VM다 OS 패치 필요	호스트 OS만 패치
데이터 관리	VM 내부 또는 연결된 스토리지	컨테이너 내부의 데이터는 컨테이너 종료 시 소멸

 

 

- Monolithic Architecture

: 고용량 고성능의 단일 서버로 구성

 

 

- MicroService Architecture

: Monolithic Architecture 와 비교하여 작은 서버들의 집합체로 구성

  ex) 네이버의 메일, MyBox, 지도 등 단독적인 컨테이너로 구성

 

 

- Docker

: 컨테이너 엔진 (컨테이너를 실행하고 관리하는 도구)

  도커는 도커허브라는 공개된 저장소 서버를 통해, 컨테이너 자료들을 관리

   Dockerfile --(build)--> Image --(run)--> Container

 

   (1) Dockerfile

      : 컨테이너 이미지 생성하기 위한 레시피 파일

        이미지 생성 과정을 코드로 가지고 있음

   (2) Docker Image

      : 서비스 운영에 필요한 프로그램, 소스코드, 라이브러리 등을 묶는 형태

       도커 이미지는 url 방식으로 관리하고 태그를 붙일 수 있음

       <Namespace>/<ImageName>:<Tag>

       docker.io/library/nginx:latest

       도커 허브에 저장되어 있는 이미지들 중 nginx 이미지 중 최근 버전의 이미지

        private:10000/mynginx:latest

        Private 한 이미지저장소를 구축하여 이미지를 관리한다면, <Namespace>부분을 해당 서버주소 및 포트번호 등으로 사용가능

 

 

- Docker HUB

: 컨테이너 이미지들을 서버에 저장하고 관리

 

- 컨테이너 오케스트레이션(orchestration)

: 다수의 컨테이너를 배포/복제/장애복구 등 총괄 관리를 자동화하는 것

   => 종류 중 쿠버네티스(Kubernestes) 가장 많이 사용

 

- 쿠버네티스

: 컨테이너형 애플리케이션의 배포, 확장, 관리를 자동화하는 오픈소스 시스템

   높은 확장성, 원활한 이동성(이식성)

   퍼블릭/프라이빗/하이브리드/멀티클라우드, 로컬 또는 원격, 가상머신, 베어메탈 등 여러 환경에서 구축 가능

   오픈 소스 도구의 장점

   플로그가 가능한 모듈 형식

 

- 쿠버네티스 아키텍쳐

: Master Node + Worker Node = Cluster

  (1) Master Node (control plane)

        - API Server

          : API를 사용하게 해주는 프로세스

        - Scheduler

           : Pod의 생성 명령이 있을 경우 어떤 Node에 배포할지 결정(배치 위치 결정)

             *pod => 컨테이너 담는 통

        - Controller Managers

           : 클러스터의 상태를 조절하는 컨트롤러들을 생성, 배포

        - etcd

           : 모든 클러스터의 구성 데이터를 저장하는 저장소

 

   (2) Worker Node

        - Container Runtime

           : 컨테이너를 실행하고 노드에서 컨테이너 이미지를 관리

             도커, CRI-O, containerd, rkt, rktlet 지원

        - Kubelet (큐블릿)

           : 컨테이너가 잘 작동하고 있는지 관리

        - kube-proxy

           : 쿠버네티스 클러스터의 각 노드마다 실행되고 있으면서, 각 노드 간의 통신 담당

 

 

- kubernetes 배포 유형

(1) All-in-One Single-Node Installation

: test를 하거나 학습을 할 때 사용

(2) Single-Node etcd, Single-Master and Multi-Worker Installation

: master node 1개 + worker node 여러 개

(3) Single-Node etcd, Multi-Master and Multi-Worker Installation

: master node 여러 개 + worker node 여러 개

(4) Multi-Node etcd, Multi-Master and Multi-Worker Installation

: master node (+ etcd) 여러 개 + worker node 여러 개

 

 

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

 

- kubernetes Object

 

- kubernetes Controller

: 클러스터 상태 관찰, 필요 시, object 생성, 변경 요청 역할

  현재 상태를 정의된 상태에 가깝게 유지하려는 특징

   (1) Auto Healing (자동 복구)

     : 노드가 삭제되거나, 노드 간 연결이 끊어졌을 때 노드 추가, 연결해줌

   (2) Auto Scaling

     : 리소스 부하가 늘어나면 pod 개수 늘려주고 줄어들면 pod 개수 줄여줌

   (3) Update & Rollback

     : 수정하고 되돌리기 기능

   (4) Job

     : 작업 실행 후 종료되는 작업(계산, 메일, 백업 등)

 

- YAML

: kubernetes object 관리

    - apiVersion : 연결할 API server의 버전

    - kind : 리소스의 유형

    - metadata : 리소스가 기본 정보를 갖고 있는 필드

                         name, label, namespace 등

    - spec : 배포되는 리소스의 원하는 상태

 

- kubectl

: Kubernetes에 명령을 내리는 CLI(Command Line Interface)

   kubectl [COMMAND] [TYPE] [NAME] [FLAGS] 형태임

    command -> get, create, apply , delete

 

 

- Pod

: Kubernetes의 가장 작은 최소 단위 Object

  Pod를 만들어서 Object를 저장함

  컨트롤러가 pod를 관리해줌

     - yaml 파일로 Pod 생성하는 명령어 => 관리, 안정성 따지면 이 방법이 좋음

       kubectl create -f <yaml 파일명>

     - kubectl 명령어로 Pod 생성하는 명령어

       kubectl run <pod명> --image=<이미지명:버전> --port=<포트번호>

 

 

- Namesapce

: Kubernetes 단일 클러스터 내 다른 리소스들을 그룹화하는 데 사용되며, 이를 통해 각 리소스에 대한 액세스 권한을 제한하거나 리소스 간의 충돌을 방지할 수 있습니다

   - yaml 을 활용한 namespace 생성

        kubectl create –f <yaml 파일명>

   - 특정 namespace 안에 pod 생성

        kubectl create -f pod.yaml –n <특정 ns 이름>

   - create, run 명령으로 namespace 와 pod 생성

        kubectl create ns <ns이름>

        kubectl run <pod이름> --image=<image이름> --port=<포트번호> –n <ns이름>

 

 

- Kubernetes Controller – ReplicaSet

: Pod의 개수를 유지

 

 

- Kubernetes Controller – Deployment

: ReplicaSet을 관리

  Deployment는 이전버전의 ReplicaSet을 10개까지 저장

    -> revisionHistoryLimit : n

   저장된 이전 버전의 ReplicaSet을 활용하여 Rollback

 

  (1) Recreate

   : 현재 운영 중인 구버전의 Pod들을 삭제하고, 업데이트 된 새 버전의 Pod들을 생성

     Downtime이 발생하기 때문에 실시간으로 사용하기엔 어려움

  (2) Rolling Update

   : 먼저 업데이트 된 Pod를 하나 생성하고, 구버전의 Pod를 삭제

     Downtime 발생하는 문제점 해결

    기존 replicaSet은 남아 있어서 rollback에 사용

 

- Deployment 생성 명령어

kubectl create deployment dp --image=nginx:1.14.0 --replicas=3

 

 

- Template

: Pod를 생성하기 위한 명세

  Deployment, ReplicaSet과 같은 Controller의 yaml 내용에 포함

  Template에는 Pod 세부사항을 결정

 

 

- Pod Scale

: replicas를 늘리거나 줄여서 pod 개수를 늘리고 줄일 수 있음

   (1) Deployment로 생성된 Pod 수를 조정(Scale)하는 명령

           kubectl scale deployment/<Deployment명> --replicas=<조정할 Pod 수>

   (2) ReplicaSet으로 생성된 Pod 수를 조정(Scale)하는 명령어

          kubectl scale rs/<ReplicaSet명> --replicas=<조정할 Pod 수>

 

 

- Kubernetes Object – Service

 : Pod에 접근하기 위해 사용하는 Object

   pod가 어떠한 이유로 재배포 되었을 때 재배포된 pod로 자동으로 접근할 수 있게 해줌

   (1) Label

     : Pod와 같은 Object에 첨부된 key와 value로 되어있음

   (2) Selector

     : Pod에 있는 Label 값을 찾아 해당하는 Object만 관리할 수 있게 연결

   (3) Annotation

     : Object를 식별하는데 사용되어지지는 않지만 참조할만한 내용들을 Lavel처럼 첨부

 

 

- Service 유형

 (1) ClusterIP (default)

    : Service가 기본적으로 갖고 있는 ClusterIP를 활용하는 방식

      같은 클러스터 내에서만 접근 가능

     - ClusterIP 유형의 Service를 생성하는 명령어

          kubectl create service clusterip <Service명> --tcp=<포트:타켓포트>

     - ClusterIP 유형의 Service를 nginx라는 Deployment와 연결하여 생성하는 명령어

          kubectl expose <연결할오브젝트(deployment)> <오브젝트명(nginx)> \

          --port=<포트> \

          --target-port=<타겟포트> \

          --type=ClusterIP

 

 

 (2) NodePort

   : 모든 Node에 Port를 할당하여 접근

    외부에서도 접근 가능

    ClusterIP에서 nodePort 지정(기능추가 느낌) -> NodePort 만들면 ClusterIP 생성됨

  - NodePort 유형의 Service를 생성하는 명령어

      kubectl create service nodeport <Service명> --tcp=<포트:타켓포트>

  - NodePort 유형의 Service를 nginx라는 Deployment와 연결하여 생성하는 명령어

      kubectl expose <연결할오브젝트(deployment)> <오브젝트명(nginx)> \

      --port=<포트> \

      --target-port=<타겟포트> \

      --type=NodePort

 

 

 (3) Load Balancer

   : Load Balancer Plugin을 설치하여 접근

     Load Balancer 생성하면 ClusterIP, NodePort 생성됨

     추가 플로그인 설치가 필요하고, 로드밸런서를 지원해주는 클라우드 환경에서 사용가능

  - LoadBalancer 유형의 Service를 생성하는 명령어

      kubectl create service loadbalancer <Service명> --tcp=<포트:타켓포트>

  - LoadBalancer 유형의 Service를 nginx라는 Deployment와 연결하여 생성하는 명령어

      kubectl expose <연결할오브젝트> <오브젝트명> \

      --port=<포트> \

      --target-port=<타겟포트> \

      --type=LoadBalancer

Kubernetes DNS

: Kubernets는 Pod와 Service에 DNS 레코드를 생성

IP 대신, 이 DNS를 활용하여 접근 가능

 

 

- Volume

: Pod 컨테이너에서 접근할 수 있는 디렉터리

Volume은 연결된 pod끼리의 공용 폴더

 

  (1) Emptydir

      : Pod가 생성할 때 함께 생성되고 Pod가 삭제될 때 함께 삭제되는 임시 Volume

 

  (2) HostPath

      : 호스트 노드의 경로를 Pod에 마운트하여 함께 사용하는 유형의 Volume

 

   (3) PV/PVC

        - PV (Persistent Volume) - 영구 볼륨

          : 클러스터 내부에서 Object처럼 관리 가능

            Pod와는 별도로 관리

            Pod에 직접 연결하지 않고 PVC를 통해서 사용

 

- PVC (PersistentVolumeClaim)

: 사용자가 PV에 하는 요청 / Pod와 PV의 중간 다리 역할