업그레이드 후 SAS Studio 에서 세션을 만들려 하면 컨텍스트가 잡히지 않고 이 메시지가 뜬다.
cause: 다음 종료 코드로 ID가 "<uuid>"인 컴퓨팅 서버가 실패했습니다: 255
path: /compute/contexts/<context-id>/sessions
255 는 "세션 프로세스가 죽었다" 는 뜻이라 원인이 하나로 좁혀지지 않는다. Job 과 파드가 아예 만들어지지 않았는지, 만들어졌다가 죽었는지 부터 가른다.
kubectl -n <namespace> get jobs --sort-by=.metadata.creationTimestamp | tail -5
kubectl -n <namespace> get pods -l 'sas.com/component=compute-server' \
--sort-by=.metadata.creationTimestamp | tail -5
| 관측 | 갈래 |
|---|---|
| Job · 파드가 0 개 | 런처가 Job 스펙을 조립하지 못했다. 컨텍스트 · 파라미터 ConfigMap 문제 |
| 파드가 생겼다가 곧 사라짐 | 파드 내부에서 초기화 실패. 스토리지 · 라이선스 · 런타임 · 권한 문제 |
세션 파드의 스펙은 여러 ConfigMap 이 합쳐져 만들어진다. 업그레이드 과정에서 일부가 빠지거나 값이 비면 런처가 검증 단계에서 실패하고, 쿠버네티스 이벤트에는 아무것도 남지 않는다.
kubectl -n <namespace> get cm | grep -E 'sas-compute-server-config|sas-compute-parameters|sas-compute-job-config'
kubectl -n <namespace> get cm <sas-compute-parameters-xxxx> -o yaml
kubectl -n <namespace> get cm <sas-compute-job-config-parameters-xxxx> -o yaml
sas-compute-server-config-* 는 SAS 런타임 파일 구성(autoexec, sasv9.cfg, logconfig 등)만 들고 있다. 파드 스펙을 만드는 값은 sas-compute-parameters-* 와 sas-compute-job-config-parameters-* 쪽에 있으므로 이 둘이 비어 있는지 본다.
런처 로그 레벨을 잠깐 올리면 조립 실패 사유가 그대로 찍힌다.
kubectl -n <namespace> set env deploy/sas-launcher LOGGING_LEVEL_ROOT=DEBUG
kubectl -n <namespace> rollout status deploy/sas-launcher
kubectl -n <namespace> logs deploy/sas-launcher --since=10m \
| egrep -i 'create job|job spec|validation|invalid|exception|forbidden'
확인이 끝나면 되돌린다.
kubectl -n <namespace> set env deploy/sas-launcher LOGGING_LEVEL_ROOT-
가장 빠른 복구는 배포 자산의 compute 컨텍스트 예제를 다시 적용하는 것이다.
kustomize build sas-bases/examples/compute-contexts | kubectl -n <namespace> apply -f -
kubectl -n <namespace> rollout restart deploy/sas-launcher
파드가 곧바로 사라져 로그를 못 보면 TTL 을 늘려 둔다.
kubectl -n <namespace> set env deploy/sas-launcher \
COMPUTE_JOB_TTL_SECONDS_AFTER_FINISHED=1800 \
COMPUTE_POD_TTL_SECONDS_AFTER_FINISHED=1800
그다음 컨테이너별로 본다. 초기화 컨테이너에서 이미 실패하는 경우가 많다.
P=$(kubectl -n <namespace> get pods -l 'sas.com/component=compute-server' \
--sort-by=.metadata.creationTimestamp -o name | tail -1 | cut -d/ -f2)
kubectl -n <namespace> describe pod $P | sed -n '/Events:/,$p'
kubectl -n <namespace> logs $P -c sas-compute-file-init --tail=200
kubectl -n <namespace> logs $P -c sas-compute-server --tail=200
자주 걸리는 지점은 홈 디렉터리 마운트 권한, 라이선스 시크릿 누락 또는 만료, Python 등 런타임 경로 누락, 그리고 서비스 어카운트의 Secret·ConfigMap 읽기 권한이다.
런처 서비스 어카운트로 더미 Job 을 서버 검증만 걸어 보면 PSA · 쿼터 · admission 웹훅 문제인지 한 번에 가른다.
cat <<'EOF' | kubectl apply -f - \
--as=system:serviceaccount:<namespace>:sas-launcher -n <namespace> --dry-run=server
apiVersion: batch/v1
kind: Job
metadata:
name: launcher-sa-smoketest
spec:
ttlSecondsAfterFinished: 30
template:
spec:
restartPolicy: Never
securityContext:
seccompProfile:
type: RuntimeDefault
containers:
- name: t
image: busybox:1.36
command: ["sh","-c","echo ok"]
resources:
requests: { cpu: "10m", memory: "32Mi" }
limits: { cpu: "100m", memory: "64Mi" }
EOF
거부되지 않으면 admission 계열은 아니고 런처 내부 조립 단계가 문제다.
이 사례는 대화 기록 안에서 해결되지 않았다. RBAC 확인 결과는 정상 클러스터와 동일했고, 파라미터 ConfigMap 이 비어 보인다는 데까지 좁힌 상태로 끝난다. 같은 증상을 만나면 위 갈래 나누기까지 수행한 뒤 SAS 기술지원에 런처 DEBUG 로그와 실패 파드 이벤트를 함께 전달하는 편이 빠르다.