Why advanced patterns matter in Kubernetes - Visual Breakdown

Process Flow - Why advanced patterns matter

Start: Simple Deployment

↓

Face Issues: Scaling, Updates, Failures

↓

Need Advanced Patterns

↓

Implement Patterns: Rolling Updates, Blue-Green, Canary

↓

Better Stability & Flexibility

↓

Improved User Experience & Reliability

Shows how starting with simple setups leads to issues, which advanced patterns solve for better stability and user experience.

Execution Sample

Kubernetes

kubectl apply -f deployment.yaml
kubectl rollout status deployment/myapp
kubectl set image deployment/myapp myapp=app:v2
kubectl rollout status deployment/myapp

This sequence applies a deployment, checks rollout status, updates the app image, and verifies the new rollout.

Process Table

Step	Action	Command Output	System State Change
1	Apply deployment manifest	deployment.apps/myapp created	Deployment 'myapp' created with initial pods
2	Check rollout status	deployment "myapp" successfully rolled out	Pods are running and ready
3	Update image to v2	deployment.apps/myapp image updated	New pods with app:v2 start rolling out
4	Check rollout status after update	deployment "myapp" successfully rolled out	Old pods terminated, new pods running
5	End	No further commands	Deployment stable with updated version

💡 Deployment updated successfully with zero downtime using rolling update pattern

Status Tracker

Variable	Start	After Step 1	After Step 3	After Step 4	Final
Deployment Version	None	app:v1	app:v2 (rolling out)	app:v2 (fully rolled out)	app:v2
Pods Ready	0	All ready	Some old, some new	All new ready	All new ready

Key Moments - 3 Insights

Why do we check rollout status after applying or updating a deployment?

Checking rollout status confirms that pods are running correctly and the update did not break the app, as shown in steps 2 and 4 of the execution table.

What happens to old pods during a rolling update?

Old pods are gradually terminated only after new pods are ready, ensuring no downtime. This is visible in step 4 where some old pods still run while new pods start.

Why not just delete old pods and create new ones immediately?

Deleting old pods immediately causes downtime. Rolling updates keep the app available by replacing pods gradually, as shown in the system state changes.

Visual Quiz - 3 Questions

Look at the execution table, what is the deployment version after step 3?

A app:v2 (fully rolled out)

B app:v1

C app:v2 (rolling out)

D None

💡 Hint

Check the variable_tracker row 'Deployment Version' after Step 3

At which step does the deployment become fully stable with the new version?

A Step 3

B Step 4

C Step 2

D Step 1

💡 Hint

Look at the 'System State Change' column in the execution_table for when old pods are terminated

If we skipped checking rollout status, what risk would increase?

A Missing failed updates causing downtime

B Faster deployment

C More pods created

D No risk at all

💡 Hint

Refer to key_moments about why rollout status checks matter

Concept Snapshot

Advanced Kubernetes patterns like rolling updates help update apps without downtime.
They replace pods gradually, ensuring stability.
Checking rollout status confirms success.
Skipping these patterns risks downtime and failures.

Full Transcript

This visual execution shows why advanced Kubernetes deployment patterns matter. Starting with a simple deployment, we apply the manifest and check rollout status to ensure pods are running. When updating the app image, rolling updates replace old pods gradually, avoiding downtime. Checking rollout status again confirms the update succeeded. Variables like deployment version and pods ready change step-by-step, showing the system state improving. Key moments explain why checking rollout status is critical and how rolling updates prevent downtime by not deleting old pods immediately. The quiz tests understanding of deployment version states, stability timing, and risks of skipping checks. Overall, advanced patterns improve reliability and user experience in Kubernetes deployments.

Practice

1. Why is it important to use advanced patterns in Kubernetes deployments?

easy

A. They reduce the need for monitoring and logging.

B. They make the YAML files shorter but less readable.

C. They improve scalability and reliability of applications.

D. They allow running Kubernetes without any configuration.

Solution

1. Step 1: Understand the role of advanced patterns

   Advanced patterns help manage complex deployments by improving how applications scale and recover from failures.

2. Step 2: Evaluate the options

   Only They improve scalability and reliability of applications. correctly states that advanced patterns improve scalability and reliability, which are key goals in Kubernetes.

3. Final Answer:

   They improve scalability and reliability of applications. -> Option C

4. Quick Check:

   Advanced patterns = better scalability and reliability [OK]

Hint: Think about what helps apps run well at scale [OK]

Common Mistakes:

• Confusing shorter YAML with better patterns
• Assuming no need for monitoring with advanced patterns
• Believing Kubernetes runs without configuration

2. Which of the following is the correct syntax to define a Kubernetes Deployment with a rolling update strategy?

easy

A. apiVersion: apps/v1\nkind: Deployment\nmetadata:\n name: myapp\nspec:\n strategy:\n type: RollingUpdate\n replicas: 3

B. apiVersion: v1\nkind: Deployment\nmetadata:\n name: myapp\nspec:\n strategy:\n type: Recreate\n replicas: 3

C. apiVersion: apps/v1\nkind: Deployment\nmetadata:\n name: myapp\nspec:\n strategy:\n rollingUpdate:\n maxSurge: 1\n maxUnavailable: 0\n replicas: 3

D. apiVersion: apps/v1\nkind: Deployment\nmetadata:\n name: myapp\nspec:\n replicas: 3

Solution

