처음부터 제대로 배우는 도커/쿠버네티스 컨테이너 개발과 운영

도커와 쿠버네티스를 활용한 컨테이너 기술의 핵심을 집대성한 실전 입문서다. 컨테이너 가상화 기술의 개념부터 시작해, 도커 기반 애플리케이션 배포와 이미지 생성, 네트워크 구성, 오케스트레이션 시스템 쿠버네티스까지 단계별로 익힐 수 있도록 구성되었다. 초판 출간 이후 변화한 최신 생태계를 반영해 전면 개정/증보되었으며, 컨테이너 개발 경험이 풍부한 저자의 노하우와 현업 사례를 담았기에 초보자부터 중급자까지 모두에게 유용하다.

1. 컨테이너와 도커 기초

도커란?
컨테이너를 사용하는 이유

5. 쿠버네티스 입문

쿠버네티스란?
쿠버네티스 개요
쿠버네티스 클러스터와 노드
네임스페이스

1. 컨테이너와 도커 기초

도커란?

컨테이너 가상화를 지원하는 대표 컨테이너 기술
애플리케이션 배포에 특화되어 있으며 컨테이너를 중심으로 개발 및 운영이 가능

도커의 소프트웨어 구성

도커 서버: 컨테이너형 기술 구현을 위한 기본 애플리케이션으로 컨테이너 실행 및 관리 등 핵심을 담당
도커 REST API: 도커 서버를 조작하기 위한 인터페이스
도커 CLI: 도커 커맨드를 구현하는 애플리케이션으로 도커 REST API와 통신하며 도커 서버를 조작함

1. 컨테이너와 도커 기초

컨테이너를 사용하는 이유

불변하는 애플리케이션과 실행 환경에 대한 재현성 확보
애플리케이션 구성 관리의 용이성
환경과 상관없이 실행 가능한 높은 이식성
컨테이너 기반 개발의 필요성

불변하는 애플리케이션과 실행 환경에 대한 재현성

B 서버에도 같은 애플리케이션을 배포했는데 A와 다르게 동작해요

배포 서버의 상태가 달라 기대처럼 동작하지 않는 상황의 근본적인 원인은 가변적인 인프라를 허용해서 발생함
- OS, CPU, Memory, 라이브러리, 언어 런타임 등 다양한 요소에 의존함
- 각 서버에 배포하는 요소를 모두 하나로 통일하는 것이 해결 방법
IaC(Infrastructure as Code): 위 문제를 해결하기 위해 코드를 사용해서 인프라 환경을 구축하는 방법
- 어떤 서버를 구성할 지, 어떤 라이브러리나 애플리케이션을 사용할 지 코드로 정의하고 관리함
IaC를 사용해도 항상 같은 결과를 보장하는 것은 아님
- 예시: nvm install node
  - 이 경우 항상 최신 버전이 릴리스될 때마다 업데이트되기에 같은 결과 보장이 어려움
언제나 실행해도 동일한 환경 유지가 가능하도록 모든 애플리케이션 런타임과 라이브러리는 특정 버전을 설치하도록 코드를 작성

애플리케이션 구성 관리의 용이성

초기부터 도커는 도커 컴포즈라는 간단한 컨테이너 오케스트레이션 시스템을 제공함
yaml 형식의 설정 파일에 컨테이너 스펙을 정의하고 의존 관계 및 동작 순서를 제어해 컨테이너의 구성을 정의하고 실행
간편하다는 장점으로 인해 로컬 개발 환경 구성에 널리 사용됨

환경과 상관없이 실행 가능한 높은 이식성

컨테이너 기술은 운영 환경에서도 함께 사용되고 있으며 적은 오버헤드에 대해서도 쉽게 스케일 아웃이 가능하다는 장점이 존재
시스템 규모와 상관없이 컨테이너 활용이 점점 증가하는 추세
데이터 스토어와 같이 컨테이너를 사용하기에는 난이도가 높은 부분도 존재함
높은 이식성의 장점을 고려하면 컨테이너 기술은 개발 환경과 운영 환경 모두 도입해야 좋은 효과를 볼 수 있음

컨테이너 기반 개발의 필요성

도커와 컨테이너 오케스트레이션 툴의 보급, 매니지드 서비스가 제공되며 컨테이너 활용이 쉬워짐
MSA 아키텍처가 등장하며 컨테이너 기술을 이용한 소규모 애플리케이션을 만드는 방식이 인기를 얻고 있음
CI 가속화나 외부 API를 사용한 개발을 목(mock) 서버와 개발 환경을 컨테이너로 제공하는 경우가 많아짐

5. 쿠버네티스 입문

쿠버네티스란?

구글의 주도로 개발된 컨테이너 운영 자동화를 위한 컨테이너 오케스트레이션 시스템
컨테이너 오케스트레이션에 필요한 API, CLI 도구를 함께 제공
컨테이너 호스트 관리, 서버 리소스를 고려한 컨테이너 배치, 스케일링, 로드 밸런서, 상태 모니터링 등의 기능을 제공

도커의 번성과 쿠버네티스의 탄생

도커는 컨테이너 배치 전략, 스케일 인/아웃, 서비스 디스커버리, 운용의 용이성이 어렵다는 단점이 존재함
2014년 OSS로 공개된 쿠버네티스는 구글이 컨테이너를 운영하며 얻은 지식을 바탕으로 탄생
많은 기업과 커뮤니티의 컨트리뷰터를 보유한 프로덕트라는 점에서 쿠버네티스는 많은 지지를 받고 있음
다양한 클라우드 플랫폼에서 쿠버네티스를 지원하기 시작

5. 쿠버네티스 입문

쿠버네티스 개요

