@lavalamp J'ai créé ceci pour essayer d'avoir un endroit où nous pouvons au moins consolider nos pensées et suivre les progrès des ressources tierces. J'ai essayé de créer une liste de lacunes connues à résoudre avant la promotion en stable.

Je n'ai pas de propriétaire en tête, mais la reconnaissance du problème semble être l'étape 1.

@ deads2k J'apprends récemment une ressource tierce, je souhaite également aider avec quelque chose.

@ deads2k J'apprends récemment une ressource tierce, je souhaite également aider avec quelque chose.

J'ai réorganisé la liste en fonction de ce que je considère comme une priorité tactique. Les gens essaient de l'utiliser maintenant et ces problèmes les brûleront gravement.

Si vous êtes à l'aise avec l'élément « ressources multiples », ce serait un bon début. Vous pourriez créer un problème distinct et nous pourrons parler de la mise en œuvre là-dedans.

@ deads2k J'ai passé du temps à essayer de reproduire le premier problème :

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.

mais avec malchance. Voici mes étapes de reproduction :

1. créer une ressource tierce personnalisée et attendre qu'elle apparaisse

[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. après un moment (plus de 10s), créez une autre ressource tierce personnalisée

[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. vérifier que les deux ressources existent

[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.

semble que nous prenons déjà en charge plusieurs ressources, une seule version.

Et j'examine en profondeur le code lié à TPR. Le thirdparty_controller effectuera une synchronisation périodique (toutes les 10 secondes), il installera chaque nouveau TPR et effectuera également un travail de suppression. Le ThirdPartyResourceServer contient tous les mappages TPR installés. Comme nous pouvons le voir sur SyncOneResource et InstallThirdPartyResource , même si ce groupe existe, il mettra toujours à jour le groupe avec la nouvelle API.

J'ai également découvert que je pouvais supprimer une définition de schéma TPR même s'il y avait des instances TPR dans le système. Je pense que cela ne devrait pas être autorisé.

@ deads2k J'ai passé du temps à essayer de reproduire le premier problème :

Essayez d'activer ce test : https://github.com/kubernetes/kubernetes/blob/master/test/integration/thirdparty/thirdparty_test.go#L137 . Si ça marche, c'est bon. S'il échoue, quelque chose ne va pas.

@deads2k Salut David, veuillez jeter un œil au message que j'ai envoyé sur Slack. En outre, j'ajoute un correctif au test d'intégration échoué, le contrôleur de ressources tiers supprimera le gestionnaire de routes correspondant lorsqu'un TPR sera supprimé, cela aidera avec le test d'intégration, mais je ne sais pas si cela entraînera d'autres problèmes .

Pour le problème n°1, il a été corrigé ici :

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

@brendandburns en fait pas, vous pouvez exécuter le test d'intégration des commentaires, et il échouera.

@brendandburns Plus correctement, nous avons pris en charge plusieurs ressources, une seule version, mais la logique de suppression a un problème.

@AdoHe avez-vous déposé un problème? Je peux jeter un oeil.

@brendandburns vous pouvez voir ici :

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

activez ce test, et vous verrez qu'il échouera. J'ai essayé de résoudre ce problème sur ma section locale et j'ouvrirai un PR plus tard dans la journée.

@brendandburns Je crains de ne pas déposer de problème.

Réf également https://github.com/kubernetes/kubernetes/issues/32306 (TPR doit être supprimé lorsque l'espace de noms est supprimé)

@deads2k pouvez-vous mettre à jour la liste de contrôle ?

@deads2k pouvez-vous mettre à jour la liste de contrôle ?

Tous les problèmes restent en suspens. Il s'agit en fait d'une fonctionnalité permettant de suivre les problèmes dans l'implémentation (déjà) bêta thirdparyresources de la version 1.3. Nous avions besoin d'un endroit pour suivre nos problèmes, mais nous devions consacrer de l'énergie à d'autres efforts en 1.5.

@deads2k Je travaille déjà sur Multiple Resources, single version et Multiple versions , je pense que beaucoup de code doit être mis à jour.

@deads2k propose- t-il toujours la cible 1.5 ?

@idvoretskyi j'ai bien peur que non :(

@deads2k : ThirdPartyResources doit être ajouté aux API fédérées.

@deads2k : Actuellement, les sélecteurs de champs ne fonctionnent pas lors de la requête de ThirdPartyObjects, est-ce quelque chose pour votre liste ?

@deads2k @rmohr kubectl a encore de nombreuses capacités exceptionnelles contre TPR, la liste ci-dessus doit être mise à jour pour les suivre.

@deads2k : Actuellement, les sélecteurs de champs ne fonctionnent pas lors de la requête de ThirdPartyObjects, est-ce quelque chose pour votre liste ?

Il s'agit d'un problème plus général de prise en charge incohérente du sélecteur de champ sur tous les types d'API.

Je commence à regarder ça aussi. Les ThirdPartyResources sont très importantes pour prendre en charge les contrôleurs "externes" comme spark , et avant de pouvoir ajouter des éléments tels que des sous-ressources, nous devrions résoudre ce problème.

Les sélecteurs de champs ne fonctionnent que sur les champs sélectionnés manuellement dans les objets API standard. Je ne m'attendrais pas à ce qu'ils fonctionnent pour les champs des TPR - apiserver n'est pas conçu pour effectuer des requêtes arbitraires. Si vous avez besoin de ce comportement, TPR ne fonctionnera pas pour vous.

La prochaine étape est-elle ici pour déplacer les TPR dans un serveur API addon ?
Il semble qu'il y ait des PR en suspens pour résoudre certains des problèmes de la liste ici qui peuvent être bloqués sur cet élément.

/cc @liggitt @deads2k @AdoHe

Pour réduire la complexité des TPR dans le code apiserver et rendre la logique TPR beaucoup plus explicite, je voterais certainement pour un tpr-apiserver autonome. Mais IMO, cela ne bloque vraiment aucun des correctifs.

J'ajoute quelques éléments sur la gestion de la sémantique de l'API (get, list, watch, update, patch) lors du traitement de plusieurs Kinds non convertibles. Je pense que cela nécessite probablement un document de conception, car il est peu probable que la sémantique corresponde à la sémantique normale de l'API.

Je vais tenter (encore un autre) de résoudre certains de ces problèmes...

https://github.com/kubernetes/kubernetes/pull/40260 et https://github.com/kubernetes/kubernetes/pull/40096 nous mettront en forme du côté kubectl

Le problème le plus grave côté serveur à l'heure actuelle est que le ramasse-miettes perd la tête face aux refowners qui pointent vers les TPR.

Une fois que nous aurons résolu ce problème, nous devrions décider quelle devrait être la sémantique de l'API autour de plusieurs versions d'un TPR donné et nous assurer que le type de TPR dispose des données dont nous avons besoin. Cela est susceptible d'affecter l'implémentation de stockage côté serveur, je préfère donc affiner la conception avant de faire trop de travail côté serveur.

@liggitt, je vais jeter un œil à ceux-ci. THX

Quelqu'un sait-il comment faire référence aux TPR dans les règles RBAC ? J'ai un TPR nommé foo-bar.something.example.com. En tant qu'administrateur de cluster, je peux obtenir une liste de foobars dans un espace de noms donné avec kubectl get foobars .

Lorsqu'un utilisateur régulier essaie la même chose, il obtient Error from server (Forbidden): the server does not allow access to the requested resource (get foobars.something.example.com) .

J'ai essayé toutes les variantes de foobar, foo-bar, etc. auxquelles je peux penser dans une règle RBAC sans succès jusqu'à présent.

Dans la règle, vous recherchez resource=foobars apigroup=something.example.com verb=get,list,watch

@ deads2k Cela a fait l'affaire. Merci!

@liggitt

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

quelque chose en rapport avec le problème de nettoyage TPR ?

Non, c'était un problème avec le ramasse-miettes ne sachant pas comment rechercher les ownerRefs à autre chose que les types compilés. Le problème inverse existe également, le ramasse-miettes ne faisant pas attention aux finaliseurs sur autre chose que les types compilés.

Ces deux problèmes de ramasse-miettes sont distincts de la nécessité de nettoyer les objets ThirdPartyResourceData de manière fiable lorsque l'objet ThirdPartyResource est supprimé.

@liggitt Merci pour l'explication patiente, alors quel est le plan de TPR en 1.6 ?

Le GC n'enregistre désormais que 1 000 fois par seconde au lieu de 50 000 fois par seconde,
il ne gagne donc plus la course avec le rotator. Mais une vraie solution sera
bientôt, espérons-le.

Le samedi 4 février 2017 à 23h54, TonyAdo [email protected] a écrit :

@liggitt https://github.com/liggitt Merci pour l'explication patiente, alors
quel est le plan de TPR en 1.6 ?

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/kubernetes/features/issues/95#issuecomment-277503470 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAnglmGf00K6W7SsJ1aSqWOI_M-A7Hf2ks5rZYBPgaJpZM4KLBmK
.

Quelques-unes des questions en suspens liées à l'examen des politiques commerciales. Pas exhaustive.

Problèmes de groupe/version : https://github.com/kubernetes/kubernetes/pull/24299 , https://github.com/kubernetes/kubernetes/pull/36977
Regardez : https://github.com/kubernetes/kubernetes/issues/25340
Lien automatique : https://github.com/kubernetes/kubernetes/issues/37622
Suppression de l'espace de noms : https://github.com/kubernetes/kubernetes/issues/37554
GC : https://github.com/kubernetes/kubernetes/issues/39816
Finaliseurs : https://github.com/kubernetes/kubernetes/issues/40715
Nettoyage des données TPR : https://github.com/kubernetes/kubernetes/issues/35949
Validation renforcée des métadonnées : https://github.com/kubernetes/kubernetes/issues/22768#issuecomment -215940468
Manque de tests unitaires : https://github.com/kubernetes/kubernetes/pull/40956
Nettoyage : https://github.com/kubernetes/kubernetes/issues/36998

Fonctionnalités que les utilisateurs pensent être des bogues car elles fonctionnent pour d'autres ressources :
Comportement asynchrone : https://github.com/kubernetes/kubernetes/issues/29002
Entiers : https://github.com/kubernetes/kubernetes/issues/30213
YAML : https://github.com/kubernetes/kubernetes/issues/37455
Sortie kubectl décente : https://github.com/kubernetes/kubernetes/issues/31343
Simplifiez le nommage des ressources : https://github.com/kubernetes/kubernetes/issues/29415
Postulez : https://github.com/kubernetes/kubernetes/issues/29542 , https://github.com/kubernetes/kubernetes/issues/39906
Modifier : https://github.com/kubernetes/kubernetes/issues/35993

/cc

S'abonner car nous essayons de gérer les TPR dans le tableau de bord.

Les problèmes de suivi sont https://github.com/kubernetes/dashboard/issues/1671 et https://github.com/kubernetes/dashboard/issues/1504.

@kubernetes/dashboard-maintainers

Quel est le statut/plan pour la TPR sans espace de noms ? Je n'ai pas trouvé de discussions à ce sujet, peut-être raté quelque chose ?

@sttts Pour commencer, je suis intrigué par le développement chez Kubernetes. Et je veux y contribuer, mais le Go est une nouvelle langue pour moi. Qu'est-ce que vous me recommandez de faire pour que je puisse obtenir ce projet pour GSoC 2017 ?

Pour ajouter quelque chose sur moi, je suis assez bon en C++ et Java et je suis titulaire d'un baccalauréat en informatique. J'ai également commencé à lire la documentation et j'ai suivi le cours Udacity impliquant Kubernetes.

@grpndrs, nous avons une liste de problèmes étiquetés qui constituent un bon point de départ pour entrer dans le code : https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Afor-new -les contributeurs. N'hésitez pas à me contacter dans slack et nous pourrons en parcourir quelques-uns.

@enisoc

Le Multiple Resources, single version, different add times toujours un problème ? Je peux à la fois créer et supprimer plusieurs TPR sans problème.

De plus, pouvons-nous numéroter les cases à cocher en Outstanding Capabilities pour qu'il soit plus facile de s'y référer ? @ deads2k Je pense que vous pouvez le faire comme ceci:

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

Est-ce que n'importe qui sait comment le composant de validation de ceci avance ? Je travaille beaucoup avec les TPR et cette fonctionnalité serait inestimable et permettrait d'économiser BEAUCOUP de code personnalisé. J'aimerais contribuer à cette fonctionnalité, mais j'aimerais savoir si quelqu'un abonné à ce problème connaît son statut

Est-ce que n'importe qui sait comment le composant de validation de ceci avance ?

Je ne m'attends pas à ce que cela se produise pour 1.7. Pour le moment, nous discutons de certaines douleurs de croissance structurelles ici https://github.com/kubernetes/community/pull/524 pour fournir une base plus stable sur laquelle se développer.

Je ne m'attends pas à ce que cela se produise pour 1.7. Pour le moment, nous discutons de certaines difficultés de croissance structurelles ici kubernetes/community#524 pour fournir une base plus stable sur laquelle se développer.

Nous prévoyons d'aller de l'avant avec https://github.com/kubernetes/community/blob/master/contributors/design-proposals/thirdpartyresources.md dans le délai de 1.7. Je ferai des mises à jour ici et dans les appels sig-apimachinery au fur et à mesure que nous avancerons.

@ deads2k Je n'ai rien vu à propos de la validation tpr. Ne considérez-vous pas que c'est quelque chose qui serait nécessaire pour la bêta ?

@frankgreco, la proposition concerne une base solide sur laquelle les TPR peuvent s'appuyer. Des fonctionnalités telles que la validation peuvent être ajoutées ultérieurement, mais sont hors de portée ici.

J'ai modifié le commentaire parent de ce fil pour utiliser le nouveau modèle et pour clarifier la portée du travail prévu pour la 1.7, si je comprends bien. Veuillez le lire et corriger/commenter.

@deads2k @enisoc Nous

@deads2k @enisoc Nous

Absolument. Pour quelque chose comme ça, nous voudrions une proposition de conception avant de commencer à examiner les demandes de tirage. De plus, étant donné le nombre d'approches différentes possibles, je vous suggère d'énumérer les trois principales idées et de donner une brève explication des raisons pour lesquelles celle que vous choisissez est la meilleure. Depuis son côté serveur, les considérations de performances et de sécurité sont très importantes.

De plus, comme il s'agit d'une fonctionnalité de grande envergure, il est important qu'elle ne devienne pas une contribution incontrôlable. Des contributions actives (critiques, tests, code, migration) pour la transition vers https://github.com/kubernetes/community/blob/master/contributors/design-proposals/thirdpartyresources.md aideraient. Je suis deads2k sur slack si vous êtes intéressé et que vous voulez parler.

Merci @deads2k ! C'est tout à fait raisonnable. Nous ferons des propositions de conception pour la validation TPR, quelle est la meilleure façon de les partager ? je vais aussi me relâcher

@xiao-zhou, nous sommes heureux d'avoir un projet Google Summer of Code accepté autour de ce même sujet (annoncé hier). Discutons sur Slack de la façon de collaborer à ce sujet. Très cool que cela vous intéresse aussi, nous avons donc beaucoup de force pour faire avancer cela !

@xiao-zhou @sttts @deads2k dès que vous avez une proposition de validation TPR (et idéalement par défaut) pensez-moi dans l'examen de la proposition ? Merci

@sdminonne il sera posté dans sig-apimachinery. Si vous vous abonnez à ce groupe Google, vous devriez en être averti.

@sttts merci

@deads2k allez-vous ajouter ObservedGeneration pour les TPR ?

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

@deads2k allez-vous ajouter ObservedGeneration pour les TPR ?

Je n'en avais pas l'intention. Un client qui s'en soucie ne pourrait-il pas simplement comparer les noms des spécifications et des statuts ?

comparer les noms de spécifications et de statut ?

Je ne suis pas sûr de te comprendre. Corrigez-moi Si je me trompe mais que je pense qu'il y a deux parties concernant ObservedGeneration : 1) le serveur API doit mettre à jour metadata.generation chaque fois qu'il y a une mise à jour dans la spécification du TPR et 2) le contrôleur responsable du TPR met status.observedGeneration jour metadata.Generation . Je suppose que 1) est ce que je vous demande et 2) est quelque chose dont les auteurs de TPR doivent s'occuper ?