1. Step 1: Identify correct apiVersion and kind

   Deployments use apiVersion 'apps/v1' and kind 'Deployment'. Options A, C, and D use this correctly.

2. Step 2: Check strategy type for rolling update

   RollingUpdate strategy requires 'strategy.type: RollingUpdate' as in apiVersion: apps/v1\nkind: Deployment\nmetadata:\n name: myapp\nspec:\n strategy:\n type: RollingUpdate\n replicas: 3. apiVersion: apps/v1\nkind: Deployment\nmetadata:\n name: myapp\nspec:\n strategy:\n rollingUpdate:\n maxSurge: 1\n maxUnavailable: 0\n replicas: 3 misses 'type' field, so it's incomplete.

3. Final Answer:

   apiVersion: apps/v1\nkind: Deployment\nmetadata:\n name: myapp\nspec:\n strategy:\n type: RollingUpdate\n replicas: 3 -> Option A

4. Quick Check:

   RollingUpdate strategy syntax = apiVersion: apps/v1\nkind: Deployment\nmetadata:\n name: myapp\nspec:\n strategy:\n type: RollingUpdate\n replicas: 3 [OK]

Hint: Look for 'strategy.type: RollingUpdate' in spec [OK]

Common Mistakes:

• Using wrong apiVersion for Deployment
• Missing 'type' under strategy for rolling update
• Confusing Recreate with RollingUpdate strategy

3. Given the following Kubernetes YAML snippet, what will be the result of applying it?

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-deploy
spec:
  replicas: 2
  selector:
    matchLabels:
      app: test
  template:
    metadata:
      labels:
        app: test
    spec:
      containers:
      - name: test-container
        image: nginx:1.19
        ports:
        - containerPort: 80
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

medium

A. Deployment will create 3 pods permanently due to maxSurge setting.

B. Deployment will create 2 pods with rolling update allowing 1 extra pod during updates.

C. Deployment will fail because maxUnavailable cannot be zero.

D. Deployment will create only 1 pod because maxUnavailable is zero.

Solution

1. Step 1: Understand replicas and rolling update settings

   The deployment requests 2 replicas. maxSurge: 1 allows 1 extra pod temporarily during updates, maxUnavailable: 0 means no pods go down during update.

2. Step 2: Analyze the effect on pod count

   During rolling update, Kubernetes can create up to 3 pods (2 + 1 surge) temporarily, but final stable state is 2 pods running.

3. Final Answer:

   Deployment will create 2 pods with rolling update allowing 1 extra pod during updates. -> Option B

4. Quick Check:

   maxSurge=1 means 1 extra pod allowed temporarily [OK]

Hint: maxSurge adds temporary pods, doesn't increase final replicas [OK]

Common Mistakes:

• Thinking maxSurge adds permanent pods
• Believing maxUnavailable cannot be zero
• Confusing maxUnavailable with pod count

4. You applied a Deployment with this strategy:

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 2
    maxUnavailable: 2

But during updates, you notice downtime. What is the likely cause?

medium

A. maxUnavailable is too high, allowing pods to be down simultaneously.

B. maxSurge is too low, preventing new pods from starting.

C. RollingUpdate strategy requires maxUnavailable to be zero.

D. Deployment replicas must be at least 5 for this strategy.

Solution

1. Step 1: Understand maxUnavailable impact

   maxUnavailable: 2 means up to 2 pods can be unavailable during update, which can cause downtime if replicas are low.

2. Step 2: Connect downtime to maxUnavailable setting

   If too many pods are down at once, service becomes unavailable, causing downtime.

3. Final Answer:

   maxUnavailable is too high, allowing pods to be down simultaneously. -> Option A

4. Quick Check:

   High maxUnavailable = possible downtime [OK]

Hint: Keep maxUnavailable low to avoid downtime during updates [OK]

Common Mistakes:

• Assuming maxSurge controls downtime
• Believing maxUnavailable must be zero always
• Thinking replicas count must be 5 for rolling updates

5. You want to deploy a microservices app on Kubernetes with zero downtime and automatic rollback on failure. Which advanced pattern combination should you use?

hard

A. Use BlueGreen deployment without readiness or liveness probes.

B. Use Recreate strategy with liveness probes and no rollback settings.

C. Use RollingUpdate strategy without probes and manual rollback.

D. Use RollingUpdate strategy with readiness probes and set 'progressDeadlineSeconds' for rollback.

Solution

1. Step 1: Identify zero downtime and rollback requirements

   RollingUpdate strategy allows gradual pod replacement for zero downtime. Readiness probes ensure traffic only goes to healthy pods. 'progressDeadlineSeconds' triggers rollback if update stalls.

2. Step 2: Evaluate options for best fit

   Use RollingUpdate strategy with readiness probes and set 'progressDeadlineSeconds' for rollback. combines RollingUpdate, readiness probes, and rollback settings, meeting all requirements. Others miss probes or rollback automation.

3. Final Answer:

   Use RollingUpdate strategy with readiness probes and set 'progressDeadlineSeconds' for rollback. -> Option D

4. Quick Check:

   RollingUpdate + readiness probes + rollback = zero downtime + auto rollback [OK]

Hint: Combine RollingUpdate, readiness probes, and rollback for smooth deploys [OK]

Common Mistakes:

• Ignoring readiness probes causing downtime
• Using Recreate strategy which causes downtime
• Skipping rollback configuration