Update README

[jihoon-seo]

• 두 파일을 추가했습니다.
  • cb-operator의 Docker Compose 모드를 이용한 Cloud-Barista 설치&실행 가이드
  • cb-operator의 Kubernetes 모드를 이용한 Cloud-Barista 설치&실행 가이드
• repo root 의 README.md 파일에서는 'Cloud-Barista 실행 환경에 따른 모드 선택 가이드' 와 각 가이드로의 링크를 제공하도록 변경했습니다.

[jihoon-seo]

@powerkimhub

• 말씀하신 사항들을 반영했습니다. (변경사항 확인)

[jihoon-seo]

@powerkimhub 꼼꼼한 확인 감사합니다.

Table format이 깨지고 있습니다. 확인이 필요해보입니다.

• 수정했습니다.
  • https://github.com/cloud-barista/cb-operator/blob/6193a74ed4e8f92d893b4047af58ea5542fb2113/docs/cb-operator-docker-compose-mode.md
  • https://github.com/cloud-barista/cb-operator/blob/6193a74ed4e8f92d893b4047af58ea5542fb2113/docs/cb-operator-k8s-mode.md

---

Kubernetes의 경우 Port를 Compose 버전과 동일하게 할 수는 없는지요?

• 앱 노출을 위해 서비스 이용하기 에 따르면 다음과 같은 K8s Svc들이 있습니다.
  • ClusterIP (기본값) - 클러스터 내에서 내부 IP 에 대해 서비스를 노출해준다. 이 방식은 오직 클러스터 내에서만 서비스가 접근될 수 있도록 해준다.
  • NodePort - NAT가 이용되는 클러스터 내에서 각각 선택된 노드들의 동일한 포트에 서비스를 노출시켜준다. <NodeIP>:<NodePort>를 이용하여 클러스터 외부로부터 서비스가 접근할 수 있도록 해준다. ClusterIP의 상위 집합이다.
  • LoadBalancer - (지원 가능한 경우) 기존 클라우드에서 외부용 로드밸런서를 생성하고 서비스에 고정된 공인 IP를 할당해준다. NodePort의 상위 집합이다.
  • ExternalName - 이름으로 CNAME 레코드를 반환함으로써 임의의 이름(스펙에서 externalName으로 명시)을 이용하여 서비스를 노출시켜준다. 프록시는 사용되지 않는다. 이 방식은 kube-dns 버전 1.7 이상에서 지원 가능하다.

---

• ExternalName: 지금의 경우에 필요한 것과는 다른 것으로 보입니다. (참고: https://bcho.tistory.com/1262)
• LoadBalancer: AWS, GCP 등에서 SaaS 로 제공하는 LB를 연결하는 것입니다. [임의의 CB 사용자가 cb-operator 를 통해 CB를 실행하는 환경]이 SaaS LB 이용 가능한 환경이라고 보장할 수 없고 또한 SaaS LB는 유료 서비스라서 이를 통해 Svc들을 expose 하는 것은 현재 상황에서는 무리가 있을 것으로 보입니다.
• 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 명령을 사용할 수도 있겠습니다만, 개발/테스트 용으로는 적합할 수 있어도 서비스를 일반적으로 제공하는 방법으로는 적합하지 않을 수도 있습니다.

---

[안]

1. NodePort 서비스가 이용하는 포트의 범위를 SP, TB 등에서 사용하고 있는 포트를 포함하도록 지정 (가능한지는 모르겠습니다)
2. cb-operator run 명령 시퀀스에 kubectl port-forward 명령을 통해 CB 구성요소 Pod들을 expose 하는 단계를 추가

---

이번 PR 말고, 다음번에는 kube~ mode와 compose mode 가이드가 많은 부분 중복되고 있는 데, 중복되는 부분을 하나로 공유 할수 있는 방법으로 개선하면 좋을 듯합니다.

맞습니다. 중복되는 부분을 스니펫으로 만들고 include (embed) 할 수 있으면 좋은데 (스니펫 예시) 찾아 보니 GitHub README 에는 이러한 기능을 사용할 수 없는 것 같습니다.

• https://stackoverflow.com/questions/11622509/github-how-to-embed-a-gist-into-readme-md/32030995
• https://github.com/github/markup/issues/199

embed 가 불가능하다면, 다음으로는, 중복 부분을 별도의 파일로 분리하고 그 파일로의 링크를 거는 방법이 있는데요, 이것은 유저의 context switching 을 유발합니다.

위의 사항을 고려하여, 다음 중에서 결정하여 적용하면 될 것 같습니다.

1. 현행 유지
   • 단점: 중복 부분 많음, 수정이 필요한 경우 양쪽 수정 필요 등...
2. 중복 부분을 별도의 파일로 분리하고 그 파일로의 링크를 걸기
   • 단점: 유저의 context switching 을 유발
3. 다른 방법을 발굴

[powerkimhub]

[안]

NodePort 서비스가 이용하는 포트의 범위를 SP, TB 등에서 사용하고 있는 포트를 포함하도록 지정 (가능한지는 모르겠습니다) cb-operator run 명령 시퀀스에 kubectl port-forward 명령을 통해 CB 구성요소 Pod들을 expose 하는 단계를 추가

• review 의견을 드리고 나서 보니, 현재 PR 범위를 너무 벗어나게 되었네요^^
• Framework Port들이 Kubernetes 밖에서 보이는 게 맞는지?
• GW로 외부 Port를 설정(1024와 같은)하고 FW들의 origin 포트는 현재처럼(31024 등) 하면 되는지?
• 등을 추후에 별도 이슈나 디스커션으로 추진하는 것으로 분리하는 게 좋을 듯합니다.

[jihoon-seo]

제가 merge 하겠습니다.. ^^