Je ne suis pas sûr de te comprendre. Corrigez-moi Si je me trompe mais que je pense qu'il y a deux parties concernant ObservedGeneration : 1) le serveur API doit mettre à jour metadata.generation chaque fois qu'il y a une mise à jour dans la spécification de la TPR et 2) le contrôleur responsable de l'état des mises à jour de la TPR .observedGeneration basé sur les métadonnées.Generation. Je suppose que 1) est ce que je vous demande et 2) est quelque chose dont les auteurs de TPR doivent s'occuper ?

Oh, j'ai mal compris de quoi tu parlais. Vous voulez observerGeneration pour le CustomResource, pas le CustomResourceDefinition. Je pensais qu'observedGeneration n'était repoussé que pour les modifications de spécifications nécessitant une action. Cela signifie qu'une mise à jour des métadonnées ne l'a pas déclenchée et qu'une mise à jour de certains champs de spécification pourrait également éviter de la perturber.

Dans mon commentaire lié ci-dessus, je demandais le support de Generation pour les instances TPR, pas pour les TPR eux-mêmes (bien que ce serait bien aussi. Des raisons de ne pas l'ajouter à tous les objets ?).

Par exemple, si j'ai Kind: TPR; name: foo.example.com et une instance de ce TPR Kind: Foo; name: foo123 , je suis intéressé par Generation/ObservedGeneration pour foo123 afin que le contrôleur Foo puisse informer les consommateurs Foo s'il a traité une mise à jour de l'instance foo123 . Est-ce que ça fait du sens? Je ne vois pas comment cela peut être réalisé sans un support approprié du côté du serveur k8s.

Oui, generation/observedGeneration a du sens pour le schéma utilisateur de la TPR et non pour la ressource TPR réelle telle qu'elle a évolué.

@kargakis La règle est de

La règle est de n'incrémenter la génération d'objets que lors de la mise à jour des spécifications, et non du statut, n'est-ce pas ?

Correct.

Si c'est le cas, cela signifie que nous devons d'abord prendre en charge officiellement la division Spec/Status sur l'instance TPR.

Oui, je m'attendais à trouver cette division dans le cadre du problème existant, mais il semble qu'il reste du travail à faire avant d'y arriver.

@kargakis J'ai modifié le commentaire de niveau supérieur pour mentionner ces éléments, bien qu'ils soient hors de portée de 1.7.

/cc

@deads2k Devrions-nous ajouter un nom abrégé pour CustomResourceDefinition ?

Ajout du nom abrégé CRD pour CustomResourceDefinition .

Une proposition de conception pour la validation de CustomResources : https://github.com/kubernetes/community/pull/708 :smile:

@deads2k @enisoc @lavalamp
se demandait si l'utilisateur peut configurer les méthodes ET (OU) CURD du contrôleur k8s pour les objets CRD

Dans mon cas d'utilisation particulier, je crée un CRD networks.stable.example.com et l'utilise pour créer l'objet réseau net1 :

Je dois m'assurer qu'un nouvel objet CRD réseau n'est pas autorisé à être créé si un objet CRD réseau avec une plage de sous-réseaux qui se chevauche existe déjà

Si un tel mécanisme n'existe pas, je serai heureux de rassembler quelques idées dans un document de conception.

Comme mentionné dans les notes de version et les documents 1.7, TPR est désormais obsolète et nous prévoyons de le supprimer dans la version 1.8. Les utilisateurs doivent passer à CRD pendant la période 1.7.

Veuillez commenter le problème de suivi pour la suppression si vous avez des questions ou des préoccupations.

Mises à jour/Plans pour 1.8 :

• Prise en charge de la validation et de la mise en valeur par défaut basées sur le schéma JSON pour CustomResources ( proposition )
• Ajouter des sous-ressources (comme le statut et l'échelle) pour les CR (~proposition à paraître bientôt~ proposition )

Merci @nikhita. J'ai modifié le premier commentaire pour refléter les plans 1.8.

La découverte renvoie des informations correctes pour les CR mais le mappeur REST ne l'utilise pas - https://github.com/kubernetes/kubernetes/issues/49948

Proposition de sous-ressources pour CustomResources : https://github.com/kubernetes/community/pull/913 :tada :

Veuillez pardonner mon erreur de publication, mais je suis arrivé sur cette page à partir d'une autre page kubernetes en pensant que kubernetes incluait un cadre de micro-services, au-delà de la simple gestion des ressources de conteneurs tiers.

Redhat commercialise OpenShift kubernetes en tant que plate-forme de micro-services, mais pourtant, je n'arrive pas à trouver cette fonctionnalité. Je suis à la recherche d'un serveur d'applications pour héberger ma propre suite de micro-services applicatifs indépendants très légers.

Est-ce qu'une telle chose existe, ou sommes-nous relégués à créer de grosses applications de guerre Java dans Springboot et à les déployer sur un serveur Tomcat qui se trouve dans un conteneur géré par kuberenetes, c'est difficile à gérer et difficile à déployer. J'ai besoin d'une plate-forme de micro-services où 1 administrateur peut gérer et exploiter des centaines de micro-services.

Cette question a-t-elle un sens ?

@hectoralicea ce

Pour des questions générales comme celle-ci, veuillez publier sur les groupes d'utilisateurs Kubernetes. Ils sont généralement beaucoup plus utiles pour ce genre de discussion de haut niveau :)

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

@colemickens @deads2k @nikhita @enisoc J'ai ajouté une section pour 1.9.

@sttts Version bêta améliorée dans la v1.9, n'est-ce pas ?

@luxas corrections de bugs bien sûr. Mais je ne pense pas que nous ayons à énumérer cela ici.

@sttts Je pensais à la validation CRD... est-ce couvert dans ce problème de fonctionnalités et passera à la version bêta dans la v1.9 ou?

@luxas du post initial

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, merci @kargakis ,

@deads2k , @enisoc pas de plans pour "stable" dans la 1.9, non ?

@idvoretskyi Exact .

@deads2k :wave: Veuillez ouvrir une documentation PR et ajouter un lien vers la feuille de calcul de suivi. Merci d'avance!

@deads2k Veuillez ouvrir une documentation PR et ajouter un lien vers la feuille de calcul de suivi. Merci d'avance!

@zacharysarah Je semble avoir égaré le lien de la feuille de calcul. Documents pour la validation CRD ici https://github.com/kubernetes/website/pull/6066

Pour mémoire, le problème de versionnage de CRD existe ici : https://github.com/kubernetes/features/issues/544.

Liste des tâches pour les CRD passant à GA : https://github.com/kubernetes/kubernetes/issues/58682

@nikhita cela signifie-t-il que l'ensemble de la fonctionnalité CRD passe à GA ?

cela signifie-t-il que l'intégralité de la fonctionnalité CRD est transférée vers GA ?

L'API passera à GA, c'est-à-dire à v1, éventuellement avec quelques sous-fonctionnalités bêta/alpha. Il n'est cependant pas terminé quand cela se produira, c'est-à-dire si la 1.10 est faisable.

@sttts @nikhita pouvez-vous définir plus précisément la feuille de route des fonctionnalités ?

pouvez-vous définir plus précisément la feuille de route des fonctionnalités ?

Pour la 1.10 :

• sous-ressources pour les ressources personnalisées et les corrections de bogues (au moins celles qui ne sont pas barrées) répertoriées dans https://github.com/kubernetes/kubernetes/issues/58682.

Il n'y a pas d'ensemble _exact_ de livrables prévu pour les prochaines versions, mais le plan est de passer en disponibilité générale d'ici la fin de l'année (https://groups.google.com/forum/#!topic/kubernetes-sig-api-machinery/ 07JKqCzQKsc).

Nous irons à GA une fois que tous les problèmes qui ne sont pas barrés dans https://github.com/kubernetes/kubernetes/issues/58682 seront terminés.

Lorsque l'API CRD devient GA, il peut contenir des fonctionnalités (exemple : CustomResourceValidation https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiextensions-apiserver/ pkg/features/kube_features.go#L35) qui pourrait être en alpha/beta.

@sttts @nikhita @deads2k
Des plans pour cela dans 1.11?

Si tel est le cas, pouvez-vous vous assurer que la fonctionnalité est à jour avec les éléments appropriés :

• La description
• Jalon
• Cessionnaire(s)
• Étiquettes:
  
  
  
  • stage/{alpha,beta,stable}
  
  
  • sig/*
  
  
  • kind/feature
  
  

cc @idvoretskyi

Des plans pour cela dans 1.11?

Je n'ai pas l'autorisation de modifier le corps des relations publiques (si quelqu'un peut le faire, ce serait génial !). Mais le plan est :

• Mettre en œuvre le contrôle de version CRD. Cela a un autre problème de fonctionnalités : https://github.com/kubernetes/features/issues/544. Proposition de conception : https://github.com/kubernetes/community/pull/2026.
• Ajoutez l'élagage et la valeur par défaut pour les ressources personnalisées.
• Cartes de support dans le schéma de validation CRD. https://github.com/kubernetes/kubernetes/issues/59485
• Implémentez la prise en charge des quotas pour les ressources personnalisées (cela peut également être considéré comme une correction de bogue) https://github.com/kubernetes/kubernetes/issues/53777

Si tel est le cas, pouvez-vous vous assurer que la fonctionnalité est à jour avec les éléments appropriés :
La description

La description d'une ligne doit être mise à jour pour inclure « Ajouter la validation, les valeurs par défaut, les sous-ressources et la gestion des

Les propositions de conception mentionnées dans la description doivent inclure :

• 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

Quelqu'un peut-il également les ajouter dans le corps des relations publiques ?

Étiquettes:

/ fonction gentille

/cc @mbohlool

Quelqu'un peut-il également les ajouter dans le corps des relations publiques ?

terminé

@nikhita @sttts @mbohlool -- juste pour clarifier, visons-nous la bêta pour le cycle 1.11 ?

@nikhita @sttts @mbohlool -- ping à nouveau sur ce...
Ciblons-nous la version bêta de la 1.11 ? Je veux juste m'assurer que le gel des fonctionnalités est aujourd'hui.

Les CRD de

Toutes les fonctionnalités/extensions répertoriées (élagage, définition par défaut, gestion des versions) commenceront probablement en tant qu'alpha.

@sttts Hmmm, dans ce cas, devrions-nous avoir des problèmes distincts pour suivre ces fonctionnalités / extensions et leurs étapes indépendamment ?

Pour enregistrer - @nikhita a créé un problème pour la sous-fonctionnalité https://github.com/kubernetes/features/issues/571

@sttts @justaugustus

Problème de sous-fonctionnalité par défaut et élagage : https://github.com/kubernetes/features/issues/575

@justaugustus @idvoretskyi à des fins de suivi 1.12 : il y aura des ajouts et peut-être des corrections de bugs mais cela restera en version bêta pour 1.12 (donc aucun changement du point de vue des fonctionnalités).

Il existe une nouvelle sous-fonctionnalité prévue en tant qu'alpha, mais elle est créée en tant que problème distinct : https://github.com/kubernetes/features/issues/575.

salut
Cette amélioration a déjà été suivie, nous aimerions donc vérifier et voir s'il est prévu que cela gradue les étapes dans Kubernetes 1.13. Cette version est destinée à être plus « stable » et aura un calendrier agressif. Veuillez n'inclure cette amélioration que si vous êtes sûr qu'elle respectera les délais suivants :

• Docs (espace réservé PRs ouvert) : 11/8
• Code Slush : 11/9
• Début du gel du code : 11/15
• Documents terminés et révisés : 27/11

Veuillez prendre un moment pour mettre à jour les jalons de votre message d'origine pour un suivi futur et envoyer un ping à feuille de suivi des améliorations 1.13

Merci!

Cette amélioration a déjà été suivie, nous aimerions donc vérifier et voir s'il est prévu que cela gradue les étapes dans Kubernetes 1.13.

Non, il n'est pas prévu de graduer cela en 1.13. L'API CRD restera en version bêta.

Les problèmes deviennent obsolètes après 90 jours d'inactivité.
Marquez le problème comme récent avec /remove-lifecycle stale .
Les problèmes périmés pourrissent après 30 jours supplémentaires d'inactivité et finissent par se fermer.

Si ce problème peut être résolu en toute sécurité maintenant, veuillez le faire avec /close .

Envoyez vos commentaires à sig-testing, kubernetes/test-infra et/ou fejta .
/cycle de vie périmé

/supprimer le cycle de vie périmé

@deads2k Bonjour - Je suis le responsable de l'amélioration pour la version 1.14 et je vérifie ce problème pour voir quel travail (le cas échéant) est prévu pour la version 1.14. Le gel des améliorations est le 29 janvier et je tiens à rappeler que toutes les améliorations doivent avoir un KEP

@claurence L'API CRD restera également en version bêta pour la version 1.14.

Bonjour @nikhita @deads2k , je suis le responsable de l'amélioration pour la 1.15. Cette fonctionnalité va-t-elle passer les étapes alpha/bêta/stable dans la version 1.15 ? S'il vous plaît laissez-moi savoir afin qu'il puisse être suivi correctement et ajouté à la feuille de calcul. Un KEP devra également être fusionné pour l'inclusion 1.15. Merci!

Une fois le codage commencé, veuillez répertorier tous les PR k/k pertinents dans ce numéro afin qu'ils puissent être suivis correctement.

cela restera en phase bêta. le travail sur la validation, la conversion et la publication OpenAPI est en cours dans la version 1.15

description mise à jour avec des liens vers les KEP pertinents pour 1.15

Hé, @liggitt @deads2k @jpbetz @sttts Je suis l'ombre de la publication de la documentation v1.15.

Cette amélioration (ou le travail prévu pour la v1.15) nécessite-t-elle de nouveaux documents (ou modifications) ?

Juste un rappel amical, nous recherchons un PR contre k/website (branche dev-1.15) dû d'ici le jeudi 30 mai. Ce serait formidable si c'était le début de la documentation complète, mais même un PR d'espace réservé est acceptable. Faites moi savoir si vous avez des questions! ??

@deads2k @jpbetz @sttts @liggitt

Juste un rappel amical, nous recherchons un PR contre k/website (branche dev-1.15) dû d'ici le jeudi 30 mai. Ce serait formidable si c'était le début de la documentation complète, mais même un PR d'espace réservé est acceptable. Faites moi savoir si vous avez des questions! ??

Docs PR pour 1.15 : https://github.com/kubernetes/website/pull/14583

@ deads2k pouvez-vous mettre à jour la description du problème ?

/jalon v1.16
/écurie d'étape

Hé, @liggitt @jpbetz @sttts Je suis le responsable de la publication des documents v1.16.

Cette amélioration (ou le travail prévu pour la v1.16) nécessite-t-elle de nouveaux documents (ou modifications) ?

Juste un rappel amical, nous recherchons un PR contre k/website (branche dev-1.16) dû d'ici le vendredi 23 août. Faites moi savoir si vous avez des questions!

@simonswine l'espace réservé PR https://github.com/kubernetes/website/pull/15982

@liggitt @jpbetz @sttts Jeudi, c'est le gel du code. Y a-t-il des PR k/k en suspens qui l'empêcheront de passer à Stable ? Tout dans le message d'origine pour le travail 1.15* prévu semble être fusionné.

Je pense que les PR exceptionnels ne sont que le bump de la version de la porte des fonctionnalités (https://github.com/kubernetes/kubernetes/pull/81965) et deux corrections de bugs exceptionnelles qui devraient être apportées cette semaine : https://github.com/kubernetes /kubernetes/pull/81436 , https://github.com/kubernetes/kubernetes/issues/78707

docs prêts à être examinés dans https://github.com/kubernetes/website/pull/15982

Sorti comme stable dans la v1.16.0

Travail post-GA suivi dans https://github.com/orgs/kubernetes/projects/28

/proche

@liggitt : Clôture de ce problème.