Résolution des problèmes de configuration de machine virtuelle unique

Echec du pod Gestionnaire des tâches : problème de propriété du stockage

Occasionnellement, après la mise à niveau vers la version 2.0.0 dans un environnement de machine virtuelle unique, le pod Gestionnaire des tâches peut ne pas démarrer. Pour résoudre le problème, procédez comme suit :
  • Si vous avez mis à niveau AppScan 360° avec le script en ligne, exécutez :
    ./AppScan360_SingleVMsetup_v2.0.0.run -- $PWD remediateStorageIssues
  • Si vous avez mis à niveau AppScan 360° avec le script hors ligne, exécutez :
    ./AppScan360_SingleVMsetup_v2.0.0_Offline.run -- $PWD remediateStorageIssues

Problèmes d'extraction d'image de pod

Lors du déploiement d'AppScan 360° dans un environnement Ubuntu à machine virtuelle unique à l'aide d'un registre Docker local, les pods peuvent ne pas démarrer en raison d'erreurs de connexion au registre.

Une erreur type dans les événements de pod peut se présenter comme suit :
Normal   Pulling    60s (x4 over 4m1s)   kubelet            
Pulling image "<ip>:5443/as360-k8s-docker-images/reloader:v1.2.1"
Warning  Failed     30s (x4 over 3m31s)  kubelet            
Failed to pull image 
"<ip>:5443/as360-k8s-docker-images/reloader:v1.2.1": rpc error: code = 
DeadlineExceeded desc = failed to pull and unpack image 
"<ip>:5443/as360-k8s-docker-images/reloader:v1.2.1": failed to resolve 
reference "<ip>/as360-k8s-docker-images/reloader:v1.2.1": failed to do 
request: Head 
"https://<ip>/v2/as360-k8s-docker-images/reloader/manifests/v1.2.1": 
dial tcp <ip>:5443: i/o timeout

Si le message d'erreur contient dial tcp <ip>:5443: i/o timeout, cela indique généralement un problème de connectivité réseau entre votre nœud Kubernetes (conteneur k0s) et le registre Docker.

Pour résoudre le problème, procédez comme suit :

  • Connectez-vous au conteneur k0s et installez les outils de diagnostic :
    docker exec -it k0s sh

  • Testez la connectivité réseau à partir du conteneur :

    • Utilisez netcat pour vérifier la connectivité au registre :
      nc -zv <registry-ip> 5443
    • Si open ne s'affiche pas dans le message, la connexion a échoué, ce qui indique un problème réseau.
    • Essayez d'extraire l'image directement à l'aide de la commande ctr du conteneur :
      k0s ctr images pull --user <user>:<pass> 
<registry-ip>:5443/as360-k8s-docker-images/reloader:v1.2.1
    • Si cela échoue, le problème est probablement lié aux règles de pare-feu.
  • Vérifiez les règles de pare-feu (UFW) et IPTables :
    • Sur l'hôte, inspectez les règles de pare-feu :
      iptables -L -n -v
    • Recherchez les chaînes liées à ufw (pare-feu simple) qui peuvent bloquer le trafic, comme dans l'exemple ci-dessous :
      Chain INPUT (policy DROP 39231 packets, 2148K bytes)
 pkts bytes target     prot opt in     out     source               destination         
6603K 9311M ufw-before-logging-input  all  --  *      *       0.0.0.0/0            
0.0.0.0/0           
6603K 9311M ufw-before-input  all  --  *      *       0.0.0.0/0            
0.0.0.0/0           
 407K   50M ufw-after-input  all  --  *      *       0.0.0.0/0            
0.0.0.0/0           
39311 2154K ufw-after-logging-input  all  --  *      *       0.0.0.0/0            
0.0.0.0/0           
39311 2154K ufw-reject-input  all  --  *      *       0.0.0.0/0            
0.0.0.0/0           
39311 2154K ufw-track-input  all  --  *      *       0.0.0.0/0            
0.0.0.0/0

  • Mettez à jour les règles UFW pour autoriser le trafic réseau Docker sur l'hôte :

    • Autorisez le trafic sur l'interface réseau Docker :
      sudo ufw allow in on docker0
