"연결이 거부됐다" 는 메시지는 층이 여럿이다. 어느 방향의 연결이 막혔는지에 따라 볼 곳이 완전히 달라지므로 먼저 아래 표로 가른다.
| 로그 주체 | 메시지 | 막힌 구간 |
|---|---|---|
| 워커·코디네이터 | AnnounceNodeAnnouncer ... Server refused connection |
노드 → 코디네이터 (클러스터 내부) |
| 워커·코디네이터 | AnnounceNodeAnnouncer ... Failed communicating with server |
TCP 는 붙었으나 TLS·프로토콜 불일치 |
| SQL 클라이언트 | java.net.ConnectException: Connection refused |
클라이언트 → 외부 진입점 (Ingress·LB·NodePort) |
| 브라우저 | Web UI 가 뜨지 않음 | 프로토콜·포트·코디네이터 여부 |
WARN http-client-announcer-121 io.trino.node.AnnounceNodeAnnouncer
Error announcing node state to http://trino-coordinator-service.databases:8080/v1/announce:
Server refused connection
노드가 코디네이터에 자신을 등록하려다 TCP 연결 자체가 거부된 상태다. DNS 는 풀렸고 그 주소에 듣고 있는 프로세스가 없거나 차단된 것이다. Kubernetes 라면 다음 순서로 좁힌다.
kubectl -n databases get pods
kubectl -n databases get svc
kubectl -n databases get endpointslices -l kubernetes.io/service-name=trino-coordinator-service
kubectl -n databases logs <coordinator-pod>
엔드포인트가 비어 있으면 서비스 selector 가 파드 라벨과 어긋났거나 파드가 Ready 가 아니다. 가장 흔한 원인이다. 엔드포인트가 있으면 워커 파드 안에서 직접 찔러 본다.
kubectl -n databases exec -it <worker-pod> -- curl -v http://trino-coordinator-service:8080/v1/info
여기까지 정상인데도 등록이 실패하면 워커의 discovery.uri 가 서비스 이름과 정확히 같은지 본다. 네임스페이스가 다르면 <service>.<namespace>.svc.cluster.local 까지 적어야 한다. NetworkPolicy 가 걸려 있는지도 확인한다.
코디네이터 자신의 로그에서 같은 메시지가 반복되는 경우도 있다. 코디네이터도 discovery 클라이언트로 동작하므로 기동 초기에는 자기 자신에게 등록을 시도하다 몇 번 실패할 수 있다. HTTP 서버가 먼저 열리고 내부 초기화가 끝나기 전이라면 일시적이다. 기동이 끝난 뒤에도 5초 간격으로 계속 반복된다면 일시적인 것이 아니므로 위 절차대로 본다.
Error announcing node state to https://trino-coordinator-service.databases.svc.cluster.local:8443/v1/announce:
Failed communicating with server
curl 로는 /v1/status 가 정상 응답하는데 Trino 내부 클라이언트만 실패한다면 통신 경로가 아니라 TLS 신뢰 문제다. curl 은 옵션에 따라 검증을 느슨하게 넘어가지만 Trino 내부 HTTP 클라이언트는 서버 인증서를 검증한다. 자체 서명 인증서를 쓴다면 그 CA 를 각 노드의 truststore 에 넣어야 한다.
/v1/announce 에 Unauthorized 가 돌아오는 것은 정상이다. 그 엔드포인트는 인증된 내부 통신만 받는다. 내부 통신 보안을 켰다면 모든 노드가 같은 shared secret 을 가져야 한다. 설정은 Trino 설정 의 내부 통신 보안 절과 Trino 자체 서명 인증서 생성 을 본다.
java.net.ConnectException: Failed to connect to trino.example.net/192.168.254.1:8443
Connection refused: getsockopt
DNS 는 풀렸고 해당 IP 의 8443 에 듣는 것이 없다는 뜻이다. 클러스터 내부가 아니라 진입점 문제다.
ss -tulnp | grep 8443
kubectl get pods -A | grep -i ingress
kubectl get ingress -A
Ingress 컨트롤러가 없거나 죽었을 때, 포트가 노출되지 않았을 때, Ingress 가 서비스에 연결되지 않았을 때 이 증상이 난다.
Web UI 는 코디네이터에서만 제공된다. 워커 주소로 접속하면 아무것도 나오지 않는 것이 정상이다. 그 외에는 순서대로 본다.
| 확인 | 내용 |
|---|---|
web-ui.enabled |
기본값은 true 다. 명시적으로 꺼 두지 않았는지 본다 |
| 프로토콜 | http-server.https.enabled=true 이고 HTTP 를 껐다면 https://<host>:8443 으로 붙어야 한다 |
| 포트 | http-server.http.port 를 바꿨는지 확인한다 |
| 인증 | http-server.authentication.type 이 걸려 있으면 로그인 화면이 나오는 것이 정상이다 |
| 리버스 프록시 | Web UI 는 루트 경로를 쓴다. 하위 경로로 프록시하면 정적 자원을 찾지 못한다 |
Trino 컨테이너 이미지의 준비 스크립트가 아래 같은 경고를 남기는 경우가 있다.
[!] Current nofile (1024) is less than 131072. Updating...
/opt/trino/bin/init-container.sh: line 17: [: unlimited: integer expression expected
[!] vm.max_map_count (65530) is low. Increasing to 262144...
sysctl: permission denied on key "vm.max_map_count"
integer expression expected 는 ulimit 결과가 unlimited 로 나와 숫자 비교에 실패한 것이라 기동에 영향이 없다. vm.max_map_count 는 커널 파라미터라 일반 컨테이너에서 바꿀 수 없다. 노드에서 직접 올리거나 파드 spec 의 securityContext.sysctls 로 넣어야 한다. 값이 낮으면 대용량 쿼리에서 메모리 매핑이 모자라 성능이 떨어진다.
sudo sysctl -w vm.max_map_count=262144
echo 'vm.max_map_count=262144' | sudo tee /etc/sysctl.d/99-trino.conf
Kubernetes 위 Trino 기동 문제 · Trino 코디네이터 이중화와 노드 식별