Kubernetes Production Deployment
Relevant source files
The following files were used as context for generating this wiki page:
The Kubernetes Production Deployment provides a highly secure and scalable environment for the AI Network Operations Platform. It serves as an "AI Network Engineer" that can discover infrastructure, troubleshoot issues, and manage changes across multi-vendor environments while ensuring every action is audited and human-approved.
This platform solves common network operations problems by providing a self-hosted assistant that understands complex topologies and vendor-specific configurations. It supports a wide array of vendors including Cisco (IOS, IOS-XE, NX-OS), Juniper, Arista, Palo Alto, Fortinet, F5, and DDI providers like Infoblox and BlueCat. The design philosophy emphasizes a "local-first" approach where the AI reasoning is visible, and no changes are executed without a second human engineer's approval.
Sources: README.md:3-12, CLAUDE.md:3-23
Overview
For network teams, the platform acts as a force multiplier by automating repetitive tasks like inventory collection and complex troubleshooting while maintaining strict security boundaries. It uses specialized "agents"—which can be thought of as expert team members like a "Troubleshooting Agent" or a "DDI Agent"—to handle specific types of queries.
Supported Vendors and Protocols
The platform uses a standardized connector (plugin system) for each vendor. Whether you are interacting with a Cisco router, a Juniper switch, or an Infoblox IPAM, the platform normalizes the data into a consistent format before the AI analyzes it.
| Vendor Family | Supported Systems/Protocols |
|---|---|
| Cisco | IOS, IOS-XE, NX-OS |
| Juniper | JunOS |
| Arista | EOS |
| Security | Palo Alto PAN-OS, Fortinet FortiOS |
| Load Balancing | F5 BIG-IP |
| DDI (DNS/DHCP/IPAM) | BlueCat, Infoblox, SpatiumDDI |
| Cloud/Virtual | AWS, Azure, VMware |
Sources: CLAUDE.md:15-30, README.md:17-21, deploy/kubernetes/netops/values.yaml:263-272
System Connectivity
The diagram below illustrates how users interact with the platform and how the platform connects to your infrastructure and external providers.
This diagram shows the high-level communication flow between users, identity services, and the multi-vendor network environment.
Sources: CLAUDE.md:15-30, deploy/kubernetes/netops/README.md:15-35
Architecture
The Kubernetes deployment organizes the platform into distinct components, each responsible for a specific part of the network operations lifecycle.
Platform Components
- frontend: The operations console where engineers chat with the AI, view the topology map, and manage approvals.
- api: The central brain that handles requests, manages security/sessions, and coordinates with agents.
- worker: The background engine that runs long jobs like network discovery, configuration backups, and packet captures without blocking your active session.
- postgres: The system of record that stores all device inventory, audit logs, and encrypted credentials.
- neo4j: A living topology map (knowledge graph) that tracks how every device, interface, subnet, and DNS zone connects to everything else.
- redis: A temporary storage area used for coordinating background tasks and caching data.
- ollama: An optional component for running AI models locally within your own data center for maximum privacy.
Sources: README.md:14-23, deploy/kubernetes/netops/README.md:10-35
Deployment Options
Network teams can choose between two deployment methods depending on their needs:
- Docker Compose: Ideal for lab environments or small teams. It runs everything on a single server using a single configuration file.
- Kubernetes (Helm): The production standard. It allows the platform to run across multiple nodes, provides automated recovery if a component fails, and includes advanced security hardening.
Comparison of the simplified single-server lab setup versus the multi-node production deployment.
Network Intelligence and Agents
The platform uses "Agents" as specialized team members. When you ask a question, a Master Architect determines which expert agent is best suited to help.
Agent Routing and Specialist Experts
The specialist agents include:
- Discovery Agent: Scans the network to find new devices and interfaces.
- Troubleshooting Agent: Diagnoses routing (BGP/OSPF) and connectivity issues.
- DDI Agent: Manages DNS records and DHCP scopes.
- Security Agent: Audits firewall policies and ACLs.
The Master Architect acts as a dispatcher, routing requests to the appropriate specialist agent for either information retrieval or change drafting.
Sources: CLAUDE.md:33-40, deploy/kubernetes/netops/README.md:15-30
Topology Data Model
The Neo4j database maintains a detailed map of the network. This is not just a list of devices, but a relationship map.
| Entity | Relationships |
|---|---|
| Device | Connects to Interfaces; belongs to a Site. |
| Interface | Belongs to a Device; connects to other Interfaces or Subnets. |
| Subnet | Contains IP Addresses; associated with VLANs. |
| DNS Zone | Contains DNS Records; maps to Subnets. |
| Application | Depends on specific DNS Records and Subnets. |
The topology model represents the physical and logical links that the AI uses to understand your network.
Sources: CLAUDE.md:53-60, deploy/kubernetes/netops/README.md:20-25
Change Approval Workflow
Safety is a core requirement. Every modification to the network follows a strict lifecycle. No agent can "login and change" a config directly; they only draft proposals.
- Draft: An agent (like the DDI Agent) creates a proposed change.
- Pending Approval: A human engineer reviews the proposed commands and the AI's reasoning.
- Approved: A second human authorizes the execution.
- Executing: The worker component takes a pre-change backup, applies the config, and verifies the result.
- Completed/Rollback: If the change fails or causes issues, the platform can use the pre-change backup to restore the previous state.
The Change Approval Flow ensures that a "human-in-the-loop" always verifies AI-suggested modifications before they hit production hardware.
Sources: README.md:1-10, CLAUDE.md:42-45, deploy/kubernetes/netops/README.md:40-50
Production Hardening and Security
The Kubernetes deployment is "hardened by default," meaning it applies high-security settings that are often optional in other systems.
Security Features
- Mutual TLS (mTLS): All communication between the platform components and the database is encrypted and requires certificates.
- Network Policies: The platform uses internal firewalls to ensure that the
frontendcan only talk to theapi, and theworkercan only talk to specific management subnets. - Packet Sandbox: Packet analysis is performed in an isolated "sandbox" so that potentially malicious traffic data cannot affect the rest of the platform.
- Audit Logs: Every AI decision and human approval is cryptographically signed and stored in a tamper-evident log.
Configuration Options (Helm Values)
Key security and scale settings can be adjusted in the values.yaml file.
| Configuration Key | Default Value | Description |
|---|---|---|
mtls.postgres.enabled | true | Enables Mutual TLS for database connections. |
networkPolicy.enabled | true | Enforces internal network segmentation. |
backup.postgres.enabled | true | Enables automated weekly and daily database backups. |
services.api.replicas | 1 | Number of API instances (increase for HA in future versions). |
Sources: deploy/kubernetes/netops/values.yaml:5-30, deploy/kubernetes/netops/README.md:55-75, deploy/kubernetes/netops/templates/NOTES.txt:5-20
Summary
The Kubernetes Production Deployment of the AI Network Operations Platform provides network engineers with a robust, secure, and multi-vendor capable assistant. By utilizing specialized agents, a deep topology map, and a mandatory human-approval workflow, the platform enables modern automation while adhering to strict enterprise security standards. Its architecture ensures that network data is analyzed in isolation, changes are backed up, and all activities are fully audited.
Sources: README.md:3-12, deploy/kubernetes/netops/README.md:1-10