Chapter 16. 쿠버네티스에 마이크로서비스 배포

[minkukjo]

느낀 점

• Kustomize에 대한 내용이 나옴.
• 관련해서 블로그 글을 좀 찾아보니 이런 아티클이 있었음. 매우 좋은 글인게, 첫 줄에 바로 요약이 나옴
• 요약 : 헬름 쓰셈. Kustomize 뻐큐뽀큐
• livenessProbe와 readnissProbe에 대한 설명이 나오는데, 복습할 겸 정리
• livenessProbe : 엔드포인트로 주기적으로 찔러서 해당 서버가 요청이 없으면 다시 실행시킴
• readnissProbe : 쿠버네티스가 이 ReadnessProbe의 경로로 요청했을 때 200인 경우에만 해당 인스턴스에 요청을 보내줌.
• failureThreshold 옵션이 중요한데 몇 번 실패하면 포기할 것인지를 결정하는 옵션이다. livenessProbe의 경우 이 수치를 넘으면 파드를 재실행시키며, readnissProbe는 이 값이 넘은 파드에겐 요청을 다음부터 안보낸다.
• 책에 StatefulSet이 적혀있었는데 기억이 안나서 찾아보니, Pod 상태를 일정하게 유지시켜주는 Controller 였다.
• 책에는 StatefulSet이랑 PersistentVolume을 사용하는 것이 아직은 입증되지않아서 사용하지않는 것을 권장한다고 하는데, 우리 회사에선 DB를 k8s 위에서 운영한다.
• https://www.youtube.com/watch?v=zGKRoM4frXo
• NodePort: 외부에서 해당 서비스로 직접 접근하기 위한 포트
• TargetPort : 서비스가 받아온 요청을 파드로 넘길 때 사용하는 포트
• Port: Cluster 내부에서 사용할 포트

[MinJunKweon]

느낀점

• 네이버에서는 아직 k8s로 DB를 운영하는 조직은 들어본적이 없음.. 민국님 말씀으론 카카오는 이미 그렇게 하고있는 것 같은데, 저희는 장비를 새로 발주해서 사용합니다ㅎㅎ
• k8s로 DB를 운영하면 얻을 수 있는 이점이 많은지는 모르겠음.. DB 특성상 스케일링이 쉽지 않고 안정성이 가장 중요하고, 부하가 집중되는 컴포넌트이다보니 더 조심스러운 느낌
• k8s에서 제공하는 rolling update도 큰 강점이라고 생각함. 쌩판 밑바닥부터 새로 구축하려고하면 까다로운 스펙인데 직관적이고 쉽게 잘 풀어낸 것 같음

[LOG-INFO]

느낀점

• Kustomize 별로 눈길이 안 가서 슥슥 넘겼음
  • 저흰 Helm씁니당
  • 민국님 아티클 공유 & 요약 감사합니다 ㅎㅎ
• liveness-probe랑 readiness-probe 차이 맨날 헷갈렸는데 다시 정리됐네용
  • liveness-probe
  • 앱이 실행이 되었는지 확인
  • 충족 못하면 앱 다시 실행
  • 앱이 점점 커지다가 시작시간이 기존 설정값을 넘어가서 앱이 안 뜨던 적이 있었음
    • initialDelaySeconds, periodSeconds, failureThreshold 값을 잘 조절해줘야 함
    • initialDelaySeconds을 너무 작게 주면 fail 나면서 재시작됨
    • initialDelaySeconds을 너무 크게 주면 앱이 시작된진 오래인데 뒤늦게서야 체크함
  • readiness-probe
  • 앱이 요청 받을 준비가 되었는지 확인
  • 충족 못하면 충족할 떄까지 요청을 보내지 않음
• '상태를 선언'하는 방식, 버전관리시스템을 통해 변경된 것만 새로 배포하는 기능, Rolling Update/Blue-Green 배포 하는 기능 등이 쿠버네티스를 갓버네티스로 만들어준 것 같음
• 요런 게 있었군!
  • kubectl rollout history deployment ???
  • kubectl rollout history deployment ??? --revision=???
  • kubectl rollout undo deployment ??? --to-revision=??
• 스프링 클라우드 유레카 vs 서비스
  • 유레카..는 쿠버네티스 안 쓰는 환경에서 유용할 듯..!
  • 또 다른 장점이.... 있.....을까?
