Ingress Nginx Controller를 internal 설정으로 설치를 한 상태였다.
kubectl get svc
Ingress Nginx Controller를 조회해봤을 때,
ingress-nginx-controller (이건 external이라고 앞으로 부르겠다)
ingress-nginx-controller-internal
이렇게, internal 용으로도 추가로 생성이 제대로 되어 있었다.
- A의 도메인으로는 아무 네트워크를 사용해도 쉽게 접속이 된다.
- B의 도메인으로는 내부망으로만 접속이 된다.
- A과 B이 모두 가르키는 곳은 공통적으로 C service이다.
A는 External Ingress Nginx Controller를 통해 접속하는 것이고,
B는 Internal Ingress Nginx Controller를 통해 접속하는 것이다.
Ingress 규칙에서 각각 A, B는 모두 backend로 연결되는 service가 C로 동일하게 설정되어 있었다다.
고로 .. A, B는 Ingress 규칙이 완전히 똑같았다. (Ingress 이름만 제외하고는)
여기서부터 헷갈리기 시작했던 것이, ingress를 각각 describe해서 보니 2개 다 완전히 내용이 똑같았는데, Address 부분이 external ingress nginx controller의 IP 주소로 똑같이 고정되어 있었다.
kubectl describe ingress A가-연결된-ingress-이름
kubectl describe ingress B가-연결된-ingress-이름
A는 External 연결이니까 그렇다치는데, B는 ingress nginx controller internal의 IP 주소로 고정되어 보여야하는 것이 아닌가? 라는 생각을 했고, 이것 때문에 모든 것들이 갑자기 다 헷갈려지기 시작했다.
그래서 A, B에 대한 nslookup을 해서 address를 조회해보니 이 부분은 내 예상대로 A의 address는 ingress nginx controller external의 IP 주소였고, B의 address는 ingress nginx controller internal의 IP 주소였다.
위와 같은 과정을 겪다 보니까 내가 뭘 하고 있는지 나도 모르겠는 지경에 왔다. 근데 답은 너무 단순했다. 그냥 내가 엄청 헷갈렸던 것 같은데..
internal ingress nginx를 쓸 지 external ingress nginx를 쓸 지는 순전히 작업자가 무슨 ip로 도메인을 등록하느냐에 달린 거다. 그리고 이 경우는 B에 특별히 ingress nginx controller internal의 IP를 등록해준 것 뿐인 것이다.

DNS 등록을 내가 하지 않았던 환경이어서 이렇게 단순한 거를 완전 뱅뱅 돌고 돈 것이다.. internal용으로 생성된 ingress nginx controller를 고를 지, 아닌 것을 고를 지.. 대체 어떤 manifest에서 셋업이 되었을까? 하면서 엄청 파일 뒤져보고 구글링했었는데..
얕은 지식과 섞이는 바람에 나 혼자 대차게 헛구글링만 한거다~
그래도 하나 얻은 건 있다.

2개가 나란히 생겼을 때 ingress object는 기본적으로 external을 향하고 있다는 것 정도는 알게 됐다. 그래서 아마 처음에 ingress를 2개 동시에 조회했을 때 모두 external에 대한 ip 주소만 뜨지 않았을까?
그래서 이것의 장점은, 새로운 ingress controller를 설치하지 않고 1개로 여러가지 방향으로 운용할 수 있다.. 인 것 같다. 기초가 항상 중요하다는 걸 또 배운다. 자꾸 삽질 블로그가 되는 것 같은데