@lavalamp Ich habe dies erstellt, um zu versuchen, einen Ort zu haben, an dem wir zumindest unsere Gedanken konsolidieren und den Fortschritt bei Ressourcen von Drittanbietern verfolgen können. Ich habe versucht, eine Liste bekannter Mängel zu erstellen, die vor der Beförderung in den Stall behoben werden müssen.

Ich habe keinen Besitzer im Sinn, aber das Erkennen des Problems scheint Schritt 1 zu sein.

@deads2k Ich lerne kürzlich Ressourcen von Drittanbietern und möchte auch bei etwas helfen.

@deads2k Ich lerne kürzlich Ressourcen von Drittanbietern und möchte auch bei etwas helfen.

Ich habe die Liste nach meiner taktischen Priorität neu geordnet. Die Leute versuchen jetzt, dies zu nutzen, und diese Probleme werden sie stark verbrennen.

Wenn Sie sich wohl fühlen, das Element "mehrere Ressourcen" zu nehmen, wäre das ein guter Anfang. Sie könnten ein separates Thema erstellen und wir können dort über die Implementierung sprechen.

@deads2k Ich habe einige Zeit damit verbracht, das erste Problem zu reproduzieren:

Multiple Resources, single version, different add times - Adding resource A, waiting for it to appear, then adding resource B fails. Resource B is never added.

aber mit Pech. Unten sind meine Reproduktionsschritte:

1. Erstellen Sie eine benutzerdefinierte Drittanbieterressource und warten Sie, bis sie angezeigt wird

[root<strong i="12">@localhost</strong> kubernetes]# cat /home/tony/Desktop/debug/lbclaim.yaml
kind: ThirdPartyResource
apiVersion: extensions/v1beta1
metadata:
  name: loadbalancerclaim.k8s.io
description: "Allow user to claim a loadbalancer instance"
versions:
- name: v1
[root<strong i="13">@localhost</strong> kubernetes]# kc create -f /home/tony/Desktop/debug/lbclaim.yaml
thirdpartyresource "loadbalancerclaim.k8s.io" created
[root<strong i="14">@localhost</strong> kubernetes]# curl  http://localhost:8080/apis/extensions/v1beta1/thirdpartyresources/
{
  "kind": "ThirdPartyResourceList",
  "apiVersion": "extensions/v1beta1",
  "metadata": {
    "selfLink": "/apis/extensions/v1beta1/thirdpartyresources/",
    "resourceVersion": "170"
  },
  "items": [
    {
      "metadata": {
        "name": "loadbalancerclaim.k8s.io",
        "selfLink": "/apis/extensions/v1beta1/thirdpartyresources/loadbalancerclaim.k8s.io",
        "uid": "dcb88b3a-9857-11e6-a19b-08002767e1f5",
        "resourceVersion": "146",
        "creationTimestamp": "2016-10-22T13:03:01Z"
      },
      "description": "Allow user to claim a loadbalancer instance",
      "versions": [
        {
          "name": "v1"
        }
      ]
    }
  ]
}

1. Erstellen Sie nach einem Moment (mehr als 10 Sekunden) eine weitere benutzerdefinierte Drittanbieterressource

[root<strong i="19">@localhost</strong> kubernetes]# cat /home/tony/Desktop/debug/loadbalancer.yaml
kind: ThirdPartyResource
apiVersion: extensions/v1beta1
metadata:
  name: loadbalancer.k8s.io
description: "Allow user to curd a loadbalancer instance"
versions:
- name: v1
[root<strong i="20">@localhost</strong> kubernetes]# kc create -f /home/tony/Desktop/debug/loadbalancer.yaml
thirdpartyresource "loadbalancer.k8s.io" created

1. Überprüfen Sie, ob beide Ressourcen vorhanden sind

[root<strong i="25">@localhost</strong> kubernetes]# curl http://localhost:8080/apis/k8s.io/v1/
{
  "kind": "APIResourceList",
  "apiVersion": "v1",
  "groupVersion": "k8s.io/v1",
  "resources": [
    {
      "name": "loadbalancerclaims",
      "namespaced": true,
      "kind": "Loadbalancerclaim"
    },
    {
      "name": "loadbalancers",
      "namespaced": true,
      "kind": "Loadbalancer"
    }
  ]
}
[root<strong i="26">@localhost</strong> kubernetes]# kc get loadbalancers
No resources found.
[root<strong i="27">@localhost</strong> kubernetes]# kc get loadbalancerclaims
No resources found.

anscheinend unterstützen wir bereits mehrere Ressourcen, eine einzelne Version.

Und ich werfe einen tiefen Blick auf TPR-bezogenen Code. Das thirdparty_controller wird regelmäßig synchronisiert (alle 10 Sekunden), es wird jedes neue TPR installieren und auch einige Löschaufgaben ausführen. Das ThirdPartyResourceServer enthält alle installierten TPR-Zuordnungen. Wie wir anhand von SyncOneResource und InstallThirdPartyResource , existiert auch diese Gruppe, sie wird die Gruppe dennoch mit der neuen API aktualisieren.

