Nov 4, 2021 by Christos Arvanitis
Unlocking innovation by making software delivery reliable, scalable, and safe is complex. It becomes even more complex when your delivery platform cannot scale properly and fails to meet the needs of your development teams when they need it most.
Spinnaker is awesome, no question. We know Spinnaker well, and we love Spinnaker, which is why we know that operating Spinnaker is complex. Between configuring Spinnaker, managing the underlying infrastructure, monitoring and meeting the SLAs/SLOs, your team will have their hands full. This (without a doubt) will lead to operational inefficiencies that will eventually slow down your deployment frequency.
Operating at scale comes with a lot of pain points for the team operating Spinnaker. Armory’s Managed team operates Armory Enterprise for Spinnaker environments at scale every day, so we’re very aware of these pain points. Given that, we’ve compiled a few tips to help you scale:
PodDisruptionBudgets
for the Spinnaker services, especially during operations like updating your Kubernetes version or updating/upgrading your node pools.cloudProvider
, account
, region
, and resourceType
. As a general principle:
cacheThread
.Consider a very simple use case where we have 30 AWS accounts, 10 ECS accounts, 100 Kubernetes clusters, and we need to onboard another 50 Kubernetes clusters with 2 cacheThreads.
A rough estimate for the current running caching agents would be:
30 x 20 + 10 x 10 + 100 x 2 x 2 = 1100 caching agents
Clouddriver will need an additional 200 caching agents for the 50 new Kubernetes clusters. The startup time of Clouddriver on every deployment could be up to 8-10 mins, and we would need at least 13 Clouddriver replicas with the default concurrent caching agents config.
By using some of the tips discussed above this scenario would experience even greater scale. For instance, by tripling the concurrent caching agents and vertically scaling Clouddriver, you would need only 5 Clouddriver replicas. Additionally, by switching to 3000 baseline IOPS disks, you will drastically reduce the start-up time of your Spinnaker services.
At Armory, we have open-sourced the Spinnaker Observability Plugin, and it is a great fit for monitoring when Spinnaker is operating at scale. Combined with the spinnaker-mixin dashboards, the plugin is a great solution for gaining insight into the operational performance of your Spinnaker platform and (by extension) your software delivery.
Your Spinnaker environment will perform faster, scale better and be more resilient, but some operational burden will still be there. For instance, every new Kubernetes account will require your team to setup the networking, proper permissions, configuration and then redeploy Clouddriver.
One option to consider to address ongoing operational issues is Armory Agent for Kubernetes. The Armory Agent for Kubernetes can help you reach massive scale by enabling account management at the team level and accelerating the onboarding of Kubernetes clusters on the fly without the need of redeploying Clouddriver.
For more information about either Armory’s Managed offering or the Armory Agent for Kubernetes, contact us. We’d love to hear from you!
Autoscaling, which helps to optimize utilization and minimize costs, is one of the most important aspects of cloud computing. Autoscaling dynamically allocates resources to your cloud application based on load. It handles bursts of load and traffic during peak hours, ensuring that end user experience is not degraded. Autoscaling also guarantees that you don’t have […]
Read more →
We’re very proud to announce that Armory’s new product — Armory Continuous-Deployment-as-a-Service or CD-as-a-Service — now supports progressive canary deployments using Service Mesh Interface (SMI). For those put off by the preceding jumble of buzzwords and acronyms, let me try to give a simple explanation. Armory CD-as-a-Service allows users (you!) to safely deploy software to […]
Read more →