쿠버네티스 (1-5) | 쿠버네티스 소개

앞으로의 스터디 내용은 <Kubernetes in Action>을 기반으로 진행합니다.
자세한 내용은, 해당 책을 확인해주세요! 
http://www.yes24.com/Product/Goods/89607047 

서론

쿠버네티스 등장 배경

기존 소프트웨어 앱 트랜드 = 모놀리스, Monolith

모놀리스 (Monolith) 애플리케이션 : 여러 모듈이 상호작용하는 로직을 하나의 프로그램 내에서 구동시키는 방식
⇒ 소규모 서비스엔 어울릴 수 있으나, 서비스가 거대해질수록 소프트웨어의 확장성 및 유연성이 줄어든다는 치명적인 단점이 있음

마이크로서비스 (Microservices) : 모놀리스 방식을 대체하기 위한 개념으로, 여러 모듈을 독립된 형태로 구성
⇒ 언어에 종속되지 않고 변화에 빠르게 대응할 수 있으며, 각 모듈의 유지/보수(관리)가 쉬움

https://den-shin.tistory.com/m/51

모놀리스 기반 레거시는 업데이트 주기가 느리다. 매번 다시 전체를 패키징해서 넘기고 배포하는 구조 때문에 그렇다.

그래서 기업들은 점점 마이크로서비스를 도입해 시장에 보다 빠르게 대응하고자 한다.

마이크로 서비스는 "독립적으로 실행되는 작은 구성 요소로 서비스를 세분화하는 것", 

"각 요소를 분리시켜 개발, 배포, 업데이트, 확장 등의 업무를 모두 개별적으로 실행할 수 있게 하는 것"을 의미한다.

 

구성 요소의 개수 증가 = 시스템 구성 및 관리의 어려움 증가

각각 나눠서 속도는 올라갔지만, 개별적으로 관리할 대상이 늘어난 것이기도 해서, 

"관리의 자동화"가 필요해졌다. 

정확히는, 각 구성 요소의 서버 배포를 자공으로 스케줄링 / 구성 / 관리 / 장애 처리 하는 일을 의미한다.

이를 수행하는 것이 쿠버네티스이다. 

 

쿠버네티스는,

• 애플리케이션을 원하는 만큼 자주 배포할 수 있게 도와주는 도구이다.
• 애플리케이션을 자동으로 모니터링하고 스케줄링을 조정하게 도와주는 도구이다.
• 시스템 관리자의 관리 대상을 개별 애플리케이션에서 쿠버테니스 및 인프라로 단순화해주는 도구이다.
• 하드웨어 인프라를 추상화하고 데이터센터를 하나의 컴퓨팅 자원으로 바라보게 해주는 도구이다.
• 개발자가 모든 유형의 애플리케이션을 배포하고 실행할 수 있게 도와주는 도구이다.

 

 

1-5-1 쿠버네티스의 필요성

1-5-1-1 모놀리스에서 마이크로서비스로

모놀리스 애플리케이션의 특징

• 요소 간 강하게 결합되어 있다
• 전체가 하나의 개체로 개발, 배포, 관리된다. 즉 부분 변경이 번거롭다.
• 구성 요소 간 경계가 불분명해진다. 구성 요소 간 의존성이 커진다.
• 시스템의 복잡성이 증가하여 관리가 어렵다. 즉, 품질 저하 가능성이 높다.
• 수평적 확장이 어렵다
  • 수직적 확장 = Scale Up. 서버 구성 요소를 추가하는 등 성능을 증대. 비싸고, 한계가 있다.
  • 수평적 확장 = Scale Out. 서버 자체 혹은 앱의 복제본을 실행. 저렴하고, 한계가 없다.

마이크로 서비스의 특징

• 독립적인 프로세스로 실행된다
• 단순한 API로 상호 간(마이크로서비스 간) 통신한다
  • RESTful API를 제공하는 HTTP와 같은 동기 프로토콜 사용이 가능하다
  • AMQP와 같은 비동기 프로토콜 사용이 가능하다.