Außerdem habe ich festgestellt, dass ich ein TPR-Schema löschen kann, selbst wenn TPR-Instanzen im System vorhanden sind. Ich denke, das sollte nicht erlaubt sein.

@deads2k Ich habe einige Zeit damit verbracht, das erste Problem zu reproduzieren:

Versuchen Sie, diesen Test zu aktivieren: https://github.com/kubernetes/kubernetes/blob/master/test/integration/thirdparty/thirdparty_test.go#L137 . Wenn es funktioniert, sind wir gut. Wenn es fehlschlägt, stimmt etwas nicht.

@deads2k Hallo David, bitte schau dir die Nachricht an, die ich auf Slack gesendet habe. Außerdem füge ich einen Fix zum fehlgeschlagenen Integrationstest hinzu, der Ressourcencontroller des Drittanbieters entfernt den entsprechenden Routen-Handler, wenn ein TPR gelöscht wird, dies wird beim Integrationstest helfen, aber ich bin mir nicht sicher, ob dies weitere Probleme mit sich bringt .

Für Problem Nr. 1 wurde es hier behoben:

https://github.com/kubernetes/kubernetes/pull/28414

@brendandburns eigentlich nicht, Sie können den Integrationstest schlägt fehl.

@brendandburns Genauer gesagt haben wir mehrere Ressourcen unterstützt, eine einzelne Version, aber die

@AdoHe hast du ein Problem

@brendandburns können Sie hier sehen:

https://github.com/kubernetes/kubernetes/blob/master/test/integration/thirdparty/thirdparty_test.go#L137 

Aktivieren Sie diesen Test, und Sie werden sehen, dass er fehlschlägt. Ich habe versucht, dies auf meinem lokalen zu beheben, und ich werde später heute eine PR öffnen.

@brendandburns Ich fürchte, ich

Siehe auch https://github.com/kubernetes/kubernetes/issues/32306 (TPR sollte gelöscht werden, wenn Namespace gelöscht wird)

@deads2k kannst du die Checkliste aktualisieren?

@deads2k kannst du die Checkliste aktualisieren?

Alle Fragen noch offen. Dies ist eigentlich eine Funktion, um die Probleme in der (bereits) Beta-Implementierung thirdparyresources von 1.3 zu verfolgen. Wir brauchten einen Ort, um unsere Probleme im Auge zu behalten, mussten aber in 1.5 Energie für andere Bemühungen aufwenden.

@deads2k Ich arbeite bereits an Multiple Resources, single version und Multiple versions , ich denke, viel Code muss aktualisiert werden.

@deads2k bietet immer noch Ziel 1.5?

