ingress 는 일반적으로 외부에서 내부로 향하는 것을 지칭한다.
쿠버네티스 인그레스는, 외부 요청을 어떻게 처리할 것인지 네트워크 7 계층 레벨에서 정의하는 오브젝트이다.

사용 이유

어플리케이션이 3 개의 디플로이먼트로 생성되어 있다고 하자.
디플로이먼트를 외부에 노출하려면 위 그림 처럼,
NodePort or LoadBalancer 타입의 서비스 3 개를 각각 디플로이먼트에 연결해주면 된다.
그런데, 이 방식은 서비스마다 세부적인 설정을 할 때 추가적인 복잡성이 발생한다.
예를 들면, 아래와 같은 내용을 구현하려면, 서비스와 디플로이먼트에 대해 일일이 설정해야한다.

1. SSL / TLS 보안 연결
2. 접근 도메인 및 클라이언트 상태에 기반한 라우팅

그래서 인그레스가 필요하다.
인그레스 오브젝트를 이용하면, URL 엔드포인트를 단 하나만 생성해서 이런 번거로움을 해결할 수 있다.

위 그림처럼, 3 개의 서비스에 대해 3 개 URL 이 각각 존재하는 것이 아니라
인그레스에 접근하기 위한 하나의 URL 만 존재한다.
핵심은, 라우팅 정의나 보안 연결 같은 세부 설정은 서비스와 디플로이먼트가 이니라 인그레스에 의해 수행

구조

ingress-example.yaml 파일을 작성하자.

효율적으로 애플리케이션을 관리하기 위해 사용되는
Namespace / ConfigMap / Secret 오브젝트를 정리한다.

Namespace

네임스페이스는 포드, 레플리카셋, 디플로이먼트, 서비스 등과 같은 쿠버네티스 리소드들이 묶여 있는
하나의 가상 공간 또는 그룹이다.
하지만, 네임스페이스의 리소스들은 논리적으로 구분된 것일 뿐, 물리적으로 격리된 것은 아니다.
즉, 서로 다른 네임스페이스에 생성된 포드가 같은 노드에 존재할 수 있다.

리눅스의 네임스페이스와는 완전히 다르다.
리눅스의 네임스페이스는, 리눅스 커널 자체 기능

Namespace 사용하기

아래와 같이 production-namespace.yaml 파일을 정의하자.

1
2
3
4

apiVersion: v1
kind: Namespace
metadata:
  name: production

그리고 네임스페이스를 생성하자.

1

kubectl apply -f production-namespace.yaml

특정 네임스페이스에 리소스를 생성하려면
hostname-deploy-svc-ns.yaml 파일에 아래와 같이 작성하고,

Pod / Replica Set / Service / Deployment 오브젝트를 정리한다.

쿠버네티스의 고유 특징

모든 리소스는 오브젝트 형태로 관리된다.

컨테이너의 집합 (Pods), 컨테이너의 집합을 관리하는 컨트롤러 (Replica Set), 사용자 (Service Account), 노드 (Node) … 등 하나의 오브젝트로 관리된다.
쿠버네티스에서 사용할 수 있는 오브젝트는 아래 명령어로 확인 가능하다.

명령어를 사용할 수 있지만, YAML 파일을 더 많이 사용한다.

kubectl 이라는 명령어로 쿠버네티스를 사용할 수 있지만,
YAML 파일로 컨테이너 뿐만 아니라 모든 리소스 오브젝트들에 사용될 수 있다.

여러 개의 컴포넌트로 구성되어 있다.

쿠버네티스 노드는 마스터 노드와 워커 노드로 나뉘어 있다.
마스터 노드는 클러스터를 관리하는 역할을 하고, 워커 노드에는 애플리케이션 컨테이너가 생성된다.
쿠버네티스는 도커를 포함한 많은 컴포넌트들이 도커 컨테이너로서 실행된다. 예를 들어,
마스터 노드에는 kube-apiserver, kube-controller-manager, kube-schueduler, coreDNS 등이 실행된다.

