API 서버가 실제로 거절하는 것을 본다

이 실습은 진짜 API 서버에서 돕니다

CRD 는 "API 서버가 이미 가진 능력을 내 타입에 빌려 준다" 는 물건입니다.
그 능력이란 스키마 검증 · 기본값 · RBAC · 감사 · watch 입니다.

그런데 가짜 클러스터에는 그 능력이 없습니다. 무엇을 넣어도 받아 주므로
잘못된 값이 거절되는 것도, 기본값이 채워지는 것도 볼 수 없었습니다.
거절당해 봐야 계약이 무엇인지 압니다.

처음 뜨는 데 2분쯤 걸립니다.

목표

개발자에게 줄 플랫폼 API 를 하나 설계하고, 그것이 실제로 담장 노릇을
하는지 확인합니다.

단계

1. CRD 를 만들고 API 서버가 그것을 받아들이는 것을 /root/cnpa/crd.txt 에 담으세요.
2. 스키마가 잘못된 값을 거절하는 것을 /root/cnpa/validate.txt 에 담으세요.
3. 기본값이 채워지는 것을 /root/cnpa/defaults.txt 에 담으세요.
4. kubectl get 이 쓸 만하게 보이도록 출력 열을 붙여 /root/cnpa/columns.txt 에 담으세요.
5. RBAC 으로 개발자가 할 수 있는 일을 정하고 /root/cnpa/rbac.txt 에 담으세요.
6. 쿼터로 자원의 담장을 세우고 /root/cnpa/quota.txt 에 담으세요.
7. 배포 원장에서 DORA 지표를 계산해 /root/cnpa/dora.txt 에 담으세요.
8. /root/cnpa/report.md 에 crd_kind=, rejected=yes, deploy_freq= 세 줄과 설명을 쓰세요.

참고

• kubectl explain 이 CRD 의 스키마를 읽어 줍니다. 문서를 따로 쓰지 않아도 되는 이유입니다.
• 거절 메시지를 그대로 남기세요. 그것이 계약의 증거입니다.
• 흔한 실수: x-kubernetes-preserve-unknown-fields: true 를 넣는 것. 잘라내기도 검증도 통째로 꺼 버립니다.
• 흔한 실수: additionalProperties: false 를 쓰는 것. properties 와 함께 쓸 수 없고, 쓸 필요도 없습니다.
• 흔한 실수: 기본값을 컨트롤러에서 채우는 것. API 서버가 채우면 kubectl get -o yaml 에 바로 보입니다.

단계 8개

1. 내 타입을 API 에 등록한다
2. 거절당해 봐야 계약을 안다
3. 빠뜨린 값을 API 서버가 채운다
4. kubectl get 이 쓸 만해야 쓰인다
5. 개발자가 할 수 있는 일을 정한다
6. 자원의 담장
7. 지표는 계산에서 갈린다
8. 무엇을 배웠나