4 ms·

There are tools to tell you if any of your deployed infrastructure uses a deprecated API. I mean, even if the tool didn't exist you could view the deprecation g

There are tools to tell you if any of your deployed infrastructure uses a deprecated API. I mean, even if the tool didn't exist you could view the deprecation guide, scroll through the kubernetes versions you'll be upgrading through, and inspect your cluster for any objects using a Kind defined by any of those APIs. It's a burden but when is maintaining infrastructure not a burden? https://kubernetes.io/docs/reference/using-api/deprecation-guide/ https://kubernetes.io/docs/reference/using-api/deprecation-g...

JohnMakin 3y ago
CRD's can break in weird ways that aren't always picked up by a tool like that.
- starttoaster 3y ago
  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

CRD's can break in weird ways that aren't always picked up by a tool like that.

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