[Kubernetes] 기말고사 정리 1

 

 

 

 

 

Chap12. Private Multi-Node Docker / Docker in docker 
- Docker in docker – DinD

- official but not recommended (권장 X) 
- 도커 안에서 다시 도커를 띄울 수 있도록 한다 + 경고가 정말 많다. 

 

 

 

 

Chap13. Docker Swarm 1
- 수천 수만대의 컴퓨터에서 SW 돌리기 위한 궁극적인 방법, 도커 스웜 (like 쿠버네티스) 
- SWARM – 떼, 구성 요소는 여러 개지만, 하나의 논리적인 군 (도커 스웜은 컨테이너들의 군) 
- 일일이 다 타이핑? 불가능 / 자동화된 도커 스웜 등장 -> 더 편하게 수많은 이미지와 컨테이너 컨트롤 가능

- 얌파일을 커맨드라인을 통해 일꾼들에게 쫙 뿌림 – 개발자 관점 
- 도커 머신을 통해 원격의 컴퓨터를 관리할 수 있게 됨 

- 도커 스웜은 원격의 노드 관리 이상으로, 여러 서비스와 컨테이너들을 관리하기 위한 용도

 

* Orchestratior - 수많은 컨테이너들이 하나의 어플리케이션(서비스)을 구성함
유기적으로 동작하게 하기 위해서, 수많은 정보를 지휘자가 관리 (오케스트레이터의 대상은 컨테이너)

* 오케스트레이터로 하나로 묶음 / 실행하는 애는 IAC (얌파일) / application이 이걸 모르게 돌아가게 하는 것이 오케스트레이터의 역할

- 수많은 작은 SW들의 총집합 = 쿠버네티스 (구글)
+ 쿠버네티스와 도커 스웜이 양대산맥 

- scalability 측면에서 쿠버네티스는 대규모의 일에 적합, 구글이 상용 서비스를 띄우기 위해 개발

- 도커 스웜 - 작은 규모에 적합, 대신 난이도가 쉽다 

 

* Container Orchestration – a process that automates the deployment, management, scaling, networking, and availability of container-based applications / CI/CD DevOps 자동화가 핵심
- multiple Docker hosts로 구성 – manager(리더)에게 얌파일을 제공, 매니저가 workers(nodes) 일꾼들을 띄운다. 

Ex) 3개의 도커 머신을 띄움 (manager, worker1, worker2)
docker-machine ssh manager docker swarm init --advertise-addr 192.168.99.100 
: 매니저야 니가 대장이야 (대장을 만드는 것) & 내가 매니저라고 주변에 뿌리는 것

docker-machine ssh worker1 docker swarm join --token ~ // 이 명령을 카피해서, 워커가 해당 스웜에 들어간다
대장님 IP address로 내 port number로 join (192.168.99.100:2377)

 

* Docker stack – init, join이 끝나면 실행은 stack files 
: 얌파일들을 이제 스택 파일이라고 부를 것, 하나의 엔드 유저 어플리케이션을 스택이라고 칭함
- scp 명령어를 통해, 내 디렉토리의 docker-compose.yaml 파일을 매니저의 디렉토리로 복사한다. 
- docker stack deploy -c docker-compose.yaml / 서비스를 돌리라고 한다 + 스웜은 자동으로 local network를 만듦

- 이후 stack rm 을 통해 네트워크와 서비스 (helloswarm) 지우기 -> docker swarm leave로 join한 워커가 스웜에서 나가기

- docker swarm leave 명령으로 매니저도 지우기 / docker-machine rm 도커 머신 노드들을 지움

 

 

 

Chap14. Docker Swarm 2 
- Scale service up & down, update - 사람이 손으로 하는 경우는 없다, 대부분 프로그램을 통해 up, down 
+ 쿠버네티스 rest API 언어별 존재, 손으로 타이핑한 명령들 모두 API 호출로 실행 가능

+ 스웜은 두 컨테이너 밀어버림 -> 명령에 대한 결정을 사람이 한다 / 쿠버네티스는 하나하나 섬세하게 교체 (사람이 얘한테 부탁) -> 인간이 하던 일을 모두 코드화 -> 쿠버네티스가 알아서 함 vs 스웜은 사람이 명령을 내림

 

docker service create --replicas 3 -p 80:80 --name web-1 nginx // nginx로 web-1 이름의 컨테이너를 3개 만들어라
docker service scale web-1=4        // * scale option을 사용하여 컨테이너 개수를 늘리고 줄임 
docker service update --image nginx:1.14.0 web-1     // latest version이던 nginx를 downgrade, 롤백

 

 

 

