쿠버네티스 노드를 붙이고 CAS 라벨까지 걸었는데 CAS 워커가 새 노드에 뜨지 않는 것은 정상이다. CAS 워커는 DaemonSet 이 아니라 CASDeployment 커스텀 리소스의 spec.workers 값만큼 cas-operator 가 만든다. 그 값을 늘리지 않으면 파드가 생길 이유가 없다.
이미 떠 있는 워커가 새 노드로 옮겨 가지도 않는다. 쿠버네티스는 실행 중인 파드를 재배치하지 않는다.
kubectl -n <namespace> get casdeployments
kubectl -n <namespace> get casdeployment <CAS_NAME> -o yaml | grep -A5 'spec:'
kubectl -n <namespace> get pods -o wide -l 'casoperator.sas.com/node-type=worker'
레이블 키는 배포 버전에 따라 다르다. 찾지 못하면 실제 파드에서 확인한다.
kubectl -n <namespace> get pod <cas-worker-pod> --show-labels
운영 중에 바로 반영해야 할 때 쓴다.
kubectl -n <namespace> patch casdeployment <CAS_NAME> \
--type=json -p='[{"op":"replace","path":"/spec/workers","value":6}]'
/spec/workers 키가 아직 없으면 replace 대신 add 를 쓴다.
이 변경은 임시다. 다음 번에 kustomize 로 다시 배포하면 원래 값으로 돌아간다.
배포 자산의 예제 트랜스포머를 site-config 로 복사해 값을 고치고 kustomization.yaml 에 등록한다.
$deploy/sas-bases/examples/cas/configure/cas-manage-workers.yaml
→ $deploy/site-config/cas-manage-workers.yaml
직접 작성해도 된다.
apiVersion: builtin
kind: PatchTransformer
metadata:
name: cas-manage-workers
patch: |-
- op: replace
path: /spec/workers
value: 6
target:
group: viya.sas.com
kind: CASDeployment
name: <CAS_NAME>
transformers:
- site-config/cas-manage-workers.yaml
kustomize build $deploy | kubectl apply -f -
(확인 필요) — 트랜스포머의 target.group 과 예제 파일 경로는 Viya 릴리스에 따라 다르다. 실제 배포 자산의 sas-bases/examples/cas/configure/ 아래를 열어 그 릴리스의 형태를 확인하고 쓴다.
수를 늘렸는데 파드가 뜨지 않으면 스케줄링 조건이다. 원인은 describe 의 Events 에 그대로 찍힌다.
kubectl -n <namespace> describe pod <pending-pod> | sed -n '/Events/,$p'
| 메시지 | 원인 |
|---|---|
node(s) didn't match Pod's node affinity/selector |
새 노드에 CAS 노드 라벨이 없다 |
had taint ... that the pod didn't tolerate |
노드 테인트에 대응하는 toleration 이 없다 |
Insufficient cpu · Insufficient memory |
노드 여유가 워커의 requests 보다 작다 |
didn't match pod topology spread constraints |
분산 제약에 걸렸다 |
CAS 노드에는 보통 workload.sas.com/class=cas 라벨과 같은 키의 테인트를 쓴다. 기존 CAS 노드의 라벨을 그대로 복사해 새 노드에 건다.
kubectl get node <OLD-NODE> --show-labels | tr ',' '\n' | grep sas
kubectl label node <NEW-NODE> workload.sas.com/class=cas
kubectl taint node <NEW-NODE> workload.sas.com/class=cas:NoSchedule
CAS 워커는 보통 노드 한 대를 통째로 쓰도록 크게 요청한다. 노드의 Allocatable 이 그보다 작으면 영원히 Pending 이다.
kubectl describe node <NEW-NODE> | grep -A6 Allocatable
워커를 늘려도 이미 메모리에 올라와 있는 테이블은 자동으로 재분배되지 않는다. 새 워커는 놀고 기존 워커만 계속 일하는 상태가 되어, 늘린 효과가 다음 적재부터 나타난다. 자동 재분배를 켜는 환경 변수가 있으며 기본값은 꺼짐이다.
- name: CAS_GLOBAL_TABLE_AUTO_BALANCE
value: "background"
- name: CAS_SESSION_TABLE_AUTO_BALANCE
value: "true"
cas-add-environment-variables.yaml 예제를 복사해 넣는다. (확인 필요) — 이 두 변수의 이름과 허용 값은 릴리스에 따라 다르므로 해당 버전의 배포 문서로 확인한다. 자동 재분배를 켜지 않을 것이라면, 워커를 늘린 뒤 테이블을 내렸다가 다시 올리는 절차를 운영 순서에 넣는다.
kubectl -n <namespace> get pods -o wide | grep cas
CAS 가 실제로 인식한 워커 수는 서버 쪽에서 본다.
proc cas;
builtins.serverStatus;
quit;