EKS사용 이유와 유의할점 (feat. 권한문제, Ingress controller)

cch_chan·2022년 6월 7일
1

기술-블로그

목록 보기
1/3

이번 Devops bootcamp 마지막 프로젝트를 진행하면서 사용한 컨테이너를 관리하는 방법 중 Docker, Kubenetes, EKS, ECS를 사용해보면서 겪은 EKS를 왜 사용 했는지와 EKS로 구현함에 따라 힘들었던점을 적어볼까 합니다.

프로젝트 시나리오 짧은 설명

적은 인원으로 간단한 EC2 기반으로 서비스를 운영으로 하는 회사가 투자를 받게 됨에 따라 개발팀 인원을 확충하여 추가 개발팀과 DevOps팀이 추가되어 기존 로컬에서 수동으로 docker build & push를 하는 방식을 자동화 시켜 dev환경으로 구축하고 staging/production 환경은 container orchestration을 구성하는것이 목표입니다.

github : https://github.com/devops-team-AltF4/scenario


container orchestration

저희 팀은 container orchestration을 구성함에 따라 ECS와 EKS 중 EKS를 사용하기로 했습니다.

우선 Docker와 kubenetes의 차이를 알아보고 아마존에서 관리하는 EKS, ECS중 EKS를 사용한 이유에 대해서 다뤄보겠습니다.

Docker vs Kubenetes 차이

간단하게 설명하면 docker는 적은 컨테이너를 다루는데 특화되었지만 다수의 컨테이너를 다루기에는 적합하지 않다. 여러개의 컨테이너를 다룰때는 docker compose를 사용하면 되지만 dev환경에서는 test할때 마다 입력해야하는 명령값이 많고 다수의 서비스를 열기에는 불편함이 많다.

하지만 Kubenetes를 사용하면 kubectl을 이용하여 다수의 컨테이너를 관리하기에 특화되어 있고 서비스를 배포 자동화 시키는 것도 argocd를 이용할 수 있고 모니터링 툴(그라파나, 프로메테우스)도 많기 때문에 조금 더 안정성 있게 관리하기에는 쿠버네티스가 적합하다.

참고 자료

로컬 Kubenetes 와 EKS 차이

우선 가장 큰 차이점은 서비스를 관리하는 서버를 아마존에서 유지보수를 시켜준다. 트래픽이 많아 질경우 트래픽에 맞춰 오토스케일링도 진행이 되기 때문에 서버 컴퓨터가 없는경우 EKS를 이용하는것이 소규모 회사에서는 적합하다.

추가로 로컬 kubenetes와 EKS에 차이로 로컬에 경우 모든 노드를 관리해야하지만 EKS의 경우 마스터노드는 아마존에서 관리하고 워커노드만 사용자가 관리하면 되기 때문에 매니징 부분에서 차이가 있다.

EKS, ECS중 EKS를 선택한 이유

production환경에 EKS를 사용한 이유는 ECS에 비해 서비스에 자유도도 높으며, 다른 클라우드 서비스로 이전할때 용이하다는 장점이 있기 때문입니다.
또 인프라구축까지 자동화 시킬때 ECS와 EKS 모두 자동화를 시킬 수 있지만 EKS는 yaml 파일로 인프라를 구축 할 수 있기 때문에 간편하고 kubenetes 사용자라면 명령어가 크게 다른것이 없기 때문에 범용성이 높기 때문에 EKS를 사용 하기로 하였습니다.

관련 설명
eks yaml로 인프라구축(https://aws-diary.tistory.com/43)


ECS - docker supported
EKS - kubernetes supported


EKS 사용에 유의할점

공용 작업을 위해선 권한 문제 해결 필요

EKS를 사용할 때 여러사람이 함께 이용하기 위해서는 권한을 공유하기 위해서는 조금 복잡한 과정이 따른다
EKS 클러스터를 생성한 사람은 마스터 권한을 가지는데 이외의 사용자가 그 클러스터를 접속하고 kubectl을 사용시 권한이 부족하다는 오류가 나타남
"error: You must be logged in to the server (Unauthorized)."
이를 해결 하기 위해서는 aws-auth ConfigMap의 추가 사용자를 등록하고 RoleBindings을 통해 권한을 공유해야합니다.

권한 문제를 해결하는 방법
참고 자료 (https://mtou.tistory.com/132)

인그레스 컨트롤러가 필요한 이유

인그레스(ingress)는 클러스터 외부에서 내부로 접근하는 요청들을 어떻게 처리할 지 정의해둔 규칙들의 모음인데 인그레스를 쿠버네티스에서 이용하기 위해서는 인그레스 컨트롤러가 필요하다.
이번 프로젝트에서 인그레스를 사용한 이유는 ALB를 사용해서 하나의 도메인으로 여러 서비스를 Path를 구분하여 routing하기 위해서 사용하였다.

기존 쿠버네티스 서비스타입에도 로드밸런서 타입이 존재하긴 하지만 그 타입으로 선택할시 Classic Load Balancer로 구성이 되어 서비스 수만큼 로드밸런서가 생성이 되기 때문에 하나의 로드밸런서로 여러 서비스를 라우팅하기 위해선 인그레스가 필요하고 인그레스 컨트롤러를 필수적으로 세팅해줘야한다.

참고 자료 : https://bcho.tistory.com/1263

ALB 인그레스 컨트롤러를 설치 방법
참고 자료
https://velog.io/@cks8483/AWS-Load-Balancer-Controller-%EC%84%A4%EC%B9%98feat.-helm

profile
꾸준히 새로운 기술을 배워나가는중입니다.

2개의 댓글

comment-user-thumbnail
2022년 6월 11일

EKS 궁금했었는데, 잘 읽고 갑니다!

1개의 답글