Sre

Core Ingress Patterns Basic HTTPS Configuration apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: secure-ingress annotations: nginx.ingress.kubernetes.io/ssl-redirect: "true" spec: tls: - hosts: - app.example.com secretName: tls-secret rules: - host: app.example.com http: paths: - path: / pathType: Prefix backend: service: name: app-service port: number: 80 Advanced Configurations 1. Path-Based Routing apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: path-based-ingress spec: rules: - host: api.example.com http: paths: - path: /v1 pathType: Prefix backend: service: name: api-v1-service port: number: 80 - path: /v2 pathType: Prefix backend: service: name: api-v2-service port: number: 80 2. Rate Limiting metadata: annotations: nginx.ingress.kubernetes.io/limit-rps: "10" nginx.ingress.kubernetes.io/limit-connections: "5" Best Practices SSL Configuration ...

While Kubernetes provides built-in scaling based on CPU and memory usage, real-world applications often need to scale based on business-specific metrics. Whether it’s database connections, queue length, or request latency, custom metrics scaling allows you to adapt your infrastructure to your application’s unique needs. Let’s explore how to implement this in a production environment. Why Custom Metrics Scaling? Traditional resource-based scaling (CPU/memory) often fails to capture the true load on your system. Consider these scenarios: ...

Node Pool Design Patterns GKE Node Pool Configuration # GKE Node Pool resource "google_container_node_pool" "general_purpose" { name = "general-purpose" cluster = google_container_cluster.primary.name location = "us-central1" autoscaling { min_node_count = 1 max_node_count = 10 location_policy = "BALANCED" } node_config { machine_type = "n2-standard-4" disk_size_gb = 100 disk_type = "pd-ssd" labels = { role = "general" env = "production" } taint { key = "specialty" value = "gpu" effect = "NO_SCHEDULE" } } management { auto_repair = true auto_upgrade = true } } EKS Node Group Configuration # EKS Node Group resource "aws_eks_node_group" "compute_optimized" { cluster_name = aws_eks_cluster.main.name node_group_name = "compute-optimized" node_role_arn = aws_iam_role.eks_node.arn subnet_ids = aws_subnet.private[*].id scaling_config { desired_size = 2 max_size = 10 min_size = 1 } instance_types = ["c5.2xlarge"] capacity_type = "SPOT" labels = { workload = "compute" cost = "spot" } taint { key = "workload" value = "compute" effect = "NO_SCHEDULE" } } AKS Node Pool Configuration # AKS Node Pool resource "azurerm_kubernetes_cluster_node_pool" "memory_optimized" { name = "memopt" kubernetes_cluster_id = azurerm_kubernetes_cluster.main.id vm_size = "Standard_E4s_v3" enable_auto_scaling = true min_count = 1 max_count = 5 node_labels = { workload = "memory-intensive" } node_taints = [ "workload=memory:NoSchedule" ] zones = [1, 2, 3] } Cloud-Specific Features GKE-Specific Capabilities # GKE-specific features resource "google_container_cluster" "advanced" { # Autopilot mode enable_autopilot = true # Vertical Pod Autoscaling vertical_pod_autoscaling { enabled = true } # Binary Authorization enable_binary_authorization = true # Workload Identity workload_identity_config { workload_pool = "${project_id}.svc.id.goog" } } EKS-Specific Features # EKS-specific features resource "aws_eks_cluster" "advanced" { # Fargate Profiles fargate_profile { name = "serverless" selectors { namespace = "serverless" } } # IPv6 Support kubernetes_network_config { ip_family = "ipv6" } # Secrets Encryption encryption_config { provider { key_arn = aws_kms_key.eks.arn } resources = ["secrets"] } } AKS-Specific Features # AKS-specific features resource "azurerm_kubernetes_cluster" "advanced" { # Azure CNI Overlay network_profile { network_plugin = "azure" network_policy = "calico" network_mode = "overlay" } # Azure AD Integration azure_active_directory_role_based_access_control { managed = true azure_rbac_enabled = true } # Azure Key Vault Integration key_vault_secrets_provider { secret_rotation_enabled = true } }

Pod Disruption Budgets (PDBs) are crucial for maintaining application availability during voluntary disruptions like node drains or cluster upgrades. Understanding PDB Basics PDBs define the minimum number of pods that must remain available during voluntary disruptions. Basic PDB Configuration apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: app-pdb spec: minAvailable: 2 selector: matchLabels: app: critical-service Implementation Strategies 1. Absolute vs. Percentage Values Choose between: minAvailable: 2: Absolute number minAvailable: "50%": Percentage-based 2. Using maxUnavailable apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: app-pdb spec: maxUnavailable: 1 selector: matchLabels: app: critical-service Best Practices PDB Calculation ...

Horizontal Pod Autoscaling (HPA) is a crucial component for maintaining application performance and resource efficiency in Kubernetes clusters. This guide explores implementation best practices and common pitfalls to avoid. Understanding HPA Fundamentals HPA automatically scales the number of pods in a deployment based on observed metrics. While CPU and memory are common scaling triggers, custom metrics can provide more meaningful scaling decisions. Key Metrics Selection When choosing metrics for HPA, consider: ...