용민 빈 주입 용민 빈 주입

클러스터 내에서 원하는 수의 Pod를 유지하여 고가용성, 부하 분산, 스케일 조정 등을 지원하는 역할을 하는 것으로 Replication Controller와 ReplicaSet가 존재합니다(Replication Controller는 구 기술로 ReplicaSet이 권장되고 있다). 이들은 항상 지정된 수의 Pod가 실행되도록 보장합니다. 장애가 발생하면 자동으로 새로운 Pod를 생성하여 서비스의 고가용성을 유지합니다. 그리고 Pod의 상태를 모니터링하여, 원하는 수와 실제 실행 중인 Pod 수가 일치하도록 조정합니다. 이제 이 두 리소스 간의 차이에 대해 살펴보겠습니다. Replication Controller오직 equality 기반의 레이블 선택만 지원하여, 좀 더 복잡한 조건의 Pod 선택이 어렵..

Pod은 쿠버네티스에서 애플리케이션을 실행하는 가장 기본적인 단위로, 하나 이상의 컨테이너들이 하나의 논리적 단위로 묶여 함께 실행됩니다. 각 Pod는 컨테이너들 간에 네트워크, 스토리지(볼륨) 등의 리소스를 공유하며, 애플리케이션의 배포, 관리, 확장을 용이하게 만듭니다. Pod의 기본 개념컨테이너 집합Pod은 하나 이상의 컨테이너를 포함합니다. 이 컨테이너들은 같은 네임스페이스를 공유하여 내부 통신이 자유롭고, 동일한 IP 주소와 포트 네임스페이스를 사용합니다. 네트워크 및 스토리지 공유Pod 내의 모든 컨테이너는 같은 네트워크 인터페이스를 사용하며, 공유 볼륨을 통해 데이터를 저장하거나 로그, 설정 파일 등을 공유할 수 있습니다. 스케일링과 클러스터 확장트래픽이 증가하면, 쿠버네티스는 우선적으로 하..

Kubelet은 Kubernetes 클러스터의 각 워커 노드에서 실행되는 핵심 에이전트입니다. Kube-API Server가 특정 워커 노드에 실행해야 할 파드의 스펙을 전달하면, 해당 노드의 kubelet은 이 요청을 받아 실제 컨테이너 런타임과 상호작용하여 파드의 생성, 실행 및 관리를 담당합니다.  주요 역할 및 기능은 다음과 같습니다. 통신 및 명령 수신API 서버와의 상호작용: kubelet은 지속적으로 kube-apiserver와 통신하면서 자신의 노드 상태와 실행 중인 파드의 상태를 보고합니다.명령 전달: kube-apiserver가 적절한 워커 노드를 결정하면, 해당 노드의 kubelet에게 파드 실행에 관한 스펙이 전달됩니다. 파드 생성 및 실행컨테이너 관리: 전달받은 파드 스펙을 바탕으..

Kube Scheduler는 Kubernetes 클러스터 내에서 파드가 실행될 노드를 결정하는 핵심 컴포넌트입니다. 이 스케줄러는 파드를 어떤 노드에 배치할지 결정하기 위해 크게 두 단계를 거칩니다. Filter Nodes (노드 선별)우선 클러스터에 존재하는 모든 노드 중에서 파드를 실행할 수 없는 노드를 먼저 걸러냅니다. 주요 과정은 다음과 같습니다. 자원 요구 사항: 파드가 요청하는 CPU, 메모리 등의 리소스를 해당 노드가 충분히 제공할 수 있는지 확인합니다.Taints와 Tolerations: 노드에 설정된 Taints를 파드가 허용하는지 확인하여, 파드가 특정 노드에 배치되는 것을 방지하는 정책이 적용되어 있으면 그 노드를 제외합니다.기타 정책: 네트워크, 스토리지 접근성, 지역 등 클러스터의..

쿠버네티스의 Kube Controller Manager는 클러스터 내부의 여러 컨트롤러들을 하나의 프로세스 내에서 실행시키는 핵심 컴포넌트입니다. 이 컴포넌트는 클러스터의 현재 상태를 지속적으로 감시하고, 원하는 상태와 실제 상태 간에 차이가 발생할 경우 이를 바로잡기 위한 복구 조치를 수행합니다. 내부적으로는 kube-apiserver와 긴밀하게 상호작용하여 클러스터 상태를 업데이트하거나 요청을 처리합니다. 아래에서 Controller의 종류 중 Node Controller와 Replication Controller에 대해 자세히 설명하겠습니다.  Node ControllerNode Controller는 클러스터에 존재하는 각 노드의 상태를 감시하는 역할을 담당합니다. 노드 상태 감시: 노드에서 주기적..

쿠버네티스의 kube-apiserver는 클러스터의 “중앙 제어 지점” 역할을 하며, 모든 클러스터 요청을 받아 처리하는 프론트엔드입니다. 아래는 kubectl 명령어로 pod 정보를 조회하거나 생성할 때 kube-apiserver가 수행하는 과정을 자세히 설명한 내용입니다.  Pod 정보 조회 (kubectl get pod)요청 수신 및 사용자 인증사용자가 kubectl 명령어로 pod 정보를 요청하면, 이 요청은 먼저 kube-apiserver에 도달합니다.kube-apiserver는 요청에 포함된 인증 정보를 확인하여 사용자가 유효한 권한을 가지고 있는지 검증합니다.요청 검증요청의 형식, 필수 파라미터 등이 올바른지 확인한 후, 진행 가능한 요청인지 판단합니다.etcd에서 데이터 조회요청이 인증되고..

etcd는 분산 키-값 저장소로, Kubernetes 클러스터의 “진실의 단일 출처(source of truth)” 역할을 수행합니다. etcd는 Kubernetes에서 클러스터 상태와 구성 정보를 저장하는 중앙 저장소 역할을 합니다. 클러스터 상태 저장etcd는 클러스터의 모든 구성 정보, 상태 데이터, 메타데이터를 저장합니다. 예를 들어, API 서버가 클러스터 리소스(파드, 서비스, 구성맵 등)의 상태를 읽고 쓰는 데 etcd를 사용합니다. 고가용성과 일관성분산 환경에서 안정적인 데이터 저장을 보장하기 위해, etcd는 강력한 일관성을 제공합니다. 이는 클러스터의 여러 노드 간의 동기화와 장애 복구에 매우 중요한 역할을 합니다. Kubernetes API 서버와의 연동API 서버는 etcd를 백엔드..

쿠버네티스에서 컨테이너 런타임과의 통합 방식은 시간이 지나면서 변화해 왔습니다. 이를 위해 Docker와 containerd의 연관성을 아래와 같이 간단히 정리할 수 있습니다.DockerDocker는 컨테이너 이미지 생성, 배포, 실행 등 포괄적인 기능을 제공하는 컨테이너 플랫폼dockershim초기에 쿠버네티스는 Docker를 직접 CRI(Container Runtime Interface)에 맞게 연결하기 위해 dockershim이라는 중간 계층을 사용초기에는 Docker API와 쿠버네티스 간의 인터페이스 역할을 수행하지만 유지 보수 및 표준화 측면에서 한계가 있었고, 이후 쿠버네티스에서 점차 deprecation(사용 중단)되어 1.24 버전부터는 제거containerdcontainerd는 Dock..