Le pare-feu empêche l'exécution de commandes via la ligne de commande

Lorsque vous exécutez des commandes ibmcloud, kubectl ou calicoctl depuis l'interface de ligne de commande, ces commandes échouent.

Des règles réseau d'entreprise empêchent peut-être l'accès depuis votre système local à des noeuds finaux publics via des proxys ou des pare-feux.

Autorisez l'accès TCP afin que les commandes CLI fonctionnent.

Cette tâche requiert le rôle d'accès à la plate-forme IAM de l'administrateur IBM Cloud pour le cluster.

Les commandes kubectl ne fonctionnent pas

Lorsque vous exécutez les commandes kubectl sur votre cluster, vos commandes échouent avec un message d'erreur similaire à l'exemple suivant.

No resources found.
Error from server (NotAcceptable): unknown (get nodes)

invalid object doesn't have additional properties

error: No Auth Provider found for name "oidc"

Votre version de kubectl est différente de la version du cluster.

Kubernetes ne prend pas en charge kubectl les versions des clients qui sont éloignées de 2 versions ou plus de la version du serveur (n +/- 2). Si vous utilisez un cluster de communauté Kubernetes, il se peut également que vous disposiez de la version Red Hat OpenShift de kubectl, qui ne fonctionne pas avec les clusters de communauté Kubernetes.

Pour vérifier votre version client de kubectl par rapport à la version du serveur de cluster, exécutez la commande kubectl version --short.

Installez la version de l'interface de ligne de commande qui correspond à la version de votre cluster.

Si vous avez plusieurs clusters avec des versions différentes ou des plateformes de conteneurs différentes telles que Red Hat OpenShift, téléchargez chaque fichier binaire de la version kubectl dans un répertoire séparé. Ensuite, vous pouvez configurer un alias dans votre profil d'interface de ligne de commande locale (CLI) pour qu'il pointe vers le répertoire de fichiers binaires kubectl qui correspond à la version kubectl du cluster que vous souhaitez utiliser, ou vous pouvez utiliser un outil tel que brew switch kubernetes-cli <major.minor>.

Les commandes kubectl dépassent le délai d'attente

Si vous exécutez des commandes de type kubectl exec, kubectl attach, kubectl proxy, kubectl port-forward ou kubectl logs, le message suivant s'affiche :

<workerIP>:10250: getsockopt: connection timed out

kubectl -n kube-system logs metrics-server-65fc69c6b7-f682d -c metrics-server
Error from server: Get “https://10.38.193.213:10250/containerLogs/kube-system/metrics-server-65fc69c6b7-f682d/metrics-server”: EOF

kubectl -n kube-system exec -it metrics-server-65fc69c6b7-f682d -c metrics-server -- sh
Error from server: error dialing backend: EOF

Passez en revue et effectuez les étapes suivantes pour votre version de cluster.

• La version 1.21 et les versions ultérieures de la connexion VPN Konnectivité entre le noeud maître et les noeuds worker ne fonctionnent pas correctement.
• Le cluster inclut des noeuds finaux de service public et privé activés.
• Les noeuds finaux de service ou la fonction VRF ne sont pas activés dans le compte.

Pour déterminer si la fonction VRF et les noeuds finaux de service sont activés dans votre compte, exécutez la commande ibmcloud account show. Recherchez la sortie suivante.

VRF Enabled:                        true
Service Endpoint Enabled:           true

Pour déterminer si le nœud final de service public et privé est activé pour votre cluster classique, exécutez ibmcloud ks cluster get -c <cluster_id>. Recherchez une sortie similaire à la suivante.

Public Service Endpoint URL:    https://c105.<REGION>.containers.cloud.ibm.com:<port>
Private Service Endpoint URL:   https://c105.private.<REGION>.containers.cloud.ibm.com:<port>

Si votre cluster remplit ces conditions, activez les noeuds finaux de service et VRF pour le compte.