The technical long-form: how I made our Kubernetes cluster more failure-resistant across three hardening pillars – resources, PodDisruptionBudgets and a five-tier PriorityClass scheme – plus zone and pod anti-affinities. Including the pitfalls: silently ignored Helm values, webhook-immutable fields, and a MaxScale pod that stubbornly stayed Pending.
Let me share my favourite result of the past few weeks: a server went down – and nobody noticed. No broken login, no blank website, no "database temporarily unavailable." It sounds like the most boring sentence in the world, and that's exactly what I'd been working towards.
Modern Minecraft server ecosystems often lack a reliable central point of truth for player information. Developers must frequently retrieve the same data from scattered sources or—even worse—reimplement their own redundant systems. This leads to data duplication, inconsistent states, and incomplete data deletion, which can conflict with privacy law requirements and make daily development unnecessarily complicated.
When building a Minecraft plugin for PaperMC, it’s easy to lose track of logs. Traditional log messages quickly hit their limits in larger projects or multi-module architectures. All the more reason to add a clear structure that keeps important information filterable.
Relatively unknown yet already present on several hundred servers. Like Fractureiser, it is promoted by the user mori0 / Riesenrad to “troll” servers. What lies behind it.
This blog entry was translated, there is also a german version of it!
Hello all together, my name is Phillipp. I am one of two lead developer and look after technologies and server architecture here in this team.
In the boundless expanse of the digital world, our team, OneLiteFeather, has discovered a quaint yet vibrant playground where we realize our creative and technical visions. At the heart of this expedition are Proxmox and Ansible, two tools that not only have our backs but also open doors to uncharted territories.