Chap15. Docker Labels

- 도커에서 취급하는 오브젝트(이미지, 컨테이너, volumes, networks, swarm nodes etc)에 라벨을 붙이는 것
- 무언가 구분하기 위해 라벨을 달 수 있다 or 컨테이너 등을 상호 관계로 묶어주기 위해서

- key-value pair (dictionary), 여러 라벨을 달 수 있다.

- Each key-label pair must be unique within an object.  
+ 카테고리(대분류에서 소분류로) 구분할 때 . 점을 찍고, 동등한 레벨에서 구분할 때 – 하이픈을 붙인다.
+ App 프로그램 개발할 때 웹사이트 역순으로 도메인을 뒤집는다 ex) com.example.some-label
+ 도커가 점유한 라벨은 사용 불가 ex) com.docker.*, io.docker.*, &org.dockerproject.*

 

* 변수에 값을 넣는다 (or 오른쪽을 왼쪽으로 칭한다)
- docker node update --label-add foo worker1 // worker1 에 :foo 라고 라벨을 붙이는 것

- static for the lifetime of the object, 한번 생성하면 오브젝트가 죽을 때까지 유지됨
- to change labels, you must recreate the object / 쿠버네티스에서는 동적으로 update 가능함 

 

 

 

Chap16. Kubernetes Overview
* 쿠버네티스도 도커스웜과 같은 컨테이너 오케스트레이션이다.
- 쿠버네티스는 실제로 회사에서 운영할 수 있는 수준, 구글이 쓰는 서비스를 오픈소스화 한 것 (구글이 써서 검증됨)
- 도커 스웜에서는 일일이 손으로 해야 하는 것들을 쿠버네티스는 자동화하여 훨씬 많은 기능을 제공, 대규모에 편리

- 쿠버네티스는 오픈소스 SW / management 기능이 도커보다 강력 / 도커를 밑에 깖 - 컨테이너 기술은 도커인 것
- open-source system for automating deployment, scaling & management of containerized applications (Google)
+ 구글의 논문 Borg, Omega - 수천 수만대의 컴퓨터를 묶는 행위 (cluster) 컨테이너가 아니라 job, task 즉 프로그램

 

* CNCF - Cloud Native computing Foundation : 애시당초 수천 수만대의 컴퓨터가 있다고 가정하고 시작
- 리눅스 산하에서 클라우드 컴퓨팅 관련으로 분리됨, 수천 수만개의 CPU, DISK, 네트워크를 생각하고 SW 만들기

- microservices, dynamically orchestrating those containers to optimize resource utilization 

* Kubernetes: polyglot - multi-language로 개발 / Google / Go 언어로 쓰임 – cluster management SW
- 컨테이너 클러스터 관리 / deploying apps에 대한 도구 제공 / scaling과 update 

 

* Pokémon Go - 컨테이너 기술 좋은 건 알겠어, 근데 public user들이 VM을 벗어날 필요가 있어?
+ 포켓몬 고: 컨테이너 베이스, 구글 쿠버네티스 사용 

-> 트래픽 폭발했지만, 서비스에 문제가 없었다 (성공적인 운영 사례) / 이정도 터지면 서비스가 멈춰야 되는데, 안 터짐 

+ 예상보다 50배 이상의 트래픽이 폭발했으나 견뎠다. 
** 쿠버네티스가 검증된 사례 - 컨테이너와 쿠버네티스는 벤처 회사 merit / 구글의 타깃은 벤처!

+ 현재 전세계가 쿠버네티스로 대동단결 / 압도적으로 컨테이너 오케스트레이터 중 쿠버네티스의 비율이 높다

 

 

 

Chap17. Microservices and Killercoda 
- 마이크로서비스 아키텍처 vs IBM mainframe - 엄청난 CPU DISK 한 대의 컴퓨터 (monolithic)

- 기존의 모놀리틱 구조 - 하나의 거대한, 막강한 컴퓨터가 모두 통제 / 사용자 인터페이스 / 저장할 정보가 있는 data access layer
/ 돌아가는 로직 / 3개를, 하나의 어플리케이션 안에 모든 기능을 구현하는 것 
- 실행파일 하나에 다 넣음 (사용자 UI, 주문과 관련된 백엔드 로직, inventory 데이터 유지 등) 

 

