Problèmes connus

Champ d'application et fonctionnalités du bac à sable Google Distributed Cloud (GDC) :

  • Persistance : le bac à sable GDC n'est pas persistant et est actualisé de manière incrémentielle tous les mois. Lorsque les environnements sont actualisés, ils sont rétablis à leur état par défaut, ce qui signifie que vous devez redéployer vos configurations. Il est recommandé d'enregistrer vos configurations, votre code et vos conteneurs dans un dépôt de code, ce qui permet également de passer d'un développement de faible à forte intensité dans des environnements de production.
  • Ressources : cette version limite la quantité des ressources suivantes :
    • Une organisation.
    • Un locataire.
    • Deux clusters Kubernetes.
  • Utilisateurs : pour garantir une utilisation adéquate des ressources partagées, les utilisateurs sont limités à 25 au maximum.
  • Données sensibles : les utilisateurs doivent accepter le CLUF avant d'accéder au bac à sable GDC. Nous vous recommandons de ne pas utiliser le bac à sable GDC pour les données sensibles ni les charges de travail de production, car il est destiné à des fins de test, de développement et de formation.
  • Expérience d'E/S : le bac à sable GDC n'est compatible qu'avec l'expérience de l'opérateur d'application (AO) ou de la persona utilisateur final du bac à sable GDC.

Problèmes connus :

  1. L'état de la stratégie réseau du projet est toujours affiché comme Not Read dans l'interface utilisateur, quel que soit son état. Utilisez l'API ou la CLI pour vérifier l'état réel.

  2. Si les étapes mentionnées dans Accéder à l'environnement pour installer des certificats n'ont pas encore été suivies, l'erreur suivante s'affiche lors de l'importation d'un fichier dans un bucket (stockage d'objets) : Check network speed to ensure your file size is within limits and certificates are properly set. Vous pouvez installer les certificats ou suivre cette solution de contournement :

    1. Dans le navigateur de votre bac à sable GDC, ouvrez la page Web https://objectstorage.org-1.zone1.google.gdch.test et acceptez le certificat.
    2. Réessayez d'importer le fichier.
    3. Si vous rencontrez toujours des problèmes tels que ErrPresignSignatureNotRecognized, essayez de désactiver la validation TLS à l'aide de gdcloud config set storage/s3_insecure_skip_tls_verify true.

  3. Délai d'expiration de la connexion : l'authentification peut expirer dans l'interface utilisateur et la CLI si l'environnement n'est pas utilisé pendant quelques minutes.

    1. Pour le délai d'expiration de l'interface utilisateur : videz le cache du navigateur et actualisez-le.
    2. Pour le délai d'expiration de gdcloud : reconnectez-vous. Consultez la section Se connecter à l'instance.

  4. La seule classe de stockage compatible pour la création d'objets PersistentVolumeClaim est standard-rwo: ReadWriteOnce. La classe de stockage standard-rwx: ReadWriteMany n'est pas compatible.

  5. Une fois que vous avez défini auth/login_config_cert_path à l'aide de gdcloud config set, la valeur est supprimée après l'exécution de gdcloud auth login. Pour contourner ce problème, ajoutez toujours --login-config-cert=/tmp/org-1-web-tls-ca.cert lors de l'exécution de gdcloud auth login.

  6. Impossible de lancer Chrome après la connexion à RDP. Essayez la solution de contournement suivante :

    1. Supprimez ~/.local/share/keyrings.
    2. Lancez Chrome avec la commande :
    /opt/google/chrome/google-chrome --password-store=basic

  7. Si le rôle d'administrateur IAM de l'organisation est supprimé de l'utilisateur fop-platform-admin@example.com, il ne peut pas être réattribué et l'utilisateur perdra l'accès à la plupart des fonctionnalités. Dans ce cas, contactez l'assistance du bac à sable GDC.

  8. Le navigateur Web ne s'ouvre pas sur l'instance de passerelle. Cause probable : la passerelle manque d'espace disque. Dans la plupart des cas, l'espace est surchargé de conteneurs, de volumes et d'images en attente. Essayez la solution suivante pour libérer de l'espace :

    docker images prune -a
docker volumes prune
docker containers prune

  9. Les tentatives de connexion à la machine virtuelle (VM) à l'aide de gcloud compute ssh échoueront. Utilisez plutôt sshuttle, comme décrit dans Se connecter à une VM.

  10. Si l'authentification du compte de service échoue avec dial tcp: lookup service-accounts.org-1.google.gdch.test on with no such host, remplacez token_uri par https://service-accounts.org-1.zone1.google.gdch.test/authenticate dans le KEY_FILE contenant les identifiants par défaut de l'application.

  11. Les hôtes GPU maintiennent une isolation architecturale du reste de l'écosystème. Les services du plan de données (tels que DBS et Object Storage) et les VM à usage général sont explicitement exclus de l'accès aux ressources sur lesquelles les charges de travail GPU s'exécutent.

  12. Les journaux d'audit du bac à sable ne sont disponibles que temporairement après le provisionnement ou l'actualisation du bac à sable. Officiellement, la journalisation d'audit dans le bac à sable n'est pas un cas d'utilisation compatible, car il s'agit d'une fonctionnalité de persona PA / IO, et l'objectif du bac à sable est d'aider à tester la persona AO.

    1. Pour contourner ce problème, actualisez ou reprovisionnez l'environnement de bac à sable afin de rétablir temporairement l'accès aux journaux d'audit, ou effectuez un redémarrage progressif du StatefulSet :

      kubectl rollout restart statefulset -n obs-system audit-logs-loki-io