@idvoretskyi Ich fürchte nicht :(

@deads2k : ThirdPartyResources sollten zu Verbund-APIs hinzugefügt werden.

@deads2k : Derzeit funktionieren Feldselektoren nicht, wenn nach ThirdPartyObjects abgefragt wird, ist das etwas für Ihre Liste?

@deads2k @rmohr kubectl hat noch viele herausragende Fähigkeiten gegen TPR, die obige Liste sollte aktualisiert werden, um diese zu verfolgen.

@deads2k : Derzeit funktionieren Feldselektoren nicht, wenn nach ThirdPartyObjects abgefragt wird, ist das etwas für Ihre Liste?

Das ist ein allgemeineres Problem der inkonsistenten Feldauswahlunterstützung über alle API-Typen hinweg.

Ich fange auch an, mir das anzuschauen. ThirdPartyResources sind sehr wichtig, um "externe" Controller wie spark zu unterstützen , und bevor wir Dinge wie Unterressourcen hinzufügen können, sollten wir dies beheben.

Feldselektoren funktionieren nur bei von Hand kuratierten Feldern in den regulären API-Objekten. Ich würde nicht erwarten, dass sie für irgendwelche Felder in TPRs funktionieren - apiserver ist nicht für willkürliche Abfragen gebaut. Wenn Sie dieses Verhalten benötigen, wird TPR für Sie nicht funktionieren.

Ist der nächste Schritt hier, die TPRs in einen Addon-API-Server zu verschieben ?
Es scheint, als ob es einige ausstehende PRs gibt, um einige der Probleme in der Liste hier zu beheben, die für dieses Element möglicherweise blockiert werden.

/cc @liggitt @deads2k @AdoHe

Um die Komplexität von TPRs im Apiserver-Code zu verringern und die TPR-Logik deutlicher zu machen, würde ich definitiv für ein eigenständiges tpr-apiserver stimmen. Aber IMO blockiert dies keine der Fixes wirklich.

Ich füge einige Punkte zum Umgang mit der API-Semantik (get, list, watch, update, patch) hinzu, wenn es um mehrere nicht konvertierbare Arten geht. Ich denke, dafür ist wahrscheinlich ein Designdokument erforderlich, da die Semantik wahrscheinlich nicht mit der normalen API-Semantik übereinstimmt.

Ich werde (noch einen) Versuch unternehmen, einige dieser Probleme zu beheben ...

https://github.com/kubernetes/kubernetes/pull/40260 und https://github.com/kubernetes/kubernetes/pull/40096 werden uns auf der kubectl-Seite in eine ordentliche Form bringen

Das derzeit schwerwiegendste serverseitige Problem ist, dass der Garbage Collector den Verstand über die OwnerRefs verliert, die auf TPRs verweisen.

Sobald dies geklärt ist, sollten wir entscheiden, wie die API-Semantik für mehrere Versionen eines bestimmten TPR aussehen soll, und sicherstellen, dass der TPR-Typ die benötigten Daten enthält. Dies wirkt sich wahrscheinlich auf die serverseitige Speicherimplementierung aus, daher würde ich das Design lieber festnageln, bevor wir zu viel serverseitige Arbeit leisten.

@liggitt Ich werde mir diese mal ansehen. Danke

Hat jemand einen Hinweis darauf, wie man in RBAC-Regeln auf TPRs verweist? Ich habe einen TPR namens foo-bar.something.example.com. Als Cluster-Administrator kann ich mit kubectl get foobars eine Liste von Foobars in einem bestimmten Namespace abrufen.

Wenn ein normaler Benutzer dasselbe versucht, erhält er Error from server (Forbidden): the server does not allow access to the requested resource (get foobars.something.example.com) .

Ich habe jede Variation von foobar, foo-bar usw. ausprobiert, die mir in einer RBAC-Regel einfällt, bisher ohne Erfolg.

In der Regel suchen Sie nach resource=foobars apigroup=something.example.com verb=get,list,watch

@deads2k Das hat den Trick gemacht. Vielen Dank!

@liggitt

The most severe server-side issue at the moment is the garbage collector losing its mind over ownerRefs that point to TPRs.

irgendwas im Zusammenhang mit dem TPR-Bereinigungsproblem?

Nein, es war ein Problem damit, dass der Garbage Collector nicht wusste, wie man die OwnerRefs nach anderen als in kompilierten Typen sucht. Es gibt auch das umgekehrte Problem, bei dem der Garbage Collector Finalizern für andere als die einkompilierten Typen keine Aufmerksamkeit schenkt.

Diese beiden Garbage Collector-Probleme unterscheiden sich von der Notwendigkeit, ThirdPartyResourceData-Objekte zuverlässig zu bereinigen, wenn das ThirdPartyResource-Objekt entfernt wird.

@liggitt Danke für die geduldige Erklärung, also was ist der Plan von TPR in 1.6?

Der GC protokolliert jetzt nur noch 1.000 Mal pro Sekunde statt 50.000 Mal pro Sekunde.
es gewinnt also nicht mehr das Rennen mit dem Log-Rotator. Aber eine echte Lösung wird sein
kommt bald, hoffentlich.

Am Samstag, den 4. Februar 2017 um 23:54 Uhr schrieb TonyAdo [email protected] :

@liggitt https://github.com/liggitt Danke für die geduldige Erklärung, also
Was ist der Plan von TPR in 1.6?

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/kubernetes/features/issues/95#issuecomment-277503470 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAnglmGf00K6W7SsJ1aSqWOI_M-A7Hf2ks5rZYBPgaJpZM4KLBmK
.

Einige der offenen Fragen im Zusammenhang mit TPR. Nicht erschöpfend.

Gruppen-/Versionsprobleme: https://github.com/kubernetes/kubernetes/pull/24299 , https://github.com/kubernetes/kubernetes/pull/36977
Ansehen: https://github.com/kubernetes/kubernetes/issues/25340
Selbstlink: https://github.com/kubernetes/kubernetes/issues/37622
Löschen des Namespace: https://github.com/kubernetes/kubernetes/issues/37554
GC: https://github.com/kubernetes/kubernetes/issues/39816
Finalizer: https://github.com/kubernetes/kubernetes/issues/40715
Bereinigung von TPR-Daten: https://github.com/kubernetes/kubernetes/issues/35949
Stärkere Validierung von Metadaten: https://github.com/kubernetes/kubernetes/issues/22768#issuecomment -215940468
Fehlende Unit-Tests: https://github.com/kubernetes/kubernetes/pull/40956
Bereinigung: https://github.com/kubernetes/kubernetes/issues/36998

Funktionen, die Benutzer für Fehler halten, weil sie für andere Ressourcen funktionieren:
Asynchrones Verhalten: https://github.com/kubernetes/kubernetes/issues/29002
Ganzzahlen: https://github.com/kubernetes/kubernetes/issues/30213
YAML: https://github.com/kubernetes/kubernetes/issues/37455
Anständige kubectl-Ausgabe: https://github.com/kubernetes/kubernetes/issues/31343
Vereinfachen Sie die Ressourcenbenennung: https://github.com/kubernetes/kubernetes/issues/29415
Bewerben: https://github.com/kubernetes/kubernetes/issues/29542 , https://github.com/kubernetes/kubernetes/issues/39906
Bearbeiten: https://github.com/kubernetes/kubernetes/issues/35993

/cc

Abonnieren, da wir versuchen, TPRs im Dashboard zu verarbeiten.

Tracking-Probleme sind https://github.com/kubernetes/dashboard/issues/1671 und https://github.com/kubernetes/dashboard/issues/1504.

@kubernetes/dashboard-maintainers

Wie ist der Status/Plan für TPR ohne Namespace? Ich habe keine Diskussionen dazu gefunden, vielleicht etwas übersehen?

@sttts Zunächst einmal fasziniert mich die Entwicklung bei Kubernetes. Und ich möchte dazu beitragen, aber Go ist eine neue Sprache für mich. Was empfehlen Sie mir, damit ich dieses Projekt für GSoC 2017 bekomme?

Um noch etwas über mich hinzuzufügen, ich bin ziemlich gut in C++ und Java und habe einen Bachelor in Informatik. Ich habe auch angefangen, die Dokumentation zu lesen und einen Udacity-Kurs mit Kubernetes belegt.

@grpndrs haben wir eine Liste mit gekennzeichneten Problemen, die ein guter Ausgangspunkt sind, um in den Code https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Afor-new -Mitwirkende. Fühlen Sie sich frei, mich in Ruhe zu kontaktieren und wir können einige davon durchgehen.

@enisoc

Ist Multiple Resources, single version, different add times immer noch ein Problem? Ich kann problemlos mehrere TPRs erstellen und löschen.

Können wir die Kontrollkästchen auch in Outstanding Capabilities nummerieren, damit sie leichter zu finden sind? @deads2k Ich denke, du kannst es so machen:

1. - [ ] ...
2. - [ ] ...

Weiß jemand, wie die Validierungskomponente davon kommt? Ich arbeite viel mit TPRs und diese Funktion wäre unbezahlbar und würde viel benutzerdefinierten Code sparen. Ich würde gerne zu dieser Funktion beitragen, würde aber gerne wissen, ob jemand, der diese Ausgabe abonniert hat, ihren Status kennt

Weiß jemand, wie die Validierungskomponente davon kommt?

Ich erwarte nicht, dass es für 1.7 passieren wird. Im Moment diskutieren wir hier https://github.com/kubernetes/community/pull/524 einige strukturelle Wachstumsschmerzen, um eine stabilere Basis für das Wachstum zu schaffen.

Ich erwarte nicht, dass es für 1.7 passieren wird. Im Moment diskutieren wir hier kubernetes/community#524 einige strukturelle Wachstumsprobleme, um eine stabilere Basis für das Wachstum zu schaffen.

Wir planen, mit https://github.com/kubernetes/community/blob/master/contributors/design-proposals/thirdpartyresources.md im Zeitrahmen 1.7 fortzufahren. Ich werde hier und in den sig-apimachinery-Aufrufen Aktualisierungen vornehmen, während wir weitermachen.

@deads2k Ich habe dort nichts über die tpr-Validierung gesehen. Würden Sie das nicht für etwas halten, das für die Beta benötigt wird?

@frankgreco bei dem Vorschlag geht es um eine solide Grundlage, auf der TPRs aufbauen können. Funktionen wie die Validierung können später hinzugefügt werden, sind hier jedoch nicht enthalten.

Ich habe den übergeordneten Kommentar dieses Threads bearbeitet, um die neue Vorlage zu verwenden und den für 1.7 geplanten Arbeitsumfang zu verdeutlichen, wie ich ihn verstehe. Bitte schauen Sie es sich an und korrigieren / kommentieren.

@deads2k @enisoc Wir haben vor kurzem damit begonnen, TPR zu verwenden, und die TPR-Validierung wird für einige unserer bevorstehenden Projekte ziemlich entscheidend sein. Wenn wir die Ressourcen haben, um daran zu arbeiten, würden Sie dann in Betracht ziehen, Mitwirkende aus der Community zu akzeptieren, um dies zu verwirklichen?

@deads2k @enisoc Wir haben vor kurzem damit begonnen, TPR zu verwenden, und die TPR-Validierung wird für einige unserer bevorstehenden Projekte ziemlich entscheidend sein. Wenn wir die Ressourcen haben, um daran zu arbeiten, würden Sie dann in Betracht ziehen, Mitwirkende aus der Community zu akzeptieren, um dies zu verwirklichen?

Absolut. Für so etwas möchten wir einen Designvorschlag, bevor wir uns mit Pull-Requests befassen. Angesichts der vielen verschiedenen Ansätze, die möglich sind, würde ich außerdem vorschlagen, dass Sie die drei wichtigsten Ideen auflisten und kurz erklären, warum die von Ihnen gewählte die beste ist. Auf der Serverseite sind Leistungs- und Sicherheitsüberlegungen sehr wichtig.

Da dies ein weitreichendes Feature ist, ist es außerdem wichtig, dass es nicht zu einem Drive-by-Beitrag wird. Aktive Beiträge (Reviews, Tests, Code, Migration) für die Umstellung auf https://github.com/kubernetes/community/blob/master/contributors/design-proposals/thirdpartyresources.md würden helfen. Ich bin deads2k auf Slack, wenn Sie interessiert sind und reden möchten.

Danke @deads2k! Das ist völlig vernünftig. Wir werden einige Designvorschläge für die TPR-Validierung machen. Wie kann man sie am besten teilen? Ich werde auch locker lassen

@xiao-zhou wir freuen uns, ein akzeptiertes Google Summer of Code-Projekt zu diesem Thema zu haben (wurde erst gestern angekündigt). Lassen Sie uns auf Slack darüber sprechen, wie Sie daran zusammenarbeiten können. Sehr cool, dass Sie sich auch dafür interessieren, also haben wir einiges an Kraft, dies voranzutreiben!

@xiao-zhou @sttts @deads2k sobald Sie einen Vorschlag für die TPR-Validierung (und idealerweise für die Nichteinhaltung) haben, können Sie mich in der Vorschlagsprüfung mit einem Mind-Tag versehen? Vielen Dank

@sdminonne es wird in sig-apimachinery gepostet. Wenn Sie diese Google-Gruppe abonnieren, sollten Sie benachrichtigt werden.

@sttts danke

@deads2k werden Sie ObservedGeneration für TPRs hinzufügen?

https://github.com/kubernetes/kubernetes/issues/7328#issuecomment -287683598

@deads2k werden Sie ObservedGeneration für TPRs hinzufügen?

Ich hatte nicht vor. Könnte ein Kunde, der sich darum kümmert, nicht einfach Spezifikations- und Statusnamen vergleichen?

Spezifikations- und Statusnamen vergleichen?

Nicht sicher, was Sie hier meinen. Korrigiert mich Wenn ich falsch liege, aber ich denke, es gibt zwei Teile bezüglich ObservedGeneration: 1) der API-Server muss metadata.generation jedes Mal aktualisieren, wenn es ein Update in der Spezifikation des TPR gibt und 2) der für die verantwortliche Controller TPR aktualisiert status.observedGeneration basierend auf metadata.Generation . Ich denke, 1) frage ich Sie und 2) ist etwas, um das sich TPR-Autoren kümmern müssen?

