Search

[스터디] Docker & Kubernetes Study #3

다루는 내용

POD 의 생성, 실행, 정지
POD 과 다른 리소스를 레이블로 조직화하기
특정 레이블을 가진 모든 파드에서 작업 수행
네임스페이스를 사용해 POD를 겹치지 않는 그룹으로 나누기
특정한 형식을 갖은 워커 노드에서 POD 배치

3.1 Pod 소개

POD 은 컨테이너의 그룹 = 쿠퍼네티스의 기본 빌딩 블럭 = 1개 이상의 컨테이너로 구성됨
컨테이너를 개별적으로 배포하기 보단는 컨테이너를 가진 POD 을 배포 및 운영함
핵심: 여러 컨테이너를 갖고 있을 경우에 POD 은 하나의 워커 노드에서 실행됨
POD이 필요한 이유
Q. 여러 프로세스를 실행하는 단일 컨테이너보다 다중 컨테이너가 나은 이유
컨테이너는 단일 프로세스를 실행하는 것을 목적으로 설계되었다
개별 프로세스가 실패하는 경우 자동으로 재시작하는 매커니즘을 구현해야 함
표준출력으로 출력된 로그가 어떤 프로세스의 로그인지 알기 어렵다
POD 이해하기
POD 그룹안에 있는 컨테이너들끼리 특정 리소스를 공유하기 위해 서로가 완전 격리되면 안됨
POD 내에서는 각 컨테이너끼리 namespace 를 공유하도록 도커를 설정
POD 내에서는 동일한 네트워크 네임스페이스와 UTS 네임스페이스(호스트 네임 공유) 안에서 실행됨
다만 파일 시스템에 한해서는 공유되지 않는다 = 컨테이너 이미지에서 파일시스템이 나오기 때문
POD 간 네트워크 통신
각 POD 별로 IP를 갖기 때문에, 서로 네트워크 상으로 통신을 주고받으면 된다.
POD 에서 컨테이너의 적절한 구성
모든 것을 POD 하나에 넣는 대신에 애플리케이션을 여러 POD으로 구성하고
각 POD 에서는 밀접하게 관련이 있는 구성 요소나 프로세스만을 포함해야 한다
웹서버와 DB가 정말로 같은 머신에서 실행되어야 하는가? → 아니요
워커가 여러개인 환경에서, 프론트엔드와 백엔드를 같은 파드에 둔다면 효율성이 떨어진다.
개별 확장 가능성: 백엔드 애플리케이션이 더 많은 컴퓨팅 리소스를 필요로 한다면 굳이 필요하지 않은 프론트까지 킬 필요가 없음
POD 에서 여러 컨테이너를 사용하는 경우
어플리케이션이 하나의 주요 프로세스와 하나 이상의 보완 프로세스로 구성된 경우
예) 특정 디렉토리에서 파일을 제공하는 웹서버 / 외부 소스에서 주기적으로 파일을 저장하는 컨테이너
두개의 컨테이너를 하나의 POD 에 넣을 지, 두개의 POD 에 분리할지 결정할 때는 다음과 같은 질문 필요
Q. 컨테이너를 함께 실행해야 하는가? 혹은 서로 다른 호스트에서 실행할 수 있는가?
Q. 여러 컨테이너가 모여 하나의 구성요소를 나타내는가? 혹은 개별적인 구성 요소인가?
Q. 컨테이너가 함께, 혹은 개별적으로 스케일링 되어야 하는가?

3.2 이후에는 실습

...

질문

Q. Stateful 한 어플리케이션 (예: DB)의 경우에는 어떻게 scale-out 을 할 수 있지?
답변: DB를 Scale-out하려면 데이터가 분산되어야 한다는 뜻이어서, 쿼리 제약이 강하게 작용하는 NoSQL 계열의 DB가 아니면 Scale out이 어려워요. DB의 Master-slave 구조를 검색해보시면 도움이 될 듯 합니다.
Q. Sidecar process 에 대한 보다 구체적인 예시 (같은 POD 안에 있어야 하는 프로세스의 예시)
답변: 제일 많이 쓰이는 패턴은 애플리케이션 서버 + 로그 수집기 조합이에요. 애플리케이션 서버가 로그를 떨구면, 로그 수집기가 네트워크 트래픽을 모니터링하면서 Bandwidth가 넉넉할 때 조금씩 중앙 로그 서버로 보내주는 것을 예로 들 수 있을 것 같아요. 이 예시에 대해 더 궁금하다면, fluentd 혹은 Logstash를 검색해보세요!