Devops

개념과 배경 마이크로서비스로 분산이 심화되면 로깅, 모니터링, 보안, 네트워킹 같은 공통 기능을 어디에 둘지 결정이 어려워짐 애플리케이션 코드에 공통 기능을 계속 끼워 넣으면 침투와 중복 증가, 배포와 버전 관리 복잡도 상승 사이드카 패턴은 공통 기능을 별도 컨테이너로 분리해 메인 서비스는 비즈니스 로직에 집중하게 하는 접근법 컨테이너 오케스트레이션 환경에서 일관된 운영 모델을 제공한다는 점이 실무적 장점 핵심 개념 사이드카 패턴의 구성 요소 메인 컨테이너: 비즈니스 로직 담당, 웹 서비스나 API 서버 등 사이드카 컨테이너: 횡단 관심사 처리, 로그 수집, 모니터링 에이전트, 프록시, 보안 검사 등 같은 파드 내 배치로 네트워크 네임스페이스와 볼륨 공유 가능, 표준 출력/공유 볼륨 등을 통해 데이터 연계 업데이트와 배포를 컨테이너 단위로 분리해 독립적 버전 관리 가능 동작 원리 하나의 파드에 메인 컨테이너와 사이드카 컨테이너를 함께 배치 ...

개요 Kubernetes 환경에서 Liveness Probe와 Readiness Probe는 애플리케이션 상태를 주기적으로 점검해 자동 복구와 트래픽 차단을 수행하는 안전 장치 역할 수행 Node.js는 싱글 스레드 기반으로 이벤트 루프 차단이나 메모리 누수 상황이 치명적이라 두 프로브의 설계가 안정성에 직접적인 영향 미침 핵심 차이 Liveness Probe의 질문은 너 살아있니, 실패 시 컨테이너 재시작 수행 Readiness Probe의 질문은 일할 준비 됐니, 실패 시 서비스 엔드포인트에서 제외해 트래픽 차단 수행 본질적 차이는 실패 시 K8s가 취하는 액션이며 재시작과 트래픽 제어로 구분됨 Node.js 맥락 Liveness Probe 대상 상황 이벤트 루프 블로킹으로 요청 처리 불가 상태 무한 루프 또는 데드락과 유사한 좀비 상태로 PID는 있으나 응답 불능 메모리 누수로 OOM 임박하여 응답 지연 또는 멈춤에 가까운 상태 Readiness Probe 대상 상황 프로세스는 떠 있으나 초기화 작업 진행 중인 상태 DB 연결 수립 중, 대용량 설정 로딩, 캐시 워밍업 등으로 실제 서비스 처리 불가 상태 유의점 Liveness는 가벼운 체크로 한정, 외부 의존성까지 포함 시 불필요한 재시작 유발 위험 Readiness는 실제 트래픽 처리 가능 여부를 반영해야 하며 의존성 준비 상태를 포함하는 편이 안전함 구현 스니펫 Node.js에서 Liveness는 최소한의 핑 수준으로, Readiness는 의존성 준비 여부를 반영하는 형태 권장 ...

컨트롤 플레인은 쿠버네티스 클러스터의 두뇌이자 의사결정 계층으로, 워커 노드가 실제 워크로드를 돌리는 동안 전체 상태를 정의하고 조율하는 역할을 맡음 조직 비유로 보면 컨트롤 플레인은 본사와 경영진, 워커 노드는 지점과 현장 직원에 해당함 개념과 정의 컨트롤 플레인은 Desired State를 선언적으로 저장하고, Observed State와 비교해 일치하도록 끊임없이 조정하는 계층 사용자는 API를 통해 상태를 선언하고, 컨트롤 플레인은 스케줄링과 컨트롤 루프로 이를 만족하도록 시스템을 수렴시킴 핵심 구성요소 API 서버 kube-apiserver — 모든 요청의 진입점, 인증·인가·어드미션 수행 후 상태 변경을 etcd에 반영 ...