* What happens once the apps becomes large & team grows in size? 
1) 새로운 요구사항 -> 4개의 구성요소가 있을 때, 용량이 늘어난다고 해서, 4개의 모듈이 일괄적으로 증가하는 경우는 별로 없음 
- 모놀리틱 구조는 특정 모듈이 2배 더 필요하면 1테라 씩 두 쌍둥이가 필요함 
- 마이크로 서비스는 증량이 필요한 모듈만 N배 차별화된 용량에 대해 필요한 만큼만 증설이 가능함
2) 팀이 커지면? 같이 하나의 대규모 어플리케이션을 작업한다는 것은 어렵다 

- 한 번 릴리즈 하려면 여러 모듈 개발자들이 규칙, 일정을 맞추어야 함 

- 각각의 독립적인 프로그램들 - 통신, API를 통해 정보를 주고 받도록 함 
- 따로 DB를 갖고 있음 / 우리 팀 프로젝트가 기능을 확장하고, 수정해도 옆 부서의 다른 프로젝트에 영향을 주지 않음 (통합 관련 회의가 줄어듦) / 릴리즈 일정이 부서별로 달라져도 됨 (독립적) // 팀의 운영(HR)에 대한 접근법도 달라짐 

-> 해당 프로그램에 최적화된 사람과 기술을 선택할 수 있다 (언어, 개발 스택, polyglot)

* Why Microservice Architecture? 
- 작은 서비스들로 찢는다 / 3개의 기능이 필요할 뿐, 각각 독립적인 서비스들로 떼어내서 실행시키고, 이걸 모아 어플리케이션으로 제공하자 / product = group of independent services / 모두 business area에 따라 쪼개지고, 각각이 원하는 tech stack을 활용하여 개발됨 / 서로 다른 서비스들은 rest over HTTP를 활용하여 통신 가능 + 작고, 빠르다

 

(1) Scalability – scalie independently without affecting other microservices – 모놀리틱은 용량 부족하면 세쌍둥이
(2) Availability - 가용성 - 계속 서비스가 동작하는가? 구성 요소 중 하나가 먹통이 되면? 모놀리틱은 다 죽음
- 일부 기능이 죽으면, 약간의 지연은 있겠지만, 걔만 되살리면 된다 - 모놀리틱처럼 통으로 망가지지는 않음
(3) Fault Tolerance – 장애 대응 – application의 작은 부분만 영향을 받는다 (SK C&C 전체 다 죽지 않고) 
(4) Agility - 요구사항이 바뀔 때, agile하게 대응 가능 - 작은 규모 팀, 지금 당장 필요한 기능을 빠르게 개발
(5) Polyglot Persistence - 하나의 거대한 서비스를 만드는데, 여러 언어와 여러 DB가 공존하는 구조
- 목적에 맞는 도구를 최적화하여 사용할 수 있다 (multi-lingual) / 모놀리틱은 DB와 major 언어가 정해짐
- 마이크로서비스는 선호하는 기술 스택으로, 독립적으로 개발 가능함 (polyglot) - 각자 본인의 역할에 충실
(6) Maintainability - 유지보수의 편리함 / 작은 파일, 프로그램들로 많이 나뉘어짐 - 덩치 큰 하나보다, 덩치 작은 여러 개가 유지보수하기 쉽다

 

* 마이크로 서비스가 장점을 갖는 경우
(1) Software stack agnostic - 각자 알아서 짜 / API만 맞추자 (HTTP 통신 프로토콜로 하는 것) 
- SW stack은 알 필요 X, 얽매이지 않음 - 원하는 기능만 제대로 해주면 됨 / 내부는 알아서 짜라 (최적화 가능)
(2) Faster Development - 작은 SW를 하루에 릴리즈 4번이나 바꿀 수 있는 것 ex) 네이버, 구글

(3) clear separation of business concerns - 복잡하니 나중에

+ 별도로 개발되고, 유지보수 되며, 7~9명의 작은 팀 내부에서 개발하고, 네트워크를 통해 서로 대화하며, 각자 어떻게 개발했는지 내부적인 구현에는 관심이 없다 - 각각의 서버는 API를 제공할 뿐
- mesh 그물 라인은 통신 라인이 있는 것을 의미 - API가 미리 잘 정의하는 것 중요 // 객체지향의 기법과 유사함
- 객체와 같이 각각 독립적인 컨테이너들로 떨어져 있는 것

 

- flask crud resful 예제 - get put delete 등 정말 작은 프로그램을 개발하기 위한 도구 – micro 프로그램들을 짬
- 이런 애들을 컨테이너 위에 구현함 + 굳이 프레임워크 안 써도 되는데, 통계 정보 등 기타 편하니까 쓰는 것

