Exposing Pods/Services in Kubernetes mode

[jihoon-seo]

• Related PR: Update README #115

• Framework Port들이 Kubernetes 밖에서 보이는 게 맞는지?
• GW로 외부 Port를 설정(1024와 같은)하고 FW들의 origin 포트는 현재처럼(31024 등) 하면 되는지?

등을 추후에 별도 이슈나 디스커션으로 추진하는 것으로 분리하는 게 좋을 듯합니다.

[jihoon-seo]

CC @powerkimhub

[@jihoon-seo's comment]

주요 엔드포인트들을 다음으로 분류할 수 있습니다.

• REST API 제공 엔드포인트
  • http://{{host}}:1024/spider
  • http://{{host}}:1323/tumblebug
  • http://{{host}}:8080/ladybug
  • http://{{host}}:9090/dragonfly
• Go API 제공 엔드포인트
  • (Spider) http://{{host}}:2048
  • (Tumblebug) http://{{host}}:50252
  • (Dragonfly) http://{{host}}:9999
• 자료 수신을 위한 엔드포인트
  • (Dragonfly) Kafka: 9092
  • (Dragonfly) collector: 8094/udp
  • ...
• 웹 UI 제공 엔드포인트
  • Spider Adminweb: http://{{host}}:1024/spider/adminweb
  • webtool: http://{{host}}:1234
  • API GW Admin: http://{{host}}:8001
  • API GW Grafana: http://{{host}}:3100
  • API GW Jaeger: http://{{host}}:16686
  • ...

---

Q. Framework Port들이 Kubernetes 밖에서 보이는 게 맞는지?
=> 추후 결정이 필요한 사안으로 보입니다.

Q. GW로 외부 Port를 설정(1024와 같은)하고 FW들의 origin 포트는 현재처럼(31024 등) 하면 되는지?
=>

• ClusterIP: 현재 모든 CB 구성요소들은 ClusterIP Svc를 가지며,
  이를 통해 K8s 클러스터 내에서는 (= CB 구성요소 간에는) 저희가 잘 알고 있는 포트 (예: Spider - 1024) 로 통신이 가능합니다.
  다만 K8s 클러스터 외부에서는 이 포트로는 접근이 불가합니다.
• NodePort: K8s 클러스터 외부에서 (예: CB 개발자) CB 구성요소 파드에 접근할 수 있도록 하기 위해
  NodePort 서비스를 이용합니다.
  포트 범위는 기본적으로는 30000-32767 이며 (이 이유로 31024 등의 포트로 개방 중)
  --service-node-port-range 플래그로 지정할 수도 있는데,
  SP, TB 등에서 사용하고 있는 포트를 포함하도록 지정하는 것도 가능한지는 모르겠습니다.
• 이 외에 kubectl port-forward 라는 명령도 있는데, Helm 만으로는 불가능합니다.
  다만, cb-operator 는 kubectl 사용이 가능한 환경에서 동작하는 것을 전제로 하고 있기 때문에
  kubectl port-forward 명령을 사용할 수도 있겠습니다만,
  개발/테스트 용으로는 적합할 수 있어도
  서비스를 일반적으로 제공하는 방법으로는 적합하지 않을 수도 있습니다.

엔드포인트 종류에 따라 다음과 같은 안이 있습니다.

• REST API 제공 엔드포인트
  • 현재도 K8s 클러스터 내에서는 (= CB 구성요소 간에는) 저희가 잘 알고 있는 포트 (예: Spider - 1024) 로 통신이 가능합니다.
  • 클러스터 외부로의 노출 방안
    • (현재 상황) NodePort 서비스를 이용하여 30000-32767 범위의 포트로 노출
    • NodePort 서비스를 이용하되 포트 범위를 변경하여 각 프레임워크가 사용하던 포트번호 그대로 노출 (가능한지는 모르겠습니다)
    • cb-operator run 명령 시퀀스에
      kubectl port-forward 명령을 통해 CB 구성요소 Pod들을 expose 하는 단계를 추가
    • 개별 프레임워크의 엔드포인트는 노출하지 않고, API GW 엔드포인트만 노출
• Go API 제공 엔드포인트
  • 현재 CB에는 Go API 에 대해 REST API GW 와 같은 엔티티가 없으므로,
    각 프레임워크의 Go API 엔드포인트를 개별적으로 expose 해야 할 것으로 보입니다.
• 자료 수신을 위한 엔드포인트
  • 현 상황 예시: CB 구성요소 중 kafka는 Docker Compose 모드에서는 9092, Kubernetes 모드에서는 32000 포트를 열고 있습니다.
  • CB 구성요소 (예: collector) 가 외부 클라이언트 (예: CB-Dragonfly agent) 와 주고받는 데이터가 JSON 이라면
    API GW 를 통할 수도 있습니다.
    다만 API GW 는 내/외부에서 시작된 API 요청을 처리하는 것을 가정하고 있으며,
    예를 들어 collector 데이터도 API GW 를 거치도록 하면 이 호출들에 대해서도 로깅, 모니터링, 트레이싱 등이 동작하기 때문에
    collector 데이터 등은 API GW 를 통하지 않도록 하는 것이 적절할 수 있습니다.
  • 주고받는 데이터가 JSON 이 아닌 경우, API GW를 통할 수 없기 때문에, 위의 kafka 예시처럼 독립적인 포트를 expose 해야 합니다.
• 웹 UI 제공 엔드포인트
  • 주고받는 데이터가 JSON 이 아닌 경우, API GW를 통할 수 없기 때문에, 독립적인 포트를 expose 해야 합니다.