测验：标签开到哪里，Operand 才起到哪里

GPU Operator 에서 '오퍼레이터' 와 '오퍼랜드' 의 관계를 바르게 말한 것은?

• 오퍼레이터는 ClusterPolicy 를 지켜보는 컨트롤러이고, 오퍼랜드는 그것이 만들어 관리하는 드라이버·툴킷·장치 플러그인 같은 데몬셋들이다
• 오퍼레이터는 노드마다 하나씩 도는 데몬셋이고, 오퍼랜드는 그 데몬셋이 실행하는 초기화 컨테이너들을 가리킨다
• 오퍼레이터는 Helm 차트가 만드는 잡이고, 오퍼랜드는 설치가 끝난 뒤 남는 ConfigMap 과 Secret 을 가리킨다
• 오퍼레이터와 오퍼랜드는 같은 것을 부르는 두 이름이라, ClusterPolicy 를 지우면 둘 다 함께 사라진다

노드 한 대에만 드라이버 오퍼랜드를 올리지 않으려면 어떻게 하는가?

• ClusterPolicy 의 driver.enabled 를 false 로 바꾸고 다른 노드에는 driver.enabled=true 를 어노테이션으로 덧붙인다
• 그 노드에 nvidia.com/gpu.deploy.driver=false 라벨을 붙인다 — 드라이버 데몬셋의 nodeSelector 가 값 "true" 만 받는다
• 드라이버 데몬셋에 그 노드를 가리키는 NoSchedule 테인트를 걸어 데몬셋 파드만 걸러지게 한다
• 그 노드에서 nvidia.com/gpu.present 라벨을 지워 오퍼레이터가 GPU 노드로 세지 않게 한다

데몬셋의 status.desiredNumberScheduled 만 보고 '오퍼랜드가 다 떴다' 고 판정하면 안 되는 이유는?

• 그 값은 데몬셋 생성 시점에 한 번 계산되고 노드가 늘어도 갱신되지 않기 때문이다
• 그 값은 파드가 Ready 가 된 수만 세므로, 아직 준비되지 않은 파드가 있는 노드가 빠지기 때문이다
• 그 값은 컨트롤러가 뜰 만하다고 판단한 노드 수라, 톨러레이트되지 않는 테인트가 있는 노드는 애초에 세지지 않기 때문이다
• 그 값은 네임스페이스 전체 데몬셋의 합이라 오퍼랜드별로 나눠 볼 수 없기 때문이다

어떤 노드에 장치 플러그인은 도는데 컨테이너 툴킷이 없다. 겉으로 드러나는 증상은?

• 장치 플러그인 파드가 CrashLoopBackOff 로 재시작을 반복하며 kubelet 로그에 런타임 등록 실패가 남는다
• 노드가 NotReady 로 바뀌고 스케줄러가 그 노드를 후보에서 빼면서 GPU 파드가 다른 노드로 몰린다
• kubelet 이 확장 자원 등록을 거부해 그 노드의 nvidia.com/gpu capacity 가 0 으로 보고된다
• 자원은 광고되고 파드도 그 노드에 스케줄되는데, 워크로드만 장치를 잡지 못한다

실습 환경에서 어떤 오퍼랜드 데몬셋의 nodeSelector 라벨을 노드에서 내렸다. 데몬셋 자체는 건드리지 않았다. 무슨 일이 일어나는가?

• 데몬셋의 다음 롤아웃이 일어날 때까지 파드는 그대로 남고, 롤아웃이 시작되면 그 노드만 건너뛴다
• 데몬셋 컨트롤러가 조건과 실제를 다시 맞추면서 그 노드의 파드를 지운다
• 파드는 남지만 Ready 조건이 False 로 바뀌고 서비스 엔드포인트에서만 빠진다
• 노드에 NoExecute 테인트가 자동으로 걸리고 그 노드의 모든 파드가 함께 퇴거된다

드라이버가 이미 호스트 이미지에 구워져 있는 클러스터를 GPU Operator 로 운영할 때 맞는 설명은?

• 오퍼레이터가 호스트 드라이버를 감지해 자동으로 드라이버 데몬셋을 건너뛰므로 별도 설정이 필요 없다
• 드라이버 데몬셋을 그대로 두어도 컨테이너 안에서만 모듈이 올라가므로 호스트 드라이버와 충돌하지 않는다
• driver.enabled 를 false 로 두면 장치 플러그인과 GFD 도 함께 꺼지므로 그것들은 손으로 설치해야 한다
• 클러스터 전체라면 driver.enabled 를 false 로, 일부 노드라면 그 노드에 deploy.driver=false 를 두며, 그렇게 뺀 드라이버의 수명 주기는 오퍼레이터가 관리하지 않는다