API Priority and Fairness
어제 누군가가 k8s api 에 get, list verbs로 reqeusts를 분당 1억번 이상 호출하여 cpu 사용률이 높아져서 audit log를 확인해보니 특정 user가 호출한 것으로 확인 됨. api server에 대한 limit을 하려고 하니 대부분 api gateway를 사용하여 제한을 거는 방법 말고도 k8s api server에서도 limit에 대한 정책이 있지 않을까 해서 찾아봄.
api priority and Fairness && flow control 은 k8s 1.16 부터 있었음.
아래와 같은 이유로 해당 옵션이 제공 되었다고 함.
###
요청이 증가하는 기간 동안 과부하가 발생하지 않도록 보호하기 위해 API 서버는 특정 시간에 처리할 수 있는 진행 중인 요청 수를 제한합니다. 이 제한을 초과하면 API 서버는 요청을 거부하기 시작하고 "요청이 너무 많음"에 대한 429 HTTP 응답 코드를 클라이언트에 반환합니다. 서버가 요청을 삭제하고 클라이언트가 나중에 다시 시도하도록 하는 것이 요청 수에 대한 서버 측 제한을 두지 않고 제어 플레인에 과부하를 주어 성능이 저하되거나 가용성이 저하될 수 있는 것보다 더 좋습니다.
###
flowschemasb 및 priorityLebelConfigurations 는 절대적인 수로 제한을 거는게 아니라 비율에 따라 request 동시 요청 갯수를 관리하는 거임 계산 공식은 아래와 같음.
$ kubectl get prioritylevelconfigurations.flowcontrol.apiserver.k8s.io
NAME TYPE ASSUREDCONCURRENCYSHARES QUEUE HANDSIZE QUEUELENGTTHLIMIT AGE
catch-all Limited 5 <none> <none> <none> 490d
exempt Exempt <none> <none> <none> <none> 490d
global-default Limited 20 128 6 50 490d
leader-election Limited 10 16 4 50 490d
system Limited 30 64 6 50 490d
workload-high Limited 40 128 6 50 490d
workload-low Limited 100 128 6 5 490d-max-requestd-inflight=400 (default)
계산 공식:
(max-requestd-inflight + max-mutating-requests-inflight) / (Total priorityLevelconfigurations, ASSUREDCONCURRENCYSHAERS) * (Current priorityLevelConfigurations, ASSUREDCONCURRENCYSHAERS)
flowschema 가 어떤 resource 의 요청에 대해 정의를 한다면
prioritylevelconfiguration 은 제한은 어떠한 동작으로 할 것인지 정의 하는 것이다.
—-
apiVersion: flowcontrol.apiserver.k8s.io/v1beta1
kind: PriorityLevelConfiguration
metadata:
name: catch-all
spec:
type: Limited
limited:
assuredConcurrencyShares: 5
limitResponse:
queueing:
handSize: 4
queueLengthLimit: 50
queue: 16
type: Queue
* 총 900개 동시 요청이 들어왔을때 15개 요청은 바로 처리되며 나머지 875개 요청 중 (queueLengthLimit * queues) 800 개 요청 중 (handSize * queueLimit) 200개 요청은 대기열로 설정되어 큐에 대기하고 있다가 처리되고 나머지 75개는 reject 발생하게 함 (429 에러)
총평: APF 를 설정하면 외부 api-reqeusts 요청에 대해 컨트롤 할 수 있으나, 내부 시스템에서 쓰는 요청도 같이 변경되는 구조임. (비율 구조이기 때문에) 공식 가이드 문서에서도 쿠버네티스 API 사용에 대해서는 데이터량을 인수를 통해 제한하라고 나와있음. 사용자의 api requests 제한은 정책적으로 막거나 ap-gateway를 통해 pi service를 제공하고 limit 정책을 거는게 효율적임.
참조:
https://blog.palark.com/kubernetes-api-flow-control-management/