+ 도커는 자기가 직접, 쿠버네티스는 NodePort라는 프로그램이 대신 하는 것 
– Cluster IP - 쿠버네티스를 띄우자마자 get all을 하면 있음 - DNS를 포함하여, 클러스터를 논리적으로 하나로 묶어줌

 

 

 

Chap18. Microservices and Killercoda
- 쿠버네티스는 도커 기반의 컨테이너를 활용해서, 그 위에 추가적인 기능들을 제공하는 오케스트레이터 SW
- Basic Objects in k8s – Node, Cluster, Container, Pod, Deployment, Ingress 

* 컨테이너 개념은 그대로 사용함 - 쿠버네티스에서는 조금 더 큰 개념이 필요 -> pod을 고안함

 

* Pods - 개발 관점에서 가장 작은 단위는 컨테이너 But 운영 관점에서는 DB, Logic 등이 함께 움직임 

- 개별적으로 컨테이너를 운용할 일X // 함께 움직여야 하기 때문에 IP Address를 묶는다. 

- 유의미한 기능을 하는 최소 단위가 pod - 내부에 컨테이너들이 들어감
ex) 1a, 1b : 컨테이너1에 해당하는 애가 2개 떠있구나 // 동일한 IP Address를 하나 부여해서 3개의 컨테이너가 함께 쓰는 것처럼 보인다 - localhost로 본인들을 호출할 수 있다

- basic building block of Kubernetes – the smallest and simplest unit in k8s – 쿠버네티스는 운영 관점이니까 
- pod은 하나의 IP Address를 공유 - 포트 넘버만 다르게 부르면 됨 / 내부 컨테이너들이 자기들끼리 대화하기 용이
- Each pod is assigned a unique IP address – pod 안의 애들은 localhost에 port number만 주면 각자 접속 가능

 

* Nodes - 노드 = 도커 머신, 컴퓨터에 상응 / A worker machine in Kubernetes – VM or physical machine 
- each node contains the services (a set of pods using label selectors) necessary to run pods 

* Clusters - 노드들의 집합체가 클러스터 / 노드가 클러스터 안으로 끌려들어감 + 스토리지들이 클러스터에 붙음
- 하나의 논리적인 컴퓨터, 클러스터가 우리의 운영의 대상
- A set of nodes that run containerized applications managed by Kubernetes 
- 이 클러스터나 노드들이 직접 인터넷에 노출되지는 않음 – 네트워크가 방어됨 

-> 밖으로 나가려면 클러스터에 구멍을 뚫어서 외부로 나가야 함

* Deployment - 하나의 얌파일로 필요한 것들을 다 띄움 – programmer describe a desired state in a Deployment
- 개발자는 희망하는 상태를 전달해 – 도커 파일은 실행, 쿠버네티스는 부탁 (pod 4개가 뜨길 희망합니다) 
- 4개 중 하나가 죽었어 -> 쿠버네티스는 모니터링하다가 다시 살려준다 - 서비스가 어떻게든 유지되도록 
* 얌파일에 인프라 기술하는 것이 desired state

 

** 도커하고 다른 큰 차이점

- 도커스웜 vs 쿠버네티스 - 쿠버네티스에는 서비스 운영할 때 필요한 프로그램들이 많음 
- 도커는 도커 엔진 / 도커 데몬 끝 (내가 도커 엔진에게 CLI로 4개 만들어주세요 요청함) 
- 쿠버네티스는 무수한 프로그램들의 덩어리 - 쿠버네티스가 해주는거야 X 아주 구체적인 Deployment Controller 프로그램이 하는 것 
- 도커에게 명령을 주면, 도커가 이에 해당하는 행동을 함 (4개를 만들어라) - 이게 도커 스타일 

- 쿠버네티스는 인간이 아니라 쿠버네티스가 하는 것 // 4개가 동작하도록 만들어 주셨으면 좋겠어요 부탁 (개발과 운영의 차이와 비슷)

 

* Ingress – An API Object that manages external access to the services in a cluster, typically HTTP 
- ingress can provide load balancing, SSL termination and name-based virtual hosting 

+ 제일 처음에는 service/cluster IP 딱 하나 떠있음 - 서비스 안의 cluster IP / node port 얘도 서비스
- 서비스가 뭐냐? 프로그램이다 - 쿠버네티스도 처음에는 도커 스웜 + borg, omega 정도 -> 점점 기능이 많아짐 
- 개발팀에서는 자주 쓰는 기능들을 라이브러리를 만들어내고, 운영팀에서는 쿠버네티스로 이것들을 도입하는 것