Viya 4 는 쿠버네티스 위에서 Deployment · StatefulSet 으로 돌아간다. 노드를 재부팅하면 kubelet 이 다시 뜨면서 Pod 도 다시 올라온다. 클러스터를 통째로 정지시키는 절차는 필요 없고, 그렇게 하면 오히려 복구가 더 번거롭다.
다만 그냥 재부팅하면 다음을 잃는다.
/cas/cache 등) — 재부팅 시 비는 것이 정상이다그래서 예정된 작업이면 CAS 를 먼저 정리하고 재부팅한다.
작업 중인 세션을 확인한다. 사용자 작업이 돌고 있으면 먼저 알린다.
kubectl -n <VIYA_NS> get pods | grep -E 'sas-cas|sas-compute'
CAS 를 정상 종료한다. 서버 이름은 기본 배포에서 default 다.
kubectl -n <VIYA_NS> get casdeployment
kubectl -n <VIYA_NS> exec -it sas-cas-server-default-controller -- sas-stop-cas-server
CAS 컨트롤러 Pod 를 그냥 지워도 재기동되지만, 세션을 정리할 기회를 주지 않으므로 위 방법을 먼저 쓴다.
노드를 하나씩 비운다. 여러 노드로 구성된 클러스터라면 순서대로 cordon · drain 해서 Pod 를 다른 노드로 옮긴 뒤 재부팅한다. 단일 노드라면 이 단계는 건너뛴다.
kubectl cordon <NODE>
kubectl drain <NODE> --ignore-daemonsets --delete-emptydir-data --timeout=10m
--delete-emptydir-data 없이는 emptyDir 을 쓰는 CAS Pod 때문에 drain 이 멈춘다.
재부팅한다.
reboot
복귀 확인. 노드가 다시 스케줄 대상이 되게 하고, Pod 가 모두 Running 인지 본다.
kubectl uncordon <NODE>
kubectl -n <VIYA_NS> get pods -o wide | grep -v Running
kubectl -n <VIYA_NS> get casdeployment
sas-readiness Pod 의 로그를 보면 어느 서비스가 아직 준비되지 않았는지 알 수 있다. Viya 전체가 올라오는 데는 수 분에서 십수 분이 걸린다.
kubectl -n <VIYA_NS> logs -l app=sas-readiness --tail=50
노드를 끄는 것이 아니라 Viya 만 멈추려면 배포 전체의 replica 를 0 으로 내린다. 되돌릴 때 원래 개수를 알아야 하므로 먼저 기록해 둔다.
kubectl -n <VIYA_NS> get deployment -o custom-columns=NAME:.metadata.name,REPLICAS:.spec.replicas > replicas.txt
kubectl -n <VIYA_NS> scale deployment --all --replicas=0
kubectl -n <VIYA_NS> scale statefulset --all --replicas=0
배포판에 따라 sas-start-all · sas-stop-all 성격의 스크립트나 CronJob 이 함께 제공되는 경우가 있으므로, 있으면 그쪽을 쓰는 편이 안전하다 (확인 필요 — 설치한 카데나스 버전의 운영 문서를 본다).
내부 PostgreSQL(Crunchy Data) 은 직접 scale 로 내리지 않는다. 오퍼레이터가 관리하므로 임의 조작하면 복구가 어려워진다.