| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
- 정보처리기사 실기 기출문제
- aws
- AI
- Spring
- 기록으로 실력을 쌓자
- APM
- CKA 기출문제
- MySQL
- 티스토리챌린지
- CKA
- minikube
- Linux
- LLM
- go
- tucker의 go 언어 프로그래밍
- Pinpoint
- 오블완
- 바이브코딩
- Kubernetes
- kotlin
- 공부
- SRE
- 코틀린 코루틴의 정석
- 컨텍스트 엔지니어링
- kotlin coroutine
- AWS EKS
- PETERICA
- CloudWatch
- Java
- golang
- Today
- Total
피터의 개발이야기
[kubernetes] Ingress Host 매칭으로 하나의 네임스페이스에 여러 Kibana 운영하기 본문
[kubernetes] Ingress Host 매칭으로 하나의 네임스페이스에 여러 Kibana 운영하기
기록하는 백앤드개발자 2025. 9. 10. 00:10ㅁ 들어가며
회사에서 kibana 서버를 이관하는 과정에서 개선점으로 쿠버네티스 환경을 선택하였다.
쿠버네티스 환경에서 동일 네임스페이스에 여러 Kibana-ElasticSearch 인스턴스를 운영해야 하는 경우, 가장 좋은 방법은 도메인 단위로 접속을 분리하는 것이다. 서비스 포트는 동일하게 유지하면서도, 각 Kibana가 바라보는 Elasticsearch와 트래픽을 확실히 분리해야 관리와 확장이 수월해진다.
이를 가능하게 해주는 핵심 기술이 바로 Ingress Host 매칭 규칙이다. 클라이언트 요청의 Host 헤더를 기준으로 트래픽을 분기하여, 동일 포트라도 각기 다른 도메인으로 접근할 때 서로 다른 Kibana 서비스로 라우팅할 수 있다. 이번 글에서는 이러한 아키텍처 설계 원리와 실제 구현 방법을 정리하였다.
처음부터 모든 기술적 이해를 바탕으로 설계할 수 없었다. 문제(의문)을 시작으로 기술에 대해서 조사하고 구체적인 방안을 정리하였다.
ㅁ 문제 정의: 여러 Ingress가 동일 포트(5601)로 매칭되면, 서로 섞여 혼돈이 생기지 않을까?
ㅇ 처음에는 nameSpace를 kibana별로 구분하려했다. 하지만, 너무 어수선해 보여 고민하였다.
ㅇ 동일 네임스페이스에서 여러 Kibana-ElasticSearch 조합을 동시에 운영해야 하는 요구 발생
ㅇ 서비스 포트(예: 5601)는 공통으로 유지해야 하지만, 도메인별로 완전히 독립된 서비스 필요
ㅇ 관리 편의성과 향후 확장을 고려한 구조 필요
ㅁ 해결 목표 / 핵심 포인트
ㅇ Service/Ingress 리소스 분리 원리를 이해하고 적용
ㅇ 각 Kibana 인스턴스가 독립적인 Elasticsearch URL 및 도메인과 연결되는 구조 확립
ㅇ 반복 가능한 YAML 템플릿으로 손쉽게 배포 가능한 환경 제공
ㅁ Ingress Host 매칭 핵심 기술
ㅇ Ingress 리소스의 spec.rules[].host는 클라이언트 HTTP Host 헤더와 매칭
ㅇ 각 도메인별(host) 라우팅 규칙을 통해 동일 네임스페이스·동일 포트 환경에서도 다른 서비스로 트래픽 분리
ㅇ Ingress에서 backend 서비스명과 포트를 지정하면, 해당 서비스가 selector를 통해 연결된 Kibana Pod로 트래픽 전달
ㅇ 결과: kibana1.example.com, kibana2.example.com 등 도메인별 완전 분리된 Kibana 서비스 운영 가능
ㅇ NGINX Ingress Controller 기준 → Host 헤더와 rules.host 값이 정확히 일치해야 해당 backend 서비스로 전달
ㅇ 주의: 와일드카드 호스트(*.example.com)는 단일 DNS 레이블만 가능
ㅁ 실제 구현 (예시 코드)
ㅇ Deployment: Kibana 컨테이너 + login-proxy 사이드카, 각기 다른 ELASTICSEARCH_HOSTS 환경변수 지정
ㅇ Service: 라벨을 기반으로 Kibana Pod 선택
ㅇ Ingress: 도메인(host) 규칙과 backend 서비스 매핑
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: kibana1-ingress
namespace: kibana
labels:
app: kibana1-worker1 #관리 목적의 태그. Service/Deployment와 구분되는 식별자.
spec:
ingressClassName: nginx # 어떤 Ingress Controller가 이 규칙을 처리할지 지정
rules:
- host: kibana1.example.com #외부에서 들어오는 도메인 이름으로
http:
paths:
- path: / #path 규칙으로 매칭 -> 모든 경로를 매칭
pathType: Prefix
backend:
service:
name: kibana1-service
port:
number: 80
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: kibana2-ingress
namespace: kibana
spec:
ingressClassName: nginx
rules:
- host: kibana2.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: kibana2-service
port:
number: 80
ㅇ Ingress는 "도메인 이름 + 경로 규칙"을 보고 요청을 어떤 Service로 라우팅할지 결정한다.
ㅇ 따라서 동일 네임스페이스에 여러 Ingress가 있어도, host 값만 다르면 요청이 올바른 서비스로 분리된다.
ㅁ 중간 정리
ㅇ Service 및 Ingress 이름을 분리하면 동일 포트 충돌 없이 다중 Kibana 운영 가능
ㅇ Ingress Host 매칭 원리 덕분에 도메인 기반 라우팅이 가능 → 관리 편의성과 확장성 강화
ㅇ 리소스 네이밍 규칙을 명확히 하여 혼선을 줄이는 것이 핵심 관리 포인트
ㅁ 마무리
이번 구조를 적용하면 여러 Kibana 인스턴스를 한 네임스페이스에서 효율적으로 운영 가능하게 되었다.
YAML 템플릿을 재사용해 손쉽게 배포/유지보수가 가능하며, 운영 효율성이 크게 향상되었다.
ㅁ 함께 보면 좋은 사이트
ㅇ kubernetes 공식문서 > ingress > 호스트네임 와일드카드
ㄴ Ingress 특징을 잘 설명
1. HTTP/HTTPS 을 활용한 경로 기반, 호스트 기반의 고급 라우팅 가능
2. 카나리 배포 지원
3. SSL/TLS 종료 지원
'Kubernetes > Infra작업' 카테고리의 다른 글
| [kubernetes] kubectl 설치 또는 업데이트 (0) | 2022.10.23 |
|---|---|
| [kubernetes] Kubernetes 스키마를 검증하기 위한 방법 (0) | 2022.09.22 |
| [kubernetes] MongoDB 환경 구축 (2) | 2022.08.24 |
| [kubernetes] 외부 IP 주소를 노출하여 클러스터의 애플리케이션에 접속하기 (7) | 2022.08.01 |
| [kubernetes] Elasticsearch Data 노드 메모리 증설 (0) | 2022.07.14 |