Nicht sicher, was Sie hier meinen. Korrigiere mich Wenn ich falsch liege, aber ich denke, es gibt zwei Teile bezüglich ObservedGeneration: 1) Der API-Server muss die metadata.generation jedes Mal aktualisieren, wenn es ein Update in der Spezifikation des TPR gibt, und 2) der Controller, der für den TPR-Update-Status verantwortlich ist .observedGeneration basierend auf Metadaten.Generation. Ich denke, 1) frage ich Sie und 2) ist etwas, um das sich TPR-Autoren kümmern müssen?

Oh, ich habe falsch verstanden, wonach du gefragt hast. Sie möchten beobachtenGeneration für die CustomResource, nicht die CustomResourceDefinition. Ich dachte, dass ObservedGeneration nur für Änderungen an der Spezifikation gestoßen wurde, die eine Aktion erforderten. Das bedeutet, dass eine Aktualisierung der Metadaten dies nicht ausgelöst hat und eine Aktualisierung einiger Spezifikationsfelder auch eine Störung vermeiden konnte.

In meinem oben verlinkten Kommentar habe ich nach Generierungsunterstützung für TPR-Instanzen gefragt, nicht für TPRs selbst (obwohl das auch schön wäre. Gibt es Gründe, sie nicht zu allen Objekten hinzuzufügen?).

