SSE(Server-Sent Events)란 무엇인가 SSE는 Server-Sent Events의 약자로, 서버가 클라이언트로 실시간 데이터를 단방향으로 푸시(push)할 수 있게 해주는 웹 기술임 클라이언트가 먼저 요청을 보내고 서버는 그 연결을 끊지 않은 채, 새로운 데이터가 생길 때마다 지속적으로 응답을 보내는 방식임 주로 실시간 알림, 주식 시세 업데이트, 라이브 피드 등 서버에서 클라이언트로 일방적인 데이터 전송이 필요한 경우에 매우 유용함 SSE vs 웹소켓, 그리고 한계 SSE는 실시간 이벤트 전송에 유용하지만 만능은 아님. 웹소켓과 비교했을 때 명확한 장단점이 존재함 ...
개요 Kubernetes에서 Taints는 노드에 거는 출입 제한 설정이고 Tolerations는 파드가 가진 출입 허용 키에 해당함 이 조합으로 스케줄러가 특정 파드를 특정 노드에서 배제하거나 허용하도록 제어 가능 비용이 높은 노드 보호, 장애 노드 격리, 점검 중 노드 비우기 같은 운영 시나리오에서 효과적임 비유로 이해하기 노드가 VIP 라운지, Taint는 라운지 입구의 안내 표지, 파드는 손님, Toleration은 출입증에 해당함 Taint가 있는 노드에는 아무 파드나 배치되지 않음 해당 Taint를 허용하는 Toleration을 가진 파드만 스케줄링 가능 ...
개요 쿠버네티스는 명령을 조율하는 Control Plane과 실제 워크로드가 실행되는 Data Plane으로 구성됨 각 컴포넌트의 역할과 흐름을 이해하면 트러블슈팅, 성능 최적화, 보안 구성에 필요한 기준이 생김 클라우드 매니지드 쿠버네티스의 경우 Control Plane은 보통 제공자가 관리하지만 동작 원리 이해는 필수 Control Plane API Server 클러스터 유일 진입점 모든 컴포넌트와 사용자는 API Server를 통해 통신 인증과 권한 확인 수행 etcd 클러스터 상태와 스펙을 보관하는 분산 키밸류 저장소 API Server만 직접 접근 가능 상태 복구의 근간이 되는 데이터 원장 Scheduler ...
개념과 배경 마이크로서비스로 분산이 심화되면 로깅, 모니터링, 보안, 네트워킹 같은 공통 기능을 어디에 둘지 결정이 어려워짐 애플리케이션 코드에 공통 기능을 계속 끼워 넣으면 침투와 중복 증가, 배포와 버전 관리 복잡도 상승 사이드카 패턴은 공통 기능을 별도 컨테이너로 분리해 메인 서비스는 비즈니스 로직에 집중하게 하는 접근법 컨테이너 오케스트레이션 환경에서 일관된 운영 모델을 제공한다는 점이 실무적 장점 핵심 개념 사이드카 패턴의 구성 요소 메인 컨테이너: 비즈니스 로직 담당, 웹 서비스나 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는 의존성 준비 여부를 반영하는 형태 권장 ...
개요 쿠버네티스에서 컨트롤러는 제어 루프를 통해 원하는 상태와 현재 상태를 맞추는 두뇌 역할 수행 사용자가 선언한 스펙을 지속 관찰하고 차이를 줄이기 위해 리소스를 생성·수정·삭제하는 자동화 구성 요소 이 문서는 주요 컨트롤러를 실무 맥락과 비유를 곁들여 정리하며, 디버깅 관점에서의 관계와 주의점을 함께 정리 워크로드 컨트롤러 Deployment 역할: 상태 비저장 앱의 표준 배포 단위, 버전 관리와 롤링 업데이트 담당 특기: 롤링 업데이트로 무중단에 가까운 배포, 이슈 시 손쉬운 롤백 관계: 파드 직접 관리 대신 ReplicaSet을 통해 간접 관리 ReplicaSet ...
컨트롤 플레인은 쿠버네티스 클러스터의 두뇌이자 의사결정 계층으로, 워커 노드가 실제 워크로드를 돌리는 동안 전체 상태를 정의하고 조율하는 역할을 맡음 조직 비유로 보면 컨트롤 플레인은 본사와 경영진, 워커 노드는 지점과 현장 직원에 해당함 개념과 정의 컨트롤 플레인은 Desired State를 선언적으로 저장하고, Observed State와 비교해 일치하도록 끊임없이 조정하는 계층 사용자는 API를 통해 상태를 선언하고, 컨트롤 플레인은 스케줄링과 컨트롤 루프로 이를 만족하도록 시스템을 수렴시킴 핵심 구성요소 API 서버 kube-apiserver — 모든 요청의 진입점, 인증·인가·어드미션 수행 후 상태 변경을 etcd에 반영 ...
개요 쿠버네티스는 제어 평면과 워커 노드, 그리고 그 사이를 매개하는 런타임과 커널 메커니즘이 맞물려 동작하는 분산 시스템 핵심은 단일 진실 소스에 원하는 상태를 기록하고, 이를 지속적으로 감시하고 조정해 실제 상태를 일치시키는 루프 각 컴포넌트의 역할과 상호작용을 이해하면 장애 대응, 스케일링, 성능 튜닝의 기준점 확보 가능 구성요소 관계 한눈에 kubectl / CI │ ▼ kube-apiserver ──> etcd │ ▲ │ └(상태 영속) │ ├─ kube-scheduler(어디 배치할지 결정) └─ kube-controller-manager(원하는 상태로 맞춤: ReplicaSet 등) [각 워커 노드] kubelet ──(CRI gRPC)──> container runtime ──(OCI)──> runc/crun ──> cgroup 설정 + 컨테이너 시작 │ │ ├─(CNI 호출) 네트워크/IP 할당 └─ 네임스페이스/마운트 등 격리 └─ kube-proxy(서비스 라우팅: iptables/ipvs) 모든 컴포넌트의 권위자이자 입구는 apiserver etcd와 직접 통신하는 주체는 apiserver만 존재 kubelet은 apiserver를 watch하여 자신에게 배정된 파드 감지 container runtime은 OCI 런타임을 통해 cgroup과 네임스페이스를 세팅하고 컨테이너 프로세스 실행 Pod 생성에서 Running까지 사용자가 kubectl apply 등으로 Desired State를 제출하면 apiserver가 인증과 유효성, 어드미션을 거쳐 etcd에 영속화 controller-manager가 오브젝트를 관찰하고 필요한 부수 리소스를 생성, 예 ReplicaSet과 Pod 등 scheduler가 Pending 파드에 대해 노드 배치를 결정, 리소스 요청, 어피니티, 토폴로지, taint와 tolerance 등을 고려해 Pod에 NodeName 바인딩 대상 노드의 kubelet이 apiserver watch로 자신에게 할당된 파드 탐지 kubelet이 이미지 풀, 볼륨 마운트, 네트워크 준비를 순차 수행, CNI 플러그인을 호출해 인터페이스와 IP 할당 kubelet이 CRI를 통해 container runtime에 파드와 컨테이너 생성 요청 전달 runtime이 OCI 런타임 runc 또는 crun을 호출하여 cgroup 생성과 리눅스 네임스페이스 PID NET MNT UTS IPC 설정 후 엔트리포인트 실행 kubelet이 liveness readiness 스타트업 프로브로 상태를 확인하고 apiserver로 주기 보고 kube-proxy가 Service와 Endpoints 변경을 반영해 iptables 혹은 ipvs 규칙 갱신, 서비스 트래픽 라우팅 경로 성립 클러스터 DNS와 Service IP를 통해 파드로 트래픽 전달 완료 cgroup과 리소스 제한 연결 PodSpec의 resources.requests와 limits가 kubelet을 거쳐 runtime에 전달되고, runtime과 OCI가 cgroup v1 또는 v2에 실제 quota와 limit 설정 CPU는 shares와 quota를 통해 스케줄러 가중치와 시간 쿼터 부여 메모리는 hard limit과 OOM killer 점수 조정으로 커널 레벨 강제 쿠버네티스 리소스 제한의 실체는 cgroup 설정이라는 점이 핵심 장애·스케일·자체 복구 흐름 컨테이너 크래시 발생 시 kubelet이 상태를 보고하고 컨트롤러가 Desired 수를 보장하기 위해 재시작 또는 재스케줄 수행 노드가 NotReady로 전환되면 스케줄러와 컨트롤러가 파드를 다른 노드로 이동시키는 복구 경로 선택 HPA VPA 클러스터 오토스케일러 등으로 Desired State를 조정하면 동일한 조율 루프로 반영되어 자원과 파드 수가 확장 또는 축소 용어 핵심 정리 control plane apiserver 권위와 입구, scheduler 배치, controller-manager 조율, etcd 단일 진실 저장소 worker node 파드를 실제로 실행하는 머신 풀 kubelet 각 노드의 현장 에이전트, 파드 라이프사이클 관리와 apiserver 동기화 담당 container runtime kubelet 지시로 컨테이너 생성과 삭제를 수행하는 실행기, CRI 인터페이스 준수 cgroup 컨테이너 자원 격리와 제한의 커널 메커니즘, OCI 런타임이 설정 마무리 apiserver는 진실의 관문, etcd는 진실의 저장소, 스케줄러와 컨트롤러는 계획과 조율, kubelet은 현장 실행, runtime과 OCI는 컨테이너 생성, cgroup은 자원 격리 담당 ...