- Implementation guidelines
- 구현 가이드라인
이 문서는 SIG-Multicluster 후원 API 구현에 대한 일반적인 가이드라인을 제공합니다.
1 준수 기대사항[ | ]
여러 공급자 간에 준수 수준이 시간이 지남에 따라 다를 것으로 예상됩니다. SIG-Multicluster는 구현이 API 사양에 대한 준수 여부를 자동으로 테스트할 수 있는 컨포먼스 스위트를 작업 중입니다. 현재는 각 KEP가 주어진 API의 준수 기준을 RFC 2119에 설명된 대로 "반드시(MUST)", "선택적으로(MAY)", "권장(SHOULD)"으로 명시하고 있습니다.
1.1 구현별 세부사항[ | ]
API의 일부 측면에서, 사양은 기능의 일반적인 사용자 사용 패턴을 제공하지만, 정확한 동작은 기본 구현에 따라 다를 수 있습니다. 알려진 경우, 이러한 것은 KEP에서 구현 세부사항으로 호출하여 준수 기대사항과 "구현별"로 간주되는 동작의 변이를 명확히 구분합니다.
2 API 관례[ | ]
SIG-Multicluster 후원 API는 Kubernetes API 관례를 따릅니다. 이러한 관례는 클라이언트 개발을 용이하게 하고 다양한 사용 사례에 걸쳐 구성 메커니즘이 일관되게 구현될 수 있도록 합니다.
3 API 프로세스[ | ]
SIG-Multicluster 후원 API는 Kubernetes 개선 제안 프로세스를 통해 커뮤니케이션 및 성숙되며, Kubernetes 릴리스의 일부로 구현되는지 여부에 관계없이 진행됩니다. SIG 후원 아티팩트(컨포먼스 테스트, 게시된 CRD yaml, 관련 이미지 또는 소프트웨어 등)는 Kubernetes-sigs Github 조직의 저장소에 게시됩니다.
4 CRD 및 Webhook 유효성 검사 한계[ | ]
CRD와 webhook 유효성 검사는 최종적인 유효성 검사가 아닙니다. Webhook은 "좋은 UX"이지만, 스키마 강제 실행이 아닙니다. 이 유효성 검사는 사용자가 잘못된 구성을 제공했을 때 즉각적인 피드백을 제공하기 위한 것입니다. 잘못된 입력이 컨트롤러에 도달할 가능성을 고려하여 방어적으로 코드를 작성해야 합니다. webhook과 CRD 유효성 검사는 신뢰할 수 없는 이유는:
- 올바르게 배포되지 않을 수 있습니다.
- 향후 API 릴리스에서 완화될 수 있습니다. (새 버전에서는 필드에 덜 제한적인 유효성 검사값이 포함될 수 있음).
이러한 한계는 SIG-Multicluster 후원 API에 국한되지 않으며, 더 넓게는 모든 Kubernetes CRD와 webhook에 적용됩니다.
구현자는 API에서 예상치 못한 값을 만나더라도 구현이 가능한 한 안전하고, 이러한 입력을 우아하게 처리해야 합니다. 가장 일반적인 대응은 구성을 잘못된 형식으로 거부하고 상태 블록에 있는 조건을 통해 사용자에게 신호를 보내는 것입니다. 중복 작업을 피하기 위해, Multicluster API 유지관리자들은 구현자가 이 목적을 위한 공유 유효성 검사 패키지를 추가하는 것을 고려하고 있습니다.
-
{{comment.page_title}} ―{{comment.name}}