Kubernetes

Progressive Delivery with ArgoCD Blue-Green Deployments apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: blue-green-app spec: source: plugin: name: argocd-rollouts repoURL: https://github.com/org/app.git targetRevision: HEAD path: rollouts/ destination: server: https://kubernetes.default.svc namespace: production --- apiVersion: argoproj.io/v1alpha1 kind: Rollout metadata: name: blue-green-rollout spec: replicas: 3 strategy: blueGreen: activeService: active-service previewService: preview-service autoPromotionEnabled: false template: spec: containers: - name: app image: app:1.0 Multi-Cluster Management Cluster Configuration apiVersion: argoproj.io/v1alpha1 kind: ApplicationSet metadata: name: multi-cluster-apps spec: generators: - clusters: {} template: metadata: name: '{{name}}-app' spec: project: default source: repoURL: https://github.com/org/app-configs.git targetRevision: HEAD path: environments/{{name}} destination: server: '{{server}}' namespace: production Sync Strategies Selective Sync apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: selective-sync-app annotations: argocd.argoproj.io/sync-wave: "5" spec: syncPolicy: automated: prune: true selfHeal: true syncOptions: - CreateNamespace=true - PruneLast=true - ApplyOutOfSyncOnly=true source: directory: recurse: true exclude: 'excluded-patterns/**' Production Example # Complete production deployment setup apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: production-deployment annotations: notifications.argoproj.io/subscribe.on-sync-succeeded.slack: production-deploys spec: project: production source: repoURL: https://github.com/org/production-config.git targetRevision: main path: overlays/production directory: recurse: true jsonnet: extVars: - name: environment value: production destination: server: https://kubernetes.default.svc namespace: production syncPolicy: automated: prune: true selfHeal: true syncOptions: - CreateNamespace=true - ServerSideApply=true retry: limit: 5 backoff: duration: 5s factor: 2 maxDuration: 3m ignoreDifferences: - group: apps kind: Deployment jsonPointers: - /spec/replicas

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 ...

The Wake-Up Call: CVE-2025-9074 A critical vulnerability recently discovered in Docker Desktop (CVE-2025-9074) serves as a sobering reminder that containers are not the security boundary many developers believe them to be. With a CVSS score of 9.3, this vulnerability allowed malicious containers to escape their supposed isolation and compromise the host system through a surprisingly simple attack vector. The Bottom Line Up Front: CVE-2025-9074 demonstrates that the widespread belief “Docker = isolated = secure” is not just wrong—it’s dangerously wrong. This misconception puts production Kubernetes environments at risk when teams fail to consider the underlying Linux kernel and operating system security implications. ...

Core Components ClusterIssuer Configuration apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: letsencrypt-prod spec: acme: server: https://acme-v02.api.letsencrypt.org/directory email: [email protected] privateKeySecretRef: name: letsencrypt-prod-account-key solvers: - http01: ingress: class: nginx - dns01: cloudflare: email: [email protected] apiTokenSecretRef: name: cloudflare-api-token key: api-token Certificate Management Wildcard Certificate apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: wildcard-cert namespace: cert-manager spec: secretName: wildcard-tls commonName: "*.example.com" dnsNames: - "*.example.com" - "example.com" issuerRef: name: letsencrypt-prod kind: ClusterIssuer usages: - digital signature - key encipherment - server auth Production Implementation # Complete cert-manager setup apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: production-certs namespace: production spec: secretName: production-tls duration: 2160h # 90 days renewBefore: 360h # 15 days subject: organizations: - Example Corp commonName: api.example.com dnsNames: - api.example.com - web.example.com - admin.example.com issuerRef: name: letsencrypt-prod kind: ClusterIssuer keystores: jks: create: true passwordSecretRef: name: jks-password key: password --- apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: secured-ingress annotations: cert-manager.io/cluster-issuer: "letsencrypt-prod" spec: tls: - hosts: - api.example.com - web.example.com secretName: production-tls rules: - host: api.example.com http: paths: - path: / pathType: Prefix backend: service: name: api-service port: number: 80

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: ...