Reprise du message précédent :
Ton service est bien attaché aux pods ?

Faudrait le yaml complet pour vraiment t’aider !

Ca va être compliqué malheureusement, je ne peux pas c/c le yaml ici... Il faudrait que je réécrive l'intégralité du déploiement, du service, des valeurs..

Inspect alors

Essayes un kubectl port-forward pour être certain que ton service réponds bien en 1er lieu

Je vais voir tout ça et je reviens vers vous, je ne connaissais pas port-forward!

Hello,
 
Je dois passer un GKE public en private, et donc redéployer tout ce qui est dessus (appli client, ingress nginx...)
 
A froid, je me dis qu'il est plus sage de partir sur un nouveau cluster, faire les déploiements, et une fois le tout validé, faire une bascule de l'ip static.
 
Sur le papier, rien de bien compliqué, mais vu que j'ai jamais fait cela, il doit bien y avoir des trucs à la con auxquels je ne pense pas et qui vont me faire chier
 
Sinon une autre solution ?
 
Merci
++

 
Tu fais un nouveau déploiement de nginx avec un LB privé.
Nouvelle entre dns dessus, tu test si c’est bon, bascule de ton ancien dns vers la nouvelle Ip privée  
 
Tu peux rester avec le 2, ça peut être utile de pouvoir faire des ingress public pour le monitoring
 
Je trouve ça overkill de refaire le cluster.
 
Sinon solution rapide mais coupure de service, tu ajoutes juste l’annotation sur le LB et mise à jour du dns

Ha mais ce n'est pas que l'ingress, mais tout le cluster a passer en mode private pour éviter d'avoir des IP pub sur chaque node.

De plus , on doit installer des runner gitlab dans le kube, et ils devront pouvoir se connecter a l'API kube. (Avec whitelistage d'ip)

En mode private on pourra les faire attaquer la private IP endpoint.

Oui effectivement c'est peut être plus simple de refaire un cluster pour tester.
 
Les noeuds en public c'est pas bien    
 
Dans mon setup:
Les noeuds sont privés
L'ingress, tu as le choix* en tant que utilisateur en fonction de l'annotation
L'API kube est public, dev dans le monde entier, filtrer sur une liste d'IP c'est compliqué, par contre audit et double authentification
 
Si public, tu es obligé d'activer notre CDN, anti-ddos, etc... sinon tu es bloqué par le firewall

Ha mais oui je suis d'accord pour les noeuds en public, d'ou le fait de le réinstaller
 
Ca se passe comment pour les disk persistent pour une migration de cluster ?
Il y a moyen de les détacher et les récupérer ?
 
++

 
Velero sera ton ami
Tu va te galérer à récupérer… et faut faire des apps cloud native  

Salut à tous, bon le topic est pas très actif mais on sait jamais.
 
J'ai un soucis un peu bête, je suis sur kubernetes et me sert d'un ingress controlleur Traefik. jusque là rien de très compliqué, j'ai aussi lancer des filebeat en RS pour recuperer les logs de tous les "workers" sur un graylog . Là aussi pas de soucis ca fonctionne. Seulement voilà, dans les logs traefik, des acces web apache/nginx surtout, je n'ai pas de status code...qui pourtant m’intéresse fortement... Mon traefik est pourtant en mode debug et à priori de base il devrait y avoir les status code, donc là je sèche un peu.... je lance le traefik en helm chart en surchargeant juste ces options:
 
additionalArguments:
  - "--log.level=DEBUG"
  - "--entrypoints.websecure.http.tls"
  - "--providers.kubernetesIngress.ingressClass=traefik-cert-manager"
  - "--ping"
  - "--metrics.prometheus"
  - "--providers.kubernetesingress=true"
  - "--accesslog=true"
  - "--accesslog.filepath=/var/log/traefik/access.log"
  - "--accesslog.bufferingsize=100"
  - "--accesslog.format=json"
 
 
Merci d'avance en tout cas et bonne journée!

 
 
Je drap.  
 
Je commençais à très bien maitriser Docker quand au boulot maintenant on gère tout avec un cluster K8s (géré sur Gcloud).  
Alors je sais pas si c'est moi ou pas, mais j'ai l'impression que c'est d'une complexité sans nom.  
Les tuto sur le net te montrent des commandes où tu appliques des yaml à distance, sans même savoir ce qu'il y a dedans, super. Y'a un tas d'opérations opaques. Et les fichiers qui contiennent des tonnes de lignes commentées.
Le nombre de choses à déployer pour certaines applications est faramineux j'ai l'impression.  
 
