@enisoc @dchen1107 @fejta @thockin @kow3ns @derekwaynecarr , a ouvert ce problème de suivi afin que nous puissions en discuter.

/attribuer

@derekwaynecarr J'ai fait quelques recherches sur les changements de kubelet requis pour la réunion sig-node de la semaine prochaine, je crois que les changements ne sont nécessaires que dans le package kuberuntime , en particulier kuberuntime_manager.go dans et kuberuntime_container.go .

Dans kuberuntime_manager.go vous pouvez modifier computePodActions pour implémenter le déclenchement de l'arrêt (tuer les side-cars lorsque tous les non-sidecars sont définitivement sortis) et démarrer les side-cars en premier.

Dans kuberuntime_container.go vous pouviez modifier killContainersWithSyncResult pour terminer les side-cars en dernier et envoyer les hooks preStop (le bit preStop hooks était un peu discutable, il n'était pas décidé si cela devait être fait ou non. @ thockin avait une bonne idée des raisons pour lesquelles vous ne voudriez peut-être pas encourager ce comportement, voir le commentaire ).

Faites-moi savoir si vous voulez que j'étudie davantage.

@kow3ns La discussion a plus de sens pour moi si nous pouvons peut-être définir une description complète de la séquence de conteneurs dans la spécification de pod (sig-app) et comment gérer la séquence dans kubelet pour le démarrage, le redémarrage et la prise en compte en cascade (sig-node). Reprenons la réunion sig-node du 5 février pour donner plus d'informations.

cc @Joseph-Irving

La proposition dit que les side-cars ne s'exécutent qu'après l'exécution des conteneurs d'initialisation. Mais que se passe-t-il si le cas d'utilisation nécessite que le side-car s'exécute pendant/avant l'exécution des conteneurs d'initialisation. Par exemple, si vous souhaitez acheminer le trafic du pod via un proxy exécuté en tant que side-car (comme dans Istio), vous souhaitez probablement que ce proxy soit en place pendant que les conteneurs d'initialisation s'exécutent au cas où le conteneur d'initialisation lui-même effectuerait des appels réseau.

@luksa Je pense qu'il est possible d'envisager d'avoir des side-cars qui fonctionnent en phase d'initialisation à un moment donné, mais actuellement, la proposition ne couvrira pas ce cas d'utilisation. Il n'y a actuellement aucun moyen d'exécuter des conteneurs simultanés dans la phase d'initialisation, ce qui serait potentiellement un changement beaucoup plus important/désordonné que ce qui est suggéré ici.

Mise à jour sur ce KEP :
J'ai parlé à la fois à @derekwaynecarr et @dchen1107 de sig-node à ce sujet et ils n'ont exprimé aucune préoccupation majeure concernant la proposition. Je vais adresser un PR au KEP en ajoutant quelques notes initiales sur les détails de la mise en œuvre et en clarifiant quelques points qui ont été soulevés au cours de la discussion.

Nous devons encore nous mettre d'accord sur l'API, il semble qu'il y ait un consensus sur le fait qu'un moyen simple de marquer les conteneurs en tant que side-cars est préférable à des drapeaux de commande plus approfondis. Avoir un bool est quelque peu limitatif, donc peut-être quelque chose de plus du genre containerLifecycle: Sidecar serait préférable afin que nous ayons la possibilité de l'étendre à l'avenir.

@Joseph-Irving En fait, ni le booléen ni le containerLifecycle: Sidecar sont appropriés pour une extensibilité future appropriée. Au lieu de cela, containerLifecycle devrait être un objet, tout comme deployment.spec.strategy , avec type: Sidecar . Cela nous permettrait ensuite d'introduire des champs supplémentaires. Pour la solution « side-car pour toute la durée de vie du pod », elle s'exprimerait ainsi :

containerLifecycle: 
  type: Sidecar
  sidecar:
    scope: CompletePodLifetime

par opposition à

containerLifecycle: 
  type: Sidecar
  sidecar:
    scope: AfterInit

Veuillez pardonner ma mauvaise appellation - j'espère que les noms transmettent l'idée.

Mais il y a un problème avec l'approche où nous introduisons containerLifecycle à pod.spec.containers . À savoir, il est faux d'avoir des side-cars qui s'exécutent parallèlement aux conteneurs d'initialisation spécifiés sous pod.spec.containers . Donc, si vous voulez vraiment pouvoir étendre cela aux conteneurs d'initialisation, vous devriez trouver une solution alternative - une solution qui vous permettrait de marquer les conteneurs comme side-car à un niveau supérieur - c'est-à-dire pas moins de pod.spec.containers ou pod.spec.initContainers , mais quelque chose comme pod.spec.sidecarContainers , dont je crois que vous avez déjà discuté, mais rejeté. Le problème des conteneurs init appelle définitivement une solution dans ce sens.

@luksa Vous pouvez également résoudre le problème d'initialisation en permettant simplement à un conteneur d'initialisation d'être marqué comme side-car et de le faire fonctionner à côté des conteneurs d'initialisation. Si je comprends bien, le problème est que les conteneurs init ont parfois besoin de side-cars, ce qui est différent d'avoir besoin d'un conteneur qui fonctionne pendant toute la durée de vie du pod.

Le problème avec pod.spec.sidecarContainers est qu'il s'agit d'un changement beaucoup plus complexe, l'outillage aurait besoin d'être mis à jour et le kubelet aurait besoin de beaucoup de modifications pour prendre en charge un autre ensemble de conteneurs. La proposition actuelle est beaucoup plus modeste, elle ne fait que s'appuyer sur ce qui existe déjà.

@Joseph-Irving Nous pourrions travailler avec cela oui. Il n'est pas idéal que le side-car s'arrête après l'exécution des conteneurs d'initialisation, puis que le même side-car redémarre, mais c'est mieux que de ne pas avoir cette option. Le plus gros problème est que les anciens Kubelets ne géraient pas correctement les conteneurs init-side-car (comme c'est le cas avec les conteneurs principaux-side-car).

Je voudrais juste que vous gardiez à l'esprit les init-sidecars lors de la finalisation de la proposition. Essentiellement, vous introduisez le concept de "side-car" dans les k8 (auparavant, nous n'avions fondamentalement qu'un ensemble de conteneurs qui étaient tous égaux). Maintenant que vous introduisez de vrais side-cars, donc à mon humble avis, vous devriez vraiment y réfléchir à fond et ne pas écarter un cas d'utilisation de side-car très important.

Je serais heureux de vous aider à mettre en œuvre cela. Sans cela, Istio ne peut pas fournir ses fonctionnalités pour init conteneurs (en fait, dans un cluster Kubernetes correctement sécurisé exécutant Istio, les conteneurs init perdent complètement la capacité de parler à _n'importe quel_ service).

En ce qui concerne la discussion sur la mise en œuvre dans https://github.com/kubernetes/enhancements/pull/841 , j'ai ouvert un WIP PR contenant un PoC de base pour cette proposition https://github.com/kubernetes/kubernetes/pull /75099. Ce n'est qu'un premier brouillon et évidemment pas parfait, mais la fonctionnalité de base fonctionne et vous donne une idée de la quantité de changement nécessaire.

cc @enisoc

J'ai mis en place une courte vidéo montrant simplement comment le PoC se comporte actuellement https://youtu.be/4hC8t6_8bTs. Le voir en action peut être mieux que de le lire.
Avis de non-responsabilité : je ne suis pas un youtuber pro.

J'ai ouvert deux nouveaux PR :

• https://github.com/kubernetes/enhancements/pull/918 concerne les critères d'obtention du diplôme, le décalage de version, la mise à niveau/le déclassement
• https://github.com/kubernetes/enhancements/pull/919 doit décider de la mise en œuvre de l'API

Toutes les pensées ou suggestions seront très appréciées.

@Joseph-Irving Désolé si je commente tard dans le processus de conception, mais j'ai un cas d'utilisation potentiel pour les conteneurs side-car qui peut ne pas être pris en charge dans la proposition de conception actuelle. Je voulais juste le soulever pour examen. L'essentiel est que j'ai un scénario où lors de la terminaison du pod, 1 side-car doit être terminé avant le conteneur principal, tandis qu'un autre side-car doit être terminé après le conteneur principal.

Un exemple concret pourrait être un pod avec un conteneur d'application Django, un side-car consul pour l'enregistrement du service et un side-car pgbouncer pour gérer les connexions à la base de données. Lorsque le pod est terminé, j'aimerais que le side-car consul soit arrêté en premier (afin qu'aucun trafic ne soit plus acheminé vers le pod), puis le conteneur d'applications (idéalement après une courte période de grâce), puis le side-car pgbouncer. La proposition actuelle semble très bien pour gérer la dépendance du conteneur app <-> pgbouncer, mais ne semble pas assez expressive pour capturer le cas où je voudrais démolir un side-car _avant_ le conteneur principal.

