Funktionsbeschreibung

• Einzeilige Funktionsbeschreibung (kann als Versionshinweis verwendet werden):
• Hauptansprechpartner (Beauftragter):
• Verantwortliche SIGs:
• Link zum Designvorschlag (Community-Repo): https://github.com/kubernetes/community/issues/429
• Rezensenten - (für LGTM) empfehlen, dass 2+ Rezensenten (mindestens einer aus der Datei OWNERS des Codebereichs) der Überprüfung zugestimmt haben. Rezensenten von mehreren Unternehmen bevorzugt:
• Genehmiger (wahrscheinlich von SIG/Gebiet, zu dem das Feature gehört):
• Funktionsziel (welches Ziel entspricht welchem ​​Meilenstein):
  
  
  
  • Alpha-Release-Ziel (xy)
  
  
  • Beta-Release-Ziel (xy)
  
  
  • Stabiles Freigabeziel (xy)
  
  

######### Veraltete Vorlage unten

Beschreibung

IPvS oder LVS ist eine Kernel-Funktion, die Anfragen auf drei verschiedene Arten weiterleiten kann, das Direct Routing-Modell ist das bevorzugte Modell.

Fortschrittsanzeige

• [ ] Alpha
  
  
  
  • [ ] Verfassen und pflegen Sie den Entwurf von Qualitätsdokumenten
    
    
    
    
    
    • [ ] Halten Sie während der Entwicklung ein Dokument über die gewünschte Erfahrung des Features auf dem neuesten Stand und wie jemand das Feature in seinem aktuellen Zustand ausprobieren kann. Betrachten Sie es als README Ihrer neuen Funktion und als Grundgerüst für die Dokumente, die vor der Veröffentlichung von Kubernetes geschrieben werden sollen. Link zu Google Doc einfügen: DOC-LINK
    
    
    
  
  
  • [ ] Design-Zulassung
    
    
    
    
    
    • [x] Designvorschlag. https://github.com/kubernetes/community/issues/429
    
    
    
    • [ ] Entscheiden Sie, in welches Repository der Code dieser Funktion eingecheckt wird. Nicht alles muss im Kern-Kubernetes-Repo landen. REPO-NAME
    
    
    
    • [ ] Anfängliche API-Überprüfung (falls API). Vielleicht gleiche PR wie Design doc. PR-NUMMER
    
    
    
    • Jeder Code, der eine API ändert ( /pkg/apis/... )
    
    
    
    • cc @kubernetes/api
    
    
    
    • [ ] Identifizieren Sie den Hirten (Ihr SIG-Leiter und/oder [email protected] können Ihnen helfen). Mein Hirte ist: _replace. [email protected]_ (und/oder GH-Handle)
    
    
    
    • Ein Hirte ist eine Person, die Ihnen dabei hilft, Ihr Feature in das Repository aufzunehmen, Rezensenten zu identifizieren und Feedback zu dem Feature zu geben. Sie sind _nicht_ (unbedingt) der Code-Reviewer des Features oder der technische Leiter für den Bereich.
    
    
    
    • Der Hirte ist _nicht_ dafür verantwortlich, zu Kubernetes-PM-Meetings zu erscheinen und/oder zu kommunizieren, ob das Feature auf dem richtigen Weg ist, um die Release-Ziele zu erreichen. Das liegt immer noch in Ihrer Verantwortung.
    
    
    
    • [ ] Identifizieren Sie den sekundären/Backup-Kontaktpunkt. Meine sekundäre Kontaktstelle ist: _replace. [email protected]_ (und/oder GH-Handle)
    
    
    
  
  
  • [ ] Schreiben Sie (Code + Tests + Dokumente) und lassen Sie sie zusammenführen. ALLE-PR-NUMMERN
    
    
    
    
    
    • [ ] Code muss standardmäßig deaktiviert sein. Verifiziert durch Code-EIGENTÜMER
    
    
    
    • [ ] Minimale Tests
    
    
    
    • [ ] Minimale Dokumente
    
    
    
    • cc @kubernetes/docs auf docs PR
    
    
    
    • cc @kubernetes/feature-reviewers zu diesem Thema , um eine Genehmigung zu erhalten, bevor Sie dies abhaken
    
    
    
    • Neue API: Glossary Section Item im Docs Repo: kubernetes/kubernetes.github.io
    
    
    
    • [ ] Versionshinweise aktualisieren
    
    
    
  
  
