EKS NW 101 ( AWSKRUG Beginner 세션)

NW 기초

Node : k8s 의 기본이 되는 리소스중하나

Cgroups : 프로세스 자원 제한,격리

Namespace : 리눅스에서의 namespace ⇒ 프로세스 격리

NW namespace : 다른 자원들이 사용할 네트워크 인터페이스 복제해서 생성하는거

Veth : (virtual ethernet) :

Bridge Interface : Veth 가 쌍으로 생성되는데 up 으로 바꿔주기 위한 스위치

Pause Conatiner : 초기 컨테이너

Kubenet : CNI Plugin

---

IPC : 메모리 네임 스페이스

NET : 네트워크 네임 스페이스 , NIC 생성 및 복제

PID : 프로세스 id

UID : 파드의 고유한 호스트 명을 가지도록 함

이러한 기술들을 사용하여 프로세스 격리하고 제약을 걸어서 가상머신처럼 분리된 네트워크와 리소스를 제공한다.

k8s 와 리눅스의 동작

컨테이너 생성시 → NIC 가 내부적으로 생성됨

컨테이너에서도 Nw namespace 가 아이피를 생성해준다.

이더넷 인터페이스를 생성하고 아이피를 할당하는 역할을 하는 것 : CNI !!

root 네임스페이스와 컨테이너 네임스페이스를 연결하기 위한 veth 을 생성한다.

파드가 노드에 배포되었을경우 kubelet 이 nic, namespace 생성 등 명령을 내려서 NIC 를 공유할 수 있게 컨테이너 여러개 복수를 생성을 해주는데 pause 컨테이너가 처음에 생성이 되고, 실제 동작이되는 app container 가 생성이된다.

파드라는건 서비스를 위해 띄우는것이고..

pause container 는 네트워크 네임스페이스를 붙들고 있는다.

그걸 가지고 파드가 삭제되기 전까지는 동일한 이더넷을 가질 수 있게 한다.

노드와 os 하나를 등가관계라고 생각하면 좋다. ( 근데 반드시 그런건 아님)

aws network

CIDR : class less inter domain (클래스 x)

인스턴스를 만들면 ENI 라고 하는 인터페이스를 붙인다. (각 서브넷 주소 할당)자동으로

private subnet 의 내부에서 외부로 나가는 통신 : NAT GW

NAT GW 를 public subnet 에 두게 되면..

파드에는 모든 ip가 하나씩 할당이 됨 == 파드마다 인터페이스가 하나씩 붙는다.

EKS Control Plane NW

모든 응답이 IGW 를 통해서 나오는 구조

아무곳에서나 인터넷으로 접근 가능하다.

내부 통신 ENI 가 있고, private endpoint 가 따로 생성이 됨

ci/cd 플랫폼을 쓰거나 IaC 를 사용할 때 외부에서 접근해야하는 제품들이 있다.

ex : github actions , tf cloud 를 연동할때에는 이런식으로 연결하도록 한다.

control plane 에 접근 불가하고, bastion host 로만..

EKS Data Plane NW (aws vpc cni)

AWS EKS 노드 관리 세가지 옵션이 있다.

1. self-managed nodes (사용자 맴대루)
2. eks managed node group
3. aws fargate (서버리스 옵션 = 직접 노드를 관리하지 않고 노드를 관리하는 )

kubernetes networking model

CNI

• k8s 의 네트워크 인터페이스를 정의하는 명세서
• 네트워크 네임스페이스를 할당하고 네트워크 인터페이스 붙임
• 모든 파드는 무조건 하나의 ip 를 가짐 (예외는 극히드뭄)
• 하나의 파드안에 여러개의 컨테이너는 동일한 nw 와 ip 를 공유한다.
• network namespace , 파드끼리 통신할때는 nat 없이

kubelet → CNI 플러그인 설치 → 그때 L-IPAM 에게 ip 생성하라고 요청

warm : ip미리 할당해둔다건지 뭐 그런 옵션이래

[옵션들]

WARM_ENI_TARGET

WARM_IP_TARGET

MINIMUM_IP_TARGET

WARM_PREFIX_TARGET

 

Amazon VPC CNI Plugin

vpc cni 는 오버레이 네트워크를 사용하지 않음

https://github.com/aws/amazon-vpc-cni-k8s

GitHub - aws/amazon-vpc-cni-k8s: Networking plugin repository for pod networking in Kubernetes using Elastic Network Interfaces

CNI plugin

대부분의 고객사가 VPC CNI 를 사용한다고 함

(eks 를 쓰면 활용을 대부분 함 ip 할당하고 네임스페이스 할당해주니까..)

다른걸 쓰고싶은 경우 책임 영역에서

Pod to Pod 통신

vpc cni : 다른 것들과도 통신이 가능함 .

CNI options

source NAT enabled

노드에서 노드 밖으로 트래픽이 나갈때 ip가 바뀐다.

내부 NAT : 내부에서 nw 가 변화해서 나간다.

AWS_VPC_K8S_CNI_EXTERNAL_CFG = false :⇒ source NAT 를 쓰겠다.

True 라면 NAT GW 를 써서 주소를 바꿀거야

그냥 내부 ip달고 나가다가 외부 NAT GW 에서 ip가 바뀜

Secondary IPs for Pods per EC2 instance

ENI 를 몇개 붙일 수 있는가

max pods = nic 개수 x ([nic 마다의 ip 개수 -1]) +2

이상의 파드를 생성할수가 없다.

탄력적 네트워크 인터페이스 - Amazon Elastic Compute Cloud

탄력적 네트워크 인터페이스 - Amazon Elastic Compute Cloud

aws vpc prefix delegation

