AEWS 2 WEEK

Hi yena·2023년 5월 1일

AEWS

목록 보기

2/8

2주차 EKS Networking

이번 스터디를 통해선 AWS CNI를 사용하는 이점에 대해서 직접 확인할 수 있었습니다. 네트워크적 관점에서 오버헤드를 줄여 성능을 향상할 수 있고, pod, node ip 관리도 편리해보였다... 앞으로도 열씸히 참여해서 k8s 지식을 늘리고 싶은 맘,,😅입니다

📌 CNI란?

CNCF 프로젝트의 일환으로서, 리눅스 컨테이너에서 네트워크 인터페이스를 구성하기 위한 플러그인을 만드는 표준이며 k8s 네트워크 환경을 구성해줍니다.

📌 AWS VPC CNI는

파드의 IP를 할당해줍니다. POD 의 IP 네트워크 대역과 워커노드의 IP 대역이 같아서 직접 통신이 가능하다는 장점이 있습니다. VPC와 완벽하게 통합이 되어 통신 구조가 간결하고 효율적임.
장애처리에도 유용.

📌 K8S Calico CNI 와 AWS VPC CNI 차이

awsvpc는 노드와 파드의 네트워크 대역을 동일하게 설정합니다.

파드간 통신하는 경우 일반적으로 K8S Calico CNI는 오버레이 통신을 하고, awsvpc는 동일 대역으로 직접 통신을 합니다. 즉, VPC의 주소 공간에 포드에 대한 IP 주소를 할당합니다.

💡 이러한 이점을 통해 컨테이너와 노드는 추가적인 경로 구성이나 오버레이 없이 VPC 네트워크를 통해 직접 통신할 수 있습니다.

( 출처 : https://velog.io/@xgro/pkos-%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4-%EC%8A%A4%ED%84%B0%EB%94%94-2%EC%A3%BC%EC%B0%A8 )

📌 워커노드에 생성 가능한 최대 POD 갯수

Secondary IPv4 addresses : 인스턴스 유형에 최대 ENI 갯수와 할당 가능 IP 수를 조합하여 선정
IPv4 Prefix Delegation : IPv4 28bit 서브넷(prefix)를 위임하여 할당 가능 IP 수와 인스턴스 유형에 권장하는 최대 갯수로 선정

📌 실습

1. 배포 확인

1-1) 설치 확인

1-2) 환경변수 정보 확인

1-3) 노드 정보 확인

1-4) krew 플러그인 확인 및 모든 네임스페이스에서 리소스 확인

1-5) 노드정보 확인 및 SSH 접속

보안그룹 ID와 보안그룹 이름(Name이 아님을 주의) 확인
노드 보안그룹 ID 확인
노드 보안그룹에 eksctl-host 에서 노드(파드)에 접속 가능하게 룰(Rule) 추가 설정
워커노드 SSH 접속

1-6) Add-on 정보 확인

아무래도 최신 버전은 많은 Add-on 을 지원하지 않고 있기 때문에 1.24 버전으로 eks 를 설치 진행!

2. 네트워크 기본 정보 확인

2-1) CNI 정보 확인

2-2) kube-proxy config 확인

iptables 모드 동작을 자세히 표현한 그림

2-3) 노드와 파드 IP 확인

노드

파드

노드IP = POD IP 인 것을 확인할 수 있다

2-4) 네트워크 정보 확인

워커노드 1번의 네트워크 인터페이스 정보 확인 가능
eni4a~~ 이게 POD 의 IP

3. 노드에서 기본 네트워크 정보 확인

3-1) 확인

ENI0 IP는 host network모드라 aws-node 의 ip와 kube-proxy 의 ip와 동일

여기에서 coredns(192.168.1.165) 는 어디에 배포 되어 있을까? 따라가보면
(NODE ip 참고하여)

노드 1번의 웜풀 ip 에서 (보조 프라이빗 IPv4) 파드의 IP 확인 가능하다

보조 ip 를 가지고 있다가 POD가 하나씩 뜨면 할당해줌

노드의 라우팅 정보를 확인해보면

보조프라이빗 ip 주소 풀 내에서 ip 가 있는 것을 확인해볼 수 있다.

3-2) 워커노드 3번 TEST pod를 띄워보고 확인 해보기