• [ ] Beta
  
  
  
  • [ ] Testen ist ausreichend für Beta
  
  
  • [ ] Benutzerdokumentation mit Tutorials
    
    
    
    
    
    • Aktualisierte exemplarische Vorgehensweise /
    
    
    
    • cc @kubernetes/docs auf Dokumenten-PR
    
    
    
    • cc @kubernetes/feature-reviewers zu diesem Thema , um eine Genehmigung zu erhalten, bevor Sie dies abhaken
    
    
    
  
  
  • [ ] Gründliche API-Überprüfung
  
  
  • cc @kubernetes/api
  
  
• [ ] Stabil
  
  
  
  • [ ] docs/proposals/foo.md wurde nach docs/design/foo.md verschoben
    
    
    
    
    
    • cc @kubernetes/feature-reviewers zu diesem Thema , um eine Genehmigung zu erhalten, bevor Sie dies abhaken
    
    
    
  
  
  • [ ] Einweichen, Belastungstest
  
  
  • [ ] ausführliche Benutzerdokumentation und Beispiele
  
  
  • cc @kubernetes/docs
  
  
  • cc @kubernetes/feature-reviewers zu diesem Thema , um eine Genehmigung zu erhalten, bevor Sie dies abhaken
  
  

FEATURE_STATUS wird für das Feature-Tracking verwendet und wird von @kubernetes/feature-reviewers aktualisiert.
FEATURE_STATUS: IN_DEVELOPMENT

Weitere Ratschläge:

Entwurf

• Sobald Sie LGTM von einem @kubernetes/feature-reviewers Mitglied erhalten, können Sie dieses Kontrollkästchen aktivieren und der Prüfer wird das Label "design-complete" anbringen.

Codierung

• Verwenden Sie so viele PRs, wie Sie benötigen. Schreiben Sie Tests in denselben oder in verschiedenen PRs, wie es für Sie bequem ist.
• Fügen Sie beim Zusammenführen jedes PR einen Kommentar zu diesem Problem hinzu, der auf die PRs verweist. Code geht in das http://github.com/kubernetes/kubernetes-Repository ,
  und manchmal http://github.com/kubernetes/contrib oder andere Repos.
• Wenn Sie mit dem Code fertig sind, bringen Sie das Label "Code-Complete" an.
• Wenn die Funktion Benutzerdokumente enthält, fügen Sie bitte einen Kommentar hinzu, in dem @kubernetes/feature-reviewers und sie werden es tun
  Überprüfen Sie, ob der Code mit der vorgeschlagenen Funktion und dem vorgeschlagenen Design übereinstimmt, und dass alles erledigt ist und dass es angemessen ist
  testen. Sie werden keine detaillierte Codeüberprüfung durchführen: Das geschah bereits, als Ihre PRs überprüft wurden.
  Wenn dies erledigt ist, können Sie dieses Kontrollkästchen aktivieren und der Prüfer wird das Label "Code abgeschlossen" anbringen.

Dokumente

• [ ] Benutzerdokumente schreiben und zusammenführen.
• Benutzerdokumente gehen in http://github.com/kubernetes/kubernetes.github.io.
• Wenn die Funktion Benutzerdokumente enthält, fügen Sie bitte einen Kommentar hinzu, in dem @kubernetes/docs .
• Wenn Sie LGTM erhalten, können Sie dieses Kontrollkästchen aktivieren und der Prüfer wird das Label "docs-complete" (Dokumente abgeschlossen) anbringen.