Référence croisée avec kubernetes / kubernetes : numéro 62822

Merci pour la mise à jour!

/assign @leblancd
/ fonction gentille
/sig réseau
/jalon 1.11

@leblancd un document de conception disponible ?

/cc @thockin @dcbw @luxas @kubernetes/sig-network-feature-requests

@idvoretskyi - Pas encore de document de conception, mais nous commencerons à collaborer sur un sous peu.

Cela signifie-t-il que Kubernetes Ingress prendra en charge Dual-Stack ?
Cela signifie-t-il que CNI ( Calico) aurait besoin d'exécuter la double pile ( les deux démons BIRD et BIRD6 par exemple) ?

@ sb1975 - En ce qui concerne la prise en charge des entrées à double pile, c'est quelque chose que nous devrons

• La prise en charge des entrées à double pile dépendra principalement du contrôleur d'entrée que vous utilisez (s'il est pris en charge et comment il est implémenté). Les contrôleurs d'entrée existants auront probablement besoin de modifications pour prendre en charge la double pile.
• Je m'attends à ce que la configuration d' entrée pour un contrôleur d'entrée typique ne change pas (la configuration peut, par exemple, toujours mapper une adresse L7 à un nom de service / port de service, sans mention de la famille V4/V6)
• Dans le cas où un service a des pods de point de terminaison à double pile, le ou les contrôleurs d'entrée peuvent avoir besoin de modifications pour mapper les paquets d'entrée en fonction de la famille de paquets, c'est-à-dire mapper les paquets d'entrée IPv4 à un point de terminaison IPv4 et mapper les paquets d'entrée IPv6 à un point de terminaison IPv6. Aux fins de la pondération de l'équilibrage de charge, un point de terminaison à double pile doit être considéré comme une cible de point de terminaison unique.

- Nous pourrions envisager la prise en charge FUTURE d'une carte de contrôleur d'entrée sur les familles V4/V6 (mapper les paquets IPv4 d'entrée à un backend IPv6, et vice versa), mais notre développement initial sera pour une double pile stricte (c'est-à-dire séparée, indépendante piles).

Concernant Calico et autres plugins CNI :

• Les plug-ins CNI NE DOIVENT PAS s'exécuter en mode double pile si un scénario de cluster ne nécessite pas de double pile, ils devraient toujours pouvoir exécuter IPv4 uniquement ou IPv6 uniquement (si le plug-in le prend en charge).
• La prise en charge de la double pile nécessitera probablement des modifications dans les divers plugins CNI, mais ce travail est considéré comme hors de la portée de ce problème Kubernetes (nous nous concentrons sur le fait que Kubernetes fonctionne pour tout plugin arbitraire à double pile, en utilisant probablement le plugin bridge comme une référence), et les travaux du CNI se feront séparément au cas par cas.
• Pour Calico en particulier, je ne suis pas un expert mais je pense qu'un seul démon BIRD peut être configuré pour gérer à la fois les routes IPv4 et IPv6 (recherchez "template bgp" ici : http://bird.network.cz/?get_doc&v= 20&f=oiseau-3.html#ss3.1). Cela dit, bien que Calico prenne déjà en charge les adresses à double pile au niveau du pod, des modifications peuvent être nécessaires pour que le routage BGP fonctionne pour les deux familles.

@leblancd : Voici donc le scénario :

1. Disons que nous utiliserons le contrôleur d'entrée NGINX
2. J'expose mes services via Ingress.
3. J'exécute mes pods configurés sur double pile
4. J'essaie d'atteindre le service à distance en utilisant les enregistrements DNS A et AAAA.
   J'espère que tout ça
5. En résumé : je souhaite me connecter aux interfaces de pod à l'aide d'adresses IPv4 ou IPv6, telles que résolues par mes propres requêtes pour les enregistrements A et/ou AAAA pour le nom du service de pod.
   Puis-je m'impliquer dans cette initiative de test, de documentation, d'architecture : mais j'ai besoin de conseils.
   Comment puis-je être au courant de l'avancement de ce s'il vous plaît.

