eks

Intro AWS의 EKS에서는 Ingress Controller를 Helm or Manifest를 이용해서 Application LoadBalancer or Networ LoadBalancer를 만들 수 있게 해 준다. 만드는 방법은 링크를 참고하면 된다. Ingress Controller를 만들면, 우리가 만든 서비스랑 연결을 해줘야 라우팅이 가능해진다. 여기서 문서를 살펴보니, alb.ingress.kubernetes.io/target-type 라는 타입을 명시할 수가 있는데, 이걸로 네트워크 최적화가 가능했다. 한 번 살펴보자. target-type 앞에서 언급한 alb.ingress.kubernetes.io/target-type은 2가지 타입이 instance, ip 타입이 존재한다. 하나씩 알..

Intro AWS EKS를 사용하면서 서비스 규모가 확장되고, Pod의 수가 늘어나거나 HPA에 의해 Scale Out이 필요한 상황들이 발생한다. 이런 경우에 노드의 리소스 부족으로 인해 새로운 Pod를 실행할 수 없는 상황이 생길 수 있다. 이러한 문제를 해결하기 위해 EKS는 Cluster AutoScaling 기능을 제공하며, 추가적으로 Karpenter라는 도구도 사용할 수 있다. 관리형 노드 그룹에 새로운 노드를 추가하는 방식으로 동작한다. 그러나, 실제로 이 기능을 적용했을 때 문제점이 하나 있다. 바로 새로운 노드가 관리형 그룹에 추가되고 실행 가능 상태가 되기까지 약간의 시간이 소요된다는 점이다. 이때 요청이 증가해서 가동되고 있는 파드들 또한 문제가 발생한다면, 서비스의 다운타임이 발생..

EKS Fargate 유형 애플리케이션 로그 수집 Part 1 이후 이제야 EKS Fargate 유형의 애플리케이션 로그 수집을 포스팅할 수 있게 됐다. 이유는 구축하는 것을 어떻게 할까 많은 고민을 했었다. 스크린숏이나, 쉘스크립트로 하기에는 글도 길어지고, 가독성이 안 좋을 것이라고 생각했다. 따라서 Terraform으로 손쉽게 구축할 수 있게 만드느라 오래 걸렸다. 먼저 실제로 실습을 진행하시려는 분들은 아주 조금의 Terraform 지식이 필요한데, 이 또한 아래의 깃허브에 설명을 적어놨다. 하나씩 따라하면 된다. 아쉽지만 Terraform에 대한 포스팅이 아니므로 개념을 설명하지는 않을 예정이다. 클론을 받고 진행하면 된다. EKS-Fargate 깃허브 링크 (안된다면, 댓글로 남겨주시면 확인해..

1. 포스팅하는 이유 서비스를 처음 맡게 되었을 때 인프라가 EKS Fargate 유형을 사용하고 있었다. 로그 수집을 위해 FluentD를 사용하고 있었는데, 아이러니하게도 Control Plane 노드(master 노드에서 명칭이 변경된 걸로 암, 이하 CP라고 칭하겠음) 로그들만 수집하고 있었다. 물론 CP 노드의 로그들을 수집하면, 클러스터 모니터링의 일부분은 구성할 수 있다. 하지만 정작 중요한 애플리케이션 로그들과 워커 노드들의 상태를 수집하고 있지 않았다. 정확하게는 수집할 수 없었다고 말하는 게 맞다. 그 이유는 Fargate 유형의 특성과 연관이 있는데, Fargate의 특성과 한계점에 대해서는 밑에서 알아보도록 하자. 하지만 애플리케이션 로그들도 중요하고, 워커 노드들의 상태를 모니터링..