ACTIVE INCIDENT
00:00 elapsed
LABLAB-K8S-02-SERVICE-NETWORKINGSEV-2
Service가 Pod를 못 찾는다 — Kubernetes 서비스 디버깅
ELAPSED
00:00
PHASE
0 / 5
SLA
45분
Kubernetes
← 목록
INCIDENT RESPONSE
0 / 6 단계 완료
📚 PREREQUISITES
Labk8s-basics-pod-deploy
Theorykubernetes/pod-basics
Theorylinux/networking-basics
TRACK
KUBERNETES
SLA
45분
SEV
SEV-2
PHASES
4단계
ENV
local
INCOMING TICKET
운영 티켓: "k8s-service-networking 인프라 구성 요청"
YOUR ROLE
주니어 인프라 엔지니어
IMPACT IF UNRESOLVED
신규 인프라 구성 지연 및 배포 일정 연기
🚨INCIDENT BRIEF
오후 2시, 슬랙에 메시지가 올라왔습니다.
api-service 연결 안 됩니다. 팀원 둘이 확인했는데 클라이언트에서 계속 Connection refused 나와요.
`kubectl get pods`를 보면 Pod는 모두 `Running`입니다.
`kubectl get svc`에도 `api-service`가 정상적으로 보입니다.
근데 왜 연결이 안 될까요?
Kubernetes Service는 Pod에 직접 연결하지 않습니다.
Endpoint 라는 오브젝트를 통해 Pod IP 목록을 관리합니다.
Service가 있어도 Endpoint가 없으면, 트래픽이 갈 곳이 없습니다.
이 Lab에서는 Kubernetes Service 디버깅의 표준 절차인
selector → label → Endpoint → DNS 흐름을 직접 파헤칩니다.
⏱ 45분📊 중급🔧 4단계#kubernetes#service#networking#endpoint
MISSION
1
증상 파악 — Service와 Endpoint 상태 확인
kubectl get svc와 kubectl get endpoints로 Service와 Endpoint 상태를 확인하고, Endpoint가 비어 있음을 발견한다
2
원인 분석 — selector와 Pod label 불일치
Service의 selector와 Pod의 label을 비교해 불일치를 발견하고, 어느 쪽이 잘못됐는지 판단한다
3
수정 적용 — label 또는 selector 교정
kubectl label 또는 kubectl patch 명령으로 Pod label을 수정(또는 Service selector 수정)해 Endpoint가 정상적으로 채워지도록 복구한다
4
DNS 해석 검증 — 클러스터 내 서비스 이름으로 통신
임시 Pod를 띄워 Service 이름(DNS)으로 api-service에 실제 HTTP 요청을 보내고, ClusterIP DNS가 작동함을 확인한다
📌 선수 지식
• [실습] k8s-basics-pod-deploy
• [이론] kubernetes/pod-basics
• [이론] linux/networking-basics
ℹ️ 실습 환경
환경: local
필요 도구: kubectl, curl
검증 스크립트: /labs/lab-k8s-02-service-networking/scripts/verify.sh
🔒
실습 실행은 Pro 플랜 전용입니다
인시던트 브리프와 학습 자료는 지금 바로 확인할 수 있습니다. 실제 실습 진행 및 터미널 사용은 Pro 플랜에서 가능합니다.
Pro로 업그레이드 →
>_ LAB TERMINAL↔ 너비 조절
NOTES