@ sb1975 - Bonne question re. le contrôleur d'entrée NGINX avec double pile. Je ne suis pas un expert du contrôleur d'entrée NGINX (peut-être que quelqu'un de plus familier peut intervenir), mais voici comment je verrais le flux de travail :

• Lorsque vous essayez d'atteindre les services Kube depuis l'extérieur, votre contrôleur DNS doit résoudre le service avec les enregistrements DNS A et AAAA pour le contrôleur d'entrée. Ce serait le choix de votre client/application d'utiliser l'enregistrement A par rapport à l'enregistrement AAAA pour atteindre le contrôleur d'entrée. L'accès externe au contrôleur d'entrée serait donc à double pile.
• Au niveau du contrôleur d'entrée NGINX, NGINX examinerait ensuite l'URL L7 (indépendamment de la demande dans un paquet IPv4 ou IPv6) et équilibrerait la charge vers les points de terminaison en amont. Si l'équilibreur de charge du contrôleur d'entrée est configuré avec ipv6=on (qui est la valeur par défaut, voir https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/#configuring-http-load -balancing-using-dns) et que le ou les points de terminaison de service sont à double pile, la configuration en amont doit avoir des entrées IPv4 et IPv6 pour chaque point de terminaison à double pile. Tel qu'il a été conçu, l'équilibreur de charge NGINX traite l'entrée IPv4 et l'entrée IPv6 d'un point de terminaison comme des serveurs distincts . (Voir la ligne dans le document mentionné ci-dessus "Si un nom de domaine se résout en plusieurs adresses IP, les adresses sont enregistrées dans la configuration en amont et équilibrées en charge.") Cela peut être considéré comme une bonne ou une mauvaise nouvelle. La bonne nouvelle est que l'équilibrage de charge sera effectué sur les points de terminaison IPv4 et IPv6 (vous donnant une certaine redondance), où, par exemple, une requête IPv4 entrante pourrait être mappée sur un point de terminaison IPv4 ou IPv6. Mais la mauvaise nouvelle potentielle concerne la granularité de l'équilibrage de charge : une connexion à un point de terminaison IPv4 et une connexion au point de terminaison IPv6 correspondant seront traitées (pour des considérations d'équilibrage de charge) comme 2 charges vers des points de terminaison séparés, plutôt que 2 charges distinctes vers le même point de terminaison . Si cette granularité d'équilibrage de charge est un problème, alors quelqu'un pourrait désactiver l'équilibrage de charge vers IPv6 (ou vers IPv4, s'il existe un bouton de configuration pour cela ?), afin que l'équilibrage de charge se fasse sur les points de terminaison IPv4 uniquement. OU , peut-être que l'équilibreur de charge NGINX peut être modifié pour traiter une connexion à une adresse IPv4 et une connexion à son adresse IPv6 correspondante comme 2 charges vers le même point de terminaison.

Quant à aider et à s'impliquer, ce serait grandement apprécié! Nous sommes sur le point de commencer à travailler sérieusement sur la double pile (cela a été un peu retardé par le travail visant à faire fonctionner CI pour IPv6 uniquement). J'espère sortir bientôt un aperçu d'une spécification (Google Doc ou KEPs WIP doc) et je chercherais de l'aide pour réviser et peut-être écrire certaines sections. Nous aurons également CERTAINEMENT besoin d'aide pour la documentation officielle (au-delà des spécifications de conception), et pour définir et mettre en œuvre des tests E2E à double pile. Certains des domaines sur lesquels je suis encore un peu vague pour la conception incluent:

• Comment les sondes de santé/vie/état de préparation sont-elles affectées ou gérées avec la double pile
• Y aura-t-il un impact sur les politiques de réseau ?
• Des soucis d'équilibrage de charge ?
• Des soucis de plug-in de fournisseur de cloud ?
• Problèmes d'entrée L3/L4 ?
  Si vous avez pensé à l'une d'entre elles, peut-être pourriez-vous nous aider avec ces sections ?

Nous envisageons également une approche intermédiaire de "double pile à la périphérie" (avec IPv6 uniquement à l'intérieur du cluster), où l'accès de l'extérieur du cluster aux services K8s serait à double pile, mais cela serait mappé (par exemple via NGINX contrôleur d'entrée) aux points de terminaison IPv6 uniquement à l'intérieur du cluster (ou utilisez NAT46 sans état). Les pods et les services du cluster devraient être tous IPv6, mais le gros avantage serait que l'accès externe à double pile serait disponible beaucoup plus rapidement du point de vue du temps de mise sur le marché.

/jalon 1.12

@leblancd / @caseydavenport - Je remarque beaucoup de discussions ici et un changement important.
Cela devrait-il être retiré du jalon 1.11 ?

@justaugustus - Oui, cela devrait être déplacé vers 1.12. Dois-je supprimer une ligne dans la feuille de calcul de version, ou dois-je faire quelque chose pour que cela soit modifié ?

@leblancd je l'ai couvert. Merci d'avoir suivi ! :)

@leblancd @kubernetes/sig-network-feature-requests --

Cette fonctionnalité a été supprimée du jalon précédent, nous aimerions donc vérifier et voir s'il existe 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 :
• Réviseur(s) - (pour LGTM) recommande d'avoir 2+ réviseurs (au moins un du fichier PROPRIÉTAIRES de la zone de code) acceptés pour réviser. 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
  
  

Veuillez noter que le gel des fonctionnalités est 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é ouvert PRs) : 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 !

/cc @justaugustus @kacole2 @robertsandoval @rajendar38

@leblancd --
Le gel des fonctionnalités est aujourd'hui. Envisagez-vous de passer à la version bêta dans Kubernetes 1.12 ?
Si tel est le cas, pouvez-vous vous assurer que tout est à jour, afin que je puisse l'inclure dans la feuille de calcul de suivi des fonctionnalités 1.12 ?

