4월 26일 쿠버네티스 온라인 세미나 Q&A _ (1) Maintenance
‘네이버 클라우드 플랫폼의 개발자들은 컨테이너를 어떻게 사용할까?’
지난 4월 26일 진행하였던 쿠버네티스 웨비나에서 많은 분들이 궁금해하신 질문들과 그에 대한 답변입니다. 컨테이너와 도커, 쿠버네티스 활용에 도움이 되셨으면 합니다.
□ Maintenance
Q1.
쿠버네티스에서 제공하는 무중단 서비스(Fault Tolerance)가 HA(High availability)와 차이 나는 부분이 있나요? 아무리 무중단 서비스라 해도 컨테이너가 죽은 몇 초 동안에도 서비스에 장애가 발생할 수 있기 때문에 이러한 부분을 어떻게 무중단 서비스로 해결하는지 궁금합니다.
A1.
컨테이너 오케스트레이션의 경우 Old Version를 유지하면서 New Version이 모두 배포됐을 때 Old Version를 제거하기 때문에 무중단 배포가 가능합니다. 이 방식은 아래 BlueGreen 배포 링크를 참고해주세요.
- High Availability: 고가용성은 긴 시간 동안 운영이 가능한 시스템의 상태를 말하며, 99.9%처럼 퍼센트로 표시합니다.
- Fault Tolerance: 시스템의 결함이 고장으로 이어지지 않도록 하는 것; HA(고가용성)와 매우 유사하지만 중단 시간을 제로로 보장
BlueGreen 배포: https://www.ianlewis.org/en/bluegreen-deployments-kubernetes
Q2.
특정 pod 에서 CPU 나 Memory 선점을 막고자 리소스 limit 값을 설정하고 그 값에 도달하면 사용자 알림이나 재시작 등의 동작을 하고 싶은데 참고할 문서가 있을까요?
A2.
임계치에 대한 알람 기능은 prometheus의 alertmanager(https://prometheus.io/docs/alerting/alertmanager/) 을 이용할 수 있습니다.
Q3.
Readiness Probe로 실패 시 service에서 제외한다고 하셨는데 그럼 제외한 이후 실패한 컨테이너는 그대로 남게 되나요 아니면 종료시키고 다시 시작되나요?
A3.
Readiness Probe는 애플리케이션이 일시적으로 트래픽을 처리할 수 없을 경우에 사용합니다. 애플리케이션을 종료하기를 원하지도 않지만, 트래픽을 보내는 것 또한 의도치 않을 때 사용합니다. 주기적으로 서비스 가능한 상태인지 체크하는 방법으로서, 종료시키고자 한다면 Liveness Probe와 연계하여 사용하셔야 합니다.
Q4.
롤링 업데이트의 버전 관리 최대 수는 얼마이며 주기는 어떻게 되나요?
A4.
Deployment 에서 관리할 수 있는 버전 관리의 수는 기본이 10개이며 spec.revisionHistoryLimit 값을 지정하면 원하는 개수로 관리가 가능합니다.
Kubernetes Service에서 업데이트 주기를 관리하지는 않습니다.
참고: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#revision-history-limit
Q5.
k8s에서 무중단 서비스를 위한 롤링업데이트를 할 때 특정 pod나 컨테이너에 사용자 세션이 유지되고 있다면 강제로 세션을 종료하거나 타임아웃을 설정할 수 있나요?
A5.
쿠버네티스에서 특정 사용자의 연결이 특정 pod에 상태가 유지되길 원하는 경우, 쿠버네티스의 Service에 SessionAffinity를 통해 설정하실 수 있습니다. 기본적으로 ClientIP기반으로 동작합니다. Ingress의 경우에는 세션 사용을 위한 쿠키명을 입력하는 것으로 설정하실 수 있습니다. 세션 유지는 사용자의 앱 설정에 의존성이 있습니다.
Q6.
Kubernetes 에서 IPC 자원도 관리한다고 들었는데 해당 기반에서 컨테이너 간 IPC 통신도 가능한 건가요?
A6.
기본적으로 k8s의 Pod 간 IPC 통신은 별도 설정 없이 되지 않아 이 정책을 따라가고 있습니다.
Q7.
저장된 이미지의 보관 및 삭제 정책,
fail pod의 최대 유지 기간 (문제 원인 분석 등의 목적 등),
이미지의 확대 시 증분인지 새로운 pod 생성인지 궁금합니다.
A7.
Pod의 경우에는 Liveness Probe를 통해 실패한 컨테이너는 제거가 됩니다. 기본값은 10초마다 질의하며, 3번 실패 시 컨테이너를 회수합니다.
이 경우 pod의 로그 또한 제거되며, 로그 확인을 위해 pod를 유지하는 방법보다는 pod의 로그를 외부로 전송하는 방법을 권장해드리고 있습니다. fluentd 등의 솔루션을 연동하여 object storage에 전송하는 방법을 통해 로그 중앙화를 구성할 수 있습니다.
네이버 클라우드 플랫폼에서는 손쉬운 로그 연동을 위해 이후 솔루션 제공 예정에 있습니다. 각 가상머신에 저장된 컨테이너 이미지들은 쿠버네티스의 imageManager에 의해 관리되며, 사용되지 않은 이미지들은 제거됩니다.
내부 설정으로 image-gc-high-threshold, image-gc-low-threshold의 값이 있으며 디스크의 80% 용량을 차지했을 때 삭제를 시도합니다.
Q8.
k8s도 컨테이너로 올라가는 걸로 알고 있는데 k8s로 무중단 업데이트가 가능한가요?
A8.
BlueGreen 배포를 이용하시면 무중단 업데이트가 가능합니다.
BlueGreen 배포: https://www.ianlewis.org/en/bluegreen-deployments-kubernetes
