[IT-정보] 쿠버네티스 서비스 FAQ 실무 가이드 – 헷갈리는 설정부터 장애 대응까지

쿠버네티스 서비스 네트워킹에서 마주하는 막막한 순간들

데브옵스 엔지니어로 일하다 보면 가장 당혹스러운 순간이 있어요. 분명히 포드는 정상적으로 실행 중이고, 로그도 아무런 에러 없이 올라오고 있는데 정작 외부나 다른 서비스에서 접속하려고 하면 연결 거부(Connection Refused) 메시지만 뜨는 상황이에요. 서비스 설정을 다시 확인해 봐도 겉보기에는 아무런 문제가 없어 보여서 밤늦게까지 터미널 창만 붙잡고 있는 경우가 많지요.

쿠버네티스 환경에서 서비스(Service)는 단순히 포트를 열어주는 도구가 아니에요. 동적으로 변하는 포드들의 IP 주소를 추적하고, 트래픽을 적절한 곳으로 전달하는 매우 정교한 네트워킹 계층이에요. 이 계층의 동작 원리를 정확히 이해하지 못하면, 배포 파이프라인을 구축할 때마다 원인 모를 통신 장애 때문에 고생할 수밖에 없어요.

이 글은 단순히 이론적인 정의를 나열하려는 것이 아니에요. 실무에서 가장 자주 묻는 질문들을 중심으로, 왜 내 서비스가 동작하지 않는지, 어떤 상황에서 어떤 타입을 선택해야 하는지, 그리고 장애가 발생했을 때 어디를 가장 먼저 점검해야 하는지를 명확하게 짚어드리고자 해요. 이 가이드를 끝까지 읽고 나면, 복잡한 네트워크 흐름 속에서도 당황하지 않고 문제를 해결하는 힘을 얻으실 수 있어요.

서비스 설정을 시작하기 전 반드시 체크해야 할 기초 지식

서비스를 구축하기 전에 가장 먼저 확인해야 할 것은 레이블(Label)과 셀렉터(Selector)의 일치 여부예요. 쿠버네티스 서비스는 포드의 IP를 직접 관리하는 것이 아니라, 특정 레이블을 가진 포드들을 묶어서 엔드포인트(Endpoint)를 생성하는 방식으로 동작해요. 만약 셀렉터에 오타가 하나라도 있다면, 서비스는 아무런 포드도 찾지 못하고 공중에 떠 있는 상태가 되어버려요.

또한, 포드의 컨테이너 내부에서 실제로 리스닝(Listening)하고 있는 포트 번호와 서비스 설정의 타겟 포트(TargetPort)가 일치하는지도 확인해야 해요. 많은 엔지니어가 서비스 포트(Port)와 타겟 포트(TargetPort)를 혼동하여 트래픽을 엉뚱한 곳으로 보내는 실수를 범하곤 해요. 이 두 개념을 명확히 구분하는 것이 네트워킹 문제 해결의 첫걸음이에요.

서비스 타입을 결정할 때는 클러스터 내부 통신인지, 아니면 외부 사용자에게 서비스를 노출해야 하는지를 먼저 판단해야 해요. 아래 표를 통해 각 타입의 특징과 선택 기준을 정리해 두었으니, 설계 단계에서 참고해 보세요.

서비스를 설계할 때는 단순히 ‘동작하게 만드는 것’을 넘어, 보안 정책과 트래픽 비용을 반드시 고려해야 해요. 예를 들어, 데이터베이스 같은 민감한 서비스는 반드시 클러스터IP를 사용하여 외부 노출을 차단해야 하며, 웹 서비스처럼 대규모 트래픽을 처리해야 한다면 로드밸런서나 인그레스(Ingress)를 조합하는 방식이 권장돼요.

실무를 위한 단계별 서비스 구성 및 운영 전략

쿠버네티스 서비스를 제대로 운영하기 위해서는 단순히 YAML 파일을 작성하는 수준을 넘어, 각 단계별로 데이터 흐름을 이해하고 제어할 수 있어야 해요. 실무에서 가장 빈번하게 적용되는 5단계 프로세스를 통해 깊이 있게 살펴볼게요.

STEP 1. 레이블 매칭과 엔드포인트 생성 확인하기

모든 서비스의 시작은 셀렉터(Selector)를 통한 포드 연결이에요. 서비스가 생성되었다고 해서 바로 통신이 되는 것은 아니에요. 서비스가 바라보고 있는 레이블이 실제 포드에 부여된 레이블과 정확히 일치하는지 확인하는 과정이 필수적이에요.

예를 들어, 서비스에 app: backend라는 셀렉터가 있다면, 대상 포드에는 반드시 app: backend 레이블이 있어야 해요. 만약 일치하지 않는다면 쿠버네티스는 해당 서비스를 위한 엔드포인트(Endpoints)를 생성하지 못해요. 엔드포인트는 서비스가 트래픽을 전달할 실제 포드들의 IP 주소 목록을 담고 있는 객체예요. 만약 kubectl get endpoints 명령어를 입력했을 때 목록이 비어 있다면, 십중팔구 셀렉터 설정 오류예요.