• 정적인 외부 API를 제공하는 독립형 프로세스라는 점에서 개별 개발 및 배포가 가능하다
• 특정 마이크로서비스별로 리소스 조절이 가능하다
• 구성 요소 수의 증가로 상호 의존성 파악이 어려워 배포 결정이 복잡해진다
• 서비스 간 분산된 체계로 인해 디버그 및 버그 추적이 어렵다 (분산 추적 시스템을 도입해야 한다. e.g. Zipkin)
• 마이크로서비스가 개별적으로 개발되어, 종속되는 라이브러리도 모두 다른 문제가 발생한다.

RESTful API 알아두기 

REST의 정의
“Representational State Transfer” 의 약자
월드 와이드 웹(www)과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 개발 아키텍처의 한 형식
REST는 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일이다. REST는 네트워크 상에서 Client와 Server 사이의 통신 방식 중 하나이다.
HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다.
즉, REST는 자원 기반의 구조(ROA, Resource Oriented Architecture) 설계의 중심에 Resource가 있고
HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍쳐를 의미한다.
웹 사이트의 이미지, 텍스트, DB 내용 등의 모든 자원에 고유한 ID인 HTTP URI를 부여한다.
CRUD Operation
Create : 생성(POST) Read : 조회(GET) Update : 수정(PUT) Delete : 삭제(DELETE) HEAD: header 정보 조회

자원을 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미한다.
즉, 자원(resource)의 표현(representation) 에 의한 상태 전달


자원(resource)의 표현(representation)
자원: 해당 소프트웨어가 관리하는 모든 것 -> Ex) 문서, 그림, 데이터, 해당 소프트웨어 자체 등
자원의 표현: 그 자원을 표현하기 위한 이름 -> Ex) DB의 학생 정보가 자원일 때, ‘students’를 자원의 표현으로 정한다.

상태(정보) 전달
데이터가 요청되어지는 시점에서 자원의 상태(정보)를 전달한다.
JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적이다.

REST가 필요한 이유
‘애플리케이션 분리 및 통합’
‘다양한 클라이언트의 등장’
최근의 서버 프로그램은 다양한 브라우저와 안드로이폰, 아이폰과 같은 모바일 디바이스에서도 통신을 할 수 있어야 한다. 이러한 멀티 플랫폼에 대한 지원을 위해 서비스 자원에 대한 아키텍처를 세우고 이용하는 방법을 모색한 결과, REST에 관심을 가지게 되었다.

Client는 URI를 이용해서 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청한다.
Client가 자원의 상태(정보)에 대한 조작을 요청하면 Server는 이에 적절한 응답(Representation)을 보낸다.
REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 Representation으로 나타내어 질 수 있다.
JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적이다.

REST API의 개념
REST API란 API(Application Programming Interface)란 데이터와 기능의 집합을 제공하여 컴퓨터 프로그램간 상호작용을 촉진하며, 서로 정보를 교환가능 하도록 하는 것

REST API의 정의
REST 기반으로 서비스 API를 구현한 것
최근 OpenAPI(누구나 사용할 수 있도록 공개된 API: 구글 맵, 공공 데이터 등), 마이크로 서비스(하나의 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처) 등을 제공하는 업체 대부분은 REST API를 제공한다.
REST API의 특징
사내 시스템들도 REST 기반으로 시스템을 분산해 확장성과 재사용성을 높여 유지보수 및 운용을 편리하게 할 수 있다.
REST는 HTTP 표준을 기반으로 구현하므로, HTTP를 지원하는 프로그램 언어로 클라이언트, 서버를 구현할 수 있다.
즉, REST API를 제작하면 델파이 클라이언트 뿐 아니라, 자바, C#, 웹 등을 이용해 클라이언트를 제작할 수 있다.

RESTful의 개념
RESTful이란 RESTful은 일반적으로 REST라는 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어이다.
‘REST API’를 제공하는 웹 서비스를 ‘RESTful’하다고 할 수 있다.
RESTful은 REST를 REST답게 쓰기 위한 방법으로, 누군가가 공식적으로 발표한 것이 아니다.
즉, REST 원리를 따르는 시스템은 RESTful이란 용어로 지칭된다.
RESTful의 목적 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것
RESTful한 API를 구현하는 근본적인 목적이 성능 향상에 있는 것이 아니라
일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높이는 것이 주 동기이니,
성능이 중요한 상황에서는 굳이 RESTful한 API를 구현할 필요는 없다.

