본문 바로가기

🛠️🔧 트러블 슈팅 (Trouble Shooting)/네트워크 (Network)

트러블 슈팅을 해보자 (TCP/IP, NLB, EKS, pod)

728x90
반응형

상황은 아래와 같다.

EKS에 AA라는 pod가 생성 되어 있다. 이 pod는 TCP/IP를 통해 BB라는 기관과 커넥션을 맺고 데이터를 송 수신 한다.

그리고 해당 pod는 TCP/IP 연결을 해야하기 때문에 고정 IP를 할당해야 했으므로, NLB를 통해서 트래픽이 전달된다.

그리고 클라이언트는 NLB의 a리전의 IP를 통해서 커넥션 연결을 시도한다.

여기서 문제는 NLB를 구성하기 위해서는 최소 2개의 리전을 설정하여 생성해야 한다. 하지만 해당 pod는 TCP/IP 연결 특성상 멀티 리전에 pod를 배포하지 못하고, a와 c리전 중 a리전에만 pod를 배포 하고 있다.

첫번째 질문

pod가 생성이 될때, EKS 특성상 A리전과 C리전중 랜덤으로 생성이 될 수 있다.

이를 방지하기 위해서는 nodeSelector를 사용하여 pod가 특정 리전에만 배포되도록 설정할 수 있다.

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  nodeSelector:
    failure-domain.beta.kubernetes.io/zone: a
  containers:
  - name: my-container
    image: my-image

affinity를 사용하여 pod가 특정 리전에 배포

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: failure-domain.beta.kubernetes.io/zone
            operator: In
            values:
            - a
  containers:
  - name: my-container
    image: my-image

두번째 질문

nodeSelector나 affinity를 사용하지 않고 다른 방법은 없어?

NLB의 교차영역 로드밸런싱 옵션을 활성화하면 단일 리전에만 배포된 Pod에 대한 트래픽을 안정적으로 처리할 수 있다.

만약에 a리전의 IP가 111.111.111.111이고 c리전의 IP가 333.333.333.333이라고 가정할때 해당 pod는 c리전에 배포 되어 있어 그래서 원래는 클라이언트가 배포된 pod와 통신하기 위해서는 c리전의 IP인 333.333.333.333을 목적지로 바라보고 들어가야 하는데, 클라이언트는 a리전의 IP인 111.111.111.111로 커넥션을 연결하도록 설정 되어 있어. 이 경우에 NLB의 교차영역 로드밸런싱 옵션을 활성화 해서 클라이언트가 정상적으로 a리전의 배포되어 있는 pod와 커넥션을 맺을수 있지 않을까?

 

결과

 NLB의 교차영역 로드밸런싱 옵션을 활성화하면 클라이언트가 a리전의 IP를 통해 접속하더라도 c리전에 배포된 Pod와 정상적으로 연결할 수 있다. 교차영역 로드밸런싱을 활성화하면 NLB는 여러 가용 영역에 걸쳐 트래픽을 분산시킬 수 있다.

 

NLB의 교차영역 로드밸런싱 옵션을 활성화하면 클라이언트가 a리전의 IP를 통해 접속하더라도 c리전에 배포된 Pod와 정상적으로 TCP/IP 커넥션을 맺을 수 있다. 교차영역 로드밸런싱을 활성화하면 NLB는 여러 가용 영역에 걸쳐 트래픽을 분산시킬 수 있으며, 이는 클라이언트가 특정 리전의 IP를 통해 접속하더라도 다른 리전에 있는 리소스와 연결할 수 있게 해준다는 의미이다.

 

- 끝 -

728x90
반응형