Course 1 Recap & Forward Map
Course: Course 1 - Foundations & Interfaces Duration: 8-10 minutes Prerequisites: Modules 1.1, 1.2, and 1.3 (completed)
Introduction
You've Come a Long Way
Three modules ago, you might have thought managing network infrastructure meant SSH-ing into switches, typing arcane commands, and hoping nothing breaks. Now you know better.
You've explored a production-style fabric using kubectl. You've created a VPC using GitOps. You've monitored switches with Grafana dashboards. You've learned to think like a Hedgehog operator.
Before we move forward, let's take a moment to consolidate what you've learned—and preview where you're going next.
Course 1 Complete
This module marks the completion of Course 1: Foundations & Interfaces. You've built the foundation—now it's time to build on it.
What this module covers:
- Quick recap of Modules 1.1-1.3 (what you've learned)
- Knowledge check questions (test your understanding)
- Preview of Course 2 (where you're going next)
- Confidence-building for the next phase
What's different about this module:
- No hands-on lab (this is reflection time)
- Self-check questions (answers provided, non-graded)
- Shorter duration (8-10 minutes)
- Focus on consolidation and readiness
Let's celebrate what you've accomplished and prepare for what's next.
Course 1 Summary
Module 1.1 Recap: Welcome to Fabric Operations
What You Learned:
Hedgehog Fabric is pre-installed, declaratively-managed infrastructure. Your role as a Fabric Operator is to provision, validate, monitor, and troubleshoot network resources—not to install switches or design topologies from scratch.
You learned that network resources are represented as Kubernetes CRDs: switches, servers, connections, and VPCs all exist as objects you can inspect with kubectl.
Key Moment:
You successfully explored the fabric topology using kubectl—listing switches, servers, and connections—without touching a single switch CLI. That was your first taste of abstraction as empowerment.
Confidence Win:
"I can navigate a fabric environment safely using kubectl commands."
Module 1.2 Recap: How Hedgehog Works
What You Learned:
The GitOps workflow became clear: Git is the source of truth, ArgoCD deploys changes, the Fabric Controller orchestrates configuration, Agent CRDs act as a bridge, and Switch Agents execute on each switch.
You were introduced to three operational interfaces:
- Gitea: Write and configure (edit YAML, commit changes)
- ArgoCD: Deploy and observe (sync status, deployment progress)
- Grafana: Monitor and validate (dashboards, metrics, trends)
You created your first VPC (myfirst-vpc
) using the browser-based GitOps workflow.
Key Moment:
You committed a VPC configuration to Git, watched ArgoCD sync it, validated with kubectl, and observed it in Grafana—all without SSHing to a single switch. The abstraction clicked.
Confidence Win:
"I can create a VPC using the GitOps workflow and observe the reconciliation happen across all three interfaces."
Module 1.3 Recap: Mastering the Three Interfaces
What You Learned:
You mastered when to use each interface:
- kubectl: Read and inspect current state, check events, troubleshoot issues
- Gitea: Write configurations, audit change history, review diffs
- Grafana: Observe trends over time, monitor health, aggregate metrics
You learned that Hedgehog VPCs use event-based reconciliation: no error events means successful deployment. You toured all 6 Grafana dashboards: Fabric, Platform, Interfaces, Logs, Node Exporter, and Switch CRM.
Most importantly, you learned a troubleshooting methodology: Check configuration (Gitea) → Verify deployment (kubectl) → Monitor health (Grafana).
Key Moment:
You navigated all three interfaces fluently, correlating information across tools to understand fabric state. You learned to select the right tool for the job.
Confidence Win:
"I know which interface to use for any given task, and I can troubleshoot by correlating data across kubectl, Gitea, and Grafana."
How It All Fits Together
The Full Operator Workflow:
┌─────────────────────────────────────────────────────────┐
│ COURSE 1: What You Now Understand │
├─────────────────────────────────────────────────────────┤
│ │
│ 1. FABRIC FOUNDATION (Module 1.1) │
│ • Pre-installed spine-leaf topology │
│ • Switches, servers, connections (Day 1 complete) │
│ • Kubernetes-native abstractions (CRDs) │
│ │
│ 2. GITOPS CONTROL MODEL (Module 1.2) │
│ • Git → ArgoCD → Fabric Controller → Agents │
│ • Declarative desired state (you declare intent) │
│ • Automatic reconciliation (system does the work) │
│ │
│ 3. THREE OPERATIONAL INTERFACES (Module 1.3) │
│ • Gitea: Write/configure/audit │
│ • kubectl: Read/inspect/troubleshoot │
│ • Grafana: Observe/monitor/trend │
│ │
│ RESULT: You can operate a Hedgehog Fabric confidently │
│ │
└─────────────────────────────────────────────────────────┘
A Day in Your Life as a Fabric Operator:
- Check Grafana Fabric Dashboard (morning health check)
- Provision new VPC via Gitea (project requirement)
- Watch ArgoCD sync the change (verify deployment)
- Use kubectl to validate reconciliation (check events)
- Monitor Grafana Interfaces Dashboard (confirm VLANs applied)
- Move on to next task, confident the fabric handled the details
You Now Operate Like a Hyperscaler:
- Infrastructure as code (Git)
- Automated reconciliation (controllers)
- Multi-layer observability (events, metrics, logs)
- Confidence through abstraction (no manual switch config)
Knowledge Check
These questions help reinforce key concepts. They're not graded—they're for your own confidence check.
Question 1: Fabric Foundation
Scenario: Your manager asks, "What's a Fabric Operator's primary responsibility?"
Which answer best describes your role?
- A) Design network topologies and select switch hardware
- B) Provision VPCs, validate connectivity, and monitor fabric health
- C) Manually configure BGP on switches
- D) Install and cable physical switches
Answer & Explanation
Answer: B) Provision VPCs, validate connectivity, and monitor fabric health
Explanation:
As a Fabric Operator, you manage Day 2 operations on pre-installed infrastructure. The physical fabric (switches, cabling) is already deployed. Your focus is on creating and managing virtual network resources (VPCs), ensuring connectivity works, and monitoring fabric health.
- A is incorrect: Design is typically done during Day 0/1 (before operator role)
- C is incorrect: You don't manually configure switches—controllers handle that
- D is incorrect: Physical installation is Day 0 work, not Day 2 operations
Module 1.1 Reference: Fabric Operator role definition, Day 2 operations focus
Question 2: GitOps Workflow
Scenario: You need to create a new VPC called dev-network
. What's the correct order of operations?
- A) kubectl apply → ArgoCD sync → Git commit → Grafana check
- B) Git commit (Gitea) → ArgoCD sync → kubectl validate → Grafana monitor
- C) Grafana monitor → Git commit → kubectl apply → ArgoCD sync
- D) ArgoCD sync → kubectl validate → Git commit → Grafana check
Answer & Explanation
Answer: B) Git commit (Gitea) → ArgoCD sync → kubectl validate → Grafana monitor
Explanation:
The GitOps workflow follows this sequence:
- Git commit (Gitea): Create VPC YAML file in the
vpcs/
directory, commit to repository (source of truth) - ArgoCD sync: ArgoCD detects the Git change and deploys the VPC CRD to the cluster
- kubectl validate: Verify VPC was created, check events for reconciliation status
- Grafana monitor: Observe fabric metrics to confirm VPC is operational
Why this order matters:
- Git must be first (source of truth in GitOps)
- ArgoCD reacts to Git changes (automation)
- kubectl validates what ArgoCD deployed (verification)
- Grafana monitors runtime behavior (observability)
Other options break the GitOps pattern or have incorrect sequencing.
Module 1.2 Reference: GitOps control model, five-actor flow
Question 3: Interface Selection for Troubleshooting
Scenario: You suspect a VPC isn't working correctly. Which interface should you check FIRST to understand the problem?
- A) Gitea (check VPC configuration)
- B) Grafana (check switch health)
- C) kubectl (check VPC events for errors)
- D) ArgoCD (check sync status)
Answer & Explanation
Answer: C) kubectl (check VPC events for errors)
Explanation:
When troubleshooting a non-working VPC, start with kubectl describe vpc <name>
to check events. Hedgehog uses event-based reconciliation for VPCs—error events immediately tell you what's wrong (e.g., "Subnet overlaps with existing VPC").
After checking events:
- If events show a configuration error → Fix in Gitea (go back to source)
- If events show no errors but VPC still not working → Check Grafana for switch health
- If VPC doesn't exist → Check ArgoCD sync status
Why kubectl first: Starting with kubectl events gives you the most direct troubleshooting information. Events tell you exactly what failed during reconciliation.
Module 1.3 Reference: Troubleshooting methodology, event-based reconciliation
Question 4: Three Interfaces - Decision Making
Match each task to the appropriate interface:
Task | Interface |
---|---|
1. View historical CPU usage trends for spine-01 over 24 hours | ? |
2. See who changed the prod-vpc configuration last week |
? |
3. Check if a VPC has reconciliation errors | ? |
4. Create a new VPC with subnet 10.20.30.0/24 | ? |
Answers & Explanation
Answers:
- Grafana - Time-series metrics and trends (Node Exporter Dashboard shows CPU over time)
- Gitea - Audit trail / commit history (shows author, timestamp, and what changed)
- kubectl - Current state and events (
kubectl describe vpc <name>
shows events) - Gitea - Write configuration (create YAML file in
vpcs/
, commit to Git)
Key Principle:
- kubectl = Read (inspect current state, troubleshoot)
- Gitea = Write (configure, audit history)
- Grafana = Observe (trends, metrics, monitoring)
Why these choices:
- Grafana stores time-series data (kubectl only shows current snapshot)
- Gitea tracks all Git commits with author and timestamp
- kubectl events show reconciliation results in real-time
- GitOps workflow requires Git as source of truth
Module 1.3 Reference: Interface decision matrix, tool selection framework
Knowledge Check Summary
How did you do?
- 4/4 correct: Excellent! You've mastered the foundational concepts.
- 3/4 correct: Strong understanding. Review any questions you missed.
- 2/4 or fewer: Revisit Modules 1.1-1.3 to reinforce concepts before continuing.
Remember: These are for your benefit, not graded assessment. Course 2 builds on these foundations, so make sure you feel confident before moving forward.
Forward Map to Course 2
Course 1 vs Course 2: What Changes?
Course 1 (Where You Are Now):
- ✅ Understood how Hedgehog Fabric works
- ✅ Learned the GitOps workflow
- ✅ Mastered the three operational interfaces
- ✅ Created a simple VPC (
myfirst-vpc
) - ✅ Observed fabric health in Grafana
Key characteristic: Exploration and understanding (mostly read-only focus + one simple VPC)
Course 2 (Where You're Going):
- 🎯 Design and create VPCs from scratch (subnet planning, VLAN allocation)
- 🎯 Attach servers to VPCs (VPCAttachment CRD)
- 🎯 Validate end-to-end connectivity (testing workflows)
- 🎯 Decommission resources safely (cleanup procedures)
- 🎯 Handle real-world provisioning scenarios
Key characteristic: Hands-on provisioning operations (creating, modifying, validating, deleting)
Preview: Course 2 Modules
Module 2.1: Define VPC Network
What You'll Learn:
- VPC design considerations (subnet sizing, IP allocation strategies)
- VLAN selection from namespaces (avoiding conflicts)
- Multi-subnet VPCs (multiple L2 domains within one VPC)
- DHCP configuration options (ranges, custom DNS, reservations)
- IPv4/VLAN namespace concepts and constraints
Hands-On:
- Create a VPC with multiple subnets
- Configure DHCP with custom ranges and options
- Plan IP allocation for a multi-tenant scenario
What's New:
You'll make design decisions (not just follow templates). Which subnet size? Which VLAN? These choices have operational consequences. Module 2.1 teaches you to think through requirements before creating VPCs.
Module 2.2: Attach Servers to VPC
What You'll Learn:
- VPCAttachment CRD (binding servers to VPC subnets)
- Connection types (MCLAG, ESLAG, unbundled, bundled)
- Subnet selection for attachments
- Server inventory review (which servers are available?)
- Native vs tagged VLAN configuration
Hands-On:
- Attach a server to your VPC
- Verify switch configuration (VLAN on correct ports)
- Observe VPCAttachment reconciliation in Grafana
- Troubleshoot attachment failures
What's New:
You'll connect virtual networks (VPCs) to physical infrastructure (servers). This bridges abstraction layers. Understanding how VPCAttachments translate into switch port configurations is key to troubleshooting connectivity.
Module 2.3: Connectivity Validation
What You'll Learn:
- End-to-end connectivity testing workflows
- Using kubectl to inspect Agent CRD interface states
- Reading Grafana metrics to confirm traffic flow
- Troubleshooting common connectivity issues (DHCP, reachability)
- Understanding DHCP relay (switches forwarding DHCP requests)
Hands-On:
- Validate server can obtain DHCP lease from VPC
- Test server-to-server connectivity within VPC
- Use Grafana Interfaces Dashboard to confirm VLANs applied
- Diagnose and fix a misconfigured attachment
What's New:
You'll validate that your configurations actually work (not just trust reconciliation). Testing builds operational confidence. You'll learn systematic validation approaches that apply to any VPC deployment.
Module 2.4: Decommission & Cleanup
What You'll Learn:
- Safe VPC deletion order (attachments first, then VPC)
- Verifying no active servers before deletion
- GitOps deletion workflow (delete YAML files from Git)
- Cleanup validation (ensure switches removed configuration)
- When to archive vs delete configurations
Hands-On:
- Safely decommission a VPC
- Remove VPCAttachments first (proper dependency order)
- Verify cleanup in kubectl and Grafana
- Understand orphaned resource prevention
What's New:
You'll learn to undo your work safely. Decommissioning is a critical Day 2 skill often overlooked in training. Understanding deletion order prevents operational issues like orphaned VLANs or stranded switch configurations.
Course 2: What You'll Be Able to Do
By the end of Course 2, you'll be able to:
- Design VPCs tailored to specific workload requirements
- Provision VPCs using GitOps workflow confidently and independently
- Attach servers to VPCs with correct connection types
- Validate connectivity end-to-end (DHCP, ping, traffic)
- Troubleshoot provisioning issues using all three interfaces systematically
- Decommission VPCs and attachments safely without leaving orphaned resources
- Operate independently for common Day 2 provisioning tasks
This is when you become productive as a Fabric Operator.
Course 1 gave you the knowledge. Course 2 gives you the skills.
Motivation & Next Steps
You're Ready
Course 1 gave you the foundation:
- You understand the fabric architecture and GitOps control model
- You know the GitOps workflow and how reconciliation works
- You've mastered the three operational interfaces
- You've created a VPC and observed reconciliation
Course 2 will give you the skills:
- VPC design and provisioning for real workloads
- Server connectivity and validation
- Systematic validation and troubleshooting
- Lifecycle management (create → use → decommission)
The difference?
Course 1 was about understanding how Hedgehog works. Course 2 is about getting work done as a Fabric Operator.
Confidence Statement
You've completed Course 1, which means:
✅ You can navigate Hedgehog Fabric using kubectl ✅ You understand GitOps workflow and why it matters ✅ You know which interface to use for any task ✅ You've successfully created a VPC using the three interfaces ✅ You can troubleshoot by correlating data across kubectl, Gitea, and Grafana
You're not an expert yet—that's not the goal. You're a confident beginner ready to tackle hands-on provisioning operations. That's exactly where you should be.
What Happens Next
Immediate Next Step:
Begin Course 2, Module 2.1: Define VPC Network
You'll design your first production-style VPC from scratch, making real design decisions about subnets and VLANs. Everything you learned in Course 1 will be applied.
Mindset for Course 2:
- Experiment: You're working in a lab environment—try things, make mistakes, learn from them
- Validate: Use all three interfaces to confirm your work
- Troubleshoot: When things don't work (and they won't always), you have the tools to diagnose
- Escalate: If you're stuck, that's normal—support is part of learning, not a sign of weakness
Remember the Learning Philosophy:
- Confidence before comprehensiveness (master core operations first)
- Focus on what matters most (common tasks, not edge cases)
- Learn by doing, not watching (hands-on every module)
- Support is strength, not weakness (escalate when appropriate)
Final Encouragement
Three modules ago, this might have seemed daunting:
"Manage a data center network using GitOps and Kubernetes? That's not for me."
Now you know it's not just possible—you've already done it.
You've explored a fabric, created a VPC, monitored switches, and troubleshot issues using kubectl, Gitea, and Grafana. The foundation is solid.
The leap from Course 1 to Course 2 is smaller than it feels. You have the foundation. Course 2 adds depth and practice through repetition and real-world scenarios.
Trust your preparation. You've earned this confidence.
Welcome to Course 2. Let's get to work.
Reference
Course 1 Module Links
Module 1.1: Welcome to Fabric Operations
- Fabric Operator role definition
- Kubernetes-native management overview
- kubectl basics for fabric exploration
Module 1.2: How Hedgehog Works
- GitOps workflow (Git → ArgoCD → Fabric Controller → Agents)
- Three interfaces introduction (Gitea, ArgoCD, Grafana)
- VPC creation walkthrough
Module 1.3: Mastering the Three Interfaces
- Interface decision matrix (when to use which tool)
- Event-based reconciliation model
- All 6 Grafana dashboards
- Troubleshooting methodology
Key Concepts Reference
GitOps Workflow:
Git (source of truth)
↓
ArgoCD (deployment automation)
↓
Fabric Controller (orchestration)
↓
Agent CRDs (bridge to switches)
↓
Switch Agents (execution on switches)
Three-Interface Model:
Interface | Role | When to Use |
---|---|---|
kubectl | Read/Inspect | Check state, view events, troubleshoot |
Gitea | Write/Audit | Create configs, review history |
Grafana | Observe/Monitor | View trends, monitor health |
Troubleshooting Flow:
- Gitea - Verify configuration is correct
- kubectl - Check deployment status and events
- Grafana - Monitor runtime health
Grafana Dashboards Quick Reference
- Fabric Dashboard - Overall fabric health (daily check)
- Platform Dashboard - Control plane health (Fabricator, K8s API)
- Interfaces Dashboard - Port status and traffic
- Logs Dashboard - Aggregated syslog
- Node Exporter Dashboard - Switch hardware metrics
- Switch CRM Dashboard - ASIC capacity monitoring
Course 2 Preview
Module 2.1: Define VPC Network (VPC design considerations) Module 2.2: Attach Servers to VPC (VPCAttachment CRD) Module 2.3: Connectivity Validation (testing workflows) Module 2.4: Decommission & Cleanup (safe deletion)
Related Documentation
Course 1 Complete! 🎉 You're ready to continue to Course 2, Module 2.1: Define VPC Network.