@danehans Merci d'avoir
cc @idvoretskyi Pour info

problème xref ipv6 : https://github.com/kubernetes/kubernetes/issues/1443

@danehans :wave: Veuillez l'indiquer dans le tableau de suivi des fonctionnalités 1.9
si cette fonctionnalité a besoin de documentation. Si oui, veuillez ouvrir un PR et ajouter un lien vers la feuille de calcul de suivi. Merci d'avance!

@zacharysarah Je n'ai accès aux commentaires qu'au tableau de suivi des fonctionnalités 1.9, j'ai donc ajouté des commentaires pour l'exigence de documents IPv6.

cc: @mmueen

@zacharysarah le journal des modifications de la version 1.9 doit-il être mis à jour manuellement pour référencer l'un des PR IPv6 ou https://github.com/kubernetes/kubernetes/issues/1443 ?

@danehans Quand tu dis changelog, tu veux dire les notes de version ?

/cc @Bradamant3 pour la visibilité des notes de version

Oui, j'essaie de comprendre si quelque chose doit être ajouté aux notes de version 1.9, et si oui, quel processus suivre. Merci.

Cela devrait avoir une note de version

/cc @Bradamant3 @nickchase Visibilité de la note de version ! ️

Le brouillon de la note de version de
https://docs.google.com/document/d/1veHHyDH9VoNTwP6yy9u2Q7Jj1hnBJGVPv3NPHInImgU/edit

Vous pouvez suivre les instructions en haut du document.

xréf : https://groups.google.com/forum/#!topic/kubernetes -sig-release/x6ySPIJkMN4 par @enisoc

@xiangpengzhao J'ai mis à jour les notes de version 1.9 avec les détails de support ipv6. S'il vous plaît laissez-moi savoir si le contenu add'l ipv6 est requis pour les notes de version 1.9.

@danehans Je pense que les détails que vous avez ajoutés sont assez bons :+1: . Mais personnellement, j'aimerais voir les PR associés (s'ils existent) pour les balles.

