SAS Studio 에서 코드를 실행하면 Launcher 가 Compute 세션 파드를 하나 만든다. 파드 안에는 sas-programming-environment 컨테이너와 함께 인증서 초기화, 설정 초기화, SSSD, 프로세스 익스포터 컨테이너가 같이 뜬다. 세션이 끝나면 파드도 사라진다.
동시 사용자가 늘면 다음과 같은 로그가 나온다.
Creating a new server with the ID ...
waiting before the 60 second timeout was reached
The process initialization for the Compute server failed
Compute service could not cancel the process within the ID ...
그런데 kubectl get pod 로 보면 Compute 파드는 Running 이다. 컨테이너가 죽은 것이 아니라 세션 준비 완료 신호가 제한 시간 안에 오지 않아 컨트롤 플레인이 실패로 판단한 상태다. 결과적으로 사용자는 실행이 멈춘 것처럼 보이고, 정리되지 않은 고아 파드가 쌓인다.
원인은 대개 다음 중 하나다.
먼저 볼 것은 다음과 같다.
kubectl logs -n <namespace> <compute-pod> -c sas-programming-environment
kubectl top node
kubectl top pod -n <namespace>
kubectl get pod -n <namespace> | grep sas-compute-server
고아 파드가 쌓여 있으면 정리하고, 노드 리소스와 스토리지 응답을 확인한 뒤 제한 시간 조정을 검토한다.
Compute 세션 파드의 리소스는 두 곳에서 정해지며 파드 템플릿에 정의된 값이 우선한다.
| 위치 | 설명 |
|---|---|
파드 템플릿(sas-compute-job-config) |
실제 적용되는 값 |
| Launcher 서비스 전역 속성 | 파드 템플릿에 값이 없을 때의 기본값과 최댓값 |
현재 값은 실제 파드에서 확인하는 것이 가장 확실하다.
kubectl -n <namespace> get podtemplate sas-compute-job-config -o yaml | grep -A8 resources
kubectl -n <namespace> describe pod <compute-pod> | grep -A6 "Limits\|Requests"
기본값은 릴리스와 배포 템플릿에 따라 다르므로 문서의 숫자를 그대로 믿지 않고 환경에서 직접 읽는다 (확인 필요).
사용자나 업무별로 다른 리소스를 주려면 Compute 컨텍스트를 나눠 쓴다. 작업 성격에 따라 small · medium · large 컨텍스트를 만들어 두면 큰 작업이 일반 세션을 밀어내는 일을 줄일 수 있다.
XCMD 는 SAS 세션에서 OS 명령을 실행하는 기능이다.
data _null_;
rc = system("ls -al");
run;
X 문, call system(), filename pipe 가 여기에 해당한다. SAS 9 에서는 -xcmd 옵션을 주지만, Viya 4 에서는 Launcher 의 lockdown 설정으로 제어한다. Compute 파드에는 sas-launcher-lockdown-config ConfigMap 이 주입돼 있다.
활성화 방법은 sas-bases/examples/sas-programming-environment 아래의 XCMD 관련 예제를 site-config 로 복사해 적용하는 것이다. 예제 파일 이름과 설정 키는 릴리스에 따라 다르므로 실제 배포 자산에서 확인한다 (확인 필요). 대화 기록에 나온 SASComputeServer 커스텀 리소스의 allowXCMD 형태는 확인되지 않았다.
적용 후 세션에서 확인한다.
proc options option=xcmd;
run;
XCMD 를 켜면 세션 사용자가 컨테이너 안에서 OS 명령을 실행할 수 있게 된다. 파일 삭제와 마운트된 공유 스토리지 접근이 가능해지므로 운영 환경에서는 기본적으로 끄고, 필요한 컨텍스트에만 제한적으로 연다.