As I've always been

알다시피, 운영체제는 더 많은 프로세스들이 메모리를 더 안정적으로 사용할 수 있도록 하기 위해 덜 사용되는 데이터를 메모리에서 디스크로 옮기는 스왑(swap)을 지원한다. 이를 통해 서버는 더 안정적으로 메모리를 관리할 수 있게 되는 것이다. 그런데, 쿠버네티스의 경우 기본 정책 상 swap을 비활성화시키도록 정책이 설정되어 있다. 물론 23년 8월 경에 알파 릴리스의 형태로 swap이 활성화된 형태로 파드를 생성할 수 있게 하는 설정이 추가되긴 했으나 아직은 프로덕션 환경에서 사용하기에는 시기상조로 보인다. 쿠버네티스에서 스왑 비활성화를 더 선호하는 이유는 "보안"이 가장 큰 이유로 볼 수 있다. 별도의 네임스페이스를 만들어서 마운트시킨 쿠버네티스 환경에서 굳이 격리된 데이터를 디스크로 스왑하는 작업은..

쿠버네티스의 파드는 여러 개의 컨테이너를 가질 수 있다. 이 중, "init containers"라고 불리는 컨테이너들이 있는데, 이 컨테이너들은 파드의 초기화를 담당한다. 파드가 생성되고 시스템적 격리가 이루어지는 초기단계에 수행되어야 할 작업들을 명시하기 위해 사용된다. Init container들이 모두 정상적으로 끝나야 초기화가 완료되고 main container 들이 실행되게 된다. 만약 init container가 실패 상태로 종료되고 restart 정책이 Never로 설정되어있다면 파드 자체의 초기화 실패로 단정하고 파드의 상태를 Failed로 바꾸게 된다. 또한, init container가 어떠한 이유로 인해 종료되지 않거나 restart 정책이 꼬여서 무한 재시작을 하고 있는 상태라면 ..

쿠버네티스 공부를 로컬호스트 상에 Kubernetes 클러스터 구축을 위해 가장 많이 사용되는 방식은 아마 도커와 minikube를 사용하는 방법일 것이다. 이 minikube를 사용한 클러스터의 경우 가장 큰 단점으로는 NodePort나 LoadBalancer와 같은 서비스에 대해서 external IP가 제대로 할당되지 않아서 서비스를 만들어도 외부 클러스터에서 접근이 잘 안되는 문제일 것이다. 이 문제를 처음 접하는 사람들은 "혹시 서비스가 제대로 만들어지지 않았나?"나 "kube-proxy"에 뭔가 문제가 있나?" 등의 삽질을 많이 하게 될 것이다. 실제로 필자 역시 처음 minikube를 사용해서 쿠버네티스 공부를 할 때에는 문제를 제대로 파악하지 못해서 몇시간동안 삽질을 했던 적이 있다. 서비..

마이크로서비스 아키텍처나 Auto-Scaling, 그리고 컨테이너 기술이 발전하면서 컨테이너 배포 패턴 자체도 다양한 방법론들이 나오게 되었다. 1. 사이드카 패턴 (Sidecar pattern) 다양한 기능을 추가 및 강화하기 위해 Pod 내에 추가적인 컨테이너를 추가하는 기법 2. 앰버서더 패턴 (Ambassador pattern) 사이드카 패턴의 세부 패턴 메인 컨테이너의 프록시 역할을 해주는 서브 컨테이너를 추가하는 패턴 nginx 등을 통해 프록시를 옆에 두는 패턴부터 REST API와 gRPC 사이의 컨버터 역할을 해주는 컨테이너 등 다양한 기법 존재 3. 어댑터 패턴 (Adaptor pattern) 사이드카 패턴의 세부 패턴 메인 컨테이너의 output 값이나 형태를 변형하는 컨테이너를 추가..

도커는 리눅스 커널이 기본으로 제공하는 기본 cgroup 기술을 이용해 애플리케이션이 좀 더 적은 리소스를 사용하게 할 수 있다. 쿠버네티스도 이러한 기능을 활용해 각 파드에서 사용하는 리소스의 양을 제한할 수 있다. 메모리 리소스 제한 컨테이너 내에서 애플리케이션을 실행할 경우 얻을 수 있는 주요 이점 중 하나는 바로 리소스 사용률을 제한할 수 있다는 것이다. 따라서 여러 애플리케이션이 동일한 하드웨어에 공존할 수 있으며 공정한 사용을 보장해준다. 200MB의 메모리와 1GB의 스왑 공간으로 제한하려면 docker run 명령어와 함께 --memory 및 --memory-swap 플래그를 사용할 수 있다. docker run -d --name mycontainer --publish 8080:8080 \..