STEP 2. 포트(Port) 설정의 삼각 관계 이해하기

서비스 설정에서 가장 많은 혼란을 야기하는 부분이 바로 포트 번호예요. 실무에서는 다음 세 가지를 반드시 구분해서 작성해야 해요.

• 포트(Port): 서비스 자체의 IP를 통해 접근할 때 사용하는 포트예요. 클러스터 내부의 다른 포드들이 이 포트로 접속해요.
• 타겟 포트(TargetPort): 트래픽이 최종적으로 도달할 포드 내 컨테이너의 포트예요. 애플리케이션이 실제로 리스닝 중인 번호와 같아야 해요.
• 노드포트(NodePort): 노드 타입을 사용할 때, 외부에서 노드의 IP와 함께 접속하기 위해 사용하는 포트예요. 보통 30000~32767 사이의 범위를 사용해요.

만약 애플리케이션이 8080 포트에서 돌아가고 있는데, 서비스의 타겟 포트를 80으로 적는다면 트래픽은 길을 잃게 돼요. 이 관계를 명확히 정의하는 것이 네트워크 설계의 핵심이에요.

STEP 3. 트래픽 노출 방식의 최적화 전략

서비스를 외부에 노출할 때는 상황에 맞는 전략을 선택해야 해요. 단순히 노드포트를 사용하는 것은 편리해 보일 수 있지만, 노드 IP가 변경되거나 보안 그룹 설정이 복잡해지는 문제를 일으킬 수 있어요.

대규모 운영 환경에서는 보통 로드밸런서(LoadBalancer) 타입을 사용하여 클라우드 공급자가 제공하는 안정적인 로드밸런서를 활용해요. 하지만 서비스 개수가 많아질수록 비용 문제가 발생할 수 있어요. 이때는 각 서비스마다 로드밸런서를 생성하는 대신, 인그레스(Ingress)를 도입하여 하나의 로드밸런서로 여러 서비스를 경로(Path) 기반으로 라우팅하는 방식이 훨씬 경제적이고 관리하기 쉬워요.

STEP 4. 헤드리스 서비스(Headless Service) 활용하기

데이터베이스 클러스터처럼 각 포드가 고유한 식별자를 가져야 하는 상태 저장 애플리케이션(StatefulSet)의 경우, 일반적인 서비스로는 부족해요. 이때 사용하는 것이 바로 헤드리스 서비스예요.

헤드리스 서비스는 클러스터IP를 할당하지 않고, DNS 조회 시 서비스의 가상 IP 대신 실제 포드들의 IP 주소를 직접 반환하도록 설정하는 방식이에요. 이를 통해 클라이언트가 특정 포드에 직접 연결하거나, 데이터베이스의 복제본(Replica)들 사이에서 직접 통신해야 할 때 매우 유용하게 쓰여요. YAML 설정에서 clusterIP: None으로 지정하는 것만으로 간단히 구현할 수 있어요.

STEP 5. 실제 배포 시나리오 및 트래픽 흐름 점검

이해를 돕기 위해 일반적인 웹 애플리케이션 배포 시나리오를 예로 들어볼게요. 사용자가 웹 브라우저를 통해 접속하는 과정은 다음과 같은 단계를 거쳐요.

1. 사용자가 도메인(example.com)으로 접속을 시도해요.
2. 외부 로드밸런서가 요청을 받아 클러스터 내부의 인그레스 컨트롤러로 전달해요.
3. 인그레스 컨트롤러는 HTTP 경로를 확인하고, 해당 요청을 적절한 서비스(예: backend-service)로 라우팅해요.
4. 서비스는 자신의 클러스터IP를 통해 내부 네트워크에서 요청을 처리하고, 엔드포인트에 등록된 포드 중 하나로 트래픽을 보냅니다.

이 흐름 중 어느 한 곳이라도 설정이 잘못되면 서비스는 중단돼요. 따라서 각 단계에서 로그 확인과 통신 테스트를 병행하며 검증하는 습관을 가져야 해요.

자주 하는 실수와 해결법 및 FAQ

자주 하는 실수와 해결법

실무에서 엔지니어들이 가장 빈번하게 겪는 트러블슈팅 사례들을 정리했어요. 문제를 만났을 때 체크리스트로 활용해 보세요.

• ❌ 실수: 셀렉터 레이블 불일치
  왜 발생하는가: 포드의 레이블을 수정했으나 서비스의 셀렉터 값을 업데이트하지 않았을 때 발생해요.
  ✅ 해결법: kubectl get pods --show-labels와 kubectl describe svc [서비스명]을 비교하여 레이블이 완벽히 일치하는지 확인하세요.
