쿠버네티스의 다양한 리소스들에 대해서 다뤄보면 ETCD라는 중요한 요소에 대해서 알 수 있다. ETCD는 키-값으로 데이터를 저장하는 스토리지로 쿠버네티스에서 모든 상태 정보(메타데이터)를 영구적으로 저장하는 역할을 한다. 마스터 노드에 있는 kube-apiserver는 이 ETCD를 참고하여 클러스터 전체의 최신 상태를 일관성 있게 유지하는 역할을 한다. 간단하게 쿠버네티스의 마스터 노드의 컴포넌트에 대한 그림을 그려보면 위와 같다. 여기서 ETCD에 접근할 수 있는 쿠버네티스의 컴포넌트는 kube-apiserver 뿐으로써 etcd는 쿠버네티스 클러스터에 있어 심장과도 같은 중요한 존재이다. 쿠버네티스는 이런 심장과도 같은 etcd를 어떻게 오케스트레이션하는 것인가? 간단하게 스포일러를 하면 etc..
쿠버네티스를 공부하다 보면 아마 처음으로 접하게 되는 것 트래픽 관련 리소스가 Service라고 하는 것일텐데, 이는 우리가 생각하는 대로 특정한 Pod에 대하여 IP를 뚫어주어 전략(ClusterIP, NodePort, LoadBalancer)에 따라서 직접 접근할 수 있게 된다. 그다음으로는 Ingress라는 리소스도 있는데, 이 또한 Port를 이용하여 IP 계층에서 직접 트래픽을 조작해 준다. 대체 어떠한 차이점이 있을까? 쿠버네티스에 대해서 단순하게 이해하고 있을 때에는 Ingress는 프론트엔드 페이지 보여줄 때, Service는 그 외라고 알고 있었지만, 좀 더 공부해 보면 사실 굉장히 이야기할 거리가 많은 주제이고 복잡하기도 했다. 재미있는 사실은 결국에는 Ingress는 웹을 보여줄 때,..
쿠버네티스 클러스터를 통해 다양한 시도를 하기 전 직접 로컬에서 테스트해 볼 수 있는 환경이 있어야 한다. 그 과정에서 사람들이 가장 많이 찾는 툴은 minikube라고 하는 툴이다. minikube는 로컬 쿠버네티스 클러스터를 생성하고 관리하기 위한 경량화된 도구로, 로컬에서 쿠버네티스 애플리케이션을 개발, 테스트 학습할 수 있도록 설계되어 있다. 이번 포스팅에서는 미니쿠베의 세팅 방법과 함께, 꿀같은 터미널 세팅에 대해서 다뤄보려고 한다. 이 외에도 vscode 세팅이나 lens 등 로컬에서 직접 쿠버네티스를 테스트하기 좋은 환경을 구축하기 위한 내용들을 포스팅한다. 먼저, 준비물들이 꽤나 있는데 다음과 같다. 이 포스팅의 내용은 macOS에 특화되어 있다. homebrewdockeroh-my-zs..
최근에 쿠버네티스 자격증을 공부하고 있는데, CMD와 ENTRYPOINT의 차이점에 대한 내용이 나왔다. 강의를 듣다 보니까 세상에, 이런 사실을 자세히 모르고 있었다니... 대충 ENTRYPOINT를 사용할 때에는 런타임에 주입하는 경우라고만 알고 있었는데, 자세히 알고 보니까 생각보다 중요한 내용이었다. 그리고 생각해 보니 예전에 재미있는 일이 있었다. 한 2년 전쯤의 일이다. node.js 프로그램을 docker container로 띄우기 위해서 아래와 같이 CMD를 입력했는데 안 됐다.CMD ["tsc", "main.ts", "&&", "node", "main.js"] ts를 통해서 타입스크립트를 빌드하고, 빌드된 js를 실행하는 명령어를 CMD로 나타냈는 데, 안 되는 것이다. 도저히 안되어 n..
매일 시간 날 때마다 geeknews를 보는 편이다. 이런저런 글들 중에서 가장 관심 있는 글을 발견하였는데 그것은 바로 도커의 멀티 스테이지 빌드에 대해서 쓰인 글이었다.[geeknews] Docker multi-stage build로 컨테이너 이미지 크기 줄이기 : https://news.hada.io/topic?id=17794 Docker Multi-Stage Build로 컨테이너 이미지 크기 줄이기 | GeekNewsDocker 컨테이너 이미지를 빌드할 때, Dockerfile이 Multi-Stage 구조가 아니라면 불필요한 파일이 포함될 가능성이 큼이는 이미지 크기 증가 및 보안 취약성 증가로 이어짐컨테이너 이미지에서 발생할news.hada.io 해당 게시글을 보고 바로 링크된 원문을 확인하여 ..
클라우드 기반이 아무래도 편하다 보니까 AWS를 통해서 다양한 서비스들을 직접 띄우면서 작업하는 도중이었으나, 최근에 일과 개인적인 공모전 관련해서 AWS를 쓰기 힘든 상황이다 보니까 온프레미즈를 통해서 배포하기 시작했다. 아무래도 AWS를 쓰는 편이 편하기는 하지만, 비용적인 측면을 고려할 수밖에 없었고, 학교에서 일하게 되면서 서버 리소스들이 꽤나 많기 때문에 대부분 Jenkins를 기반으로 서빙하기 시작했다. 빌드의 꽃은 역시 매개 변수를 넣어주는 것이라고 생각한다. 도커 이미지를 만드는 과정에서도 다른 사람들의 스크립트를 보면서 저마다 도커 이미지를 빌드하는 방법이 다 다르다고 생각하였는데, 각각 다양한 이후의 확장성을 고려한 도커 파일을 작성하는 것이었다. 그렇기 때문에 이러한 젠킨스 빌드에서도..
먼저, 이전에 개인 프로젝트를 통한 AWS Serverless 배포 파이프라인을 구축하였다. 많은 요소들을 신경 써서 여러모로 구축하였고, 서버 비용도 예상할 수 있는 수준 이내로 끊으려고 했었다. 그런데 한 가지 문제가 발생하는데... 그것은 바로 배포가 무려 30분이나 걸린다는 사실이었다. 그 이유는 다음과 같았다. cpu 2 core, memory 4GB씩 물려 있던 ECS의 리소스를 비용 문제로 각각 절반식 줄여버린 것이다. 사실 생각해 보면 이미 예견된 문제였었다. AWS freetier에서 지원하는 ec2 t2.micro에서 스프링을 빌드해 본 적이 있다면 알 수 있을 것이다. 1 core와 1GB memory를 지원하는 t2.micro에서 gradlew build를 실행하면, 빌드 도중에 메..
들어가며평소에도 그렇고 일을 하면서도 그렇고, 프로젝트에서도 배포쪽으로 다양하게 서포트하는 쪽이라 nginx를 굉장히 많이 사용하는 편이다. 특히 학교에서 일하게 되면서 네트워크 정책이 전산을 관리하는 곳에서 통제하기 때문에 제한된 구조로 특정 포트밖에 이용할 수 없게 된다. 이 때 nginx를 극한으로 사용하는 방법에 대해서 알아보기 시작하였다. nginx를 리버스 프록시 및 로드 밸런싱과 같이 다양한 방법으로 사용하다가 Nginx Proxy Manager라는 것을 알게 되었다. 굉장히 신세계였는데, 매번 nginx.conf를 직접 설정하고 nginx -t로 문법 체크하고, reload하는 것과는 다르게, 손쉽게 SSL을 통한 https 접속 및 서브 도메인 로드 밸런싱을 지원하는 점이 좋았다. 더 말..