POD 띄우기 전

node 3번에 eth 인터페이스가 추가로 생성된것을 확인 가능하다.

라우팅 정보를 확인해봐도 확인가능

3-3) 테스트 파드 접속 후 확인

pod1 번에 zsh로 접속하여 ip 인터페이스 정보를 확인해보니 node 1번 인터페이스 ip와 동일한것을 확인해볼 수 있다.

nameserver ip도 확인해볼 수 있다(= coredns의 서비스 ip)

4. 노드 간 파드 통신

pod 1에서 pod 2로 ping

node 안에서 tcp dump 로 확인해보면
pod와 pod끼리 바로 꽂히는 것을 확인 가능

5. 파드에서 외부 통신 테스트 및 확인

5-1) 외부 라우팅

POD1번에서 구글로 ping (통신 가능!)

5-2)

pod1번의 외부로 나갈때 공인 ip = 워커 노드 1번의 할당된 유동 public ip와 동일

6. 노드에 파드 생성 갯수 제한

Secondary IPv4 addresses (기본값) : 인스턴스 유형에 최대 ENI 갯수와 할당 가능 IP 수를 조합하여 선정
인스턴스 타입 별 ENI 최대 갯수와 할당 가능한 최대 IP 갯수에 따라서 파드 배치 갯수가 결정됨
-> 단점 : 경량의 pod는 더 띄울 수 있는데 더 못띄움
해결 방안 : Prefix Delegation, WARM & MIN IP/Prefix Targets, Custom Network

파드 사용 가능 계산 예시 : aws-node 와 kube-proxy 파드는 host-networking 사용으로 IP 2개 남음
((MaxENI (IPv4addr-1)) + 2)
t3.medium 경우 : ((3 (6 - 1) + 2 ) = 17개 >> aws-node 와 kube-proxy 2개 제외하면 15개

6-1) 최대 파드 생성 및 확인

deployment 생성

pod 확인

pod 8개로 증가

pod 50개
-> pending 된 pod 들이 보임(ip 갯수 제한에 걸림)

실제로 pod 안의 로그 이벤트도 확인해보면 too many pod 로그 확인 가능

7. Service

서비스 종류
1. ClusterIP 타입

2. Nodeport 타입 : k8s 가 배포되지 않은 쪽에서 pod 내부로 접근가능하게 조치할때 외부에 노출할 수 있게 하는 방법

3. LoadBalancer 타입 (기본 모드) : NLB 인스턴스 유형

4. Service (LoadBalancer Controller : AWS Load Balancer Controller + NLB IP 모드 동작 with AWS VPC CNI

-> NLB를 거쳐서 Nodeport로 들어와야하는데 POD로 바로 통신

7-1) 로드밸런서 배포

OIDC 확인 (aws 콘솔에서도 확인 가능)

로드밸런서를 컨트롤하기위한 Load Balancer Controller POD 를 위한 IAM 정책을 생성하고

IRSA 정보 확인

IAM role의 신뢰관계 확인

타겟그룹 서비스 확인

실제로 콘솔에서 로드밸런서에 연결된 타겟그룹을 가보면, 등록된 타겟에 아래와 같은 ip들을 확인 가능하다.

이 ip 들은 POD의 IP인것을 확인이 가능하다
원래 로드밸런서는 nodeport 로 동작하여야하는데
vpc cni 와 유기적으로 연동이 되므로 효율적으로 사용할 수 있다

2개의 파드에 분산이 잘 되고 있는지 확인

7-2) pod 하나로 scale down

쿠버네티스에서 deployment 하나로 줄였는데, alb에서 대상타겟 그룹이 하나로 줄어든 것을 확인 가능하다

이것이 가능한 이유는 aws 로드밸런서 컨트롤러 파드가 IRSA로 적절한 권한을 가지고 있기 때문이다

이렇게 유연하게 aws에 신경쓰지 않고도 k8s에서 aws 자원 조절 가능

8. Ingress

Ingress 란?
클러스터 내부의 서비스(ClusterIP, NodePort, Loadbalancer)를 외부로 노출(HTTP/HTTPS) - Web Proxy 역할
AWS Load Balancer Controller + Ingress (ALB) IP 모드 동작 with AWS VPC CNI

8-1) game pod 배포