Ca fait pas longtemps que j'ai commencé, je merdouille déjà pas mal. J'espère pouvoir avoir une formation solide rapidement car ça va pas être gérable du tout.
 
J'ai réussi à déployer une application via Helm (netbox) je ne sais pas trop comment j'ai réussi. Bon ça fonctionne mais j'ai vraiment du mal à piger comment. Maintenant j'ai des soucis avec l'application car elle est utilisée en mode insecure, j'ai mis un loadbalancer devant mais sans HTTPS.  
Là je regarde comment mettre un nginx https devant mais je m'y perd totalement. DigitalOcean à un tutorial assez complet, mais encore, on applique sans réfléchir un fichier distant qui te créer une dizaine d'objets différents sans t'expliquer ce qu'il y a dedans et j'aime pas ça.

Bah c'est pas magique ouais, lis de la doc et évite de suivre des tutos a l'aveugle

Quand je suis les tuto, j'aime bien connaitre ce que fais chaque lignes, c'est pour ça que y'a énormément de tuto que je n'applique pas.

Petite question d'ailleurs, il y a un service que nous perdons au boulot, souvent le soir en weekend.
Si je vais regarder le cluster (un GKE), c'est un service qui est déployé de type "Pod".

On est d'accord qu'il tombe car il y a une update sur GKE et le pod n'est pas automatiquement remonté ?
Dans les logs j'ai l'impression que cela arrive à chaque update système, même si ce n'est pas super clair.
 Il faudrait plutôt utilisé un objet "deployment" ou "statefulset" ?

 
Sur GKE dans les logs tu as l'informations si c'est bien un update qui casse ton pod... tu peux regarder la date de création du nouveau noeud en version simple.
Si c'est juste un pod avec une app web par exemple, il te faut un deployment avec 3 replica mini, liveness, readiness, et anti-affinity pour être sur que tes 3 pods ne sont pas sur le même noeud. C'est assez bien expliqué dans la doc Kubernetes tous ça.

Hello,
 
Petite question Cronjobs k8s.
 
