퀴즈: 서버측 적용과 필드 소유

kubectl get deploy web -o json | jq '.metadata.managedFields' 가 null 을 돌려준다. 왜인가?

• 서버측 적용을 쓰지 않은 객체라 기록이 없다
• jq 가 배열을 문자열로 읽어 실패한 것이다
• 이 네임스페이스에 조회 권한이 없다
• kubectl 이 managedFields 를 기본으로 감추기 때문이다

--force-conflicts 로 적용에 성공했다. 소유 기록에는 어떤 일이 일어나나?

• 충돌한 필드를 두 관리자가 함께 소유하게 된다
• 그 필드의 소유가 옛 관리자에게서 새 관리자로 넘어간다
• 소유 기록이 초기화되고 모든 필드가 새 관리자 것이 된다
• 충돌 기록만 남고 소유는 바뀌지 않는다

관리자 hotfix 가 replicas 를 5 로 빼앗아 간 뒤, 매니페스트에서 replicas 줄을 지우고 다시 적용했다. 값은?

• 아무도 소유하지 않게 되어 API 기본값인 1 이 된다
• 이전 주인이 적용했던 값인 2 로 돌아간다
• 마지막 값인 5 가 그대로 유지된다
• 필드가 아예 삭제되어 조회되지 않는다

kubectl scale 로 replicas 를 바꾼 뒤 서버측 적용을 하면 충돌 메시지에 무엇이 나오나?

• 관리자 이름 없이 필드 경로만 나온다
• scale 명령은 소유 기록을 남기지 않아 충돌이 없다
• 관리자 kubectl 과 함께 하위 자원 이름이 표시된다
• Deployment 전체가 다른 관리자 것이라고 나온다

클라이언트측 적용이 남기는 것과 서버측 적용이 남기는 것의 차이는?

• 앞은 지난 매니페스트를 주석에 통째로 남기고, 뒤는 필드별 소유 기록을 남긴다
• 앞은 아무것도 남기지 않고, 뒤만 주석을 남긴다
• 둘 다 같은 주석을 남기고 저장 위치만 다르다
• 앞은 서버에, 뒤는 클라이언트 캐시에 기록을 남긴다

Argo CD 무시 규칙의 managedFieldsManagers 가 비교 대상을 고르는 기준은?

• 필드 경로를 정규식으로 맞춘다
• 그 필드가 마지막으로 바뀐 시각을 본다
• Application 의 프로젝트 이름으로 묶는다
• 그 필드를 소유한 관리자 이름을 본다