[HN Gopher] Obscure challenges supporting Kubernetes 1.22 in Pixie
___________________________________________________________________
Obscure challenges supporting Kubernetes 1.22 in Pixie
Author : htroisi
Score : 12 points
Date : 2021-10-05 18:33 UTC (4 hours ago)
(HTM) web link (blog.px.dev)
(TXT) w3m dump (blog.px.dev)
| zzyzxd wrote:
| The article described their issues related to using deprecated
| software (etcd-operator and nats-operator, both archived by
| upstreams), which rely on some k8s beta APIs that deprecated 2
| years ago. The result shouldn't be surprising at all.
|
| > Unfortunately, both operators chose to define their CRD inside
| of their code (rather than as a separate yaml) and the latest
| releases still used the beta version of the API.
|
| They made it sound like a bad thing, but I don't think it is
| necessarily true in all cases. It is convenient to define CRDs
| outside the operator code, but just like putting ORMs in your
| CRUD app, embedding CRDs in code gives developers better chance
| to ensure that their code is compatible with a specific API
| version. If I say my code only supports v1 API, I can't help you
| if you run it with v2 API and it gets broken.
| michaelmdresser wrote:
| I've been encountering similar challenges dealing with old
| Kubernetes library versions, CRDs, etc. Is this a problem mainly
| with the Kubernetes project or just Go dependencies? It's quite
| frustrating, and I always discover some new set of voodoo to
| handle it.
| philkuz wrote:
| I'm not quite sure the flavor of your problems, but I imagine
| some of them were caused be the confusion between v1beta1 and
| v1 apis. Users would continue to use beta versions of APIs
| despite the availability of the GA APIs.
|
| Hopefully this becomes easier with the beta lifecycle policy:
| https://kubernetes.io/blog/2020/08/21/moving-forward-from-be...
|
| Unfortunately this also means you'll see similar issues in the
| short term.
|
| One way to avoid these might be to opt for only GA k8s APIs for
| your infra.
| kobalsky wrote:
| > coreos archived etcd-operator
|
| doesn't surprise me.
|
| this operator really tarnished coreos in my eyes when I learned
| that the it worked only with volatile storage, so if for example,
| your power backup failed and every node went down, you lost your
| all your etcd data until your last manual backup.
|
| it felt like it was a half-assed attempt of a proof of concept
| and it was somehow being used in production systems by a lot of
| people, including the guys in the article.
|
| however, and to be fair, I don't know if it evolved much after
| our experience, although the fact that it was scrapped doesn't
| bode well.
|
| luckily it didn't resist much testing so we didn't waste much
| time with it.
___________________________________________________________________
(page generated 2021-10-05 23:02 UTC)