|
Ce document a été traduit à l'aide d'une technologie de traduction automatique. Bien que nous nous efforcions de fournir des traductions exactes, nous ne fournissons aucune garantie quant à l'exhaustivité, l'exactitude ou la fiabilité du contenu traduit. En cas de divergence, la version originale anglaise prévaut et fait foi. |
FAQ technique
Comment puis-je réinitialiser le mot de passe administrateur ?
Installation de Docker :
$ docker exec -ti <container_id> reset-password New password for default administrator (user-xxxxx): <new_password>
Installation de Kubernetes (Helm) :
$ KUBECONFIG=./kube_config_cluster.yml
$ kubectl --kubeconfig $KUBECONFIG -n cattle-system exec $(kubectl --kubeconfig $KUBECONFIG -n cattle-system get pods -l app=rancher --no-headers | head -1 | awk '{ print $1 }') -c rancher -- reset-password
New password for default administrator (user-xxxxx):
<new_password>
Installation de Kubernetes (Helm - Applicable à Rancher Prime v2.13.1) :
$ KUBECONFIG=./kube_config_cluster.yml
$ kubectl --kubeconfig $KUBECONFIG -n cattle-system exec $(kubectl --kubeconfig $KUBECONFIG -n cattle-system get pods -l app=rancher-prime --no-headers | head -1 | awk '{ print $1 }') -c rancher-prime -- reset-password
New password for default administrator (user-xxxxx):
<new_password>
J’ai supprimé/désactivé le dernier administrateur, comment puis-je y remédier ?
Installation de Docker :
$ docker exec -ti <container_id> ensure-default-admin New default administrator (user-xxxxx) New password for default administrator (user-xxxxx): <new_password>
Installation de Kubernetes (Helm) :
$ KUBECONFIG=./kube_config_cluster.yml
$ kubectl --kubeconfig $KUBECONFIG -n cattle-system exec $(kubectl --kubeconfig $KUBECONFIG -n cattle-system get pods -l app=rancher | grep '1/1' | head -1 | awk '{ print $1 }') -- ensure-default-admin
New password for default administrator (user-xxxxx):
<new_password>
Installation de Kubernetes (Helm - Applicable à Rancher Prime v2.13.1) :
$ KUBECONFIG=./kube_config_cluster.yml
$ kubectl --kubeconfig $KUBECONFIG -n cattle-system exec $(kubectl --kubeconfig $KUBECONFIG -n cattle-system get pods -l app=rancher-prime | grep '1/1' | head -1 | awk '{ print $1 }') -- ensure-default-admin
New password for default administrator (user-xxxxx):
<new_password>
Mon ClusterIP ne répond pas au ping
ClusterIP est une IP virtuelle, qui ne répondra pas au ping. Le meilleur moyen de tester si le ClusterIP est configuré correctement est d’utiliser curl pour accéder à l’IP et au port afin de voir s’il répond.
Où puis-je gérer les modèles de nœuds ?
Les modèles de nœuds sont accessibles en ouvrant votre menu de compte (en haut à droite) et en sélectionnant Node Templates.
Pourquoi mon équilibreur de charge de couche 4 est-il dans l’état Pending ?
L’équilibreur de charge de couche 4 est créé en tant que type: LoadBalancer. Dans Kubernetes, cela nécessite un fournisseur de cloud ou un contrôleur capable de satisfaire ces demandes, sinon ils resteront dans l’état Pending indéfiniment. Plus d’informations peuvent être trouvées sur Fournisseurs de cloud ou Créer un équilibreur de charge externe
Où l’état de Rancher est-il stocké ?
-
Installation de Docker : dans l’etcd intégré du conteneur
rancher/rancher, situé à/var/lib/rancher. -
Installation de Kubernetes : l’emplacement par défaut se trouve dans les répertoires
/var/lib/rancher/rke2ou/var/lib/rancher/k3sdu cluster RKE2/K3s respectif créé pour exécuter Rancher.
Comment les versions Docker prises en charge sont-elles déterminées ?
Nous suivons les versions Docker validées pour les versions Kubernetes en amont. Les versions validées peuvent être trouvées sous Dépendances externes dans le CHANGELOG.md de la version Kubernetes.
Comment puis-je accéder aux nœuds créés par Rancher ?
Les clés SSH pour accéder aux nœuds créés par Rancher peuvent être téléchargées via la vue Nœuds. Choisissez le nœud auquel vous souhaitez accéder et cliquez sur le bouton vertical ⋮ à la fin de la ligne, puis choisissez Télécharger les clés comme indiqué dans l’image ci-dessous.
Décompressez le fichier zip téléchargé et utilisez le fichier id_rsa pour vous connecter à votre hôte. Assurez-vous d’utiliser le bon nom d’utilisateur (rancher ou docker pour RancherOS, ubuntu pour Ubuntu, ec2-user pour Amazon Linux)
$ ssh -i id_rsa user@ip_of_node
Comment puis-je automatiser la tâche X dans Rancher ?
L’interface utilisateur se compose de fichiers statiques et fonctionne en fonction des réponses de l’API. Cela signifie que chaque action/tâche que vous pouvez exécuter dans l’interface utilisateur peut être automatisée via l’API. Il y a 2 façons de faire cela :
-
Visitez
https://your_rancher_ip/v3et parcourez les options de l’API. -
Capturez les appels API lors de l’utilisation de l’interface utilisateur (le plus couramment utilisé pour cela est Outils de développement Chrome, mais vous pouvez utiliser ce que vous voulez)
L’adresse IP d’un nœud a changé, comment puis-je récupérer ?
Un nœud doit avoir une adresse IP statique configurée (ou une adresse IP réservée via DHCP). Si l’IP d’un nœud a changé, vous devrez le retirer du cluster et le réajouter. Après sa suppression, Rancher mettra à jour le cluster pour le ramener à l’état correct. Si le cluster n’est plus dans l’état Provisioning, le nœud est retiré du cluster.
Lorsque l’adresse IP du nœud a changé, Rancher a perdu la connexion avec le nœud, il ne pourra donc pas nettoyer le nœud correctement. Voir Nettoyage des nœuds du cluster pour nettoyer le nœud.
Lorsque le nœud est retiré du cluster et que le nœud est nettoyé, vous pouvez réajouter le nœud au cluster.
Comment puis-je ajouter plus d’arguments/liaisons/variables d’environnement aux composants Kubernetes dans un cluster Kubernetes lancé par Rancher ?
Vous pouvez ajouter plus d’arguments/liaisons/variables d’environnement via le Fichier de configuration RKE2 ou Fichier de configuration K3s.
Comment vérifier si ma chaîne de certificats est valide ?
Utilisez la commande openssl verify pour valider votre chaîne de certificats :
|
Configurez |
SSL_CERT_DIR=/dummy SSL_CERT_FILE=/dummy openssl verify -CAfile ca.pem rancher.yourdomain.com.pem rancher.yourdomain.com.pem: OK
Si vous recevez l’erreur unable to get local issuer certificate, la chaîne est incomplète. Cela signifie généralement qu’il y a un certificat CA intermédiaire qui a émis votre certificat de serveur. Si vous avez déjà ce certificat, vous pouvez l’utiliser dans la vérification du certificat comme indiqué ci-dessous :
SSL_CERT_DIR=/dummy SSL_CERT_FILE=/dummy openssl verify -CAfile ca.pem -untrusted intermediate.pem rancher.yourdomain.com.pem rancher.yourdomain.com.pem: OK
Si vous avez vérifié avec succès votre chaîne de certificats, vous devez inclure les certificats CA intermédiaires nécessaires dans le certificat de serveur pour compléter la chaîne de certificats pour toute connexion établie avec Rancher (par exemple, par l’agent Rancher). L’ordre des certificats dans le fichier de certificat de serveur doit d’abord être le certificat de serveur lui-même (contenu de rancher.yourdomain.com.pem), suivi des certificats CA intermédiaires (contenu de intermediate.pem).
-----BEGIN CERTIFICATE----- %YOUR_CERTIFICATE% -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- %YOUR_INTERMEDIATE_CERTIFICATE% -----END CERTIFICATE-----
Si vous obtenez toujours des erreurs lors de la vérification, vous pouvez récupérer le sujet et l’émetteur du certificat de serveur en utilisant la commande suivante :
openssl x509 -noout -subject -issuer -in rancher.yourdomain.com.pem subject= /C=GB/ST=England/O=Alice Ltd/CN=rancher.yourdomain.com issuer= /C=GB/ST=England/O=Alice Ltd/CN=Alice Intermediate CA
Comment vérifier Common Name et Subject Alternative Names dans mon certificat de serveur ?
Bien qu’une entrée dans Subject Alternative Names soit techniquement requise, avoir le nom d’hôte à la fois dans Common Name et comme entrée dans Subject Alternative Names vous donne une compatibilité maximale avec les anciens navigateurs/applications.
Vérifiez Common Name :
openssl x509 -noout -subject -in cert.pem subject= /CN=rancher.my.org
Vérifiez Subject Alternative Names :
openssl x509 -noout -in cert.pem -text | grep DNS
DNS:rancher.my.org
Pourquoi faut-il plus de 5 minutes pour qu’un pod soit reprogrammé lorsqu’un nœud a échoué ?
Cela est dû à une combinaison des paramètres par défaut de Kubernetes suivants :
-
kubelet
-
node-status-update-frequency: Spécifie la fréquence à laquelle kubelet publie l’état des nœuds au maître (par défaut 10s)
-
-
kube-controller-manager
-
node-monitor-period: La période de synchronisation de NodeStatus dans NodeController (par défaut 5s) -
node-monitor-grace-period: Durée pendant laquelle nous permettons à un nœud en cours d’exécution d’être non réactif avant de le marquer comme non sain (par défaut 40s) -
pod-eviction-timeout: La période de grâce pour supprimer les pods sur les nœuds échoués (par défaut 5m0s)
-
Voir Kubernetes: kubelet et Kubernetes: kube-controller-manager pour plus d’informations sur ces paramètres.
Dans Kubernetes v1.13, la fonctionnalité TaintBasedEvictions est activée par défaut. Voir Kubernetes: évictions basées sur les Taints pour plus d’informations.
-
kube-apiserver (Kubernetes v1.13 et supérieur)
-
default-not-ready-toleration-seconds: Indique les tolerationSeconds de la tolérance pour notReady:NoExecute qui est ajoutée par défaut à chaque pod qui n’a pas déjà une telle tolérance. -
default-unreachable-toleration-seconds: Indique les tolerationSeconds de la tolérance pour unreachable:NoExecute qui est ajoutée par défaut à chaque pod qui n’a pas déjà une telle tolérance.
-