service/ k8s의 dns구성, service type> externalName

## 쿠버네티스 환경에서 도메인서버

 

# 일단 뜯어볼까?

쿠버네티스 환경에서는 도메인으로 서로 통신 할 수 있다.

도메인 서버를 확인하려면,

kubectl get pods --all-namespace -o wide

모든 네임스페이스에서 모든 pod를 확인해보았다.

저기 보이는 core dns가 쿠버네티스 환경에서 dns서버 역할을 하는것이다.

난 master node에 있을줄 알았는데 worker노드에도 있는것같음..

참고로 얘는 kube-system 네임스페이스에서 동작한다.

여기서 보이는 coredns파드들은 또한 clusterIP서비스로 묶이는데, 이게 바로 kube-dns서비스이다.

kubectl get service -n kube-system

이 kube-dns서비스는 clusterIP타입이고, 위에 쓴 coredns파드들의 단일진입점을 만들어준다.

kubectl describe service kube-dns -n kube-system

엔드포인트가 위에 coredns파드들의 아이피와 같다.

 

 

 

# pod내에서 dns서버를 확인해보자~

일단 난 pod를 만들때 네트워크 관련 툴들을 사용하기위해서 praqma/network-multitool라는 이미지로 만들었다.

kubectl run test-pod --image=praqma/network-multitool -it /bin/bash

생성과 동시에 exec로 접속했다.

여기서 /etc/resolv.conf파일을 보자.

cat /etc/resolve.conf

네임서버가 10.96.0.10으로 되어있다.

즉 아까 우리가 확인헀던 kube-dns의 clusterIP이다.

 

 

 

# 외부로는 핑이 안통하는거 아냐?

나도 궁금했는데 ping을 외부로 쳐보니 됐다.

ping 8.8.8.8

coredns가 가장 먼저 검색하는 dns서버가 되는것같다.

 

 

 

# pod들에서 각 pod들에 통신하는 도메인.

일단 양식은 이렇다.

<pod의 IP주소 -으로 쪼개야함>.<pod가 속한 네임스페이스>.pod.cluster.local

일단 난 default 네임스페이스가 아니라, muzzi-house네임스페이스에서 생성한 pod에 연결할 예정이다.

 

일단 아무 이미지로 pod를 만들어주자.

네트워크 명령어를 쓸거라 위에서 썼던 praqma/network-multitool이미지로 만들었다.

kubectl run test-pod --image=praqma/network-multitool -it /bin/bash

사실 아까 만든 test-pod를 그대로 썼다.

접속후에 저 양식에 맞는 양식에 맞게 curl 명령어를 쳐보자.

 

curl 10-244-10-173.muzzi-house.pod.cluster.local

 

잘 연결된걸 볼 수 있다.

 

 

# service에도 연결된다~

양식은 아래와 같다.

<서비스 이름>.<pod가 속한 네임스페이스>.svc.cluster.local

이게 양식이다.

아까 만들어둔 pod들 리스트를 다시 보면, 

nginx-deployment라는 이름의 deployment로 세개의 pod를 띄웠고,

마스터노드에서 서비스를 확인하면, 

my-service라는 서비스만 떠있다. 물론 이 서비스를 위의 deployment pod들에 라벨링 해놨다.

kubectl describe service my-service

사실 저기에 statefulset-0~2까지 다 연결해놔서 총 여섯개가 있다.

암튼 저렇게 연결한게 맞다.

 

그리고 다시 test-pod에 exec로 접속하자.

그럼 이 서비스에 위에 양식에 맞춰 curl명령을 날려보자 ㅎ

 

 curl my-service.muzzi-house.svc.cluster.local

잘 연결된걸 볼 수 있다.

 

 

# 이 양식이 /etc/resolv.conf에도 있다..

뭐 사실 요청할때 저걸 붙여줘서 도메인요청한다는데 모르곘고.. 양식까먹으면 저기서 찾자.

참고로 네임스페이스 이름은 저기서 확인 되지만,  service name은 pod내에서 알 수 있는지 모르겠다.

 

 

 

 

 

 

 

 

 

 