@currankaushik , dans le scénario que vous avez décrit, vous pourriez potentiellement utiliser un crochet de pré-arrêt pour dire au conteneur consul de se préparer à l'arrêt et d'arrêter les demandes de routage vers vous (en supposant qu'il puisse prendre en charge quelque chose comme ça). des crochets de pré-arrêt seront envoyés aux side-cars avant le début de la fin des conteneurs.

La motivation pour cela était que les side-cars proxy comme istio puissent entrer dans un état où ils ne vous acheminent pas le trafic mais autorisent toujours le trafic pendant que votre application se termine et s'arrête.

Ça sonne bien, merci @Joseph-Irving. Donc, juste pour confirmer ma compréhension à un niveau élevé : les crochets de pré-arrêt seront d'abord envoyés aux side-cars, suivis des crochets de pré-arrêt aux non-sidecars, SIGTERM aux non-sidecars, puis (après que tous les non-sidecars sont sortis ) SIGTERM aux side-cars ? La proposition de conception (https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/sidecarcontainers.md) semble impliquer cela mais dit également :

Les crochets PreStop seront envoyés aux side-cars et aux conteneurs en même temps.

@currankaushik ouais ce que vous avez décrit est le comportement prévu.

Cette ligne que vous avez citée a besoin d'être reformulée. J'avais des idées fausses sur la façon dont les crochets de pré-arrêt étaient envoyés aux conteneurs lorsque j'ai écrit cela. Merci de l'avoir signalé.

@Joseph-Irving est-ce que cette fonctionnalité cible l'inclusion alpha pour la 1,15 ?

@kacole2 ouais c'est le plan, en supposant que nous puissions mettre en œuvre le KEP à temps pour le gel des améliorations (30 avril). Une fois l'API finalisée https://github.com/kubernetes/enhancements/pull/919 et le plan de test convenu https://github.com/kubernetes/enhancements/pull/951, je pense que nous devrions être prêts.

/jalon v1.15
/étape alpha

@Joseph-Irving Kubernetes 1.15 Enhancement Freeze est le 30/04/2019. Pour être inclus dans le jalon Kubernetes 1.15, les KEP doivent être dans un état « implémentable » avec des plans de test et des critères de graduation appropriés. Veuillez soumettre tous les PR nécessaires pour que ce KEP adhère aux critères d'inclusion. Si cela dépasse le jalon 1,15, veuillez nous en informer afin que nous puissions apporter les modifications de suivi appropriées.

@mrbobbytables, malheureusement, les PR ouverts pour mettre cela dans un état implémentable n'ont pas eu beaucoup de mouvement sur eux, donc je pense que nous devrons retarder cela jusqu'au 1.16.

Pas de soucis. Merci d'avoir été si rapide à répondre et à nous le faire savoir!
/jalon clair

N'oubliez pas que ce KEP est très important pour Istio !

C'est un point d'orgue pour tous les projets utilisant des frameworks de service avec un démarrage/arrêt coordonné (cluster akka, lagom, etc.) avec le maillage de service istio voir .

cc @jroper

@Joseph-Irving sry à propos du commentaire tardif, mais je ne vois pas ce qui suit dans le document de conception, et je me demandais quel est le comportement prévu de ceux-ci:

si nous voyons une défaillance du side-car, les redémarrons-nous toujours si le conteneur principal n'est pas terminé (sans tenir compte de la stratégie de redémarrage dans le pod) ? Cela serait utile car le side-car fonctionnait comme proxy, équilibrage de charge, rôle de gardiennage, et peu importe s'il échoue plusieurs fois tant que le conteneur principal peut continuer à fonctionner

De plus, lors du calcul de la phase de pod, si tous les conteneurs principaux ont réussi et que le side-car a échoué (ce qui est très courant, car si le side-car n'attrape pas SIGTERM, le code de retour sera comme 143 ou quelque chose du genre), la phase de pod est-elle toujours "Réussie" ?

@zhan849 actuellement, les conteneurs side-car obéissent à la politique de redémarrage du pod et sont comptés lors du calcul de la phase du pod, telle que Succeeded .

Nous en avons débattu un peu plus tôt dans le processus, mais le sentiment général était que nous devions nous écarter le moins possible d'un conteneur normal, en ne le faisant que s'il permet les cas d'utilisation décrits.

En ce qui concerne la phase de pod : je dirais que toutes les applications exécutées dans kubernetes devraient gérer les SIGTERM (en particulier les side-cars), mais parfois vous voudriez savoir si vos side-cars ont mal tourné et cela devrait être reflété dans la phase de pod, cacher cette information pourrait prêter à confusion.

Pour la politique de redémarrage, il semble que ce ne soit un problème que si la politique de redémarrage ne l'est jamais et que votre side-car est susceptible de planter. Je ne sais pas si la complication de les diverger de la politique de redémarrage des pods en vaut la peine, d'autant plus que certaines personnes peuvent vouloir que leurs side-cars obéissent à la politique de redémarrage des pods.

Ces deux choses correspondent exactement à ce que fait un conteneur normal et à ce qui se passe actuellement.
Les changer ne semblait pas être nécessaire pour atteindre les objectifs énumérés dans le Kep.

Si vous avez des cas d'utilisation répandus expliquant pourquoi les changer est nécessaire pour atteindre ces objectifs, ce serait utile. Car cela permet de justifier plus facilement une modification plus compliquée de la base de code.

@Joseph-Irving, nous avons des implémentations de side-car plus simples qui ont fonctionné en interne pour certains besoins immédiats (nous n'avons pas contribué car cela est déjà en cours dans la communauté), et voici ce que nous avons appris.

Concernant la phase de pod :

1. Le statut d'existence du conteneur est déjà reflété dans pod.status.containerStatuses afin que nous ne perdions pas les informations. De plus, étant donné qu'un grand cas d'utilisation de side-car est dans Job (ou dans tous les pods d'exécution tels que ceux de Kubeflow), des charges de travail significatives seront appliquées uniquement au conteneur principal et si la phase de pod est marquée comme Échec en raison d'un échec du side-car. , cela entraînera des tentatives inutiles et entraînera d'autres conséquences trompeuses telles que l'échec de la tâche, etc.

2. Bien qu'il soit idéal pour les side-cars de gérer les SIGTERM, en production, il pourrait y avoir beaucoup de side-cars qui sont simplement construits sur des logiciels open source et ils ne gèrent pas bien les SIGTERM, y compris kube-proxy , postfix , rsyslogd , et bien d'autres (et même si SIGTERM est géré, pour SIGKILL non capturable, ce ne sera certainement pas 0)

En ce qui concerne la politique de redémarrage (cela peut être discutable, mais faire en sorte que les side-cars obéissent strictement à la politique de redémarrage n'est pas du tout réaliste en production) :

1. Forcer le side-car à redémarrer lorsque les conteneurs principaux sont toujours en cours d'exécution en définissant « OnFailure » ​​n'est pas une option car cela redémarrera les conteneurs principaux en échec et est source de confusion avec la limite de nouvelle tentative au niveau du travail.

2. Habituellement, lors de la gestion des side-cars, les conteneurs principaux ont généralement de nombreuses logiques de nouvelle tentative pour les side-cars indisponibles, et celles-ci sont effectuées avant que la communauté ne dispose d'une prise en charge des side-cars avec un ordre de démarrage explicite des conteneurs. De telles gestions d'erreurs historiques ne sont pas très faciles à modifier étant donné l'étendue de celle-ci. Ne pas redémarrer le side-car entraînera le blocage des conteneurs principaux et une nouvelle tentative

3. La propagation des échecs aux contrôleurs de niveau supérieur déclenchera des chaînes de réconciliation et de nombreux appels d'API, de sorte qu'une escalade inutile des erreurs peut rendre kubernetes moins évolutif.
   Un exemple plus spécifique : si les conteneurs principaux d'une tâche sont toujours en cours d'exécution et que le side-car échoue, le redémarrage du side-car n'aura qu'une opération d'état du pod PATCH et au plus 1 appel d'API lié à un événement. Mais si le pod échoue complètement, cela entraînera une réconciliation de Job, et davantage de contrôleurs de niveau d'embauche tels que CronJob et d'autres CRD et il pourrait y avoir beaucoup plus d'appels d'API.

je veux aussi voir si d'autres personnes ont rencontré des problèmes similaires (/cc @kow3ns )

Ce changement incorporerait-il le comportement souhaité dans https://github.com/kubernetes/community/pull/2342 , de sorte qu'il y aurait un moyen de configurer l'ensemble du pod (ou simplement le conteneur non-sidecar) pour redémarrer si un side-car échoue?

@JacobHenner, il n'est actuellement pas prévu de mettre en œuvre ce type de mécanisme dans ce KEP, nous avons discuté de son intégration, mais il n'a pas vraiment de dépendance à ce KEP et pourrait être développé indépendamment de cela. Il semble donc mieux adapté d'avoir son propre KEP.

@Joseph-Irving juste pour partager notre impl qui a abordé les pièges mentionnés ci-dessus pour votre référence (https://github.com/zhan849/kubernetes/commits/kubelet-sidecar) puisque notre objectif est d'attendre le support officiel, nous essayons pour garder le changement aussi local que possible dans ce commit.

donc pour une politique de redémarrage de travail == Jamais, avec 1 conteneur principal, 1 mauvais side-car qui plante constamment, 1 bon side-car qui continue de fonctionner, le statut du pod ressemblera à ceci après la fermeture du conteneur principal avec l'impl ci-dessus.

containerStatuses:
  - containerID: xxxxx
    image: xxxxx
    imageID: xxxxx
    lastState: {}
    name: main
    ready: false
    restartCount: 0
    state:
      terminated:
        containerID: xxxxx
        exitCode: 0
        finishedAt: "2019-05-24T17:59:53Z"
        reason: Completed
        startedAt: "2019-05-24T17:59:43Z"
  - containerID: xxxxx
    image: xxxxxx
    imageID: xxxxx
    lastState: {}
    name: sidecar-bad
    ready: false
    restartCount: 1
    state:
      terminated:
        containerID: xxxxx
        exitCode: 1
        finishedAt: "2019-05-24T17:59:46Z"
        reason: Error
        startedAt: "2019-05-24T17:59:45Z"
  - containerID: xxxxx
    image: xxxxxxx
    imageID: xxxxx
    lastState: {}
    name: sidecar-healthy
    ready: false
    restartCount: 0
    state:
      terminated:
        containerID: xxxxx
        exitCode: 137
        finishedAt: "2019-05-24T18:00:24Z"
        reason: Error
        startedAt: "2019-05-24T17:59:44Z"
  hostIP: 10.3.23.230
  phase: Succeeded
  podIP: 192.168.1.85
  qosClass: BestEffort
  startTime: "2019-05-24T17:59:41Z"

En général, je conviens qu'un side-car KEP doit prendre en compte la phase de pod et la politique de redémarrage avant de pouvoir passer à un état implémentable. Peu m'importe qu'il s'agisse de ce KEP ou non, mais je suis d'accord en général avec les arguments de @ zhan849 et cela doit être traité ici.

merci @smarterclayton !
@Joseph-Irving, faites-nous savoir s'il y a autre chose que vous aimeriez que nous partagions avec le side-car dans la pratique.

@ smarterclayton @ zhan849 , je ne suis pas particulièrement en désaccord avec vos arguments, j'essaie juste de donner quelques contre-points. C'était un choix conscient de ne pas modifier les phases de pod/la politique de redémarrage car cela augmenterait encore la portée de cette proposition et personne n'y croyait vraiment.

Je vais rapporter ces commentaires à sig-apps/sig-node et voir ce qu'ils en pensent. sig-node en particulier tenait à garder les side-cars aussi près que possible des conteneurs normaux, si @derekwaynecarr ou @dchen1107 veulent intervenir, cela serait apprécié.

Le plan de test https://github.com/kubernetes/enhancements/pull/951 et la conception de l'API https://github.com/kubernetes/enhancements/pull/919 PRs ont maintenant été fusionnés.

J'ai ouvert https://github.com/kubernetes/enhancements/pull/1109 pour que le KEP soit marqué comme implémentable, une fois que tout le monde est satisfait, nous devrions pouvoir commencer le développement pour cela en tant qu'alpha en 1.16 🤞

Ce Kep a été marqué comme implémentable, je vais donc augmenter les PR pour le mettre en 1.16 à partir de la semaine prochaine !

J'ai soulevé https://github.com/kubernetes/kubernetes/pull/79649 pour implémenter l'API, j'aurai un PR séparé pour les changements de Kubelet.

Salut @Joseph-Irving, je suis le responsable de l'amélioration 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 . Si ce n'est pas le cas, je le supprimerai du jalon et modifierai l'étiquette suivie.

Une fois le codage 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.

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

Merci.

@Joseph-Irving Si vous voulez / avez besoin de personnes supplémentaires pour mettre en œuvre cela, j'ai beaucoup d'intérêt pour cet atterrissage, donc je suis heureux de donner un coup de main.

Salut @kacole2 ceci vise Alpha pour 1.16, le KEP a été marqué comme implémentable.
Le seul PR pour cela actuellement est kubernetes/kubernetes#79649 pour l'API

@mhuxtable Je vais augmenter le PR pour les changements de kubelet assez bientôt, en terminant juste certaines choses, j'apprécierais grandement de l'aide pour y jeter un coup d'œil. Je le lierai ici quand il sera soulevé.

J'ai ouvert https://github.com/kubernetes/kubernetes/pull/80744 qui implémente les changements de kubelet.

Veuillez noter que kubernetes/kubernetes#79649 (api) est toujours ouvert, ce PR contient donc des commits, ce qui le fait paraître volumineux. Je l'ai décomposé en commits qui implémentent chacun une fonctionnalité différente, il devrait donc être facile de l'examiner de cette façon.

Je n'ai pas tout à fait fini de faire tous les cas de test pour cela, mais le premier brouillon de l'implémentation de travail est terminé, j'aimerais donc que les gens y jettent un coup d'œil.

cc @kacole2

@Joseph-Irving

Je suis l'une des ombres de la documentation v1.16.
Cette amélioration (ou le travail prévu pour la v1.16) 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.16 (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.16) dû d'ici le vendredi 23 août, il peut simplement s'agir d'un PR d'espace réservé pour le moment. Faites moi savoir si vous avez des questions!

Salut @daminisatya , oui, cela nécessitera des mises à jour de Docs, j'ai soulevé https://github.com/kubernetes/website/pull/15693 en tant que PR d'espace réservé.
Je serais intéressé de savoir si quelqu'un a des opinions sur l'endroit où les Docs devraient aller, j'ai mis quelque chose dans content/en/docs/concepts/workloads/pods/pod-lifecycle.md pour l'instant.

Avec moins d'une semaine avant Code Freeze, il semble très peu probable que cela puisse passer en 1.16.
Nous avons encore deux PR ouverts relativement importants kubernetes/kubernetes#80744 et kubernetes/kubernetes#79649 qui ont eu du mal à obtenir des critiques.
Espérons qu'il y aura plus de bande passante pour les réviseurs au prochain cycle de publication pour les examiner.

/attribuer

Cela pourrait-il permettre d'écrire un side-car qui peut démarrer le service réel à la demande (et le détruire) ?

Comme l'échelle à zéro, mais la seule chose qui fonctionne au ralenti est le side-car. Lorsque la demande arrive, il lance le service réel et après une dernière réponse, par exemple 30s, il le fermera. Cela pourrait permettre un moyen simple de faire une mise à l'échelle presque à zéro (avec seulement les side-cars en marche).

@Ciantic Avec Operator Framework, vous pouvez faire cela et bien plus encore. Regarde

@janosroden J'ai regardé, mais il semble assez difficile de comprendre comment élever les services en cours d'exécution à zéro évolutif.

Le problème n'est pas qu'il n'y a pas d'options disponibles, par exemple Osiris , Keda ou knative . J'ai essayé le dernier, mais il monopolise 8 Go de mémoire, difficile de dire qu'il est « sans serveur » à ce stade.

Le problème est que la plupart de ces implémentations ont besoin de nouvelles ressources, etc. il est beaucoup plus facile de le penser pour pouvoir injecter un side-car qui peut contrôler l'ensemble du cycle de vie (y compris le démarrage et le redémarrage à la demande) afin qu'il puisse contrôler le service au-delà de assis là.

Pourquoi cela serait-il bénéfique ? C'est vraiment utile dans les situations de faible utilisation et de faible mémoire, par exemple k3s avec Raspberry Pi, ou Digital Ocean droplet pour les projets de loisirs. Beaucoup d'entre nous ont beaucoup de services Web qui n'ont pas besoin de fonctionner tout le temps, il suffit d'avoir un side-car qui peut les réveiller à la demande serait suffisant.

Pas sûr que cela fonctionne vraiment pour votre cas d'utilisation. Je vois totalement le désir de faire ce que vous voulez faire sur de tels systèmes aux ressources limitées. Mais pour être vraiment stable, vous devez utiliser des demandes de ressources pour aider à planifier la charge de travail. Celles-ci devraient être spécifiées à l'avance, donc que la charge de travail soit en cours d'exécution ou non, elle doit réserver la ressource.

Pour contourner ce problème, vous avez à peu près besoin d'un pod pour effectuer la réception de connexion initiale et faire une nouvelle demande de pod à k8s, attendre qu'il le lance, puis lui envoyer le trafic. Les améliorations des conteneurs side-car ne sont pas nécessaires dans ce cas, je pense. Vous avez besoin de quelque chose de plus comme un xinetd pour k8s je pense.

Salut @Joseph-Irving -- Les améliorations 1.17 mènent ici. Je voulais vérifier et voir si vous pensez que cette amélioration passera à l'alpha 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!

Salut @mrbobbytables , en supposant que nous puissions tout revoir à temps, le plan est de passer à l'alpha en 1.17.

Les PR actuellement ouverts sont :
https://github.com/kubernetes/kubernetes/pull/79649 - Modifications de l'API
https://github.com/kubernetes/kubernetes/pull/80744 - Changements Kubelet

Fait moi savoir si tu as besoin de quoique ce soit d'autre!

Super! Merci @Joseph-Irving j'ajouterai l'info sur la feuille de suivi 👍

@Joseph-Irving

Je suis l'une des ombres de la documentation v1.17.
Cette amélioration (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!

Merci!

Salut @ VineethReddy02 oui, cela nécessitera de la documentation, l'espace réservé PR est ici https://github.com/kubernetes/website/pull/17190

J'ai soulevé un PR pour mettre à jour le KEP https://github.com/kubernetes/enhancements/pull/1344 c'est basé sur une discussion que nous avions dans la mise en œuvre PR https://github.com/kubernetes/kubernetes/pull /80744.

j'apprécierais tout commentaire

Hé @Joseph-Irving 1.17 Enhancement Shadow ici ! 👋 Je vous contacte pour voir comment évolue cette amélioration.

L'équipe d'amélioration suit actuellement kubernetes/kubernetes#79649 et kubernetes/kubernetes#80744 dans la feuille de suivi. Y a-t-il d'autres PR k/k qui doivent également être suivis ?

Aussi, un autre rappel amical que nous approchons rapidement du gel du code (14 novembre).

Salut @annajung ,

Salut @Joseph-Irving, Demain est le gel du code pour le cycle de publication 1.17 . Il semble que les PRs k/k n'aient pas été fusionnés. Nous signalons cette amélioration comme At Risk dans la feuille de suivi 1.17.

Pensez-vous que tous les PR nécessaires seront fusionnés par l'EoD du 14 (jeudi) ? Après cela, seuls les problèmes de blocage de version et les PR seront autorisés dans le jalon avec une exception.

Salut @annajung , malheureusement, il semble très peu probable qu'ils soient fusionnés avant le gel du code. Nous avons fait beaucoup de progrès au cours de ce cycle de publication, nous espérons donc pouvoir les fusionner au début de la version 1.18.

Hé @Joseph-Irving Merci pour la mise à jour. Je mettrai à jour le jalon en conséquence et marquerai cette amélioration comme reportée à 1.18. Merci!

/jalon v1.18

Salut @Joseph-Irving. 1.18 Les améliorations mènent ici 👋 .

La version 1.18 a commencé hier, alors je vous contacte pour voir si vous prévoyez de l'atterrir dans la version 1.18 ? Je pense que cela a raté la 1.17 à cause du gel du code. Comment les choses se présentent-elles pour 1,18 ? Je vois que les PR sont toujours ouverts.

Merci!

Salut @jeremyrickard ,

Oui, le plan est d'obtenir cela dans la version 1.18.

L'API PR (https://github.com/kubernetes/kubernetes/pull/79649) a reçu une critique de thockin, l'autre jour, il avait quelques points mais une fois ceux-ci résolus, nous fermerons ce PR et intégrerons les commits dans (https://github.com/kubernetes/kubernetes/pull/80744) afin que nous puissions fusionner l'API et la mise en œuvre ensemble.

Quant au Kubelet PR (https://github.com/kubernetes/kubernetes/pull/80744), il a juste besoin d'être révisé, j'espère que nous pourrons obtenir de la bande passante sig-node pour le réviser ce cycle.

Merci pour la mise à jour @Joseph-Irving

Je l'ai ajouté à la feuille de suivi !

Désolé d'être en retard à la fête. Il s'agit d'une amélioration significative pour les cas courants. Mais ne semble pas couvrir un cas plus avancé.

Prenons le cas d'un side-car qui exporte des logs qui dépend également du side-car Istio. Si le side-car Istio s'arrête en premier, certains journaux sensibles peuvent ne pas être exportés.

Une approche plus générique consisterait à définir des dépendances explicites entre les conteneurs. Peu importe si ce sont des side-cars ou non.

Que pensez-vous d'une telle définition d'API à la place :

kind: Pod
spec:
  containers:
  - name: myapp
    dependsOn: ["exporter", "istio"]
  - name: exporter
    dependsOn: ["istio"]
  - name: istio

@rubenhak ça devient très vite désordonné. Que faut-il satisfaire pour que la dépendance soit claire pour continuer ? Il y a souvent un écart entre démarré et prêt dont je pense que dependOn se soucierait vraiment de ce que l'API ne traite pas.

@kfox1111 Comment la conception proposée détermine-t-elle que le side-car est démarré et prêt pour lancer le conteneur principal ? La seule différence que je propose est qu'au lieu de marquer les conteneurs comme "side-car", il faut utiliser une manière plus générique de définir la dépendance.

Je ne pense pas que dependOn devrait spécifier des critères. Il pourrait être spécifié dans le conteneur dépendant. Ne serait - readinessProbe et / ou livenessProbe suffisant? Sinon, il peut y avoir une startupProbe - dont le succès indique que les conteneurs dépendants peuvent être démarrés.

Bonjour @Joseph-Irving, je suis l'une des ombres des docs v1.18.
Cette amélioration pour (ou le travail prévu pour la v1.18) 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.18 (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.18) dû d'ici le vendredi 28 février, il peut simplement s'agir d'un PR d'espace réservé pour le moment. Faites moi savoir si vous avez des questions!

Salut @irvifa J'ai soulevé un PR d'espace réservé ici https://github.com/kubernetes/website/pull/19046

Salut @Joseph-Irving Merci pour votre réponse rapide !

@rubenhak - Je suis d'accord avec @kfox1111 pour dire qu'avoir un graphique complet des dépendances peut devenir assez compliqué assez rapidement. Que diriez-vous de commencer les conteneurs dans l'ordre indiqué dans les spécifications du pod, puis de les démonter dans l'ordre inverse (comme une pile) ? Ce serait beaucoup plus simple à mettre en œuvre et couvre la plupart des cas d'utilisation de commande courants auxquels je peux penser.

@rgulewich , pourriez-vous développer un peu plus, qu'est-ce qui peut être compliqué exactement? Dériver l'ordre du graphique est une tâche triviale, surtout compte tenu du fait qu'aucun opérateur sain d'esprit ne ferait fonctionner plus de 15 side-cars (déjà un tronçon).

L'idée d'ordre est ok, mais comme la plupart des side-cars sont injectés à l'aide de contrôleurs d'admission, il serait vraiment difficile de garantir l'exactitude de l'ordre. Il y a un besoin d'indirection.

@rubenhak, il pourrait y avoir un cycle dans l'ordre de dépendance des conteneurs, comment k8s/kubelet décide-t-il de rompre le cycle et de décider dans quel ordre démarrer/arrêter les conteneurs ? En pensant à voix haute, cela pourrait peut-être être une validation côté API.

Salut @Joseph-Irving,

Juste un rappel amical que le gel du code pour la 1.18 est le 05 mars 2020 .

Au fur et à mesure que nous suivons le gel du code, veuillez répertorier / créer un lien vers tous les PR sur lesquels vous travaillez pour obtenir cette amélioration !

Salut @jeremyrickard ,

Le pr doit-il suivre https://github.com/kubernetes/kubernetes/pull/80744
Ce PR contient des modifications de l'API, mais les commits seront fusionnés dans le PR ci-dessus une fois l'examen terminé https://github.com/kubernetes/kubernetes/pull/79649

@rubenhak, il pourrait y avoir un cycle dans l'ordre de dépendance des conteneurs, comment k8s/kubelet décide-t-il de rompre le cycle et de décider dans quel ordre démarrer/arrêter les conteneurs ? En pensant à voix haute, cela pourrait peut-être être une validation côté API.

@bjhaid , côté API peut faire la validation. La détection de boucle est un algorithme trivial avec une complexité temporelle linéaire (tout comme la traversée DFS).

Il peut également être nécessaire de relancer la validation après l'injection de side-car.

J'y réfléchis depuis un moment... La plupart des problèmes de dépendances se résument, je pense, aux maillages de service. (peut-être que quelqu'un peut penser à un autre exemple)

Le proxy de maillage de services est un side-car qui doit démarrer et être prêt avant toute autre chose, et doit se terminer après toute autre chose. Ils fonctionnent depuis longtemps et sont donc plus un side-car qu'un conteneur d'initialisation.

Mais dans l'idéal, les initContainers devraient tous pouvoir également utiliser le service mesh.

Mais initContainers peut avoir besoin d'initialiser d'autres conteneurs side-car.

Alors que nous pourrions concevoir une sorte de système de dépendance complexe impliquant des conteneurs init, des conteneurs side-car et des conteneurs réguliers, nous devrions peut-être avoir simplement deux classes de side-cars ? side-cars réguliers et side-cars réseau ?

les side-cars du réseau doivent tous être prêts dès le début. les proxys de service mesh vont ici.
Les conteneurs init s'exécutent ensuite dans l'ordre.
les side-cars démarrent tous et se préparent. Cela peut inclure des éléments tels que des proxys d'authentification, des enregistreurs, etc.
les conteneurs réguliers démarrent et deviennent prêts.

le démontage est à l'envers.

Cela éliminerait-il le problème de dépendance tout en résolvant tous les problèmes que les maillages de service semblent avoir avec la commande de conteneurs ? je le pense?

@kfox1111 , Vault effectue désormais une injection secrète à l'aide de side-cars. Dans quelle classe doit-il s'intégrer ? De plus, selon le cas, le coffre-fort peut dépendre du maillage de service, ou l'inverse.

Tout ce que je dis, c'est qu'une telle conception finirait par exploser en 10 classes de side-car. Une telle approche implique une opinion encore plus forte sur la façon dont les choses devraient fonctionner. Les gens commençaient à pirater avec des classes, juste pour obtenir l'ordre requis pour lancer l'application.

Si le seul but de ces classes est de définir l'ordre, pourquoi ne pas le faire explicitement ?

Pour répondre à votre question, bien qu'une telle conception couvre certains cas d'utilisation, cela n'aide pas avec d'autres cas comme les side-cars de coffre, les side-cars de journalisation, etc. Il s'agit déjà d'une proposition de refonte de la fonctionnalité d'origine. Puisqu'il s'agit d'une deuxième tentative, cela vaut la peine de bien faire les choses cette fois.

Je ne sais pas à quel point les dépendances sont complexes. Pourriez-vous élaborer plus à ce sujet? Les dépendances rendent les définitions YAML plus évidentes, il n'y a pas de logique cachée. Une approche avec des classes codées en dur nécessiterait une logique cachée et beaucoup plus de documentation expliquant pourquoi les side-cars réseau devraient fonctionner après d'autres side-cars, etc.

Et si on introduisait un champ dans Container ?

    // +optional
    Priority int

Ce champ est effectif parmi les conteneurs du même type (side-car, normal).
Pour les conteneurs side-car, le conteneur side-car avec une priorité plus élevée serait instancié en premier / détruit en dernier.

@tedyu , la dépendance a beaucoup plus de métadonnées et de valeur que la "priorité". Il faut 30 lignes de code c++ pour produire un ordre de priorité compte tenu de la dépendance https://www.geeksforgeeks.org/find-the-ordering-of-tasks-from-given-dependencies/ . L'inverse n'est pas possible.

Un autre avantage est que, compte tenu du graphe de dépendance, certains conteneurs peuvent être démarrés en même temps.
Dans l'exemple suivant : "A -> B, B -> C, D -> C" les conteneurs B et D peuvent être démarrés en même temps si C est initialisé. Je ne dis pas que l'implémentation doit prendre en charge cela, mais au moins cela peut être très utile si l'API permet une telle définition.

La priorité entière ne fonctionnera pas bien - les gens utiliseront toutes sortes de nombres différents et non standardisés comme ils le font avec la propriété CSS z-index (comme -9999 ).

@rubenhak Ce que vous suggérez à ce stade est fondamentalement une fonctionnalité entièrement différente de celle décrite dans ce KEP, ce n'est pas un petit ajustement, c'est une réécriture totale. Cela nécessiterait que tous ceux qui avaient précédemment accepté cette fonctionnalité (il a fallu un an pour que cela soit approuvé par toutes les parties) pour réévaluer cela.
Si vous êtes passionné par une telle fonctionnalité, je vous suggère de créer votre propre KEP et de l'apporter aux différents SIG pour obtenir leurs commentaires à ce sujet.

L'idée d'un graphe de dépendance a été longuement discutée lorsque cette proposition a commencé en 2018, la conclusion a été unanime en ce sens que même si cela permettrait d'autres cas d'utilisation, ils n'étaient pas des cas d'utilisation assez forts et que la complexité supplémentaire n'en valait pas la peine.

Je pense que vous sous-estimez quelque peu le degré de changement requis pour mettre en œuvre ce que vous décrivez. Mais si c'est aussi simple que vous semblez le penser, vous pouvez créer votre propre preuve de concept de ce travail dans Kubernetes et la présenter aux SIG pour aider à renforcer votre cas.

Ce KEP n'est pas encore une fonctionnalité GA, si votre KEP est approuvé et mis en œuvre, nous pouvons supprimer celui-ci. Ils ne sont pas encore mutuellement exclusifs.

Ce changement n'est peut-être pas la solution parfaite pour chaque cas d'utilisation, mais il améliore considérablement l'expérience pour la plupart et je pense que nous ferions bien mieux de fusionner cela plutôt que de débattre pendant une autre année de la mise en œuvre.

si votre KEP est approuvé et mis en œuvre, nous pouvons supprimer celui-ci. Ils ne sont pas encore mutuellement exclusifs.

Seraient-ils _jamais_ mutuellement exclusifs ?

Je me demande si cette fonctionnalité a une valeur _même si_ un ordre de démarrage/d'arrêt plus explicite des conteneurs (ce qui, je pense, serait génial) est activé via une autre amélioration à l'avenir... et je pense que oui.

Tout ordre de démarrage / arrêt, impliqué par la classification des conteneurs en tant qu'init, side-car ou « régulier » mis de côté, ces classifications expriment également d'autres aspects utiles et sans doute sans rapport du comportement souhaité d'un conteneur, n'est-ce pas ?

Par exemple, il est utile dans un pod avec restartPolicy != Always (un pod qui implémente un travail, peut-être), que les conteneurs désignés comme side-cars n'aient aucune incidence sur un pod entrant dans un état terminé.

@kfox1111 , Vault effectue désormais une injection secrète à l'aide de side-cars. Dans quelle classe doit-il s'intégrer ? De plus, selon le cas, le coffre-fort peut dépendre du maillage de service, ou l'inverse.

Nous avons travaillé avec des pilotes éphémères csi afin que des choses comme le coffre-fort n'aient pas besoin de side-cars/conteneurs d'initialisation. Je crois qu'il y a un pilote de coffre-fort en préparation.

Bien que le side-car normal avec emptyDir semble convenir à un side-car qui doit utiliser les side-cars du réseau ?

@Joseph-Irving, je n'essayais en aucun cas d'empêcher ce KEP d'entrer. Je me rends compte que vous l'avez commencé il y a près de 2 ans et qu'il y a beaucoup de gens qui attendent que cela soit publié.

Avez-vous un lien vers une discussion antérieure relative au graphique de dépendance ?

Salut @Joseph-Irving,

Rappel amical que nous fermons assez rapidement le gel du code le 05 mars 2020 . Il ne semble pas que vos PR aient encore fusionné, avez-vous toujours l'impression d'être sur la bonne voie pour le gel du code pour cette amélioration ?

Hé @jeremyrickard , L'examen de l'API (https://github.com/kubernetes/kubernetes/pull/79649) est essentiellement terminé. Nous fermerons ce PR et passerons entièrement au PR d'implémentation afin que tout (API et Implémentation) puisse être fusionné en un seul PR.

Le PR de mise en œuvre (https://github.com/kubernetes/kubernetes/pull/80744) a été soigneusement examiné, j'essaie donc d'obtenir un approbateur sig-node pour examiner l'approbation finale.

Il est quelque peu difficile pour moi de dire si cela se produit à temps pour le gel du code, cela dépend beaucoup de savoir si je parviens à attirer l'attention de certains approbateurs à temps.

J'adorerais voir cela entrer par gel de code. Cela rendrait la solution d'Istio à https://github.com/istio/istio/issues/7136 à la fois plus simple et meilleure.

Y a-t-il un mouvement sur cette entrée à 1,18 ? Semble nécessaire pour que les side-cars istio fonctionnent comme prévu avec des tâches à exécution rapide.

J'ai essayé de contacter les approbateurs sig-node de diverses manières, mais je n'ai eu aucune réponse. Je ne suis donc pas très optimiste sur le fait que cela passera en 1.18.

@Joseph-Irving, le canal slack #pr-reviews a été créé pour ces cas. Avez-vous essayé cela? C'est un moyen d'obtenir une escalade sur les critiques de PR. (je ne l'ai pas vu dedans)

Salut @Joseph-Irving,

Nous ne sommes plus qu'à quelques jours du gel du code. Voulez-vous reporter cela à 1,19 en fonction de la bande passante du réviseur ? Ou essayer de pousser ?

Salut @jeremyrickard ,

Personne ne m'a répondu concernant la fusion de ces PR dans la version 1.18, donc je doute fortement que cela se produise.

On peut reporter à 1,19 mais je commence à me demander s'il y a un intérêt à le faire.
Ce KEP est en vol depuis près de deux ans (l'alpha cible d'origine était de 1,15), les PR en question sont ouverts depuis près d'un an, il n'y a jamais de "bande passante de critique" pour eux.
J'ai poliment envoyé des e-mails, relâché, assisté à des réunions sig et même trouvé des personnes en personne pour obtenir des critiques, mais nous avons fait très peu de progrès.
Toutes les critiques que j'ai réussi à obtenir n'ont suggéré que des changements mineurs, ce n'est pas comme si de grandes réécritures avaient été demandées, les PR sont tous fondamentalement les mêmes qu'il y a un an, juste un peu plus raffinés.
Je ne sais pas si je suis censé cingler les gens de manière agressive tous les jours jusqu'à ce qu'ils me répondent, mais ce n'est vraiment pas quelque chose que je suis à l'aise de faire.

Je pense que le problème est plus que personne ne se soucie réellement de cette fonctionnalité, je suis le seul à faire avancer cette fonctionnalité, personne dans les SIG ne semble intéressé à voir cela à travers. S'il faut deux ans pour passer en version alpha, combien de temps faudra-t-il pour passer en version bêta/GA ? (comme quand la plupart des gens peuvent réellement l'utiliser)

De manière frustrante, il semble y avoir un intérêt de la part de la communauté au sens large et des utilisateurs finaux à intégrer cette fonctionnalité, la raison pour laquelle j'ai fait cela en premier lieu est que j'ai vu que c'était un problème, en demandant aux SIG s'ils allaient le réparer, et ils dit "nous n'avons pas la capacité mais nous serions heureux que vous le fassiez".
J'ai donc fait tout ce qu'ils ont demandé, j'ai écrit le KEP, je l'ai fait approuver par toutes les parties, j'ai écrit tout le code, tous les tests, je l'ai constamment mis à jour à chaque sortie de version, et pourtant nous y sommes.

Chaque fois que nous retardons cela, j'ai l'impression de laisser tomber un tas de gens, est-ce que tout est de ma faute ? le code est-il si terrible que personne ne commentera même? ne suis-je pas assez agressif pour essayer d'attirer l'attention ?
J'ai juste l'impression que je ne peux pas faire ça tout seul, et j'en ai un peu marre de battre ce cheval mort.

Je suis désolé pour la longue diatribe (ne s'adresse pas à vous personnellement Jeremy ou à quiconque personnellement d'ailleurs), mais cela ronge lentement mon âme depuis longtemps maintenant.

De manière frustrante, il semble y avoir un intérêt de la part de la communauté au sens large et des utilisateurs finaux à intégrer cette fonctionnalité, la raison pour laquelle j'ai fait cela en premier lieu est que j'ai vu que c'était un problème, en demandant aux SIG s'ils allaient le réparer, et ils dit "nous n'avons pas la capacité mais nous serions heureux que vous le fassiez".

@Joseph-Irving À ce sujet. En tant qu'utilisateur actif, je regarde ce fil parce que je suis intéressé (et deux de mes collègues aussi). L'activité sur le problème, la demande d'extraction, les canaux slack ou les signatures peuvent ne pas être le meilleur indicateur d'intérêt pour cette fonctionnalité.

@dims Peut-être pouvez-vous nous éclairer ?

@thockin Je vous ai écouté dans le podcast Kubernetes il y a environ un an et vous avez parlé de contribuer à Kubernetes. C'est peut-être vous ou quelqu'un d'autre dans un autre épisode de podcast qui vous êtes senti vraiment mal que ce side-car KEP n'ait pas atteint la 1,16. Bon, nous y revoilà.

Ce problème semble être un excellent exemple de la difficulté de contribuer si vous n'êtes pas un employé de, par exemple. Google, RedHat ou autre gros joueur.

J'ai également demandé à Slack de l'aide pour le réviser, mais on vient de me dire qu'il y a une retenue explicite par @thockin, donc je ne suis pas sûr non plus de la voie à suivre.

J'ai passé beaucoup de temps sur la fonctionnalité du pilote csi éphémère. Le faire passer était tout aussi frustrant et il y avait des moments où je n'étais pas sûr que ça allait le faire après tant de retards et de refontes. Alors, je ressens ta douleur. Ce serait formidable si nous pouvions trouver un moyen de le rendre moins douloureux. Cela étant dit, nous l'avons également finalement intégré après avoir raté quelques versions majeures. Alors s'il vous plaît, ne perdez pas espoir! Le navire peut être difficile à tourner, mais il finit par le faire.

Toute personne exécutant tout type de topologie qui dépend d'un side-car de réseau rencontre très probablement des problèmes de commande de démarrage / d'arrêt de conteneur que ce KEP résoudrait potentiellement. Ctrl-F pour "Istio" sur ce ticket, et vous verrez un tas de désagréments liés à la commande de conteneurs.

Y a-t-il des mainteneurs Istio ici ? Beaucoup sont des Googleurs et pourraient avoir plus d'influence sur les gens de K8 en interne.

En tant que boutique Istio / K8s, nous vous encourageons absolument à obtenir cet atterrissage, @Joseph-Irving ! ️

bravo à @Joseph-Irving pour avoir fabriqué un side-car jusqu'ici.

Même pour la gestion du cycle de vie des side-cars, toute tâche par lots nécessiterait cette fonctionnalité ou Kubernetes ne fonctionnerait tout simplement pas pour eux, et c'est pourquoi nous avons également passé beaucoup de temps à aider les revues de code et à fournir des retours !

Nous avons forké les k8 depuis un certain temps à cause de cela et nous sommes vraiment impatients de voir une fonctionnalité aussi importante prise en charge officiellement.

En tant que boutique Istio + Kubernetes, nous attendions également cette fonctionnalité avec impatience. Et de plus en plus frustré qu'il glisse d'une version à l'autre. Nous ne sommes pas ravis de devoir recourir à des hacks pour tuer les side-cars sur les charges de travail. Pour nos besoins, il s'agit de la fonctionnalité la plus importante dont nous avons besoin dans Kubernetes, depuis plus d'un an.

@thockin Il a été rapporté ci-dessus que vous avez explicitement mis cela en attente. Pouvez-vous s'il vous plaît expliquer pourquoi.

Il y a aussi beaucoup d'utilisateurs de Linkerd qui attendent cela avec impatience. Accrochez-vous @Joseph-Irving, nous vous encourageons.

Je ne sais pas si tout le monde ici a vu, mais après avoir creusé et regardé une vidéo de kubecon, j'ai découvert que Lyft avait fait quelque chose de similaire à celui-ci. Voici le commit mentionné de leur fork de kubernetes : https://github.com/lyft/kubernetes/commit/ba9e7975957d61a7b68adb75f007c410fc9c80cc

En tant que boutique Istio + Kubernetes, nous attendions également cette fonctionnalité avec impatience. Et de plus en plus frustré qu'il glisse d'une version à l'autre.

Je suis un utilisateur potentiel d'istio, mais je suis resté un peu à l'écart en raison de l'attente d'une fonctionnalité comme celle-ci. Au cours des discussions ci-dessus, cependant, je continue de voir des choses qui me font penser que la fonction side-car seule, comme discuté ici, ne résoudra pas tous les problèmes que le side-car istio a avec le flux de travail. Cela peut aider cependant. Ce qui, je pense, fait partie de la raison pour laquelle cela a calé.

Comment fonctionne l'exécution d'istio dans un side-car lors de l'utilisation du pilote istio cni ? Je pense que les conteneurs init essayant d'atteindre le réseau ne fonctionneront toujours pas correctement, comme indiqué dans la documentation istio.

d'où ma question ci-dessus si les side-cars du réseau sont sa propre chose.

Ce problème semble être un excellent exemple de la difficulté de contribuer si vous n'êtes pas un employé de, par exemple. Google, RedHat ou autre gros joueur.

Ha ! Ce que vous ne savez pas, c'est que ces gens se coincent aussi parfois !

Sérieusement, je suis désolé. J'ai des excuses, mais ça craint donc je ne vais pas m'embêter.

Pour éclaircissement :
Je ne veux pas dire que nous ne devrions pas fusionner cela en tant qu'alpha pour obtenir des commentaires sur l'approche. En général, je pense que c'est sain. Je pense qu'il y a quelques trous dans les cas d'utilisation tels que les maillages de service qu'il ne couvre pas tout à fait. Mais ce n'est pas une raison pour bloquer l'obtention de cela dès que possible afin que nous puissions trouver tous les autres cas d'utilisation qu'il ne couvre pas afin que nous puissions faire en sorte que la version bêta de la fonctionnalité fonctionne bien pour tout le monde. C'est précisément ce qu'est un alpha pour l'OMI.

Je ne fais que mentionner ce que j'ai fait, en particulier aux personnes qui espèrent que ce sera une solution miracle au problème de maillage de service existant. Je ne pense pas que l'alpha tel que proposé résoudra complètement ce problème particulier. Alors n'espérez pas trop haut pour l'instant. Mais s'il vous plaît, ne bloquons pas cette fonctionnalité simplement parce qu'elle ne prend pas encore en charge tout le monde.

J'ai demandé une exception, voyons si nous pouvons essayer d'obtenir ceci :
https://groups.google.com/d/msg/kubernetes-sig-release/RHbkIvAmIGM/nNUthrQsCQAJ

C'est peut-être vous ou quelqu'un d'autre dans un autre épisode de [Kubernetes Podcast] qui vous êtes senti vraiment mal que ce side-car KEP n'ait pas atteint la 1,16

S'il vous plaît voir les épisodes 72, avec Lachie Evenson , et 83, avec Guenièvre Saenger . J'ai même annoncé cette semaine que des examens de relations publiques étaient nécessaires pour résoudre ce problème. On peut le faire!

Y a-t-il des mainteneurs Istio ici ? Beaucoup sont des Googleurs et pourraient avoir plus d'influence sur les gens de K8 en interne.

@duderino et @howardjohn ont déjà tous les deux commenté ce fil.

Pour être clair, nous avons besoin de fusionner :
kubernetes/kubernetes#79649
kubernetes/kubernetes#80744

Y a-t-il d'autres PR que nous devrions suivre ?

Merci!

• Équipe des améliorations

Un grand merci à tous ceux qui ont posté des messages de soutien (en public ou en privé) qui ont été très appréciés ❤️

Les membres de la communauté ont fait de vaillants efforts pour essayer de mettre cela en 1.18, y compris l'équipe de publication qui a accepté une demande d'extension, mais hélas, la décision a été prise de reporter cela à 1.19. Vous pouvez voir la conversation pertinente à partir de ce commentaire : https://github.com/kubernetes/kubernetes/pull/80744#issuecomment -595292034.

Bien qu'il ne soit pas entré dans la 1.18, cela a suscité beaucoup plus d'attention ces derniers jours qu'il n'en a eu depuis un certain temps, j'espère donc que cet élan se poursuivra dans la 1.19.

cc @jeremyrickard , @kikisdeliveryservice

Super truc @Joseph-Irving, on dirait que certaines de vos frustrations ont valu la peine et ont été écoutées. Merci d'avoir persévéré.

/jalon v1.19

Salut tout le monde. Un groupe d'entre nous a discuté de ce sujet au cours de la semaine dernière.

Tout d'abord, nous nous excusons pour ce qui s'est passé ici. Nous n'en sommes pas contents.

Ce PR et le KEP associé ont mis en lumière un certain nombre de choses que le projet peut améliorer. Nous aimerions séparer les préoccupations sociales, procédurales et techniques.

Socialement, ce long métrage a été victime de notre envie de nous faire plaisir. Derek a approuvé le KEP, malgré les réserves exprimées au sein du SIG, car Clayton et Tim le poussaient. Nous nous faisons tous confiance, mais apparemment, nous n'avons pas toujours l'impression de pouvoir dire « non ». Nous le savons parce que nous avons tous fait exactement la même chose. Aucun de nous ne veut être le bloqueur de la prochaine grande idée.

Se faire confiance doit inclure la confiance que nous pouvons dire « non » et la confiance que lorsque quelqu'un dit « non », il le fait pour de bonnes raisons. Ce domaine technique s'étend sur les SIG, et nous ne devrions PAS faire pression sur le nœud de signature, qui sera finalement celui qui réglera les problèmes, pour qu'il accepte de nouvelles fonctionnalités qu'il ne soit pas encore à l'aise de prendre en charge. Il ne s'agit pas de Tim, Derek ou Clayton en particulier, mais TOUS les approbateurs de haut niveau, les responsables SIG et les contributeurs « seniors ».

Cette fonctionnalité a également été victime de l'incertitude procédurale autour des KEP. En tant que réviseur KEP, suis-je obligé d'être un réviseur de code ? Déléguer à un réviseur de code ? Ou juste pour lire le KEP ? Au fur et à mesure que les KEP s'étendent sur les versions, comment pouvons-nous nous assurer qu'un berger est disponible pour l'ensemble des changements budgétisés dans une période particulière de versions. Si un KEP couvre les SIG, comment budgétisons-nous et allouons-nous du temps entre les SIG ? Nous devons clarifier cela. Nous allons travailler sur certaines propositions de changement KEP (KEP KEP) pour renforcer la définition des rôles dans le processus KEP.

Techniquement, cette fonctionnalité a été victime à la fois du temps et de l'attention. Les évaluateurs n'ont pas pris suffisamment de temps pour l'examiner, ou ce n'était tout simplement pas une priorité suffisamment élevée pour eux. Les discussions en va-et-vient prennent du temps. Les circonstances et notre compréhension de l'espace du problème changent avec le temps.

À mesure que de plus en plus d'utilisateurs adoptent Kubernetes, nous constatons qu'un nombre croissant de cas extrêmes ou de flocons étranges sont signalés à sig-node. Étant donné que le cycle de vie du pod est au cœur de Kubernetes, toute modification apportée à ce sous-système DOIT être entreprise avec soin. Notre capacité à fusionner de nouvelles fonctionnalités doit être équilibrée avec notre désir d'améliorer la fiabilité. La façon dont nous envisageons le cycle de vie du Pod aujourd'hui est un peu différente de celle que nous pensions lorsque cette fonctionnalité a été lancée. Cela ne diminue en rien les cas d'utilisation qui y ont conduit, mais cela suggère que les KEP de longue durée doivent être périodiquement réexaminés au fil du temps.

Nous pensons que nous devons réfléchir un peu aux principes de base du cycle de vie du Pod. Que voulons-nous vraiment? Nous avons essayé de ne pas sombrer dans une trop grande complexité, mais nous craignons d'avoir simplement divisé cette complexité en plusieurs phases, et le résultat net peut être PLUS complexe que de simplement s'y attaquer de front.

Qu'est-ce que cela signifie pour ce PR et le KEP associé ? Nous ne sommes pas sûrs à 100 %. Cela signifie probablement que nous ne devrions PAS encore faire passer cela.

Derek a fait part de certaines inquiétudes concernant le séquençage de l'arrêt. Le KEP les a appelés hors de portée pour l'instant, mais il y a quelques hésitations. Nous ne respectons déjà pas la terminaison gracieuse lors de l'arrêt du nœud, ce qui a surpris de nombreux utilisateurs. Ce n'est pas la faute de ce KEP, mais appelons ça des « circonstances atténuantes ». Si quelqu'un utilise des side-cars pour « nettoyer » ses pods (par exemple, pour drainer les journaux mis en cache dans un service de journalisation), il s'attendra (raisonnablement) à une sémantique claire et utile autour de l'arrêt, ce que ce KEP ne garantit pas.

Tim craint que les side-cars init aient besoin de devenir une chose, et cela ne semble pas correct. Il a renoncé à cette préoccupation dans le passé, mais cela le dérange toujours.

Nous avons besoin de SIG Node pour aider à définir quel est l'objectif à moyen terme pour le cycle de vie des pods, et quel est leur appétit pour s'en charger. Si nous pouvons convenir qu'il s'agit d' un pas progressif vers l'objectif, nous pouvons le débloquer, mais à moins que nous ne connaissions l'objectif, nous sommes probablement en train de suralimenter nos phares.

Soyons tous les premiers à dire que ça pue. Nous avons de vrais énoncés de problèmes, un contributeur passionné et un ensemble de mainteneurs bien intentionnés, et nous nous sommes retrouvés... ici. Tim offrira son temps pour aider à réfléchir et à concevoir. Derek poussera le travail de fermeture des nœuds pour le cycle de vie actuel du pod afin de garantir que nous ayons une base stable pour le développer davantage. Nous devrons spécifier très soigneusement les garanties que nous pouvons et ne pouvons pas faire face aux pannes imprévues des machines.

Merci,
Clayton, David, Dawn, Derek, John, Tim

Pour essayer de stimuler un mouvement vers l'avant : Derek ou Dawn - y a-t-il quelqu'un qui peut prendre le temps de réfléchir à un cycle de vie plus holistique des pods et des conteneurs ?

@thockin ajoutera ceci à l'ordre du jour de sig-node.

@thockin @derekwaynecarr quel est le tl; dr pour savoir pourquoi cela n'a pas pu entrer?

Description de l'amélioration en une ligne : les conteneurs peuvent désormais être marqués comme side-cars afin qu'ils démarrent avant les conteneurs normaux et s'arrêtent après la fin de tous les autres conteneurs.

Cela ressemble à quelque chose qui faciliterait la vie dans cette nouvelle ère de side-cars en maille de service.

De plus, des recommandations pour que les side-cars démarrent avant les conteneurs d'applications principaux et s'arrêtent après l'arrêt du conteneur d'applications principal aujourd'hui ?

... quel est le tl; dr quant à pourquoi cela n'a pas pu entrer?

@naseemkullah De https://github.com/kubernetes/enhancements/issues/753#issuecomment -597372056 ... 👇

Qu'est-ce que cela signifie pour ce PR et le KEP associé ? Nous ne sommes pas sûrs à 100 %. Cela signifie probablement que nous ne devrions PAS encore faire passer cela.

Derek a fait part de certaines inquiétudes concernant le séquençage de l'arrêt. Le KEP les a appelés hors de portée pour l'instant, mais il y a quelques hésitations. Nous ne respectons déjà pas la terminaison gracieuse lors de l'arrêt du nœud, ce qui a surpris de nombreux utilisateurs. Ce n'est pas la faute de ce KEP, mais appelons ça des « circonstances atténuantes ». Si quelqu'un utilise des side-cars pour « nettoyer » ses pods (par exemple, pour drainer les journaux mis en cache dans un service de journalisation), il s'attendra (raisonnablement) à une sémantique claire et utile autour de l'arrêt, ce que ce KEP ne garantit pas.

[...]

Nous avons besoin de SIG Node pour aider à définir quel est l'objectif à moyen terme pour le cycle de vie des pods, et quel est leur appétit pour s'en charger. Si nous pouvons convenir qu'il s'agit d'un pas progressif vers l'objectif, nous pouvons le débloquer, mais à moins que nous ne connaissions l'objectif, nous sommes probablement en train de suralimenter nos phares.

Respectueusement, je suis curieux de savoir si des pistes envisagent de prioriser le tri de ce problème. @Joseph-Irving a consacré énormément de travail à cela et un nombre impressionnant de personnes qui auraient été satisfaites de sa solution sont impatientes d'entendre une solution supérieure de la part de ceux qui ont refusé cela.

Au minimum, même s'il y a des scrupules à certains aspects, je pense qu'il est toujours raisonnable d'entrer en tant qu'Alpha afin de trouver quels problèmes apparaîtront dans la pratique. Pouvons-nous fusionner cela ? Les problèmes peuvent l'empêcher de passer à la version bêta, donc je ne pense pas qu'il soit essentiel d'être parfait avant la création d'une alpha initiale.

l'ajoutera à l'agenda du nœud de signature.

@thockin @derekwaynecarr y a-t-il une mise à jour sur l'état actuel de cela? J'ai parcouru les notes de réunion de sig-node et je n'ai rien vu à ce sujet.

Il y a un grand nombre de développeurs sur ce fil qui seraient plus qu'heureux de consacrer du temps à sa mise en œuvre, car c'est essentiel pour de nombreux cas d'utilisation (le KEP lui-même en a 2,5 fois plus :+1: que n'importe quel autre KEP). Que pouvons-nous faire pour que cela se produise? Avoir une liste de conditions préalables à la stabilité de ce domaine, même si cela peut s'étendre sur de nombreuses versions à accomplir, sur lesquelles nous pourrions commencer à travailler activement serait une énorme amélioration par rapport à ce que nous en sommes aujourd'hui.

Salut @Joseph-Irving @thockin @khenidak @kow3ns -- 1.19 Améliorations Lead ici, je voulais vérifier si vous pensez que cette amélioration passerait en 1.19 ?

Pour avoir cette partie de la version :

1. Le KEP PR doit être fusionné dans un état implémentable
2. Le KEP doit avoir des plans de test
3. Le KEP doit avoir des critères d'obtention du diplôme.

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

@palnabarun , Selon ce commentaire https://github.com/kubernetes/enhancements/issues/753#issuecomment -597372056, ce KEP a été suspendu indéfiniment, donc non, il ne sera pas diplômé en 1.19.

Merci @Joseph-Irving d'avoir clarifié la situation. :+1:

Appréciez vos efforts !

À tous ceux qui sont impatients de le faire, et encore à @Joseph-Irving - je suis personnellement très désolé pour cette situation. Je veux ça (ou quelque chose comme ça), aussi, mais le fait est que sig-node a plus de travail à faire que les gens à le faire en ce moment, et ils ne sont pas prêts à considérer cela.

C'est nul. Je comprends. Je le fais vraiment vraiment.

La meilleure façon dont les gens pourraient aider est de sauter dans sig-node et d'aider à augmenter la capacité en effectuant des révisions de code et en triant les problèmes, en corrigeant les bogues et les tests, et en construisant vers un endroit où les experts de sig-node ont plus de capacité et confiance pour effectuer un tel changement.

sig-node a plus de travail à faire que de personnes à le faire en ce moment

Entendu. Nous avons fait la promotion, en mettant l'accent sur les besoins en capacité de sig-node en interne. Nous embauchons et encadrons des bénévoles de l'OSS sig-node, certains expérimentés, tous avec le désir de travailler dans cet espace (quatre à ce jour). Je vais citer votre commentaire @thockin , merci !

/jalon clair

La meilleure façon dont les gens pourraient aider est de sauter dans sig-node et d'aider à augmenter la capacité en effectuant des révisions de code et en triant les problèmes, en corrigeant les bogues et les tests, et en construisant vers un endroit où les experts de sig-node ont plus de capacité et confiance pour effectuer un tel changement.

@thockin Pourriez-vous fournir les liens comme les référentiels, les listes de diffusion, les guides, etc. ? Cela aiderait les gens à se faire une idée sur la façon de s'engager efficacement avec sig-node. Cette demande de fonctionnalité particulière a plus de 2 ans et aucune résolution n'est en vue.

@ tariq1890 les gens qui écrivent ce KEP ont tout fait correctement. ils n'ont laissé aucune pierre non retournée. Le problème ici est exactement ce que @thockin a dit, il y a une dette technologique que nous devons d'abord réparer et des mains sont nécessaires pour cela avant de pouvoir envisager celle-ci. Donc, la demande est que les gens aident avec ce qui doit être fait.

Veuillez consulter la dernière mise à jour ici : https://github.com/kubernetes/enhancements/pull/1874

@dims Je pense que j'ai été mal compris. Ce que je voulais dire, c'est que nous avons besoin d'une liste de cibles et d'objectifs réalisables. S'il y a une dette technologique à traiter, nous pourrions alors maintenir un jalon GitHub ou fournir une liste à puces des éléments d'action en attente dans le commentaire du PO afin que les personnes visitant ce problème puissent savoir immédiatement ce qui doit être traité.

Je suis certainement prêt à offrir mon aide pour sig/node avec l'avancement de ce KEP, mais je ne sais pas comment

@tariq1890 la demande spécifique est ici : "prérequis sur l'arrêt gracieux du nœud kubelet (pas encore soumis)" https://github.com/kubernetes/enhancements/pull/1874/files#diff -c6212b56619f2b462935ad5f631d772fR94

Nous devons commencer. Quelqu'un doit prendre le point et le faire avancer.

-- Dims

Donc, le résumé https://github.com/kubernetes/enhancements/pull/1874 pour ceux dans ce numéro : Sig-node (et d'autres) pense qu'il n'est pas judicieux d'introduire une nouvelle fonctionnalité comme ce KEP, qui ajoute un comportement plus complexe à la terminaison de pod, alors qu'il existe toujours le problème plus générique de la terminaison de pod lors de l'arrêt d'un nœud.
Il a donc été décidé que cette fonctionnalité ne progressera pas tant que la solution à la terminaison de nœud n'aura pas été implémentée.
Il y a actuellement un google doc ici : https://docs.google.com/document/d/1mPBLcNyrGzsLDA6unBn00mMwYzlP2tSct0n8lWfuRGE
Qui contient une grande partie de la discussion autour de la question, mais le KEP pour cela n'a pas encore été soumis.
Il y a encore des questions ouvertes, donc commenter cela pourrait être utile, je pense que @bobbypage et @mrunalp dirigent cet effort afin qu'ils puissent peut-être partager d'autres façons dont les gens pourraient aider à faire avancer les choses.

@Joseph-Irving remercie énormément d'avoir résumé. J'espère que toute l'énergie +ve sur cette amélioration se traduira par une plus grande participation de tout le monde à sig-node sur une base régulière et pas seulement une seule fois pour les fonctionnalités. Il y a beaucoup de travail à faire et très peu de mains.

Salut! Un autre commentaire concernant ce KEP, cependant : j'ai soulevé quelques cas marginaux à propos de ce KEP lors des réunions précédentes du nœud SIG (le 23 juin si vous voulez regarder les enregistrements) et nous avons décidé que la bonne façon de poursuivre cette discussion était d'ouvrir des relations publiques sur ces questions afin que nous puissions décider de la meilleure façon de procéder.

Je travaille actuellement sur un PR pour énoncer ces problèmes et quelques alternatives auxquelles je peux penser.

De plus, l'état du KEP est désormais provisoire (au lieu d'être implémentable) de sorte qu'il peut être revu et remis à implémentable uniquement lorsque toutes les personnes sont d'accord pour se sentir à l'aise d'aller de l'avant avec le KEP.

Je pense que c'était la seule information manquante dans ce numéro. Merci!

@rata Avez-vous ouvert des problèmes/RP sur la bonne façon de gérer les problèmes ?

@mattfarina Ceci est le PR https://github.com/kubernetes/enhancements/pull/1913
Il contient un certain nombre de solutions proposées aux problèmes/cas limites actuels dans le KEP
Contient également des détails sur un certain nombre d'alternatives qui ont été discutées et rejetées, afin que nous ayons un meilleur journal des raisons pour lesquelles certaines décisions ont été prises.

J'aimerais beaucoup que la fonctionnalité side-car couvre également la mise à l'échelle :
Aujourd'hui, la mise à l'échelle HPA est basée sur une métrique (telle que le processeur). Si le pod contient plus d'un conteneur, la moyenne de tous les conteneurs est utilisée (pour autant que je sache). Pour les pods avec side-car (app + nginx, etc.), il est très difficile de faire fonctionner correctement la mise à l'échelle. J'espérais que la mise en œuvre du side-car dans Kubernetes inclurait le marquage d'un conteneur dans le pod comme « faisant autorité » en termes de métriques utilisées pour la mise à l'échelle HPA.

J'aimerais beaucoup que la fonctionnalité side-car couvre également la mise à l'échelle :

Je suis d'accord que cela serait utile mais ce n'est pas nécessairement spécifique au "side-car" et puisque la mise en œuvre est découplée de cela, il peut être judicieux d'en faire une question distincte - celle-ci est déjà très complexe. Je ne suis pas non plus convaincu que vous vouliez simplement ignorer le side-car. Par exemple, nous pouvons préférer une mise à l'échelle HPA par conteneur. Je ne sais pas - aurait besoin d'être exploré comme son propre problème, je pense.

Quelqu'un a-t-il une référence à, ou pourrait-il avoir la gentillesse de partager, la solution de contournement actuelle pour ce problème, en particulier pour le cas du side-car Istio Envoy ?

Je me souviens d'une solution de contournement possible impliquant:

• une image Envoy personnalisée qui ignore SIGTERM.
• appel de /quitquitquit sur Envoy depuis le conteneur d'applications à l'arrêt (similaire à la solution de contournement de l'achèvement du travail)

Quelqu'un a-t-il une référence à, ou pourrait-il avoir la gentillesse de partager, la solution de contournement actuelle pour ce problème, en particulier pour le cas du side-car Istio Envoy ?

Nous utilisons une image de démon personnalisée comme un supervisor pour envelopper le programme de l'utilisateur. Le démon écoutera également un port particulier pour transmettre l'état de santé des programmes des utilisateurs (sortis ou non).

Voici la solution de contournement :

• Utilisation de l'image du démon en tant que initContainers pour copier le binaire sur un volume partagé.
• Notre CD détournera la commande des utilisateurs, laissez le démon démarrer en premier. Ensuite, le démon exécute le programme des utilisateurs jusqu'à ce qu'Envoy soit prêt.
• De plus, nous ajoutons preStop , un script qui vérifie en permanence l'état de santé du démon, pour Envoy.

Par conséquent, le processus des utilisateurs démarrera si Envoy est prêt et Envoy s'arrêtera une fois le processus des utilisateurs terminé.

C'est une solution de contournement compliquée, mais elle fonctionne bien dans notre environnement de production.

Le lien dans la description donne un 404

https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0753-sidecarcontainers.md

Je pense que ça devrait être :

https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0753-sidecarcontainers.md

ouais il a été déplacé dans https://github.com/kubernetes/enhancements/pull/1913 , j'ai mis à jour le lien

Quelqu'un a-t-il une référence à, ou pourrait-il avoir la gentillesse de partager, la solution de contournement actuelle pour ce problème, en particulier pour le cas du side-car Istio Envoy ?

@shaneqld pour les problèmes de démarrage, la communauté istio a proposé une solution de contournement assez intelligente qui injecte essentiellement envoy comme premier conteneur dans la liste des conteneurs et ajoute un crochet postStart qui vérifie et attend qu'envoy soit prêt. Ceci est bloquant et les autres conteneurs ne démarrent pas en s'assurant qu'envoy est là et prêt avant de démarrer le conteneur d'applications.

Nous avons dû le porter sur la version que nous utilisons, mais c'est assez simple et nous sommes satisfaits des résultats jusqu'à présent.

Pour l'arrêt, nous "résolvons" également avec le hook preStop, mais en ajoutant un sommeil arbitraire que nous espérons que l'application se fermera gracieusement avant de continuer avec SIGTERM.

Relations publiques associées : https://github.com/kubernetes/enhancements/pull/1980

Salut @Joseph-Irving @thockin et tout le monde :sourire:

Les améliorations mènent ici. Je vois qu'il y a encore une tonne de conversations en cours, mais pour rappel, veuillez nous tenir au courant de tout projet d'inclure cela dans la version 1.20 afin que nous puissions suivre les progrès.

Merci!
Kirsten

@kikisdeliveryservice vous tiendra au courant, merci !

Quelqu'un a-t-il une référence à, ou pourrait-il avoir la gentillesse de partager, la solution de contournement actuelle pour ce problème, en particulier pour le cas du side-car Istio Envoy ?

@shaneqld pour les problèmes de démarrage, la communauté istio a proposé une solution de contournement assez intelligente qui injecte essentiellement envoy comme premier conteneur dans la liste des conteneurs et ajoute un crochet postStart qui vérifie et attend qu'envoy soit prêt. Ceci est bloquant et les autres conteneurs ne démarrent pas en s'assurant qu'envoy est là et prêt avant de démarrer le conteneur d'applications.

Nous avons dû le porter sur la version que nous utilisons, mais c'est assez simple et nous sommes satisfaits des résultats jusqu'à présent.

Pour l'arrêt, nous "résolvons" également avec le hook preStop, mais en ajoutant un sommeil arbitraire que nous espérons que l'application se fermera gracieusement avant de continuer avec SIGTERM.

Pourriez-vous montrer en détail comment procéder ? Comment réaliser l'ajout de 'pré-arrêt' au side-car Istio-proxy ? Il semble qu'il ait besoin d'une configuration personnalisée ou d'un side-car personnalisé. Je suis confronté au même problème que lorsque les pods diminuent, le conteneur principal essaie de terminer les travaux mais il perd la connexion avec l'extérieur probablement parce que le side-car Istio s'est fermé immédiatement après SIGTERM. Pour le moment, je n'utilise que l'injection side-car par défaut. Merci!

Ok, ce fil est piraté. Restons dans le sujet, s'il vous plaît.

Juste un petit rappel que le gel des améliorations aura lieu la semaine prochaine, le mardi 6 octobre. À ce moment-là, le KEP devra être mis à jour pour être marqué comme réalisable.

De plus, le KEP utilise un format plus ancien, donc la mise à jour serait géniale (une fois que vous aurez fini de définir les détails): https://github.com/kubernetes/enhancements/tree/master/keps/NNNN-kep-template

@kikisdeliveryservice merci pour le reste. Fera s'il est décidé d'être inclus pour 1.20. Merci! :)

Cela ne fera pas partie de la 1.20. Merci beaucoup pour le ping ! :)

Je m'intéresse à ce problème et je voulais remercier @Joseph-Irving et @howardjohn pour leurs idées à ce sujet, qui ont aidé à résoudre certaines de mes questions.

Je ne veux pas détourner cette proposition, mais sur la base des conversations ci-dessus, je me demande s'il s'agit peut-être d'un problème légèrement plus large/plus vaste que celui qui a été reconnu jusqu'à présent.

Je peux imaginer les solutions suivantes à ce problème -

1. Définissez une nouvelle entité de conteneur "conteneur side-car" qui commence après initContainers, avant "conteneurs principaux" et se termine après la fin des "conteneurs principaux" (conformément à la proposition originale de @Joseph-Irving)
2. Définissez un champ supplémentaire sur (1) qui définit si le "conteneur side-car" commence avant le ou les initContainer selon la suggestion @luksa ).
3. Allez plus loin.

Personnellement, l'option (2) résout mon problème immédiat.

Mais je me demande si ces questions ne parlent pas d'un problème plus stratégique dans les K8 concernant la planification et la façon dont nous définissons un pod. Dans mon cas spécifique (lié à Istio) , j'ai suggéré quelque chose comme des niveaux d'exécution dans les pods.

L'option (2) résout également mon problème, mais je peux imaginer des structures de dépendances encore plus complexes qui pourraient nécessiter l'intégration d'un DAG de dépendances de conteneurs dans un pod/statefulSet/daemonSet/whatever - c'est l'option (3) à laquelle je pense.

Vous vous demandez simplement si ce problème devrait vraiment être recentré sur la définition du pod lui-même, dans l'optique de créer quelque chose de plus générique ? Je pensais à l'origine en termes d'analogie avec les niveaux d'exécution, mais peut-être qu'une structure DAG de type Airflow aurait l'applicabilité la plus large.

Qu'en est-il également de l'ajout d'envoy en tant que conteneur d'initialisation ? De cette façon, il fournira un réseau pour d'autres conteneurs d'initialisation. Lorsque init se terminera, il « quittera 0 » également, puis l'envoyé régulier (pas init) prendra le relais

@michalzxc Si je ne me trompe pas, les conteneurs d'initialisation sont exécutés un par un de manière séquentielle, vous ne pouvez donc actuellement pas avoir d'envoyé à côté d'un autre conteneur en tant que init-container .

Salut!

La discussion parallèle s'est poursuivie sur ces lieux (j'ai mis à jour sig-node slack, github PR qui a démarré cela et plusieurs listes de diffusion):
https://groups.google.com/g/kubernetes-sig-node/c/w019G3R5VsQ/m/bbRDZTv5CAAJ
https://groups.google.com/g/kubernetes-sig-node/c/7kUaX-jBN3M/m/dhI3E8LOAAAJ

Comme vous pouvez le voir, nous collectons maintenant des cas d'utilisation, après avoir eu quelques cas d'utilisation supplémentaires, différents petits groupes peuvent créer des pré-propositions pour les traiter. N'hésitez pas à ajouter votre cas d'utilisation (si ce n'est pas encore là) ou à rejoindre plus tard pour la partie pré-propositions :-)

S'il vous plaît, gardons ce problème d'amélioration sur le sujet (et probablement fermé). Vous êtes invités à rejoindre la conversation sur ces lieux :)

Ce KEP ne progressera pas, Sig-node et d'autres pensent qu'il ne s'agit pas d'un pas incrémental dans la bonne direction, ils sont donc revenus à la planche à dessin et proposeront de nouveaux KEP qui, espérons-le, pourront résoudre toutes les utilisations. cas mentionnés dans ce KEP ainsi que d'autres.

S'il vous plaît voir @rata « s commentaire précédent https://github.com/kubernetes/enhancements/issues/753#issuecomment -707014341
Pour les endroits où vous pouvez contribuer à la discussion.

Il est regrettable que tout le travail effectué sur ce KEP ne soit pas utilisé, mais un groupe plus large de personnes réfléchit maintenant à ces problèmes, donc j'espère que la solution qu'ils trouveront sera la meilleure pour tout le monde.
J'ai déjà passé plus de deux ans à essayer de faire passer cela, donc je pense que c'est le bon moment pour moi d'aller de l'avant, @rata et d'autres

/proche

@Joseph-Irving : Clôture de ce problème.