sudo ufw allow out on docker0
    • Autorisez le trafic vers les ports du registre :
      sudo ufw allow out from any to <registry-ip> port 5443 proto tcp
sudo ufw allow out from any to <registry-ip> port 7443 proto tcp

  • Vérifiez la résolution :

    • Exécutez à nouveau les tests de connectivité (netcat, ctr images pull) à partir du conteneur k0s.
    • En cas de succès, les extractions d'image de pod devraient maintenant fonctionner comme prévu.

AppScan 360° ne parvient pas à se connecter à la base de données : échec du déploiement SCA

  • La connexion à la base de données a échoué car l'adresse IP ne se trouvait pas dans la plage de règles réseau
  • Par conséquent, le déploiement SCA échoue également car le déploiement ASCP ne se termine pas correctement
egress:
  - to:
    - namespaceSelector: {}
    - ipBlock:
        cidr: 10.0.0.0/8
    - ipBlock:
        cidr: 192.168.0.0/16
    - ipBlock:
        cidr: 172.16.0.0/12
    - ipBlock:
        cidr: fc00::/7

Procédures d'identification et de résolution des problèmes

  • Vérifier la chaîne/l'adresse IP de connexion à la base de données

Résolution

  • Ajoutez l'adresse IP cidr de la base de données à la règle de sortie de stratégie réseau

Le pod Coredns échoue avec une erreur crashloopbackoff

  • Echec du pod coredns avec une erreur crashloopbackoff dans la configuration du cluster k0s
  • Erreur dans le journal du pod Coredns
maxprocs: Leaving GOMAXPROCS=28: CPU quota undefined 
plugin/forward: no nameservers found 
stream closed: EOF for kube-system/coredns-6946cc8786-q52sw (coredns)

Résolution

  • Ajoutez l'entrée nameserver dans le fichier /etc/resolv.conf de la machine hôte si elle n'est pas présente.
  • Supprimez les pods coredns pour les recréer ensuite.
  • Ou définissez l'entrée nameserver dans un configmap coredns si vous voulez la garder spécifique au cluster et ne pas dépendre du fichier resolv.conf de la machine hôte
   kubectl -n kube-system edit configmap coredns

   # Replace forward . /etc/resolv.conf
   forward . 8.8.8.8 1.1.1.1 # Or specify any specific nameserver applicable for your environment

RHEL : application non accessible au redémarrage de la machine virtuelle

  • Après que vous avez installé AppScan 360° sur une machine virtuelle RHEL, si la machine virtuelle est redémarrée, l'application peut devenir inaccessible et afficher l'erreur « 503 service indisponible » lors de l'accès à l'URL de l'application.
  • Cela est dû aux conteneurs podman qui ont pu être arrêtés et au cluster k0s qui a pu être arrêté.

Résolution

  • Les scripts d'aide sont disponibles dans le kit de configuration de machine virtuelle unique dans le chemin ci-dessous pour démarrer les composants requis.
    # Navigate to aioWorkspace directory
cd <AS360_SETUP_DIRECTORY>/aioWorkspace
# Navigate to utils scripts
cd bin/utils

# Execute script to start podman containers
./startPodmanContainers.sh

# Check if k0s cluster is running, if not start the cluster using below script
k0s status
kubectl get pods -A

# Execute script to start k0s cluster if it is not running
./startK0sOnHost.sh

# Verify if all pods are running
kubectl get pods -A

Problème de réinstallation d'AppScan 360° dans une configuration de machine virtuelle unique avec les pods istio bloqués

  • Lors de la réinstallation d'AppScan 360° dans une configuration de machine virtuelle unique, les pods istio peuvent rester bloqués en attente s'ils n'ont pas été nettoyés correctement lors de la désinstallation.

Résolution

  • Utilisez un script d'aide pour nettoyer les ressources istio, puis poursuivez l'installation.
    # Navigate to aioWorkspace directory
cd <AS360_SETUP_DIRECTORY>/aioWorkspace
# Navigate to utils scripts
cd bin/utils

# Execute script to clean up istio resources
./cleanIstio.sh
  • Essayez ensuite d'installer AppScan 360° à nouveau à l'aide de la commande d'installation.