> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # Solution Deployment strategies > This article reviews deployment strategies, service verification, and traffic management for safe application rollouts. In this lesson, we will review the deployment strategies used in our lab exercise. This guide details how to identify the deployment strategy, verify service configurations, and gradually shift traffic between application versions for a safe rollout. *** ## Question 1: Identify the Deployment Strategy Begin by identifying the deployment strategy used for the deployment in the default namespace. 1. List all deployments by running: ```bash theme={null} root@controlplane ~ ➜ kubectl get deployments NAME READY UP-TO-DATE AVAILABLE AGE frontend 5/5 5 5 30s ``` 2. Next, inspect the details of the "frontend" deployment to check its strategy: ```bash theme={null} root@controlplane ~ ➜ kubectl describe deployment frontend Name: frontend Namespace: default CreationTimestamp: Thu, 04 Aug 2022 23:30:33 +0000 Labels: app=myapp tier=frontend Annotations: deployment.kubernetes.io/revision: 1 Selector: app=frontend Replicas: 5 desired | 5 updated | 5 total | 5 available | 0 unavailable StrategyType: RollingUpdate MinReadySeconds: 0 RollingUpdateStrategy: 25% max unavailable, 25% max surge Pod Template: Labels: app=frontend version=v1 Containers: webapp-color: Image: kodekloud/webapp-color:v1 Port: Host Port: Environment: Mounts: Volumes: Conditions: Type Status Reason ``` From the output, notice the deployment strategy is **RollingUpdate**. *** ## Question 2: Identify the Correct Service The "frontend" deployment is connected to a NodePort service. Follow these steps to verify the service: 1. List the services: ```bash theme={null} root@controlplane ~ ➜ kubectl get service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE frontend-service NodePort 10.97.89.251 8080:30080/TCP 65s kubernetes ClusterIP 10.96.0.1 443/TCP 16m ``` 2. Describe the service to inspect its configuration: ```bash theme={null} root@controlplane ~ ➜ kubectl describe service frontend-service Name: frontend-service Namespace: default Labels: app=myapp Annotations: Selector: app=frontend Type: NodePort IP Family Policy: SingleStack IP Families: IPv4 ``` Since the service selector (`app=frontend`) matches the pod labels in the "frontend" deployment, the correct service is **frontend-service**. *** ## Question 3: Accessing the Web Application To confirm that the web application is running, click the web app button provided in the interface. This step verifies that the application is accessible and functioning as expected. Reload the web application multiple times to observe consistency in responses from the running version. *** ## Question 4: Traffic Splitting with a New Deployment A new deployment, **frontend-v2**, has been created in the default namespace with an updated image. The goal is to divert less than 20% of traffic to this new version, while keeping the total number of pods unchanged. 1. Verify both deployments: ```bash theme={null} root@controlplane ~ ➜ kubectl get deployments NAME READY UP-TO-DATE AVAILABLE AGE frontend 5/5 5 5 2m43s frontend-v2 2/2 2 2 35s ``` With the same selector (`app=frontend`), traffic is balanced across 7 pods (5 for **frontend** and 2 for **frontend-v2**), meaning **frontend-v2** receives approximately 28% of the traffic. 2. To reduce the traffic to about 16.7%, scale down **frontend-v2** to 1 replica: ```bash theme={null} root@controlplane ~ ➜ kubectl scale deployment --replicas=1 frontend-v2 deployment.apps/frontend-v2 scaled ``` 3. Confirm the change: ```bash theme={null} root@controlplane ~ ➜ kubectl get deployments NAME READY UP-TO-DATE AVAILABLE AGE frontend 5/5 5 5 4m52s frontend-v2 1/1 1 1 2m44s ``` With a total of 6 pods now running, **frontend-v2** receives roughly 16.7% of the traffic. Refresh the application in your browser several times to observe any version changes when a request is routed to **frontend-v2**. *** ## Question 5: Redirect All Traffic to the New Version (v2) Once you have confirmed that the new version functions correctly, safely redirect all traffic to **frontend-v2** by following these steps: 1. Scale down the original **frontend** deployment: ```bash theme={null} root@controlplane ~ ➜ kubectl scale deployment --replicas=0 frontend deployment.apps/frontend scaled ``` 2. Scale up the **frontend-v2** deployment to handle all traffic: ```bash theme={null} root@controlplane ~ ➜ kubectl scale deployment --replicas=5 frontend-v2 deployment.apps/frontend-v2 scaled ``` 3. Verify the updates: ```bash theme={null} root@controlplane ~ ➜ kubectl get deployments NAME READY UP-TO-DATE AVAILABLE AGE frontend 0/0 0 0 4m52s frontend-v2 5/5 5 5 2m44s ``` 4. Finally, remove the old **frontend** deployment entirely: ```bash theme={null} root@controlplane ~ ➜ kubectl delete deployment frontend ``` After reloading the application tab, only version 2 of the application should be active. Ensure that your testing confirms the new deployment is stable before fully decommissioning the original version. *** ![The image shows a green background with text displaying "Hello from frontend-v2-69d77d4d95-xgwj4!" and "Application Version: v2" in white.](https://kodekloud.com/kk-media/image/upload/v1752871260/notes-assets/images/Certified-Kubernetes-Application-Developer-CKAD-Solution-Deployment-strategies/frame_340.jpg) This successful adjustment in the deployment strategy confirms that all user traffic is now routed to version 2 of the web application.