• ❌ 실수: 포트와 타겟 포트 혼동
  왜 발생하는가: 서비스 포트와 컨테이너 포트를 반대로 설정하여 트래픽이 전달되지 않아요.
  ✅ 해결법: 서비스 YAML의 port는 클러스터 내부 접속용, targetPort는 포드 내부 앱 포트임을 명심하고 재설정하세요.
• ❌ 실수: Readiness Probe 실패로 인한 엔드포인트 누락
  왜 발생하는가: 포드는 떠 있지만, 애플리케이션 준비 상태가 완료되지 않아 서비스에서 제외된 경우예요.
  ✅ 해결법: kubectl describe pod를 통해 Readiness Probe가 성공했는지 확인하고, 앱의 초기화 로직을 점검하세요.
• ❌ 실수: 노드포트 포트 충돌 또는 방화벽 차단
  왜 발생하는가: 지정한 노드포트가 이미 사용 중이거나, 클라우드 보안 그룹에서 해당 포트를 허용하지 않았을 때 발생해요.
  ✅ 해결법: 클라우드 콘솔에서 보안 그룹 규칙을 확인하고, 사용 가능한 포트 범위인지 체크하세요.
• ❌ 실수: DNS 전파 지연 및 캐시 문제
  왜 발생하는가: 서비스 생성 직후 DNS 정보가 즉시 업데이트되지 않아 이전 정보를 조회하는 경우예요.
  ✅ 해결법: 잠시 기다린 후 다시 시도하거나, nslookup [서비스명]을 통해 DNS가 올바른 IP를 가리키는지 확인하세요.

자주 묻는 질문

Q. 클러스터IP가 있는데 왜 외부에서 접속이 안 되나요?

클러스터IP는 말 그대로 클러스터 내부 전용 주소이기 때문이에요. 외부에서 접속하려면 노드포트나 로드밸런서 타입을 사용하거나, 인그레스를 통해 통로를 열어주어야 해요.

Q. 서비스의 엔드포인트가 비어 있으면 어떻게 해야 하나요?
가장 먼저 서비스의 셀렉터와 포드의 레이블이 일치하는지 확인하세요. 또한, 포드가 Running 상태인지, 그리고 Readiness Probe를 통과했는지 반드시 체크해야 합니다.

Q. 하나의 서비스에 여러 개의 포트를 설정할 수 있나요?
네, 가능해요. 하나의 서비스 YAML 안에 여러 개의 ports 항목을 정의하면, 하나의 서비스 IP로 여러 프로토콜이나 포트 번호를 관리할 수 있어요.

Q. 헤드리스 서비스와 일반 서비스의 결정적인 차이는 무엇인가요?
일반 서비스는 클러스터IP라는 가상 IP를 통해 트래픽을 분산하지만, 헤드리스 서비스는 IP를 부여하지 않고 DNS를 통해 포드들의 실제 IP를 직접 알려준다는 점이 달라요.

Q. 서비스 이름을 변경하면 기존 통신에 영향이 있나요?
네, 매우 큰 영향을 줘요. 서비스 이름은 쿠버네티스 내부 DNS의 호스트네임으로 사용되기 때문에, 이름을 변경하면 해당 서비스를 호출하던 모든 클라이언트의 설정도 함께 변경해야 해요.

안정적인 네트워킹 운영을 위한 마무리 가이드

쿠버네티스 서비스는 클러스터라는 거대한 생태계를 연결하는 신경망과 같아요. 신경망이 꼬이면 전체 시스템이 마비되듯, 서비스 설정 오류 하나가 서비스 전체의 중단으로 이어질 수 있습니다. 오늘 배운 내용을 바탕으로 실무에서 더욱 탄탄한 인프라를 구축해 보세요.

이제 이론은 충분히 익혔습니다. 다음 단계로 나아가기 위해 아래의 실천 과제를 제안합니다.

• 오늘 할 일: 현재 운영 중인 서비스의 YAML 파일을 열어 셀렉터와 타겟 포트가 정확한지 검토하세요.
• 이번 주 할 일: 테스트 환경에서 노드포트와 로드밸런서의 트래픽 흐름 차이를 직접 명령어로 확인해 보세요.
• 실행 직전 할 일: 서비스 장애를 대비한 모니터링 알람(엔드포인트 유무 등) 설정을 검토하세요.

실습 환경에서 직접 적용해 보시고, 설정 과정에서 막히는 부분이나 이해가 되지 않는 특이 케이스가 있다면 언제든 댓글로 질문을 남겨 주세요. 함께 고민하면 해결할 수 있어요!

관련하여 더 깊은 공부가 필요하시다면, 쿠버네티스 서비스 기본 개념 글이나 클러스터 구축 입문 글을 함께 읽어보시는 것을 추천합니다.