https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html

 

1-5-1-2 일관된 애플리케이션 환경

애플리케이션 실행 환경이 모두 다르다는 것은 개발과 운영 측면에서 항상 큰 숙제였다.

개발 환경과 프로덕션 환경 간 차이, 그리고 프로덕션 환경 내에서도 프로덕션 머신 간 환경 차이까지 있다. 

즉 개발 환경과 프로덕션 환경이 정확히 일치하도록, 라이브러리, 시스템 구성, 네트워크 등 동일한 환경을 구성해두고, 가능하면 동일한 구성의 서버 환경에 애플리케이션을 추가하는 방식이 이상적이다.

 

개발 환경과 프로덕션 환경의 차이 알아두기

개발 환경과 프로덕션 환경

local 로컬 개발 환경
먼저 개발을 하려면, 각자 개발자 PC에 개발 및 테스트 환경이 셋업 되어 있어야 한다. 각 개발자마다, 설치된 서버 환경을 local 환경이라고 한다. (예. 각 PC에 MySQL등의 DB와 Tomcat등의 제품을 설치하고, Eclipse와 같은 개발툴과, 컴파일러 등이 설치되어 있는 환경) 이 local 환경을 구축할시에 가장 주의해야 할점은 모든 개발자가 같은 개발 환경을 사용해야 한다는 것이다. 실제로 많이 일어나는 문제인데, 다른 version은 JVM를 사용하거나, 다른 버전의 Tomcat을 사용하거나 Lang (문자 local 설정)을 서로 다르게 해서, 정작 코드를 합칠때, local에서 잘 작동했던 코드가 작동하지 않는 경우가 많다. 개발 환경을 표준화 하는 방법은 여러 방법이 있지만, 전체 개발 환경 (JDK, Eclipse, 라이브러리)을 zip 파일 형태로 묶어서 사용하는 방법이 가장 일반적이다. 또는 뒤에서도 설명하겠지만, maven을 사용할 경우, 개발에 사용되는 JDK,라이브러리 버전등을 지정할 수 있기 때문에 개발환경 차이에서 오는 문제점 상당 부분을 해소할 수 있다.

dev 서버 개발 환경
개발 환경은 각 개별 개발자들이, 만든 코드를 합쳐서 서버 환경에서 테스트해볼 수 있는 환경이다. 소스코드를 형상관리 시스템에 commit하면, 코드는 이 dev 환경에 자동으로 배포되고, 이 환경에서 테스트가 된다. 기능 개발을 위주로 하기 때문에, 서버의 환경은 production 보다 훨씬 작다. 예를 들어 production이 클러스터링 환경으로 수개의 서버로 구성된다면, 개발 환경은 한 두 개의 서버로 기능 구현이 가능한 정도로 구축하는 것이 일반적이다.

Integration 통합 개발 환경
통합 개발 환경은, 여러개의 컴포넌트를 동시 개발하는 프로젝트가 있고, 각 컴포넌트가 다른 컴포넌트에 대해서 dependecy를 가지고 있을때, 컴포넌트를 통합 및 테스트 하는 환경으로 사용한다. 예를 들어 단말과 서버를 같이 개발하는 환경의 경우 이 integration 환경에서 통합을 한다. dev 환경과 마찬가지고, 최소한의 set으로 구성하되, dev 환경에서 release가 되면 주기적으로 deploy 한다.

