Convert Insight boxes to admonitions and add React diagram components

- Fix chapter 5 title to match other chapters (Chapter 5: ...)
- Convert 52 Insight boxes from code formatting to :::info[Insight] admonitions
- Replace ASCII diagrams with React components in chapters 4, 7, 8, 10:
  - ch04: Pod architecture diagrams → StackDiagram, CardGrid, ProcessFlow
  - ch07: Service routing → StackDiagram
  - ch08: Ingress flow → ProcessFlow
  - ch10: Service discovery → ProcessFlow, StackDiagram, CardGrid

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Author: YZXBiz

docs/docs/01-kubernetes-primer.md

@@ -52,9 +52,9 @@ Kubernetes orchestrates your applications by:
 | Manual updates | Rolling updates with zero downtime |
 | Manual monitoring | Built-in health checking |
 
-`★ Insight ─────────────────────────────────────`
+:::info[Insight]
 The best orchestration is invisible. When Kubernetes works properly, applications simply function - scaling during traffic spikes, recovering from failures, and updating seamlessly. The complexity is hidden, but the operational benefits are immense.
-`─────────────────────────────────────────────────`
+:::
 
 ### 1.2. Containerization Technology
 
@@ -132,9 +132,9 @@ Microservices applications are built from many small, specialized, independent s
 **Operational Considerations:**
 Microservices provide unprecedented flexibility but require sophisticated orchestration to manage distributed system complexity. This is where Kubernetes provides essential coordination capabilities.
 
-`★ Insight ─────────────────────────────────────`
+:::info[Insight]
 Microservices aren't just about technology - they're fundamentally about organizational structure. Each service enables independent team ownership, release cycles, and technology choices, creating flexibility that requires orchestration platforms like Kubernetes to manage effectively.
-`─────────────────────────────────────────────────`
+:::
 
 ## 3. The Story Behind Kubernetes
 
@@ -256,9 +256,9 @@ Kubernetes enables true application portability across different infrastructure
 - **Vendor Independence**: Avoid cloud provider lock-in through standardized APIs
 - **Migration Flexibility**: Move workloads based on cost, performance, or compliance requirements
 
-`★ Insight ─────────────────────────────────────`
+:::info[Insight]
 The power of abstraction lies in hiding complexity while providing enhanced capabilities. Just as modern operating systems manage thousands of processes across multiple CPU cores, Kubernetes manages thousands of applications across multiple cloud data centers with similar elegance.
-`─────────────────────────────────────────────────`
+:::
 
 ---
 
@@ -310,9 +310,9 @@ Kubernetes enables organizations of any size to operate with the same sophistica
 **Looking Forward:**
 Subsequent chapters will explore Kubernetes internal architecture, installation procedures, and practical application deployment scenarios. The foundational concepts covered here provide the context for understanding Kubernetes' technical implementation and operational patterns.
 
-`★ Insight ─────────────────────────────────────`
+:::info[Insight]
 Kubernetes represents more than technology advancement - it enables new organizational and operational patterns. Small teams can now operate resilient, scalable applications with automation and reliability previously available only to companies with Google's resources and expertise.
-`─────────────────────────────────────────────────`
+:::
 
 ---
 

docs/docs/02-kubernetes-principles.md

@@ -58,9 +58,9 @@ A Kubernetes cluster provides the computing infrastructure for applications thro
 - **Scalability**: Add or remove nodes based on demand
 - **Abstraction**: Hide infrastructure complexity from applications
 
-`★ Insight ─────────────────────────────────────`
+:::info[Insight]
 Kubernetes abstracts distributed computing complexity similarly to how a concert hall abstracts acoustics and power management. Applications simply "show up and perform" without worrying about underlying infrastructure details.
-`─────────────────────────────────────────────────`
+:::
 
 ### 1.2. Control Plane Nodes
 
@@ -408,9 +408,9 @@ spec:
 4. **Corrective Actions**: Controllers make necessary changes
 5. **Continuous Monitoring**: Controllers maintain desired state over time
 