• 쿠버네티스 서비스에서 서비스 이름을 hostname으로 사용할 수 있는 것은 매우 좋은 듯 (유레카도 그렇긴 했지만, 서비스는 http://임)
• 코드형 인프라?

[2rohyun]

느낀점

---

• 이번 장도 쿠버네티스 관련 개념을 익히려고 하였다. ( 실습, 명령어 사용은 개념 조금 더 익히고 … )
• Kustomize 와 Helm 이 무엇을 하는 친구인지 알게되었고, 민국님께서 올려주신 포스트도 도움이 많이 되었다. (감사합니다!)
• 이 책을 진행하면서 각 장에 나오는 주제들 마다 항상 회사는 어떤 방식으로 사용하고 있을까? 하며 찾아보는 재미가 있었는데.. 쿠버네티스 파트로 넘어오면서 DevOps & Infra 레벨에 대해 전혀 모르니 회사에 대입해보기가 쉽지 않다.. 열심히 공부해야지 ...

끄적끄적

---

• 라이브니스 프로브는 스프링 부트 액추에이터의 정보 엔드포인트로 보내는 HTTP 요청에 기반한다. 즉 마이크로서비스가 비정상이라서 정보 엔드포인트가 200으로 응답하지 않으면 쿠버네티스는 마이크로서비스 인스턴스를 다시 시작한다.
• 레디니스 프로브는 스프링 부트 액추에이터의 상태 점검 엔드포인트로 보내는 HTTP 요청에 기반한다. 쿠버네티스는 상태 점검 엔드포인트가 HTTP 상태 코드 200으로 응답하는 경우에만 마이크로서비스 인스턴스에 요청을 보낸다. 일반적으로 마이크로서비스 인스턴스가 관련 자원을 제대로 사용할 수 있을 때 에만 200으로 응답한다. 따라서 상태 점검 엔드포인트가 200으로 응답하지 않으면 마이크로서비스 인스턴스에 요청을 보내지 않는다.
• 속성
  • initialDelaySeconds : 컨테이너가 시작한 후 검사 시작 전까지 쿠버네티스가 대기하는 시간
  • periodSeconds : 쿠버네티스의 검사 요청 간격
  • timeoutSeconds : 쿠버네티스가 검사를 실패한 것으로 처리하기 전에 응답을 기다리는 시간
  • failureThreshold : 쿠버네티스가 검사에 몇번 실패하면 포기할 것인지 지정한다.
  • successThreshold : 쿠버네티스가 실패한 검사를 다시 성공으로 갖누하게 하려면 검사에 몇 번 성공해야 하는지 지정한다.
• 검사 설정을 최적화하는 것은 어려운 작업이다. 파드에 과도한 검사 요청을 보내지 않으면서도 파드의 가용성 변경에 쿠버네티스가 신속하게 반응할 수 있도록 균형을 맞추는 건 쉽지 않다. 라이브니스 프로브에 너무 적은 값을 지정하면 재시작할 필요가 없는데도 쿠버네티스가 파드를 재시작한다. 즉 라이브니스 프로브에 적은 값을 설정한 파드가 많으면 불필요한 재시작 또한 많아진다. successThreshold 이외의 검사 구성 값이 너무 크면 쿠버네티스가 느리게 반응하기 때문에 개발 환경에선 곤란할 수 있다.
• 롤링 업그레이드
  • 개별적으로 업데이트되는 자율적인 마이크로서비스가 증가하고 있는 시스템 환경에서는 잦은 업데이트로 인한 가도 중단이 반복되는 것을 막아야 한다. 즉 비가동 시간 없이 업데이트를 배포할 수 있어야 한다.
  • 롤링 업그레이드는 새 쿠버네티스 파드로 새 버전의 마이크로서비스를 시작하는 것이다. 새 파드에 문제가 없으면 쿠버네티스는 이전 버전을 종료한다.
  • 롤링 업그레이드가 제대로 작동하려면 다른 서비스와의 통신에 사용하는 메시지 형식 및 API나 데이터베이스 구조가 이전 버전과의 호환성을 유지하고 있어야 한다.
  • 디플로이먼트 객체는 기본적으로 모든 업데이트를 롤링 업그레이드로 수행하도록 구성돼 있다.