출항사

도커나 도커 스웜 모드를 사용할 때에는 컨테이너를 논리적으로 구분하는 방법이 없었다. 그래서 용도에 따라 컨테이너와 그에 관련된 리소스들을 구분 지어 관리할 수 있는 일종의 논리적인 그룹이 있으면 좀 더 편할 것이다. 쿠버네티스에서는 리소스를 논리적으로 구분하기 위해 네임스페이스(Namespace)라는 오브젝트를 제공한다. 간단히 생각해 네임스페이스는 파드, 레플리카셋, 디플로이먼트, 서비스 등과 같은 쿠버네티스 리소스들이 묶여 있는 하나의 가상 공간 또는 그룹이라고 생각하면 된다. 예를들어 모니터링을 위한 모든 리소스들을 monitoring이라는 이름의 네임스페이스에서 생성할 수 있고, 테스트를 위한 리소스들은 testbed라는 네임스페이스에서 생성할 수 있다. 또는 여러 개발 조직이 하나의 쿠버네티스..

이전까지 쿠버네티스에서 컨테이너를 구성하는 가장 중요한 요소인 파드, 레플리카셋, 그리고 디플로이먼트에 대해서 알아봤다. 그러나 디플로이먼트를 통해 생성된 파드에 어떻게 접근할 수 있을지에 대해서는 아직 알아보지 않았다. 이전에는 kubectl describe 명령어로 파드의 내부 IP를 직접 확인한 뒤 파드로 직접 접근할 수는 있었지만, 이 방법은 로컬 개발 환경 또는 쿠버네티스 클러스터 내부에서만 사용할 수 있었다. 게다가 도커 컨테이너와 마찬가지로 파드의 IP는 영속적이지 않아 항상 변할 수 있다는 점도 유의해야 한다. 여러 개의 디플로이먼트를 하나의 완벽한 애플리케이션으로 연동하려면 파드 IP가 아닌, 서로를 발견(Discovery)할 수 있는 다른 방법이 필요하다. 도커 컨테이너는 -p 옵션으로..

디플로이먼트 사용하기 레플리카셋만 사용해도 충분히 Micro Service 구조의 컨테이너를 구성할 수 있을 것 같지만, 실제 쿠버네티스 운영 환경에서 레플리카셋을 YAML 파일에서 사용하는 경우는 거의 없다. 대부분은 레플리카셋과 파드의 정보를 정의하는 '디플로이먼트(Deployment)'라는 이름의 오브젝트를 YAML 파일에 정의해 사용한다. 디플로이먼트는 레플리카셋의 상위 오브젝트이기 때문에 디플로이먼트를 생성하면 해당 디플로이먼트에 대응하는 레플리카셋도 함께 생성된다. 따라서 디플로이먼트를 사용하면 파드와 레플리카셋을 직접 생성할 필요가 없다. 간단한 예시를 통해 디플로이먼트를 직접 생성해 보자. apiVersion: apps/v1 kind: Deployment metadata: name: my-..

레플리카셋을 사용하는 이유 쿠버네티스의 기본 단위인 파드는 여러 개의 컨테이너를 추상화해 하나의 애플리케이션으로 동작하도록 만드는 컨테이너 묶음이다. 그러나 YAML에 파드를 생성하게 되면 이 파드의 생성 주기는 어떻게 될까? YAML로 생성한 파드는 아래와 같은 두 가지 방법으로 삭제할 수 있다. kubectl delete -f nginx-pod-with-ubuntu.yaml kubectl delete pods my-nginx-pod 만약 kubectl delete 명령어로 파드를 삭제하면 파드의 컨테이너 또한 삭제된 뒤 쿠버네티스에서 영원히 사라지게 된다. 이처럼 YAML 파일에 파드만 정의해 생성할 경우 해당 파드는 오직 쿠버네티스 사용자에 의해 관리된다. 단순히 파드의 기능을 테스트하는 등의 간단..

쿠버네티스를 도커 스웜 모드와 비교해 봤을 때, 쿠버네티스만이 가지는 고유한 특징이 있다. 모든 리소스는 오브젝트 형태로 관리된다. 쿠버네티스는 대부분의 리소스를 '오브젝트'라고 불리는 형태로 관리한다. 그리고 이 오브젝트라는 용어는 흔히 알고 있는 추상화된 집합에서 크게 벗어나지 않는 개념이다. 도커 스웜을 사용할 때, 컨테이너의 묶음을 표현하기 위해 '서비스(service)'라는 것을 사용했었다. 스웜 모드의 서비스도 컨테이너 리소스의 집합을 정의한 것이기 때문에 일종의 오브젝트라고 볼 수 있다. 그러나 쿠버네티스는 이러한 개념을 더욱 폭넓고 세밀한 단위로 사용한다. 예를 들어 쿠버네티스에서는 컨테이너의 집합(Pods), 컨테이너의 집합을 관리하는 컨트롤러(Replica Set), 사용자(Servic..

스웜 모드는 롤링 업데이트를 자체적으로 지원하며, 매우 간단하게 사용할 수 있다. 롤링 업데이트를 테스트하기 위한 서비스를 먼저 생성해 보자. 컨테이너 생성에 사용될 이미지는 nginx 1.10으로 설정했다. docker service create --name myweb2 \ --replicas 3 \ nginx:1.10 docker service update 명령어를 사용하면 생성된 서비스의 각종 설정을 변경할 수 있는데, 이미지를 업데이트하려면 update 명령어의 --image 옵션을 설정하면 된다. 아래의 명령어는 위에서 생성한 myweb2 서비스의 이미지를 nginx:1.11로 업데이트하는 명령어이다. docker service update \ --image nginx:1.11 \ myweb2 ..

스웜 모드 서비스 개념 Docker Swarm 모드를 사용하지 않고, 사용하는 도커 명령어의 제어 단위는 컨테이너이다. 예를 들어 docker run 명령어는 컨테이너를 생성하고, docker rm 명령어는 컨테이너를 삭제한다. 그러나 스웜 모드에서 제어하는 단위는 컨테이너가 아닌 '서비스(Service)'이다. 서비스는 같은 이미지에서 생성된 컨테이너의 집합이며, 서비스를 제어하면 해당 서비스 내의 컨테이너에 같은 명령이 수행된다. 서비스 내에 컨테이너는 1개 이상 존재할 수 있으며, 컨테이너들은 각 워커 노드 혹은 매니저 노드에 할당된다. 이렇게 서비스 내의 컨테이너를 '태스크(Task)'라고 부르기도 한다. 예를들어, ubuntu 이미지로 서비스를 생성하고 컨테이너의 수를 3개로 설정했다고 가정해 ..

Docker Swarm을 사용하는 이유 일반적인 도커 사용법은 대부분 하나의 호스트를 기준으로 한다. 예를 들어 docker ps 명령어는 하나의 도커 엔진에 존재하는 컨테이너의 목록을 출력하며 create, run 명령어 또한 하나의 도커 엔진에 컨테이너를 생성한다. 그러나 실제 도커를 서비스 환경에 적용한다면 문제가 생길 수 있다. 만약 하나의 호스트 머신에서 도커 엔진을 구동하다가 CPU나 메모리, 디스크 용량과 같은 자원이 부족하면 어떻게 해결할까? 가장 간단한 해결 방법은 '성능이 좋은 서버를 새로 구매'하는 방법일 것이다. 하지만, 자원의 확장성 측면이나 비용 측면에서도 이는 좋은 해답이 아니다. 자원이 부족할 때마다 성능이 좋은 서버를 구매할 수 없을 뿐만 아니라 높은 가격의 서버를 사고 유..