Petites requêtes, résultats partagés
De petites pages constituent automatiquement une liste complète. Les caches compacts sont réutilisés et maintenus à jour par des watches.
L’ESPACE DE TRAVAIL POUR VOTRE INFRASTRUCTURE
Kubernetes et Docker.Un seul espace de travail.
Une application de bureau pour les développeurs et les équipes DevOps. Inspectez les ressources Kubernetes, suivez les logs Docker et gérez les releases Helm au même endroit.Sans installer kubectl ni la CLI HelmConnexion directe à l’API Kubernetes. Helm est intégré.
Kubernetes + DockerLes opérations quotidiennes au même endroit
Vos accès existantsKubeconfig et contextes Docker
Helm intégréPas de CLI Helm à installer séparément
Préserve les ressources de votre cluster et de votre ordinateur.
Ocular charge le type de ressource et les namespaces choisis. Il ne collecte pas en arrière-plan toutes les ressources et leurs descriptions complètes.
Une charge encadrée
La concurrence, la fréquence des requêtes et la conservation des caches inutilisés sont limitées. Une requête All Namespaces trop volumineuse invite à choisir des namespaces plutôt que de présenter discrètement une liste partielle.
Vous contrôlez le chargement
Actualisez une liste, suivez la durée et les données reçues, ou annulez la requête. Le graphe du cluster ne se charge qu’à votre demande.
10 000 Pods. 558 MiB de mémoire.
Une liste complète de 10 000 Pods, avec recherche et tri locaux. Des requêtes limitées, un cache partagé et un chargement explicite vous permettent de maîtriser la charge.
- Connexion → liste complète des ressources
- 9,8 s
- Ressources dans la liste complète
- 10 000
- Budget de lecture · requêtes/s
- 10
- Pic mémoire échantillonné · app et navigateur
- 558 MiB
Mesuré avec SPK Ocular 1.7.0 sous Linux, en mode navigateur. Pic échantillonné du PSS total de l’application et de Chromium sur 6 sessions, avec consultation des détails d’objets.
Conditions de mesure
Par connexion : 10 requêtes de lecture/s avec une rafale de 20, et au plus 4 réponses de durée limitée en cours.
Mesuré avec SPK Ocular 1.7.0 sur une API HTTP Kubernetes de test locale. Le premier chargement est la médiane de 3 nouvelles sessions ; 100 pages de 100 Pods constituent la liste complète.
Mode navigateur sous Linux avec une instance dédiée de Chromium sans interface. Le PSS inclut les processus de l’application et de Chromium ; l’API HTTP de test et l’outil de mesure sont exclus. Le pic observé sur 6 sessions valides était de 558 MiB.
La mémoire a été échantillonnée environ toutes les 0,5 secondes.
De « qu’est-ce qui a échoué ? » à « que faire ? »
Les informations pour comprendre et agir sont réunies, sans devoir reconstituer la situation à partir d’une dizaine de fenêtres.
01 / INVESTIGATION
Trouvez les workloads qui demandent votre attention.
Repérez les ressources en difficulté, ouvrez les objets liés et inspectez leur configuration. L’interface indique quand les permissions ou les erreurs de connexion empêchent d’obtenir une vue complète.
- État des ressources, événements et relations
- Choix des espaces de noms, recherche et favoris
- Historique des révisions de Deployment et comparaison YAML en lecture seule
02 / DIAGNOSTIC
Gardez les indices sous les yeux.
Les lignes correspondantes apparaissent pendant la lecture limitée de l’historique ; les nouvelles lignes arrivent en parallèle. La recherche porte sur le résultat filtré. Ouvrez un terminal ou redirigez un port de service pour poursuivre le diagnostic.
Téléchargez l’historique conservé par la source indépendamment des filtres et de la limite de lignes affichées. Le panneau des téléchargements s’ouvre automatiquement avec progression et annulation ; cliquez sur une ligne terminée pour ouvrir le fichier. Un clic droit sur le bouton de téléchargement des logs permet de choisir l’emplacement. La rétention, les limites d’export et les lectures incomplètes restent explicites. La copie utilise le tampon filtré de l’affichage.
- Tous les niveaux de journal, filtres textuels et recherche
- Fenêtres de journaux séparées et exports en texte brut
- Terminaux, sélection de conteneur et redirection locale de ports
03 / RELEASES
Helm, de l’installation au rollback.
Choisissez des charts et des versions, modifiez les values et vérifiez la mise à niveau avant de la lancer. Consultez l’historique des releases et revenez à une révision précédente dans la même fenêtre.
- Dépôts de charts et registres OCI
- Installation, mise à niveau, rollback et désinstallation
- Helm intégré. Aucune CLI distincte nécessaire.
FICHIERS DU CONTENEUR
Parcourez les dossiers. Modifiez les fichiers sur place.
Parcourez les conteneurs Docker et les Pods Kubernetes, suivez les liens symboliques et modifiez les configurations dans une arborescence mise en cache. L’application de bureau copie des fichiers et dossiers entiers sur votre ordinateur.
- Dossiers en cache, nombres d’entrées et navigation par liens symboliques
- Coloration syntaxique et édition UTF-8 jusqu’à 2 MiB
- Enregistrement avec protection des modifications non enregistrées et vérification des changements externes
- Téléchargements directs dans le dossier de téléchargements du système
Nécessite un conteneur Linux actif : sh pour parcourir, readlink pour les liens et tar pour télécharger. Les fichiers et dossiers sont transférés sans la limite de 2 MiB de l’éditeur ; les noms existants ne sont pas écrasés. Les téléchargements en mode navigateur nécessitent l’application de bureau.
Reliez les éléments de votre investigation.
Risques de configuration et rapports sur les images
Examinez les paramètres des workloads Kubernetes, les règles RBAC déclarées et la sélection des ressources par NetworkPolicy. Consultez les rapports de vulnérabilités existants de Trivy Operator avec les détails de l’image, du paquet et des correctifs disponibles. Ocular ne lance pas de scans et n’installe pas l’opérateur ; les résultats ne prouvent ni l’exploitabilité ni la conformité à des normes.
Graphe du cluster
Explorez les relations fondées sur les UID et les routes déclarées de Service, Ingress et Gateway. Il s’agit de configuration, pas de trafic mesuré.
Chronologie des événements
Examinez des instantanés limités de Kubernetes Events regroupés par propriétaires des charges de travail. Actualisez explicitement ; la rétention et la couverture incomplète restent visibles. Ce n’est pas un historique d’audit.
Comprendre RBAC
Retracez les liaisons ServiceAccount et les règles des rôles. Vérifiez les requêtes sur le serveur avec l’identité de la connexion actuelle ; les déclarations et les décisions sur votre propre accès restent distinctes.
Comparer des ressources enregistrées
Sélectionnez deux ressources sur des environnements connectés et comparez leur YAML normalisé en lecture seule. Les contenus Secret et les brouillons non enregistrés sont exclus ; les champs de service sont facultatifs.
Conserver votre espace d’investigation
Épinglez des propriétés en lecture seule et conservez les références aux logs, les onglets de terminal terminés et les dimensions des panneaux après un redémarrage. Connectez-vous et reprenez explicitement ; aucun contenu ni commande n’est enregistré ou rejoué.
Les outils du quotidien sont déjà là.
Navigation rapide · Ctrl+K
Accédez aux vues, environnements et namespaces, ou recherchez des ressources par type et nom, comme dep model, dans les namespaces sélectionnés. Sur macOS, utilisez Command+K.
Ressources Kubernetes
Pods, deployments, services et ressources personnalisées avec détails et relations.
Docker
Conteneurs autonomes, projets et services Compose. Consultez les logs, ouvrez des terminaux et examinez les actions sur les conteneurs.
Vérification des changements
Examinez les changements avant de les appliquer. Les permissions de l’infrastructure restent en vigueur.
Un espace qui garde vos réglages
Les espaces de noms sélectionnés, filtres, favoris et largeurs de colonnes sont enregistrés.
VOS AGENTS. VOS RÈGLES.
Donnez du contexte à l’agent. Gardez la main sur les changements.
Les agents de programmation locaux peuvent inspecter l’environnement via Ocular. Choisissez les espaces de noms, types de ressources et opérations autorisés, puis examinez les actions qui exigent votre approbation.
Délimitez l’accès
Choisissez l’environnement, les espaces de noms et les opérations.
Analysez ensemble
Donnez à l’agent le contexte des ressources et des logs.
Vérifiez l’action
Approuvez les changements protégés ou suspendez l’accès une fois le travail terminé.
Les agents locaux exécutés sous le même utilisateur du système d’exploitation partagent ces permissions. Ocular ne les isole pas des autres programmes de votre ordinateur. Les conteneurs Docker autonomes sont actuellement disponibles uniquement dans l’interface ; les autorisations de projets ne les incluent pas.
Découvrez l’interface.
Écrans réels de SPK Ocular 1.9.0. Données de démonstration, sans maquettes.
L’interface des captures est en anglais.
LOCAL / OPEN SOURCE
Aucun composant Ocular à installer dans votre cluster.
Ocular se connecte depuis votre ordinateur avec votre kubeconfig et vos contextes Docker existants. Aucun serveur central ou composant Ocular dans le cluster n’est requis.
Code sourceVotre accès existant
Utilisez vos identifiants et permissions configurés. Les programmes d’authentification externes indiqués dans kubeconfig doivent toujours être installés.
Open source
Lisez le code, signalez un bug ou contribuez sous licence Apache 2.0.
SANS OFFRE PAYANTE
Toutes les fonctions. Pour tous.
Gratuit pour les particuliers, les équipes et les entreprises de toute taille. Aucune limite liée au chiffre d’affaires ou au financement, aucune licence par poste ni fonction verrouillée.
Réunissez vos environnements.
Choisissez le système d’exploitation et l’architecture, puis téléchargez l’installateur de bureau. Toutes les fonctions sont incluses.
Linux, Windows et macOS · x86-64 et ARM64
Les paquets et sommes de contrôle sont aussi disponibles directement sur GitHub Releases, sans compte. Les builds de développement sont disponibles séparément dans les exécutions CI réussies ; un compte GitHub peut être nécessaire et leur durée de conservation est limitée.
- Choisissez DEB/RPM pour Linux, MSI pour Windows ou DMG pour macOS. Des archives portables sont aussi disponibles.
- Vérifiez la somme SHA-256, puis installez et ouvrez Ocular.
- Utilisez votre kubeconfig ou Docker context existant pour inspecter l’environnement.
Installation et compatibilité
Linux nécessite GTK 3 et WebKit2GTK 4.1, y compris en mode navigateur.
- DEB / RPM
- Depuis 1.6.1, DEB et RPM nécessitent glibc 2.35 ou ultérieure. Ubuntu 24.04 reste la base des compilations natives.
- Distributions vérifiées
- L’installation des paquets et le démarrage en mode bureau et navigateur ont été vérifiés sur x86-64 sous Ubuntu 22.04 et Debian 12/13 (DEB), ainsi que Fedora 44 (RPM). Ubuntu 22.04 a aussi été vérifié nativement sur ARM64.
Les vérifications utilisent des environnements de distribution isolés avec un noyau hôte partagé et X11. Elles ne certifient pas les noyaux standard, Wayland ni les pilotes GPU.
Windows : Windows 10/11 avec WebView2. macOS : version 12 ou ultérieure, Intel ou Apple Silicon.
Les installateurs Windows ne sont pas signés ; les builds macOS ont une signature ad-hoc, sans notarisation. Vérifiez la source du téléchargement et la somme SHA-256 du paquet avant l’installation.
Avant de commencer.
L’usage commercial est-il vraiment gratuit ?
Oui. Pas de limites liées au chiffre d’affaires ou au financement, d’abonnement ni de période d’essai limitée. Toutes les fonctions sont incluses ; les dons sont facultatifs.
Dois-je installer quelque chose dans le cluster ?
Aucun serveur ou composant Ocular dans le cluster n’est nécessaire. L’application utilise votre accès Kubernetes existant. Certaines fonctions dépendent de services du cluster, comme metrics-server pour les métriques des ressources.
Ocular inclut-il un moteur de conteneurs ?
Non. Ocular utilise les moteurs Docker existants, les conteneurs autonomes et les projets Compose. Il ne fournit ni moteur de conteneurs ni machine virtuelle.
Dois-je installer Helm séparément ?
Non. Ocular utilise le SDK Helm intégré pour parcourir les charts et gérer les releases. Aucune CLI Helm distincte n’est nécessaire. Les permissions Kubernetes et l’accès au dépôt de charts restent requis.
Puis-je l’utiliser avec mon agent de programmation ?
Oui, via l’API locale des agents. Vous autorisez l’accès à des environnements, périmètres et opérations choisis. Les écritures protégées nécessitent une vérification. Les agents exécutés sous votre utilisateur du système partagent ces permissions. Vous pouvez suspendre leur accès à tout moment.