External Name 서비스와 CoreDNS를 이용한 크로스 네임스페이스

오랜만에 글좀 정리하러 왔음

쿠버네티스에 스파이크 트래픽이 들어오면, 이상하게 한쪽 파드로만 쏠리는 증상이 있댜

뭐지 하면서 고민해봤댜

 

제목을 보고, 내가 nginx ingress 글 자주 올리는거보면 대충 구조 어떤지 글 쓰는 사람들은 알거임.

 

LB (L4) > Nginx_POD > EN_service > POD

왜 이딴 구조로 했냐면, LB가 반드시 1개의 L4 이면서 네임스페이스가 다른 각기 파드로 트래픽을 전달하기 위한 구조로는, 지금 이 방법밖에 내가 못찾았었음.

L7 LB로 크로스네임스페이스 기법 있긴 한데, 나는 지금 환경에서 반드시 L4를 썼어야함.

그래서 Nginx Ingress로 확장시켜온거임.

 

근데 EN_Service 를 보면 알겠지만, 이거 결국 내부적으로는 kube dns 쿼리하는데 있어서 coredns가 반드시 동반됨.

 

이 때 위 구조에서 간혹 문제가 발생함.

일상적이고 점진적인 트래픽인 로드밸런싱이 문제 없는데, 꼭 스파이크성 트래픽에서는 로드밸런싱 못하더라.

 

의심해볼게 딱 두개다.

 

- 캐시?

- TTL?

 

사실 2개 모두 큰 축에선 같은 범주긴 함. 

coredns도 결국 DNS인지라 캐시와 쿼리 설정이 들어감.

 

너님들도 아마 coredns 글 파봤으면 이거 봤을거임.

https://kubernetes.io/ko/docs/tasks/administer-cluster/dns-custom-nameservers/

DNS 서비스 사용자 정의하기

 

그리고 이 부분.

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors
        health {
            lameduck 5s
        }
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
            pods insecure
            fallthrough in-addr.arpa ip6.arpa
            ttl 30
        }
        prometheus :9153
        forward . /etc/resolv.conf
        cache 30
        loop
        reload
        loadbalance
    }

 

각 단어의 자세한 의미는 공홈 들어가서 보셈.

여기서 ttl 30초인데, 이거를 그냥 지워버리면? 그냥 ttl 30초로 디폴트임.

이거 비활성화 하려면 반드시 ttl 0으로 지정해줘야함.

 

ExternalName 쓰면서 스파이크 트래픽 밸런싱 안되면 반드시 의심해봐라 ㅇㅇ