AWS 네트워킹 기본 구성 요소
Amazon VPC (virtual private cloud)
- Amazon EKS 클러스터를 배포하는 곳
- 가상 데이터 센터로 AWS 리소스를 시작할 수 있는 AWS cloud 격리된 공간
- Ipv4 주소 범위를 CIDR 블록으로 지정
- 단일 AWS 리전에서 생성
서브넷
- 클러스터를 만들때 지정한다. 서브넷은 컨트롤 플레인과 노드간 통신에 사용하는
탄력적 네트워크를 Amazon EKS 에서 배치하는 곳을 결정합니다. - VPC 생성후 가용역역에 하나 이상의 서브넷이 추가 된다.
- 각 서브넷은 하나의 가용 영역 내에 모두 상주해야한다. 다른 영역으로 확장 불가능
- VPC CIDR의 하위 집합에 속하는 CIDR 블록 지정
- 퍼블릭과 프라이빗 서브넷으로 나누어진다.
- 트래픽이 인터넷 게이트웨이로 라우팅 된다면 퍼블릭
- 프라이빗은 NAT 게이트 웨이를 사용하여 인터넷/다른AWS서비스에 접근할 수 있다.
VPC와 서브넷을 나눌때는 CIDR를 신중하게 고려해야한다. 할당 가능한 IP 개수가 부족해지면 Pod 생성이 안되며 IP가 부족함을 해결하는 방법또한 복잡성이 높고 권장되지 않기 때문이다.
- 보안그룹
- 트래픽이 Amazon EKS컨트롤 플레인과 작업자 노드 사이에 흐를 수 있도록 기본 셋팅
- 인스턴스에 대한 인바운드/아운바운드 트래픽을 제어하는 가상 방화벽 역할
- 서브넷 수준이 아닌 인스턴스 수준에서 작동
- 도일한 인스턴스의 모든 인터페이스가 동일한 보안 그룹을 사용
- cluster, control plane, work node 보안 그룹등이 있다 - DNS
- Amazon EKS를 이용한 라우팅을 위해 IP 주소와 도메인 이름을 변환 하는데 사용
- 요청을 인프라로 라우팅할때 도메인 이름을 IP주소로, IP주소를 도메인이름으로 변환하는 등의 작업 필요
- aws route 53 서비스 이용
가용역역 : 1개 이상의 물리 데이터센터를 묶은 논리적인 데이터 센터
즉 가용역역 간에는 독립적인 전원,물리적 보인 등의 시설을 가지며 물리적인 장애가 발생 하더라도 가용역역 간에 영향을 미치지 않는다.
리전 : 가용역역이 2개 이상 구성된 지리적 영역
Pod 통신
EKS 클러스터 내부의 Pod들은 각각 IP주소를 가지며 포트를 할당 받는다.
Pod 간의 통신 컨테이너 통신은 아래와 같이 가능하다.
Pod 안의 컨테이너간 통신
Pod 내부의 컨테이너들은 모두 같은 namespace를 가지기 때문에 NAT 없이도 통신이 가능하다.
같은 노드 안에 있는 Pod 간의 통신
각각의 pod는 서로 다른 namespace를 가지고 있을 수 있으며
이런 경우는 위와 다른 방식으로 통신을 한다.
각각의 pod 들은 라우팅 테이블을 가지고 있으며, 노드 역시도 고유한 라우팅 테이블을 가진다. 라우팅 테이블에 알맞은 설정들이 되어 있어서 Linux 가상 이더넷 (veth) 를 통해서 pod와 노드의 네임스페이스간에 터널을 생성한다.
- veth0b/veth0a, veth1a/veth1b는 각각이 한쌍이다.
- pod와 node 영역에 각각의 쌍이 존재 한다.
- pod에서 통신시 해당하는 쌍의 노드 영역으로 통신 요청
- 같은 노드안의 pod간의 통신
veth 는 리눅스의 가상 이더넷 인터페이스로 한 쌍으로 만들어져서 네트워크 네임스페이스들을 터널로서 연결 할 수 있다.
서로 다른 노드에 있는 Pod 통신
서로 다른 노드간의 통신을 위해서는 각각의 Pod에서 노드 외부로 통신을 전달 하기 위해 브릿지 인터페이스를 타고 NAT 처리를 하는 등의 작업이 필요하다.
하지만 CNI 를 사용하여 브릿지 인터페이스를 만들고 컨테이너 네트워크 대역대를 나눠주며 라우팅 테이블을 생성 할 수 있게 되면서 통신이 가능하다.
NAT : 클라이언트의 프라이빗 IP 주소를 퍼블릭 IP주소로 변환하여 요청을 송신, 응답은 반대의 경우로 하는 행위를 처리한다.
CNI : container network interface 로 컨테이너 간의 네트워킹을 제어할 수 있는 플러그인을 만들기 위한 표준
통신 서비스 동작
Pod는 동적으로 사라지고 생성되기 때문에 고정적인 Ip를 가지지 못한다. 그러한 문제점을 해결하고 Pod와 통신 하기 위해서는 서비스를 이용 한다.
서비스는 고정된 Ip 주소 및 포트를 가지고 있기 때문에 서비스로 요청을 전달하고 서비스가 연결된 Pod 중 하나로 라우팅 처리를 해주게 된다.
그리고 이러한 서비스는 아래의 4가지 방법으로서 사용 된다.
ClusterIP
ClusterIP 서비스는 클러스터 내부에서만 엑세스 할 수 있는 Ip 로
각가의 Pod 들은 clusterIP를 통해서 통신을 진행하며 소개되는 다른 서비스 방식들의 기초가 되는 Ip 입니다.
clusterIp는 전달 받은 트래픽을 설정된 포트의 Pod 로 라우팅 해준다.
라우팅 할 때는 kube-prox의 iptable 규칙을 사용한다.
클러스터 내부에서만 사용 가능한 IP 이기 때문에 외부에서 직접적으로 호출을 할 수 는 없다.
ex)
아래 clusterIp의 80번 포트로 들어온 트레픽은 myapp의 pod중 하나의 9376 포트로 라우팅 된다.
apiVersion: v1
kind: Service
metadata:
name: myapp-service
spec:
type: ClusterIP
ports:
- name: http
protocol: TCP
targetPort: 9376
port: 80
selector:
app: myapp
type: frontendNodePort
cluster 내부에 있는 노드에 port 를 열어서 외부에서 직접적으로 호출을 할 수 있다. NodePort를 생성할때 자동으로 ClusterIp도 생성되며 내부에서의 통신은 clusterIp를 통해서 이루어지게 된다.
ex)
아래는 노드의 30008포트가 열려서 외부에서 통신이 가능하며
들어온 트래픽은 clusterIp의 80포트를 통해서
myapp의 pod 중 하나의 80 포트로 라우팅 된다.
apiVersion: v1
kind: Service
metadata:
name: myapp-service
spec:
type: NodePort
ports:
- targetPort: 80
port: 80
nodePort: 30008
selector:
app: myapp
type: frontendLoadBalance
node는 동적으로 사라지고 생성될 수 있기 때문에 고정적인 Ip로 호출이 가능하다고 해도 nodeport만 사용하는것에는 한계가 있다.
클러스터 외부에서 각 노드들로 트래픽을 전달 해주는게 LoadBalance 이며
NodePort와 ClusterIp를 생성하여 활용 한다.
apiVersion: v1
kind: Service
metadata:
name: myapp-service
spec:
type: LoadBalancer
ports:
- protocol: TCP
port: 80
targetPort: 80
clusterIP: 10.0.171.239
selector:
app: myapp
type: frontend
status:
loadBalancer:
ingress:
- ip: 192.0.2.127추가로 서비스마다 로드밸런서를 정의하는것은 쉽지 않기 때문에
Ingress를 활용하여 특정 url 을 기반으로 다른 성격의 서비스를 라우팅 할 수 있다. 이렇게 정의가 된다면 서비스당 로드 밸런서 한개에서 Ingress 당 로드 밸런서 하나로 라우팅이 가능하다.
ExternalName
외부 서비스를 쿠버네티스 내부에서 호출할때 사용 한다.
서비스 메시(Service Mesh)
MSA 구조에서 서비스간의 커뮤니케이션 통제 불편함을 해소하기 위해 나온 개념으로
서비스 간의 통신을 제어하고 표시하고 관리할 수 있는데 특화된 마이크로 서비스를 위한 인프라 계층이다.
기존의 서비스 아키텍처와 다르게 직접 호출을 하지 않고 자체 인프라 계층의 Proxy를 통해서 호출이 이루어 딘다. 이를 통해서 서비스의 트레픽을 네트워크단에서 통제 할 수 있으며 Client의 요구에 따라 proxy단에서 라우팅 서비스도 가능하다.
Reference
seongjin.me