Wenn ich beispielsweise Kind: TPR; name: foo.example.com und eine Instanz dieses TPRs Kind: Foo; name: foo123 , bin ich an Generation/ObservedGeneration für foo123 interessiert, damit der Foo-Controller die Foo-Konsumenten wissen lassen kann, ob es verarbeitet wurde ein Update für die foo123 Instanz. Macht das Sinn? Ich sehe nicht, wie dies ohne angemessene Unterstützung auf der K8s-Serverseite erreicht werden kann.

Ja, generation/observedGeneration ist für das Benutzerschema des TPR sinnvoll und nicht für die tatsächliche TPR-Ressource, wie sie sich entwickelt hat.

@kargakis Die Regel besteht darin, die Objektgenerierung nur bei Spezifikationsaktualisierungen zu

Die Regel lautet, die Objektgenerierung nur bei Spezifikationsaktualisierungen zu erhöhen, nicht den Status, oder?

Richtig.

Wenn dies der Fall ist, müssen wir zuerst die Spec/Status-Aufteilung auf der TPR-Instanz offiziell unterstützen.

Ja, ich hatte erwartet, diese Aufteilung als Teil des bestehenden Problems zu finden, aber es scheint, dass noch mehr Arbeit geleistet werden muss, bevor wir dort ankommen.

@kargakis Ich habe den Kommentar auf oberster Ebene bearbeitet, um diese Elemente zu erwähnen, obwohl sie für 1.7 nicht

/cc

@deads2k Sollten wir einen Kurznamen für CustomResourceDefinition hinzufügen?

Kurzname CRD für CustomResourceDefinition hinzugefügt .

Ein Designvorschlag zur Validierung von CustomResources: https://github.com/kubernetes/community/pull/708 :smile:

@deads2k @enisoc @lavalamp
habe mich gefragt, ob der Benutzer den k8s-Controller UND (ODER) CURD-Methoden für CRD-Objekte konfigurieren kann

