[V0_FILE]typescriptreact:file="app/page.tsx" 'use client'; import React, { useState, useEffect } from 'react'; import { Card, CardContent, CardHeader, CardTitle } from '@/components/ui/card'; import { Button } from '@/components/ui/button'; import { CheckCircle, XCircle, RotateCcw, Clock, Target, BookOpen, Zap, ChevronRight, ChevronLeft, Play, Award, Brain, ArrowLeft, ArrowRight } from 'lucide-react'; const KCNALearningSystem = () => { const [mode, setMode] = useState('menu'); const [currentCourse, setCurrentCourse] = useState(0); const [currentLesson, setCurrentLesson] = useState(0); const [currentQuiz, setCurrentQuiz] = useState(0); const [currentQuestion, setCurrentQuestion] = useState(0); const [selectedAnswer, setSelectedAnswer] = useState(''); const [showResult, setShowResult] = useState(false); const [score, setScore] = useState(0); const [answers, setAnswers] = useState([]); const [timeLeft, setTimeLeft] = useState(0); const [timerActive, setTimerActive] = useState(false); const [flashcardIndex, setFlashcardIndex] = useState(0); const [showAnswer, setShowAnswer] = useState(false); const [completedLessons, setCompletedLessons] = useState(new Set()); const [quizScores, setQuizScores] = useState({}); // Comprehensive Course Content const courses = [ { title: "Kubernetes Fundamentals", description: "Master the core concepts of Kubernetes architecture and components", icon: "🎯", color: "bg-blue-50 border-blue-200", lessons: [ { title: "Kubernetes Architecture Overview", content: `# Kubernetes Architecture Overview ## What is Kubernetes? Kubernetes (K8s) is an open-source container orchestration platform that automates the deployment, scaling, and management of containerized applications. ## Master Node Components ### 1. API Server (kube-apiserver) - **Primary interface** to the Kubernetes cluster - Processes REST requests and updates etcd - Validates and configures API objects - Acts as the gateway for all cluster operations ### 2. etcd - **Distributed key-value store** that stores all cluster data - Maintains cluster state and configuration - Provides consistent and highly-available data storage - Critical for cluster recovery and consistency ### 3. Scheduler (kube-scheduler) - **Assigns pods to nodes** based on resource requirements - Considers factors like resource availability, constraints, and policies - Makes intelligent placement decisions - Can be customized with scheduling policies ### 4. Controller Manager (kube-controller-manager) - Runs various **controllers** that regulate cluster state - Node Controller: Monitors node health - Replication Controller: Ensures desired replica count - Endpoints Controller: Manages service endpoints ## Worker Node Components ### 1. kubelet - **Primary node agent** that manages containers - Communicates with API server - Ensures containers are running in pods - Reports node and pod status ### 2. kube-proxy - **Network proxy** that handles service networking - Maintains network rules for service communication - Implements load balancing for services - Manages iptables/IPVS rules ### 3. Container Runtime - **Runs containers** (Docker, containerd, CRI-O) - Pulls container images - Starts and stops containers - Manages container lifecycle ## Key Concepts - **Declarative Management**: Describe desired state, K8s maintains it - **Self-Healing**: Automatically replaces failed components - **Scalability**: Scales applications up/down based on demand - **Load Balancing**: Distributes traffic across healthy pods` }, { title: "Pods and Workloads", content: `# Pods and Workloads ## Pods - The Basic Unit ### What is a Pod? - **Smallest deployable unit** in Kubernetes - Contains one or more containers that share resources - Containers in a pod share network and storage - Pods are ephemeral - they come and go ### Pod Characteristics - **Shared Network**: All containers share the same IP - **Shared Storage**: Volumes are shared across containers - **Lifecycle**: All containers start/stop together - **Communication**: Containers communicate via localhost ## Workload Resources ### 1. Deployments - **Best for stateless applications** - Manages ReplicaSets automatically - Supports rolling updates and rollbacks - Ensures desired number of replicas **Use Cases:** - Web applications - APIs - Microservices - Any stateless application ### 2. StatefulSets - **For stateful applications** requiring stable identity - Provides stable network identities - Ordered deployment and scaling - Persistent storage per pod **Use Cases:** - Databases (MySQL, PostgreSQL) - Distributed systems (Kafka, Elasticsearch) - Applications requiring stable hostnames ### 3. DaemonSets - **Ensures pod runs on every node** (or selected nodes) - Automatically schedules pods to new nodes - Good for node-level services **Use Cases:** - Log collection agents (Fluentd) - Monitoring agents (Prometheus Node Exporter) - Network plugins - Security agents ### 4. Jobs - **Runs pods to completion** - Ensures successful termination - Can run multiple pods in parallel - Retries failed pods **Use Cases:** - Batch processing - Data migration - Backup tasks - One-time computations ### 5. CronJobs - **Scheduled execution** of Jobs - Uses cron syntax for scheduling - Manages multiple Job executions - Handles timezone considerations **Use Cases:** - Automated backups - Report generation - Cleanup tasks - Periodic data processing ## Pod Lifecycle 1. **Pending**: Pod created but not scheduled 2. **Running**: Pod assigned to node and containers started 3. **Succeeded**: All containers terminated successfully 4. **Failed**: At least one container failed 5. **Unknown**: Pod status cannot be determined` }, { title: "Services and Networking", content: `# Services and Networking ## Services - Stable Network Access ### What are Services? - **Stable endpoint** for accessing pods - Provides load balancing across pods - Survives pod restarts and rescheduling - Uses label selectors to target pods ## Service Types ### 1. ClusterIP (Default) - **Internal access only** within cluster - Gets a cluster-internal IP address - Default service type - Perfect for internal communication **Use Cases:** - Database services - Internal APIs - Microservice communication ### 2. NodePort - **Exposes service on each node's IP** at a static port - Accessible from outside the cluster - Port range: 30000-32767 - Routes to ClusterIP service **Use Cases:** - Development environments - Small applications - When LoadBalancer isn't available ### 3. LoadBalancer - **Exposes service externally** using cloud provider's load balancer - Creates NodePort and ClusterIP services - Gets external IP from cloud provider - Most common for production external access **Use Cases:** - Production web applications - Public APIs - External-facing services ### 4. Headless Services - **No cluster IP assigned** (ClusterIP: None) - DNS returns pod IPs directly - Used for service discovery - No load balancing by kube-proxy **Use Cases:** - StatefulSet services - Custom load balancing - Direct pod communication - Service discovery ## DNS in Kubernetes - **Automatic DNS resolution** for services - Format: \`service-name.namespace.svc.cluster.local\` - Pods get DNS records too - CoreDNS is the default DNS server ## Network Policies - **Firewall rules** for pods - Control ingress/egress traffic - Based on labels and namespaces - Requires network plugin support ## Ingress - **HTTP/HTTPS routing** to services - Layer 7 load balancing - SSL termination - Path-based and host-based routing - Requires Ingress Controller` } ] }, { title: "Container Technology & Runtime", description: "Deep dive into containers, runtimes, and the Open Container Initiative", icon: "📦", color: "bg-green-50 border-green-200", lessons: [ { title: "Container Fundamentals", content: `# Container Fundamentals ## What are Containers? - **Lightweight, portable packages** that include application and dependencies - Share the host OS kernel - Isolated processes with their own filesystem, network, and process space - Much lighter than virtual machines ## Container vs Virtual Machines ### Containers: - Share OS kernel - Fast startup (seconds) - Lower resource overhead - Application-level isolation ### Virtual Machines: - Full OS per VM - Slower startup (minutes) - Higher resource usage - Hardware-level isolation ## Container Images - **Read-only templates** used to create containers - Built in layers for efficiency - Stored in container registries - Follow semantic versioning ### Image Layers - Each instruction in Dockerfile creates a layer - Layers are cached and reused - Only changed layers need to be rebuilt - Base images provide common layers ## Container Lifecycle 1. **Created**: Container instance created from image 2. **Running**: Container is executing 3. **Paused**: Container processes are suspended 4. **Stopped**: Container has exited 5. **Deleted**: Container instance removed ## Benefits of Containers - **Consistency**: Same environment across dev/test/prod - **Portability**: Run anywhere containers are supported - **Efficiency**: Better resource utilization than VMs - **Scalability**: Quick scaling up/down - **DevOps**: Enables CI/CD and microservices` }, { title: "Open Container Initiative (OCI)", content: `# Open Container Initiative (OCI) ## What is OCI? The **Open Container Initiative** is a Linux Foundation project that creates open industry standards for container formats and runtimes. ## OCI Specifications ### 1. Runtime Specification (runtime-spec) - **Defines how to run containers** - Configuration format for containers - Lifecycle operations (create, start, stop, delete) - Runtime environment requirements ### 2. Image Specification (image-spec) - **Defines container image format** - Image manifest structure - Layer format and distribution - Content addressing and verification ### 3. Distribution Specification (distribution-spec) - **Defines how to distribute container images** - Registry API specifications - Image push/pull operations - Content discovery mechanisms ## OCI Compliance Benefits - **Interoperability**: Images work across different runtimes - **Vendor Neutrality**: No lock-in to specific vendors - **Innovation**: Encourages runtime innovation - **Security**: Standardized security practices ## OCI Runtimes ### Low-Level Runtimes #### runC - **Reference implementation** of OCI runtime spec - Most widely used runtime - Used by Docker, containerd, CRI-O - Written in Go #### crun - **C implementation** of OCI runtime - Faster startup than runC - Lower memory usage - Compatible with runC ### High-Level Runtimes #### containerd - **Industry-standard container runtime** - Used by Docker and Kubernetes - Manages container lifecycle - Image management and storage #### CRI-O - **Kubernetes-specific runtime** - Implements Kubernetes CRI - Lightweight and secure - OCI-compliant by design ## OCI Images - **Standard format** for container images - Platform-independent - Content-addressable - Supports multi-architecture images ### Image Structure - **Manifest**: Image configuration and layer references - **Configuration**: Container configuration - **Layers**: Filesystem layers - **Annotations**: Additional metadata` }, { title: "Advanced Container Runtimes", content: `# Advanced Container Runtimes ## Security-Focused Runtimes ### Kata Containers - **Lightweight VMs** for container workloads - Hardware-enforced isolation - Compatible with OCI and CRI - Better security than traditional containers **Features:** - VM-level isolation - Fast boot times (~150ms) - Small memory footprint - Strong workload isolation **Use Cases:** - Multi-tenant environments - Untrusted workloads - Regulatory compliance - High-security requirements ### gVisor - **User-space kernel** for containers - Application-level sandboxing - Intercepts and handles system calls - Compatible with Docker and Kubernetes **Features:** - Strong isolation without VMs - Limited attack surface - No hardware virtualization required - Lower overhead than VMs **Use Cases:** - Serverless platforms - Function-as-a-Service - Multi-tenant applications - Security-critical workloads ## Runtime Architecture ### Container Runtime Interface (CRI) - **Kubernetes API** for container runtimes - Defines gRPC API between kubelet and runtime - Enables pluggable runtimes - Standardizes runtime integration ### CRI Components 1. **ImageService**: Manages container images 2. **RuntimeService**: Manages container lifecycle 3. **PodSandbox**: Provides pod-level isolation ## Runtime Comparison | Runtime | Isolation | Performance | Use Case | |---------|-----------|-------------|----------| | runC | Process | High | General purpose | | Kata | VM | Medium | Secure workloads | | gVisor | Sandbox | Medium-High | Untrusted code | | Firecracker | MicroVM | High | Serverless | ## Choosing the Right Runtime ### Consider: - **Security requirements**: How much isolation needed? - **Performance needs**: Startup time and overhead - **Compatibility**: With existing tools and systems - **Resource constraints**: Available CPU and memory - **Operational complexity**: Management and debugging ## Future of Container Runtimes - **WebAssembly (WASM)** integration - **Confidential computing** support - **Better GPU** and hardware acceleration - **Improved debugging** and observability - **Edge computing** optimizations` } ] }, { title: "Cloud Native Architecture", description: "Learn about cloud native patterns, microservices, and modern application architecture", icon: "☁️", color: "bg-purple-50 border-purple-200", lessons: [ { title: "Cloud Native Principles", content: `# Cloud Native Principles ## What is Cloud Native? **Cloud Native** is an approach to building and running applications that exploits the advantages of cloud computing environments. ## Core Principles ### 1. Microservices Architecture - **Small, independent services** that communicate over APIs - Each service owns its data and business logic - Independently deployable and scalable - Technology diversity allowed **Benefits:** - Faster development and deployment - Better fault isolation - Team independence - Technology flexibility **Challenges:** - Increased complexity - Network communication overhead - Distributed system challenges - Monitoring and debugging difficulty ### 2. Containerization - **Package applications** with their dependencies - Consistent environments across stages - Resource efficiency - Fast scaling and deployment ### 3. Dynamic Management - **Automated orchestration** of workloads - Self-healing capabilities - Auto-scaling based on demand - Infrastructure as code ### 4. DevOps and Continuous Delivery - **Automated CI/CD pipelines** - Infrastructure automation - Monitoring and observability - Rapid iteration and feedback ## Cloud Native Computing Foundation (CNCF) ### Mission Promote adoption of cloud native computing across the industry ### Key Projects - **Kubernetes**: Container orchestration - **Prometheus**: Monitoring and alerting - **Envoy**: Service proxy - **Fluentd**: Log collection - **Jaeger**: Distributed tracing ## The Twelve-Factor App ### Methodology for building cloud native applications: 1. **Codebase**: One codebase per app 2. **Dependencies**: Explicitly declare dependencies 3. **Config**: Store config in environment 4. **Backing Services**: Treat as attached resources 5. **Build/Release/Run**: Separate stages 6. **Processes**: Stateless processes 7. **Port Binding**: Export services via ports 8. **Concurrency**: Scale via process model 9. **Disposability**: Fast startup and shutdown 10. **Dev/Prod Parity**: Keep environments similar 11. **Logs**: Treat logs as event streams 12. **Admin Processes**: Run as one-off processes ## Design Patterns ### Service Mesh - **Dedicated infrastructure layer** for service communication - Handles service discovery, load balancing, encryption - Examples: Istio, Linkerd, Consul Connect ### Circuit Breaker - **Prevents cascade failures** in distributed systems - Fails fast when downstream services are unavailable - Allows recovery time for failing services ### Bulkhead Pattern - **Isolates critical resources** from less critical ones - Prevents resource exhaustion - Similar to ship compartments ### Saga Pattern - **Manages distributed transactions** - Coordinates multiple services - Handles partial failures gracefully` }, { title: "GitOps and Infrastructure as Code", content: `# GitOps and Infrastructure as Code ## GitOps Fundamentals ### What is GitOps? **GitOps** is a methodology that uses Git repositories as the single source of truth for infrastructure and application configuration. ### Core Principles 1. **Declarative**: System state described declaratively 2. **Versioned**: All changes tracked in Git 3. **Immutable**: No direct changes to running systems 4. **Automated**: Changes applied automatically 5. **Auditable**: Complete change history in Git ### GitOps Workflow 1. **Developer** pushes code changes to Git 2. **CI Pipeline** builds and tests application 3. **Image** pushed to container registry 4. **Config Repository** updated with new image tag 5. **GitOps Agent** detects changes and applies them 6. **Cluster State** updated to match Git repository ## GitOps Tools ### ArgoCD - **Declarative GitOps** continuous delivery - Kubernetes-native - Web UI for application management - Multi-cluster support ### Flux - **GitOps toolkit** for Kubernetes - CNCF graduated project - Supports Helm and Kustomize - Progressive delivery features ### Tekton - **Cloud-native CI/CD** building blocks - Kubernetes Custom Resources for pipelines - Reusable pipeline components - Multi-cloud and hybrid support ## Infrastructure as Code (IaC) ### What is IaC? **Infrastructure as Code** treats infrastructure configuration as software code that can be versioned, tested, and deployed. ### Benefits - **Consistency**: Repeatable infrastructure - **Version Control**: Track infrastructure changes - **Automation**: Reduce manual errors - **Collaboration**: Team-based infrastructure management - **Testing**: Validate infrastructure before deployment ### IaC Tools #### Terraform - **Multi-cloud** infrastructure provisioning - Declarative configuration language (HCL) - State management and planning - Large provider ecosystem #### Pulumi - **Infrastructure as code** using familiar languages - Supports TypeScript, Python, Go, C# - Real programming constructs - Native cloud provider APIs #### AWS CloudFormation - **AWS-native** infrastructure templates - JSON/YAML template format - Built-in rollback capabilities - Integration with AWS services #### Azure Resource Manager (ARM) - **Azure-native** template deployment - JSON template format - Parameter and variable support - Resource group management ## Configuration Management ### Helm - **Package manager** for Kubernetes - Templating engine for YAML manifests - Version management for releases - Chart repositories for sharing ### Kustomize - **Template-free** customization of Kubernetes YAML - Patch-based configuration - Built into kubectl - Overlay-based environments ### Jsonnet - **Data templating language** - Generates JSON/YAML configurations - Libraries and inheritance - Complex configuration scenarios ## Best Practices ### Repository Structure \`\`\` ├── apps/ │ ├── frontend/ │ ├── backend/ │ └── database/ ├── infrastructure/ │ ├── terraform/ │ └── helm/ └── environments/ ├── dev/ ├── staging/ └── prod/ \`\`\` ### Security Considerations - **Secret Management**: Never store secrets in Git - **Access Controls**: Limit repository access - **Branch Protection**: Require reviews for changes - **Signed Commits**: Verify commit authenticity` }, { title: "Serverless and Edge Computing", content: `# Serverless and Edge Computing ## Serverless Computing ### What is Serverless? **Serverless** is a cloud computing model where the cloud provider manages server infrastructure, allowing developers to focus on code. ### Characteristics - **Event-driven**: Functions triggered by events - **Automatic Scaling**: Scales to zero when not used - **Pay-per-use**: Pay only for actual execution time - **Stateless**: Functions don't maintain server state - **Managed Infrastructure**: No server management ### Function as a Service (FaaS) #### AWS Lambda - **Event-driven** compute service - Supports multiple languages - Integrates with AWS services - Automatic scaling and high availability #### Google Cloud Functions - **Lightweight** compute solution - HTTP and event triggers - Integrated with Google Cloud services - Pay-per-invocation pricing #### Azure Functions - **Serverless** compute service - Multiple trigger types - Integrated development experience - Consumption and premium plans ### Serverless Frameworks #### Knative - **Kubernetes-based** serverless platform - Scale-to-zero capabilities - Request-driven autoscaling - Eventing system for event sources #### OpenFaaS - **Open source** FaaS platform - Runs on Kubernetes or Docker Swarm - CLI and web UI - Marketplace of functions ## Edge Computing ### What is Edge Computing? **Edge computing** brings computation and data storage closer to data sources and users to reduce latency and bandwidth usage. ### Edge Characteristics - **Low Latency**: Reduced round-trip time - **Bandwidth Optimization**: Less data to cloud - **Offline Capability**: Works without internet - **Local Processing**: Real-time decision making - **Privacy**: Data stays local ### Kubernetes at the Edge #### K3s - **Lightweight Kubernetes** distribution - Perfect for edge and IoT devices - Single binary (<100MB) - ARM and x86 support - SQLite instead of etcd **Features:** - Easy installation and management - Reduced resource requirements - Built-in containerd and runc - Simplified TLS management #### MicroK8s - **Snap-based** Kubernetes distribution - Zero-ops Kubernetes for workstations - Add-ons marketplace - Multi-node clustering #### K0s - **Zero-friction** Kubernetes distribution - Single binary distribution - No external dependencies - GitOps-friendly ### Edge Use Cases #### IoT and Industrial - **Sensor Data Processing**: Real-time analytics - **Predictive Maintenance**: Machine learning at edge - **Quality Control**: Computer vision processing - **Safety Monitoring**: Immediate response to hazards #### Retail and Commerce - **Inventory Management**: Real-time stock tracking - **Customer Analytics**: Behavior analysis - **Payment Processing**: Low-latency transactions - **Personalization**: Real-time recommendations #### Autonomous Systems - **Self-driving Cars**: Real-time decision making - **Drones**: Flight control and navigation - **Robotics**: Motion planning and control - **Smart Cities**: Traffic and resource management ## Serverless Best Practices ### Function Design - **Single Responsibility**: One function, one purpose - **Idempotent**: Safe to retry operations - **Stateless**: No persistent state in functions - **Fast Startup**: Minimize cold start time ### Monitoring and Observability - **Distributed Tracing**: Track requests across functions - **Custom Metrics**: Business-specific measurements - **Error Handling**: Graceful error recovery - **Performance Monitoring**: Track execution time and memory ### Security - **Least Privilege**: Minimal permissions - **Input Validation**: Sanitize all inputs - **Secret Management**: Use secure secret stores - **VPC Configuration**: Network isolation when needed` } ] }, { title: "Security and Compliance", description: "Master Kubernetes security, RBAC, policies, and compliance frameworks", icon: "🔒", color: "bg-red-50 border-red-200", lessons: [ { title: "Kubernetes Security Model", content: `# Kubernetes Security Model ## Security Layers ### The 4Cs of Cloud Native Security 1. **Code**: Application code security 2. **Container**: Container image and runtime security 3. **Cluster**: Kubernetes cluster security 4. **Cloud**: Infrastructure and network security ## Authentication ### How Kubernetes identifies users and services #### User Authentication - **X.509 Certificates**: Most common method - **Service Account Tokens**: For pods and services - **Static Token Files**: Basic token authentication - **Identity Providers**: OIDC, LDAP integration #### Service Accounts - **Kubernetes identity** for pods - Automatically mounted as secrets - Each namespace has a default service account - Can be customized for specific permissions ### Authentication Flow 1. **Request** arrives at API server 2. **Authentication plugins** verify identity 3. **User information** extracted from credentials 4. **Request** proceeds to authorization ## Authorization ### What authenticated users can do #### Authorization Modes ##### RBAC (Role-Based Access Control) - **Most common** authorization mode - Uses roles and role bindings - Fine-grained permissions - Namespace and cluster-wide scopes ##### ABAC (Attribute-Based Access Control) - **Policy file** defines access rules - Complex attribute-based decisions - More flexible but harder to manage - Less commonly used ##### AlwaysAllow - **Permits all requests** (default in some setups) - Only for development/testing - Never use in production ##### AlwaysDeny - **Denies all requests** - Used for maintenance mode - Rarely used in practice ## Admission Control ### Final step before API server processes requests #### Admission Controllers ##### ValidatingAdmissionWebhooks - **Custom validation** logic - Can reject requests based on custom rules - Runs after all built-in admission controllers ##### MutatingAdmissionWebhooks - **Modify requests** before processing - Can add/change/remove fields - Runs before validating controllers ##### Built-in Controllers - **PodSecurityPolicy**: Define pod security standards - **ResourceQuota**: Limit resource usage - **LimitRanger**: Set default resource limits - **NamespaceLifecycle**: Prevent actions in terminating namespaces ## Network Security ### Network Policies - **Kubernetes firewall** rules for pods - Control ingress and egress traffic - Based on labels and namespaces - Requires CNI plugin support ### Service Mesh Security - **mTLS** (Mutual TLS) between services - Identity-based access control - Traffic encryption and authentication - Examples: Istio, Linkerd, Consul Connect ## Secrets Management ### Kubernetes Secrets - **Base64 encoded** (not encrypted!) - Stored in etcd - Mounted as files or environment variables - Better than hardcoding in images #### Secret Types - **Generic**: Arbitrary key-value pairs - **TLS**: TLS certificates and keys - **Docker Registry**: Container registry credentials - **Service Account**: Tokens for service accounts ### External Secret Management #### HashiCorp Vault - **Dynamic secret generation** - Encryption as a service - Audit logging - Policy-based access control #### AWS Secrets Manager - **Automatic rotation** of secrets - Integration with AWS services - Fine-grained access control - Encryption at rest and in transit ### Best Practices - **Never store secrets in images** - Use external secret management systems - Implement secret rotation - Audit secret access - Encrypt secrets at rest in etcd` }, { title: "RBAC and Access Control", content: `# RBAC and Access Control ## RBAC Concepts ### Core Components #### Users and Groups - **Users**: Individual identities (humans or systems) - **Groups**: Collections of users with similar access needs - **Service Accounts**: Kubernetes-managed identities for pods #### Roles and ClusterRoles ##### Role - **Namespace-scoped** permissions - Defines what actions can be performed on which resources - Only applies within a specific namespace ##### ClusterRole - **Cluster-wide** permissions - Can be used for cluster-scoped resources - Can be bound to users across all namespaces #### RoleBindings and ClusterRoleBindings ##### RoleBinding - **Links users/groups to Roles** within a namespace - Grants permissions defined in the Role - Namespace-scoped ##### ClusterRoleBinding - **Links users/groups to ClusterRoles** cluster-wide - Grants permissions across the entire cluster - Cluster-scoped ## RBAC Examples ### Basic Role Example \`\`\`yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: default name: pod-reader rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "watch", "list"] \`\`\` ### RoleBinding Example \`\`\`yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: read-pods namespace: default subjects: - kind: User name: jane apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io \`\`\` ### ClusterRole Example \`\`\`yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: node-reader rules: - apiGroups: [""] resources: ["nodes"] verbs: ["get", "list", "watch"] \`\`\` ## Common RBAC Patterns ### Developer Role \`\`\`yaml # Developers need to manage their applications rules: - apiGroups: ["", "apps", "extensions"] resources: ["pods", "deployments", "services", "configmaps", "secrets"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] \`\`\` ### Read-Only Access \`\`\`yaml # Monitoring or auditing access rules: - apiGroups: ["*"] resources: ["*"] verbs: ["get", "list", "watch"] \`\`\` ### Namespace Admin \`\`\`yaml # Full access within specific namespace rules: - apiGroups: ["*"] resources: ["*"] verbs: ["*"] \`\`\` ## Service Account Security ### Default Service Account - Every namespace has a **default service account** - Automatically assigned to pods without explicit service account - Has minimal permissions by default ### Custom Service Accounts \`\`\`yaml apiVersion: v1 kind: ServiceAccount metadata: name: my-service-account namespace: default --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: my-service-account-binding namespace: default subjects: - kind: ServiceAccount name: my-service-account namespace: default roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io \`\`\` ## RBAC Best Practices ### Principle of Least Privilege - Grant **minimum necessary permissions** - Start with no access and add as needed - Regularly audit and remove unused permissions - Use namespace-scoped roles when possible ### Role Management - **Create reusable roles** for common patterns - Use descriptive names for roles and bindings - Document role purposes and permissions - Version control RBAC configurations ### Monitoring and Auditing - **Enable audit logging** for API server - Monitor for failed authorization attempts - Regular access reviews - Use tools like \`kubectl auth can-i\` to test permissions ### Security Considerations - **Don't use default service accounts** for applications - Rotate service account tokens regularly - Use pod security contexts to limit privileges - Monitor service account usage and permissions` }, { title: "Pod Security and Policies", content: `# Pod Security and Policies ## Pod Security Standards ### Pod Security Levels #### Privileged - **Unrestricted** policy - Allows known privilege escalations - Broadest level of permissions - Should be used sparingly #### Baseline - **Minimally restrictive** policy - Prevents known privilege escalations - Allows default pod configuration - Good starting point for most workloads #### Restricted - **Heavily restricted** policy - Follows current pod hardening best practices - May cause compatibility issues - Highest security level ### Pod Security Context \`\`\`yaml apiVersion: v1 kind: Pod metadata: name: security-context-demo spec: securityContext: runAsUser: 1000 runAsGroup: 3000 fsGroup: 2000 containers: - name: sec-ctx-demo image: busybox securityContext: allowPrivilegeEscalation: false readOnlyRootFilesystem: true runAsNonRoot: true \`\`\` ## Open Policy Agent (OPA) ### What is OPA? **Open Policy Agent** is a general-purpose policy engine that enables unified policy enforcement across the stack. ### OPA Gatekeeper - **Kubernetes-native** policy controller - Uses OPA and Rego policy language - Admission controller webhook - Constraint templates for reusable policies ### Rego Language \`\`\`rego # Example policy: Require labels package kubernetes.admission deny[msg] { input.request.kind.kind == "Pod" required := {"app", "version"} provided := input.request.object.metadata.labels missing := required - object.keys(provided) count(missing) > 0 msg := sprintf("Missing required labels: %v", [missing]) } \`\`\` ### Common Policies - **Resource limits**: Ensure CPU/memory limits - **Image policies**: Block untrusted registries - **Label requirements**: Enforce labeling standards - **Security contexts**: Require non-root users ## Container Security ### Image Security #### Image Scanning - **Vulnerability scanning** of container images - Static analysis of image layers - Integration with CI/CD pipelines - Tools: Trivy, Clair, Snyk #### Image Signing - **Digital signatures** for container images - Verify image authenticity and integrity - Tools: Cosign, Notary, Docker Content Trust ### Runtime Security #### Security Contexts - **Control security settings** for pods and containers - User and group IDs - File system permissions - Privilege escalation controls #### Capabilities - **Fine-grained privileges** instead of full root - Add or drop Linux capabilities - Principle of least privilege - Examples: NET_ADMIN, SYS_TIME ### Supply Chain Security #### SLSA (Supply-chain Levels for Software Artifacts) - **Framework** for supply chain security - Levels 0-4 with increasing security - Build provenance and verification - Tamper-proof build systems #### Software Bill of Materials (SBOM) - **Inventory** of software components - Vulnerability tracking - License compliance - Dependency analysis ## Compliance Frameworks ### SOC 2 (Service Organization Control 2) - **Security, availability, processing integrity** - Trust services criteria - Third-party auditing - Cloud service compliance ### PCI DSS (Payment Card Industry Data Security Standard) - **Credit card data protection** - Network security requirements - Access controls and monitoring - Regular security testing ### HIPAA (Health Insurance Portability and Accountability Act) - **Healthcare data protection** - Administrative, physical, technical safeguards - Audit controls and data integrity - Access management ### FedRAMP (Federal Risk and Authorization Management Program) - **US government cloud security** - Standardized security assessment - Continuous monitoring - Authority to Operate (ATO) ## Security Monitoring ### Audit Logging - **Record all API requests** - Who, what, when, where - Configurable audit policies - Integration with SIEM systems ### Runtime Monitoring - **Behavioral analysis** of running containers - Anomaly detection - Process monitoring - Network traffic analysis ### Security Metrics - **Failed authentication** attempts - Policy violations - Privilege escalations - Suspicious network activity` } ] }, { title: "Storage and Data Management", description: "Understand Kubernetes storage concepts, persistent volumes, and data management", icon: "💾", color: "bg-yellow-50 border-yellow-200", lessons: [ { title: "Kubernetes Storage Fundamentals", content: `# Kubernetes Storage Fundamentals ## Storage Concepts Overview ### Container Storage Challenges - **Ephemeral by nature**: Containers are stateless - **Data persistence**: Need to survive container restarts - **Shared storage**: Multiple containers need access - **Performance**: Different workloads need different storage types ### Kubernetes Storage Architecture #### Container Storage Interface (CSI) - **Standard interface** for storage systems - Vendor-neutral storage integration - Dynamic provisioning capabilities - Snapshot and cloning support ## Volume Types ### Ephemeral Volumes #### emptyDir - **Temporary storage** within pod - Shared between containers in same pod - Deleted when pod is removed - Good for cache, temporary files \`\`\`yaml apiVersion: v1 kind: Pod metadata: name: test-pd spec: containers: - image: nginx name: test-container volumeMounts: - mountPath: /cache name: cache-volume volumes: - name: cache-volume emptyDir: {} \`\`\` #### hostPath - **Mounts file/directory** from node filesystem - Survives pod restart but not node failure - Security risk - avoid in production - Useful for accessing node-level resources ### ConfigMaps and Secrets as Volumes #### ConfigMap Volumes - **Configuration data** as files - Non-sensitive configuration - Can be updated dynamically #### Secret Volumes - **Sensitive data** as files - Passwords, certificates, tokens - Base64 encoded (not encrypted!) \`\`\`yaml volumes: - name: config-volume configMap: name: app-config - name: secret-volume secret: secretName: app-secrets \`\`\` ### Network Storage #### NFS (Network File System) - **Shared storage** across multiple nodes - ReadWriteMany access mode - Good for legacy applications #### Cloud Provider Volumes - **AWS EBS**: Block storage - **GCE Persistent Disks**: Block storage - **Azure Disks**: Block storage - **Cloud provider managed** ## Persistent Volumes (PV) and Claims (PVC) ### Persistent Volumes - **Cluster-wide storage resource** - Independent lifecycle from pods - Administrator provisioned or dynamic - Various storage backends supported \`\`\`yaml apiVersion: v1 kind: PersistentVolume metadata: name: pv0003 spec: capacity: storage: 5Gi volumeMode: Filesystem accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Recycle storageClassName: slow nfs: path: /tmp server: 172.17.0.2 \`\`\` ### Persistent Volume Claims - **Request for storage** by users - Specifies size, access modes, storage class - Binds to appropriate PV - Used by pods to access storage \`\`\`yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: myclaim spec: accessModes: - ReadWriteOnce resources: requests: storage: 8Gi storageClassName: slow \`\`\` ### Access Modes #### ReadWriteOnce (RWO) - **Single node** can mount for read-write - Most common for databases - Block storage typically #### ReadOnlyMany (ROX) - **Multiple nodes** can mount for read-only - Good for shared configuration - Network storage usually #### ReadWriteMany (RWX) - **Multiple nodes** can mount for read-write - Requires special storage systems - NFS, distributed storage ### Volume Lifecycle 1. **Provisioning**: PV created (static/dynamic) 2. **Binding**: PVC bound to suitable PV 3. **Using**: Pod uses PVC in volume mount 4. **Releasing**: PVC deleted, PV released 5. **Reclaiming**: PV reclaimed based on policy ### Reclaim Policies #### Retain - **Manual cleanup** required - Data preserved for recovery - PV not available for new claims #### Delete - **Automatic cleanup** of storage - Both PV and underlying storage deleted - Default for dynamic provisioning #### Recycle (Deprecated) - **Basic scrub** of volume (rm -rf /*) - PV available for new claims - Not recommended for production` }, { title: "Storage Classes and Dynamic Provisioning", content: `# Storage Classes and Dynamic Provisioning ## Storage Classes ### What are Storage Classes? **Storage Classes** define different types of storage available in a Kubernetes cluster, enabling dynamic provisioning of Persistent Volumes. ### Key Components #### Provisioner - **Creates storage** when requested - Cloud provider or storage system specific - Examples: kubernetes.io/aws-ebs, kubernetes.io/gce-pd #### Parameters - **Storage-specific configuration** - Disk type, IOPS, encryption settings - Varies by provisioner #### Reclaim Policy - **What happens** when PVC is deleted - Delete, Retain, or Recycle #### Mount Options - **Filesystem mount options** - Performance and security settings ### Example Storage Class \`\`\`yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: fast-ssd provisioner: kubernetes.io/aws-ebs parameters: type: gp3 iops: "3000" throughput: "125" encrypted: "true" reclaimPolicy: Delete allowVolumeExpansion: true mountOptions: - debug volumeBindingMode: WaitForFirstConsumer \`\`\` ## Dynamic Provisioning ### How It Works 1. **User creates PVC** specifying storage class 2. **Storage controller** watches for new PVCs 3. **Provisioner** creates storage in backend 4. **PV created** and bound to PVC automatically 5. **Pod** can use the storage immediately ### Benefits - **No pre-provisioning** required - **Automatic lifecycle** management - **Self-service** for developers - **Cost efficiency** - create only what's needed ### Volume Binding Modes #### Immediate - **PV created immediately** when PVC is created - May cause scheduling issues - Default mode #### WaitForFirstConsumer - **Delays PV creation** until pod is scheduled - Ensures volume is created in correct zone - Better for multi-zone clusters ## Cloud Provider Storage ### AWS Storage Options #### EBS (Elastic Block Store) - **Block storage** for EC2 instances - Different volume types (gp3, io2, st1) - Automatic backups with snapshots - Single AZ attachment \`\`\`yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: aws-ebs-gp3 provisioner: ebs.csi.aws.com parameters: type: gp3 throughput: "250" iops: "3000" allowVolumeExpansion: true \`\`\` #### EFS (Elastic File System) - **Network file system** - Multi-AZ access - ReadWriteMany support - Serverless scaling ### Google Cloud Storage Options #### Persistent Disks - **Block storage** for GCE instances - Standard and SSD options - Regional persistent disks - Automatic encryption \`\`\`yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: gce-pd-ssd provisioner: pd.csi.storage.gke.io parameters: type: pd-ssd zones: us-central1-a,us-central1-b \`\`\` #### Cloud Filestore - **Managed NFS** service - High performance - ReadWriteMany support ### Azure Storage Options #### Azure Disks - **Block storage** for VMs - Premium and Standard options - Zone-redundant storage - Disk encryption #### Azure Files - **Managed file shares** - SMB and NFS protocols - Multi-instance access ## Storage Performance ### Performance Characteristics #### Throughput - **Data transfer rate** (MB/s) - Important for sequential workloads - Varies by storage type and size #### IOPS (Input/Output Operations Per Second) - **Random access performance** - Critical for databases - Depends on workload patterns #### Latency - **Response time** for storage operations - Important for interactive applications - Affected by storage type and distance ### Performance Optimization #### Choose Right Storage Type - **SSDs** for high IOPS workloads - **HDDs** for throughput-intensive workloads - **Network storage** for shared access #### Volume Size Considerations - **Larger volumes** often have higher performance - IOPS and throughput may scale with size - Cost vs performance tradeoffs #### Topology Awareness - **Zone/region placement** affects latency - Co-locate storage and compute when possible - Use topology spread constraints ## Storage Monitoring ### Key Metrics #### Volume Utilization - **Disk space usage** - Alert before volumes fill up - Capacity planning #### Performance Metrics - **IOPS and throughput** monitoring - Latency measurements - Queue depths #### Error Rates - **I/O errors** and failures - Storage backend health - Network connectivity issues ### Monitoring Tools #### Prometheus - **Storage metrics** collection - Custom exporters for storage systems - Alerting on thresholds #### Kubernetes Events - **PV/PVC events** in cluster - Binding and provisioning status - Error conditions ### Troubleshooting Common Issues #### PVC Stuck Pending - **Check storage class** exists - Verify provisioner is running - Resource quotas and limits - Node/zone availability #### Mount Failures - **File system** compatibility - Mount options conflicts - Permission issues - Network connectivity` }, { title: "StatefulSets and Data Persistence", content: `# StatefulSets and Data Persistence ## StatefulSet Fundamentals ### What are StatefulSets? **StatefulSets** are Kubernetes workloads designed for applications that require stable, unique network identities and persistent storage. ### Key Characteristics #### Stable Network Identity - **Predictable pod names**: pod-0, pod-1, pod-2 - **Stable DNS names**: pod-0.service.namespace.svc.cluster.local - **Persistent across restarts** #### Ordered Deployment and Scaling - **Sequential creation**: pod-0 before pod-1 - **Reverse order deletion**: pod-2 before pod-1 - **Rolling updates** maintain order #### Persistent Storage - **Unique PVC** for each pod - **Survives pod restart** and rescheduling - **Automatic PVC creation** ### StatefulSet vs Deployment | Feature | StatefulSet | Deployment | |---------|-------------|------------| | Pod Identity | Stable, ordered | Random | | Storage | Persistent per pod | Shared or ephemeral | | Network | Stable DNS names | Service-based LB | | Scaling | Ordered | Parallel | | Use Case | Databases, queues | Stateless apps | ## StatefulSet Configuration ### Basic StatefulSet Example \`\`\`yaml apiVersion: apps/v1 kind: StatefulSet metadata: name: mysql spec: serviceName: mysql-headless replicas: 3 selector: matchLabels: app: mysql template: metadata: labels: app: mysql spec: containers: - name: mysql image: mysql:8.0 env: - name: MYSQL_ROOT_PASSWORD value: "rootpassword" ports: - containerPort: 3306 volumeMounts: - name: mysql-storage mountPath: /var/lib/mysql volumeClaimTemplates: - metadata: name: mysql-storage spec: accessModes: ["ReadWriteOnce"] resources: requests: storage: 10Gi storageClassName: fast-ssd \`\`\` ### Headless Service \`\`\`yaml apiVersion: v1 kind: Service metadata: name: mysql-headless spec: clusterIP: None # Headless service selector: app: mysql ports: - port: 3306 \`\`\` ## Volume Claim Templates ### Purpose - **Automatic PVC creation** for each pod - **Unique storage** per StatefulSet pod - **Persistent** across pod lifecycle ### Template Structure \`\`\`yaml volumeClaimTemplates: - metadata: name: data labels: app: myapp annotations: volume.beta.kubernetes.io/storage-class: "fast" spec: accessModes: ["ReadWriteOnce"] resources: requests: storage: 20Gi \`\`\` ### PVC Naming Convention - **Format**: \`--\` - **Example**: data-mysql-0, data-mysql-1, data-mysql-2 - **Persistent** even when pods are deleted ## Common StatefulSet Patterns ### Database Clusters #### Primary-Replica MySQL \`\`\`yaml apiVersion: apps/v1 kind: StatefulSet metadata: name: mysql spec: replicas: 3 serviceName: mysql-headless template: spec: initContainers: - name: init-mysql image: mysql:8.0 command: - bash - "-c" - | set -ex # Generate server-id from pod ordinal echo [mysqld] > /mnt/conf.d/server-id.cnf echo server-id=$((100 + $HOSTNAME_ORDINAL)) >> /mnt/conf.d/server-id.cnf # Setup replication if not primary if [[ $HOSTNAME_ORDINAL -ne 0 ]]; then echo log-slave-updates >> /mnt/conf.d/server-id.cnf fi volumeMounts: - name: conf mountPath: /mnt/conf.d env: - name: HOSTNAME_ORDINAL valueFrom: fieldRef: fieldPath: metadata.name \`\`\` ### Message Queues #### Apache Kafka - **Broker identification** using pod ordinal - **Persistent log storage** per broker - **Zookeeper coordination** for cluster management ### Distributed Databases #### Apache Cassandra - **Seed nodes** for cluster bootstrapping - **Data replication** across nodes - **Consistent hashing** for data distribution ## StatefulSet Operations ### Scaling StatefulSets #### Scale Up - **New pods created** in order - **PVCs created** automatically - **Joins cluster** after previous pod ready #### Scale Down - **Pods terminated** in reverse order - **PVCs retained** by default - **Data preserved** for future scale up ### Rolling Updates #### Update Strategy \`\`\`yaml spec: updateStrategy: type: RollingUpdate rollingUpdate: partition: 2 # Update pods with ordinal >= 2 \`\`\` #### Staged Updates - **Partition parameter** controls which pods update - **Gradual rollout** to test changes - **Rollback capability** if issues found ### Pod Management Policies #### OrderedReady (Default) - **Sequential** pod creation/deletion - **Waits for readiness** before next pod - **Safer** for stateful applications #### Parallel - **Concurrent** pod operations - **Faster** scaling and updates - **Less safe** for data consistency ## Data Management Best Practices ### Backup Strategies #### Volume Snapshots - **Point-in-time** storage snapshots - **CSI snapshot** support - **Application-consistent** backups #### Application-Level Backups - **Database dumps** and exports - **Consistent** data state - **Cross-platform** portability ### Disaster Recovery #### Multi-Zone Deployment - **Zone-aware** pod placement - **Replicated storage** across zones - **High availability** during zone failures #### Cross-Region Replication - **Async replication** to remote regions - **Recovery time** considerations - **Network latency** impact ### Monitoring StatefulSets #### Key Metrics - **Pod readiness** and availability - **Storage utilization** per pod - **Replication lag** for databases - **Cluster membership** status #### Health Checks - **Liveness probes** for pod health - **Readiness probes** for traffic acceptance - **Custom health** endpoints ### Troubleshooting #### Common Issues - **PVC provisioning** failures - **Init container** failures - **Network partition** handling - **Split-brain** scenarios #### Debug Commands \`\`\`bash # Check StatefulSet status kubectl describe statefulset mysql # Check PVC status kubectl get pvc # Check pod logs kubectl logs mysql-0 # Check service endpoints kubectl get endpoints mysql-headless \`\`\`` } ] } ]; // Comprehensive Quiz Database const quizzes = [ { title: "Kubernetes Architecture Deep Dive", timeLimit: 600, category: "fundamentals", questions: [ { question: "Which component is responsible for making scheduling decisions in Kubernetes?", options: ["kubelet", "kube-proxy", "kube-scheduler", "etcd"], correct: 2, explanation: "The kube-scheduler is responsible for assigning pods to nodes based on resource requirements, constraints, and policies." }, { question: "What is the primary function of etcd in a Kubernetes cluster?", options: ["Container runtime", "Distributed key-value store", "Network proxy", "Load balancer"], correct: 1, explanation: "etcd is the distributed key-value store that stores all cluster data, maintaining cluster state and configuration." }, { question: "Which node component ensures that containers are running in pods?", options: ["kube-proxy", "kubelet", "containerd", "kube-scheduler"], correct: 1, explanation: "The kubelet is the primary node agent that manages containers and ensures they are running in pods." }, { question: "What does the kube-proxy component handle?", options: ["Pod scheduling", "Service networking and load balancing", "Image pulling", "Storage management"], correct: 1, explanation: "kube-proxy handles service networking by maintaining network rules and implementing load balancing for services." }, { question: "Which API server validation occurs first?", options: ["Authorization", "Admission Control", "Authentication", "Resource Validation"], correct: 2, explanation: "Authentication occurs first to identify who is making the request, followed by authorization and admission control." } ] }, { title: "Pod and Workload Management", timeLimit: 480, category: "fundamentals", questions: [ { question: "What is the smallest deployable unit in Kubernetes?", options: ["Container", "Pod", "Deployment", "Service"], correct: 1, explanation: "A Pod is the smallest deployable unit in Kubernetes and can contain one or more containers that share resources." }, { question: "Which workload type ensures that a pod runs on all nodes in the cluster?", options: ["Deployment", "StatefulSet", "DaemonSet", "Job"], correct: 2, explanation: "DaemonSet ensures that a copy of a pod runs on all (or selected) nodes in the cluster." }, { question: "What type of workload is best for stateful applications requiring stable network identities?", options: ["Deployment", "StatefulSet", "ReplicaSet", "DaemonSet"], correct: 1, explanation: "StatefulSet is designed for stateful applications that require stable network identities and persistent storage." }, { question: "Which workload type is used for running batch processing tasks to completion?", options: ["Deployment", "StatefulSet", "Job", "CronJob"], correct: 2, explanation: "Job runs pods to completion and ensures successful termination, making it ideal for batch processing tasks." }, { question: "What is the difference between a Job and a CronJob?", options: ["Jobs run continuously, CronJobs run once", "No difference", "CronJobs run on a schedule, Jobs run once", "CronJobs are deprecated"], correct: 2, explanation: "CronJobs run Jobs on a time-based schedule using cron syntax, while Jobs run once to completion." } ] }, { title: "Kubernetes Networking Mastery", timeLimit: 540, category: "networking", questions: [ { question: "What is the default service type in Kubernetes?", options: ["NodePort", "LoadBalancer", "ClusterIP", "ExternalName"], correct: 2, explanation: "ClusterIP is the default service type, providing internal access only within the cluster." }, { question: "Which service type provides a stable endpoint but no load balancing?", options: ["ClusterIP", "NodePort", "LoadBalancer", "Headless"], correct: 3, explanation: "Headless services (ClusterIP: None) provide stable endpoints without load balancing, returning pod IPs directly via DNS." }, { question: "What port range is used for NodePort services?", options: ["1024-65535", "30000-32767", "8000-9000", "80-8080"], correct: 1, explanation: "NodePort services use the port range 30000-32767 to expose services on each node's IP." }, { question: "Which component provides DNS resolution for services in Kubernetes?", options: ["kube-dns", "CoreDNS", "etcd", "kube-proxy"], correct: 1, explanation: "CoreDNS is the default DNS server in modern Kubernetes clusters, providing automatic DNS resolution for services." }, { question: "What is the purpose of Network Policies in Kubernetes?", options: ["Load balancing", "Service discovery", "Firewall rules for pods", "Ingress routing"], correct: 2, explanation: "Network Policies act as firewall rules for pods, controlling ingress and egress traffic based on labels and namespaces." } ] }, { title: "Container Runtime & OCI Deep Dive", timeLimit: 420, category: "runtime", questions: [ { question: "What does OCI stand for?", options: ["Open Container Initiative", "Orchestration Container Interface", "Open Cloud Infrastructure", "Operational Container Integration"], correct: 0, explanation: "OCI stands for Open Container Initiative, which creates open industry standards for container formats and runtimes." }, { question: "Which is the reference implementation of the OCI runtime specification?", options: ["Docker", "containerd", "runC", "CRI-O"], correct: 2, explanation: "runC is the reference implementation of the OCI runtime specification and is used by most container runtimes." }, { question: "What type of isolation does Kata Containers provide?", options: ["Process isolation", "Namespace isolation", "VM-level isolation", "Network isolation"], correct: 2, explanation: "Kata Containers provides VM-level isolation using lightweight VMs while maintaining container compatibility." }, { question: "What does gVisor provide for container security?", options: ["Network encryption", "Application-level sandboxing", "Image scanning", "Secret management"], correct: 1, explanation: "gVisor provides application-level sandboxing by intercepting and handling system calls in user space." }, { question: "Which runtime is specifically designed for Kubernetes integration?", options: ["Docker", "runC", "CRI-O", "containerd"], correct: 2, explanation: "CRI-O is specifically designed for Kubernetes and implements the Container Runtime Interface (CRI)." } ] }, { title: "Cloud Native Architecture Patterns", timeLimit: 600, category: "architecture", questions: [ { question: "What is the main principle behind GitOps?", options: ["Using Git for code only", "Declarative infrastructure managed through Git", "Automated testing", "Container deployment"], correct: 1, explanation: "GitOps uses Git repositories as the single source of truth for declarative infrastructure and application configuration." }, { question: "Which of the following is NOT one of the 12-Factor App principles?", options: ["Stateless processes", "Port binding", "Microservices architecture", "Dev/prod parity"], correct: 2, explanation: "Microservices architecture is not one of the 12-Factor App principles, though it aligns with cloud native practices." }, { question: "What is the primary benefit of a service mesh?", options: ["Faster deployment", "Service-to-service communication management", "Container orchestration", "Storage management"], correct: 1, explanation: "Service mesh provides a dedicated infrastructure layer for service-to-service communication, handling discovery, load balancing, and security." }, { question: "Which pattern helps prevent cascade failures in distributed systems?", options: ["Bulkhead", "Circuit Breaker", "Saga", "Observer"], correct: 1, explanation: "Circuit Breaker pattern prevents cascade failures by failing fast when downstream services are unavailable." }, { question: "What is Infrastructure as Code (IaC)?", options: ["Writing application code", "Managing infrastructure through code", "Container orchestration", "Service monitoring"], correct: 1, explanation: "Infrastructure as Code treats infrastructure configuration as software code that can be versioned, tested, and deployed." } ] }, { title: "Serverless and Edge Computing", timeLimit: 360, category: "serverless", questions: [ { question: "Which Kubernetes distribution is specifically designed for edge and IoT environments?", options: ["minikube", "k3s", "microk8s", "kind"], correct: 1, explanation: "k3s is a lightweight Kubernetes distribution designed for edge and IoT environments with minimal resource requirements." }, { question: "What is a key characteristic of serverless computing?", options: ["Always-on servers", "Manual scaling", "Pay-per-execution", "Fixed pricing"], correct: 2, explanation: "Serverless computing uses a pay-per-execution model where you only pay for actual function invocations and execution time." }, { question: "Which project provides serverless capabilities on Kubernetes?", options: ["Istio", "Knative", "Helm", "Prometheus"], correct: 1, explanation: "Knative is a Kubernetes-based platform for deploying and managing serverless workloads with scale-to-zero capabilities." }, { question: "What is the main advantage of edge computing?", options: ["Lower costs", "Reduced latency", "Better security", "Easier management"], correct: 1, explanation: "Edge computing's main advantage is reduced latency by bringing computation and data storage closer to data sources." }, { question: "What makes k3s suitable for edge deployments?", options: ["Large resource requirements", "Single binary distribution with minimal footprint", "Complex setup process", "Requires external dependencies"], correct: 1, explanation: "k3s is distributed as a single binary (<100MB) with minimal resource requirements, making it perfect for edge environments." } ] }, { title: "Security and RBAC Mastery", timeLimit: 720, category: "security", questions: [ { question: "What is the default authorization mode in a basic Kubernetes setup?", options: ["RBAC", "ABAC", "AlwaysAllow", "AlwaysDeny"], correct: 2, explanation: "AlwaysAllow is often the default authorization mode in basic setups, though RBAC should be used in production." }, { question: "How are Kubernetes Secrets encoded by default?", options: ["AES-256 encryption", "Base64 encoding", "SHA-256 hashing", "Plain text"], correct: 1, explanation: "Kubernetes Secrets are base64 encoded by default, which is not encryption and can be easily decoded." }, { question: "What does OPA (Open Policy Agent) provide in Kubernetes?", options: ["Container runtime", "Policy enforcement and validation", "Service mesh", "Storage management"], correct: 1, explanation: "OPA provides policy enforcement and validation, allowing fine-grained control over what actions are allowed in the cluster." }, { question: "Which RBAC resource grants permissions within a specific namespace?", options: ["ClusterRole", "Role", "ClusterRoleBinding", "RoleBinding"], correct: 1, explanation: "A Role grants permissions within a specific namespace, while ClusterRole grants cluster-wide permissions." }, { question: "What language is used to write OPA policies?", options: ["YAML", "JSON", "Rego", "JavaScript"], correct: 2, explanation: "Rego is the purpose-built policy language used to write OPA policies." }, { question: "Which admission controller can modify requests before they are processed?", options: ["ValidatingAdmissionWebhook", "MutatingAdmissionWebhook", "ResourceQuota", "LimitRanger"], correct: 1, explanation: "MutatingAdmissionWebhook can modify requests before processing, while ValidatingAdmissionWebhook can only accept or reject them." } ] }, { title: "Storage and Data Management", timeLimit: 540, category: "storage", questions: [ { question: "Which access mode allows multiple nodes to mount a volume for read-write operations?", options: ["ReadWriteOnce", "ReadOnlyMany", "ReadWriteMany", "WriteOnlyMany"], correct: 2, explanation: "ReadWriteMany (RWX) allows multiple nodes to mount a volume for read-write operations, typically requiring network storage." }, { question: "What is the purpose of a StorageClass in Kubernetes?", options: ["Define pod storage limits", "Enable dynamic provisioning of storage", "Manage container images", "Configure network policies"], correct: 1, explanation: "StorageClass defines different types of storage and enables dynamic provisioning of PersistentVolumes." }, { question: "Which volume type provides temporary storage that is shared between containers in the same pod?", options: ["hostPath", "emptyDir", "persistentVolumeClaim", "configMap"], correct: 1, explanation: "emptyDir provides temporary storage shared between containers in the same pod and is deleted when the pod is removed." }, { question: "What happens to a PersistentVolume when its reclaim policy is set to 'Retain'?", options: ["Automatically deleted", "Available for immediate reuse", "Manual cleanup required", "Converted to emptyDir"], correct: 2, explanation: "With 'Retain' policy, manual cleanup is required and the PV is not automatically available for new claims." }, { question: "Which workload type automatically creates unique PersistentVolumeClaims for each pod?", options: ["Deployment", "StatefulSet", "DaemonSet", "Job"], correct: 1, explanation: "StatefulSet uses volumeClaimTemplates to automatically create unique PVCs for each pod." } ] }, { title: "Advanced Kubernetes Concepts", timeLimit: 600, category: "advanced", questions: [ { question: "What is the difference between Horizontal Pod Autoscaler (HPA) and Cluster Autoscaler?", options: ["HPA scales nodes, Cluster Autoscaler scales pods", "Both scale pods", "HPA scales pods, Cluster Autoscaler scales nodes", "No difference"], correct: 2, explanation: "HPA scales the number of pods in a deployment, while Cluster Autoscaler scales the number of nodes in the cluster." }, { question: "What does the Vertical Pod Autoscaler (VPA) adjust?", options: ["Number of pods", "CPU and memory requests/limits", "Storage capacity", "Network bandwidth"], correct: 1, explanation: "VPA adjusts the CPU and memory requests and limits for containers based on historical usage patterns." }, { question: "Which component provides the Kubernetes API extension mechanism?", options: ["etcd", "API Aggregation Layer", "kubelet", "kube-proxy"], correct: 1, explanation: "The API Aggregation Layer allows extending the Kubernetes API with custom resources and API servers." }, { question: "What is the purpose of Custom Resource Definitions (CRDs)?", options: ["Define new API resources", "Configure networking", "Manage storage", "Handle authentication"], correct: 0, explanation: "CRDs allow you to define new API resources and extend the Kubernetes API with custom objects." }, { question: "Which probe type should be used to determine if a container is ready to accept traffic?", options: ["livenessProbe", "readinessProbe", "startupProbe", "healthProbe"], correct: 1, explanation: "readinessProbe determines if a container is ready to accept traffic and should be included in service endpoints." } ] }, { title: "KCNA Mock Exam - 25 Questions", timeLimit: 900, // 15 minutes category: "mock", questions: [ { question: "What is the primary function of the Kubernetes scheduler?", options: ["Manage network traffic", "Assign pods to nodes", "Store cluster state", "Handle authentication"], correct: 1, explanation: "The Kubernetes scheduler assigns pods to nodes based on resource requirements and constraints." }, { question: "Which service type exposes an application externally using a cloud provider's load balancer?", options: ["ClusterIP", "NodePort", "LoadBalancer", "Headless"], correct: 2, explanation: "LoadBalancer service type uses the cloud provider's load balancer to expose services externally." }, { question: "What does a DaemonSet ensure in a Kubernetes cluster?", options: ["Pods run in a specific order", "A pod runs on every node", "Pods have persistent storage", "Pods scale automatically"], correct: 1, explanation: "DaemonSet ensures that a copy of a pod runs on all (or selected) nodes in the cluster." }, { question: "Which container runtime provides VM-level isolation?", options: ["runC", "containerd", "Kata Containers", "CRI-O"], correct: 2, explanation: "Kata Containers provides VM-level isolation using lightweight virtual machines." }, { question: "What is the main benefit of using GitOps?", options: ["Faster builds", "Declarative infrastructure management", "Better monitoring", "Reduced costs"], correct: 1, explanation: "GitOps provides declarative infrastructure management using Git as the single source of truth." }, { question: "Which Kubernetes distribution is designed for edge computing?", options: ["minikube", "k3s", "OpenShift", "Docker Desktop"], correct: 1, explanation: "k3s is a lightweight Kubernetes distribution specifically designed for edge and IoT environments." }, { question: "How are Kubernetes Secrets stored by default?", options: ["Encrypted", "Base64 encoded", "Plain text", "Hashed"], correct: 1, explanation: "Kubernetes Secrets are base64 encoded by default, not encrypted." }, { question: "What does RBAC stand for in Kubernetes security?", options: ["Resource-Based Access Control", "Role-Based Access Control", "Rule-Based Access Control", "Request-Based Access Control"], correct: 1, explanation: "RBAC stands for Role-Based Access Control, the primary authorization mechanism in Kubernetes." }, { question: "Which access mode allows multiple nodes to mount a volume for reading?", options: ["ReadWriteOnce", "ReadOnlyMany", "ReadWriteMany", "WriteOnlyOnce"], correct: 1, explanation: "ReadOnlyMany allows multiple nodes to mount a volume for read-only access." }, { question: "What is the purpose of a StatefulSet in Kubernetes?", options: ["Run stateless applications", "Manage stateful applications with stable identities", "Handle batch jobs", "Provide load balancing"], correct: 1, explanation: "StatefulSet manages stateful applications that require stable network identities and persistent storage." }, { question: "Which component handles service networking in Kubernetes?", options: ["kubelet", "kube-scheduler", "kube-proxy", "etcd"], correct: 2, explanation: "kube-proxy handles service networking by maintaining network rules and implementing load balancing." }, { question: "What does OCI stand for in container technology?", options: ["Open Container Initiative", "Orchestrated Container Interface", "Open Cloud Infrastructure", "Operational Container Integration"], correct: 0, explanation: "OCI stands for Open Container Initiative, which creates standards for container formats and runtimes." }, { question: "Which workload type is best for running batch processing jobs?", options: ["Deployment", "DaemonSet", "StatefulSet", "Job"], correct: 3, explanation: "Job workload type is designed for running batch processing tasks that need to run to completion." }, { question: "What is the main advantage of microservices architecture?", options: ["Lower complexity", "Independent development and deployment", "Reduced network traffic", "Simplified monitoring"], correct: 1, explanation: "Microservices architecture allows independent development and deployment of services." }, { question: "Which policy language is used with Open Policy Agent (OPA)?", options: ["YAML", "JSON", "Rego", "Python"], correct: 2, explanation: "Rego is the purpose-built policy language used to write OPA policies." }, { question: "What does Infrastructure as Code (IaC) enable?", options: ["Faster applications", "Version-controlled infrastructure", "Better security", "Reduced costs"], correct: 1, explanation: "Infrastructure as Code enables version-controlled, repeatable infrastructure management." }, { question: "Which volume type provides persistent storage that survives pod restarts?", options: ["emptyDir", "hostPath", "PersistentVolumeClaim", "configMap"], correct: 2, explanation: "PersistentVolumeClaim provides persistent storage that survives pod restarts and rescheduling." }, { question: "What is the primary purpose of Knative?", options: ["Container orchestration", "Serverless workloads on Kubernetes", "Service mesh", "Storage management"], correct: 1, explanation: "Knative provides serverless capabilities on Kubernetes with scale-to-zero functionality." }, { question: "Which autoscaler adjusts CPU and memory requests for containers?", options: ["Horizontal Pod Autoscaler", "Vertical Pod Autoscaler", "Cluster Autoscaler", "Node Autoscaler"], correct: 1, explanation: "Vertical Pod Autoscaler (VPA) adjusts CPU and memory requests and limits based on usage patterns." }, { question: "What is the default DNS server in modern Kubernetes clusters?", options: ["kube-dns", "CoreDNS", "Bind9", "dnsmasq"], correct: 1, explanation: "CoreDNS is the default DNS server in modern Kubernetes clusters." }, { question: "Which probe determines if a container should be restarted?", options: ["readinessProbe", "livenessProbe", "startupProbe", "healthProbe"], correct: 1, explanation: "livenessProbe determines if a container should be restarted when it becomes unhealthy." }, { question: "What does gVisor provide for container security?", options: ["Network isolation", "Application-level sandboxing", "Image scanning", "Secret encryption"], correct: 1, explanation: "gVisor provides application-level sandboxing by intercepting system calls in user space." }, { question: "Which service provides a stable endpoint without load balancing?", options: ["ClusterIP", "NodePort", "LoadBalancer", "Headless"], correct: 3, explanation: "Headless services provide stable endpoints without load balancing, returning pod IPs directly." }, { question: "What is the main characteristic of serverless computing?", options: ["Always-on servers", "Manual scaling", "Event-driven execution", "Fixed resource allocation"], correct: 2, explanation: "Serverless computing is characterized by event-driven execution with automatic scaling." }, { question: "Which CNCF project is used for distributed tracing?", options: ["Prometheus", "Fluentd", "Jaeger", "Envoy"], correct: 2, explanation: "Jaeger is the CNCF project used for distributed tracing in cloud native applications." } ] } ]; // Enhanced Flashcards with categories const flashcards = [ { category: "Architecture", question: "What is the primary function of etcd?", answer: "Distributed key-value store that maintains cluster state" }, { category: "Architecture", question: "Which component makes pod scheduling decisions?", answer: "kube-scheduler" }, { category: "Architecture", question: "What does kubelet do?", answer: "Node agent that manages containers and ensures pods are running" }, { category: "Architecture", question: "Role of kube-proxy?", answer: "Handles service networking and load balancing" }, { category: "Workloads", question: "Best workload for stateless applications?", answer: "Deployment" }, { category: "Workloads", question: "Which workload ensures pods run on all nodes?", answer: "DaemonSet" }, { category: "Workloads", question: "Workload for applications needing stable identity?", answer: "StatefulSet" }, { category: "Workloads", question: "Best for batch processing tasks?", answer: "Job" }, { category: "Workloads", question: "How to run jobs on a schedule?", answer: "CronJob" }, { category: "Networking", question: "Default service type in Kubernetes?", answer: "ClusterIP" }, { category: "Networking", question: "Service type for external cloud load balancer?", answer: "LoadBalancer" }, { category: "Networking", question: "Service with no cluster IP?", answer: "Headless Service" }, { category: "Networking", question: "NodePort service port range?", answer: "30000-32767" }, { category: "Networking", question: "Default DNS server in K8s?", answer: "CoreDNS" }, { category: "Storage", question: "Volume type for temporary pod storage?", answer: "emptyDir" }, { category: "Storage", question: "Volume access mode for single node read-write?", answer: "ReadWriteOnce (RWO)" }, { category: "Storage", question: "Volume access mode for multi-node read-write?", answer: "ReadWriteMany (RWX)" }, { category: "Storage", question: "What enables dynamic volume provisioning?", answer: "StorageClass" }, { category: "Security", question: "Default authorization mode?", answer: "AlwaysAllow (in basic setups)" }, { category: "Security", question: "How are Secrets encoded?", answer: "Base64 encoded (not encrypted)" }, { category: "Security", question: "What does RBAC stand for?", answer: "Role-Based Access Control" }, { category: "Security", question: "OPA policy language?", answer: "Rego" }, { category: "Security", question: "Which admission controller can modify requests?", answer: "MutatingAdmissionWebhook" }, { category: "Container Runtime", question: "What does OCI stand for?", answer: "Open Container Initiative" }, { category: "Container Runtime", question: "OCI runtime reference implementation?", answer: "runC" }, { category: "Container Runtime", question: "Container runtime with VM isolation?", answer: "Kata Containers" }, { category: "Container Runtime", question: "Runtime providing application sandboxing?", answer: "gVisor" }, { category: "Cloud Native", question: "What is GitOps?", answer: "Infrastructure management using Git as single source of truth" }, { category: "Cloud Native", question: "Lightweight K8s for edge computing?", answer: "k3s" }, { category: "Cloud Native", question: "Kubernetes serverless platform?", answer: "Knative" }, { category: "Cloud Native", question: "What does IaC stand for?", answer: "Infrastructure as Code" }, { category: "Autoscaling", question: "What does HPA scale?", answer: "Number of pods (horizontally)" }, { category: "Autoscaling", question: "What does VPA scale?", answer: "CPU and memory resources (vertically)" }, { category: "Autoscaling", question: "What does Cluster Autoscaler scale?", answer: "Number of nodes in cluster" }, { category: "Monitoring", question: "Probe to check if container should be restarted?", answer: "livenessProbe" }, { category: "Monitoring", question: "Probe to check if container is ready for traffic?", answer: "readinessProbe" }, { category: "Advanced", question: "What do CRDs enable?", answer: "Custom Resource Definitions - extend K8s API" }, { category: "Advanced", question: "Component for extending K8s API?", answer: "API Aggregation Layer" } ]; // Timer effect useEffect(() => { let timer; if (timerActive && timeLeft > 0) { timer = setInterval(() => { setTimeLeft(prev => prev - 1); }, 1000); } else if (timeLeft === 0 && timerActive) { handleQuizComplete(); } return () => clearInterval(timer); }, [timerActive, timeLeft]); const formatTime = (seconds) => { const mins = Math.floor(seconds / 60); const secs = seconds % 60; return `${mins}:${secs.toString().padStart(2, '0')}`; }; const startCourse = (courseIndex) => { setCurrentCourse(courseIndex); setCurrentLesson(0); setMode('course'); }; const startQuiz = (quizIndex) => { setCurrentQuiz(quizIndex); setCurrentQuestion(0); setScore(0); setAnswers([]); setSelectedAnswer(''); setShowResult(false); setTimeLeft(quizzes[quizIndex].timeLimit); setTimerActive(true); setMode('quiz'); }; const handleAnswerSelect = (answer) => { setSelectedAnswer(answer); }; const handleNextQuestion = () => { const newAnswers = [...answers, selectedAnswer]; setAnswers(newAnswers); if (selectedAnswer == quizzes[currentQuiz].questions[currentQuestion].correct) { setScore(score + 1); } if (currentQuestion + 1 < quizzes[currentQuiz].questions.length) { setCurrentQuestion(currentQuestion + 1); setSelectedAnswer(''); } else { handleQuizComplete(); } }; const handleQuizComplete = () => { setTimerActive(false); setShowResult(true); const quizKey = `quiz_${currentQuiz}`; const percentage = Math.round((score / quizzes[currentQuiz].questions.length) * 100); setQuizScores(prev => ({ ...prev, [quizKey]: Math.max(prev[quizKey] || 0, percentage) })); }; const resetQuiz = () => { setCurrentQuestion(0); setScore(0); setAnswers([]); setSelectedAnswer(''); setShowResult(false); setTimerActive(false); }; const startFlashcards = () => { setFlashcardIndex(0); setShowAnswer(false); setMode('flashcards'); }; const nextFlashcard = () => { setFlashcardIndex((prev) => (prev + 1) % flashcards.length); setShowAnswer(false); }; const prevFlashcard = () => { setFlashcardIndex((prev) => (prev - 1 + flashcards.length) % flashcards.length); setShowAnswer(false); }; const shuffleFlashcards = () => { const randomIndex = Math.floor(Math.random() * flashcards.length); setFlashcardIndex(randomIndex); setShowAnswer(false); }; const markLessonComplete = (courseIndex, lessonIndex) => { const lessonKey = `${courseIndex}-${lessonIndex}`; setCompletedLessons(prev => new Set([...prev, lessonKey])); }; // Main Menu if (mode === 'menu') { return (

KCNA Complete Learning System

Master Kubernetes and Cloud Native concepts with comprehensive courses and practice

5 Complete Courses 10 Practice Quizzes 38 Flashcards

{/* Learning Paths */}

{/* Courses Section */}

Learning Courses

{courses.map((course, index) => ( {course.icon}

{course.title}

{course.description}

{course.lessons.length} lessons {[...completedLessons].filter(key => key.startsWith(`${index}-`)).length} completed

))}

{/* Practice Section */}

Practice & Test

{/* Flashcards */} Smart Flashcards

{flashcards.length} cards across {[...new Set(flashcards.map(f => f.category))].length} categories

Quick review of essential concepts with categorized cards

{/* Quiz Categories */}

{quizzes.slice(0, 4).map((quiz, index) => ( {quiz.title}

{Math.floor(quiz.timeLimit / 60)}m {quiz.questions.length}Q {quizScores[`quiz_${index}`] && ( {quizScores[`quiz_${index}`]}% )}

))} {/* Mock Exam Highlight */} {quizzes[quizzes.length - 1].title}

Full exam simulation - 25 questions in 15 minutes

{/* Study Progress */} Study Tips

• Complete courses sequentially for best learning

• Use flashcards for daily review sessions

• Practice quizzes after each course module

• Take mock exam when consistently scoring 80%+

• Real KCNA: 25 questions, 15 minutes, 80% to pass

); } // Course Mode if (mode === 'course') { const course = courses[currentCourse]; const lesson = course.lessons[currentLesson]; const isCompleted = completedLessons.has(`${currentCourse}-${currentLesson}`); return (

