EKS Cluster 구축 - 1. Intro

저는 쿠알못입니다.

하지만 Kubernetes를 AWS에서 EKS를 통해 데모를 구축했던 부분을 상세히 적어보려합니다.

 

그전에, 간단하게 Kubernetes와 EKS를 왜 사용할까? 에 대한 부분을 조금 나눠보려합니다.

쿠알못이기에, 틀린 부분이 있을 수 있으니 틀렸다면 댓글로 과감하게 말씀해주세요.

 

아래의 링크에서 상당히 좋은 강의를 보고 그 이유를 알 수 있습니다.

https://www.youtube.com/watch?v=O3znWPUdt18

---

Kubernetes는 정의형 오케스트레이션 툴 입니다.

도커스웜, ECS, 쿠버네티스등 많은 오케스트레이션 툴 중 Kubernetes가 표준이 된 이유가 무엇일까요?

 

제가 생각했을 때는 나중에 올릴 포스트에서 나올 여러 오픈소스들과의 연동이 매우 쉽게 가능하고

또한 정의형이기 때문에 yaml 파일만 있으면 어디서든 동일한 구성의 서비스 및 인프라를 구성할 수 있다는 점입니다.

기존에 도커만 깔면 컨테이너로 어떤 인프라 구조이던 서비스를 올릴 수 있던 것에서 더 나아가

전체 서비스 환경자체를 어떤 서버든 인프라 구성이던 yaml을 통해 찍어낼 수 있다는 점입니다.

 

이렇다보니, Terraform과 같이 아에 인프라 제일 밑단까지 코드로 구성하여 운영하게 된다면,

인프라 구성의 변경 추적 및 관리 이식성이 엄청나게 뛰어나지는 것입니다.

 

이렇게 정의형으로 이식성이 뛰어나다는 것은 다음과 같은 장점을 가집니다.

실제로 서비스를 구현하기 위해 프로젝트를 시작하면 개발계에서 모든것을 시작하다 보니

DEV 환경에서 커뮤니케이션 미스로 설정했지만 아무도 기억 못하는 것 때문에

PRD 환경을 만들었음에도 DEV 환경에서만 정상적으로 서비스가 작동한다던지 하는 이슈들이 꽤 있습니다.

프로젝트 시간에 쫓기다보면 결국 DEV환경이 PRD가 되고 DEV를 다시 만들어서 사용하는 현상들을

정의형 인프라 구조를 가져가면 해결할 수 있는 것이죠.

 

하지만 이에 맞게 단점도 있습니다.

코드로 구성되기 때문에 코드 문법에 맞게 새롭게 공부를 해야한다는 점과,

코드 리뷰가 충분히 되지 않거나 혹은 예상치 못한 에러가 발생하게 된다면,

간단한 수정이라도 형상관리 형태가 꼭 이루어져야 하다 보니 빠른 수정이 어려울 수 있습니다.

 

물론 대게 Kubernetes는 정말 급하다면 kubectl 등 CLI 를 통해 수행하면 되긴 하지만,

kubernetes, IaC 등을 사용하는 것이 형상관리 및 운영 관점을 극대화 하기 위함이므로 이러한 부분을 피해야합니다.

 

yaml파일 또한 구성하는 사람의 스타일에 따라 달라질 수 있고,

IaC는 코드를 짜는 사람의 스타일에 따라 추후 인수인계에 상당한 어려움을 겪을 수 있습니다.

 

이렇게 Kubernetes가 정의형 아키텍쳐이기에 가지는 특징에 대해 좀 적어보았습니다.

---

이제 EKS에 대해 조금 간략하게 알아보도록 하겠습니다.

 

여러 AWS의 매니지드 서비스를 사용하시다 보면, 커스터마이징을 하는 부분에 있어 제약이 많습니다.

EKS는 그러한 제약이 없도록 구성하여 위의 이식성을 그대로 가져갈 수 있도록 구성되었습니다.

 

쿠버네티스를 구축하고 그 안에서 사용하는 모든 정보는 ETCD에 기록되게 됩니다.

따라서 마스터노드 및 ETCD 노드를 이중화 삼중화하는 것이 상당히 중요하게 되는데,

AWS는 EKS에서 이 마스터노드와 ETCD노드를 관리해주고 Private Link로 연결되어 내부망 통신으로

안전하게 워커노드와 통신할 수 있습니다.

 

따라서 EKS를 사용하시면 워커노드 서버만 관리하시면 되고

이를, Cloud9과 같은 곳에서 RBAC가 할당된 IAM을 세팅한 후

IAM자체가 RBAC다보니, 이 또한 쿠버네티스 RBAC에 대한 이해도 빨리 하실 수 있습니다.

Cloud9 접근 권한을 제어하는 형태로 구성하면 네임스페이스 별로 관리하기가 상당히 용이합니다.

 

또한 원래 쿠버네티스의 Pod는 IP가 가상으로 구성되게 되어있으나,

EKS는 CNI를 통해 ENI와 매핑되어 실제 AWS VPC CIDR의 대역으로 구성됩니다.

즉, Pod가 배포되는 시점에 AWS VPC의 IP 방화벽 등이 세팅되는 것이죠.

그리고 이렇다보니 구성하실 때, 통 서브넷을 구성하시는게 가장 좋을 것으로 판단됩니다.

 

Storage에 관련된 부분도 사실 Kubernetes Storage Class를 만지시다보면,

AWS의 EBS 플랫폼과 굉장히 유사하다고 느끼실 수 있습니다.

CSI를 통해서 AWS Storage Service를 쉽게 마운트하여서 사용이 가능합니다.

 

AWS또한 kubernetes에 협력하여서 개발을 같이하다보니 upstream kubernetes에서 

공식적으로 위의 서비스를 제공하고 있는 상태입니다.

 

충분히 더 좋고 많은 내용이 있겠지만 아직 쿠알못이기에 더 많은 내용은 적지 못하는 점 이해해주시기 바랍니다.

다른 핸즈온 포스터와는 다르게 어떻게 매핑되고 사용되는지 좀 상세하게 글과 함께 올릴 예정입니다.

 

다음 포스터 부터 EKS Cluster를 수동으로 만들면서 어떤 요소들이 필요하고

각 요소가 어떤 역할들을 하는지 알아보면서 구축해보도록 하겠습니다.