• La prise en charge d'IPv6 alpha a été ajoutée. Les détails notables de la prise en charge d'IPv6 incluent :
  
  
  
  • Prise en charge des déploiements de clusters Kubernetes IPv6 uniquement. Cette fonctionnalité ne prend pas en charge la double pile.
  
  
  • Prise en charge des plans de contrôle et de données IPv6 Kubernetes.
  
  
  • Prise en charge des déploiements de clusters IPv6 Kubernetes à l'aide de kubeadm.
  
  
  • Prise en charge du backend iptables kube-proxy à l'aide d'ip6tables.
  
  
  • Repose sur les binaires CNI 0.6.0 pour la mise en réseau des pods IPv6.
  
  
  • Bien que d'autres plugins CNI prennent en charge IPv6, seuls les plugins CNI bridge et local-ipam ont été testés pour la version alpha.
  
  
  • Ajoute la prise en charge d'IPv6 pour kube-dns à l'aide d'enregistrements SRV.
  
  
  • Mises en garde
  
  
  • Les HostPorts ne sont pas pris en charge.
  
  
  • Un masque de réseau IPv6 pour le réseau cidr de pod ou de cluster doit être /66 ou plus long. Par exemple : 2001:db1::/66, 2001: dead:beef ::/76, 2001:cafe::/118 sont pris en charge. 2001:db1::/64 n'est pas pris en charge
    
    ```
  
  

@danehans J'ai Before Upgrading . Je ne pense pas que nous devrions les mettre là.

@xiangpengzhao La seule préoccupation que j'ai est que plusieurs PR ont été utilisés pour les différentes balles.

@xiangpengzhao J'ai déplacé le contenu IPv6 pour les notes de version 1.9. S'il vous plaît laissez-moi savoir si vous avez d'autres préoccupations.

@danehans That LGTM :)

J'utilise Kubernetes sur IPv6 uniquement (v1.8.x) depuis un certain temps maintenant,
et le plus gros problème à résoudre, je pense, est de détecter si IPv6 est activé pour arrêter d'utiliser ClusterIPs (10.32.xx) sur les clusters.

@ valentin2105 pouvez-vous s'il vous plaît ouvrir un problème dans k/k pour suivre cela si vous pensez qu'il s'agit d'un problème qui doit être résolu ?
https://github.com/kubernetes/kubernetes/issues

@danehans
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

@leblancd mène la charge IPv6. Je vais le laisser commenter.

@justaugustus - Cela devrait probablement être divisé en 2 problèmes distincts :
Prise en charge IPv6 uniquement : version 1.9, Alpha
Prise en charge de la double pile : version 1.11, Alpha
Je pense que ce problème (#508) est suffisant pour la prise en charge d'IPv6 uniquement, et un nouveau problème sera nécessaire pour la double pile.

/ fonction gentille

@leblancd

• Des travaux sont-ils prévus pour la prise en charge d'IPv6 uniquement dans la version 1.11 ? Si oui, pouvez-vous nous dire s'il s'agit d'un suivi alpha, bêta ou stable, afin que nous puissions définir le jalon ?
• Cela vous dérangerait-il d'ouvrir un problème avec les détails appropriés pour la prise en charge de Dual-Stack ?

@justaugustus
IPv6 uniquement fonctionne correctement sur les versions v1.9 et v1.10 et également en double pile.

@justaugustus :
Problème de fonctionnalité Dual-Stack

Cette fonctionnalité actuelle n'a pas de jalon, nous aimerions donc vérifier et voir s'il y a des plans pour cela dans Kubernetes 1.12.

Si tel est le cas, veuillez vous assurer que ce problème est à jour avec TOUTES les informations suivantes :

• Description de la fonctionnalité en une ligne (peut être utilisée comme note de version) :
• Contact principal (cessionnaire) :
• SIG responsables :
• Lien de proposition de conception (dépôt communautaire) :
• Lien vers e2e et/ou tests unitaires :
• Examinateur(s) - (pour LGTM) recommande d'avoir 2+ examinateurs (au moins un du fichier OWNERS de la zone de code) acceptés pour l'examen. Les évaluateurs de plusieurs entreprises ont préféré :
• Approbateur (probablement du SIG/de la zone à laquelle appartient la fonctionnalité) :
• Cible de fonctionnalité (quelle cible correspond à quel jalon) :
  
  
  
  • Cible de sortie alpha (xy)
  
  
  • Cible de la version bêta (xy)
  
  
  • Cible de version stable (xy)
  
  

Définissez les éléments suivants :

• La description
• Cessionnaire(s)
• Étiquettes:
  
  
  
  • stade/{alpha,beta,stable}
  
  
  • sig/*
  
  
  • genre/caractéristique
  
  

Une fois cette fonctionnalité correctement mise à jour, veuillez envoyer un ping explicite à @justaugustus , @kacole2 , @robertsandoval , @rajendar38 pour noter qu'elle est prête à être incluse dans la feuille de calcul de suivi des fonctionnalités pour Kubernetes 1.12 .

Veuillez noter que le gel des fonctionnalités est demain, le 31 juillet , après quoi tout problème de fonctionnalité incomplet nécessitera une demande d'exception pour être accepté dans le jalon.

De plus, veuillez tenir compte des délais pertinents suivants :

• Date limite des documents (espace réservé PR ouvert) : 21/08
• Gel du cas de test : 28/08

Veuillez vous assurer que tous les PR pour les fonctionnalités incluent également des notes de version pertinentes.

Bonne expédition !

PS Ceci a été envoyé via l'automatisation

Salut @leblancd

Existe-t-il un plan pour rendre la version bêta du support IPv6 dans K8s 1.12 ? Si vous vous en souvenez, j'avais posé des questions sur l'état de la prise en charge de la double pile dans https://github.com/kubernetes/features/issues/563. Comme la double pile a encore du travail à faire, j'essaie de déterminer si nous ne pouvons vivre qu'avec le support IPv6 pour le moment, mais c'est toujours en alpha, donc au cas où vous pourriez partager une date provisoire sur le moment où IPv6 peut devenir bêta /GA, ce sera vraiment utile.

@navjotsingh83 Quel point vous manque à propos d'IPv6 dans Kubernetes ?

Salut @valentin2105

Nous n'avons pas encore configuré et utilisé IPv6 dans K8. Mais avant d'entrer dans les détails, j'ai posté cette question parce qu'il s'agit toujours d'une fonctionnalité alpha, donc même si cela fonctionne (ce qui pourrait être le cas), nous ne pouvons pas avoir de fonctionnalités alpha en production. Nous sommes maintenant en phase de PoC/planification pour savoir si nous devons ou non déployer notre application sur K8 dans la prochaine version, donc en fonction du moment où la fonctionnalité deviendra bêta (au moins) ou GA (préférée), nous prendrons une décision go/nogo .

Salut @navjotsingh83 - La prise en charge d'IPv6 uniquement devrait être bêta dans K8s 1.13. Ce qui manque pour que la fonctionnalité IPv6 uniquement soit considérée comme bêta, c'est le CI Kubernetes IPv6 uniquement, et c'est en cours. Voici la proposition initiale d'un CI K8s (utilisant un cluster multinœud virtualisé dans un environnement GCE) : https://github.com/kubernetes/test-infra/pull/7529. Cette proposition de CI a du succès, mais le groupe test-infra m'a demandé de passer de l'utilisation d'un cluster basé sur GCE au déploiement d'un cluster multinœud directement dans un conteneur Prow (pour éliminer la dépendance aux opérations GCE). Cela se traduit par une architecture Docker-in-Docker-in-Docker, qui a été un peu difficile à mettre en œuvre. Je m'attends à avoir un nouveau CI PR dans une semaine qui s'exécute dans un conteneur Prow local, mais cela nécessitera une autre série d'examens avant d'être fusionné.

Y a-t-il quelque chose de spécifique re. le support double pile dont vous avez besoin ? En d'autres termes, si la prise en charge d'IPv6 uniquement était bêta/GA, serait-ce suffisant ? J'aimerais savoir si ce que nous avons proposé dans la spécification à double pile correspond à ce dont vous avez besoin.

Salut @leblancd @danehans
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 : 15/11
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

Nous encourageons également maintenant que chaque nouvelle amélioration s'aligne sur un KEP. Si un KEP a été créé, veuillez créer un lien vers celui-ci dans le message d'origine ou profitez-en pour développer un KEP.

Merci!

@leblancd merci pour la mise à jour ici, très intéressante. Heureux de voir que cela se concrétise enfin avec la 1.13.

Bonjour,

Je me demandais quel est l'état supposé actuel de la prise en charge d'IPv6 ? Si j'essaie d'amorcer un cluster en utilisant

kubeadm init --pod-network-cidr 2a0a:e5c0:102:3::/64 --apiserver-advertise-address=2a0a:e5c0:2:12:400:f0ff:fea9:c401 --service-cidr 2a0a:e5c0:102:6::/64

Le résultat est que le serveur API n'est pas joignable par la suite :

root<strong i="10">@ubuntu</strong>:/etc/kubernetes/manifests# kubectl get nodes
The connection to the server localhost:8080 was refused - did you specify the right host or port?

Vérification des conteneurs créés :

root<strong i="14">@ubuntu</strong>:/etc/kubernetes/manifests# docker ps 
CONTAINER ID        IMAGE                  COMMAND                  CREATED             STATUS              PORTS               NAMES
a55623e52447        k8s.gcr.io/pause:3.1   "/pause"                 7 minutes ago       Up 7 minutes                            k8s_POD_kube-apiserver-ubuntu_kube-system_fec7f583ea75dd4fc232913538c9fba1_0
cefb94378d33        ab81d7360408           "kube-scheduler --ad…"   24 minutes ago      Up 24 minutes                           k8s_kube-scheduler_kube-scheduler-ubuntu_kube-system_44b569a35761491825f4e7253fbf0543_0
c569ef8d9e30        26e6f1db2a52           "kube-controller-man…"   24 minutes ago      Up 24 minutes                           k8s_kube-controller-manager_kube-controller-manager-ubuntu_kube-system_fe38083b94da6f6c5a89788091e3bcb6_0
a25693b556e5        3cab8e1b9802           "etcd --advertise-cl…"   24 minutes ago      Up 24 minutes                           k8s_etcd_etcd-ubuntu_kube-system_7db86297afa09dfaa5049a791ed76555_0
9e85d0f7873d        k8s.gcr.io/pause:3.1   "/pause"                 24 minutes ago      Up 24 minutes                           k8s_POD_kube-scheduler-ubuntu_kube-system_44b569a35761491825f4e7253fbf0543_0
d6516a6656a7        k8s.gcr.io/pause:3.1   "/pause"                 24 minutes ago      Up 24 minutes                           k8s_POD_kube-controller-manager-ubuntu_kube-system_fe38083b94da6f6c5a89788091e3bcb6_0
8dab4c0348a9        k8s.gcr.io/pause:3.1   "/pause"                 24 minutes ago      Up 24 minutes                           k8s_POD_kube-apiserver-ubuntu_kube-system_84183f750feaa89bfaa9d456805fdc7a_0
b561f8c07ff7        k8s.gcr.io/pause:3.1   "/pause"                 24 minutes ago      Up 24 minutes                           k8s_POD_etcd-ubuntu_kube-system_7db86297afa09dfaa5049a791ed76555_0

Il ne semble pas y avoir de mappage de port pour 8080 - ne devrait-il pas y en avoir un ?

Salut @telmich ,

Je ne connais pas grand-chose à KubeADM, mais ce que je sais, c'est qu'IPv6 sur Kubernetes fonctionne très bien.

Comme je vois votre commande, je vais vous suggérer d'utiliser des crochets autour de vos adresses v6 comme [2a0a:e5...]

Salut @valentin2105 !

C'est formidable d'entendre qu'IPv6 devrait fonctionner, mais comment amorcer un cluster kubernetes sans kubeadm ?

Syntaxe Re [] : elle est généralement utilisée pour une seule adresse IPv6, pas pour les plages et kubeadm échoue immédiatement lors de son utilisation :

root<strong i="9">@k8s1</strong>:~# kubeadm init --pod-network-cidr '[2a0a:e5c0:102:3::/64]' --service-cidr '[2a0a:e5c0:102:6::/64]'
[serviceSubnet: Invalid value: "[2a0a:e5c0:102:6::/64]": couldn't parse subnet, podSubnet: Invalid value: "[2a0a:e5c0:102:3::/64]": couldn't parse subnet, KubeProxyConfiguration.ClusterCIDR: Invalid value: "[2a0a:e5c0:102:3::/64]": must be a valid CIDR block (e.g. 10.100.0.0/16)]
root<strong i="10">@k8s1</strong>:~# 

J'ai pris le temps d'écrire mes conclusions jusqu'à présent sur https://redmine.ungleich.ch/issues/6255 et actuellement, je prétends qu'il n'y a aucun moyen de configurer un cluster IPv6 uniquement à l'aide de kubeadm pour le moment.

Étant donné que je suis un débutant k8s, je me demande 2 choses :

• Est-ce que je me trompe sur ma demande?
• Si j'ai raison, comment puis-je néanmoins configurer un cluster kubernetes en mode IPv6 uniquement ?

Pour la dernière question : j'ai déjà jeté un œil aux différentes phases de kubeadm et j'ai essayé de répliquer l'init en procédant phase par phase, mais ce qui n'est pas clair pour moi, quand/comment modifier les options pour etcd, apiserver, contrôleur pour que je puisse le contrôler plus finement?

Vous devriez déboguer quel composant plante pendant que vous le lancez avec kubeadm, c'est peut-être à propos de CNI ? Je ne sais pas si le pont hôte-local prend en charge IPv6 dans cni.

Si vous voulez essayer de configurer la v6 uniquement et peut-être comparer avec votre configuration kubeadm, consultez ma recette Saltstack qui fonctionne en IPv6 car je l'utilise dans quelques clusters v6 uniquement.
https://github.com/valentin2105/Kubernetes-Saltstack

@danehans 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 Aucun travail IPv6 n'est prévu pour la 1.14.

Bonjour @danehans , je suis le Enhancement Lead 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. Toutes les améliorations nécessitent un KEP avant d'être également promues.

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.

@thockin @BenTheElder Je pense qu'il peut être possible de graduer les clusters ipv6 uniquement en version bêta dans 1.15.
Si nous fusionnons ceci https://github.com/kubernetes-sigs/kind/pull/348 je peux travailler sur les tests défaillants pendant ce cycle https://github.com/kubernetes/kubernetes/issues/70248 et ajouter un travail au CI
Qu'en penses-tu?

@kacole2 Malheureusement, je ne travaille plus sur IPv6.

Est-ce que quelqu'un travaille sur le support IPv6 natif (non dual stack) dans k8s ?

@telmich Cela devrait être possible aujourd'hui. Jetez un œil à https://github.com/leblancd/kube-v6 pour une bonne présentation de l'état actuel.

Salut @danehans - Je suis une ombre d'améliorations pour la 1.16.

Cette fonctionnalité va-t-elle passer les étapes alpha/beta/stable dans la version 1.16 ? Veuillez me le faire savoir afin qu'il puisse être ajouté à la feuille de calcul de suivi 1.16 .

Une fois le développement commencé ou s'il l'a déjà fait, veuillez répertorier tous les PR k/k pertinents dans ce numéro afin qu'ils puissent être suivis correctement.

J'ai remarqué qu'il n'y a pas de KEP lié dans la description du problème ; pour rappel, chaque amélioration nécessite un KEP dans un état implémentable avec des critères d'obtention du diplôme expliquant les exigences de chaque étape alpha/bêta/stable.

Pour rappel, les dates d'étape 1.16 sont : Enhancement Freeze 7/30 et Code Freeze 8/29.

Merci!

@mariantalla Je ne travaille plus sur la fonctionnalité. Vous voudrez peut-être demander à sig network de voir si quelqu'un d'autre envisage de s'occuper de l'obtention du diplôme.

@ lachie83 c'est quelque chose à évoquer avec SIG-Network dans vos réunions.

Ouais. Permettez-moi de mettre cela sur l'agenda du réseau SIG

Je soumettrai un PR avec un KEP pour passer d'IPv6 à Bêta au cours de ce cycle

Merci @aojea , j'ajouterai les deux (ceci et https://github.com/kubernetes/enhancements/issues/1138) comme suivi pour la v1.16, ciblant beta et At Risk tandis que KEP n'est pas fusionné.

Êtes-vous d' accord pour que désigne également comme propriétaire de ce problème et que

@mariantalla

Hé, @aojea, 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. 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!

Hé, @aojea, 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. 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!

@neolit123 @timothysc Je pense que je peux ajouter une section aux docs kubeadm https://github.com/kubernetes/website/tree/master/content/en/docs/setup/production-environment/tools/kubeadm comme Configuring your Kubernetes cluster to use IPv6 , qu'en pensez-vous ? Est-ce que ça marche pour vous?

@aojea
dépend de ce que vous prévoyez d'ajouter à la doc?

ces sections mentionnent déjà que ipv6 est pris en charge par kubeadm :
https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#initializing -your-control-plane-node
https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod -network

/assign @aojea
/ unassign @danehans

Hé @aojea - juste un petit rappel que le gel des améliorations 🥶est demain. Cette amélioration est menacée pour le moment, car son KEP n'est pas encore fusionné.

Je crois que le KEP est suivi dans #1138 . Pouvons-nous regrouper cela dans ce problème ?

ces sections mentionnent déjà que ipv6 est pris en charge par kubeadm :
https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#initializing -your-control-plane-node
https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod -network

@simplytunde semble que la documentation

semble que la documentation destinée à l'utilisateur est déjà couverte

Je ne dirais pas que kubeadm est la seule documentation destinée aux utilisateurs pour la prise en charge d'IPv6, mais je m'en remettrai à SIG Network et aux mainteneurs de cette fonctionnalité.

@aojea @danehans @lachie83
Enhancement Freeze est passé pour la 1.16. Le KEP à #1139 n'a jamais été fusionné et maintenant il est supprimé du jalon 1.16. Si cela souhaite être rajouté, veuillez déposer une exception et cela nécessitera l'approbation du responsable de la publication .

/jalon clair

@kacole2 merci pour le suivi, ciblons alors 1,17.

Salut @aojea -- Les améliorations 1.17 mènent ici. Je voulais vérifier et voir si vous pensez que cette amélioration passera à alpha/beta/stable en 1.17 ?

Le calendrier de diffusion actuel est le suivant :

Lundi 23 septembre - Début du cycle de publication
Mardi 15 octobre, EOD PST - Gel des améliorations
Jeudi 14 novembre, EOD PST - Gel du code
Mardi 19 novembre - Les documents doivent être complétés et révisés
Lundi 9 décembre - Sortie de Kubernetes 1.17.0

Si vous le faites, 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. ??

Merci!

@mrbobbytables selon le KEP il ne manque qu'une chose c'est le travail CI dans un fournisseur de cloud

IPv6 Passage à la version bêta

Critères d'obtention du diplôme

• [x] Il a la parité des fonctionnalités IPv4

• [x] Il a CI utilisant un environnement de test kubernetes

  • Type de travail de blocage de version IPv6
  • Type de travail de pré-soumission IPv6 (informatif)

• [ ] Il a CI utilisant au moins un fournisseur de cloud

• [x] Il a réussi tous les tests de conformité e2e
• [x] Il est documenté

Impressionnant. L'ajoutera pour être suivi en tant que diplômé en version bêta 👍

Bonjour @aojea, je suis l'une des ombres des docs v1.17.
Cette amélioration pour (ou le travail prévu pour la v1.17) nécessite-t-elle de nouveaux documents (ou des modifications aux documents existants) ? Sinon, pouvez-vous s'il vous plaît mettre à jour la feuille de suivi des améliorations 1.17 (ou faites-le moi savoir et je le ferai)

Si c'est le cas, juste un rappel amical, nous recherchons un PR contre k/website (branche dev-1.17) dû d'ici le vendredi 8 novembre, il peut simplement s'agir d'un PR d'espace réservé pour le moment. Faites moi savoir si vous avez des questions!

@irvifa
Cela vous dérange-t-il de mettre à jour la feuille de suivi des améliorations ?
Nous n'aurons pas besoin de plus de documents comme expliqué ici https://github.com/kubernetes/enhancements/issues/508#issuecomment -516064858

D'accord, merci pour la confirmation @aojea . J'ai mis à jour la feuille de suivi comme demandé.

Salut @aojea , les améliorations 1.17 mènent ici 👋 Il ne semble pas qu'il y ait de PR k/k ou autres qui soient en suspens, mais comment se présentent les choses concernant la dernière tâche ? "_Il a CI utilisant au moins un fournisseur de cloud_"

Salut @aojea , 1.17 Les améliorations mènent ici Il ne semble pas qu'il y ait de PR k/k ou autres qui soient exceptionnels, mais comment se présentent les choses concernant la dernière tâche ? "_Il a CI utilisant au moins un fournisseur de cloud_"

c'est WIP https://github.com/kubernetes-sigs/cluster-api-provider-aws/pull/1322 , mais je ne peux pas garantir que je peux le faire :man_shruging:

Salut @aojea. Le gel du code est à 17h PT aujourd'hui pour le cycle de version 1.17.
Pensez-vous que https://github.com/kubernetes-sigs/cluster-api-provider-aws/pull/1322 sera fusionné d'ici là ? ??

Je sais que cela ne fait pas partie de k/k et n'est pas exactement soumis au gel, mais idéalement, nous aurions tout en place d'ici là.

ciblons 1.18 @mrbobbytables , cela a beaucoup d'inconnues et je ne peux pas consacrer assez de temps :man_shrugging:

Ça ira! Merci pour la réponse rapide
/jalon v1.18

Salut @aojea -- 1.18 Améliorations ombre ici. Je voulais vérifier et voir si vous pensez que cette amélioration passera à [alpha|beta|stable] en 1.18 ?
Le calendrier de diffusion actuel est le suivant :
Lundi 6 janvier - Début du cycle de publication
Mardi 28 janvier EOD PST - Gel des améliorations
Jeudi 5 mars, EOD PST - Gel du code
Lundi 16 mars - Les documents doivent être complétés et révisés
Mardi 24 mars - Sortie de Kubernetes 1.18.0
Pour être incluse dans la version, cette amélioration doit avoir un KEP fusionné dans le statut implementable . Le KEP doit également avoir des critères d'obtention du diplôme et un plan de test définis.
Si vous souhaitez inclure cette amélioration, 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. ??
Nous suivrons les améliorations ici : http://bit.ly/k8s-1-18-enhancements
Merci!

salut @kikisdeliveryservice
Le KEP a été fusionné https://github.com/kubernetes/enhancements/pull/1139 et est de implementable

Il ne manque qu'un élément :

Il a CI utilisant au moins un fournisseur de cloud

et nous pourrons faire passer IPv6 en version bêta en 1.18

cc: @lachie83 @aramase

merci @aojea !

Salut @aojea -

Seth ici, Docs shadow sur l'équipe de publication 1.18.

Ce travail d'amélioration prévu pour la version 1.18 nécessite-t-il de nouveaux documents ou des modifications aux documents existants ?

Sinon, pouvez-vous s'il vous plaît mettre à jour la feuille de suivi des améliorations 1.18 (ou faites-le moi savoir et je le ferai)

Si des mises à jour de la documentation sont nécessaires, rappelez que les PR d'espace réservé contre k/website (branche dev-1.18) sont dus d'ici le vendredi 28 février.

Faites moi savoir si vous avez des questions!

@sethmccombs une question, un article de blog sur la fonctionnalité compte-t-il comme une mise à jour de la documentation ?

Salut @aojea !

Pour rappel, le Code Freeze est le jeudi 5 mars. Pouvez-vous s'il vous plaît lier tous les PR k/k ou tout autre PR qui devrait être suivi pour cette amélioration ?

Merci!
L'équipe des améliorations 1.18

@aramase avez-vous un lien pour suivre le travail IPv6 sur Azure, afin que l'équipe d'amélioration puisse suivre la fonctionnalité ?

@aojea - Le @karenhchu en tant que responsable des communications)

hey @aojea @aramase pourriez-vous

@jeremyrickard J'ai créé l'espace réservé PR dans test-infra pour le travail - https://github.com/kubernetes/test-infra/pull/16461

Autres PR qui devront être fusionnés avant -
https://github.com/kubernetes/kubernetes/pull/88448
https://github.com/Azure/aks-engine/pull/2781

Je termine les tests et supprimerai ensuite les WIP.

Salut @aojea @aramase
Comme la date limite des relations publiques pour les espaces réservés aux documents est demain. Si cette amélioration a besoin de docs. Veuillez créer un PR d'espace réservé contre la branche dev-1.18 dès que possible.

Merci!

/jalon clair

Salut, @aojea @aramase car il n'y a pas de PR d'espace réservé aux documents pour cette amélioration et n'a reçu aucune mise à jour sur le front des documents. nous avons dépassé la date limite pour les relations publiques d'espace réservé aux documents. Nous supprimons donc cette amélioration de la version 1.18. Si vous souhaitez demander une exception. Veuillez vous référer à https://github.com/kubernetes/sig-release/blob/master/releases/EXCEPTIONS.md

Merci!

Désolé, aucune mise à jour de la documentation n'est nécessaire :smile:

/jalon v1.18

Quelle fonctionnalité IPv6 a atterri dans Kubernetes 1.18 ? S'agit-il d'une double pile ou d'IPv6 uniquement en version bêta ?
Je suis confus car rien n'a changé dans la doc.

Quelle fonctionnalité IPv6 a atterri dans Kubernetes 1.18 ? S'agit-il d'une double pile ou d'IPv6 uniquement en version bêta ?
Je suis confus car rien n'a changé dans la doc.

Ce problème ne suit que l'ipv6, passé à la version bêta en 1.18

La double pile est alpha et est suivie dans d'autres problèmes/KEP

/jalon clair

(suppression de ce problème d'amélioration du jalon v1.18 lorsque le jalon est terminé)

Salut @aojea @danehans ,

1.19 Les améliorations sont ombrées ici. Je voulais vérifier et voir si vous pensez que cette amélioration sera diplômée en 1.19 ?

Pour avoir cette partie de la version :

The KEP PR must be merged in an implementable state
The KEP must have test plans
The KEP must have graduation criteria.

Le calendrier de diffusion actuel est le suivant :

Monday, April 13: Week 1 - Release cycle begins
Tuesday, May 19: Week 6 - Enhancements Freeze
Thursday, June 25: Week 11 - Code Freeze
Thursday, July 9: Week 14 - Docs must be completed and reviewed
Tuesday, August 4: Week 17 - Kubernetes v1.19.0 released

Faites-le moi savoir et je l'ajouterai à la feuille de suivi 1.19 (http://bit.ly/k8s-1-19-enhancements). 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. ??

Merci!

Merci @kikisdeliveryservice , mais je pense que nous devrions maintenant nous concentrer sur la double pile.
Aucun changement ici pendant cette version

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é

Salut @aojea @danehans

Les améliorations mènent ici. Avez-vous l'intention d'obtenir ce diplôme en 1.20 ?

Merci,
Kirsten

Salut @aojea @danehans

Les améliorations mènent ici. Avez-vous l'intention d'obtenir ce diplôme en 1.20 ?

non :sourire:

Merci pour la mise à jour!

Existe-t-il une documentation sur la façon de vérifier les opérations IPv6 uniquement ? google ne m'a conduit qu'à ipv4 ou ipv6 dualstack.

Existe-t-il une documentation sur la façon de vérifier les opérations IPv6 uniquement ? google ne m'a conduit qu'à ipv4 ou ipv6 dualstack.

qu'entends-tu par "vérifier" ?

L'installation pour IPv6 uniquement est la même que pour IPv4, il vous suffit d'utiliser des adresses et des sous-réseaux IPv6 dans votre configuration, aucune modification supplémentaire n'est nécessaire.
https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#initializing -your-control-plane-node

Peut confirmer. J'exécute 1.17.x en mode IPv6 uniquement. Suivez simplement le guide IPv4 et utilisez les adresses IPv6. C'est en gros ça.