2회차

컨테이너란 ? 컨테이너 안에는 화물이 있고, 컨테이너 간은 독립적이다 .

사이즈나 규격등이 표준적. isolatio,portability가능하며, 동일한 platform 안에 올라갈 수 있다. 

처음으로 명확한 컨테이너를 시작한 것이, 리눅스이다. 

 

리눅스의 개념 (간단)

namespace -> name (다양한 변수를 분리) 각 그룹이 독자적 사용

Cgroup -> cpu, 메모리 같은 자원을 격리

 

즉,  여러개의 프로세스가 각자 고립된 공간에서 사용되는 구조를 컨테이너라 한다.

https://jihyukcoding.tistory.com/36

쓰레드, 프로세스

내 블로그를 참조하면, 프로세스는 실행중인 프로그램 이다.

 

쉽게 푼다면, 컨테이너는 WINDOW,LINUX같은 운영체제 위에서, 각 실행중인 프로그램(프로세스)들이 각자 독립적으로 작동하는 구조를 의미한다.

 

장점 : 생성, 시작 ,종료가 빠르다

컨테이너 안의 application 들 library등을 함꼐 공유하기 때문에 자원이 효율적이다.(OS에 종속적)

Portability( 이식성이 높다 )

 

단점 : 허나 이와 동시에 ost에 종속적이고, 컨테이너 별 커널 공유가 힘들다. 

 

Docker라는 컨테이너 엔진이 등장. Dockerswarm이라는 관리기술을 함꼐 총칭 

현재 대세는 Kubernetes ! docker는 점점 사라지는 기술이 되어 간다. 

컨테이너 환경에서 독립적으로 애플리케이션을 실행할 수 있도록 컨테이너를 만들고 관리하는 것을 도와주는 도구라고 할 수 있다.

 

Namespace 상세 :

ex) ID가 있다면, ID2와 ID3를 다양한 GROUP간 독립 시켜주는 개념 .

PID 9라는 ID를 , 다른 그룹에서도 사용할 수 있게끔 하는 것

EX2) CGROUPS (각 ID간의 )사용할수 있는 자원을 제한하는 것 .

 

ISOLATE : PID,IPC,UTS등을 활용한다 , NET도 활용하고 

논리적으로 다른 NAME으로 GROUPING 하는 것을 NAMESPACE라고 할 수도 있다. 

하나의 CONTAINER안에 모든 것이 들어가 있다 = OS위에 프로세스로 존재한다. 

 

Docker -> Layer한 구조를 갖춘다. 

가장 밑에 os-> 그 위에 default parameter -> application a (read) -> application b (read write)

 

만약에 image를 update 한다고 하면?

1. 기본 image -> application위에 올린다

2. modification -> 수정된 image가 반영된다 . 

3. image registry에 저장된다 

4. docker 엔진이 이러한 application을통해서 받아오고

5. 완성된 image를 update, finish. 

여기서 image는 img file이 아니라, container의 역할을 하여 작동하게 끔 하는 것을 의미한다.

 

DOCKER의 예시 

UBUNTU + MYSQL + CONFIGURATION + USER 생성 + DB를 붙여서 + 생성 

(이러한 것들이 LAYER로 쌓여서, CONTAINER로 작동한다 )

 

Cloud Computing의 관리를 위한 software 

-> Openstack . cloud infra를 관리하기 위한 software. 허나 현재는 container등도 모두 관리하는 기능 포함

 

Kubernetes를 본격적으로 시작하자. 

google이 만듬. 소스를 공개하여 많은 사람이 개발할 수 있게끔 하였음 . 그 이후, 공개 software을 사용하는 속도가 공개 소프트웨어중 가장 빨랐고, 시장을 압도. +Linus Foundation이 재단에서 도움을 줬음. 

CNCF라는 foundation아래에서 관리 됨. 즉, CNCF가 KUBERNETES를 관리한다.  (약자로 K8S)

 

한글 정의 -> 쿠버네티스는 컨테이너화 된(라이버르러,어플리케이션등을 모아둔) 어플리케이션의 배포(서버에 돌린다) , 확장(한개의 cpu로 돌렸더니 많은사람이 써서 몰리면 더 많은 cpu 사용) , 그리고 여러가지 관리를 자동화하는 오픈 소스 시스템

 

