3 ms·

Third party CRD’s are ubiquitous in every single kubernetes-based infra I’ve yet seen so far in my career. Nowhere was I making a statement vis a vis how it sho

Third party CRD’s are ubiquitous in every single kubernetes-based infra I’ve yet seen so far in my career. Nowhere was I making a statement vis a vis how it should be, but that dependencies like this have yet not to become a huge headache on every K8s upgrade I’ve done (started on 1.12, I just moved my current project to 1.27, and have done most upgrades in between). Given that the kubernetes dev cycle is so fast and API changes are so frequent, combined with the fact that the kubernetes API is designed to be built on top of, this tends to be a real hassle in the real world was my only point. Compare it to something like the “old” way of doing it, some monolith running on a container in a VM - that stuff could run until the cows come home with very few issues or intervention.

starttoaster 3y ago
Yeah that's pretty fair. Though I'd say that's something I struggle with today as a whole; keeping up with software changes among all my infrastructure dependencies. The old solution to this used to be, "just don't ever update it and you'll have no problems until the server is 30 years old and fails to boot." Nowadays you can't really get away with that, so we update all of the things all of the time, constantly juggling support matrixes between various pieces of it all with interlocking dependencies. I don't think this is a problem that is unique to kubernetes, is what I'm getting at. You never said that it was, I'm mostly thinking out loud.