Python Web Framework 중에서 간단한 API 서버를 만들기엔 Flask 같은 경량화 프레임워크가 적합합니다. app.py는 API 서버의 간단한 엔드포인트를 하나 구현하여 문자열을 리턴하는 어플리케이션을 작성했습니다.
mychart 안에는 helm chart로 동적 렌더링을 할수 있는 구조로 구성했으며 시간 관계상 image name만 렌더링 해두었습니다.
도커파일은 Python과 FLASK를 설치 하는 파일을 작성했고 CMD는 추가 인자로 명령어를 덮어쓸 수 있지만, ENTRYPOINT로 설정한 명령어는 컨테이너 실행 시 추가 인자로 덮어쓸 수 없기 때문에 테스트용으로는 CMD를 사용하여 docker run 명령어 옵션으로 추가적인 옵션들을 주면서 빌드 테스트를 한다. (예를 들어 5000번 포트가 이미 사용중이라) docker run -p 로 5001번 포트를 오픈하는 경우? 기본적으로는 ENTRYPOINT 명령어는 컨테이너가 시작될 때 필수적으로 특정 명령을 실행해야 하는 경우에 적합하다.
istio를 사용한 이유는 NGINX ingress는 보다 검증된 솔루션이지만 원시적인 로드밸런싱과 라우팅에 초점을 맞춘 엔터프라이즈 기업들에 적합하다고 생각한다. 또한 콘텐츠 전송이나 워크로드의 성능의 최적화가 무엇보다 중요한 업무 특성상 사용하는것이 바람직하다.
반면 istio는 가장 큰 차이점이 Envoy 사이드카를 매개체로 통신을 한다는 점이다. 이를 통해 서비스 메시를 구성하여 모니터링,보안,기타 공통적으로 필요한 작업들을 수행할수 있으며, NGINX 컨트롤러 와 비교적 고급적인 기능들을 제공한다. 특히, 트래픽 관리 / 보안 기능 / 옵저버빌리티적으로 보다 자세한 지표와 추적을 제공할수 있다. 또한 Gateway + VirtualService + EnvoyFilter 등 YAML 파일 작성을 통해 트래픽 관리와 보안적인 관리를 워크로드 어플리케이션의 코드 수정 없이 구현할수 있다는 점이 가장 큰 장점인것 같다.
2-1. 서로 다른 VPC 상의 서비스가 통신하기 위해서는 VPC Peering 또는 TGW를 사용하여 통신할수 있습니다. TGW를 사용했을 경우 보다 단순한 구조로 확장 가능한 아키텍처를 구성할수 있으며 AWS 이외에도 ON-prem의 VPN 네트워크 또는 Direct Connect 방식으로도 다른 서비스와도 TGW를 통해 통신할수 있습니다.
하지만, 배포하려는 서비스의 규모와 특성을 고려하여 VPC를 어떻게 연결할지에 대한 방법에 대해서는 조금 더 고려해봐야 합니다. 중앙 관리형으로 TGW를 관리할 경우 그에 대한 이점도 있지만 비용 또는 대역폭의 제한이 문제가 되는 경우가 있을수 있습니다. 단순한 통신만을 위하여 TGW를 고려하는것은 상황에 맞지 않을수 있다. VPC 10개 정도 되는 소규모 연결에서는 VPC Peering이 유리하다고 생각한다.
2-2. AWS Transit Gateway와 프라이빗 NAT 게이트웨이를 함께 사용하여 CIDR 블록이 겹치는 두 VPC 간에 프라이빗 통신을 설정 할수 있습니다. 예를 들어, 동일한 대역으로 2개 VPC를 생성하였다면, 해당 VPC안의 서브넷 중 TGW와 연결할 서브넷은 IP를 중복하지 않게 구성해야 하지만, TGW와 연결하지 않을 서브넷은 NAT 게이트웨이를 통해서 통신하게 라우팅 테이블을 구성 한다면 통신 하게 만들수 있다.
NAT게이트웨이를 통해서 통신을 하게끔 라우팅 설정을 하면 Source IP가 NAT GW의 아이피로 통신 하기 때문에, 아이피가 중복되는 대역에서도 통신이 가능하다.