https://platformengineering.org logo
Join Slack
Powered by
This message was deleted.
# general
s
This message was deleted.
j
ie. primary and secondary doesn't make sense because they're both "primary"
-a
and 
-b
works but i was trying to find something that doesn't relegate one of the clusters to a seemingly secondary status; I want the name to indicate they are equal but separate entities
I guess that makes sense if they're in different AZs and you match the name to the AZ, but I'm trying to think about this cloud-agnostically for a blog / talk
k
blue/green?
As in blue/green deploy, although it's not quite the same, since both are active. But it's a similar idea that neither one is primary/secondary
p
Side question, why do you do this, and is it working for you? (We’re considering doing blue green cluster upgrades and I’m curious how well this works at scale)
k
Philip, do you mean upgrading everything in an entire cluster at once? We did this at a client some years back, and found that it didn't scale well as the system grew. It was better to do blue/green at the service level than the whole wodge at once.
p
I mean kubernetes version upgrades. I agree, upgrading all the services at the same time is a incident waiting to happen (we do this occasionally because we effectively have a distributed monolith and occasionally need to “deploy the world”). But I’m mostly curious about blue green eks upgrades (we’ve also looked into active / active failover clusters, mainly for our management clusters)
j
So I thought of using colors, but blue/green has a specific meaning and I don't want to confuse the issue.
Philip, that's actually the exact workflow that is leading me down this path. Having two k8s clusters per environment I think is an important technique for handling upgrades to cloud provided k8s clusters, since none of them offer a downgrade strategy besides "spin up a new cluster at the old version"
Having two clusters sharing the load, you can apply changes to one, and if anything goes wrong, you can just flip 100% of traffic to the one you didn't touch.
The downside is you need to over-provision a bit, which increases costs, and have a solid failover strategy to go from 50 to 100% of traffic in a few seconds.
Of course if you only have one cluster, you probably don't have a failover strategy at all. 🫠
p
Heh, yeah if any of those things go wrong we’d be in a bad spot for sure.
I agree with avoiding naming with specific meaning in other contexts. My last company we named clusters by random colors, which works well if they are all fungible, but can be confusing if they are unique in purpose (is my service on purple or orange?)
j
Hot/hot if both clusters are up and running and responding to requests.
j
Yeah I think for this pattern to work you need to be deploying the same things to each cluster.
j
Hot/Warm if one of them is just ready, but not getting requests
j
Right they'll both be "hot" but that's not a unique name. 🙃
s
When we had web farms, we just numbered them. WEB-01, WEB-01, etc. I think that's a reasonable pattern with no baggage. Nobody thought WEB-01 was more important or dealt with different traffic to WEB-02. It's also pretty easy to remember the names... and you know exactly what you'll call the third one if you add it (no need to assemble a committee to vote on your third planet, colour, or sci-fi reference).
j
hahaha
good point
s
There's also the benefits of not having to remember how to spell 
cluster-la'an-noonien-singh
😆
w
What about east/west
j
I was actually thinking of that myself, Will; just worried that people will think it's related to the actual location of the clusters
Open in Slack
PreviousNext
Powered by