Kubernetes - 01. 쿠버네티스 소개 ( 컨테이너편 )

본 포스팅은 '쿠버네티스 기초 다지기 3/e' 책을 사용하여 스터디를 하면서 정리 한 내용입니다.

Container는 가상머신이다?

Container는 hypervisor와 완전히 다릅니다. 궁극적으로는 hypervisor와 유사한 형태의 "가상화"를 목표로 하고 있지만 hypervisor는 OS 및 커널이 통째로 가상화되는 반면에 container는 간단히 보면 filesystem의 가상화만을 이루고 있습니다. container는 호스트 PC의 커널을 공유하고 따라서 init(1) 등의 프로세스가 떠있을 필요가 없으며, 따라서 가상화 프로그램과는 다르게 적은 메모리 사용량, 적은 overhead를 보입니다.

실제 하드웨어인 것처럼 에뮬레이션(emulation)을 하는 VM과 달리 container는 호스트 PC의 자원을 격리(isolation)된 상태로 그대로 활용하기 때문에 VM에 비해 성능 저하가 눈에 띄게 적습니다.

도커 vs VM - 출처 : https://www.docker.com/resources/what-container

읽고 넘어갑시다. ( http://pyrasis.com/book/DockerForTheReallyImpatient/Chapter01/01 )

컨테이너 ( 도커 컨테이너 )

컨테이너는 여러 기술을 사용해 필요한 모든 것을 상자 안에 넣고 완전히 캡슐화한, 독립형 소프트웨어로 작동하는 경량 이미지를 만든다.

이미지 안에는 애플리케이션 바이너리, 시스템 도구, 라이브러리, 환경-기반 구성, 런차임 등이 포함될 수 있다.

개발자와 운영자가 실행 환경에 구애받지 않고 컨테이너의 모든 기능을 문제 없이 실행할 수 있도록 격리해주기 때문에 이는 매우 중요한 특성이다.

실행 환경에는 개발자 노트북과 모든 상용화 준비 환경, 상용 환경이 포함된다.

컨테이너 기술의 핵심은 다음 세 가지이다.

- 컨트롤 그룹( 약자는 cgroups )

- 네임 스페이스

- 통합 파일 시스템

컨트롤 그룹

컨트롤 그룹은 각 프로세스 또는 컨테이너가 소비하는 호스트의 리소스를 공유하고 제한한다.

- Memory 컨트롤 그룹 : 페이지 접근을 그룹별로 추적하며 물리 메모리, 커널 메모리, 전체 메모리에 대한 제한을 정의할 수 있다.

- Blkio 컨트롤 그룹 : 블록 디바이스당 읽기 및 쓰기 작업의 그룹별 I/O 사용량을 추적한다. 디바이스별 읽기, 쓰기 등의 연산을 바이트 단위로 제한할 수 있다.

- CPU 컨트롤 그룹 : CPU 당 사용자 및 시스템의 CPU 시간 및 사용량을 추적한다. 가중치는 설정할 수 있지만 한계치는 설정할 수 없다.

- Freezer 컨트롤 그룹 : 자원을 효율적으로 스케줄링하기 위해 작업을 중단하고 시작하는 배치 관리 시스템에 유용하다. SIGSTOP신호는 프로세스를 일시 중단

- CPUset 컨트롤 그룹 : 멀티 코어 CPU 아키텍쳐 내의 특정 CPU에 그룹을 고정할 수 있다. 애플리케이션별로 CPU 를 고정하면 CPU 사이에서 이동하지 않게하여 로컬 메모리 접근량을 늘리거나 스레드 전환을 최소화해 코드의 성능을 향상시킬 수 있다.

- Net_cls/net_prio 컨트롤 그룹: 컨트롤 그룹 내의 프로세스에서 생성되는 송신 트래픽 클래스(net_cls) 나 우선순위 (net_prio)를 감시한다.

- Device 컨트롤 그룹 : 장치 노드에 대한 그룹의 읽기/ 쓰기 권한을 제어한다.

네임 스페이스

네임 스페이스는 프로세스가 갖는 다른 프로세서, 네트워킹, 파일 시스템, 사용자 ID 컴포넌트의 가시성을 제한한다. 다시말해서. 컨테이너 프로세스가 동일한 네임스페이스에 있는 것들만 볼 수 있도록 제한된다.

도커엔진은 다음과 같은 네임스페이스를 사용한다.

- pid : 다른 네임스페이스와 독립된 프로세스 ID 집합을 통해 프로세스를 격리한다.

- net : loopback 인터페이스를 바탕으로 네트워크 스택을 가상화해 네트워크 인터페이스를 관리한다. 하나의 네임스페이스에 존재하는 물리 네트워크 인터페이스와 가상 네트워크 인터페이스를 동시에 만들 수 있다.

Routing
라우팅은 한 네트워크에서 다른 네트워크로 패킷을 이동시키는 과정과 네트워크 안의 호스트에게 패킷들을 전달하는 과정을 의미한다. 라우팅은 정적, 동적, default 라우팅이 존재한다.

Routing Protocol & Routed Protocol
택시(라우터)의 택시기사(라우팅 프로토콜)에 의해 운반되는 고객(라우티드 프로토콜)

Routed Protocol

라우터에 의해 라우팅을 당할때 사용되는 프로토콜 라우팅 프로토콜에 의해 결정된다.

Routing Protocol

라우팅 알고리즘이라고도 하며, 어디로 전송해야할지에 대한 경로 정보를 가지고 있는 라우팅 테이블을 기억해둠.

라우팅 프로토콜	RIP, IGRP, OSPF, EIGRP
라우티드 프로토콜	TCP/IP, IPX, Apple Talk

Loopback inteface?
Loopback interface 는 관리 목적상 만들었다고 생각하면 좋습니다.
OSPF는 loopback을 Router-id 정하는데 사용했고, BGP는 update-source 로 사용했습니다.

OSPF?

OSPF(Open Shortest Path First) 최단경로우선 - OSPF는 인터넷 프로토콜인 IP 네트워킹에서 사용하기 위한 계층구조 동적 라우팅 프로토콜이다.

이것은 하나의 AS(Autonomous Sysyem)안에서 동작하는 링크 스테이트 라우팅 프로토콜의 특징을 가진다

AS?

Autonomous System ( 자율시스템 )

인터넷 내에서 자율 시스템은 인터넷에 대한 라우팅 정책을 대표하는 하나 이상의 네트워크 운영자의 통제 하에서 각기 연결된 인터넷 프로토콜 라우팅 접두사들의 모임이다. ISP에서 지원하는 자율 시스템이 여러 개 있을 수 있으나 인터넷은 ISP의 라우팅 정책만을 주시한다

예를들면 K사라는 ISP업체의 라우터들이 관리자에 의해 설정되었다면 그 K사의 라우터들은 하나의 AS 가 된다.

동일한 라우팅 정책으로 하나의 관리자에 의하여 운영되는 네트워크, 즉 한 회사나 단체에서 관리하는 라우터 집단을 자율 시스템(AS, Autonomous System)이라 하며, 각각의 자율 시스템을 식별하기 위한 인터넷 상의 고유한 숫자를 망식별번호(AS번호)라 합니다.

현재 일반적으로 사용중인 AS번호는 2-byte의 체계로 65,536개의 AS번호 사용이 가능하나, IPv4주소와 마찬가지로 가까운 미래에 고갈될 것으로 예측됩니다. 국제 인터넷 표준화기구(IETF, Internet Engineering Task Force)는 기존의 2-byte AS번호 체계의 확장 형태인 4-byte AS번호를 정의하였고,이에 따라 약 43억개의 AS번호를 사용할 수 있게 되었습니다.

EGP?
- AS 간 연결하는 라우팅 프로토콜로써 EGP, BGP 등이 있다.

IGP?
- AS 안에서 운영되는 라우팅 프로토콜로서 RIP, IGRP, OSPF, EIGRP 등이 있다.

AS 번호 사용

AS번호는 둘이상의 상위 ISP, IX와 연결된 다중 연결 사이트(Multi-Homed Site)를 구성하는 경우 필요합니다. 다중 연결 사이트에서는 도달가능정보를 여러 ISP에 배포하므로 라우팅 정책에 혼란을 줍니다. 이런 경우 AS번호를 부여함으로써 AS가 자신의 라우팅 정책과 도달가능정보를 책임 있게 배포할 수 있습니다.

AS 번호 신청은

인터넷상에서 독립적인 네트워크를 구축할 수 있는 설비를 운용하고, 두개 이상의 서로 다른 망과 연결되어 있거나 연결 계획이 있는 경우, 독자적인 라우팅 경로 설정이 가능한 경우 AS번호를 할당 신청할 수 있습니다.

Routed Protocol

라우터에 의해 라우팅을 당할때 사용되는 프로토콜 라우팅 프로토콜에 의해 결정된다.

Routing Protocol

라우팅 알고리즘이라고도 하며, 어디로 전송해야할지에 대한 경로 정보를 가지고 있는 라우팅 테이블을 기억해둠.

라우팅 프로토콜	RIP, IGRP, OSPF, EIGRP
라우티드 프로토콜	TCP/IP, IPX, Apple Talk

OSPF?

OSPF(Open Shortest Path First) 최단경로우선 - OSPF는 인터넷 프로토콜인 IP 네트워킹에서 사용하기 위한 계층구조 동적 라우팅 프로토콜이다.

이것은 하나의 AS(Autonomous Sysyem)안에서 동작하는 링크 스테이트 라우팅 프로토콜의 특징을 가진다

AS?

Autonomous System ( 자율시스템 )

예를들면 K사라는 ISP업체의 라우터들이 관리자에 의해 설정되었다면 그 K사의 라우터들은 하나의 AS 가 된다.

EGP?
- AS 간 연결하는 라우팅 프로토콜로써 EGP, BGP 등이 있다.

IGP?
- AS 안에서 운영되는 라우팅 프로토콜로서 RIP, IGRP, OSPF, EIGRP 등이 있다.

AS 번호 사용

출처 : 한국인터넷정보센터 ( https://krnic.or.kr/jsp/resources/asInfo.jsp )

AS 번호 신청은

- ipc : 프로세스 사이의 통신에 대한 접근을 관리한다.

- mnt: 파일 시스템 마운트 지점을 제어한다. 리눅스 커널에서 생성된 첫번째 네임스페이스이며 독점하거나 공유할 수 있다.

- uts: 유닉스 시간 공유 시스템은 단일 시스템이 다른 호스트와 도메인 이름 지정 스키마를 다른 프로세스에 제공할 수 있게 함으로써 버전 ID 와 커널을 격리한다.

- user: 이 네임스페이스를 사용하면 컨테이너에 추가 구성을 하지 않아도 UID/GID를 컨테이너에서 호스트로 매핑할 수 있다.

통합파일 시스템

통합 파일 시스템은 이미지를 효율적으로 저장, 다운로드, 실행할 수 있도록 해준다. 컨테이너는 새파일 시스템을 생성하지 않고도 새로운 컨테이너를 즉시 생성할 수 있는 copy-on-write 저장소를 사용한다.

copy-on-write 저장소는 git 과 같은 분산 버전 제어 시스템과 비슷한 방식으로 변경 사항을 추적한다.

통합파일 시스템은 각 레이어를 따로 구워 만든 레이어 케이크를 떠올리면 이해하기 쉽다.

	Apahce 우분투 이미지	MySQL 우분투 이미지	기본 우분투 이미지
Layer 3	아파치	MySQL
Layer 2	우분투	우분투	우분투
Layer 1	리눅스 커널	리눅스 커널	리눅스 커널

여기서 위의 우분투 이미지 레이어는 캐싱이 되어서, 도커의 두 번째 빌드시 MySQL, Apache 등의 레이어가 추가될 경우 속도가 더 빠르다.

쿠버네티스는 이런 컨테이너를 오케스트레이션 하는 플랫폼이다.

이런 컨테이너형 앱을 관리할 수 있는 서비스들이 있다. AWS 의 EKS, GCP 의 GKE , Azure의 AKS 이 세 서비스들의 공통점은 바로 K( 쿠버네티스 ) 기반의 서비스라는 것이다. 사용자는 쿠버네티스의 클러스터 관리 기능을 사용하여 클러스터의 최적화, 구성, 배포에 집중할 수 있다.

여기서 잠시 CI/CD 에 대해서 생각하고 넘어가보자. 개발을 하면서 어려웠던 점을 생각해보면 여러가지들이 있을텐데, 그 중에서 테스트 환경을 사용환경과 일치하는 개발 환경을 만드는 것은 언제나 쉽지 않고, 이런 환경 불일치는 지속적인 전달 CD의 장점을 충분히 이끌어내기 어렵다. CI는 조직의 소프트웨어 제공 수명 주기를 앞당기기 위한 첫 번째 단계로 소프트웨어 기능을 빠르고 안정적으로 고객에게 전달할 수 있도록 지원한다. 이런 CI 를 사용해 CD를 할 수 있어야만 개발자가 배포를 제대로 수행할 수 있다.

이 구조를 이용할 경우 개발자 노트북에서 배포한 컨테이너는 스테이징, 리얼 서버에 쉽게 배포할 수 있다. 이 부분이 가능한 이유는 위에서처럼 레이어를 지정해 파일을 빌드하는 컨테이너의 특성 때문이다. 다시말해, 모든 의존성이 레이어로 묶여 OS, 패키지, 애플리케이션 버전의 동일성을 보장하기가 매우 쉽다.

CD(지속적 제공)는 모든 코드 변경을 CI(지속적통합)를 이용해 자동으로 빌드하고 테스트해 사용환경으로 배포하는 과정을 형상화하고 프로세스화 한것이다.

우리가 쿠버네티스를 CI/CD와 함께 사용하면 아래와 같은 일반적인 문제에 대한 risk 를 줄일 수 있다.

- 긴 배포 주기 : 코드 수정부터 배포까지 시간이 오래걸리면 그 시간만큼 수익 손실이 발생한다.

- 어려운 코드 수정 : 배포 주기가 짧을 수록, 버그 발견이 쉬울 수 있다.

- 향상된 배포 : CI/CD 프로세스 전반을 자동화하고 모니터링, 로깅함으로써 잠재적 결함을 보다 신속하게 해결할 수 있다.

마이크로서비스와 오케스트레이션

마이크로서비스는 `Martin Fowler`의 말을 인용하여 표현하자면 다음과 같다.

간단히 얘기하면 마이크로 서비스 아키텍처 스타일은 단일 애플리케이션을 작은 서비스 모음으로 나눠 개발하는 접근 방식으
로, 각 서비스는 각자의 프로세스에서 실행되며 HTTP 리소스 API와 같은 경량의 메커니즘을 사용해 통신한다. 이런 서비
스는 비즈니스 역량을 기반으로 구축되며 완전히 자동화된 배포 머신에 의해 독립적으로 배포될 수 있다. 서비스들에 대한
최소한의 중앙 집중 관리가 필요하며 다양한 프로그래밍 언어와 다양한 데이터 저장소 기술을 사용해 작성될 수 있다.

이제 곧 수많은 컨테이너와 마이크로서비스가 생길 것이고 이를 관리할 수 있는 전략이 필요할 것이다.

격리된 컨테이너에 개별적인 마이크로 서비스를 만들거나, 단순히 애플리케이션 개발에서 이식성과 불변성에 대한 모든 장점을 최대한 활용하길 바라더라도 오케스트레이션의 필요성은 분명하다.

이런 의미에서 쿠버네티스(k8s) 와 같은 오케스트레이션 도구가 중요하다.

다음 장에서 쿠버네티스가 무엇인지, 그리고, 어떤식으로 가볍게 테스트 해볼 수 있는지 알아본다.

출처: 쿠버네티스 기초 다지기 3/e - 조나단 바이에르

참고

- https://tech.ssut.me/what-even-is-a-container/

- http://pyrasis.com/book/DockerForTheReallyImpatient/Chapter01/01

저작자표시 비영리 변경금지

'Computer > Kubernetes' 카테고리의 다른 글

Kubernetes - 10. 고가용성과 확장성을 위한 설계 (0)	2020.10.23
Kubernetes - 05. 쿠버네티스의 저장소 개념 탐구 (0)	2020.09.10
Kubernetes - 02. 쿠버네티스의 핵심구성 요소로 기초 다지기 (0)	2020.08.08
Kubernetes - 01. 쿠버네티스 소개 ( MiniKube 실습편 ) (2)	2020.08.02

Slow Thinking

Kubernetes - 01. 쿠버네티스 소개 ( 컨테이너편 )

Container는 가상머신이다?