qa 테스팅 환경
테스트 환경은 QA 엔지니어에 의해서 사용되는 환경으로, short release 주기에 따라서, 개발환경에서 QA 환경으로 배포 되고, 여기서 기능 및 비기능 (Load Test)등을 QA 엔지니어가 수행한다. 비 기능 테스트를 수행할 시에는, production과 거의 유사한 환경을 만들어 놓고, 테스트를 수행한다. (경우에 따라서는 비기능 테스트는 release전에, production 환경에서 직접 수행하는 경우도 있다. 이런 경우는 release cycle이 매우 긴 경우 주로 사용하는데, 기업의 내부 IT 시스템 만들어서 몇 년씩 사용 하는 경우와 같은 때 이런 방식을 이용한다

staging 스테이징 환경
운영 환경과 거의 동일한 환경을 만들어 놓고, 운영환경으로 이전하기 전에, 여러 가지 비 기능적인 부분 (Security, 성능, 장애등)을 검증하는 환경이다.

production 운영 환경
실제 서비스를 위한 운영 환경

출처: https://bcho.tistory.com/759 [조대협의 블로그] 

 

형상관리란?

형상관리의 정의 (1)
소프트웨어 개발을 하다보면 필연적으로 듣프로젝트를 하다보면 형상 관리라는 단어와 그 중요성을 듣게된다.
하지만 지금까지 “형상관리==git. 특정 시점에 대해 상태를 기록해놓으면 이후라도 언제든지 그 환경으로 돌아갈 수 있게 도와주는 것” 정도로 생각하고 제대로된 정의는 찾아보지 않았다.
그럼 이제 위키피디아에서 정의하는 형상관리를 살펴보자.

소프트웨어 구성 관리（ Software Configuration Management) 또는 형상 관리는 소프트웨어의 변경사항을 체계적으로 추적하고 통제하는 것으로, 형상 관리는 일반적인 단순 버전관리 기반의 소프트웨어 운용을 좀 더 포괄적인 학술 분야의 형태로 넓히는 근간을 이야기한다. 소프트웨어 구성 관리란 소프트웨어 소스 코드 뿐 아니라 개발 환경, 빌드 구조 등 전반적인 환경 전반적인 내역에 대한 관리 체계를 정의하고 있다．

변경 관리 / 버전 관리 / 형상 관리

오호, 형상 관리랑 버전 관리랑 비슷한건지 알았는데 형상관리가 더 포괄적인 거였다.
그런데 이 둘의 차이가 뭘까하고 찾아보는 과정에서 변경관리라는 개념까지 나왔다.
이 세가지 개념을 간단하게 아래와 같이 정리 가능할 수 있다.

변경 관리 — 소스코드 변경 사항에 대한 관리
버전 관리 — 변경사항을 ‘버전’이란 개념을 통해 관리.
형상 관리 — 위의 개념을 포함해 프로젝트와 관련된 모든 변경사항을 관리.

https://sujinnaljin.medium.com/software-engineering-%ED%98%95%EC%83%81-%EA%B4%80%EB%A6%AC%EC%97%90-%EB%8C%80%ED%95%98%EC%97%AC-932d14f6f341

 

1-5-1-3 데브옵스를 통한 지속적인 배포

데브옵스

• 개발팀이 직접 애플리케이션을 배포하고 관리한다는 것. 개발, QA, 운영 전체가 하나의 프로세스로 협업하는 것.
• 신속한 애플리케이션 제공을 통해 피드백 반영이 용이해짐. 
• 운영팀이 아닌 개발자라도 배포할 수 있도록 배포 프로세스의 간소화, 단순화가 필요
• 노옵스 : 개발자가 하드웨어 인프라를 전혀 알지 못하더라도 운영팀없이 배포가 가능한, 데브옵스의 이상향
• 이를 <쿠버네티스>가 가능케 한다!

 

 

1-5-2 컨테이너 기술

1-5-2-1 컨테이너란?

모든 마이크로서비스를 각각 다른 가상머신에 올리는 방법으로 격리시킨다면?

1. 리소스 낭비) 구성요소가 갈수록 작아지고 숫자가 많아지면서 하드웨어 리소스가 발생한다.

2. 복잡한 관리) 가상머신별로 개별적으로 구성하고 관리하는 작업량이 상당하다.

 

리눅스 컨테이너를 사용해 격리한다면?

동일한 호스트 위에서 여러개의 서비스를 실행할 수 있는데, 

