Last active
July 9, 2024 09:27
-
-
Save gpsarkar/2f0e4edd0336b33afa4a8842c63c73f6 to your computer and use it in GitHub Desktop.
Revisions
-
gpsarkar revised this gist
Jul 9, 2024 . 1 changed file with 0 additions and 10 deletions.There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode charactersOriginal file line number Diff line number Diff line change @@ -104,13 +104,3 @@ When deploying applications to Kubernetes (K8s), several deployment strategies c **K8s Implementation**: - Use the `kubectl apply` command with `strategy: type: Recreate`. -
gpsarkar created this gist
Jul 9, 2024 .There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode charactersOriginal file line number Diff line number Diff line change @@ -0,0 +1,116 @@ When deploying applications to Kubernetes (K8s), several deployment strategies can be used depending on the requirements for uptime, risk mitigation, and resource management. Here are some common deployment strategies, including commit-based deployment: ### 1. Rolling Updates **Description**: Gradually updates instances of the application one at a time. This ensures that there is no downtime, but it can be slower. **Steps**: 1. Start updating the instances one by one. 2. Wait for the new instance to be up and running before updating the next one. 3. Continue until all instances are updated. **Use Case**: When you need zero downtime and can tolerate running different versions of the application simultaneously during the update. **K8s Implementation**: - Use the `kubectl rollout` command. - Configure the `Deployment` with `strategy: type: RollingUpdate`. ### 2. Blue-Green Deployment **Description**: Maintains two environments (blue and green). One environment is live, and the other is idle. You deploy the new version to the idle environment and switch traffic to it once it's confirmed to be working. **Steps**: 1. Deploy the new version to the green environment. 2. Test the green environment. 3. Switch the traffic to the green environment if tests pass. 4. The blue environment now becomes idle and can be used for the next update. **Use Case**: When you want to minimize deployment risk and can afford additional infrastructure. **K8s Implementation**: - Use separate namespaces or services for blue and green. - Update the service to point to the new version after testing. ### 3. Canary Deployment **Description**: Gradually routes a small percentage of traffic to the new version while the rest continue to use the old version. If no issues are found, gradually increase the traffic to the new version. **Steps**: 1. Deploy the new version alongside the old version. 2. Route a small percentage of traffic to the new version. 3. Monitor the new version. 4. Gradually increase traffic to the new version if no issues are detected. **Use Case**: When you need to test the new version with real user traffic without fully committing. **K8s Implementation**: - Use Ingress controllers or service mesh (e.g., Istio) to manage traffic splitting. - Adjust the traffic distribution gradually. ### 4. A/B Testing **Description**: Similar to canary deployment but used for experimentation. Different users are served different versions to compare performance or features. **Steps**: 1. Deploy multiple versions of the application. 2. Route traffic to different versions based on specific rules or user segments. 3. Analyze the performance and user behavior for each version. **Use Case**: When you need to compare different versions or features under real user conditions. **K8s Implementation**: - Use feature flags and traffic management tools like Istio or Ambassador. ### 5. Shadow Deployment **Description**: Deploys the new version alongside the old version but does not route live traffic to it. Instead, it mirrors the live traffic to the new version for testing. **Steps**: 1. Deploy the new version. 2. Mirror traffic from the old version to the new version. 3. Monitor and analyze the new version’s performance without affecting users. **Use Case**: When you need to test the new version under production load without affecting the end-user. **K8s Implementation**: - Use service mesh (e.g., Istio) to mirror traffic. ### 6. Commit-Based Deployment **Description**: Automatically deploys the application to Kubernetes whenever changes are committed to the version control system. **Steps**: 1. Set up a CI/CD pipeline that triggers on commits. 2. Build and test the application. 3. Create or update the Kubernetes manifests. 4. Deploy the new version to the Kubernetes cluster. **Use Case**: When you need continuous deployment and integration, ensuring that every commit is tested and deployed. **K8s Implementation**: - Use CI/CD tools like Jenkins, GitLab CI/CD, or GitHub Actions. - Configure pipelines to trigger on commits and perform the deployment steps automatically. ### 7. Recreate Deployment **Description**: Shuts down all old instances and then starts new ones. This method causes downtime but is simple and straightforward. **Steps**: 1. Shut down all instances of the old version. 2. Deploy the new version. **Use Case**: When downtime is acceptable or for development environments. **K8s Implementation**: - Use the `kubectl apply` command with `strategy: type: Recreate`. ### Participation in Deployment Strategy Discussions As a manager, here’s how you can participate effectively in discussions regarding deployment strategies: 1. **Understand the Requirements**: Know the application’s uptime requirements, risk tolerance, and deployment frequency. 2. **Stakeholder Communication**: Communicate with stakeholders to understand their priorities, such as minimizing downtime, quick rollbacks, or real-time testing. 3. **Resource Allocation**: Ensure the team has the resources needed for the chosen deployment strategy (e.g., additional infrastructure for blue-green deployments). 4. **Risk Management**: Discuss potential risks and mitigation strategies for each deployment method. 5. **Monitoring and Rollback Plans**: Ensure that there are robust monitoring and quick rollback plans in place for each deployment strategy.