Salut @justaugustus - Le statut bêta devra se glisser dans Kubernetes 1.13. Nous faisons des progrès (quoique lents) sur la conception KEP (https://github.com/kubernetes/community/pull/2254), et nous nous rapprochons du réengagement avec le PR de test CI, mais le Kubernetes 1.12 cible était un peu trop optimiste.

Je mettrai à jour la description/le résumé ci-dessus avec les informations que vous avez demandées précédemment. Merci pour votre patience.

/supprimer l'alpha de l'étape
/étape bêta

Pas de soucis, @leblancd. Merci pour la mise à jour!

Salut, @justaugustus @leblancd

Je viens de lire la mise à jour selon laquelle la version bêta est déplacée vers la 1.13 pour la double pile. Quelle est la date de sortie prévue de la 1.13 ? Nous recherchons actuellement un support dual stack. C'est une décision irrésistible pour notre produit de passer aux conteneurs.

@navjotsingh83 - Je ne pense pas que la date de sortie de Kubernetes 1.13 ait été solidifiée. Je ne vois pas la 1.13 répertoriée dans la documentation des versions de Kubernetes .

@navjotsingh83 @leblancd 1.13 Le calendrier de sortie est publié . C'est un cycle de publication court avec le gel du code le 15 novembre. Pensez-vous qu'il est assez de temps pour passer cette fonctionnalité à la version bêta. Pouvez-vous s'il vous plaît mettre à jour ce problème avec votre niveau de confiance, ce qui est en attente en termes de code, de test et d'achèvement de la documentation ?

Selon la discussion lors de la réunion du réseau SIG, bien qu'un travail considérable soit effectué sur cette fonctionnalité dans la 1.13, il ne devrait pas passer en version bêta dans la 1.13. suppression d'un jalon en conséquence.

/jalon clair

@kacole2 pour supprimer cela de la feuille de calcul des améliorations 1.13

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é

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

@leblancd Je voulais donner suite à votre commentaire précédent concernant la création d'une délimitation à la périphérie du cluster pour IPv4/IPv6 :

« Nous envisageons également une approche intermédiaire « double pile à la périphérie » (avec IPv6 uniquement à l'intérieur du cluster), où l'accès de l'extérieur du cluster aux services K8s serait à double pile, mais cela serait mappé (par exemple via contrôleur d'entrée NGINX) aux points de terminaison IPv6 uniquement à l'intérieur du cluster (ou utilisez NAT46 sans état). Les pods et les services du cluster devraient être tous IPv6, mais le gros avantage serait que l'accès externe à double pile serait disponible beaucoup plus rapidement du point de vue du temps de mise sur le marché.

Ce cas d'utilisation serait bon pour un projet en cours, alors je voulais voir vos réflexions sur le calendrier, voir si quelque chose moi-même ou quelqu'un de notre groupe pourrait contribuer à aider avec ce délai de mise sur le marché plus rapide.

@KevinAtDesignworx Si l' curl -v 93.184.216.34 -H "Host: example.com" dire

eh bien, il y a 464XLAT donc ipv6 uniquement à l'intérieur du conteneur serait faisable.

@KevinAtDesignworx - Si l'utilisation d'un contrôleur d'entrée fonctionnait dans votre scénario, il est possible de configurer un contrôleur d'entrée NGINX pour un fonctionnement à double pile de l'extérieur (proxy à une famille unique à l'intérieur du cluster): https://github.com/leblancd/ kube-v6#installer -un-contrôleur-d'entrée-dual-stack-sur-un-ipv6-only-kubernetes-cluster

