기능 설명

• 한 줄로 된 기능 설명(릴리스 노트로 사용할 수 있음):
• 기본 연락처(담당자):
• 책임 있는 SIG:
• 디자인 제안 링크(커뮤니티 저장소): https://github.com/kubernetes/community/issues/429
• 검토자 - (LGTM의 경우) 2명 이상의 검토자(코드 영역 OWNERS 파일에서 최소 한 명)가 검토에 동의하도록 권장합니다. 여러 회사의 리뷰어 선호:
• 승인자(기능이 속한 SIG/영역에서 가능):
• 기능 목표(어떤 목표가 어떤 이정표와 같음):
  
  
  
  • 알파 릴리스 대상(xy)
  
  
  • 베타 출시 대상(xy)
  
  
  • 안정 출시 목표(xy)
  
  

######### 아래의 오래된 템플릿

설명

IPvS 또는 LVS는 3가지 다른 방식으로 요청을 프록시할 수 있는 커널 기능이며 직접 라우팅 모델이 선호되는 모델입니다.

진행률 추적기

• [ ] 알파
  
  
  
  • [ ] 초안 품질 문서 작성 및 유지
    
    
    
    
    
    • [ ] 개발하는 동안 원하는 기능 경험과 현재 상태에서 기능을 사용해 볼 수 있는 방법에 대해 문서를 최신 상태로 유지하십시오. 새로운 기능의 README와 Kubernetes 릴리스 이전에 작성될 문서의 골격으로 생각하십시오. Google 문서에 링크 붙여넣기: DOC-LINK
    
    
    
  
  
  • [ ] 디자인 승인
    
    
    
    
    
    • [x] 디자인 제안. https://github.com/kubernetes/community/issues/429
    
    
    
    • [ ] 이 기능의 코드를 체크인할 저장소를 결정합니다. 모든 것이 핵심 kubernetes 리포지토리에 상륙할 필요는 없습니다. REPO 이름
    
    
    
    • [ ] 초기 API 검토(API인 경우). 디자인 문서와 같은 PR일 수도 있습니다. 홍보 번호
    
    
    
    • API를 변경하는 모든 코드( /pkg/apis/... )
    
    
    
    • 참조 @kubernetes/api
    
    
    
    • [ ] 양치기를 식별합니다(SIG 리드 및/또는 [email protected]이 도움을 드릴 수 있습니다). 나의 양치기는: _replace. [email protected]_ (및/또는 GH 핸들)
    
    
    
    • 셰퍼드는 기능을 리포지토리에 가져오고 검토자를 식별하며 기능에 대한 피드백을 제공하는 프로세스를 알려주는 데 도움을 줄 개인입니다. 그들은 기능의 코드 검토자나 해당 분야의 기술 리더가 _아닙니다_ (필수적으로).
    
    
    
    • 목자는 Kubernetes-PM 회의에 표시하거나 기능이 릴리스 목표를 달성하기 위해 순조롭게 진행 중인 경우 커뮤니케이션에 대한 책임이 _없습니다_. 그것은 여전히 ​​당신의 책임입니다.
    
    
    
    • [ ] 보조/백업 접점을 식별합니다. 내 보조 연락처: _replace. [email protected]_ (및/또는 GH 핸들)
    
    
    
  
  
  • [ ] 작성(코드 + 테스트 + 문서)한 다음 병합합니다. 모든 홍보 번호
    
    
    
    
    
    • [ ] 코드는 기본적으로 비활성화되어야 합니다. 코드 소유자에 의해 확인됨
    
    
    
    • [ ] 최소한의 테스트
    
    
    
    • [ ] 최소한의 문서
    
    
    
    • 문서 PR의 참조 @kubernetes/docs
    
    
    
    • cc @kubernetes/feature-reviewers 이 문제 를 확인하기 전에 승인을 받으십시오.
    
    
    
    • 새 API: 문서 저장소의 용어집 섹션 항목 : kubernetes/kubernetes.github.io
    
    
    
    • [ ] 릴리스 정보 업데이트
    
    
    
  
  
• [ ] 베타
  
  
  
  • [ ] 베타 테스트로 충분합니다.
  
  
  • [ ] 튜토리얼이 포함된 사용자 문서
    
    
    
    
    
    • 문서 리포지토리의 업데이트된 연습/튜토리얼 : kubernetes/kubernetes.github.io
    
    
    
    • 문서 PR의 참조 @kubernetes/docs
    
    
    
    • cc @kubernetes/feature-reviewers 이 문제에 대해 확인하기 전에 승인을 받으십시오.
    
    
    
  
  
  • [ ] 철저한 API 검토
  
  
  • 참조 @kubernetes/api
  
  
• [ ] 안정적인
  
  
  
  • [ ] docs/proposals/foo.md가 docs/design/foo.md로 이동되었습니다.
    
    
    
    
    
    • cc @kubernetes/feature-reviewers 이 문제에 대해 확인하기 전에 승인을 받으십시오.
    
    
    
  
  
  • [ ] 담그기, 부하 테스트
  
  
  • [ ] 자세한 사용자 문서 및 예제
  
  
  • 참조 @kubernetes/docs
  
  
  • cc @kubernetes/feature-reviewers 이 문제 를 확인하기 전에 승인을 받으십시오.
  
  

FEATURE_STATUS는 기능 추적에 사용되며 @kubernetes/feature-reviewers 의해 업데이트됩니다.
기능_상태: IN_DEVELOPMENT

추가 조언:

설계

• @kubernetes/feature-reviewers 회원으로부터 LGTM을 받으면 이 확인란을 선택할 수 있으며 검토자는 "디자인 완료" 레이블을 적용합니다.

코딩

• 필요한 만큼 PR을 사용합니다. 편리한 대로 동일하거나 다른 PR에 테스트를 작성하십시오.
• 각 PR이 병합되면 PR을 참조하는 이 문제에 주석을 추가하십시오. 코드는 http://github.com/kubernetes/kubernetes 저장소로 이동합니다.
  때로는 http://github.com/kubernetes/contrib 또는 다른 저장소.
• 코드 작업이 끝나면 "코드 완성" 레이블을 적용합니다.
• 기능에 사용자 문서가 있는 경우 @kubernetes/feature-reviewers 언급하는 주석을 추가하면 문서가
  코드가 제안된 기능 및 디자인과 일치하는지, 모든 것이 완료되었는지, 적절한
  테스트. 그들은 상세한 코드 검토를 하지 않을 것입니다: 이미 PR이 검토되었을 때 일어난 일입니다.
  완료되면 이 확인란을 선택하면 검토자가 "코드 완성" 레이블을 적용합니다.

문서

• [ ] 사용자 문서를 작성하고 병합합니다.
• 사용자 문서는 http://github.com/kubernetes/kubernetes.github.io 로 이동
• 기능에 사용자 문서가 있는 경우 @kubernetes/docs 언급하는 주석을 추가하세요.
• LGTM을 받으면 이 확인란을 선택할 수 있으며 검토자는 "문서 완성" 레이블을 적용합니다.