[책읽기] Kubernetes Best Practices 쿠버테니스 모범 사례 - 오라일리, 한빛미디어

근황먼저.

 

2년전쯤부터 한컴싸인(https://www.hancomsign.com)이라는 웹서비스를 개발하다, 그 조직이 직무별로 쪼개지면서 개발팀장을 하다, 최근 더 흥미로운, 혹은 변화가 많은? 조직으로 이동하여 현재는 팀원을 하고 있다.

 

그전 AI를 하던때부터 지금까지 많은 책들을 읽었는데, 정리할 시간이 없어 오랜만에 일찍 퇴근한 김에 읽었던 책들중 몇권을 순차적으로 정리해 본다. 오래전에 읽었던 책들도 있어서, 지금 이 글을 읽는 사람에게는 이미 오래된 책일 수 있이라 도움이 될런지 모르겠지만, 그래도 읽은 티라도 내 보려고 대충 정리해 본다. 그러니 걍 그런가 보다 하자.

 

제목 : Kubernetes Best Practices 쿠버테니스 모범 사례 - 오라일리, 한빛미디어

책 읽기

• 이 책은 초보자용 책이 아니다. 이미 쿠버네티스의 개념과 동작에 대해서 잘 파악하고 있는 사람이 실제 문제들을 어떤식으로 해결할 수 있을지에 대한 정보를 주는 책이다. 물론 그렇다고 정답을 주는것은 아니지만, 어떤 점들을 고려해야 하고 어떤식으로 해결 할 수 있을지 정도를 알려 준다.
• Best Practices-모범사례를 살펴보는것의 좋은점은, "이런걸 하고 싶을때는 어떻게 하지?" 라던지, "이런 경우에는 어떻게 문제를 해결하지?" 라던지 혹은 생각하지도 못한 상황에 대해서 미리 생각해 보고, 대비할 수 있게 해 준다는 점이다. 막상 닥치면 또 적당히 알아서 잘 하겠지만, 그래도 "이렇게 해결해도 되는거야?"에 대한 스스로에 대한 의심을 조금 걷어내 줄 수 있다는 점이 좋다.
• 책은 설치부터 어드미션 컨트롤러까지 거의 모든 부분을 커버하고 있다. 책 한권에 이걸 다 커버할 수 있나? 라는 생각이 든다면 정확하다. 그렇기 때문에 이 책은 초보자용 책은 아니다.

책의 모든 내용을 옮기는것은 문제가 되기도 하고, 나도 그럴 시간도 없으니 이 책에 나오는 주요 내용 몇개만 정리해 보겠다. 그리고 내 경험과 생각도 살짝 추가해 둔다. 만약 아래 내용을 보고 "오~ 그럴듯하게 정리되어 있네?" 싶다면, 책을 구매해서 차근히 읽어 보도록 하자.

모범사례 (중 일부...)

• 개발하는 도중에는 latest tag를 사용해도 되나, 실제로 배포하는 운영환경에서는 명확한 tag를 사용하도록 하자.
  • 찬 : 이건 사실 CI 쪽에서 잘 해 줘야 한다. 나 같은 경우에는 빌드가 나올때도 빌드번호, 커밋ID, 브랜치이름, 배포환경의 값을 모두 조합해서 tag 이름을 매겼었다. 같은 branch에 같은 commit 이라고 해도, 배포환경이 다른 경우 다른 빌드 결과물이 나올 수 있기 때문이다. 물론 develop branch의 경우에는 tag를 latest로 매겨 로컬 개발환경에서는 누구든 항상 최신의 이미지를 사용할 수 있도록 했다.
• 사용자 혹은 목적에 따라 namespace를 분리해라. 그래야 관리가 편하다.
• 매트릭, 로깅을 잘 관리하자. 쿠버네티스 시스템의 "문제 신호"를 감지 할 수 있고, 상황을 잘 알려(슬랙 따위로 알림) 줄 수 있어야  안정적으로 클러스터를 운영할 수도 있고 웹서비스의 문제점도 잘 파악할 수도 있다. 이런 정보를 수집하고 관리하는 애들은 웹서비스들이 모여 있는 클러스터에 같이 두지 말고, "모니터링 클러스터"를 따로 만들자.
  • 찬 : 여기서는 쿠버네티스단에서 관리 혹은 추출할 수 있는 정보들만 이야기 하고 있다. 예를들면 Istio 따위를 통해서 트래픽이 전달된다면, 그곳의 출입구만 확인하면 트래픽이 들어 왔다가 나가는데 얼마의 시간이 걸렸는지 혹은 Http라면 어떤 응답을 했는지 따위를 알 수 있을거다. 하지만 웹서비스 레벨의 메트릭은 자동으로 수집되지 않으므로, 필요하다면 웹서비스에서 적절하게 처리해 줘야 한다. 예를 들면, Spring의 경우 actuator를 추가하여 "모니터링 클러스터"에 있는 Prometheus 에게 전달 할 수 있도록 수동으로 설정해 줘야 한다.
• configmap 따위를 변경했다고 해서 바로 Pod 에 적용되는게 아니므로, 반드시 Pod를 내렸다 올리는 수준의 작업을 해 줘야 한다.
  • 찬 : 이건 어찌 생각해 보면 당연한거다. Pod가 뜰때 ENV 값들이 셋팅되고 그 이후에 Pod에 있는 command 가 실행된다. 보통 프로그램을 작성할때 딱 한번만 ENV 값을 읽어오고, 이후에는 그냥 사용만 하도록 만든다. 그러므로 ENV 값을 동적으로 바꾼다고 해도 적용되지 않는 경우가 대부분이다. 만약 이 값이 동적으로 바뀐다면 프로그램이 오동작하는 경우도 매우 만을 것이다.
• 클러스터에 있는 많은 Node(컴퓨터)들은 각자 상황이 다를 수도 있다. 그러므로 Pod들을 적절한 Node에 배치 될 필요가 있다. 이런걸 강제하고 싶은 경우는 Node에 Label을 주고, nodeSelector 를 이용하거나, 혹은 tolerations 를 사용해 Pod가 제대로 된 Node에 배치 될 수 있도록 조정해 줘야 한다.
  • 찬 : 예를들어 어떤 컴퓨터는 GPU가 달려 있을 수도 있고, 어떤 컴퓨터는 낮은 버전의 CPU가 달려 있어서, CPU 명령어중 avx2가 지원되지 않을 수도 있다. ( 관련글 : [PyTorch] x86 CPU에서 양자화(Quantization) 관련 실행시 에러가 나는 경우 - Didn't find engine for operation quantized::conv_prepack NoQEngine ) 그러므로 Pod들은 "적절한 node"에 배치될 필요가 있으므로, 그런 경우에는 이런걸 활용하면 된다.
• 애플리케이션이 확장될 필요가 있을 때는 HPA-수평확장-쉽게 말하면 걍 Pod 갯수 늘리기를 하는게 좋다. VPA-수직확장-쉽게말하면 CPU랑 RAM늘리기도 가능하겠지만 추천되지 않고 있으니 아예 할 생각을 말자.
• 웹서비스의 로그를 출력하는 곳이 로컬 디스크인지 확인하고, 그렇다면 stdout이나 stderr로 빼도록 하자.
  • 찬 : 로컬디스크에 로그가 출력되면, Pod가 내려가면 로컬 디스크도 같이 없어지므로 로그를 구할 수 없다. 만약 로컬이 아니라 네트워크 디렉토리에 출력한다고 해도, "그 파일을 다시 S3 따위의 장기간 저장소"로 옮겨줘야 하는것을 웹서시브측에서 구현해야 하는 문제가 있다. 웹서비스를 개발한다면 로그의 출력을 stdout과 stderr로 보내도록 하고, 쿠버테이스(혹은 클러스터) 관리자에게, "로그 좀 알아서 잘 모아 주세요." 라고 요청하자. 그러면 그 관리자가 여유가 된다면, "검색"도 할 수 있도록 ElasticSearch(혹은 OpenSearch)따위에 알아서 올려 줄 거다. 그러니 웹서비스 개발자라면 "제발!!!!" 로그를 걍 stdout과 stderr에 출력하도록 하자.
• 찬 : 요건 책에 나와 있는지 모르겠지만, 생각났으니 써 본다. 제발!!!!! 웹서비스를 만들때, 배포 환경에 따라 달라 질 수 있는 값들은 모두!!!! 환경변수로 빼 두자. 이걸 한번 해 두면, 배포하는 사람이 알아서 내가 만든 웹서비스를 이리저리 설치해서 배포할 수 있다. 만약 이런걸 코드에 박아둔다면, 배포하는 환경마다 매번 코드를 수정해야 하고, 매번 빌드를 새롭게 만들어서 전달해야 할 것이다. 그러니 코드를 짤 때 부터, 각종 URL, KEY, ID, Password, Email 주소등 변경 될 법한 것들에 대해서 모두 고려하는것이 좋다.

오늘 시간 난김에 읽은 책을 몇개 더 정리하려고하니.. 요 정도로 끝.