In meinem speziellen Anwendungsfall erstelle ich ein networks.stable.example.com CRD und verwende es, um das Netzwerkobjekt net1 zu erstellen:

Ich muss sicherstellen, dass kein neues Netzwerk-CRD-Objekt erstellt werden darf, wenn bereits ein Netzwerk-CRD-Objekt mit einem überlappenden Subnetzbereich vorhanden ist

Falls ein solcher Mechanismus nicht existiert, fasse ich gerne einige Gedanken in einem Design-Dokument zusammen.

Wie in den Versionshinweisen und Dokumenten zu 1.7 erwähnt, ist TPR jetzt veraltet und wir planen, es in 1.8 zu entfernen. Benutzer sollten während des Zeitrahmens 1,7 zu ​​CRD wechseln.

Bitte kommentieren Sie das Tracking-Problem zur Entfernung, wenn Sie Fragen oder Bedenken haben.

Updates/Pläne für 1.8:

• Unterstützung von JSON-Schema-basierter Validierung und Standardeinstellung für CustomResources ( Vorschlag )
• Fügen Sie Unterressourcen (wie Status und Skala) für CRs hinzu (~Vorschlag wird bald veröffentlicht~ Vorschlag )

Danke @nikhita. Ich habe den oberen Kommentar bearbeitet, um 1,8-Pläne widerzuspiegeln.

Discovery gibt korrekte Informationen für CRs zurück, aber der REST-Mapper verwendet sie nicht - https://github.com/kubernetes/kubernetes/issues/49948

Vorschlag für SubResources für CustomResources: https://github.com/kubernetes/community/pull/913 :tada:

Bitte entschuldigen Sie meinen falschen Beitrag, aber ich bin von einer anderen Kubernetes-Seite auf diese Seite gekommen, weil ich dachte, dass Kubernetes ein Micro-Services-Framework enthält, das über die Verwaltung von Containerressourcen von Drittanbietern hinausgeht.

Redhat vermarktet OpenShift Kubernetes als Micro-Services-Plattform, aber ich kann diese Funktion noch nicht finden. Ich suche einen ähnlichen Anwendungsserver, um meine eigene Suite von sehr leichten unabhängigen Anwendungs-Microservices zu hosten.

Gibt es so etwas oder sind wir dazu gezwungen, fette Java-War-Apps in Springboot zu erstellen und sie auf einem Tomcat-Server bereitzustellen, der sich in einem von Kuberenetes verwalteten Container befindet, ist das schwer zu verwalten und schwierig bereitzustellen. Ich benötige eine Microservices-Plattform, auf der ein Administrator Hunderte von Microservices verwalten und betreiben kann.

Ist diese Frage sinnvoll?

@hectoralicea Dieses

Bei allgemeinen Fragen wie diesen posten Sie bitte die Kubernetes-Benutzergruppen. Sie sind normalerweise viel hilfreicher für diese Art von Diskussion auf hoher Ebene :)

Siehe https://groups.google.com/forum/#!forum/kubernetes -users, http://slack.k8s.io/ oder Stack Overflow.

@colemickens @deads2k @nikhita @enisoc Ich habe einen Abschnitt für 1.9 hinzugefügt.

@sttts Verbesserte Betaversion in v1.9, oder?

@luxas Bugfixes natürlich. Aber ich glaube, das müssen wir hier nicht aufzählen.

@sttts Ich habe über die CRD-Validierung nachgedacht ... wird dies in diesem Feature-Problem behandelt und wird in v1.9 auf Beta umgestellt, oder?

@luxas aus dem ersten Beitrag

Scope of work planned for v1.9

    CRD validation to beta kubernetes/kubernetes#22768 kubernetes/kubernetes#53829
    CRD sub-resources as alpha kubernetes/community#913

Oh, danke @kargakis , hab da nicht

@deads2k , @enisoc keine Pläne für "stable" in 1.9, oder?

@idvoretskyi Richtig.

@deads2k :wave: Bitte öffnen Sie eine Dokumentations-PR und fügen Sie einen Link zur Tracking-Tabelle hinzu. Danke im Voraus!

@deads2k Bitte öffnen Sie eine Dokumentations-PR und fügen Sie einen Link zur Tracking-Tabelle hinzu. Danke im Voraus!

@zacharysarah Ich scheine den Tabellenlink verlegt zu haben. Dokumente zur CRD-Validierung hier https://github.com/kubernetes/website/pull/6066

Für die Aufzeichnung existiert das CRD-Versionsproblem hier: https://github.com/kubernetes/features/issues/544.

Liste der Aufgaben für CRDs, die zu GA wechseln: https://github.com/kubernetes/kubernetes/issues/58682

@nikhita bedeutet dies, dass die gesamte CRD-Funktion auf GA

Bedeutet das, dass die gesamte CRD-Funktion auf GA umgestellt wird?

Die API wird auf GA verschoben, dh auf v1, möglicherweise jedoch mit einigen Beta-/Alpha-Unterfunktionen. Es wird jedoch nicht beendet, wenn dies geschehen wird, dh ob 1.10 machbar ist.

@sttts @nikhita kannst du die Feature-Roadmap genauer definieren?