동시에 서로 다른 환경을 만들어줄 수도 있고, 오버헤드를 적게 가져가면서 격리가 가능하다.

 

가상머신	컨테이너
무겁다. 구성요소 프로세스 외로도 시스템 프로세스를 실행해야 한다. 추가 컴퓨팅 리소스가 필요하다는 의미이다.	가볍다. 동일한 하드웨어 기준 더 많은 수의 구성요소 실행이 가능하다. 추가된 프로세스에 대한 오버헤드가 없다. 시스템 서비스를 실행하지 않기 때문이다. (부팅 없이 즉시 실행)
가상머신 별로 가진 게스트 OS는 가상화를 제공하는 하이퍼바이저를 통해 호스트 OS를 거쳐 명령한다.	가상화를 담당하는 하이퍼바이저 없이 곧바로 호스트 OS 커널에서 명령을 수행한다.
완전한 격리를 제공해 보안 상 안전하다.	모두 동일한 커널을 사용한다는 점에서 보안 위험이 발생한다.

 

리눅스 컨테이너는 격리를 어떻게 할까?

리눅스 네임스페이스를 사용해 격리하고, 리눅스 컨테이너그룹을 통해 리소스 양을 제한한다.

 

1. 리눅스 네임스페이스의 사용

리눅스 네임스페이스는, 각 프로세스가 시스템에 대해 독립적인 뷰를 갖도록 한다.

리눅스 시스템마다 가진 하나의 네임스페이스에는
시스템 리소스 (사용자 ID, 네트워크 인터페이스, 파일 시스템, 프로세스 ID 등)를 포함한다.

물론, 네임스페이스를 추가할 수는 있지만, 하나의 프로세스는 하나의 네임스페이스 위에서 실행된다.

실행 중인 프로세스는 해당 네임스페이스 내에 들어있는 리소스만 볼 수 있다는 의미이다.

(물론 소속은 여러 네임스페이스가 가능하다)

 

네임스페이스 더 알아보기

리눅스 네임스페이스란?
리눅스 네임스페이스는 프로세스를 실행할 때 시스템의 리소스를 분리해서 실행할 수 있도록 도와주는 기능입니다. 한 시스템의 프로세스들은 기본적으로 시스템의 리소스들을 공유해서 실행됩니다. 이를 단일 네임스페이스라고 생각해볼 수 있습니다. 실제로 리눅스에서는 1번 프로세스(init)에 할당되어있는 네임스페이스들을 자식 프로세스들이 모두 공유해서 사용하는 구조로 이루어져있습니다.

현재 리눅스에서 지원하는 네임스페이스는 크게 보면 다음과 같습니다.
Cgroup 네임스페이스(cgorup)
IPC 네임스페이스(ipc) : 프로세스 간 통신
네트워크 네임스페이스(network)
마운트 네임스페이스(mnt)
PID 네임스페이스(pid) : 프로세스 ID
사용자 네임스페이스(user) : 사용자 ID
UTS 네임스페이스(uts) : 호스트와 도메인 네임
시간 네임스페이스(time)

https://www.44bits.io/ko/keyword/linux-namespace

 

Process와 관련된 Namespace의 특징
Namespace와 Process는 밀접한 관계를 가지고 있다. 먼져 Process와 관련된 Namespace의 특징을 알아본다. Namespace는 Namespace에 소속되어 있는 Process가 존재하지 않는 경우 Linux Kernel에 의해서 자동으로 제거된다는 특징을 갖고 있다. 즉 Namespace가 생성되기 위해서는 Namespace에 소속되어 있는 Process가 반드시 존재해야 한다는 의미이기도 하다. 이러한 이유 때문에 Namespace와 관련된 System Call들은 모두 Process와 연관되어 있다.