쿠버네티스 리소스는 애플리케이션 배포 구성을 위한 요소를 의미

쿠버네티스에서 다루는 리소스 목록

리소스	용도
노드 (Node)	쿠버네티스 클러스터에서 실행되는 컨테이너 배포 서버
네임스페이스 (Namespace)	쿠버네티스 클러스터 내부에서 생성하는 가상 클러스터
파드 (Pod)	컨테이너 집합체 단위로 컨테이너 실행 방법을 정의
레플리카셋 (ReplicaSet)	동일한 스펙의 여러 파드를 생성, 관리
디플로이먼트 (Deployment)	레플리카셋의 세대 관리
서비스 (Service)	파드 집합에 액세스하기 위한 경로 정의
인그레스 (Ingress)	서비스를 쿠버네티스 클러스터 외부로 공개
컨피그 맵 (ConfigMap)	설정 정보 정의, 파드에 공급
퍼시스턴트 볼륨 (PersistentVolume)	파드가 사용하는 스토리지의 크기와 유형을 정의
퍼시스턴트 볼륨 클레임 (PersistentVolumeClaim)	퍼시스턴트 볼륨을 동적으로 확보
스토리지 클래스 (StorageClass)	퍼시스턴트 볼륨이 확보한 스토리지 유형 정의
스테이트풀셋 (StatefulSet)	같은 스펙으로 고유성이 있는 여러 파드를 생성, 관리
데몬셋 (DaemonSet)	모든 Worker Node에서 단일 파드를 생성, 관리
잡 (Job)	상주 목적이 아닌 여러 파드를 생성하고 정상 종료 보장
크론 잡 (CronJob)	cron 기법으로 스케줄링하여 실행되는 잡
시크릿 (Secret)	인증 정보 등 보안 데이터 정의
롤 (Role)	네임스페이스 내부에서 조작할 수 있는 쿠버네티스 리소스 규칙 정의
롤 바인딩 (RoleBinding)	Role과 쿠버네티스 리소스 사용 유저 연결
클러스터 롤 (ClusterRole)	Cluster 전체에서 조작할 수 있는 쿠버네티스 리소스 규칙 정의
클러스터 롤 바인딩 (ClusterRoleBinding)	ClusterRole과 쿠버네티스 리소스 사용 유저 연결
서비스 어카운트 (ServiceAccount)	파드가 쿠버네티스 리소스를 조작할 때의 계정

5. 쿠버네티스 입문

쿠버네티스 클러스터와 노드

쿠버네티스 클러스터(cluster) 란 쿠버네티스의 다양한 리소스를 관리하는 집합 그룹을 의미
클러스터에서 가장 큰 단위는 노드(Node) 이며 노드는 클러스터에서 등록된 컨테이너의 호스트로 컨테이너 배포에 사용됨
클러스터에는 전체를 관리하는 서버인 컨트롤 플레인이 적어도 하나 이상 배치됨
클러스터 구성은 다음과 같이 두 그룹으로 구성됨
- 컨트롤 플레인 노드
- 워커 노드
쿠버네티스는 노드의 리소스 상태와 배치 전략에 따라 컨테이너를 적절하게 배치하는 기능이 존재
kubectl get nodes 명령어를 통해 클러스터에서 사용하는 노드의 리스트를 확인 가능

컨트롤 플레인을 구성하는 관리 컴포넌트

컴포넌트명	역할
kube-apiserver	쿠버네티스의 API를 공개하는 컴포넌트로 `kubectl` 명령어로 리소스를 조작함
etcd	높은 가용성의 분산 key-value 스토어로 클러스터의 백업 스토어로 사용
kube-scheduler	노드를 모니터링하고 컨테이너를 배치할 최적의 노드를 선택
kube-controller-manager	리소스를 제어하는컨트롤러 실행

클라우드 기반 쿠버네티스에서 노드는 GCP의 GCE, AWS의 EC2 인스턴스 등으로 구성
온프레미스 환경에서는 컨트롤 플레인이 단일 장애 지점이 되지 않도록 다중 컨트롤 플레인으로 3대 이상 배치하는 것을 권장

참고 자료

클러스터 아키텍처 | Kubernetes

5. 쿠버네티스 입문

네임스페이스

클러스터 안에 삽입할 수 있는 가상의 클러스터
클러스터 생성 시 다음의 기본 네임스페이스가 생성됨
- defualt: 기본적으로 생성되는 네임스페이스로 별도의 네임스페이스를 생성하지 않고 새 클러스터를 사용할 수 있음
- kube-node-lease: 각 노드의 연관된 리스 오브젝트를 갖고 있으며 kubelet이 헬스 체크를 통해
  컨트롤 플레인이 노드의 장애를 탐지하는데 사용
- kube-public: 모든 클라이언트(인증되지 않은 클라이언트 포함) 가 읽기 권한으로 접근 가능
- kube-system: 쿠버네티스 시스템에서 생성한 오브젝트를 위한 네임스페이스
네임스페이스별로 조작 권한을 설정할 수 있음
kubectl get namespace 명령어를 통해 네임스페이스 조회

여러 개의 네임스페이스를 사용하는 경우

네임스페이스는 여러 개의 팀이나 프로젝트에 걸친 사용자가 많은 환경에 사용하도록 개발됨
사용자가 거의 없거나 수 십명 정도의 유저가 사용하는 환경에서는 네임스페이스가 필요하지 않음
각 쿠버네티스 리소스는 하나의 네임스페이스만 존재
동일한 네임스페이스 내에서 리소스를 구별하려면 레이블을 사용
프로덕션 레벨의 클러스터에서는 default 네임스페이스 사용을 지양할 것

참고 자료

네임스페이스 | Kubernetes