2 ms·

I mean, CRD API changes/deprecations are, by nature, not reported by the kubernetes project because they're maintained by whatever software provider you install

I mean, CRD API changes/deprecations are, by nature, not reported by the kubernetes project because they're maintained by whatever software provider you installed them from. Unless you're saying that the CRD creates generic kubernetes resources in the cluster that is owned by the CR. In which case, the tool should definitely pick up the generic object at least, but not necessarily tell you that you need to update your version of the CRD, again because the CRD is owned by a third party.

JohnMakin 3y ago
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.

JohnMakin 3y ago

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.