## externalName 서비스

# 개념

얘는 서비스이긴 한데 도메인을 서비스로 제공하는거다.

그림으로 설명하자면,

걍 밑에 분홍글씨로 적어놨듯이, pod들에서 external name service의 서비스이름과 해당 서비스가있는 네임스페이스를 양식에 맞춰서 넣은게 도메인이되고 이 도메인은 이 external service에 연결된 외부도메인으로 연결해준다.

뭔가 도메인계의 프록시같은 느낌적인 느낌

 

# yaml양식

apiVersion: v1
kind: Service
metadata:
  name: muzzi-ex-service
  namespace: muzzi-house
spec:
  type: ExternalName
  externalName: google.com

얘는 양식이 존나 단순한데, spec필드에 type필드에 ExternalName으로 정해주고, externalName에 연결할 외부도메인을 적어주면 된다.

 

 

 

 

# 테스트 해볼까?

apiVersion: v1
kind: Service
metadata:
  name: muzzi-ex-service
  namespace: muzzi-house
spec:
  type: ExternalName
  externalName: google.com

kubectl create -f test-ex-name-svc.yaml

잘 만들어졌다.

 

그럼 이제 아까 만들어 놓은 test-pod에 접속해보자.

kubectl exec -it test-pod -- /bin/bash

 

접속후에 아까 만든 양식에 이 서비스로해서 curl을 날려보자.

 

curl <external name service이름>.<네임스페이스>.svc.cluster.local

여기에 갖다 넣으면,

curl muzzi-ex-service.muzzi-house.svc.cluster.local

이렇게 된다.

커맨드를 쳐보면, 

404가 뜨긴했지만.. 구글은 맞다.

암튼 잘 치환되서 접속됐다고 한다...

 

 

# 그냥 curl google.com으로는 안되니?

google.com만 썼을경우

www.google.com을 썼을경우

둘다 뭔가 되는것같은데 위에 external name service썻을때랑은 좀 틀리다.

뭐가다른지 모르겠는데.. 어차피 도메인으로 접속할거면 딱히 필요없지 않나 싶었다.

gpt한테 물어봤는데,

1. 외부 서비스 접근:
   • 클러스터 외부에 위치한 서비스에 접근할 때 사용합니다. 예를 들어, 외부 데이터베이스, 외부 웹 서비스, 또는 다른 클러스터 등을 가리킬 수 있습니다.
2. 호스트 이름 사용:
   • ExternalName Service는 호스트 이름을 사용하여 외부 서비스에 연결합니다. IP 주소가 아니라 호스트 이름을 사용하는 것은 관리상의 유연성을 제공하며, IP 주소가 변경되더라도 호스트 이름을 통해 서비스에 계속 접근할 수 있습니다.
3. DNS를 통한 해결:
   • ExternalName Service는 클러스터 내에서 DNS 조회를 통해 호스트 이름을 해결합니다. 이는 다른 서비스들이 클러스터 내에서 일반적인 DNS 규칙을 따르며, 외부 서비스도 마치 내부 서비스처럼 취급할 수 있게 합니다.

뭐 이렇단다. 사실 잘 모르겠다.

 

 

 

 

# 생각..

뇌피셜로 생각해보자면 external name service를 만들고, 예를들어 도메인을 가지고있는 db나 api서버를 만들었을때, 이 도메인이 바뀌거나 뭐 특이해질경우 각 pod들에 있는 프로세스가 도메인으로 이곳들에 접근할때, 하나하나 다 바꿔줘야할것이다.

하지만 external name service로 도메인을 만들고 각 pod들의 도메인관련 프로세스들을 이 서비스의 dns로 통신하게 했다면, 이 external name service의 externalName필드만 수정해주면 될것이다.

뭐 대충 생각해봐서..

 

 

 

# 참조

K8s Headless Service, 왜 필요한가

 

쿠버네티스 입문 - 10 - 쿠버네티스 DNS