Kubernetes Deployments

Simply put, adding new Kubernetes targets and attempting to deploy your applications can take hours, involve multiple people, require custom code, and have downtime. As your Kubernetes adoption grows, so does the latency, and complexity of managing the growing number of accounts, configurations, and credentials. 

Deploying beyond a single deployment within a single Kubernetes cluster – to multiple Kubernetes clusters – and managing the promotion lifecycle from one environment to the next is complex and difficult. 

Leveraging multiple Canary or Blue/Green strategies that roll out multiple independent ReplicaSets and jointly deciding whether to progress or rollback for both, limits you from leveraging the best strategy for the environment. 

Using one branch per environment limits the power of Git and using multiple branches. Changing your existing manifests from deployment objects to custom rollout objects is time consuming and redundant. Updating every cluster each time a new feature or fix is released is time you are not focusing on building value for your business. Updating tightly coupled services can cause breakage and downtime. 

Horizontal Pod Autoscaling (HPA) state and load must be taken into account when deploying in order to ensure maximum uptime and efficient use of resources. When deploying changes other than your rollout object, they may not take effect until you manually restart your rollout object. Changes outside rollout or deployment objects don’t follow the same deployment rules.

• Install an agent that connects to your cluster. The agent does not have any business logic per cluster; the agent is for communication purposes, so there’s no need to update each cluster with new releases or fixes.
• Structure Git repositories in whatever way makes the most sense to you. You can trigger Armory easily from wherever you are doing things today – any CI tool, like Github Actions. 
• Deploy any kubernetes object type.
• Define how each environment relates to one another in the deployment manifest. 
• Define constraints you want satisfied before deployment can proceed to next steps.
• Use different deployment strategies for different environments. 
• Automatically account the amount of resources HPA has scaled for your application to make sure that both the old and new versions are running at that current scale.
• Deploy multiple Kubernetes manifests together and jointly decide whether to proceed or rollback for all.
• Use webhooks and canary and impact analysis to leverage your existing automation to validate changes. 
• Use Manual Approvals to involve human judgment before code reaches production.
• Armory runs the complete deployment regardless of what changed, not just updates to the replicaset. This means that if you deploy additional objects, such as a configMap or a secret, and only those additional objects change, the replica set will still be restarted and the same production validation logic/deployment strategy will be run during the restart. This ensures that the other changed manifests are picked up by the new version. All changes follow the same strategy, regardless of what changed.

• Platform Ops teams – Simplify managing multiple clusters that are running across the organization and deploying to them. Spend less time building, maintaining, and troubleshooting deployments; and spend more time building value for your business.
• Application Dev teams – No need to figure out how to deploy or how to optimize your deployment. Focus on writing great code. Commit your code and watch it deploy to production safely, securely, reliably and automatically, everytime. See which stage and environment your deployment is at, the state, and all the information you need to be informed and aware.
• Executives – Save money with cost efficient and easier-to-maintain tooling, reduce the risk of outages that impact your customers; maintain SLAs, focus your resources on building your unique business value.