DevOps Colleague

StatefulSet + headless service 조합은 Kubernetes에서 PostgreSQL처럼 상태(stateful)를 가진 애플리케이션을 배포하고, 노드 간 안정적인 네트워크 ID를 제공하는 핵심 메커니즘입니다.특히, PostgreSQL의 클러스터링 구성이나 장애조치(failover) 시 이 구조가 중요한 역할을 해요. ✅ 1. Headless Service란?apiVersion: v1kind: Servicemetadata: name: postgresspec: clusterIP: None # 👈 headless로 만듦 selector: app: postgres ports: - port: 5432 📌 핵심 특징:항목설명clusterIP: NoneCluster IP가 ..

HAProxy와 Nginx는 둘 다 로드 밸런서 및 프록시 서버로 널리 사용되지만, 설계 철학, 기능, 활용 방식에서 차이가 있습니다.또한 L4 (TCP) 와 L7 (HTTP/HTTPS) 모두에서 사용 가능하지만, 각각의 특징에 따라 어떤 레이어에 더 적합한지도 차이가 납니다. HAProxy vs Nginx – 핵심 비교 항목HAProxyNginx원래 목적고성능 L4/L7 로드밸런서정적 웹 서버 + L7 프록시L4 지원 (TCP)✅ 강력함 (기본)⚠️ 가능 (stream 모듈 필요)L7 지원 (HTTP)✅ 매우 정교함✅ 뛰어남 (기본 제공)성능 (대용량 처리)✅ 매우 우수 (특화됨)✅ 우수 (Web에 특화됨)설정 방식선언적, 세부 제어 강력선언적, 간결하고 직관적동적 구성 변경제한적 (RELOAD 필요)..

Spring Boot 애플리케이션이 Kubernetes에서 Pod 시작 시 CPU 사용량이 급증하는 주된 이유는 JVM(Java Virtual Machine)의 초기화 과정과 Spring Boot 자체의 초기 부팅 과정 때문입니다.이를 자세히 분석하면 다음과 같은 주요 원인이 있습니다.1️⃣ JVM 초기화 및 JIT(Just-In-Time) 컴파일 최적화✔ JVM은 애플리케이션 실행 전 여러 초기화 작업을 수행✔ JIT(Just-In-Time) 컴파일러가 코드를 최적화하면서 CPU 사용량 증가✅ 설명:JVM은 애플리케이션 실행 시 클래스 로딩, 메서드 컴파일, JIT 최적화를 수행특히 JIT 컴파일러는 처음 실행되는 코드의 성능을 최적화하기 위해 상당한 CPU를 사용JIT 컴파일이 완료된 후에는 CPU ..

Kubernetes 컨트롤러는 특정 리소스의 원하는 상태(Desired State) 와 현재 상태(Current State) 를 비교하고,이를 동기화(Sync)하는 역할을 합니다. 1️⃣ Kubernetes 컨트롤러의 기본 개념컨트롤러는 반복적으로 현재 상태를 확인하고, 원하는 상태로 변경하는 작업을 수행하는 과정입니다.기본 컨트롤러 루프for { desired := getDesiredState() // 원하는 상태 가져오기 current := getCurrentState() // 현재 상태 가져오기 makeChanges(desired, current) // 현재 상태를 원하는 상태로 변경}  Kubernetes 컨트롤러는 실시간으로 이벤트를 감지하여 상태를 조정하는 역할을 합니다.Info..

Watcher를 사용한 Kubernetes 리소스 감시 예제Watcher는 Kubernetes API 서버와 직접 연결하여 실시간 이벤트를 감지하는 방식입니다.하지만 API 서버 부하가 커질 수 있고, 연결이 끊기면 다시 연결해야 하는 단점이 있습니다.  Watcher 기반 Deployment 감시 예제아래 코드는 Watcher를 사용하여 Kubernetes의 Deployment 리소스를 실시간으로 감시합니다.package mainimport ( "context" "fmt" "log" v1 "k8s.io/api/apps/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/client-go/kubernetes" "k8s.io/client-go/rest" ..

Kubernetes API 서버 자체는 gRPC를 직접 지원하지 않지만, 일부 내부 및 확장 기능에서 gRPC 기반 통신을 활용하는 부분이 있음.1️⃣ Kubernetes API 서버는 RESTful API 기반Kubernetes API 서버는 기본적으로 HTTP/HTTPS REST API 를 제공함.모든 공식 API 엔드포인트는 JSON 형식으로 데이터를 주고받음.예제: curl -X GET https://:6443/api/v1/pods kubectl 역시 RESTful API를 사용해서 Kubernetes와 상호작용함.2️⃣ Kubernetes 내부에서 gRPC가 사용되는 곳비록 API 서버가 gRPC를 직접 노출하지는 않지만, Kubernetes 내부적으로 gRPC 기반 통신이 사용되는 몇 가지 요..

1. istio/base  • 역할: istio/base는 Istio 설치의 기본 리소스들을 정의하는 Helm 차트입니다. 여기에는 네임스페이스, 클러스터 역할, 역할 바인딩, 서비스 계정, 커스텀 리소스 정의(CRD) 등 Istio의 모든 구성 요소가 동작하는 데 필요한 기본 인프라 스트럭처가 포함됩니다. 다른 Istio 컴포넌트들은 istio/base에 의존하여 설정됩니다. 2. istio/istiod  • 역할: istio/istiod는 Istio의 제어 평면(Control Plane)을 담당하는 Helm 차트입니다. 이 차트는 Istio의 핵심 컴포넌트인 istiod를 설치하며, 서비스 메쉬 내에서의 트래픽 관리, 정책 적용, 텔레메트리 수집 등을 수행합니다. istiod는 Envoy 사이드카 프..

EOF(End Of File) stdin은 쉘 스크립트에서 입력을 다루는 방법 중 하나로, 주로 명령어 내에서 여러 줄의 텍스트를 인라인으로 전달할 때 사용됩니다. 예를 들어 kubectl apply 명령어를 통해 Kubernetes에 리소스를 정의하고 적용하는 과정에서 EOF stdin을 활용할 수 있습니다. EOF stdin의 역할EOF(End Of File) stdin은 쉘에서 입력의 끝을 나타내기 위한 기호입니다. 이 기호를 사용하면 명령어에 여러 줄의 텍스트를 직접 포함시킬 수 있습니다. 이 방식은 주로 사용 예시: kubectl apply -f - 위 예제에서는 kubectl apply 명령어에 파일 입력 대신 표준 입력(stdin)을 사용하여 Kubernetes 리소스를 정의하고 적용하고 있..