{course.title}

{course.description}

Lesson {currentLesson + 1} of {course.lessons.length}

{lesson.title}

{/* Lesson Navigation */}

{course.lessons.map((lessonItem, index) => ( ))}

{/* Lesson Content */} {lesson.title} {isCompleted && }

{lesson.content}

{/* Navigation Controls */}

{!isCompleted && ( )}

); } // Quiz Mode if (mode === 'quiz') { const quiz = quizzes[currentQuiz]; const question = quiz.questions[currentQuestion]; if (showResult) { const percentage = Math.round((score / quiz.questions.length) * 100); const passed = percentage >= 80; return (

{passed ? : } Quiz Complete!

{percentage}%

You scored {score} out of {quiz.questions.length} questions correctly

{passed ? '🎉 Excellent! You passed!' : '📚 Keep studying and try again!'}

); } return (

{quiz.title}

Question {currentQuestion + 1} of {quiz.questions.length}

{formatTime(timeLeft)}

{/* Progress Bar */}

{/* Question */} {question.question}

{question.options.map((option, index) => ( ))}

{/* Next Button */}

); } // Flashcards Mode if (mode === 'flashcards') { const card = flashcards[flashcardIndex]; return (

Flashcards

Card {flashcardIndex + 1} of {flashcards.length}

{card.category}

{/* Flashcard */} setShowAnswer(!showAnswer)}>

{showAnswer ? 'Answer' : 'Question'}

{showAnswer ? card.answer : card.question}

Click to {showAnswer ? 'see question' : 'reveal answer'}

{/* Controls */}

); } return null; }; export default KCNALearningSystem;

About

Tags

Share

More from glody007

More Templates Like This

About

Tags

Share

About

Tags

Share

More from glody007

More Templates Like This