-`★ Insight ─────────────────────────────────────`
+:::info[Insight]
 The declarative model separates intent from implementation. You describe the "musical piece" you want performed, and Kubernetes orchestrates all the complex coordination needed to make it happen continuously and reliably.
-`─────────────────────────────────────────────────`
+:::
 
 ### 4.2. Pods
 
@@ -621,9 +621,9 @@ Client → Service (stable IP) → kube-proxy → Pod (dynamic IP)
 - **Session Affinity**: Route requests from same client to same pod
 - **Least Connections**: Route to pod with fewest active connections (external LB)
 
-`★ Insight ─────────────────────────────────────`
+:::info[Insight]
 Services solve the "moving target" problem inherent in dynamic container environments. Without Services, connecting to applications would be like trying to call specific musicians during a performance - you'd never know if they're available or where to reach them.
-`─────────────────────────────────────────────────`
+:::
 
 ---
 
@@ -669,9 +669,9 @@ This chapter explored the fundamental principles and architecture that enable Ku
 **Looking Forward:**
 Subsequent chapters will build on these architectural concepts to explore Kubernetes installation, configuration, and practical application deployment scenarios. The principles covered here underpin all Kubernetes operations.
 
-`★ Insight ─────────────────────────────────────`
+:::info[Insight]
 Kubernetes success stems from clear architectural separation of concerns - like a well-orchestrated symphony where each section has specific responsibilities but all work toward creating beautiful music. This organizational clarity enables both reliable operations and sophisticated automation.
-`─────────────────────────────────────────────────`
+:::
 
 ---
 

docs/docs/03-getting-kubernetes.md

@@ -79,9 +79,9 @@ Your Kubernetes learning environment should progress from simple to complex base
 **Cost-Effective Approach:**
 Start with local development for foundational concepts, then use cloud environments only when specific cloud-native features are required.
 
-`★ Insight ─────────────────────────────────────`
+:::info[Insight]
 Master fundamentals locally before moving to cloud environments. This approach builds solid foundations while minimizing costs and complexity during the learning process.
-`─────────────────────────────────────────────────`
+:::
 
 ---
 
@@ -230,9 +230,9 @@ This local setup supports:
 - ConfigMap and Secret management
 - Most Kubernetes learning scenarios
 
-`★ Insight ─────────────────────────────────────`
+:::info[Insight]
 This local cluster handles 90% of Kubernetes learning scenarios. Master Pods, Deployments, Services, and advanced concepts locally before moving to cloud environments for specific integrations.
-`─────────────────────────────────────────────────`
+:::
 
 ---
 
@@ -418,9 +418,9 @@ lke349416-551020-47ad6c5c0000    Ready     <none>    19m    v1.32.1
 - **Authentication failures**: Confirm kubeconfig downloaded correctly
 - **Context issues**: Use `kubectl config current-context` to verify active cluster
 
-`★ Insight ─────────────────────────────────────`
+:::info[Insight]
 Managed clusters hide infrastructure complexity while providing production features. You only see worker nodes, but gain access to cloud load balancers, persistent storage, and enterprise-grade reliability.
-`─────────────────────────────────────────────────`
+:::
 
 ---
 
@@ -546,9 +546,9 @@ Docker Desktop provides graphical context switching through the whale icon menu
 - **Backup Strategy**: Maintain secure backups of working configurations
 - **Environment Separation**: Use separate contexts for different environments
 
-`★ Insight ─────────────────────────────────────`
+:::info[Insight]
 kubeconfig enables seamless multi-cluster workflows. Develop locally, test in staging, and deploy to production using identical kubectl commands - context switching changes the target cluster without changing your workflow.
-`─────────────────────────────────────────────────`
+:::
 
 ---
 

docs/docs/04-working-with-pods.md

@@ -1,5 +1,7 @@
 # Chapter 4: Working with Pods
 
+import { ProcessFlow, StackDiagram, CardGrid, colors } from '@site/src/components/diagrams';
+
 **Previous:** [Chapter 3: Getting Kubernetes](03-getting-kubernetes.md) | **Next:** [Chapter 5: Virtual Clusters and Namespaces](05-virtual-clusters-namespaces.md)
 
 ---
