이스티오는 디버깅이 어려운 툴 중 하나라고 생각합니다. 그 이유는 간단하죠. 이스티오 자체가 어렵기 때문입니다. 서비스 메시 툴 답게 많은 네트워크 지식을 요구하기 때문에 디버깅이 어려울 수 밖에 없습니다. 네트워크 관련된 부분이 많기 때문에 어디서부터 디버깅을 해야 하는지 감도 사실 잘 안 옵니다. 이게 이스티오 문제인가? 클라우드 문제인가? 쿠버네티스 문제인가? 판단하기까지도 오래 걸리죠. 그러다 보니 애플리케이션을 배포하던 중 약간이라도 이스티오와 관련한 문제가 발생했다고 생각하는 경우 그냥 애플리케이션에서 이스티오를 빼버립니다. 정확히는 이스티오 사이드카(프록시)를 레이블을 통해 인젝션에서 제외시켜 버리는 것이죠.  이스티오 사이드카를 주입하지 않았기 때문에 대부분의 문제는 해결되지만, 이는 근본..

AWS 에서 GCP 로 넘어가면서 자연스레 AWS Secrets Manager 에서 GCP Secret Manager 로 넘어가게 되었습니다.서비스 이름이 AWS 에선 Secrets 복수를 사용하고, GCP 에선 Secret 단수를 사용하는데 글 후반부에서는 왜 이렇게 지었는지 대략적으로 알 수 있게 됩니다! Secret Manager 라는 서비스는 사실 특별한 기능은 없습니다. 그저 시크릿을 저장하는 저장소 역할을 하는데, 쿠버네티스 환경에서 External Secrets 나 Argo Vault Plugin 을 사용하면 원하는 시크릿을 쉽게 가져올 수 있다는 장점이 있습니다. AWS Secrets Manager 에 익숙한 상태였기 때문에 GCP 에서도 비슷하게 가져가면 될 것 같다라는 생각으로 마이그레..

이전 글인 [트러블 빵야] 6개월 동안 즐거웠다.. 잘가고 다신 보지 말자! - 504 Gateway Timeout (이슈 편) 에서 이어집니다! 곰곰이 생각해봤습니다. 504 Gateway Timeout ... 결국 어디선가 Response 를 받아야 하는데 받지 못해서 생기는 이슈 입니다. 어디서 Response 을 받지 못했을까요? 위 아키텍처만 봤을땐, 더 이상 도저히 모르겠습니다.  그래서 위 이미지보다 조금 더 아키텍처를 구체화시켜봤습니다. AWS ALB 는 Target Group 에 등록된 노드에게 트래픽을 라우팅 해주는데, Karpenter 로 생성되는 노드들은 모두 동일한 Target Group 에 등록됩니다. (대수롭지 않게 동일한 Target Group 에 등록되게끔 구성했죠) 여기서..

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

EKS 에 배포된 파드들은 AWS 에 접근하기 위한 방법으로는 크게 2가지가 있습니다. EC2 Instance Profile IAM Role for Service Account EC2 Instance Profile 은 워커 노드에게 AWS 에 접근할 수 있는 자격 증명을 해주죠. 정해진 EC2 인스턴스에 정해진 애플리케이션을 배포한다면 위 방법은 아주 좋은 방법이에요. 하지만, 쿠버네티스 환경에 배포되는 파드들은 하나의 특정한 노드에 배포되지 않아요. NodeAffinity 와 Label 을 통해서 노드를 제한하긴 하지만 느슨하게 그룹핑을 하죠. 만약 쿠버네티스 환경에서 App 이 Replica 3 개로 배포되고, Hard PodAffinity 를 주어 파드를 전부 다른 노드에 배포되게끔 한다면, 또 다..

쿠버네티스 환경에선 Action Controller Runner (이하 ARC) 를 이용해서 파드를 Self Hosted Runner 로 사용할 수 있습니다. ARC 구조는 위와 같습니다. Self Hosted Runner 로 사용할 파드를 RunnerDeployment 또는 RunnerSet 으로 배포할 수 있죠. RunnerDeployment 는 쿠버네티스에서 Deployment 와 동일하게 동작하고, RunnerSet 은 StatefulSet 과 동일하게 동작합니다. 또한 배포하게 되면 파드 안에 2가지 컨테이너 동작하게 되는데, 하나는 Github Action Job 을 처리하는 Runner 컨테이너, 또 하나는 Docker 관련 일을 처리하는 Docker 컨테이너입니다. 옵션을 통해 Runner..

Nginx 기반의 Pod 내에서 S3 와 Mount 하기 위해 goofys 를 사용했던 적이 있습니다. (goofys 말고 EBS 나 EFS 도 위시리스트에 있었지만, goofys 가 가장 적합하다고 판단하여 goofys 를 사용하게 되었습니다) 그림으로 표현하자면 아래와 같죠. Nginx 가 provisioning 될 때 ConfigMap 으로 init.sh 를 주어 goofys 를 마운트 한 후 실행되도록 했습니다. 이런식으로 말이죠. #!/usr/bin/env sh set -eu wget https://github.com/kahing/goofys/releases/latest/download/goofys chmod +x goofys /goofys /var/nginx ... nginx -g 'daemo..

테라폼은 Code 로 인프라를 구축할 수 있게 도와주는 IaC Tool 입니다. 특히 AWS 인프라를 구축할 때 참 유용하게 사용할 수 있죠. module 을 제공해주기 때문에 어렵지 않게 VPC, EKS, ELB 를 생성하고 코드를 관리 할 수 있습니다. 이번 글에서는 테라폼을 이용해 EKS 를 구축하는 과정에서 겪은 문제점과 이를 해결했던 방법에 대해 이야기 해볼까 합니다. 우선 Apply!! terraform-aws-eks 에 가보면 아주 친절하게 테라폼을 이용해 EKS 를 구축할 수 있는 방법에 대해 알려줍니다. 무작정 eks 모듈을 import 하고 example 과 EKS Best Practices Guides 참고하여 테라폼 코드를 작성했습니다. provider "kubernetes" { h..