← Back to Recording

Summary

Overview

This course session provides an in-depth exploration of Kubernetes Deployment resources, focusing on deployment strategies (recreate and rolling update), rollout management (status, pause, resume, undo), revision history, and the role of labels and annotations in resource orchestration. The session includes live demonstrations of creating, updating, and rolling back deployments using kubectl, with emphasis on practical configuration, best practices, and cluster behavior under different rollout scenarios. The training concludes with a review of key concepts and an introduction to dry-run and admission control mechanics.

Topic (Timeline)

1. Deployment Scaling and Label Selector Fundamentals [00:00:00 - 00:07:09]

  • Clarified common kubectl command errors (e.g., scale rs vs scale deploy) and correct syntax: kubectl scale deploy <name> --replicas=<count>.
  • Explained how to identify top-level resources managing a Pod using label selectors: query Pods with app=<label-value> to determine ownership by a Deployment or ReplicaSet.
  • Emphasized that no direct command exists to list all top-level resources managing a Pod; must use label-based querying from the resource side.
  • Introduced label selector operators: !=, in, notin, existence checks (app without value), and negation (!app).
  • Highlighted the three critical label locations in a Deployment YAML:
    1. metadata.labels — labels on the Deployment object itself.
    2. spec.selector.matchLabels — used by the Deployment to find and manage Pods.
    3. spec.template.metadata.labels — labels applied to created Pods.
  • Stressed that spec.selector.matchLabels must be a subset of spec.template.metadata.labels for valid deployment; mismatch causes failure to spawn Pods.
  • Noted that labels are arbitrary keys (not reserved), and application teams typically own label conventions in production.

2. Deployment Strategies: Recreate vs Rolling Update [00:07:10 - 00:19:16]

  • Introduced Deployment as the top-level resource for managing ReplicaSets and Pods, with built-in rollout capabilities.
  • Defined two native strategies:
    • Recreate: Terminates all existing Pods before creating new ones → results in downtime.
    • RollingUpdate: Gradually replaces Pods to maintain availability.
  • Detailed RollingUpdate parameters:
    • maxUnavailable: Maximum Pods allowed to be down during update (e.g., 25% of 100 Pods = 25 down at once).
    • maxSurge: Maximum extra Pods allowed above desired count (e.g., +25% = 125 total during update).
  • Explained that maxSurge increases resource demand temporarily; use cautiously in resource-constrained clusters.
  • Clarified that setting maxUnavailable=100% is functionally equivalent to Recreate.
  • Noted default strategy is RollingUpdate with maxUnavailable=25% and maxSurge=25%.

3. Rollout Management: Status, Pause, Resume, and Undo [00:19:16 - 00:35:02]

  • Demonstrated kubectl rollout status deploy/<name> to monitor real-time rollout progress.
  • Showed how to pause a rollout (kubectl rollout pause deploy/<name>) to halt progression for debugging, then resume (kubectl rollout resume deploy/<name>).
  • Explained kubectl rollout history deploy/<name> to view revision history, including annotations and image versions.
  • Demonstrated rollback using:
    • kubectl rollout undo deploy/<name> → reverts to previous revision.
    • kubectl rollout undo deploy/<name> --to-revision=<N> → reverts to a specific revision.
  • Highlighted that revision history is maintained only at the Deployment level, not ReplicaSet or Pod.
  • Showed how to configure revisionHistoryLimit in YAML to control how many past revisions are retained (default: 10).
  • Demonstrated live deployment workflow:
    1. Create Deployment with nginx:1.22-alpine.
    2. Update image to 1.22 → trigger rollout.
    3. Update to 1.23 → trigger second rollout.
    4. Rollback to 1.22 → confirm revision history and state changes.

4. Annotations, Dry-Run, and Admission Control [00:35:02 - 00:43:54]

  • Introduced annotations as non-queryable metadata for tools (e.g., CI/CD, monitoring), distinct from labels.
    • Example: kubernetes.io/change-cause: "Deploying v1.22 Alpine" — visible in rollout history.
  • Explained kubectl create ... --dry-run=client → generates YAML without submitting to API server.
  • Contrasted with --dry-run=server → submits request to API server for validation and mutation, but does not persist to etcd.
  • Clarified server-side processing: requests pass through authentication → authorization → admission controllers (validation/mutation).
  • Noted that admission controllers may add defaults (e.g., namespace) or reject invalid specs — dry-run=server reveals these transformations.
  • Emphasized that dry-run=server is critical for testing compliance with cluster policies before actual deployment.

Appendix

Key Principles

  • Label Consistency: spec.selector.matchLabels must match or be a subset of spec.template.metadata.labels for successful Pod management.
  • Rollout Safety: Use RollingUpdate with maxUnavailable and maxSurge to avoid downtime; avoid Recreate in production unless downtime is acceptable.
  • Revision Control: Always use revisionHistoryLimit to prevent etcd bloat; use rollout history and undo for safe rollbacks.
  • Annotations for Tooling: Use kubernetes.io/change-cause to log deployment intent; annotations are not used for resource selection.

Tools Used

  • kubectl scale deploy <name> --replicas=N
  • kubectl rollout status deploy/<name>
  • kubectl rollout pause/resume deploy/<name>
  • kubectl rollout history deploy/<name> --revision=N
  • kubectl rollout undo deploy/<name> --to-revision=N
  • kubectl create deploy <name> --image=<img> --dry-run=client/server -o yaml
  • kubectl apply -f <file>.yaml

Common Pitfalls

  • Using scale rs instead of scale deploy — ReplicaSets are managed by Deployments; direct scaling is discouraged.
  • Mismatched labels between selector and template — causes Pods to be unmanaged.
  • Setting maxSurge too high without sufficient cluster resources — leads to pending Pods.
  • Omitting revisionHistoryLimit — can cause etcd performance degradation over time.
  • Assuming annotations can be used in selectors — they cannot; only labels are queryable.

Practice Suggestions

  • Recreate a Deployment with 5 replicas and test maxUnavailable=50% and maxSurge=20%.
  • Modify a Deployment’s image and observe rollout status; pause and resume manually.
  • Use dry-run=server to see how admission controllers modify your YAML (e.g., adding namespace or resource limits).
  • Delete a Deployment and recreate it with --dry-run=client -o yaml to generate a clean template.
  • Add kubernetes.io/change-cause annotation to a rollout and verify it appears in rollout history.