Namespace와 관련된 Process의 특징
Namespace와 관련된 Process의 특징을 알아본다.
모든 Process들은 반드시 모든 Namespace Type의 특정 Namespace에 소속되어야 한다는 특징을 갖고 있다.
따라서 Container의 Process뿐만 아니라 Host의 Process들도 Host의 Namespace에 소속되어 동작한다. 또한 fork() 또는 clone() System Call을 이용하여 Child Process를 생성하는 경우, Namespace 관련 설정을 적용하지 않는 이상 기본적으로 Child Process는 Parent Process가 이용하는 Namespace를 상속받아 그대로 이용한다는 특징도 갖고 있다. 이러한 상속 특성 때문에 기본적으로 Host의 Process들은 Host의 Namespace에 소속되고, 각 Container의 Process들은 각 Container의 Namespace에 소속되어 동작한다.

https://ssup2.github.io/onebyone_container/3.4.Namespace_with_Process/

 

2. 리눅스 컨테이너 그룹(cgroup)으로 리소스 양 제한하기

컨테이너가 사용 가능한 시스템 리소스 양을 제한하기 위해 리눅스 커널 기능인 cgroup을 이용한다.

설정량 이상의 CPU, 메모리, 네트워크 대역폭 사용이 불가하다.

 

1-5-2-2 도커 소개

도커란

• 컨테이너를 여러 시스템에 쉽게 이식하게 하는 최초의 컨테이너 시스템
• 패키징 단순화 : 서로 다른 환경 및 종속성과 무관히 자유롭게 애플리케이션을 프로비저닝하는 데에 사용 
• 파일 시스템 포함 전체 환경을 애플리케이션과 함께 패키징 - 어디서나 동일하게 실행 가능
• 가상머신과 동일한 수준의 격리를 컨테이너 기반으로 제공
• 레이어 구성 : 여러 이미지에서 공유되고 재사용될 수 있도록 도커 기반 이미지는 레이어로 구성된다
  • 서로 다른 이미지들도 동일한 레이어를 포함할 수 있다. 동일한 레이어를 포함하면 2번 전송할 필요가 없으니 배포가 효율적이고 빠르게 진행된다.
  • 또한, 각 레이어는 동일한 호스트에 1회만 저장된다. 스토리지 공간도 효율적으로 사용이 가능하다.
  • 컨테이너 이미지 레이어는 읽기 전용이며, 컨테이너 실행 시 이미지 레이어 위 쓰기 가능 레이어를 추가하여 실행한다.
• 도커는 애플리케이션 패키징, 배포, 실행용 플랫폼

도커의 구성요소

• 이미지 : 애플리케이션 + 해당 환경을 패키징한 것. 파일시스템 및 실행파일 경로 등 메타데이터 포함.
• 레지스트리 : 도커 이미지를 저장하고 공유하는 저장소. 푸시/풀 가능.
• 컨테이너 : 도커 이미지 기반해 생성된 컨테이너. 다른 프로세스와 격리되어 실행. 리소스 양도 제한.

도커로 이미지 빌드부터 배포, 실행까지

1. 개발자는 도커에 이미지를 빌드한 뒤 푸시하라고 명령한다
2. 도커는 개발 머신 위에서 이미지를 빌드한다
3. 개발머신 위 도커는 이미지를 레지스트리(저장소)에 푸시한다
4. 운영머신 위 도커는 이미지를 레지스트리로부터 풀해서 가져온다
5. 운영머신 위 도커는 가져온 이미지를 기반으로 컨테이너를 실행한다

가상머신	도커 컨테이너
각 가상머신은 자체 커널을 사용하여 완전히 격리된다.	컨테이너는 호스트의 리눅스 커널을 사용하므로 특정 커널 버전 관련 의존성이 발생할 수 있다. 호스트 아키텍처의 영향도 받는다.
파일 시스템 공유 한 가상머신 위 다른 두 앱은 동일한 파일 시스템을 공유한다.	파일 시스템 공유 2개의 다른 컨테이너가 파일 시스템을 공유하려면 해당 이미지 레이어를 동일하게 사용하면 된다. 읽기전용이므로 상호 격리는 유지된다.

 

1-5-2-3 도커의 대안, RKT

RKT

