As I've always been

DNS란?DNS는 Domain Name System의 약자이다. DNS는 사람이 쉽게 해석할 수 있는 도메인명(ex, www.bluewhale.com)을 IP 주소(179.10.2.10)로 변환하는 기능을 의미한다. DNS는 /etc/hosts 파일에 저장된 도메인-IP 맵핑 정보를 읽거나, 이를 갖고 있는 네임 서버와의 통신을 통해 이루어진다.DNS in LinuxLinux 환경에서 DNS를 사용하는 방법은 크게 2가지가 있다./etc/hosts/etc/hosts 파일은 컴퓨터가 도메인명으로 IP를 찾을 때 가장 먼저 열어보는 파일이다. 윈도우에서는 C:\Windows\System32\drivers\etc\hosts 경로에 파일이 위치한다.파일을 열어보면 아래와 같이 localhost가 이미 추가되어 ..

쿠버네티스 클러스터에 20개의 파드 복제본이 있는 StatefulSet이 있다고 가정해 보자.파드의 컨테이너에 사용되는 이미지가 상당히 큰 경우, 워커 노드에서 이미지를 가져오는 데 시간이 걸린다.따라서 StatefulSet의 모든 파드가 하나씩 실행되는 데 많은 시간이 걸립니다. 다른 시나리오에서는 워커 노드 중 하나가 비정상 상태가 되어 그 노드에서 실행 중인 파드가 퇴거되었다고 가정해 보자.따라서 다른 노드에서 파드가 다시 스케줄되지만, 인터넷을 통해 컨테이너 레지스트리에서 이미지를 다시 가져와야 하므로 중단 시간이 길어지게 된다. 이 때 Spegel이 도움이 된다.Spegel은 상태 비저장 클러스터 로컬 OCI 레지스트리 미러이다.Spegel은 쿠버네티스 클러스터의 각 노드가 로컬 레지스트리 미러..

알다시피, 운영체제는 더 많은 프로세스들이 메모리를 더 안정적으로 사용할 수 있도록 하기 위해 덜 사용되는 데이터를 메모리에서 디스크로 옮기는 스왑(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 마지막으로, 도커 엔진 내의 모든 이..