kubernetes -> [worker node(어플리케이션이 돌아가는 환경) -> 안에 Pod,contiainer engine등을 설치해야만 worker node가 가능] , [Master (api방식으로 call한다 그러므로 API SERVER, CONTROLLER MANAGER, SCHEDULER 어디에 돌릴까를 결정해준다. 패키지화 되어있는 프로그램(컨테이너)를 돌려줘? 어디에 돌릴지를 결정 해준다. ETCD라는 DATABASE도 있다. 근데 MYSQL이런게 아니고, KEY->VALUE(JSON방식? )의 정보 저장소 (나중에 사용이 편할듯) +분산DB구조임], 일반 NODE[일하는 NODE와 유사하나, 일하는 NODE엔 CONTAINER ENGINE이 필요하다] 

이 MASTER, 몇십개의 WORKER NODE들을 모아서 , CLUSTER라고 부른다. 

 

작동 구조 -> MASTER가 망가지면 다 망가지는 구조 . BACKUP의 MASTER를 준비해둔다.

 

Master node

-> 독립된 controller라고 생각해도 될 part의 controller part 들이 있다. 

-> scheduler도 있다. 

 

별도의 server를 구매해서 서버를 꾸민다. 하지만 기업에서는 주로 public cloud (naver,amazon)등에서 virtual machine을 빌린다. 그 virtual machine에서 container를 돌려도 된다. (worker node 대체) 

ㅈvirtual node의 증설이 결국 node의 증설과 같은 의미가 된다. 그 위치를 지정해줘야한다면 cloud-controller라고 지정해줄 수도 있다. 이러한 controller도 개념상에는 master node 안에 포함되진 않지만, 어떻게 보면 master node를 통해 작동된다고 할 수도 있다. 

API SERVER? 각 node와의 calling을 할때, API를 활용한다. hellm?이라는 것도 사용할수 있지만 주로는 http 방식으로 api 명령을 내린다. 

 

Worker node . kubelet이라는 software가 worker node안에서 master node와의 커뮤니케이션 담당.

kublet은 pod라는 명령이 돌아가는 기본 단위가 된다 . 

 

정리 

master node안에는 API SERVER가있고, 모든 명령은 여기를 통한다

CONtroller Manager : 복제,배포등의 관리를 담당하고, APISERVER와 통신하여 작업을 수행한다 

SCHEDULER : 요청된 WORKLOAD(컨테이너의 일)을 어느 노드에서 배치시켜서 작업할지 결정. 

ETCD : 가볍고 빠른 분산형 KEY-VALUE 형태의 DBMS .

 

NODE : POD로 불리는 기본 컨테이너가 운영되는 서버 . 컨테이너 엔진, MASTER과 통신하는 KUBLET, KUBE-PORXY등이 위치한다. (PORXY는 추후 학습) KUBECTL : 명령어 도구 , 명렁어를 API SERVER가 이해할 수 있는 RESTFUL API로 변환시킨다. 

 

POD?? 컨테이너 얘기하더니 왠 PODK8S(쿠퍼네틱스)에서 컨테이너가 동작되는 기본단위를 PoD라고 정의한 것 . 기본적으론 1pod안에서 1container가 위치하나, 내가 짠 프로그램을 근간으로 하는 다른 application을 생성했다 ! 논리적으로는 1개지만, 실제적으론 2개 이다. 이 2개를 1 pod에 위치시킬 수 있다. 

 

Container환경에서 어플리케이션 들이 동작하게 된다면, 해당 버전의 upgrade혹은 관리를 docker를 통해 진행할 수 있다.

이 의미는, container가 이미지로 패키징되어 배포되면, docker에서 해당 container의 application의 버전의 조정등이 가능하다. 

 

Application이 돌고 있다? 외부와 연결하는 networking 이 필요하다 . network interface도 있고 , 계층도 있고 . 

이러한 network나 stoarge 기능 또한 한 pod안에 포함될 수 있다. 

즉 node안에는 pod가 있고, 그 pod 안에 container가 돌아간다. 

 

---- 정리 이후 기타 내용 ----

kublet이, master아 명령을 내리는 것이 아니고 직접 올라가서 api server에 올라가서 확인한다 . 

기본적으로 push가 아니라 pull 같은 느낌으로 동작한다. 

 

외부에서 pod 쪽으로 전송될때 proxy가 지원을 한다

어떻게? proxy가 내부 iptable 등을 확인하여 , pod의 위치를 확인해줌

Container Engine -> Podcontainer를 돌린다, container engine이 Pod를 돌으라는 명령을 내린다. 

 

-- 총 정리 --

API를 통해서 명령을 받아들이고, SCHEDULER로 어디 NODE에서 돌리지 생각하고, CONTROLELR MANAGE, ETCD가 있따. 이 돌리는 NODE에는 KUBLET이 APISERVER와 통신하고, POD들이 있고, CONTAINER ENGINE도 있다. 

++ 조교님의 팁 

APISERVER를 보고, 모든 작업 중 진행할 것을 정리한다. 

 

KEBERNETS 설계 개념 

 

WSL?SSL? 학부 수업에서 가상수업을 진행했을 것이다. 

WSL은 WINDOW와 통합하여 가상머신보다 편하고 가볍게 LINUX를 활용한다. 

이 환경을 세팅해 오는것이 다음주 수욜까지의 과제이다 .