그리고, kubelet 이라는 에이전트가 모든 노드에 실행된다.
kubelet 은 컨테이너의 생성/삭제 뿐만 아니라 마스터와 워커 노드 간 통신 역할을 담당한다.

쿠버네티스 입장에서, 도커 데몬 또한 하나의 컴포넌트이다.
도머 스웜 모드는 도커에 내장된 기능인 반면, 쿠버네티스는 그렇지 않다.
오히려, 쿠버네티스가 도커를 이용하는 방식이다.

쿠버네티스 설치 환경의 종류

쿠버네티스는 사용 환경과 목적에 따라 설치하는 방법이 다양하다.

1. 개발 용도: Minikube, Docker for Mac/Windows 에 내장된 쿠버네티스
2. 서비스 테스트 or 운영 용도: kops, kubespray, kubeadm, EKS/GKE 의 Managed Service

개발 용도

개발 용도의 쿠버네티스는 로컬 노드를 standalone 모드로 사용해서, 쿠버네티스의 기능을 완벽하게 사용하기에는 어렵다.
여러 서버의 자원을 클러스터링해 컨테이너를 배치하는 것이 쿠버네티스의 핵심 기능인데, 한 개의 노드로는 이것을 확인해볼 수 없기 때문이다.

서비스 테스트 or 운영 용도

서비스 테스트 or 운영 용도라면, 어떠한 환경에서 쿠버네티스를 설치할 것인지를 결정해야한다.
쿠버네티스의 사용 환경은 크게 두 가지이다.

1. AWS, GKE 등의 클라우드 플랫폼 환경
2. 자체적으로 보유한 on-premise 서버 환경

클라우드 플랫폼 환경

클라우드 플랫폼에서 쿠버네티스를 사용한다면, 서버 인스턴스만을 사용해 쿠버네티스를 설치할지, 쿠버네티스 자체를 서비스로서 제공하는 managed service 를 사용할지 선택해야한다.

도커 컴포즈를 사용하는 이유

여러 개의 컨테이너로 구성된 웹 애플리케이션을 테스트하기 위해,
아래처럼 웹 서버 컨테이너와 데이터베이스 컨테이너를 각각 생성해야한다.

1
2
3
4
5

# docker run --name mysql -d jko/composetest:mysql mysqld

# docker run -d -p 80:80 \
--link mysql:db --name web \
jko/composetest:web apachectl -DFOREGROUND

여러 개의 컨테이너를 하나의 서비스로 정의해 컨테이너 묶음으로 관리하면 편리할 것이다.
Docker Compose 는, 컨테이너를 시용한 서비스의 개발과 CI 를 위해 여러 개의 컨테이너를 하나의 프로젝트로서 다룰 수 있는 작업 환경을 제공한다.
여러 컨테이너의 옵션과 환경을 정의한 파일을 읽어 컨테이너를 순차적으로 생성하는 방식으로 동작한다.

도커 컴포즈 사용

도커 컴포즈는 컨테이너의 설정이 정의된 YAML 파일을 읽어 도커 엔진을 통해 컨테이너를 생성한다.
그래서, YAML 파일을 아래처럼 작성해야한다.

1
2
3
4
5
6
7
8
9
10
11
12

version: '3.0'
services: # 생성될 컨테이너를 묶어놓은 단위
  web:
    image: jko/composetest:web
    ports:
      - "80:80"
    links:
      - mysql:db
    command: apachectl -DFOREGROUND
  mysql:
    image: jko/composetest:mysql
    command: mysqld

그리고 아래 명령어로, 컨테이너를 생성한다.

1

# docker-comose up -d

도커 컴포즈 구성 단위

도커 스웜을 사용하는 이유

하나의 호스트 머신에서 도커 엔진을 구동하다, CPU, 메모리, 디스크 용량과 같은 자원이 부족해질 수 있다.
이를 해결하기 위한 방법으로, 가장 많이 사용하는 방법이 여러 대의 서버를 클러스터로 만들어 자원을 병렬로 확장하는 것이다.