Les contrôleurs d'entrée devraient s'exécuter sur le réseau hôte sur chaque nœud, de sorte que les contrôleurs devraient être configurés en tant que démon (un contrôleur d'entrée sur chaque nœud). Cela suppose :

• Vos nœuds sont à double pile (par opposition aux pods et aux services unifamiliaux)
• Votre /etc/hosts sur chaque nœud a des entrées IPv6 et uniquement des entrées IPv6 (pas d'adresses IPv4) pour le nom d'hôte de ce nœud.

Cela s'ajouterait à un NAT64/DNS64 pour les connexions des clients V6 à l'intérieur du cluster vers des serveurs externes IPv4 uniquement.

Stateless NAT46 est également une option, mais je n'ai pas essayé cela, donc je n'ai pas de guides de configuration pour cela.

@leblancd des travaux prévus ici pour 1h15 ? On dirait qu'un KEP n'a pas encore été accepté à ce stade non plus. Merci!

@leblancd Je voulais donner suite à votre commentaire précédent concernant la création d'une délimitation à la périphérie du cluster pour IPv4/IPv6 :

« Nous envisageons également une approche intermédiaire « double pile à la périphérie » (avec IPv6 uniquement à l'intérieur du cluster), où l'accès de l'extérieur du cluster aux services K8s serait à double pile, mais cela serait mappé (par exemple via contrôleur d'entrée NGINX) aux points de terminaison IPv6 uniquement à l'intérieur du cluster (ou utilisez NAT46 sans état). Les pods et les services du cluster devraient être tous IPv6, mais le gros avantage serait que l'accès externe à double pile serait disponible beaucoup plus rapidement du point de vue du temps de mise sur le marché.

Ce cas d'utilisation serait bon pour un projet en cours, alors je voulais voir vos réflexions sur le calendrier, voir si quelque chose moi-même ou quelqu'un de notre groupe pourrait contribuer à aider avec ce délai de mise sur le marché plus rapide.

Depuis l'intérieur d'un conteneur (qui n'est qu'IPv6), envoie une requête curl (c'est-à-dire curl -v 93.184.216.34 -H "Host: example.com") vers l'extérieur du cluster. Je pense que cela donnera une erreur de destination inconnue ou de destination inaccessible, à moins qu'il n'existe une route ipv4 sur l'hôte où le conteneur existe.

@GeorgeGuo2018 si k8s implémentait DNS64/NAT64, cela fonctionnerait. cela dépend fortement de la mesure dans laquelle les k8 iront dans les solutions 464xlat/plat et de ce qui devrait être géré au niveau des routeurs de périphérie, etc.

en fait, je pense que ce serait possible en utilisant un DaemonSet/Deployment qui utilise la mise en réseau de l'hôte et Tayga à l'intérieur de l'espace de noms kube-system afin que le DNS64 interne utilise tayga pour sortir du réseau.

Cela ressemble à une solution pour moi.

Nous gérons un réseau IPv6 uniquement en interne et NAT64/DNS64 fonctionne assez bien pour nous. Pour certains éléments hérités où il n'y avait pas du tout de support IPv6, nous avons fini par utiliser clatd directement là où c'était nécessaire. (Dans notre cas directement sur une VM.)

@ kacole2 - Je voudrais que cela soit suivi pour 1,15. Je travaille pour fusionner les relations publiques suivantes - https://github.com/kubernetes/enhancements/pull/808

Spécifiquement pour la version 1.15, nous ajouterions la prise en charge des éléments suivants :

• Modifications de type API
  
  
  
  • Types Kubernetes
  
  
  • Types d'IRC
  
  
• mise en réseau de pods à double pile (pod multi-IP)
• prise en charge multifamiliale de kubenet

cc @caseydavenport pour le suivi des jalons ^

@kacole2 le KEP est maintenant fusionné. Faites-moi savoir s'il y a autre chose dont nous avons besoin pour que cela soit suivi dans 1.15

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

@kacole2 le KEP est maintenant fusionné. Faites-moi savoir s'il y a autre chose dont nous avons besoin pour que cela soit suivi dans 1.15

@ lachie83 Salut, Lachie, vouliez-vous dire que la prise en charge de la double pile IPv4/IPv6 de ce KEP était terminée ?

@kacole2 le KEP est maintenant fusionné. Faites-moi savoir s'il y a autre chose dont nous avons besoin pour que cela soit suivi dans 1.15

En fait, je veux savoir si la prise en charge de la double pile sera sûrement ajoutée dans k8s 1.15.

@leblancd L'espace réservé PR contre k8s.io dev-1.15 est dû jeudi 30 mai.

@leblancd L'espace réservé PR contre k8s.io dev-1.15 est dû jeudi 30 mai.

Puis-je considérer que la prise en charge de la double pile sera disponible dans la version 1.15 ?

@GeorgeGuo2018 Il figure toujours sur la feuille d'amélioration pour la version 1.15, mais seul le responsable de l'amélioration @kacole2 peut vous fournir de meilleurs détails à ce sujet.

Salut @lachie83 @leblancd. Code Freeze est le jeudi 30 mai 2019 @ EOD PST . Toutes les améliorations apportées à la version doivent être complètes, y compris les tests , et les documents PR doivent être ouverts.

Veuillez répertorier tous les PR k/k actuels afin qu'ils puissent être suivis jusqu'au gel. Si les PR ne sont pas fusionnés par gel, cette fonctionnalité glissera pour le cycle de version 1.15. Seuls les problèmes de blocage de version et les PR seront autorisés dans le jalon.

Je vois que kubernetes/kubernetes#62822 dans le message d'origine est toujours ouvert. Y a-t-il d'autres PR que nous prévoyons de fusionner également ?

Si vous savez que cela va glisser, veuillez répondre et nous le faire savoir. Merci!

@simplytunde - Appréciez le heads-up. Je travaille sur la préparation des docs PR cette semaine.

@GeorgeGuo2018 - Ce sera un KEP à plusieurs versions. Nous prévoyons d'atterrir la phase 1 en 1.15. Veuillez consulter le plan de mise en œuvre dans le KEP pour plus de détails - https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6-dual-stack.md#implementation -plan.

@simplytunde - J'ai créé le premier espace réservé docs PR ici avec un WIP https://github.com/kubernetes/website/pull/14600. Je prévois de terminer et de le préparer pour examen au cours des prochains jours.

@kacole2 Merci pour le ping. J'ai mis à jour la feuille de calcul des améliorations 1.15 avec le PR k/k que nous suivons (https://github.com/kubernetes/kubernetes/pull/73977) ainsi que le projet de document PR (https://github.com/ kubernetes/website/pull/14600). Nous sommes toujours sur la bonne voie pour fusionner ce PR avant le gel du code. LMK s'il me manque autre chose

@kacole2 après discussion avec @claurence et l'équipe de publication, nous avons décidé de supprimer cela du jalon 1.15. Veuillez le supprimer et mettre à jour la feuille de calcul le cas échéant. Merci pour toute votre aide jusqu'à présent.

/jalon clair

@simplytunde J'ai également commenté les docs PR. Pouvez-vous s'il vous plaît vous assurer que cela est également supprimé du jalon 1.15 ?

Salut @lachie83 @leblancd , je suis l'Ombre d'Amélioration 1.16. Cette fonctionnalité va-t-elle passer les étapes alpha/bêta/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 .

Les dates clés sont Enhancement Freeze 7/30 et Code Freeze 8/29.

Merci.

https://github.com/kubernetes/dns/issues/315 couvre l'ajout d'IPv6/AAAA à la spécification de découverte de service DNS .

@ lachie83 @leblancd une idée si cela sera diplômé en 1.16 pour le suivre?

@evillgenius75 @kacole2 Cela doit être suivi dans 1.16. Cette fonctionnalité sera à l'état alpha. Nous mettrons en œuvre la phase 1 et la phase 2 telle que définie dans le KEP est 1.16

Suivi KEP

• https://github.com/kubernetes/enhancements/pull/808

K/k PRs fusionnés (actuellement dans le master sera en 1.16)

• [FUSIONNÉ] Phase 1 - https://github.com/kubernetes/kubernetes/pull/73977
• [FUSIONNÉ] Tests e2e de phase 1 - https://github.com/kubernetes/kubernetes/pull/78801
• [MERGED] Phase 1 de nettoyage des tests e2e - https://github.com/kubernetes/kubernetes/pull/80001
• Services/points de terminaison de la phase 2 - https://github.com/kubernetes/kubernetes/pull/79386
• Phase 2 kube-proxy - https://github.com/kubernetes/kubernetes/pull/79576

PR associés

• Prise en charge d'IPv6 https://github.com/kubernetes-incubator/ip-masq-agent/pull/45
• Documents de la phase 1 - seront rouverts une fois que nous aurons finalisé les exemples d'outillage - https://github.com/kubernetes/website/pull/14600
• [MERGED] nettoyage - node dropDisabledFields - https://github.com/kubernetes/kubernetes/pull/79741
• Prise en charge de plusieurs tailles de masque pour les cidrs de cluster - https://github.com/kubernetes/kubernetes/pull/79993
• E2e Prow Job pour dualstack https://github.com/kubernetes/test-infra/pull/12966

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

@simplytunde voici la docs PR - https://github.com/kubernetes/website/pull/16010

@ lachie83, le gel du code de rappel amical pour la 1.16 est le jeudi 29/08. (comme si vous ne le saviez pas). On dirait que ces PR sont toujours en suspens :
Services/points de terminaison de la phase 2 - kubernetes/kubernetes#79386
Phase 2 kube-proxy - kubernetes/kubernetes#79576

Associée:
Prise en charge de plusieurs tailles de masque pour les cidrs de cluster - kubernetes/kubernetes#79993
E2e Prow Job pour dualstack kubernetes/test-infra#12966

Salut @lachie83 @leblancd, il semble que https://github.com/kubernetes/kubernetes/pull/79576 et https://github.com/kubernetes/kubernetes/pull/79993 n'aient pas fusionné avant le gel du code et ce n'est pas le cas dans le bassin de fusion des marées . Cette fonctionnalité va être supprimée de la v1.16. Si vous souhaitez toujours que cela fasse partie de la version 1.16, veuillez déposer une exception

@kacole2 Toutes nos excuses pour les délais de réponse. Le principal PR était le suivi de https://github.com/kubernetes/kubernetes/pull/79386. Quant à kubernetes/kubernetes#79576, nous avons pris la décision de reporter cela à 1.17 et de nous concentrer plutôt sur https://github.com/kubernetes/kubernetes/pull/82091 (en accord avec sig-network) qui remplit les mêmes objectifs de phase2 que ont été présentés dans le KEP. L'autre PR connexe a été suivi dans cette version était https://github.com/kubernetes/kubernetes/pull/80485 qui est également fusionné. kubernetes/kubernetes#79993 a également été reporté à 1.17

Salut @lachie83 @leblancd -- 1.17 Les améliorations 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, veuillez énumérer tous les PR k/k pertinents dans ce numéro afin qu'ils puissent être suivis correctement. ??

Merci!

/jalon clair

Salut Bob. Merci d'avoir tendu la main. Je suis toujours en train de planifier la phase 3 de cette amélioration qui complétera l'amélioration jusqu'à son achèvement. Cette amélioration sera toujours en alpha à la fin de cette version, mais il y aura des travaux liés à la phase 3 qui atterriront en k/k dans le cadre de la 1.17.

Voici une liste de livrables de haut niveau pour 1.17 pour double pile. Je mettrai à jour cette liste tout au long de la sortie.

• Proxy double pile IPtables - https://github.com/kubernetes/kubernetes/pull/79576
• prise en charge api descendante pour Pod.Status.PodIPs - https://github.com/kubernetes/kubernetes/pull/83123
• e2e teste un plugin CNI
• Modifications du fichier d'hôte (l'adresse IPv6 pour le nom d'hôte doit être ajoutée /etc/hosts) - https://github.com/kubernetes/kubernetes/pull/83123
• Type double pile - https://github.com/kubernetes-sigs/kind/pull/692
• Mettre à jour la suite e2e - https://github.com/kubernetes/kubernetes/pull/80725
• Prise en charge des tranches de point de terminaison
• Prise en charge de la double pile pour Kubeadm - https://github.com/kubernetes/kubeadm/issues/1612

Très apprécié, merci gentiment @lachie83 ❤️ Je vais y aller et l'ajouter à la fiche de suivi.

/jalon v1.17

@mrbobbytables J'ai également ajouté un PR pour détailler les travaux énumérés ci-dessus dans le cadre de la phase 3 du KEP après avoir communiqué le plan via sig-network. Le KEP lui-même est toujours dans l'état implementable et ces changements documentent simplement le travail prévu dans le cadre de la 1.17 en particulier.

À un moment donné, je voudrais m'assurer que https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/ couvre IPv6 DNS. https://github.com/kubernetes/website/issues/15434 pistes qui changent ; en le mentionnant ici pour noter un renvoi.

KEP mis à jour pour ajouter des tests e2e de phase 2 - https://github.com/kubernetes/enhancements/pull/1311

Bonjour @lachie83, 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 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!

@lachie83

Étant donné que nous approchons de la date limite pour les relations publiques d'espace réservé Docs le 8 novembre. Veuillez essayer d'en obtenir un contre la branche k/website dev-1.17.

Salut @lachie83 , je sais que tu gardes un œil, mais je dois quand même entrer et le mentionner
Le gel du code approche à grands pas (14 novembre). Comment se présentent les choses ? Est-ce que tout est sur la bonne voie pour fusionner avant cette date ?

Merci!

Salut @mrbobbytables ! Merci pour le ping. Nous suivons les PR suivants pour atterrir en 1.17. Il peut y avoir un ou deux autres PR associés à ce changement. Ces modifications nécessiteront des documents. Je vais créer un espace réservé docs PR

• Prise en charge de Dualstack pour le mode kube-proxy iptables pr/82462
• API Dualstack vers le bas pr/82462
• ajouter la prise en charge des tranches de points de terminaison de metaproxier ipvs pr/84089
• Autoriser plusieurs masques cidr de nœuds dans kube-controller-manager pr/79993

@irvifa - Voici l'espace réservé docs PR. https://github.com/kubernetes/website/pull/17457

Cool merci @lachie83

@ lachie83 demain est le gel du code pour le cycle de publication 1.17. Il semble que les PRs k/k n'aient pas encore été fusionnés. 😬 Nous signalons cela comme à risque dans la feuille de suivi des améliorations 1.17.
Pensez-vous qu'ils seront fusionnés par l'EoD du 14 (jeudi) ? Après ce point, seuls les problèmes de blocage de version et les PR seront autorisés dans le jalon avec une exception.

Merci Bob - J'en discuterai avec sig-network aujourd'hui et je ferai une mise à jour.

Salut @mrbobbytables. Voici une liste des PR sur lesquels nous travaillons pour être fusionnés par EoD aujourd'hui et qui ont été approuvés par sig-network.

• https://github.com/kubernetes/kubernetes/pull/85246
• https://github.com/kubernetes/kubernetes/pull/83123
• https://github.com/kubernetes/kubernetes/pull/79993

Le PR restant sera très probablement ramené à 1,18 - https://github.com/kubernetes/kubernetes/pull/82462

@mrbobbytables vient de confirmer que tous les PR indiqués ci-dessus ont été fusionnés et que nous allons effectivement mettre kubernetes/kubernetes#82462 à 1.18. Cette amélioration peut toujours être suivie car ces PR ajoutent des changements significatifs au comportement dualstack dans 1.17. Maintenant, il ne me reste plus qu'à préparer les docs PR ! Nous espérons débarquer kubernetes/kubernetes#82462 en 1.18 et faire progresser ce travail en version bêta

Super, merci @lachie83 !

Et c'est en direct ! https://kubernetes.io/blog/2019/12/09kubernetes-1-17-release-announcement/

Nous prévoyons de déplacer cette amélioration vers la version bêta dans la version 1.18. Les critères d'obtention du diplôme d'amélioration et les plans de test peuvent être trouvés dans le KEP avec ce PR - https://github.com/kubernetes/enhancements/pull/1429

/jalon 1.18

@lachie83 : Le jalon fourni n'est pas valide pour ce référentiel. Jalons dans ce référentiel : [ keps-beta , keps-ga , v1.17 , v1.18 , v1.19 , v1.20 , v1.21 ]

Utilisez /milestone clear pour effacer le jalon.

/jalon v1.18

Nous prévoyons de déplacer cette amélioration vers la version bêta dans la version 1.18. Les critères d'obtention du diplôme d'amélioration et les plans de test peuvent être trouvés dans le KEP avec ce PR - #1429

Merci pour la mise à jour

Veuillez suivre le PR suivant dans le cadre des travaux pour atterrir en 1.18. https://github.com/kubernetes/kubernetes/pull/82462

Ajout d'autres PR connexes pour le suivi :
https://github.com/kubernetes/test-infra/pull/15893
https://github.com/kubernetes-sigs/kind/pull/692

Merci @lachie83 !

Salut @ lachie83 , avez-vous d'autres relations publiques que nous devrions suivre autres que celles mentionnées ci-dessus ?

Bonjour, @lachie83 @leblancd - Je suis l'ombre de Docs dans 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 des 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 avant le vendredi 28 février.

Faites moi savoir si vous avez des questions!

Si quelqu'un veut de l'aide pour documenter IPV6 ou des trucs à double pile pour la v1.18, donnez-moi un coup de pouce. Je peux peut-être aider.

Salut @lachie83 ,

On dirait que kubernetes-sigs/kind#692 n'a pas encore fusionné. Est-ce essentiel pour votre remise des diplômes bêta ?

Hé @jeremyrickard @sethmccombs, nous allons devoir passer de l'obtention du diplôme à la version bêta étant donné ce PR https://github.com/kubernetes/kubernetes/pull/86895. Jusqu'à ce que nous ayons une voie raisonnable à suivre, je ne pense pas qu'il soit sage de passer à la version bêta de la 1.18.

/jalon clair

@lachie83 Merci pour la mise à jour. J'ai supprimé cette amélioration du jalon. Dans l'attente de cela le 1.19. :)

Je voudrais confirmer que l'état de l'amélioration dualstack reste dans alpha en 1.18. Je travaille actuellement avec la communauté pour évaluer les travaux qui devraient être terminés en 1.19. Il est probable que cette amélioration reste à l'état alpha dans la version 1.19, mais je voudrais confirmer. Je vais également prendre des mesures pour mettre à jour les documents afin de refléter l'état d'amélioration dans les documents 1.18.

S'il y a des pages sur le site Web qui affichent Kubernetes à double pile en tant que version bêta, veuillez les classer contre k/site Web en tant que bogues prioritaires/importants-bientôt.

Salut @ lachie83 -- Améliorations 1.19

Le calendrier de diffusion actuel est le suivant :

• Lundi 13 avril : Semaine 1 - Début du cycle de publication
• Mardi 19 mai : Semaine 6 - Gel des améliorations
• Jeudi 25 juin : Semaine 11 - Gel du code
• Jeudi 9 juillet : Semaine 14 - Les documents doivent être complétés et révisés
• Mardi 4 août : Semaine 17 - Sortie de Kubernetes v1.19.0

S'il y a des pages sur le site Web qui affichent Kubernetes à double pile en tant que version bêta, veuillez les classer contre k/site Web en tant que bogues prioritaires/importants-bientôt.

@sftim J'ai levé deux PR pour traiter l'étiquetage des versions en 1.17 et 1.18

@palnabarun Nous travaillons pour mettre à jour le KEP dualstack dans le délai de publication de la version 1.19, mais nous ne pensons pas actuellement que nous apporterons des modifications au code dans la version 1.19. Nous avons un problème de blocage avec le travail qui a déjà été fait (grâce à son état alpha ). Le problème de blocage est https://github.com/kubernetes/kubernetes/pull/86895. Nous prévoyons de résoudre ce problème via la mise à jour KEP suivante https://github.com/kubernetes/enhancements/pull/1679 mais il faudra du temps pour obtenir un consensus sur le changement proposé. À ce stade, l'amélioration dualstack restera dans l'état alpha jusqu'à ce que nous résolvions ce problème de blocage avec l'implémentation actuelle. Je fournirai des mises à jour au fur et à mesure que les choses avancent.

Merci Lachie pour les mises à jour. J'apprécie tous les efforts! :slightly_smileing_face:

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é

Nous aimerions que cette amélioration soit suivie dans la version 1.20. Il sera réimplémenté à l'état alpha selon le kep mis à jour - https://github.com/kubernetes/enhancements/pull/1679. Veuillez suivre le PR suivant pour la mise en œuvre - https://github.com/kubernetes/kubernetes/pull/91824. Nous prévoyons de terminer l'examen et de fusionner le PR au début du cycle de publication 1.20.

Dernier passage au statut bêta à double pile, comme discuté lors de la réunion du réseau SIG du 17 septembre, pour ceux qui jouent à la maison :

• Doit résoudre l'ambiguïté de la vérification de l'état de la double pile de kubelet ; via https://github.com/kubernetes/enhancements/pull/1975
• Doit terminer et fusionner le PR des services à double pile existant (en cours d'examen); via https://github.com/kubernetes/kubernetes/pull/91824
• Doit finaliser le comportement des adresses IP des nœuds à double pile ; via https://github.com/kubernetes/enhancements/pull/1665
• Devrait déterminer les modifications (le cas échéant) requises pour le champ Spec.LoadBalancerIPs du service

Tous ces éléments sont activement travaillés, et 1.20 est toujours l'objectif pour l'obtention du diplôme de la bêta de l'API à double pile. Cependant, malgré tous nos efforts, il y a toujours une chance que quelque chose ne soit pas résolu à temps, et si c'est le cas, le réseau SIG décidera de poursuivre ou non le passage à la version bêta lors de nos réunions publiques. Tout le monde est le bienvenu à se joindre.

@dcbw merci beaucoup pour la mise à jour (désolé je n'ai pas pu passer l'appel). Est-il judicieux de passer à la version bêta de la version 1.20 ou simplement de rester en version alpha ? Si nous voulons passer à la version bêta, les critères d'obtention du diplôme dans le KEP ont-ils toujours un sens étant donné qu'il s'agit d'une réimplémentation https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6 -dual-stack.md#graduation -criteria

@dcbw merci beaucoup pour la mise à jour (désolé je n'ai pas pu passer l'appel). Est-il judicieux de passer à la version bêta de la version 1.20 ou simplement de rester en version alpha ? Si nous voulons passer à la version bêta, les critères d'obtention du diplôme dans le KEP ont-ils toujours un sens étant donné qu'il s'agit d'une réimplémentation https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6 -dual-stack.md#graduation -criteria

Ce n'est pas vraiment une réimplémentation, cependant. Tous les travaux précédents sont toujours valables et les travaux de la version 1.20 s'y ajoutent pour finaliser les derniers changements nécessaires qui ont été identifiés. Mon interprétation de la discussion sur le réseau sig est que la liste publiée par @dcbw est l'ensemble des problèmes connus restants à résoudre pour l'obtention du diplôme.

Salut tout le monde,

1.20 Améliorations Lead ici, je vais définir cela comme suivi, veuillez me mettre à jour si quelque chose change :)

Pour rappel, le gel des améliorations est le 6 octobre.

À noter que le KEP utilise un ancien format que nous avons mis à jour vers : https://github.com/kubernetes/enhancements/tree/master/keps/NNNN-kep-template

Meilleur,
Kirsten

/jalon v1.20

Salut, @russellb -

Ce n'est pas vraiment une réimplémentation, cependant. Tous les travaux précédents sont toujours valables et les travaux de la version 1.20 s'y ajoutent pour finaliser les derniers changements nécessaires qui ont été identifiés.

Compte tenu des modifications apportées à l'API dans https://github.com/kubernetes/kubernetes/pull/91824, il est assez différent que le marquage de la double pile en tant qu'alpha pour 1.20 laissera la place à d'autres réimplémentations qui s'avéreront nécessaires. Je sais que nous sommes tous impatients de recevoir la version bêta, mais commençons par décrocher le PR avec +9,319 −3,261 et laissons la poussière retomber. :)

Compte tenu des modifications apportées à l'API dans kubernetes/kubernetes#91824 , il est assez différent que le marquage de la double pile en tant qu'alpha pour 1.20 laissera de la place pour d'autres +9,319 −3,261 et laissons la poussière retomber. :)

@bridgetkromhout oui, nous devons atterrir sur https://github.com/kubernetes/kubernetes/pull/91824 avant de pouvoir prendre une décision sur la préparation de l'API. J'espère vraiment que nous pourrons le faire dès que possible.

Salut tout le monde,

1.20 Ombre d'amélioration ici 👋

Étant donné que cette amélioration est prévue pour la version 1.20, veuillez garder à l'esprit ces dates importantes à venir :
Vendredi 6 novembre : Semaine 8 - Date limite pour les relations publiques de l'espace réservé aux documents
Jeudi 12 novembre : Semaine 9 - Gel du code

Pour rappel, veuillez lier tous vos PR k/k ainsi que vos PR docs à ce problème afin que nous puissions les suivre.

Merci!

Salut @kinarashah @kikisdeliveryservice - J'ai confirmé lors de l'appel du réseau sig que nous avons besoin de ce reclassement en alpha pour 1.20. C'est une réimplémentation complète qui a besoin de temps pour s'imprégner et être testée en phase alpha.

Bonjour @lachie83 , 1.20 Docs shadow ici.

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

Si tel est le cas, veuillez suivre les étapes ici pour ouvrir un PR contre la branche dev-1.20 dans le k/website . Ce PR peut être juste un espace réservé pour le moment et doit être créé avant le 6 novembre .

Jetez également un œil à la documentation d'une version pour vous familiariser avec les exigences de documentation pour la version.

Merci!

Merci @reylejano-rxm - nous avons ouvert kubernetes/website#24725

Salut @lachie83

Merci d'avoir créé les docs PR !

Veuillez garder à l'esprit les dates importantes à venir :

• Vendredi 6 novembre : Semaine 8 - Date limite pour les relations publiques de l'espace réservé aux documents TERMINÉ !
• Jeudi 12 novembre : Semaine 9 - Gel du code
• Lundi 23 novembre : semaine 11 - Docs PR prêt pour examen

Pour rappel, veuillez lier tous vos PR k/k ainsi que vos PR docs à ce problème pour que l'équipe de publication puisse les suivre.

Salut @kinarashah @kikisdeliveryservice - J'ai confirmé lors de l'appel du réseau sig que nous avons besoin de ce reclassement en alpha pour 1.20. C'est une réimplémentation complète qui a besoin de temps pour s'imprégner et être testée en phase alpha.

Salut @lachie83

Compte tenu de ce qui précède, je suppose que cela est toujours destiné à l'alpha tel quel ? Je ne vois aucun PR en suspens qui doit fusionner / le travail a déjà été fusionné.

_Juste un rappel que Code Freeze arrive dans 2 jours le jeudi 12 novembre . Tous les PR doivent être fusionnés à cette date, sinon une exception est requise._

Merci!
Kirsten

Salut, @kikisdeliveryservice - oui, la prise en charge de la double pile IPv4/IPv6 (réimplémentée) sera alpha pour la version 1.20.

Voici les progrès que nous avons pour cette amélioration :

1) Le code est fusionné à partir de https://github.com/kubernetes/kubernetes/pull/91824 - sera alpha pour 1.20
2) Les mises à jour de la documentation couvrant ce changement de code se trouvent sur https://github.com/kubernetes/website/pull/24725/ - examinées et fusionnées dans la branche dev-1.20

Y a-t-il autre chose nécessaire pour la version 1.20 que nous n'avons pas terminé sur cette amélioration ?

@bridgetkromhout Merci pour la mise à jour claire, tout va bien !

Il semble que LoadBalancerIP dans ServiceSpec ne fasse pas encore partie de l'implémentation à double pile. Y a-t-il un plan pour le soutenir ou l'ai-je manqué?

Salut @chenwng - Les modifications apportées au code du fournisseur de cloud pour les équilibreurs de charge sont actuellement hors de portée, comme défini dans le KEP ici - https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6 -dual-stack.md#load -balancer-operation.

Vous pouvez nous aider en fournissant votre cas d'utilisation et les modifications suggérées pour comprendre et décider si nous devons apporter des modifications au KEP.

@chenwng Il y a un KEP en cours d' LoadBalancerIPs dans les clusters à double pile - https://github.com/kubernetes/enhancements/pull/1992

Merci pour l'info, @aramase , @lachie83 .