근묵자흑

1. 포드의 자원 사용량 제한쿠버네티스 클러스터에서 안정적인 서비스를 제공하려면 각 파드가 사용하는 자원을 적절히 관리해야 합니다. 이는 노드의 자원이 고갈되는 것을 방지하고, 애플리케이션 간의 공정한 자원 분배를 보장합니다.1.1 컨테이너와 파드의 자원 사용량 제한: LimitsLimits는 컨테이너가 사용할 수 있는 최대 자원량을 정의합니다. CPU와 메모리에 대해 각각 설정할 수 있으며, 이를 초과하면 시스템이 개입합니다.apiVersion: v1kind: Podmetadata: name: resource-limited-podspec: containers: - name: app image: nginx resources: limits: memory: "256Mi"..

1. 쿠버네티스의 권한 인증 과정쿠버네티스의 모든 요청은 API 서버를 통해 처리되며, 다음과 같은 단계를 거칩니다:인증(Authentication): 사용자 또는 서비스가 누구인지 확인인가(Authorization): 인증된 사용자/서비스가 요청한 작업을 수행할 권한이 있는지 확인승인(Admission Control): 요청이 클러스터 정책에 부합하는지 확인쿠버네티스는 다양한 인증 메커니즘을 지원합니다:클라이언트 인증서(X.509)베어러 토큰(Bearer Token)서비스 어카운트 토큰OpenID Connect 토큰웹훅 토큰 인증인증이 완료되면 RBAC 시스템을 통해 인가 과정이 진행됩니다. 2. 서비스 어카운트와 롤, 클러스터 롤서비스 어카운트(ServiceAccount)서비스 어카운트는 파드 내에..

1. Persistent Volume (PV) - 스토리지라는 창고PV가 뭘까요?PV는 Kubernetes 클러스터에서 제공하는 '스토리지 창고'라고 생각하면 됩니다.일상생활에 비유하면:아파트 단지의 공용 보관함대여할 수 있는 창고빌릴 수 있는 저장 공간주요 특징:클러스터 리소스: 노드처럼 클러스터의 일부로 존재파드와 독립적: 컨테이너가 삭제되어도 데이터가 유지접근 모드: 누가 어떻게 접근할 수 있는지 정의apiVersion: v1kind: PersistentVolumemetadata: name: my-storagespec: capacity: storage: 5Gi accessModes: - ReadWriteOnce # 한 번에 한 노드만 읽기/쓰기 가능 persistentVolume..

Kubernetes를 사용하다 보면 영구 스토리지 관리는 핵심적인 부분입니다. 특히 PersistentVolume(PV)과 PersistentVolumeClaim(PVC)이 어떻게 바인딩되는지 그 내부 동작 방식을 이해하는 것은 효율적인 스토리지 관리에 매우 중요합니다. 이 블로그에서는 Pod가 생성될 때 PV와 PVC가 바인딩되는 전체 워크플로우를 심층적으로 분석하고, Kubernetes 소스 코드를 통해 내부 동작 원리를 알아보겠습니다.Kubernetes 스토리지 기본 개념Kubernetes에서 영구 스토리지를 관리하는 주요 객체들을 먼저 이해해 봅시다:PersistentVolume(PV): 관리자가 프로비저닝하거나 스토리지 클래스를 통해 동적으로 프로비저닝된 클러스터의 스토리지 조각입니다. PV는 ..

Kubernetes 아키텍처 개요컨트롤 플레인 컴포넌트 상세 분석워커 노드 컴포넌트 상세 분석Pod 생성 워크플로우 심층 분석Kubernetes 객체 관계선언적 상태 관리 워크플로우Ingress 워크플로우운영 고려사항Kubernetes 아키텍처 개요Kubernetes(쿠버네티스)는 컨테이너화된 애플리케이션의 배포, 스케일링, 관리를 자동화하는 오픈소스 플랫폼입니다. 전체 아키텍처는 크게 컨트롤 플레인과 워커 노드로 구성됩니다.GitHub 리포지토리: https://github.com/kubernetes/kubernetes컨트롤 플레인은 클러스터의 '두뇌' 역할을 하며, 워커 노드는 실제 애플리케이션 컨테이너가 실행되는 곳입니다. 이 두 요소는 함께 작동하여 컨테이너화된 애플리케이션의 효율적인 배포와 관리..

1. Nginx Ingress Controller의 등장 배경1.1 C10K 문제와 이벤트 기반 아키텍처인터넷 발전 초기 단계에서 대부분의 웹 서버는 연결당 하나의 프로세스나 스레드를 할당하는 방식으로 동작했습니다. 이는 적은 수의 연결에서는 잘 작동했지만, 동시 연결 수가 증가하면서 한계에 부딪혔습니다.1990년대 후반, Dan Kegel은 "C10K 문제"라는 용어를 만들었습니다. 이는 서버가 10,000개의 동시 연결(Connections 10K)을 처리하는 과제를 의미합니다. 하드웨어 자원이 충분함에도 불구하고 I/O 처리 방식의 한계로 인해 서버가 제대로 처리하지 못하는 현상이었습니다. C10K 문제의 핵심 원인:1. 연결당 하나의 프로세스/스레드 모델의 비효율성2. 커널의 I/O 처리 방식(s..