DNS 프록시는 이스티오 사이드카의 새 구성 요소로, 이 절의 목표는 DNS 프록시가 클러스터 내 서비스의 호스트네임을 해석하는 방법을 이해시키는 것이다.
1️⃣ DNS 프록시가 클러스터 호스트네임을 해석하는 방법
클러스터 내 호스트네임을 해석하는 데 관련된 단계를 모두 이해하기 위해 webapp.istioinaction 호스트네임이 해석되는 구체적인 과정을 따라가볼 것이다.
1) 클라이언트는 webapp.istioinaction 을 해석하기 위해 DNS 쿼리를 만든다.
2) 운영체제가 DNS 해석을 처리한다. 운영체제는 먼저 hosts 파일에 정의된 항목 중에 호스트네임과 일치하는 것이 있는지 확인한다. 일치하는 항목이 없으면 요청을 기본 DNS 해석기(resolver)로 전달한다.
3) 우분투의 기본 DNS 해석기는 systemd-resolverd(로컬 애플리케이션에 호스트네임 해석을 제공하는 시스템 서비스)이며, 루프백 주소 127.0.0.53에서 53 포트를 리스닝한다. 그러나 요청은 절대로 거기에 도달하지 않는데, 요청을 DNS 프록시로 리다이렉트하도록 istio-agent 가 Iptables 규칙을 설정하기 때문이다.
4) DNS 프록시에는 서비스 메시 내에서 알려진 서비스를 해석하기 위한 항목들이 포함돼 있다. 호스트네임이 일치하면 해석되며, webapp.istioinaction이 그런 경우다. 컨트롤 플레인이 NDS로 설정하기 때문이다.
5) 그렇지 않고 클러스터 서비스가 아니면 DNS 프록시가 물러나 resolv.conf 파일에 명시된 네임서버로 넘기며, 호스트네임은 여기서 해석되거나 해석하는 데 실패한다.
각 단계를 검증해보자.
systemd-resolverd(127.0.0.53 에서 수신 중인)로 향하는 DNS 퀴리를 Iptables 규칙이 로컬호스트의 포트 15053에서 UDP 및 TCP 패킷을 수신 중인 DNS 프록시로 리다이렉트하는 것부터 확인해보자.
# Iptables 규칙 확인 : proxyConfig.proxyMetadata ISTIO_META_DNS_CAPTURE="true" 설정 시 아래 규칙 추가됨
root@forum-vm:~# iptables-save | grep 'to-ports 15053'
-A OUTPUT -d 127.0.0.53/32 -p udp -m udp --dport 53 -j REDIRECT --to-ports 15053
-A ISTIO_OUTPUT -d 127.0.0.53/32 -p tcp -m tcp --dport 53 -j REDIRECT --to-ports 15053
DNS 퀴리 트래픽이 DNS 프록시 포트로 리다이렉트되는 것을 볼 수 있다. 포트 정보 확인하자.
# tcp, udp 를 127.0.0.1 에 port 15053 에서 이스티오 에이전트(pilot-agent)가 DNS 프록시 처리 확인
root@forum-vm:~# netstat -ltunp | egrep 'PID|15053'
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:15053 0.0.0.0:* LISTEN 8881/pilot-agent
udp 0 0 127.0.0.1:15053 0.0.0.0:* 8881/pilot-agent
# 해당 주소로 DNS 쿼리
root@forum-vm:~# dig +short @localhost -p 15053 webapp.istioinaction
10.10.200.67
root@forum-vm:~# dig +short @localhost -p 15053 catalog.istioinaction
10.10.200.42
root@forum-vm:~# dig +short @localhost -p 15053 forum.forum-services
10.10.200.150
예상대로 15053 포트에서 수신 중인 pilot-agent 가 FQDN 을 해석한다. 이번 예제는 요청을 해석하기 위해 DNS 서버를 직접 지정했는데, 그럴 필요가 없다. 애플리케이션이 호스트네임을 해석할 때는 Iptable 규칙에 따라 요청이 자동으로 이 포트로 리다이렉트된다. 다음으로는 컨트롤 플레인이 DNS 프록시에 어떤 항목을 설정했는지 알아보자.
2️⃣ DNS 프록시가 인식하는 호스트네임은 무엇인가?
DNS 프록시가 인식하는 항목을 모두 찾으려면 istiod의 디버그 엔드포인트를 사용해야 한다. 디버그 엔드포인트를 사용하면 모든 워크로드의 사이드카에 대한 NDS 설정을 쿼리할 수 있다.
(⎈|default:N/A) root@k3s-s:~# istioctl proxy-status | awk '{print $1}'
NAME
catalog-77fdb4997c-jrr9d.istioinaction
forum-vm.forum-services
istio-eastwestgateway-86f6cb4699-h795g.istio-system
istio-ingressgateway-7b7ccd6454-mxllv.istio-system
webapp-684c568c59-w4mv9.istioinaction
# NDS 설정을 가져올 때 proxyID 파라미터에 이름을 사용한다.
(⎈|default:N/A) root@k3s-s:~# kubectl -n istio-system exec deploy/istiod -- curl -Ls "localhost:8080/debug/ndsz?proxyID=forum-vm.forum-services" | jq
{
"resource": {
"@type": "type.googleapis.com/istio.networking.nds.v1.NameTable",
"table": {
"catalog.istioinaction.svc.cluster.local": {
"ips": [
"10.10.200.42"
],
"registry": "Kubernetes",
"shortname": "catalog",
"namespace": "istioinaction"
},
"forum.forum-services.svc.cluster.local": {
"ips": [
"10.10.200.150"
],
"registry": "Kubernetes",
"shortname": "forum",
"namespace": "forum-services"
},
"grafana.istio-system.svc.cluster.local": {
"ips": [
"10.10.200.182"
],
"registry": "Kubernetes",
"shortname": "grafana",
"namespace": "istio-system"
},
"istio-eastwestgateway.istio-system.svc.cluster.local": {
"ips": [
"10.10.200.112"
],
"registry": "Kubernetes",
"shortname": "istio-eastwestgateway",
"namespace": "istio-system"
},
"istio-ingressgateway.istio-system.svc.cluster.local": {
"ips": [
"10.10.200.187"
],
"registry": "Kubernetes",
"shortname": "istio-ingressgateway",
"namespace": "istio-system"
},
"istiod.istio-system.svc.cluster.local": {
"ips": [
"10.10.200.72"
],
"registry": "Kubernetes",
"shortname": "istiod",
"namespace": "istio-system"
},
"jaeger-collector.istio-system.svc.cluster.local": {
"ips": [
"10.10.200.191"
],
"registry": "Kubernetes",
"shortname": "jaeger-collector",
"namespace": "istio-system"
},
"kiali.istio-system.svc.cluster.local": {
"ips": [
"10.10.200.86"
],
"registry": "Kubernetes",
"shortname": "kiali",
"namespace": "istio-system"
},
"kube-dns.kube-system.svc.cluster.local": {
"ips": [
"10.10.200.10"
],
"registry": "Kubernetes",
"shortname": "kube-dns",
"namespace": "kube-system"
},
"kubernetes.default.svc.cluster.local": {
"ips": [
"10.10.200.1"
],
"registry": "Kubernetes",
"shortname": "kubernetes",
"namespace": "default"
},
"metrics-server.kube-system.svc.cluster.local": {
"ips": [
"10.10.200.76"
],
"registry": "Kubernetes",
"shortname": "metrics-server",
"namespace": "kube-system"
},
"prometheus.istio-system.svc.cluster.local": {
"ips": [
"10.10.200.21"
],
"registry": "Kubernetes",
"shortname": "prometheus",
"namespace": "istio-system"
},
"tracing.istio-system.svc.cluster.local": {
"ips": [
"10.10.200.18"
],
"registry": "Kubernetes",
"shortname": "tracing",
"namespace": "istio-system"
},
"webapp.istioinaction.svc.cluster.local": {
"ips": [
"10.10.200.67"
],
"registry": "Kubernetes",
"shortname": "webapp",
"namespace": "istioinaction"
},
"zipkin.istio-system.svc.cluster.local": {
"ips": [
"10.10.200.41"
],
"registry": "Kubernetes",
"shortname": "zipkin",
"namespace": "istio-system"
}
}
}
}
요약된 출력은 webapp 서비스를 보여주는데, webapp.istioinaction.svc.cluster.local 라는 이름에 매핑된 IP 주소 목록을 포함하고 있다. 출력을 살펴보면 webapp.istioinaction 같은 짧은 변형 variation 이 없다는 것을 확인할 수 있다. istio-agent 가 NDS 설정을 받을 때, 다음과 같이 쿠버네티스 클러스터에서 설정될 모든 변형을 만들어낸다. 그리고 모두 동일한 IP 목록 주소, 즉, 앞 선 목록에서 봤던 10.10.200.67로 해석된다.
(⎈|default:N/A) root@k3s-s:~# istioctl proxy-config route deploy/webapp.istioinaction --name 80 -o json
...
"name": "webapp.istioinaction.svc.cluster.local:80",
"domains": [
"webapp.istioinaction.svc.cluster.local",
"webapp",
"webapp.istioinaction.svc",
"webapp.istioinaction",
"10.10.200.67"
...
핵심은 다음과 같다. DNS 프록시는 istiod가 알고 있는 서비스들로 설정된다. istio-agent는 호스트네임의 더 짧은 변형들을 생성한다. 쿠버네티스 내의 경험과 일치시키기 위함이다. 이런 DNS 프록시 내의 레코드는 클러스터 내 서비스 호스트네임을 해석하는 데 사용된다. 클러스터가 아닌 호스트네임(퍼블릭 도메인 같은)쿼리는 머신에서 처음 설정한 네임서버로 넘어간다.
3️⃣ 에이전트 동작 커스터마이징
에이전트는 로그 내용, 로그 형식, 에이전트가 인증서를 발급받기 위해 요청할 인증서 수명 설정 같은 동작 등 다양한 설정 선택지가 있다. 예를 들어 두 가지 수정을 하길 원한다고 해보자. 첫 번째, DNS 프록시의 로깅 수준을 debug로 올린다. 두 번째, 인증서 수명을 12시간으로 줄인다. 이는 사이드카용 설정 파일인 /var/lib/istio/envoy/sidecar.env 를 업데이트하면 된다.
root@forum-vm:~# cat /var/lib/istio/envoy/sidecar.env
...
root@forum-vm:~# grep "^[^#]" /var/lib/istio/envoy/sidecar.env # 주석 처리
# 변수 추가
root@forum-vm:~# echo 'ISTIO_AGENT_FLAGS="--log_output_level=dns:debug"' >> /var/lib/istio/envoy/sidecar.env
root@forum-vm:~# echo 'SECRET_TTL="12h0m0s"' >> /var/lib/istio/envoy/sidecar.env
root@forum-vm:~# grep "^[^#]" /var/lib/istio/envoy/sidecar.env
ISTIO_AGENT_FLAGS="--log_output_level=dns:debug"
SECRET_TTL="12h0m0s"
# 변경 사항 적용
root@forum-vm:~# systemctl restart istio# 다음을 디버깅했을 때
root@forum-vm:~# tail -f /var/log/istio/istio.log
...
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version 0; flags: ; udp: 1232
; COOKIE: 5db07e72c6d0807e
;; QUESTION SECTION:
;www.daum.net. IN A
protocol=udp edns=true id=e3c08982-a30c-4d17-b992-f1c76ea89abe
2025-05-31T10:23:15.515415Z debug dns response for hostname "www.daum.net." not found in dns proxy, querying upstream
2025-05-31T10:23:15.517765Z debug dns upstream response for hostname "www.daum.net." : ;; opcode: QUERY, status: NOERROR, id: 63920
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version 0; flags: ; udp: 65494
;; QUESTION SECTION:
;www.daum.net. IN A
;; ANSWER SECTION:
www.daum.net. 79 IN CNAME daum-4vdtymgd.kgslb.com.
daum-4vdtymgd.kgslb.com. 3 IN A 121.53.105.193
...root@forum-vm:~# dig +short @localhost -p 15053 www.daum.net
daum-4vdtymgd.kgslb.com.
121.53.105.193
DNS 프록시에 대한 디버그 로그를 볼 수 있다. 인증서가 로테이션되면 /etc/certs/cert-chain.pem 파일에 저장된 새 인증서의 만료 시간을 검사할 수도 있다. 모든 설정 옵션 목록은 이스티오의 pilot-agent 문서를 참조하자.
pilot-agent
Istio Pilot agent.
istio.io
4️⃣ 메시에서 WorkloadEntry 제거하기
가상머신이 메시에 자동 등록되던 것처럼, 삭제되면 정리된다. AWS 가상머신용 EC2를 삭제하면 된다. 시간이 조금 지난 후, WorkloadEntry 가 정리됐는지 확인하자.
(⎈|default:N/A) root@k3s-s:~# kubectl get workloadentries -A
No resources found
클라우드 네이티브 워크로드의 일시성을 지원하려면 워크로드 항목을 자동으로 삭제하는 것이 자동 등록만큼 중요하다.
✔️ 쿠버네티스 파드와 가상머신을 메시에 통합하는 방법 간의 차이
|
기능
|
쿠버네티스 구현
|
가상머신 구현
|
|
프록시 설치
|
istioctl로 직접 주입하거나 웹훅으로 자동 주입
|
직접 다운로드해 설치
|
|
프록시 설정
|
사이드카 주입 중 완료
|
istioctl을 사용해 WorkloadGroup에서 설정을 생성하고 프록시가 있는 가상머신으로 전송
|
|
워크로드 ID 부트스트랩
|
서비스 어카운트 토큰이 쿠버네티스 메커니즘에 의해 주입
|
서비스 어카운트 토큰을 가상머신으로 수작업으로 전송
|
|
헬스 체크
|
쿠버네티스가 Readiness / Liveness 프로브 수행
|
WorkloadGroup에 Rediness 프로브 설정
|
|
등록
|
쿠버네티스가 처리
|
WorkloadGroup의 구성원으로 가상머신 자동 등록
|
|
DNS 해석
|
클러스터 내 FQDN을 해석하는 데 DNS 서버 사용, DNS 프록시를 사용할지는 선택 가능
|
istiod가 DNS 프록시를 설정해 FQDN을 해석
|
실제 프로젝트에서는 이때까지 과정을 자동화해야 한다. 가상머신을 메시에 수작업으로 추가하면 메시가 아주 취약해진다. 오늘날의 프로젝트들은 좋은 관행들을 따라 가상머신을 구축 및 배포하는 자동화를 갖추고 있어 보통 패커, 앤서블, 테라폼 같은 도구를 사용한다. 그러나 기존 자동화가 있으면 일거리가 줄어드므로, 애플리케이션에 이스티오의 사이드카를 설치하고 설정과 토큰을 제공하도록 스크립트를 업데이트하기만 하면 된다. 그러면 마침내 가상머신이 메시에 통합된다.
'Istio' 카테고리의 다른 글
| Ambient Mesh (1) (4) | 2025.06.05 |
|---|---|
| Istio Traffic Flow (1) | 2025.05.31 |
| 가상 머신 프로비저닝 (0) | 2025.05.31 |
| 가상머신 인프라 준비하기 (AWS EC2 K3S) (0) | 2025.05.31 |
| 이스티오의 가상머신 지원 (3) | 2025.05.28 |