@@ -74,20 +76,21 @@ Pods enable resource sharing by providing a shared execution environment for one
 
 **Multi-Container Pod Architecture:**
 
-```
-Pod: web-application (IP: 10.244.1.5)
-┌─────────────────────────────────────────┐
-│                                         │
-│  ┌─────────────┐    ┌─────────────────┐ │
-│  │ Web Server  │    │ Log Collector   │ │
-│  │ Port: 8080  │    │ Port: 5005      │ │
-│  │             │    │                 │ │
-│  └─────────────┘    └─────────────────┘ │
-│           │                    │        │
-│           └── Shared Volume ───┘        │
-│                                         │
-└─────────────────────────────────────────┘
-```
+<StackDiagram
+  title="Pod: web-application (IP: 10.244.1.5)"
+  layers={[
+    {
+      label: 'Containers',
+      color: colors.blue,
+      items: ['Web Server (Port: 8080)', 'Log Collector (Port: 5005)']
+    },
+    {
+      label: 'Shared Resources',
+      color: colors.slate,
+      items: ['Shared Volume']
+    }
+  ]}
+/>
 
 **Container Communication Patterns:**
 - **External Access**: `10.244.1.5:8080` (web) and `10.244.1.5:5005` (logs)
@@ -181,9 +184,9 @@ spec:
 - **Pending**: No suitable node found (check resources/constraints)
 - **Failed**: Scheduling impossible (insufficient cluster capacity)
 
-`★ Insight ─────────────────────────────────────`
+:::info[Insight]
 Resource requests and limits are critical for scheduling efficiency. Without them, the scheduler cannot make optimal decisions and may place workloads on inadequate nodes, leading to performance issues.
-`─────────────────────────────────────────────────`
+:::
 
 ### 1.4. Pod Lifecycle
 
@@ -255,19 +258,30 @@ Every Kubernetes cluster implements a pod network that automatically connects al
 
 **Network Architecture:**
 
-```
-Kubernetes Cluster Network
-┌──────────────────────────────────────────────────┐
-│                                                  │
-│ Node 1           Node 2           Node 3         │
-│ ┌──────────┐    ┌──────────┐    ┌──────────┐     │
-│ │ Pod A    │    │ Pod B    │    │ Pod C    │     │
-│ │ 10.1.1.2 │◄──►│ 10.1.2.5 │◄──►│ 10.1.3.8 │     │
-│ └──────────┘    └──────────┘    └──────────┘     │
-│                                                  │
-│ Pod Network: Direct communication across nodes   │
-└──────────────────────────────────────────────────┘
-```
+<CardGrid
+  cards={[
+    {
+      title: 'Node 1',
+      description: 'Pod A',
+      items: ['IP: 10.1.1.2'],
+      color: colors.blue
+    },
+    {
+      title: 'Node 2',
+      description: 'Pod B',
+      items: ['IP: 10.1.2.5'],
+      color: colors.green
+    },
+    {
+      title: 'Node 3',
+      description: 'Pod C',
+      items: ['IP: 10.1.3.8'],
+      color: colors.purple
+    }
+  ]}
+/>
+
+**Pod Network: Direct communication across nodes**
 
 **CNI Plugin Options:**
 
@@ -308,9 +322,9 @@ spec:
 - **Application Segmentation**: Multi-tier applications with controlled access
 - **Service Mesh**: Advanced traffic management and security
 
-`★ Insight ─────────────────────────────────────`
+:::info[Insight]
 The pod network starts completely open for ease of use and learning. In production environments, implement network policies to control traffic flow, just like security checkpoints in logistics networks.
-`─────────────────────────────────────────────────`
+:::
 
 ---
 
@@ -340,14 +354,25 @@ Init containers run before application containers and must complete successfully
 
 **Execution Flow:**
 
