Kubernetes contd
Job and CronJob
- There are many cases where we run batch jobs on servers
- Refer Here for official docs
- writing cron expressions
- Refer Here for the changes
Popular Deployment Startegies available
Here’s the updated table that includes the Blue/Green deployment strategy:
| Strategy | Description | Benefits | Risks |
|---|---|---|---|
| Recreate | Terminates the old version and releases the new one. Involves shutting down the old version completely, deploying the new version, and then rebooting the whole system. | Simple and predictable. | Downtime, limitations in testing and scalability. System downtime between shutting down the old software and booting the new one. |
| Rolling Update | Gradually rolls out a new version by updating nodes in batches. Two versions of the service run simultaneously: the old and the new. Traffic is shifted in increments. | Less risky than Recreate, easier to implement and rollback. Zero-downtime updates. Gradual rollout limits impact. | More complex to manage. Can take a long time. Requires support for old and new versions. Long rollback duration. |
| Canary | Releases a new version to a subset of users before a full rollout. Gradually rolls out the new version to a small percentage of users. | Allows observation of software behavior in production with minimal impact. Enables quick adjustments before full rollout. Reduces the risk of introducing new problems. | More complex to manage than other strategies. Potential user impact. |
| A/B Testing | Releases a new version to a subset of users in a precise way (HTTP headers, cookies, weight, etc.). Randomly assigns users to different versions of an application. | Helps in making business decisions based on statistics. Compares the performance of two versions of an application. | Requires extra work to set up a more advanced infrastructure. |
| Blue/Green | Employs two identical environments, one active (blue) and one idle (green). New code is deployed to the idle environment, tested, and then traffic is switched from blue to green[3][5]. The blue environment then becomes the backup[2]. | Reduces downtime, provides simple rollouts and quick rollbacks, and facilitates easy disaster recovery[1][2]. Enables continuous delivery[4]. | Requires double the hardware resources. Database migrations can be complex[2]. Requires careful infrastructure preparation[6]. |
Citations:
[1] https://octopus.com/devops/software-deployments/blue-green-deployment/
[2] https://www.split.io/glossary/blue-green-deployment/
[3] https://www.techtarget.com/searchitoperations/definition/blue-green-deployment
[4] https://launchdarkly.com/blog/blue-green-deployments-a-definition-and-introductory/
[5] https://codefresh.io/learn/software-deployment/what-is-blue-green-deployment/
[6] https://launchdarkly.com/blog/blue-green-deployments-versus-rolling-deployments/
[7] https://www.redhat.com/en/topics/devops/what-is-blue-green-deployment
- Kubernetes natively supports Recreate and Rolling updates and also rolling out a new version and undo rollout (rollback), This can be acheived with 3 controllers
- Deployment
- Daemonset
- Stateful sets