• 컨테이너 실행 플랫폼 (도커와 동일)
• 컨테이너 형식 및 런타임과 관련해 업계 표준 준수에 방점을 둔 플랫폼
• 쿠버네티스는 도커 외로도 RKT를 지원하는 것처럼, 도커 기반 컨테이너만을 위한 것이 아니다

 

1-5-3 쿠버네티스

수많은 애플리케이션 구성 요소의 관리, 개발, 배포 솔루션을 위해 등장한 쿠버네티스

 

쿠버네티스

• 컨테이너화된 애플리케이션의 배포와 관리를 돕는 소프트웨어
• 인프라를 추상화해 각 노드를 하나의 컴퓨터처럼 사용하도록 하여 개발, 배포 관리를 단순화
• 개발자 : "노드 클러스터의 운영체제 역할". 개발자가 인프라 서비스를 구현하지 않아도
  서비스 디스커버리, 스케일링, 로드밸런싱, 자가치유 등을 수행 가능.
• 운영자 : "리소스 효율화 도구" :
  노드 위치와 무관히 실행 가능한 환경을 제공해 효율적인 재배치 및 조합으로 리소스 효율화 가능

https://kubernetes.io/ko/docs/concepts/overview/components/

 

1-5-3-1 쿠버네티스 구성 요소

• 마스터 노드
  • 개발자가 애플리케이션 매니페스트를 마스터에 게시
  • 전체 쿠버네티스 시스템을 제어, 관리하는 컨트롤 플레인을 실행
• 워커 노드 클러스터
  • 쿠버네티스가 애플리케이션을 워커 노드 클러스터에 배포
  • 실제 배포되는 컨테이너 애플리케이션 실행
  • 하나의 노드에 여러 개의 애플리케이션 배포 가능 (함께 실행되도록 지정 가능)
  • 클러스터 내 워크 노드들은 위치와 무관히 상호 통신 가능

 

https://catalog.us-east-1.prod.workshops.aws/v2/workshops/9c0aa9ab-90a9-44a6-abe1-8dff360ae428/ko-KR/10-intro/100-k8s

컨트롤 플레인

• 클러스터를 제어하고 작동하는 역할
• 하나의 마스터 노드에서 실행될 수도, 고가용성을 위해 여러 노드로 분할/복제될 수도 있음
• 구성요소
  • 쿠버네티스 API 서버 : 사용자, 컨트롤 플레인 구성 요소들과 통신하는 매개체
  • ETCD : 분산 데이터 저장소. 클러스터 구성을 지속적으로 저장하는 장소.
  • 컨트롤러 매니저 : 구성 요소 복제, 워커 노드 추적, 노드 장애 처리 등 클러스터 관련 기능 수행
  • 스케줄러 : 애플리케이션 배포 기능. (배포할 구성 요소들을 각 워커 노드에 할당)

워커 노드의 구성

• 컨테이너 런타임 : 컨테이너를 실행하는 요소.
  • 도커일 수도, RKT일 수도, 다른 런타임일 수도 있다.
• Kubelet : API 서버와 통신하고 컨테이너를 관리한다.
• KubeProxy (쿠버네티스 서비스 프록시) : 구성 요소 간 네트워크 트래픽의 로드밸런싱 담당

 

 1-5-3-2 쿠버네티스로 애플리케이션 실행하기

1. 하나 이상의 컨테이너 이미지로 패키징하기
2. 패키징된 이미지를 레지스트리로 푸시하기
3. 쿠버네티스 API 서버에 애플리케이션 디스크립션 게시하기
4. 디스크립션으로 컨테이너 실행하기
   1. 디스크립터를 통해 파드 수와 컨테이너 수, 그리고 각 파드 당 복제본 수를 명시한다.
      파드 = 컨테이너 세트. 한 파드에 여러 컨테이너가 들어있을 경우 함께 배치해서 서로 격리하지 않은 채 실행해야 함.
   2. 컨트롤 플레인의 스케줄러가 명시된 각 컨테이너에 필요한 리소스를 계산한다
   3. 스케줄러가 해당 시점에 사용 가능한 워커 노드에 컨테이너를 할당한다
   4. 할당받은 워커 노드의 Kubelet은 컨테이너 런타임에 필요한 컨테이너 이미지를 가져와 실행을 지시한다
