실제로 Kubernetes를 운영해야 하는 사람들을 위한 가이드

Kubernetes 튜토리얼은 pod 배포 방법을 가르칩니다. 하지만 노드가 갑자기 Ready 상태를 벗어나고 온콜 폰이 울리지 않게 하는 방법을 가르치는 튜토리얼은 없습니다. 이 가이드는 그 두 번째 부분입니다.

리소스 요청과 한계는 선택 사항이 아닙니다

컨테이너에 resources.requests와 resources.limits를 설정하지 않으면 스케줄러가 추측으로 작동하고, kubelet은 노드의 메모리가 부족할 때 어떤 pod을 먼저 제거해야 할지 알 수 없습니다. requests는 컨테이너가 정상 부하 상황에서 실제로 사용하는 값으로 설정하세요. 희망하는 값이 아니라요. 메모리 한계는 requests에 가깝게 설정하세요. OOM으로 종료된 pod은 깔끔하게 재시작되기 때문입니다. 하지만 CPU 한계는 일반적으로 더 느슨하거나 없어야 합니다. 시끄러운 이웃 문제와 싸우고 있지 않다면 말이죠. 하드 한계로 인한 CPU 스로틀링은 디버그하기 힘든 지연 시간 급증을 일으킵니다. kubectl top pods -n your-namespace를 정기적으로 실행하고 선언한 값과 비교하세요. 몇 개 이상의 서비스가 있는 클러스터에서는 불일치가 빠르게 쌓입니다.

etcd는 전체 클러스터입니다. 그렇게 취급하세요

Kubernetes가 아는 모든 것은 etcd에 살아있습니다. etcd를 잃으면 일부 메타데이터가 아니라 클러스터 상태 전체를 잃습니다. 스케줄에 따라 etcdctl snapshot save /backup/etcd-snapshot.db를 실행하고, 최소한 한 번은 스크래치 클러스터에서 실제로 복구를 테스트하세요. 3개월 동안 손상된 것으로 밝혀진 야간 백업을 가진 팀들을 봤습니다. 아무도 검증하지 않았기 때문입니다. 관리형 컨트롤 플레인(EKS, GKE, AKS)을 사용하고 있다면 etcd를 직접 관리하지 않지만, 여전히 문제 상황이 발생했을 때가 아니라 미리 공급자의 백업 및 복구 절차를 알아야 합니다.

살성 프로브와 준비 프로브는 때로 의견이 달라야 합니다

흔한 실수는 살성 프로브와 준비 프로브 모두에 같은 엔드포인트를 사용하는 것입니다. 살성 프로브는 다음에 응답해야 합니다