- mon job se lance via la cronjob, un pod est démarré et commence a faire son taf (export base mysql)
- le node qui fait tourner le pod est supprimé puis recréé (gke auto update ou repair est passé par la)
- mon pod est kill (normal)
- mais mon job est tjrs en mode "running" (le timer de Duration continue de s'incrémenter), et ce dernier ne passe donc pas en erreur, afin de déclencher une alerte monitoring.
 
 
Pods Statuses:  0 Running / 0 Succeeded / 0 Failed  
 
Mais il n'y a plus de pod qui tourne pour ce job...
 
 
Comment éviter cela ?

Drap

 
Tu peux poster le yaml ? Reflexe à prendre ici    
ça fait pas le taff le activeDeadlineSeconds ?
 

 
Edit: creuse plutôt ça: https://kubernetes.io/docs/concepts [...] finalizers

Drap

Y a un intérêt en prod sur un cluster private gke d'avoir des svc en nodeport a la place de clusterIP ?

Pas d'accès interne, les services sont exposés avec un GLB

J'avoue j'ai pas d'usage en tête si ce n'est optimiser la latence sur certains cas d'usage vraiment a la marge.

Any retour d'exp sur ceph avec rook ?
 
Le k8s sera sur GCP (gke donc) et la solution filestore est trop chère.

 
Ça fait le café, regarde longhorm aussi, mais c’est pas très Cloud native ça  

Qu'est ce qui n'est pas trés cloud native ? Le fait d'avoir besoin de stockage persistant et que l'appli ne sait pas faire de l'object sur un GCS ?
 
Pour longhorm, tu conseil de lui dédier un node pool (avec ssd) ?
 
Bon j'essaye de l'installer sur k3s mais ça ne passe pas
 
(combined from similar events): Error: failed to generate container "2234bdc0604507f28dd32f86ec64eb6a18c253494dadb9f230e207ddc2173236" spec: failed to generate spec: path "/var/lib/longhorn/" is mounted on "/" but it is not a shared mount
 
Je ne sais pas si c'est parceque les nodes sont sous alpine
 
Edit : https://www.claudiokuenzler.com/blo [...] ared-mount
 
Piouuuuuu fallait la trouver celle-là, je ne connaissais pas ce mount --make-shared /

Bon au final longhorm, faut installer des dépendances sur les nodes.
Comment tu gères ça sur un GKE, sachant que les nodes sont "éphéméres" ?

 
Rook ou longhorm c'est pareil, il faut RBD module, donc pas de COS mais un OS Ubuntu.  
Après je ne l'utilise pas au quotidien, aucune pertinence de data dans les clusters chez moi (hors cache).

yes et il faut aussi les packages iscsi.
 
Au final pas sur que ce soit la meilleure solution pour gérer le stockage.
 
Reste le NFS, mais dans du k8s je n'ai jamais testé

Tu peux faire du cloud storage fuse mais j’aime pas.
Encore une fois essaye de ne pas en avoir besoin dans ton apps, tu mets quoi dedans ?

Ce n'est pas moi le dev de l'app et je n'ai pas encore plus d'info sur les specs.
 
Je sais que ce sera du nodejs en front et magento en back
 
Je ne connais pas le volume de persistant data.
 
Donc j'anticipe et je regarde ce qui pourrait être bien à mettre en place ^^

Une solution éprouvée pour créer des secrets k8s avec un contenu venant de GCP secret-manager et le tout avec helm/argocd ?

 
Si il y en a parmi vous qui sont entrain de se préparer pour le CKA, CKAD, CKS, KCNA w/e, KodeKloud offre un accès gratuit à toutes leurs formations et exercices pendant une semaine.  
https://pages.kodekloud.com/free-week

Tiens petite question ici, on ne sait jamais
 
J'ai installé des runner github sur un GKE.
 
Pod avec request CPU de 500 et pas de limite, et 4G de RAM en limite/request
 
J'ai aussi mis en place de l'autoscalling.
 
Techniquement, ça fonctionne, le HPA est peut être un poil long à scaler mais ça fait le taf.
 
Par contre, niveau performance, c'est assez catastrophique. Sur un workload de 20 job on passe de 10mn sur les runner github a 20 mn sur les runners GKE
 
En worker j'ai de la n2-standard-8 (8vcpu/32Go de ram), et pareil le scaling des worker fonctionne correctement.
 
Qu'est ce qui peut expliquer que l'on fait X2 sur le traitement ?
 
Chez github, les runners sont sur des VM (avec docker et 2vcpu et 7Go de ram), est ce que ça viendrait de cela ? On a une VM dédiée pour un runner et on donc pas de partage de CPU comme sur un worker K8s ?
 
Si vous avez des pistes d'optmisation, je suis preneur
 
 
 

Quelle est l'utilisation CPU/ram des nodes ?

 
Et bien le CPU est asez sollicité, ce qui me semble normal, vu qu'on lui balance pas mal de gros traitement
 
Il faudrait presque réussir à pouvoir limiter le nombre de pod sur le node pour éviter de trop le charger et avoir de la contention au niveau du CPU.
 
Peut être en augmentant la memory request/limit afin de le forcer a scaler un node.
Mais bon, ce n'est financièrement plus très économique.

Bon j'ai testé avec des machines avec 16vcpu et 16Go de ram afin de ne pas trop les charger et au final je gagne 3-4 min.
Avec des pods a 4Go de ram, ça scale vite les nodes, donc j'ai du cpu dispo !
 
Il doit y avoir une contention ailleurs, docker peut être.

Nouvelle approche:  
 
20 nodes , 20 runners (1 par node)
le tout sur des serveur preemptible, et je coupe tout ce petit monde le soir pour le remettre en route le matin.
 
Autoscalling désactivé, sinon ça fait chier pour le resize à 0.
 
Avec un runner par node gke, les perfs sont pas trop mal, avec des nodes équivalentes à ce que propose github (2vcpu et 8Go de ram)

Question déploiement,
 
Mes dev font actuellement du kubectl apply pour déployer leur manifests (dans une pipeline).
Le problème est que si ils suppriment des manifests, l'apply ne va pas le supprimer sur le k8s et on se retrouve avec des pods/jobs fantômes.
 
La solution serait de passer par un vrai tools de déploiement, mais je ne connais que Helm qui pourrait répondre au besoin.
Avez-vous en tête d'autres tools ou solution, sans passer par une usine à gaz (argocd) pour ce cas de figure ?
 
++

Tu les stocks comment les manifests ? sur git ?
 
Le plus simple ça reste flux ou argocd pour sync, tu peux utiliser la version namespace de ArgoCD si tu veux pas gérer ça dans un cluster, etc...
 
Sinon il faudrait lister les fichiers delete puis kubectl delete dans ton pipeline...

Les manifests sont modifiés à la volé à coup de sed.
Quand j'ai vu ça, je suis parti direct sur helm au final.

J'ai juste a adapter les variables dans les manifests et les passer en --set lors du helm upgrade.
Et je vais pouvoir virer cette vilaine step qui fait des sed