해당 포스팅은 현재 재직중인 회사에 관련이 없고, 개인 역량 개발을 위한 스터디 자료로 활용할 예정입니다.
시리즈의 마지막 편이다. 지금까지 분산 학습의 내용들을 정리해봤다.
그런데 마지막 질문이 남는다.
"이 많은 노드를 어떻게 하나의 학습 잡으로 묶어서 돌리지?"
노드 수십 대에 일일이 SSH로 들어가 EFA를 켜고 FSx를 마운트하고 mpirun을 칠 수는 없다. 프로비저닝·스케줄링·장애 복구를 대신 해주는 오케스트레이션 계층이 필요하다. 이 글에서는 AWS의 세 가지 방식을 비교한다.
해당 포스팅은 현재 재직중인 회사에 관련이 없고, 개인 역량 개발을 위한 스터디 자료로 활용할 예정입니다.
이번 포스팅의 목적은 Gateway API의 개념을 이해하고 Lattice를 통해 AWS Gateway API Controller를 EKS에서 사용해보기 위함이다.
AWS에는 기본 ENI가 포함된 서브넷에서 사용할 수 있는 IP개수는 제한되어 있다. 파드의 수 제한이 발생할 수 있기 때문에 secondary ENI에 다른 서브넷을 사용하여 가용 IP개수를 늘릴수 있다. 또한 보안상의 이유로 파드는 노드의 기본 네트워크 인터페이스와 다른 서브넷 또는 보안 그룹을 사용해야 할 수 있다.
CNI Custom Networking이 활성화가 되면 파드는 다른 서브넷에 생성이 되고, 노드 서브넷의 아이피를 사용하지 않는다.
EKS에서 파드 대역을 분리 하기 위해서 CNI Custom Networking 설정을 진행한다. 해당 env 값을 변경하면 즉시 aws-node 가 교체된다.
지난글에 이어 이번에는 홈랩으로 구성한 EKS Anywhere 클러스터에서 운영, 개발환경 구성을 위한 여러가지 도구를 설치해보는 과정을 정리하고자 한다.
지난 포스팅은 다음 링크에서 확인할 수 있다.
EKS Anywhere는 eksctl를 사용하는 환경에서 Kubernetes Cluster API Provider vSphere 인 CAPV를 통해 vSphere 기반으로 쿠버네티스 클러스터를 구성해주는 오픈소스이다. CAPV Spec은 Kubernetes Cluster API 기반으로 쿠버네티스 스타일 API형태의 선언적(Declarative) 방식으로 쿠버네티스 클러스터의 Lifecycle을 관리하는 프로젝트이다.
Ubuntu 또는 Mac admin 환경에서 eksctl 명령어로 로컬 클러스터들을 관리하고 클러스터를 생성, 삭제할 수 있다. 일단 기본적으로 클러스터를 생성하고 관리하는 방식이 eksctl과 거의 유사하다. 또한 EKS 서비스의 배포 버전과 동일한 버전을 사용함으로써 (포스팅 당시 버전 1.21) vSphere 기반 하이브리드 환경에서의 쿠버네티스 클러스터 및 워크로드 관리를 편하게 할 수 있다.