본문 바로가기

분류 전체보기333

Kubernetes - Liveness probe - 출처: Kubernetes in action - 파드 유지 쿠버네티스의 최대 장점은 컨테이너 목록을 제공하면 관리자가 신경쓰지 않아도 클러스터 어딘가에서 계속 실행되고 있다고 믿을 수 있다는것이다. 파드가 워커 노드에 스케줄링되면 노드의 kubelet은 컨테이너를 실행한다. 이때 주 프로세스에 crash가 발생하면 kubelet은 컨테이너를 재시작한다. 하지만 문제는 앱이 쓸 수 없게 되는 상황에서 언제나 crash가 발생하지는 않는다는것이다. 예를 들어 자바 앱에서 메무리 누수가 일어나는 경우 OOM이 일어날지언정 JVM 프로세스는 계속 실행된다. 이럴 경우 OOM 익셉션을 잡아서 재시작하면 되겠지만 이런식으로 모든 경우의 수를 대비할수는 없다. 그러므로 앱 내부 기능이 아닌 외부에서 앱의 상태를 .. 2022. 10. 10.
Kubernetes - Namespace - 출처: Kubernetes in action - 출처: https://github.com/ahmetb/kubectx - 네임스페이스 앞에서 배운 레이블을 통해 리소스를 그룹화할 수 있었다. 레이블은 하나의 오브젝트에 여러 개를 할당할 수 있으므로 오브젝트 그룹이 서로 겹칠 수 있다. 만약 레이블이 어떤 구조로 되어있는지 모르는 사용자가 kubectl을 통해 처음 리소스를 조회할 때 셀렉터를 지정하지 않고 조회하면 모든 오브젝트를 봐야 한다. 쿠버네티스는 한번에 하나의 그룹에서만 작업할 수 있도록 오브젝트를 그룹화해주는 네임스페이스 개념을 제공한다. 네임스페이스를 사용하면 많은 구성요소를 가진 복잡한 시스템을 더 작은 개별그룹으로 분리할 수 있다. 리소스를 개발, QA 같은 환경으로 나누거나 원하는 방.. 2022. 10. 9.
Kubernetes - Label 및 Annotation - 출처: kubernetes in action - 레이블 파드 예제에서는 2개 정도밖에 생성해보지 않았지만 실제 환경에서는 서비스 규모에 따라 컴포넌트가 수십개 이상이 될수도 있다. 여기에 개발, 운영과 같은 환경까지 고려하면 배수만큼 늘어나므로 파드들을 관리하기가 쉽지 않다. 레이블은 개발자나 시스템 관리자가 파드를 쉽게 그룹화할 수 있도록 해준다. 레이블을 활용하면 파드에 대한 작업을 수행할 때 개별적으로 하지 않고 한꺼번에 할 수 있다. 파드를 기반으로 설명했지만 레이블은 다른 쿠버네티스 리소스에도 적용할 수 있다. 리소스에 키/값 형태를 추가하고 레이블 셀렉터를 통해 리소스 선택시 활용한다. 실제로 레이블을 활용하는 예로는 앱이나 배포 환경에 대한 레이블을 붙이는것이다. app에는 파드가 속한 .. 2022. 10. 9.
Kubernetes - Pod - 출처: Kubernetes in action - 파드 파드는 하나 이상의 컨테이너 그룹이다. 쿠버네티스는 컨테이너를 개별적으로 배포하지 않으며 컨테이너 그룹인 파드를 배포 및 운영한다. 파드에 속한 컨테이너 그룹은 하나의 워커 노드에 배포된다. 즉 파드 내의 컨테이너들은 각각 다른 워커 노드에 배포되지 않는다. 단순히 기술적인 관점에서는 여러 프로세스를 하나의 컨테이너에서 실행시킬 수 있다. 하지만 이 방법은 권고되지 않는다. 컨테이너는 단일 프로세스를 실행할 목적으로 설계되었다. (자식 프로세스를 생성하는 경우는 예외) 만약 단일 컨테이너에서 여러 프로세스를 실행하면 아래와 같은 문제가있다. 여러 프로세스가 로그를 동일 표준 출력에 기록하면 관리하기가 난해하다. 프로세스별로 재시작하는 매커니즘을 원.. 2022. 10. 9.
Kubernetes - deploy app tutorial - 출처: Kubernetes in action - 출처: https://kubernetes.io/docs/concepts/overview/components/ - 출처: https://preiner.medium.com/kubernetes%EC%9D%98-%EC%9D%B4%ED%95%B4-%EA%B0%9C%EB%85%90%EC%A0%95%EB%A6%AC-17245a0d5f4d - 앱 실행 일반적으로 쿠버네티스에 앱을 배포할때는 구성 요소를 기술한 JSON이나 YAML 매니페스트를 준비해야 하지만 첫번째 앱 배포 예제이므로 간단한 방법으로 배포해본다. 책에서는 "kubectl run" 명령어를 통해 레플리케이션 컨트롤러를 생성하여 파드 생성을 제어한다. 그러기 위해 명령어 옵션에 "--generator=r.. 2022. 10. 6.
Kubernetes - cluster 생성 - 출처: kubernetes in action - 출처: https://kubernetes.io/docs/concepts/overview/components/ - Kubernetes cluster 설치 이전까지 살펴본 Docker 학습은 쿠버네티스 클러스터에 배포하기 위한 준비 과정이라고 볼 수 있다. 이제 본격적으로 쿠버네티스 클러스터를 설치하여 배포해보자. 회사내에서 사용하는 규모 정도되면 다중 노드 쿠버네티스 클러스터 설치해야 하는데 이는 단순한 작업이 아니다. 쿠버네티스 지식뿐만 아니라 리눅스와 네트워크에 관한 상당한 지식도 요구하기 때문이다. 클라우드 공급자를 통해 설치하는 대신 학습 목적을 위해 단일 노드 클러스터인 minikue를 이용한다. kubeadm 으로도 설치할 수 있지만 쿠버네티스.. 2022. 10. 6.
Kubernetes - Docker basic - 출처: Kubernetes in action - Docker를 사용한 컨테이너 이미지 생성 간단한 Node.js 앱을 만들어서 컨테이너 이미지로 패키징해보자. 앱의 기능은 http 요청을 받아 해당 호스트머신의 이름을 응답하는 것이다. 위의 코드는 8080으로 http 서버를 시작하고 모든 요청에 대해 200을 상태코드와 함께 hostname 정보를 응답한다. 위의 앱을 이미지로 패키징하려면 우선 Dockerfile을 생성해야 한다. Dockerfile은 이미지를 생성하기 위해 수행해야할 사항들을 기술한 파일이라고볼 수 있다. FROM node:7 ADD app.js /app.js ENTRYPOINT ['node', 'app.js'] app.js와 동일한 path에 위의 내용으로 Dockerfile을.. 2022. 10. 6.
Kubernetes - 개요 - 출처: Kubernetes in action - 모놀리스 to 마이크로서비스 과거에는 대부분의 시스템들이 모놀리스 형태였다. 하지만 점차 시스템들이 대형화되면서 모놀리스 시스템의 단점이 드러났다. 모놀리스 시스템은 해당 구성요소들이 너무 강하게 결합되어있기 때문에 시스템 구성요소의 일부분만 변경해도 전체 배포 과정을 거쳐야 한다. 또한 만약 시스템의 사용자가 많아지면 확장해야하기 마련인데 수직 형태의 증설(Scale up)은 CPU나 RAM을 2배로 올린다고 성능이 선형적으로 정확히 2배로 증가하지 않기 때문에 한계가 존재한다. 그래서 수평 형태의 확장(Scale out) 을 보통 선택하는데 어플리케이션 코드가 크게 변경되어야 하는 경우도 있어서 이 역시 쉽지 않다. 이를 극복하기 위해 나온 개념이 .. 2022. 10. 2.
DDD - Inteface - 출처: 도메인 주도 설계 - 에릭 에반스 - Intention Revealing Interface (의도를 드러내는 인터페이스) Interface는 Client 개발자가 객체를 효과적으로 사용하기 위해 알아야할 정보를 추상화하고 있다. 그래서 Interface가 제대로 작성되어 있지 않으면 Client 개발자는 사용하려고 하는 개체에 대한 세부사항을 아주 세밀하게 알고 있어야 한다. Client 개발자의 머릿속이 이런 구현 세부사항들로 넘처나게 되면 해결해야 할 비즈니스 문제를 집중해서 해결할 수 없다. 객체의 캡슐화 가치가 떨어지게되는것이다. 클래스나 연산이름을 지을때에는 수행 방법이 아닌 결과와 목적만을 표현해야 한다. TDD 를 잠깐이라도 접해본적이 있다면 구현하지도 객체에 대해 Test cod.. 2022. 10. 1.
DDD - Specification - 출처: 도메인 주도 설계 - 에릭 에반스 - Specification 간단한 규칙을 검사하는 코드를 작성할때 Boolean을 반환하는 anInvoice.isOverdue() 와 같은 형태로 작성하는 경우가 많다. 규칙이 단순하다면 이정도로 충분하지만 어플리케이션의 규칙이 항상 간단한것만은 아니다. 송장(Invoice)의 지불유예기간에 대한 정책은 고객의 계정상태나 제품군에 따라 달라질 수 있다. 이런 규칙들이 늘어나다보면 송장이라는 모델은 송장 자체를 표현하기 보다 송장에 대한 규칙만 늘어놓는 코드로 전락하고 송장의 본질적인 특성이 무엇인지 파악할 수 없게 된다. 다시말해서 원래 모델링했던 Entity, VO 책임에 맞지 않은 규칙의 다양성과 조합이 본질적인 모델의 의미를 압도하게 된다. 이런 규칙들.. 2022. 9. 25.

티스토리툴바