Kubernetes HPA 사용시 마주칠 수 있는 문제들

이준석·2022년 9월 7일
1

Infra

목록 보기
5/5
post-thumbnail
post-custom-banner

서론

현재 저는 AWS EKS (kubernetes v1.21) 를 이용해서 쿠버네티스 클라우드 서비스를 이용하고 있고, 배포 방식은 Argo CD 를 이용해서 사용하고 있습니다. 그래서 이번에 Kubernetes HPA 를 이용해서 자동으로 Scale out, down 을 하기 위해서 적용을 해보았고, 적용하는 가운데 만난 2가지 큰 문제에 대해서 다뤄볼 예정입니다.

본론

1. Volume Mount 오류

오류 내용은 다음과 같습니다.

Error: cannot find volume “kube-api-access-v9cmd” to mount into container “my-api-server”

해당 문제는 비교적 손쉽게 해당 링크에서 해결 방법을 발견하였습니다.

현재 Pod 들이 사용하고 있는 Service Account (SA)automountServiceAccountToken 값을 false 로 지정해주기만 하면 됩니다. 별도로 SA 를 만들지 않는 이상 각 네임스페이스에는 defaultSA 가 존재하고 Pod 들은 해당 SA 를 사용합니다.

만약 Pod 에 어떤 SA 를 사용하고 있는지 알고 싶으시면 다음 명령어로 확인하실 수 있습니다.

$ kubectl edit pod <pod이름> -n <네임스페이스>
ex) kubectl edit pod php-apache -n php

따라서 아래로 내리다보면 다음 설정값이 보일꺼고 해당 내용에 적힌 값이 사용중인 SA 입니다.

serviceAccount: default
serviceAccountName: default

SA 를 확인했으면 해당 SA 설정을 편집하기 위해 다음 명령을 입력해줍니다.

$ kubectl edit sa default -n php
apiVersion: v1
automountServiceAccountToken: false  <-- 추가
kind: ServiceAccount

# (생략)

해당 값을 추가하면 더이상 Volume Mount 오류는 발생하지 않는다.

2. Pod가 생성되자마자 바로 종료되는 이슈

문제를 해결한 과정을 서술하고 있습니다. 필요 없으신 분들은 아래로 쭉쭉 내려서 해결방법만 살펴보셔도 상관없습니다!

위의 과정을 해결해서 정상적으로 Pod 가 생성되는지 확인하기 위해서 부하를 주었는데 이게 왠걸... Pod 가 생성되자마자 바로 종료돼버리는 것이었다.

원인을 찾지 못하고 하루를 날려버렸고, 원론적인 부분부터 해결하기 위해 쿠버네티스 공식 홈페이지 HPA를 정독했다. 지식은 얻었지만 해결 방법은 찾지 못했다.

그리고 Argo CD 를 이용해서 Canary 배포를 하고 있기 때문에 YAML 파일 버전이 조금 다르다. (이전 포스팅 참고) 따라서 해당 파일에 맞는 HPA 공식문서를 다시금 정독하고 있었다. 여기서 한가지 키포인트를 잡은게 ReplicaSet 베이스로 HPA 가 작동한다라는 포인트를 얻고 내가 배포한 Argo CD ReplicaSet 설정 파일을 살펴보았더니 한가지 어노테이션이 눈에 밟혔다.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  annotations:
    rollout.argoproj.io/desired-replicas: '1'

desired-replicas 값이 1이라고 적혀있는데, 해당 값에 따라서 ReplicaSet 에 생성될 Pod 의 개수를 정하게 된다. 따라서 테스트를 진행하면서 해당 값을 계속 모니터링 한 결과 계속해서 1로 고정이 되는 이슈가 있었다. (정확히는 숫자가 바뀌었다가 새로고침 되면서 다시 1로 싱크가 되었다.)

그리하여 좀 더 검색을 한 결과 해당 링크에서 나와 똑같은 증상을 가진 사람을 찾게 되었고 나온 해법대로 한 결과 말끔히 해결되었다.

해결 방법은 다음과 같다.

자신이 사용하고 있는 Deplyment YAML 파일에 spec.replicas 값이 설정되어있는지 확인해본다. 해당 값이 설정되어 있으면 해당 값으로 고정되기 때문에 HPA 를 사용하는 의미가 없어진다. 해당 방법은 놀랍게도 Argo CD 공식 문서 Best Practice 에 나와있었다. (YAML 파일에 주석을 읽어주세요)

따라서 해당 한 줄 만 지워주면 말끔히 Pod 가 생성되었다가 시스템이 안정이 되면 약 5분 ~ 6분 시간이 흐른뒤에 파드를 종료시킨다.

저는 부하 테스트를 진행할 때 다음 명령어를 이용해서 진행했는데, 쿠버네티스 공식 홈페이지에서 사용하는 방식이고 클라우드에서 내부 통신으로만 통신할 경우 과금되지 않는 다는 것으로 알고 있어서 해당 방식을 채용하였습니다.

  • 적절하게 자신에게 맞는 방식으로 수정해서 사용하면 됩니다!)
  • 네임스페이스가 별도로 존재하는 경우 네임스페이스까지 명시해주셔야 합니다.)
kubectl -n php run -i --tty load-generator --rm --image=busybox:1.28 --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"

그리고 부하가 잘 수집되고 있는지는 다음 명령으로 확인합니다. (값이 업데이트되면 아래에 새롭게 라인이 추가되면서 업데이트 됩니다.)

$ kubectl get hpa php-hpa -n php --watch
NAME         REFERENCE                     TARGET       MINPODS   MAXPODS   REPLICAS   AGE
php-apache   Deployment/php-apache/scale   0% / 50%     1         10        1          11m

결론

찾아보면 진짜 별거 아닌 문제로 골머리를 앓는게 대부분인거 같다. 어찌보면 오히려 어려운 부분이 오류 검색이 잘되고 상대적으로 잘 해결되는 것 같다. 또한 공식 문서에는 언제나 해답이 존재한다는 것도 이번 문제를 통해서 알게 되었다.

혹시나 이런 문제가 발생한 사람들이 좌절하지 않도록 하기 위해서 해결되는대로 빠르고 블로그에 글을 올립니다.

이만 총총..🏃🏻‍♀️🧞‍♂️

profile
호주 워홀중 https://blog.naver.com/wnstjrl96
post-custom-banner

0개의 댓글