aleks-mariusz
commented
6 years ago It's no secret that Kubernetes (and anything devops/cloudy in general) is a fast-moving set of technologies. I too am in a similar position, quite able with linux/shell/networking concepts (i'm very well seasoned at the risk of sounding not-very-humble). I'm currently attempting to lead the containerization strategy at the firm i recently started in so for me it's very important (not to mention very interesting) to get familiar with how things are done.
My advice to you would be to play with mini-kube. It is an all-in-one 'cluster-in-a-box' setup that will get you started in minutes not hours. You can do that for a week or two to get familiar with the general kubernetes concepts, at least if you are totally new. I should have done that probably but i did a lot of reading instead, and ended up a few weeks ago jumping straight into trying to set up a 3x master HA set up with integrated storage (for persistent volumes). Though I've learned a LOT doing that, the process was anything but easy, it was however quite rewarding. My current struggle is getting centralized logging working, mainly because at some point (or maybe just specific to the distro i use, CentOS 7), docker doesn't log to json-files, and unfortunately all the fluentd/file-bit/etc examples i've come across kind of expect that, with very little supporting systemd's journald services that docker/kubelet/etc log to.
One thing to keep in mind that i've learned is to pay attention to how actively supported any projects you're considering adopting are. If they haven't been touched in a year, that's a bit of a red flag. As you are probably aware of how fast it moves, keeping it up to date isn't something you can completely forget about. If you are planning to be near the cutting-edge of this technology then it's good to be aware of how the landscape is slowly changing (such as the general move toward systemd i'm suspecting down the line). If you want to be on the very cutting edge (testing nightly builds and such) then updating is going to be a fact of life for you.
So to answer your question, how often to update? keep an eye on it every few weeks probably. The documentation is quite good, set up a test cluster in addition to your main cluster, script the re-creation of the test cluster and have it mirror your main cluster, testing any new technology in the test cluster. That's what i'm doing, with a lab cluster i rebuild at least once or twice a week with new lessons learned. The solidified ones will end up in my main cluster (mainly for dev work) and eventually i'm hoping to have a prod cluster in AWS that will have zero one-off things and all deployed via automation (such as the gitops mindset that things like Helm and Weave Flux gives you).
rafi
zladuric
pstadler
I am trying to estimate how resource-intensive is to maintain this cluster. I'm pretty decent with linux, shells, networking, the concept, I could even fall back to iptables without a hiccup. But my current job is relatively far from devops.
So setting this cluster up would take several hours, up to a day, I assume. That I can afford. But I wonder how up-to-date is it important to be, and furthermore, how frequent are updates to various parts of the project. By using Google's containers, I have a feeling every time I log in to my computer there's an update to gcloud and kubectl packages.
I would maintain this cluster purely for personal reasons - playing with it a bit, maybe learning etc. But if I need to spend a lot of time just maintaining this, then I'm probably better off using Scaleway or Hetzner directly.
Can anybody share any insights into this topic? How often do you have to do updates etc to this system?