-```
-Init Container Sequence:
-┌─────────────┐  ┌─────────────┐  ┌─────────────┐
-│   Init 1    │→ │   Init 2    │→ │ Application │
-│ Setup DB    │  │ Check API   │  │   Server    │
-│ (must pass) │  │ (must pass) │  │ (starts)    │
-└─────────────┘  └─────────────┘  └─────────────┘
-```
+<ProcessFlow
+  steps={[
+    {
+      title: 'Init 1',
+      description: 'Setup DB (must pass)',
+      color: colors.orange
+    },
+    {
+      title: 'Init 2',
+      description: 'Check API (must pass)',
+      color: colors.orange
+    },
+    {
+      title: 'Application',
+      description: 'Server (starts)',
+      color: colors.green
+    }
+  ]}
+/>
 
 **Init Container Example:**
 
@@ -414,16 +439,35 @@ Sidecars are defined as init containers with `restartPolicy: Always`, which make
 
 **Sidecar Lifecycle:**
 
-```
-Sidecar Container Lifecycle:
-┌─────────────────────────────────────────────┐
-│ 1. Sidecar starts first                     │
-│ 2. Main application starts after sidecar   │
-│ 3. Both containers run together             │
-│ 4. Main application shuts down              │
-│ 5. Sidecar shuts down after main app       │
-└─────────────────────────────────────────────┘
-```
+<ProcessFlow
+  steps={[
+    {
+      title: 'Sidecar Starts',
+      description: 'Sidecar container starts first',
+      color: colors.purple
+    },
+    {
+      title: 'Main App Starts',
+      description: 'Main application starts after sidecar',
+      color: colors.blue
+    },
+    {
+      title: 'Running Together',
+      description: 'Both containers run together',
+      color: colors.green
+    },
+    {
+      title: 'Main App Shutdown',
+      description: 'Main application shuts down',
+      color: colors.orange
+    },
+    {
+      title: 'Sidecar Shutdown',
+      description: 'Sidecar shuts down after main app',
+      color: colors.red
+    }
+  ]}
+/>
 
 **Content Synchronization Example:**
 
@@ -475,9 +519,9 @@ As of Kubernetes v1.29+, native sidecar support is in beta, providing:
 - **Lifecycle Management**: Proper shutdown sequencing
 - **Status Tracking**: Clear sidecar vs main container status
 
-`★ Insight ─────────────────────────────────────`
+:::info[Insight]
 Sidecar containers implement the single responsibility principle - each container has one focused job. This separation makes components simpler, more reusable, and easier to troubleshoot than monolithic applications.
-`─────────────────────────────────────────────────`
+:::
 
 ---
 
@@ -764,9 +808,9 @@ HOSTNAME=hello-pod
 | `kubectl logs` | Container output | Application debugging |
 | `kubectl exec` | Container access | Interactive debugging |
 
-`★ Insight ─────────────────────────────────────`
+:::info[Insight]
 The Pod name becomes the hostname for all containers inside it, making networking and debugging intuitive. A Pod named "web-server" has hostname "web-server" for all its containers.
-`─────────────────────────────────────────────────`
+:::
 
 ### 4.4. Multi-Container Examples
 
@@ -1012,9 +1056,9 @@ Pods are the fundamental building blocks of Kubernetes, providing a standardized
 **Looking Forward:**
 While Pods are fundamental, production deployments typically use higher-level controllers like Deployments, StatefulSets, and DaemonSets that provide additional capabilities like self-healing, scaling, and rolling updates.
 
-`★ Insight ─────────────────────────────────────`
+:::info[Insight]
 Pods embody the separation of concerns principle - they handle application packaging and resource sharing while letting Kubernetes manage scheduling and orchestration. This separation enables the flexibility and power of the Kubernetes platform.
-`─────────────────────────────────────────────────`
+:::
 
 ---
 

docs/docs/05-virtual-clusters-namespaces.md

@@ -1,4 +1,4 @@
-# 5. Virtual Clusters with Namespaces
+# Chapter 5: Virtual Clusters with Namespaces
 
 *Understanding how Kubernetes organizes cluster resources through logical separation*