그러나, 여러 대의 서버를 하나의 자원 풀로 만드는 것은 쉽지 않다.
에를 들면,

• 새로운 서버나 컨테이너가 추가되었을 때 이를 발견 하는 작업 (Service Discovery)
• 어떤 서버에 컨테이너를 할당할 것인가에 대한 스케쥴러
• 클러스터 내의 서버가 다운 되었을 때 고가용성 보장

이러한 문제를 쉽게 해결할 수 있는 솔루션으로 도커에서 공식적으로 제공하는 Docker Swarm 과 Swarm Mode 를 사용할 수 있다.

스웜 클래식과 도커 스웜 모드

도커 스웜에는 두 가지 종류가 있다.

1. 스웜 크래식: 도커 버젼 1.6 이후부터 사용할 수 있는 컨테이너로서의 스웜
2. 스웜 모드: 도커 버젼 1.2 이후부터 사용할 수 있는 도크 스웜 모드

위 둘의 차이는, 목적이다.

1. 스웜 클래식: 여러 대의 도커 서버를 하나의 지점에서 사용하도록 단일 접근점을 제공한다.
2. 스웜 모드: 마이크로서비스 아키텍처의 컨테이너를 다루기 위한 클러스터링 기능에 초점을 둔다.

도커 이미지와 컨테이너

도커 엔진에서 사용하는 기본 단위와 핵심은 이미지와 컨테이너이다.

도커 이미지

이미지는 컨테이너를 생성할 때 필요한 요소이다. 가상 머신을 생성할 때 사용되는 iso 파일과 비슷하다.
이미지는 여러 개의 계층으로 된 바이너리 파일로 존재하고, 컨테이너를 생성하고 실행할 때 읽기 전용으로 사용된다.

이미지 이름은, 다음과 같은 형태로 구성된다 : [저장소 이름]/[이미지 이름]:[태그]
ex) jko/ubuntu:14.04

도커 컨테이너

이미지로 컨테이너를 생성하면, 이미지 목적에 맞는 파일이 들어 있는 파일 시스템과, 격리된 시스템 자원 및 네트워크를 사용할 수 있는 독립된 공간이 생성된다.

컨테이너는 이미지를 읽기 전용으로 사용하되 이미지에서 변경된 사항만 컨테이너 계층에 저장하기때문에, 컨테이너에 무엇을 하든지 원래 이미지는 영향을 받지 않는다.
또한, 컨테이너는 호스트와 분리되어있기 때문에, 어떤 애플리케이션을 설치하거나 삭제해도 다른 컨테이너와 호스트는 변화가 없다.

예를 들어,

Docker

Docker 는 리눅스 컨테이너에 여러 기능을 추가해서 애플리케이션을 컨테이너로서 조금 더 쉽게 사용할 수 있게 만들어진 오픈소스 프로젝트이다.

도커와 관련된 프로젝트에는,

• Docker Compose
• Private Registry
• Docker Hub
• Docker for Desktop
• …

일반적으로 도커라고 하면 Docker Engine 이라는 의미로 많이 쓰인다.
도커의 생태계에 있는 모든 프로젝트들은 도커 엔진을 더 효율적으로 사용하기 위한 것에 불과하기 때문이다.

가상 머신과 도커 컨테이너

가상 머신

기존의 가상화 기술은, 하이퍼바이저를 이용해 여러 운영체제 (= Guest OS) 를 하나의 호스트에서 생성해 사용하는 방식이었다.
각 Guest OS 는 다른 Guest OS 와 완전히 독립된 공간과 시스템 자원을 할당받아 사용한다.
이러한 가상화 방식을 사용할 수 있는 가상화 툴로는 VirtualBox, VMware 등이 있다.

시스템 자원을 가상화하고 독립된 공간 생성 작업은 항상 하이퍼바이저를 거치기 때문에 일반 호스트에 비해 성능 손실이 발생한다.
그리고, Guest OS 를 사용하기 위한 라이브러리, 커널 등을 전부 포함하여 가상 머신을 배포하기 위한 이미지를 만들었을 때 이미지의 크기가 크다.