이미지 크기 최적화 대용량의 컨테이너 이미지를 사용하기 시작하면 몇 가지 문제에 직면하게 된다. 가장 먼저 기억해야 할 사항은 시스템의 하위 계층에서 제거된 파일이 실제 이미지에서 존재한다는 점이다. 다음 상황을 고려해보자. - A 계층 (이름이 BigFile인 대용량 파일 포함) - B 계층 (이름이 BigFile인 대용량 파일 제거) - C 계층 (B 계층을 기반으로 정적 바이너리 제거) 위와 같은 상황에서는 BigFile이 더 이상 컨테이너 이미지 내에 존재하지 않는다고 생각할 것이다. 결과적으로 이미지를 실행할 경우, 해당 파일에는 더 이상 접근이 불가능하다. 그러나 실제로는 A 계층에 여전히 위치하고 있다. 즉, 더 이상 접근이 불가능한 파일임에도 전체 컨테이너 이미지의 크기에는 영향을 미치는 ..

컨테이너 이미지는 컨테이너 기술을 다루는 거의 모든 사람이 처음 접하게 되는 기술이다. 컨테이너 이미지는 OS 컨테이너 내부에서 프로그램을 실행하는데 필요한 모든 파일을 캡슐화하는 바이너리 패키지다. 컨테이너를 처음 접하는 방식에 따라 로컬 파일 시스템에서 컨테이너 이미지를 빌드하거나 이미 구축돼 있는 컨테이너 레지스트리(container registry)로부터 이미지를 다운로드하기도 한다. 두 경우 모두 컴퓨터에 컨테이너 이미지가 있으면 해당 이미지를 실행해 OS 컨테이너 내부에서 실행되는 애플리케이션을 생성할 수 있다. 가장 유명하고 널리 사용되는 컨테이너 이미지 포맷을 도커 이미지 포맷이며, 이를 사용할 경우 도커 명령으로 컨테이너를 패키징, 배포, 실행할 수 있다. 도커 이미지 포맷은 도커 오픈소..

Docker로 처음 작업을 하다보면 불필요한 이미지들을 다운받거나 도커 이미지를 잘못 굽는 등의 이슈가 자주 발생하게 된다. 이러한 이미지들이 쌓이다보면 어느 순간 이미지 리스트가 사용하지 않는 이미지들로 가득차게 된다. 이러한 경우에 쉽게 불필요한 도커 이미지들을 지우는 기능으로 prune이 있다. # 사용 중이지 않은 모든 도커 이미지 삭제 $ docker image prune 추가로, prune을 사용해서 exit된 모든 컨테이너들을 지울 수도 있고, 이미지와 컨테이너 모두를 정리할 수도 있다. # 종료된 모든 컨테이너 삭제 docker container prune # 종료된 모든 컨테이너들과 사용되지 않고 있는 이미지들 삭제 docker system prune 마지막으로, 도커 엔진 내의 모든 이..

Ubuntu 도커 이미지 상에서 혹은 EC2 ubuntu나 ECS 등에서 opencv-python를 설치한 뒤 cv2를 import하려고 할 때 다음과 같은 에러 메세지를 마주할 수 있다. ImportError: libGL.so.1: cannot open shared object file: No such file or directory 이러한 에러가 나는 가장 큰 이유는 cv2의 dependency 라이브러리 파일들 중 일부가 설치가 안 되어 있어서 생기는 에러이다. 보통 우분투를 로컬 머신에 설치하면 거의 일어나지 않는 경우이나, Docker 이미지나 EC2 프리티어 버전 등에서는 이러한 에러가 잘 발생한다. 우선, 일반적으로 가장 잘 알려진 해결법으로는 "libgl1-mesa-glx" 패키지를 설치하..

docker attach attach는 실행되고 있는 컨테이너에 접속하는 명령어이다. 사용법은 다음과 같다. docker attach 간단하게 말하자면, attach를 사용하게 되면 로컬 머신의 stdin, stdout, stderr 스트림들이 해당 컨테이너와 연결되게 된다. 즉, 표준 입출력을 연결시켜서 컨테이너 내부의 제어가 가능하도록 해주는 기능이라고 할 수 있다. attach로 컨테이너를 접속한다면 처음 도커 컨테이너를 run하였을 때의 환경이 포그라운드로 보여지게 된다. 따라서, 만약 도커 컨테이너를 run할 시 /bin/bash로 들어간 것이 아니라면 attach를 활용해서는 들어갈 수 없다. 참고로 container의 pid 1은 리눅스에 의해 특별하게 관리되고 있어서 기본 액션 시그널을 무..