5. 실행 중
   1. 애플리케이션의 배포 상태와 사용자의 디스크립션이 일치하는지 지속적으로 확인한다
      (중단 혹은 응답 중지 발생 시 쿠버네티스가 자동으로 재시작 진행)
   2. 복제본 수를 늘릴지 줄일지 실행 중에 결정 가능하다. (추가 복제본 기동 / 초과 복제본 중지)
      쿠버네티스가 실시간 메트릭을 기반으로 자동 조정할 수도 있다.

 

디스크립션이란

컨테이너 이미지, 애플리케이션 구성 요소 포함 이미지, 구성 요소간 통신 방법, 동일 서버 내 배치되어야 하는 구성 요소 정보 등

실행할 구성 요소 복제본 수, 내외부 서비스 제공 구성 요소, 타 구성 요소에서 검색 가능하도록 IP 주소 하나를 노출하는 구성 요소 등

Application objects on K8S are all composed of specific resource descriptions, including deployment, service, etc. They are saved in their own files or collectively written to a configuration file. Then kubectl apply – f is deployed. If the application is only composed of one or several such services, the above deployment method is enough. For a complex application, there will be many resource description files similar to the above, such as microservice architecture application. There may be as many as ten or dozens of services constituting the application. If there is a need to update or roll back the application, it may be necessary to modify and maintain a large number of resource files involved, and this way of organizing and managing the application is not enough. And due to the lack of management and control of the released application version, the The application maintenance and update on Kubernetes face many challenges, such as: (1) how to manage these services as a whole; (2) how to reuse these resource files efficiently; (3) it does not support application level version management

https://www.fatalerrors.org/a/finish-k8s-day-3-6-kubernetes-core-technology-helm.html

 

컨테이너가 할당된 노드가 달라지더라도 문제가 없는 이유

• 쿠버네티스는 서비스 별로 변하지 않는 하나의 IP 주소를 부여한다 (환경변수로 제공되거나, DNS로도 조회 가능)
• 고정된 서비스 IP 주소로, 해당 서비스를 제공하는 모든 컨테이너를 노출하고, 그 주소를 통해 모든 다른 애플리케이션과도 통신한다.
• 그렇게 일정하게 유지되는 서비스 IP 주소로 트래픽이 들어오면, Kube-proxy가 모든 컨테이너에 서비스가 연결되도록 로드밸런싱을 진행한다.

 

1-5-3-5 쿠버네티스 장점

• 애플리케이션 배포 단순화
  • 컨테이너화된 애플리케이션은 실행에 필요한 모든 것을 포함하므로 별도 설치가 필요없이 즉시 실행이 가능
  • 배포 시 고려해야 할 서버의 하드웨어 조건의 경우 쿠버네티스를 통해 간편하게 설정하여 할당 가능
• 하드웨어 활용도 증가
  • 리소스 요구사항인 디스크립션 따라 가장 적합한 노드에 애플리케이션을 할당하는 스케줄러
  • 클러스터 내 노드간 자유로운 이동을 통해 하드웨어 활용도 증대
• 상태 확인과 자가 치유
  • 모니터링 중 노드 장애 발생 시 자동으로 다른 노드로 스케줄링 진행
  • 노드 장애 시 재배치는 자동화되어, 노드 수정을 통한 하드웨어 리소스 풀 반환에만 집중 가능
• 오토스케일링
  • 부하 급증 시 인스턴스 수 자동 조정 가능
  • 클라우드 제공업체 API로도 노드 추가 통해 클러스터 크기 자동 조정 가능
• 애플리케이션 개발 단순화
  • 개발과 프로덕션 환경 일원화로 버그 수정이 용이
  • 서비스 디스커버리 및 피어 검색 기능 등 쿠버네티스의 기능 관련 부분을 구현할 필요 소멸
  • 신규 애플리케이션 출시 시 오류 있을 경우 자동 감지 및 즉시 롤아웃 중지
  • 결론적으로 CD 가속화를 통해 조직 효율 증가