threat-intel-qdrant-service를 postgres와 같은 이유로 NodePort로 열면서 격은 일과, 범용 DB 클라이언트("DBUI")로는 왜 Qdrant에 붙을 수 없는지 정리.

1. 문제 상황

postgres(postgres-service)를 NodePort로 열어 DBUI에서 접속에 성공한 뒤, 같은 네임스페이스(c4i)의 threat-intel-qdrant-service도 원격에서 접속하려 했다.

원인은 postgres와 동일: threat-intel-qdrant-service가 type: ClusterIP였다. ClusterIP는 클러스터 내부 전용 가상 IP라, 노드의 Tailscale IP(100.x.x.x)로는 애초에 도달할 수 없다.

2. 조치 — git에 바로 type: NodePort 커밋

postgres 사례에서 "ignoreDifferences + 수동 패치"는 재현성이 없어 재해가 반복된다는 걸 확인했으므로, 이번엔 처음부터 git에 직접 커밋하는 쪽을 택했다.

# apps/threat-intel-ai-service/qdrant.yaml (변경 후, 커밋 0dc7c1c)
spec:
  type: NodePort
  selector:
    app: threat-intel-qdrant
  ports:
    - port: 6333
      targetPort: 6333
      nodePort: 30333
      protocol: TCP

nodePort: 30333은 postgres 때 쓔 "30000 + 원래 포트 마지막 3자리" 패턴을 따른 것 (6333 → 30333).

<table header-row="true"><tr><td>Service</td><td>NodePort</td></tr><tr><td>postgres-service</td><td>30432</td></tr><tr><td>defense-api-gateway</td><td>30081</td></tr><tr><td>argocd-server</td><td>31525 / 30443</td></tr><tr><td>threat-intel-qdrant-service</td><td>30333 (신규, 충돌 없음)</td></tr></table>

3. 다른 컴포넌트에 미치는 영향 — 없음

4. 인증이 없다 — postgres와의 결정적 차이

postgres는 target-tracking-secrets에서 POSTGRES_USER/PASSWORD를 주입받지만, threat-intel-qdrant Deployment에는 컨테이너 env가 하나도 없다. Qdrant는 QDRANT__SERVICE__API_KEY 환경변수를 명시적으로 설정해야만 API 키 인증이 켜진다. 지금은 그게 없으므로 30333에 도달할 수 있는 누구나 인증 없이 컴렉션을 읽고/쓰고/지울 수 있다. Tailscale 오버레이 안이라는 것만이 유일한 방어선이다.

5. DBUI(범용 DB 클라이언트)로는 왜 안 되나 — no adapter for http

NodePort까지 다 열어놓고 DBUI 연결 필드에 http://100.x.x.x:30333를 넣었더니 다음 에러: DB: no adapter for http

원인: postgres 때와 달리 이건 네트워크/K8s 문제가 아니라 클라이언트 소프트웨어의 한계다. TablePlus/DBeaver 같은 범용 DB 클라이언트는 postgres://, mysql:// 같은 정해진 DB 와이어 프로토콜의 어댑터만 내장한다. Qdrant는 그런 프로토콜이 아니라 순수 HTTP REST API(+선택적 gRPC)로 통신하는 벡터 DB라 "http"라는 어댑터 자체가 클라이언트 목록에 없어 연결 시도 단계에서 바로 거부당한다.

대안

Qdrant 이미지(qdrant/qdrant:v1.12.4)에는 REST 포트(6333/30333)에 웹 대시보드가 내장되어 있다. 베이지를 브라우저로 직접 열면 된다:

http://100.83.49.100:30333/dashboard