앞서 작성했던 트러블 슈팅 관련 글 중에 한 글은 제목이 "타노스는 이런 느낌일까?" 라고 지었을 만큼 꽤나 힘들었던 에러였죠. 근데 이번에 겪은 이슈는 앞선 글 제목에 타노스 라고 붙이기 민망할 정도로 원인을 찾기가 힘들었고, 또한 이슈가 6개월이나 지속될 정도로 마음 아팠던 트러블 슈팅이였습니다.  들어가기 앞서 간략하게 환경은 다음과 같아요. 쿠버네티스는 AWS EKS(v1.28) 를 이용하고 있으며, 서비스메시 서비스인 이스티오(v1.18)의 인그레스 게이트웨이와 AWS ALB 를 맵핑하여 클러스터 외부에서 클러스터 내부 서비스에 접근이 가능합니다. 그리고 여기서 사용할 내부 서비스는 ArgoCD(v2.5) 입니다. 이슈는 ME! 가 ArgoCD 에 접근을 했을때 불특정하게 504 Gateway ..

들어가기 앞서 저는 Windows 를 많이 다뤄보지 않았기 때문에 부족하거나 틀린 부분이 있을 수 있습니다! 쿠버네티스는 v1.23 버전, Karpenter 는 v0.31 버전입니다. 쿠버네티스(EKS) 환경에 윈도우와 Karpenter 를 활성화 하는 방법에 대해선 여기를 참고하세요. Karpenter 에 대해 궁금하다면 여기를 참고하세요. 그럼 렛츠두더코드~ 우리가 쿠버네티스를 사용하는 방법은 바로 오케스트레이션을 위함이죠. 하나의 마스터 플레인으로 여러 노드의 여러 파드를 좀 더 쉽게 관리하기 위해서입니다. Action Runner 역시 예외는 아니죠. Action Runner Controller 를 이용하면 쉽게 쿠버네티스 환경에서 파드 단위의 Runner 배포가 가능합니다. 맨 처음 Action..

우리는 보통 EKS 의 워커 노드로 x86 이든, arm64 이든 리눅스를 사용합니다. 특히 EKS 환경이라면 아마존 리눅스2를 사용하겠지요. 근데 간혹 워커 노드로 윈도우를 필요로 하는 경우가 있습니다. 예를 들어 라이브러리를 만들었는데, 리눅스 뿐만 아니라 윈도우 환경에서도 이 라이브러리를 필요로 합니다. 그렇다면 이 라이브러리를 이미지로 빌드하려면 리눅스가 아닌 윈도우 환경에서 만들어야 하죠. 다행히 EKS 는 윈도우를 지원해줍니다. 또한 Karpenter 에서도 윈도우를 지원해주죠. 그럼 어떻게 EKS 환경에서 윈도우를 활성화 하는지, 이후 Karpenter 에서 윈도우를 어떻게 프로비저닝 하는지 한번 알아보도록 하죠. 참고로 진행한 쿠버네티스 버전은 1.23 이고, Karpenter 는 0.31..

누구나 한번 쯤은 슈뢰딩거의 고양이에 대해서 들었거나 관련 밈을 보셨을 겁니다. 그래도 혹시 모르시는 분들을 위해 간단히 알려드리죠. 고양이를 보이지 않는 상자에 넣고, 그 속에 50:50 확률로 고양이를 죽이는 독극물을 넣었을 때 고양이는 죽을까요? 살까요? 일반 세계에서는 죽었다, 살았다 라고 표현하지만 양자역학 세계에서는 이를 죽음과 삶이 중첩된 상태라고 표현합니다. 즉, 살아있으면서 죽어있다 라고 합니다. 오늘 글에서 소개할 Fargate (파게이트) 또한 슈뢰딩거의 고양이와 비슷한 개념입니다. (나만 그렇게 생각할수도..) Fargate 는 무엇일까? 우리는 보통 AWS 를 이용해서 애플리케이션을 배포한다고 하면 EC2 를 통해 인스턴스를 생성하고, 그 인스턴스 내부에 컨테이너나 직접 프로세스로..

쿠버네티스 API 요청 과정 간단하게 API Server에 접근하기 까지 프로세스를 보면, 첫번째, 요청을 보냈을 때 인증(Authentication) 과정을 거친다. "너는 k8s cluster에 등록된 사용자가 맞는거지?" 두번째, 인증 과정을 통과한 후 인가(Authorization) 과정을 거친다. "등록된 사용자는 맞고 이 액션을 할 수 있는 권한은 있니?" 세번째, 인증과 인가를 통과하게 되면 Admission Control을 거친다. "너가 보낸 요청을 적절한지 확인해볼까?" 이 과정을 무사히 마치면 "요청 승인"이 된다. 하지만 만약 한 과정이라도 적절치 않다면 "요청 반려"가 된다. 그럼 본격적으로 AWS EKS를 이용하여 만든 클러스터에 최초 생성한 IAM 사용자가 아닌 새롭게 만든 I..