DevOps Colleague

Kubernetes Operator에서 Custom Resource(CR)의 상태 정보를 외부 DB나 외부 API 호출을 통해 업데이트해야 하는 경우, reconcile 루프에서 무조건 호출하는 건 anti-pattern 입니다. 목표: "상태 변화가 있을 때만 외부 상태를 조회하고 .status를 업데이트한다 [패턴 1] 조건부 외부 API 호출 (Reconcile 루프 내 최소 호출)CR의 .spec 또는 .status에 변화가 있을 때만 외부 API/DB를 조회.외부 상태를 조회해 .status를 업데이트.구현 예시:if hasMeaningfulChange(myResource.Spec, myResource.Status) { externalStatus := queryExternalAPI(myRe..

🔁 1. Reconciliation Loop 남용 / 비효율적인 처리문제: Reconcile 루프에서 너무 많은 로직을 처리하거나, 상태가 바뀌지 않아도 리소스를 계속 업데이트하거나, 외부 API를 호출하는 경우.예시:매번 Deployment를 업데이트하여 rollout이 반복됨외부 DB나 API를 reconcile 루프마다 계속 호출해결: 상태 변화가 있을 때만 필요한 작업을 수행하고, idempotent하게 구현.📦 2. Status 필드 미사용 또는 오용문제: CR의 .status 필드를 사용하지 않거나, 너무 많은 정보를 넣어서 상태 추적이 어려운 경우.해결: 적절한 정보를 넣어 관찰 가능한 상태를 만들고, 컨트롤러는 이 상태를 기준으로 동작해야 함.🧠 3. 컨트롤러가 너무 많은 책임을 가짐..

GPU, 데이터 로컬리티, 멀티 테넌시 등의 특별한 요구사항이 있다면 Scheduler Extender를 먼저 고려하고, 근본적인 변경이 필요하면 Custom Scheduler를 구축하는 것이 좋다  맞춤형 스케줄링(Custom Scheduling)이 필요한 유즈케이스 Kubernetes 기본 스케줄러는 일반적인 워크로드 배치를 최적화하지만, 특정한 요구사항을 가진 애플리케이션에는 맞춤형 스케줄링이 필요할 수 있습니다. 맞춤형 스케줄링이 필요한 유즈케이스 1. GPU 워크로드 최적화 • 특정 GPU 모델(A100, V100 등)을 요구하는 경우 • 사용 가능한 GPU 메모리를 기반으로 Pod을 배치해야 하는 경우 2. 데이터 로컬리티 최적화 • Pod이 특정 데이터 노드와 가까운 곳에서 실행되어야 성능이..

Kubernetes의 기본 Pod 스케줄러(Default Scheduler)는 새로 생성된 Pod을 적절한 Node에 배치하는 역할을 합니다. 스케줄링 로직은 크게 Filter(필터링) → Score(점수 평가) → Bind(할당) 세 단계로 진행됩니다. 1. 스케줄링 프로세스① 후보 노드 필터링 (Predicates)스케줄러는 먼저 클러스터 내의 모든 노드 중에서 Pod을 실행할 수 없는 노드를 제외합니다. 이 과정에서 다음과 같은 조건이 적용됩니다.필터링 조건1. NodeSelector & NodeAffinitynodeSelector, nodeAffinity 등의 조건이 맞지 않으면 제외nodeSelector: disktype: ssd 2. Taints & Tolerationstaint가 적용된 노..

❓ ServiceEntry는 네임스페이스마다 설정해야 하나?👉 아니요, 반드시 네임스페이스마다 설정할 필요는 없습니다.👉 하지만, ServiceEntry의 적용 범위는 리소스를 정의한 네임스페이스에 따라 달라질 수 있음.1️⃣ ServiceEntry의 네임스페이스 적용 범위설정 위치적용 대상특징공용 네임스페이스 (예: istio-system)모든 네임스페이스의 Pod에서 사용 가능클러스터 전체에서 외부 서비스 접근 가능특정 네임스페이스 (예: app-namespace)해당 네임스페이스의 Pod에서만 사용 가능네임스페이스 별로 개별 설정 필요2️⃣ ServiceEntry 적용 범위에 따른 예제✅ 1. 클러스터 전체에서 공유 (istio-system 네임스페이스에 설정)👉 모든 네임스페이스의 Pod가 ..

❓ Istio Egress Gateway에서 TLS 요청이 해석되는 방식👉 예, SIMPLE 모드를 사용하면 Egress Gateway에서 TLS를 해석할 수 있음.👉 Egress Gateway에서 클라이언트(앱)와 외부 서버 간의 TLS 연결을 두 개의 개별 TLS 연결로 변환함.클라이언트(앱) → Egress Gateway에서 TLS 종료Egress Gateway → 외부 서버로 새로운 TLS 연결 생성 1️⃣ PASSTHROUGH 모드 vs SIMPLE 모드 비교✅ 1. PASSTHROUGH 모드 (TLS 직접 전달)Egress Gateway에서 TLS를 해석하지 않고 그대로 외부 서버로 전달.TLS 핸드셰이크 및 암호화는 앱과 외부 서버 간에 직접 수행됨.Istio는 트래픽을 해석할 수 없으며..

❓ Egress Gateway에서 VirtualService 설정이 필요한가?👉 예, 필요한 경우가 많지만, 필수는 아닙니다.ServiceEntry만으로 클러스터 내부의 Pod들이 외부 서비스와 직접 통신할 수 있도록 설정 가능.하지만 Egress Gateway를 통해 트래픽을 반드시 경유하도록 강제하려면 VirtualService가 필요.즉, Egress Gateway를 통한 외부 서비스 트래픽을 세밀하게 제어하려면 VirtualService를 추가해야 합니다. 🔎 ServiceEntry와 VirtualService의 차이점리소스 종류역할필수 여부ServiceEntry클러스터 내부에서 외부 서비스로의 트래픽을 허용✅ 필수VirtualService트래픽이 반드시 Egress Gateway를 통과하도록..

Istio에서 North-South Traffic(남북 트래픽)은 클러스터 외부와 내부 간에 흐르는 트래픽을 의미합니다.💡 쉽게 말해?외부에서 클러스터 내부로 들어오는 트래픽 (Inbound)클러스터 내부에서 외부로 나가는 트래픽 (Outbound) 1️⃣ North-South Traffic의 주요 개념트래픽 방향설명예제North Traffic (Ingress, 들어오는 트래픽)외부 클라이언트(사용자, API, 서비스)가 클러스터 내부의 애플리케이션에 요청을 보낼 때 발생- 사용자가 브라우저에서 https://my-app.com 접속- 모바일 앱이 클러스터 내부의 API 서버에 요청South Traffic (Egress, 나가는 트래픽)클러스터 내부의 서비스가 외부 API 또는 인터넷 리소스에 요청을 ..