You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 31, 2024. It is now read-only.
Pour éviter les problèmes liées au load balancing, ingress et aux PVCs, j'ai choisi de tenter le déploiement des charts helm dans un envrionnement cloud: scaleway.
Après création du cluster kubernetes, et d'une VM de travail, je me logué sur le dernier puis installé un certain nombre d'outils:
kubectl pour interagir avec le cluster k8s
helm pour installer les charts afin d'installer les différents composantes d'un connecteur fiware
l'utilitaire "yq", utilisé par le script generate.sh (mentionné plus tard)
Note: j'appelle la release fc1 ainsi que le namespace dans lequel créer les composantes, puis avec --set, je specifie le déploiement se fait avec helm (pas avec argo).
J'ai aussi changé les valeurs, me référant à l'exemple service-provider-ips, voici le résultat:
Code
$ helm install -n fc1 fc1 dsc/data-space-connector --create-namespace -f examples/service-provider-ips/values-dsc.yaml --set argoApplications=false
W0417 13:33:43.276530 8200 warnings.go:70] annotation "kubernetes.io/ingress.class" is deprecated, please use 'spec.ingressClassName' instead
W0417 13:33:43.283632 8200 warnings.go:70] annotation "kubernetes.io/ingress.class" is deprecated, please use 'spec.ingressClassName' instead
W0417 13:33:43.283651 8200 warnings.go:70] annotation "kubernetes.io/ingress.class" is deprecated, please use 'spec.ingressClassName' instead
W0417 13:33:43.312711 8200 warnings.go:70] annotation "kubernetes.io/ingress.class" is deprecated, please use 'spec.ingressClassName' instead
W0417 13:33:43.312751 8200 warnings.go:70] annotation "kubernetes.io/ingress.class" is deprecated, please use 'spec.ingressClassName' instead
Error: INSTALLATION FAILED: failed post-install: 1 error occurred:
* timed out waiting for the condition
J'ai attendu pendant un dizaine de minutes pensant que ce problème allait se résoudre tout seul (je me suis dit que peut être que les probes étaient trop optimistes), cependant rien n'a changé entre temps.
Essai 2
Quand cet exemple a echoué, j'ai exécuté le script generate.sh pour constituer les charts en local, mais pour ça j'ai du ajouter un certain nombre de dépôts helm:
J'ai cru en premier que le problème était dû au fait que je n'ai pas changé les paramètres par default des charts, ce qui a provoqué le disfonctionnement observé. En d'autres termes, j'ai supposé que les manifestes kubernetes étaient correctes mais les containers plantaient après le démarrage car les valeurs par défaut ne correspondaient pas à mon environnement de travail (tel que l'adresse du did server dans la composante keycloak).
Mais après avoir investigué avec kubectl (describe, logs, get -o yaml), je me suis rendu compte que c'était dû à des mauvaises configurations kubernetes, en voici la liste :
Objet
Raison
deploy/fc1-mongodb
Could not write in mounted volume (pvc fc1-mongodb) DB directory
StatefulSet/postgresql-dsc
password authentication failed for user "postgres"
deploy/fc1-activation-service
for both volumes "ccs-init-volume" and "config-volume" : attempt to mount volume from CM that does not exist
deploy/fc1-dsba-pdp
for volume "ishare-secret": secret used to create volume does not exist
StatefulSet/fc1-keycloak
failed for multiple volumes (did-config, profiles, did-secret), because related CMs / secrets not found
Job/fc1-keycloak-keycloak-config-cli
no idea
deploy/fc1-vcwaltid-certs
for volume "certs": secret used to create volume does not exist
StatefulSet/keyrock-dsc
secret "vcwaltid" not found
Pour la plupart de sont des volumes qui ne peuvent pas être montés car les secrets / configmaps dont ils dépendent n'existent pas.
Pour le StatefulSet postgres, étrangement c'est un problème d'identifiants.
Pour le déploiement mongo, c'est un problème de doit d'écriture dans une volume monté dedans.
comment dois-je procéder pour arriver à déployer le chart?
J'ai cru lire dans le dépôt qui documente le connecteur que des certificats EiDAS étaient nécessaire. Pourquoi donc y a-t-il les charts prévoient-ils cert-manager?
Qu'est ce qui manque pour faire marcher l'exemple?
I also changed the values, using the service-provider-ips example, this is what I observed:
Code
$ helm install -n fc1 fc1 dsc/data-space-connector --create-namespace -f examples/service-provider-ips/values-dsc.yaml --set argoApplications=false
W0417 13:33:43.276530 8200 warnings.go:70] annotation "kubernetes.io/ingress.class" is deprecated, please use 'spec.ingressClassName' instead
W0417 13:33:43.283632 8200 warnings.go:70] annotation "kubernetes.io/ingress.class" is deprecated, please use 'spec.ingressClassName' instead
W0417 13:33:43.283651 8200 warnings.go:70] annotation "kubernetes.io/ingress.class" is deprecated, please use 'spec.ingressClassName' instead
W0417 13:33:43.312711 8200 warnings.go:70] annotation "kubernetes.io/ingress.class" is deprecated, please use 'spec.ingressClassName' instead
W0417 13:33:43.312751 8200 warnings.go:70] annotation "kubernetes.io/ingress.class" is deprecated, please use 'spec.ingressClassName' instead
Error: INSTALLATION FAILED: failed post-install: 1 error occurred:
* timed out waiting for the condition
After waiting for a while (~10 mins), thinking the kubernetes probed might've been too optimistic and issues might just go away, nothing changed.
Attempt 2
When the example failed, I ran the script generate.sh to recreate the charts, and then see if the helm repo was somehow outdated. I had to pull some other repos for that to work, like the following:
First, I thought the issue was related a poor configuration since I just rolled with the default settings in all the values files, not matching at all my work environment.
However, after investgating more with kubectl (describe, logs, get -o yaml), I found out that the problem laid to some misconfiguration of different kubernetes objects, here is a list:
Objet
Raison
deploy/fc1-mongodb
Could not write in mounted volume (pvc fc1-mongodb) DB directory
StatefulSet/postgresql-dsc
password authentication failed for user "postgres"
deploy/fc1-activation-service
for both volumes "ccs-init-volume" and "config-volume" : attempt to mount volume from CM that does not exist
deploy/fc1-dsba-pdp
for volume "ishare-secret": secret used to create volume does not exist
StatefulSet/fc1-keycloak
failed for multiple volumes (did-config, profiles, did-secret), because related CMs / secrets not found
Job/fc1-keycloak-keycloak-config-cli
no idea
deploy/fc1-vcwaltid-certs
for volume "certs": secret used to create volume does not exist
StatefulSet/keyrock-dsc
secret "vcwaltid" not found
Mostly it is about volumes that cannot be mounted because the secrets / configmaps they originate from don't exist.
For the StatefulSet postgres, strangely, it is an issue of wrong credentials.
As for the deployment mongo, it is about permissions to write inside a mounted volume.
English version below
Procédure de déploiement:
OS: Ubuntu 22.04
Kubernetes: v1.29.2
Helm : v3.14.2
Essai 1
Initialement, j'ai suivi les indications du README, à savoir:
Note: j'appelle la release fc1 ainsi que le namespace dans lequel créer les composantes, puis avec --set, je specifie le déploiement se fait avec helm (pas avec argo).
J'ai l'erreur suivante:
J'ai aussi changé les valeurs, me référant à l'exemple service-provider-ips, voici le résultat:
Code
J'ai attendu pendant un dizaine de minutes pensant que ce problème allait se résoudre tout seul (je me suis dit que peut être que les probes étaient trop optimistes), cependant rien n'a changé entre temps.
Essai 2
Quand cet exemple a echoué, j'ai exécuté le script generate.sh pour constituer les charts en local, mais pour ça j'ai du ajouter un certain nombre de dépôts helm:
Code
Ce script m'a généré une application helm dans charts/data-space-connector que j'ai tenté de déployer, voici le résultat:
Code
$ helm install -n fc1 fc1 charts/data-space-connector/ --set argoApplications=false --create-namespace Error: INSTALLATION FAILED: failed post-install: 1 error occurred: * job fc1-keycloak-keycloak-config-cli failed: BackoffLimitExceeded
Débogage
J'ai cru en premier que le problème était dû au fait que je n'ai pas changé les paramètres par default des charts, ce qui a provoqué le disfonctionnement observé. En d'autres termes, j'ai supposé que les manifestes kubernetes étaient correctes mais les containers plantaient après le démarrage car les valeurs par défaut ne correspondaient pas à mon environnement de travail (tel que l'adresse du did server dans la composante keycloak).
Mais après avoir investigué avec kubectl (describe, logs, get -o yaml), je me suis rendu compte que c'était dû à des mauvaises configurations kubernetes, en voici la liste :
Voici la liste de tous les pods :
Code
Mes questions sont les suivantes:
Votre aide serait le bienvenu.
Deployment process:
OS: Ubuntu 22.04
Kubernetes: v1.29.2
Helm : v3.14.2
Attempt 1
Initially, I followed the indications of the README, i.e. :
Note: I named the realase as well as the namespace fc1, and with --set, je specify that helm ought to be used, not argo.
This is the error I observed:
I also changed the values, using the service-provider-ips example, this is what I observed:
Code
After waiting for a while (~10 mins), thinking the kubernetes probed might've been too optimistic and issues might just go away, nothing changed.
Attempt 2
When the example failed, I ran the script generate.sh to recreate the charts, and then see if the helm repo was somehow outdated. I had to pull some other repos for that to work, like the following:
Code
As a result, I managed to get a local helm chart in charts/data-space-connector, that I deployed leading to the following result:
Code
$ helm install -n fc1 fc1 charts/data-space-connector/ --set argoApplications=false --create-namespace Error: INSTALLATION FAILED: failed post-install: 1 error occurred: * job fc1-keycloak-keycloak-config-cli failed: BackoffLimitExceeded
Debugging
First, I thought the issue was related a poor configuration since I just rolled with the default settings in all the values files, not matching at all my work environment.
However, after investgating more with kubectl (describe, logs, get -o yaml), I found out that the problem laid to some misconfiguration of different kubernetes objects, here is a list:
Check out the list of the pods :
Code
My questions are the following:
Your help would be greatly appreciated.
The text was updated successfully, but these errors were encountered: