모래성 말고 철옹성

Kube-Scheduler란?Kube-Controller-Manager는 Kubernetes 클러스터의 상태를 원하는 목표 상태(Desired State)로 유지하도록 관리하는 핵심 컴포넌트이다. 쉽게 말해, “쿠버네티스의 자동화 관리자(Controller 집합체)”라고 할 수 있다. Kube-Scheduler의 주요 역할과 기능ReplicaSet Controller지정된 수의 Pod가 항상 실행되도록 보장Node Controller노드의 상태(정상/비정상) 모니터링 및 조치Endpoint ControllerService와 Pod를 연결 (네트워크 엔드포인트 관리)Service Account & Token ControllerPod가 API Server와 안전하게 통신 가능하도록 인증자격 발급이런 다양한 ..

Kube-Scheduler란?Kube-Scheduler는 Kubernetes에서 Pod가 어떤 노드(Node)에 배치될지 결정하는 스케줄러 컴포넌트이다.kubectl 명령을 실행하거나, 외부 어플리케이션이 API 요청을 보낼 때, 그 요청들은 가장 먼저 Kube-API Server를 통과하게 된다. Pod는 스스로 실행 위치를 알 수 없기 때문에, 클러스터 내 리소스 상태를 확인하고 가장 적절한 노드에 할당하는 역할을 한다. Kube-Scheduler의 주요 기능스케줄링 후보 탐색실행 가능한 노드 필터링자원 조건 확인CPU, Memory 등 하드웨어 리소스 자원 고려정책 기반 선택NodeSelector, Node Affinity, Taints & Tolerantions 지원우선순위 부여적합한 노드 점수화..

Kube-API Server란?Kube-API Server는 Kubernetes 클러스터의 Gateway로서, 모든 명령과 요청이 반드시 지나가는 핵심 컴포넌트이다.kubectl 명령을 실행하거나, 외부 어플리케이션이 API 요청을 보낼 때, 그 요청들은 가장 먼저 Kube-API Server를 통과하게 된다.Kube-API Server의 주요 핵심기능REST API 제공Kubernetes와 통신할 수 있는 표준 HTTP API 제공인증/인가 처리사용자나 서비스 계정의 권한 검증etcd 연동클러스터 상태 정보 저장, 조회요청 검증과 변환잘못된 요청 거부, 필요한 데이터 구조 변환다른 컴포넌트들과 중재Controller, Scheduler등과 상태 동기화Kubernetes에서의 위치사용자 ↔ Kube-AP..

etcd란? 분산 환경에서 데이터를 안정적으로 저장하는 강한 일관성(Strong Consistency) 기반의 키-값 저장소이다.주요 특징으로는리더 선출 자동 처리 - 네트워크 분할 상황에서도 안정적으로 리더 선출고가용성 - 리더 노드 장 시 데이터와 서비스 지속 가능분산 시스템 필수 구성요소 - k8s같은 클러스터 환경에서 핵심 메타데이터 저장소로 사용etcd 주요 기능간단한 인터페이스curl 같은 HTTP 도구로 값 읽기/쓰기 가능key-value 저장표준 파일 시스템처럼 계층적 디렉토리 구조 지원변경 감지특정 키, 디렉터리 변경 시 감지하고 반응보안 기능선택적 SSL 클라이언트 인증서 지원고성능인스턴스당 초당 수천 건의 쓰기 처리 가능TTL 지원특정 키에 만료 시간 부여 가능분산 합의Raft 프로토..

쿠버네티스 아키텍처 톺아보기쿠버네티스(Kubernetes)는 컨테이너 오케스트레이션을 위한 플랫폼이다. 컨트롤 플레인(Control Plane), 워커 노드(Worker Node), 애드온(Add-ons) 이렇게 세 가지 부분으로 나누어 알아보자. 🏗 컨트롤 플레인 (Control Plane)쿠버네티스 클러스터의 두뇌 역할. API 서버: 쿠버네티스의 모든 요청을 처리하는 중심 허브컨트롤러 매니저: 클러스터 상태를 원하는 상태로 유지스케줄러: 워커 노드에 적절한 파드를 배치etcd: 클러스터의 상태 정보를 저장하는 키-값 저장소🏭 워커 노드 (Worker Node)컨테이너가 실제로 실행되는 곳 Kubelet: 컨트롤 플레인의 명령을 받아 컨테이너를 관리Kube Proxy: 네트워크 통신을 담당컨테이너..

Service의 역할쿠버네티스에서 Service는 파드(Pod)들이 안정적으로 네트워크를 통해 통신할 수 있도록 도와주는 리소스다. 각 파드는 고유한 IP를 가지지만, 동적으로 변경될 수 있기 때문에 직접 접근하는 것이 어렵다. 이를 해결하기 위해 Service가 존재하며, 특정 네트워크 정책을 설정하여 안정적인 접근을 가능하게 한다.네트워크 추상화: 파드가 변경되더라도 동일한 네트워크 주소를 통해 접근할 수 있도록 한다.로드 밸런싱: 여러 개의 파드로 트래픽을 분산시켜 부하를 조절한다.디스커버리: DNS와 연동하여 내부 또는 외부 서비스 탐색이 용이하도록 지원한다.쿠버네티스에서 Service를 생성할 때, spec.type 필드를 통해 동작 방식을 정의할 수 있다. 주요한 세 가지 유형은 다음과 같다...

1분 쿠버네티스QoS (Quality of Service)쿠버네티스에서 QoS는 파드(Pod)의 리소스 우선순위를 결정하는 역할을 한다. 노드에 리소스가 부족할 때 우선순위가 낮은 파드가 먼저 종료되므로, 서비스 안정성을 위해 QoS 설정이 중요하다.QoS 클래스BestEffort: 리소스 request/limit 없음 → 가장 먼저 종료됨Burstable: request보다 더 많이 사용할 수 있음 → 중간 우선순위Guaranteed: request=limit → 가장 높은 우선순위샘플apiVersion: v1kind: Podmetadata: name: qos-examplespec: containers: - name: guaranteed-container image: nginx reso..

1분 쿠버네티스Pod의 ReadinessProbe와 LivenessProbeReadinessProbe컨테이너가 트래픽을 받을 준비가 되었는지를 결정새로 Pod가 구동일 될 때 컨테이너 내부의 App(ex. tomcat)이 준비(Ready)되었는지 확인LivenessProbe컨테이너를 언제 재시작해야 하는지 결정Pod는 Running 상태이더라도 App(ex. tomcat)이 장애 상황이 있을 수 있는데, 이 상황에 App을 지속적으로 확인하여 Pod를 재기동공통설정 내용은 HttpGet, exec, TÇPSocket으로 공통된 속성으로 해당 App에 대한 상태체크readiness sample code (tcpSocket)apiVersion: v1kind: Podmetadata: name: goproxy..