ip 를 추가로 확장하는 법

m3, m4 일때는 이 기능 사용불가

prefix delegation 을 사용하면 파드의 집적도를 높일 수 있음

딜레이가 좀 있음

보안그룹 for pods

노드가 SNAT 를 쓰지않으면 보안그룹 적용할 때 문제가 있음

왜냐하면 만약에 prefix delegation 을 썼는데 ip가 어떻게 할당되는지 모름

그 ip가 동적으로 바뀌기 때문에 보안그룹에 어떻게 넣어야 할지를 모르기 때문에 운영이 힘들어진다.

그래서 나온게, 보안그룹 for pods 라는 기능이 나왔다.

그걸 가능하게 하는게 branch and truck ENIS 이다.

Trunk ENI : 부모 ENI

하위에 Branch ENI 를 만들어서

각 파드가 인터페이스를 갖게 함

파드별로 독립적으로 보안설정을 하게 함

고 설정을 활성화 하는것은 ENABLE_POD_ENI = true

이것도 5세대 이상 사용 가능하고 SNAT 사용 불가

trunk 를 사용할꺼라고 노드마다 레이블을 줘야한다.

<aside> 💡 아까 빼먹은거

kubelet 은 110개의 파드 제약이 있는데 늘릴 수 있음 ( kubelet 옵션 수정하면)

</aside>

ENI limit

trunk ENI 의 제한

• 최대 몇개의 ENI 생성이 가능한가?

Pod networking - Custom networking

• AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG = true

서브넷 하나 만들어서 붙일 수 있음 - 하나의 워커노드

ip 제약조건 발생시 vpc 에 서브넷 을 추가하고 ip대역 추가해서 해결

노드별 파드의 개수 증가하는법

—use-max-pods false —kubelet-extra-args --max-pods=110

Custom NW + SNAT + transit GW

Ingress Controller

외부에서 들어오는 .. 의 의미

Ingress : 외부에서 서비스 호출이 들어오는 트래픽을 어떻게 관리할거냐를 구현한거를 Ingress Controller 라고 얘기함

k8s Ingress

f5 인그레스 컨트롤러 ,nginx ,어쩌고를 이용해서도 가능함

쿠버네티스 서비스 : 서비스 형태로 외부에 노출

사용자는 서비스라는 LB 에 통해서 내부에 있는 파드로 접근

직접 접근은 간혹 있음 (ex : 게임사)

일반적으로 Ingress : 서비스를 통해서 접근을 한다고 생각하면 됨

AWS LB Controller

매핑관계가 있음

path 기반, blue green .. → Ingress

NLB

ALB 로 매핑됨

crd : custom ..어쩌고

타겟그룹이랑 매핑하게 되는 역할

서비스와 타겟그룹이 매핑이 되어야 스케일링도 하고 뭣도 함

Ingress with AWS CNI

관리자는 인그레스 생성 해줘 (k8s api 에 요청)

ALB 를 하나 만든다. 통신은 두가지 형태로 구성된다. (instance, ip 모드)

ip : alb- > 바로 파드까지 (대부분의 모드 - 레이턴시 줄고 ..)

Instance Mode : 서비스와 ALB 를 관리하는 조직이 다를 경우 !

 

노드포트 : 포트로 라우팅

⇒ 노드 포트를 사용 하지 않는게 좋다고 함.

=> 평소에 이런 자리에서 질문을 해본적이 없었는데 처음으로 궁금해서 질문을 해보았다. 이당시 k8s 스터디를 하고있던 터라 노드포트의 명확한 용도와 필요성에 대한 궁금증이 생겨 질문했다.

 

 

노드포트서비스는 노드에 대한 ip를 알고있다는 가정을 기반하에 동작하고,

노드가 스케일링 오케스트레이션 영역으로 넘어가게되면 어떤 노드를 스케일링 하는지도 모르고 ..

파드 막 생성되고 삭제가 되는 과정 중에 노드가 막 증가했다가 빠졌다가 하기도 한다.

노드의 ip와 포트를 알고있어야 하기 때문에,, 서비스에 매핑을 할때도 그렇고..

aws LB 를 사용안하는 경우에는 노드 포트에 대한 수동 관리가 필요하다.

로컬에서 접근하려면 (못들음) 를 통해서 번거롭게 포트를 막 찾아야한다고 ..

결론 : 사용하지 않는게 좋다. 서비스에 인그레스를 붙이는게 제일 좋은 방법이라고 ..

선언하는 방법

annotations 로

target group 은 노드포트에 있는 ip 와 포트를 매핑하는것

L7 ALB - > 원하는 파드를 target group을 이용하여 매핑한다.

target group 에 ip 를 매핑하는게 target group binding ..

cpu 를 기준으로 오토스케일링을 하는데,

오토스케일링은 카펜터나 그런거를 하기도 하고

pod의 리소스 체크는 프로메테우스나 뭐 그런걸 이용해서 체크하기도 하고..

---

EKS 는 소규모에서는 가성비적이지 않다.

컨테이너를 쓰는 이유는 MS 적으로 좋은거지 비용 효율적으로 좋지는 않다.

워크샵

Prefix Delegation | EKS Workshop

Custom Networking | EKS Workshop

Security Groups for Pods | EKS Workshop

Exposing applications | EKS Workshop

 

---

정리를 하고 나니까 제가 커뮤니티 활동에 요근래 소홀해졌었는데, 

다시 그때의 기억과 열정이 떠오릅니다.

올해도 열심히 어렵고 모르는 개념이더라도 그 자리에 함께 새로운 개념들을 배워나가는것 자체만으로도 재미를 느끼고 있어서 적극적으로 참여해보아야겠습니다! ㅎㅎ