회의에서 나온 팀원들의 질문을 종합하여 답변을 정리하였습니다.
Knative는 주소를 생성하는 규칙을 가지고 있습니다. 따라서 사용자 함수 배포 요청하는 순간 예측할 수 있습니다. Redis Queue에 배포 요청에 대한 대기열로 하고, 별도의 Endpoint를 사용해 요청 처리 여부를 확인하는 방식을 사용할 수 있습니다.
백엔드 설계가 잘 된 상태라 지금도 지원 가능합니다.
아닙니다. Generic Runner(Image)는 미리 준비된 Runtime Container Image입니다. 함께 좋은 용어를 정하면 좋을 것 같습니다.
Runtime Container Image(Generic Runner)에서 Key를 가지고 있는 사람만 받도록 처리할 수 있습니다. 보다 확실하게는 Ingress에서 처리하는 방법이 있습니다.
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: full-option-runner
namespace: default
# [1] 메타데이터 라벨링 (모니터링/관리를 위해 필수)
labels:
app: my-faas-platform
env: production
spec:
template:
metadata:
name: full-option-runner-v1 # 리비전 이름 고정 (디버깅 용이)
annotations:
# [2] 오토스케일링 설정
# 최소 1개 유지 (Cold Start 방지) ~ 최대 10개 제한
autoscaling.knative.dev/minScale: "1"
autoscaling.knative.dev/maxScale: "10"
# 스케일링 속도 조절 (Panic 모드 진입 방지 등)
autoscaling.knative.dev/scaleToZeroPodRetentionPeriod: "1m" # 0으로 줄어들기 전 대기 시간
spec:
# [3] 컨테이너 설정 (표준 K8s PodSpec)
containerConcurrency: 100 # (Hard Limit) 이 파드는 절대 100개 이상 동시 처리 불가 (503 에러 리턴)
containers:
- image: docker.io/<YOUR_ID>/python-runner:v1
name: user-container
# [4] 리소스 할당 (Resource Quota) - OOM 방지 및 스케줄링 최적화
resources:
requests:
cpu: "100m" # 0.1 코어 보장
memory: "128Mi" # 128MB 보장
limits:
cpu: "500m" # 최대 0.5 코어까지만 사용 가능
memory: "256Mi" # 최대 256MB (넘으면 죽음)
# [5] 환경변수 (Inline Code 등)
env:
- name: CODE_CONTENT
value: |
def handler(event, context):
return {"msg": "This is full option service!"}
# [8] 트래픽 관리 (Canary Deployment 등)
# 새 버전을 배포하더라도 트래픽을 조금씩 옮길 수 있음
traffic:
- tag: latest
percent: 100
latestRevision: true
맞습니다. 최초 생성에는 무조건 하나가 동작하는 상태입니다. 이후 트래픽이 없으면 0으로 줄어듭니다.
사용자가 my-func를 만들어도, 서로 다른 네임스페이스에 있으므로 충돌 X.
user-a의 함수: my-func.user-a.svc.cluster.localuser-b의 함수: my-func.user-b.svc.cluster.localNoisy Neighbor 해결. 사용자 A가 함수를 100개 띄우거나 CPU를 100% 써서 사용자 B의 서비스가 느려지는 것 방지.