Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
Me: “I’ve done Kubernetes before what could possibly go wro-“
(cni0 breaks IPv4 routing serverside by containerd)
Me:
1 -
Why the f*** do people add their BD on LinkedIn??? Who wants to know when a f**** recruiter gets another year older??? If I am close to you I will know or have you on FB.... WTF, who anyway had the idea that would be a good feature to add???4
-
Oh my.. I think I'm enjoying molesting kubernetes :)
A while ago I got pissed at k8s because with 1.24 they brought backward-incompatible changes, ruling my cluster broken. Then I thought to myself: "why not create a Docker image that would run kubernetes inside? Separate images for control plane, agent and client"
Took me a while, but I think tonight I've had a breakthrough (I love how linux works...)!! The control-plane is spinning up!! Running on containerd
Still needs some work and polishing, but hey! Ephemeral k8s installation with a single docker-run command sure sounds tempting!
P.S. Yes, I know there is `kind` and 'kinder', but I'm reluctant to install a separate tool that installs a set of tools for me. Kind of... too shady. Too many moving parts. Too deeply hidden parts I may have to fix. Having a dumb-simple Dockerfile gives me the openness, flexibility and simplicity I want. + I can always use it as a base image to add my customizations later on! Reinstalling a cluster would be a breeeeeeze6 -
Stop restyling confluence and bitbucket taking more space in an ugly fashion. Don't fix what ain't broken. **#*#*#1
-
Someone send help. IBM has taken over my village. They're brainwashing the children; they wont use any packages that don't end in 'd'!2
-
Took the dive and started learning kubernetes for the last 90 minutes or so. All I can say at this time... is... fuckin' hell m8!
It's some pretty damn cool tech and deconstructing the pieces to understand how to properly build on top of it has been interesting; to say the least.
but shit, man...
the amount of abstractions happening on top of docker/containerd are just asking for tons of problems hahaha. The last place I worked, we had a fair share of devs that either could not or would not bother with trying to understand docker and would constantly push code to the environments, shit would break, and then they'd come to my team and ask us to basically be human log parsers for them... how in the hell my last company is going to fare with trying to roll out kube is beyond me.
tl;dr - kubernetes has a buttload of moving targets and abstracts a metric-fuck-ton of stuff. Last company I worked for is gonna strugglepuff trying to use it. -
Finally!! I've managed to molest containerd and kubernetes!!
Now I can run k8s in a container :) yayy!!!
https://gitlab.com/netikras/KubICon
Next: figure out a way to automatically and transparently share certs6 -
Dear Lord, please stop people from enforcing standards and bypassing them themselves.
Take kubernetes for example. Since v1.24 CRI has been announced as the standard, and kubernetes is shifting to live by it.
But it's not.
Yes, it's got the CRI spec defined and the unix://cri.sock used for that standardised communication. What nobody's telling you, is that that socket MUST be on the same runtime as the kube. I.e. you can't simply spin up a dockerd/containerd/cri-o server and share its CRI socket via CIFS/NFS/etc. Because kube-cp will assume that contained is running on the same host as cp and will try to access its services via localhost.
So effectively you feed the container via a socket to another machine, it spins up the container and that container tries to
- bind to your local machine's IP (not the one's the container is running on)
- access its dependencies via localhost:port, while they are actually running on your local machine (not the CRI host)
I HOPE this will change some day. And we'll have a clear cut between dependencies and dependents, separated by a single communications channel - a single unix socket. That'd be a solution I'd really enjoy working with. NOT the ip-port-connect-bind spaghetti we have now.4
Top Tags
Weekly Rant
View