können Sie die Feature-Roadmap genauer definieren?

Für 1.10:

• Unterressourcen für benutzerdefinierte Ressourcen und Fehlerbehebungen (zumindest die nicht durchgestrichenen), die in https://github.com/kubernetes/kubernetes/issues/58682 aufgeführt sind.

Für die nächsten Releases sind keine _genauen_ Ergebnisse geplant, aber es ist geplant, bis Ende des Jahres auf GA zu gehen (https://groups.google.com/forum/#!topic/kubernetes-sig-api-machinery/ 07JKqCzQKsc).

Wir werden zur GA gehen, sobald alle Probleme, die in https://github.com/kubernetes/kubernetes/issues/58682 nicht durchgestrichen sind, abgeschlossen sind.

Wenn die CRD-API auf GA wechselt, sind möglicherweise Funktionen enthalten (Beispiel: CustomResourceValidation https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiextensions-apiserver/ pkg/features/kube_features.go#L35), die sich in Alpha/Beta befinden könnten.

@sttts @nikhita @deads2k
Gibt es Pläne dafür in 1.11?

Wenn ja, können Sie bitte sicherstellen, dass die Funktion mit den entsprechenden Informationen auf dem neuesten Stand ist:

• Beschreibung
• Meilenstein
• Bevollmächtigte(n)
• Etiketten:
  
  
  
  • stage/{alpha,beta,stable}
  
  
  • sig/*
  
  
  • kind/feature
  
  

cc @idvoretskyi

Gibt es Pläne dafür in 1.11?

Ich habe keine Berechtigung, den PR-Text zu bearbeiten (wenn das jemand kann, wäre es großartig!). Aber der Plan ist:

• Implementieren Sie die CRD-Versionsverwaltung. Dies hat ein weiteres Funktionsproblem: https://github.com/kubernetes/features/issues/544. Designvorschlag: https://github.com/kubernetes/community/pull/2026.
• Beschneiden und Standardeinstellungen für benutzerdefinierte Ressourcen hinzufügen.
• Unterstützungszuordnungen im CRD-Validierungsschema. https://github.com/kubernetes/kubernetes/issues/59485
• Implementieren Sie Kontingentunterstützung für benutzerdefinierte Ressourcen (dies kann auch als Fehlerbehebung angesehen werden) https://github.com/kubernetes/kubernetes/issues/53777

Wenn ja, können Sie bitte sicherstellen, dass die Funktion mit den entsprechenden Informationen auf dem neuesten Stand ist:
Beschreibung

Die einzeilige Beschreibung sollte aktualisiert werden, um "Validierung, Standardisierung, Unterressourcen und Versionierung für CRDs hinzufügen" zu enthalten.

In der Beschreibung erwähnte Designvorschläge müssen Folgendes enthalten:

• https://github.com/kubernetes/community/pull/2026
• https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/customresources-validation.md
• https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/customresources-subresources.md

Kann jemand diese bitte auch in den PR-Text einfügen?

Etiketten:

/freundliches Feature

/cc @mboloool

Kann jemand diese bitte auch in den PR-Text einfügen?

getan

@nikhita @sttts @mbohlool -- nur um das klarzustellen,

@nikhita @sttts @mbohlool -- nochmal anpingen ...
Zielen wir auf die Betaversion von 1.11? Ich möchte nur sichergehen, dass der Feature-Freeze heute ist.

@justaugustus CRDs sind bereits Beta. GA ist für den 1.11. nicht geplant.

Alle aufgeführten Funktionen/Erweiterungen (Pruning, Defaulting, Versioning) werden wahrscheinlich als Alpha starten.

@sttts Hmmm, sollten wir in diesem Fall separate Probleme haben, um diese Funktionen / Erweiterungen und ihre Phasen unabhängig zu verfolgen?

Zum Aufzeichnen - @nikhita hat ein Issue für das Subfeature https://github.com/kubernetes/features/issues/571 erstellt

@sttts @justaugustus

Unterfunktionsproblem beim Standardisieren und Bereinigen: https://github.com/kubernetes/features/issues/575

@justaugustus @idvoretskyi für 1.12-Tracking-Zwecke: Es wird Ergänzungen und möglicherweise Fehlerkorrekturen geben, aber dies wird für 1.12 in der Beta bleiben (also keine Änderung aus der Perspektive der Funktionen).

Es gibt eine neue Unterfunktion, die als Alpha geplant ist, aber als separate Ausgabe erstellt wird: https://github.com/kubernetes/features/issues/575.

Hi
Diese Verbesserung wurde bereits nachverfolgt, daher würden wir gerne prüfen, ob es Pläne für diese Erweiterung der Phasen in Kubernetes 1.13 gibt. Diese Version soll "stabiler" sein und einen aggressiven Zeitplan haben. Bitte nehmen Sie diese Erweiterung nur auf, wenn ein hohes Maß an Vertrauen besteht, dass die folgenden Fristen eingehalten werden:

• Docs (offene Platzhalter-PRs): 11/8
• Code-Slush: 11/9
• Code-Einfrieren beginnt: 11/15
• Vollständige und überprüfte Dokumente: 27.11

Bitte nehmen Sie sich einen Moment Zeit, um die Meilensteine ​​in Ihrem ursprünglichen Beitrag für die zukünftige Verfolgung zu aktualisieren und pingen Sie Tracking-Blatt für 1.13 Verbesserungen aufgenommen werden müssen

Vielen Dank!

Diese Verbesserung wurde bereits nachverfolgt, daher würden wir gerne prüfen, ob es Pläne für diese Erweiterung der Phasen in Kubernetes 1.13 gibt.

Nein, ein Abschluss in 1.13 ist nicht geplant. Die CRD-API wird in der Betaphase bleiben.

Die Probleme veralten nach 90 Tagen Inaktivität.
Markieren Sie das Problem mit /remove-lifecycle stale .
Veraltete Ausgaben verrotten nach weiteren 30 Tagen Inaktivität und werden schließlich geschlossen.

Wenn dieses Problem jetzt sicher geschlossen werden kann, tun Sie dies bitte mit /close .

Senden Sie Feedback an sig-testing, kubernetes/test-infra und/oder fejta .
/Lebenszyklus veraltet

/Remove-Lifecycle-Stale

@deads2k Hallo - ich bin der prüfe dieses Problem, um zu sehen, welche Arbeiten (falls vorhanden) für die Version 1.14 geplant sind. Das Einfrieren der Erweiterungen ist am 29. Januar und ich möchte daran erinnern, dass alle Erweiterungen ein KEP haben müssen

@claurence Die CRD-API wird auch für 1.14 in der Betaphase bleiben.

Hallo @nikhita @deads2k , ich bin der Enhancement Lead für 1.15. Wird diese Funktion in 1.15 die Alpha-/Beta-/Stable-Phasen abschließen? Bitte lassen Sie es mich wissen, damit es richtig verfolgt und der Tabelle hinzugefügt werden kann. Ein KEP muss auch für die Aufnahme von 1.15 zusammengeführt werden. Vielen Dank!

Sobald die Codierung beginnt, listen Sie bitte alle relevanten k/k-PRs in dieser Ausgabe auf, damit sie ordnungsgemäß nachverfolgt werden können.

dies wird im Beta-Stadium bleiben. Arbeiten an Validierung, Konvertierung und OpenAPI-Veröffentlichung finden in 1.15 statt

aktualisierte Beschreibung mit Links zu relevanten KEPs für 1.15

Hey, @liggitt @deads2k @jpbetz @sttts Ich bin der Schatten der Version 1.15 der Dokumente.

Erfordert diese Verbesserung (oder die für v1.15) geplante Arbeit neue Dokumente (oder Änderungen)?

Nur eine freundliche Erinnerung, wir suchen eine PR gegen k/website (Zweig dev-1.15) bis Donnerstag, 30. Mai. Es wäre toll, wenn es der Anfang der vollständigen Dokumentation wäre, aber selbst ein Platzhalter-PR ist akzeptabel. Lassen Sie es mich wissen, wenn Sie Fragen haben! 😄

@deads2k @jpbetz @sttts @liggitt

Nur eine freundliche Erinnerung, wir suchen eine PR gegen k/website (Zweig dev-1.15) bis Donnerstag, 30. Mai. Es wäre toll, wenn es der Anfang der vollständigen Dokumentation wäre, aber selbst ein Platzhalter-PR ist akzeptabel. Lassen Sie es mich wissen, wenn Sie Fragen haben! 😄

Docs PR für 1.15: https://github.com/kubernetes/website/pull/14583

@deads2k können Sie die

/Meilenstein v1.16
/bühnenstall

Hey, @liggitt @jpbetz @sttts Ich bin der Versionsleiter von v1.16 docs.

Erfordert diese Verbesserung (oder die für v1.16) geplante Arbeit neue Dokumente (oder Änderungen)?

Nur eine freundliche Erinnerung, wir suchen eine PR gegen k/website (Zweig dev-1.16), die bis Freitag, den 23. August fällig ist. Lassen Sie es mich wissen, wenn Sie Fragen haben!

@simonswine der Platzhalter-PR https://github.com/kubernetes/website/pull/15982

@liggitt @jpbetz @sttts Donnerstag ist Code-Freeze. Gibt es ausstehende k/k-PRs, die verhindern, dass dies zu Stable wird? Alles im ursprünglichen Beitrag für geplante 1.15*-Arbeiten scheint zusammengeführt zu werden.

Ich glaube, die ausstehenden PRs sind nur der Feature-Gate-Versions-Bump (https://github.com/kubernetes/kubernetes/pull/81965) und zwei herausragende Bugfixes, die in dieser Woche erscheinen sollten: https://github.com/kubernetes /kubernetes/pull/81436 , https://github.com/kubernetes/kubernetes/issues/78707

Dokumente zur Überprüfung bereit in https://github.com/kubernetes/website/pull/15982

Als stabil in v1.16.0 veröffentlicht

Post-GA-Arbeit nachverfolgt in https://github.com/orgs/kubernetes/projects/28

/nah dran

@liggitt : Schließe dieses Problem.