AKS에서 파드가 네트워크에 연결하지 못할 때

 

현재 AKS에 NestJS 파드를 올려야 하는 상황이다. 분명히 네트워크 엔드포인트 잘 맞추고, 서비스 잘 올렸는데 자꾸 백엔드에서 DB에 접속을 하지 못하는 이슈가 있었다. 현재 이 상황에서 내가 해본 것들은 다음과 같다.

 

1. Service 포트 확인하기
2. Deployment, Service 라벨 확인하기
3. Pod에 접속해서 curl 날려서 DB 연결 확인하기
4. Azure 가상 머신에 접속하여 이미지 빌드 후 푸시하기
5. 원격 저장소에 있는 이전 이미지 배포하기(이건 잘됨)
6. 클러스터 처음부터 다시 만들기
7. CNI 설정 처음부터 다시하기

 

이정도의 엄청난 삽질을 하고 있었다...그런데 CRI에 대해서 한번 확인해 보라고 주변 분께서 제안해 보셨다. 그래서 CRI에 대해서 잠깐 알아본 이후 바로 확인해 보았다.

 

CRI

---

CRI란 Container Runtime Interface의 약자이다. 쿠버네티스는 기본적으로 컨테이너 애플리케이션을 오케스트레이션 하는 도구이다. 그러므로 도커만 지원하는 것이 아닌 cri-o, containerd, rkt 등의 컨테이너 런타임을 지원한다. 하지만 이러한 런타임 도구들은 여러가지가 있기 때문에 쿠버네티스에서는 CRI라는 표준 규격을 제시하여 다른 컨테이너 런타임 도구들이 CRI에 맞추어 제작되면 알아서 잘 돌아가는 것이다.

 

여기서 알아야 할 것이 도커가 최근 특정 조건에서 유료화 정책을 시작했다. 그래서 특정 쿠버네티스 클러스터 서비스들은 기본적으로 도커를 지원하지 않는 경우도 생기기 시작했다는 것이다. 여기서 무언가 잘못되었음을 느꼈다.

 

https://learn.microsoft.com/ko-kr/azure/aks/cluster-configuration

AKS(Azure Kubernetes Service)의 클러스터 구성 - Azure Kubernetes Service

해당 문서를 보면 aks 클러스터에서 docker는 사용 중지되고 있으며, 2023년 5월(다음달???) 부터는 지원하지 않는 다는 문서를 보았다. 나는 지금까지 docker를 사용해서 이미지를 빌드한 이후 acr에 업로드하여 테스트하고 있었다. 지금까지 헛수고만 하고 있었다는 것이다.

 

해결하기

---

그래서 어떻게 해결했나. 답은 containerd를 사용하거나 acr를 사용하는 것이다. containerd는 컨테이너 런타임 중의 하나로서, 도커도 사실 근간은 containerd 위에서 돌아가는 애플리케이션이다. 여튼 containerd를 사용해서 빌드를 해도 되지만, 이미 az-cli 환경이 익숙하고 내 pc에 설치되어 있어서 acr 명령어를 통해서 빌드 이후 원격 레포지토리에 푸시하는 편이 좋아 보였다. 상식적으로 azure에서 제공하는 서비스끼리 호환이 되지 않으면 문제가 심각하지 않겠는가? 라는 생각으로 진행했다...

 

az acr build \
  --image myregistry.azurecr.io/my-image \
  --registry myregistry \
  --file Dockerfile \
  .

예시로 로컬의 Dockerfile을 사용해서 빌드 후 푸시했다. 이후에 쿠버네티스 클러스터에 deploy하니 잘된다...5일동안 삽질한게 너무 허무하게 끝나버렸다. 여기서 내가 docker를 써도 된다고 믿었던 이유는 정상적으로 실행은 되었기 때문이다. docker exec 명령어로 접속하면 접속은 잘되는데 네트워크 관련해서 계속 문제가 생기고 결국 죽텔죽...아니 계속 죽어버리는 문제가 생겼다.

 

이번 일을 계기로 CRI의 중요성에 대해서 알게 되었고, 쿠버네티스의 트러블 슈팅에 대해서 조금 더 잘 알게 되었다.