리루

1. 쿠버네티스를 알기위한 기본 사항들 본문

# Study/Container

1. 쿠버네티스를 알기위한 기본 사항들

뚱보리루 2020. 5. 25. 16:52

1. 쿠버네티스 사용 이유.
 - 대규모 서비스를 최대한 자원을 효율적으로 사용하기 위함.
 - 기존 VM(VMWare, Open Stack)들은 가상화는 되는데 효율이 안나왔다.(무거운 OS를 사용하게 돼서)
 - dot Cloud 라는 회사가 Linux의 cgroup이라는 자원 격리기술을 Container라는 기술로 만드들고 docker라고 회사명을 변경
 - 컨테이너 가상화 기술은 서버스간 자원격리를 해서 OS를 따로 띄우지 않아도 됨.
 - OS 가동시간이 없기 때문에 자동화시에 엄청 빠르고 자원 효율도 매우 높음.
 - 근데 도커 자체는 하나의 서비스를 컨테이너로 가상화시켜서 배포를 하는거지 엄청 많은 서비스들을 운영할 때 그걸 일일이 배포하고 운영하는 역할을 하진 않는다.
 - 이런걸 해주는게 컨테이너 오케스트레이션이라는 개념이고, 여러 컨테이너들을 관리해주는 솔루션이라고 보면됨.
 - 도커가 오픈소스라 이를 활용해 오케스트레이션 서비스(오케스트레이터)들이 많은 회사에서 나왔는데 이 중 하나가 구글의 쿠버네티스다.
 - 쿠버네티스 개발시에는 여러 회사가 참여함(ms, google, ibm 등등)

 1.1 쿠버네티스가 해주는 자동화
 - Auth Scaling : 트래픽에 따라 자원을 자동으로 구성
 - Auto Healing : 한 서버가 장애가 나도 장애가난 서버 위에 있는 서비스들이 다른 서버로 이동시켜주는 기능.
 - Deployment : 기능을 통해 RollingUpdate, ReCreate 기능 지원

 1.2 VM vs Container
 - VM : Host OS 위에 VM 가상화를 위한 hypervisor가 있고 그 위에서 GuestOS 구성
 - Container : Host OS위에 Container 가상화를 시켜주는 여러 소프트웨어 들이 있고(도커, rkt, LXC)
 - 도커가 컨테이너를 만들어주는데 이 컨테이너는 서버와 이를 위한 라이브러리를 함께 이미지로 만들 수 있다.
 - 도커는 여러 컨테이너간에 Host 자원을 분리해서 사용하게 해준다.(namespace, cgroups을 사용해 격리를하게되고, namespace는 커널에 관한 영역을 분리(mnt,pid,net,ipc), cgroups는 자원에 관한 영역을 분리(memory, CPU, I/O, network) )
 - 컨테이너 가상화가 깔려있는 OS에서는 개발환경에 대한 걱정 없이 배포가 가능해짐
 - 시스템 구조적으로 컨테이너는 한 OS를 공유하는 개념이고, VM은 각각의 OS를띄워야해 컨테이너가 빠를 수 밖에 없다.
 - 보안적으로 vm은 게스트 os가 뚫려도 다른 게스트 os나 host os 와 완벽히 분리가 되어있어 영향이 없는데, 컨테이너는 한 컨테이너가 뚫려 os 영역에 접근가능해지면 다른 컨테이너가 위험에 쳐할 수 있다.
 - 컨테이너는 시스템을 모듈별로 만들어 개발했을 때 배포 및 확장부분에 있어 효율적이다. VM의 경우에는 새로운 게스트 OS를 띄워야해 불필요하게 모듈을 확장해 자원을 낭비해야 하는 경향이 있다.

 2. 쿠버네티스 사용자
  2.1 쿠버네티스 운영자
   - 클러스터를 운영
   - Installation, Architecture, Networking
  2.2 쿠버네티스 사용자
   - 쿠버네티스 기능을 이용해서 서비스를 배포
   - Workloads, Service, Storage / Config, Metadata, Cluster


3. 쿠버네티스 개념
 - Master, Node들로 구성된 쿠버네티스 Cluster
 - Node들은 자원을 제공, Master는 쿠버테니스 전반적인 기능을 컨트롤
 - 클러스터 내 namespace가 쿠버테니스 오브젝트들을 독립된 공간으로 분리해준다.
 - Namesapce는 쿠버네티스 최소 배포단위인 Pod들이 있고, Pod들에게 외부로부터 접근이 가능하게 해주는 Service가 있다.
 - 서로다른 Namesapce에 있는 pod들에게는 Service에서 연결이 불가.
 - Pod 안에는 여러 Container들이 있고, 컨테이너 하나 당 하나의 앱이 돌아가니, pod 하나당 여러 앱들이 돌아갈 수 있다.
 - 근데 Pod에 문제가 생겨 재생성이 되면 그 안에 있는 데이터들이 다 날아가서 공용으로 사용할 수 있는 Volume을 만들어 사용 가능.
 - Namespace에 ResourceQuota와 LimitRange를 달아서 pod 갯수나 cpu/memory를 제한할 수 있다.
 - ConfigMap이나 Secret을 통해서 Pod 생성시 환경변수 값이나 파일 마운팅이 가능하다.
 - Controller가 Pod들을 관리해준다.
    - Replication Controller, ReplicaSet이 기본적인 컨트롤러인데, 파드가 죽으면 감지해 살려주거나 파드의 갯수를 scale in-out 해준다.
    - Deployment는 배포 후 새 파드들을 업그래이드 해주고 배포시 문제가 생기면 롤백을 도와준다.
    - DaemonSet은 한 노드에 파드가 하나씩만 유지되게 해준다. (이런 케이스는 추후 설명)
    - Job은 어떤 특정 작업만하고 종료되어야 할때 사용, 이게 주기적인 작업이 되면 Cron Job 사용.