4 ms·

Building a cluster is a fun and relatively easy project. You learn much more by having the hardware at your fingertips. You can simulate network failures and po

Building a cluster is a fun and relatively easy project. You learn much more by having the hardware at your fingertips. You can simulate network failures and power failures or you can crash an important daemon. By causing problems you can see how K8s responds and manages itself when it does not have the nodes it expects. It is important to know these things because, for example, if you create a pod instead of a replica set then the loss of a node will mean the inability to use the pod assigned to that node. You need to know how a pod and a replica set differ in order to create a self-healing stack. You can learn all of that with the cloud solutions but the ability to answer your own questions will always be the superior means of learning. The Agile movement has convinced many that the solution that gets you up and running today is the best. A good engineer is not afraid of working and learning instead of just buying a pre-baked implementation and calling themself an experienced user. The cluster that I know like the back of my hand is my “real” cluster. The production cluster is someone else’s that I just rent.

geerlingguy 7y ago
Through my work on this project, I've learned a ton about kubectl, kubeadm, the control plane, etc. that I never learned when managing EKS clusters at a previous job. It's good to know more of the 'guts' of an insanely complex ecosystem like Kubernetes, which is why I often recommend people follow Kelsey Hightower's "Kubernetes the Hard Way" guide to install Kubernetes from primitives at least once.
tyingq 7y ago
Sure. It's not necessarily skipping all those things you mention that's the motivation. Just the desired order and upfront effort to learn things about K8S.
TheOperator 7y ago
I bought into the rhetoric about the superiority of using real tech when I was studying for IT. It will make you more competent when you actually get on the job. It gets you used to encountering issues that come up in real environments far more than virtualized/simulated ones E.G. loose cables. Yet to be honest I wouldn't recommend going the real tech route because I don't think it justifies the time and money investment when you can learn the lessons it teaches you on the job. One thing I realised is that it really doesn't really help you pass certs or look good in interviews aside from your ability to say "I made an k8s cluster out of raspberry pis". I might endorse it from a strict fun standpoint.

geerlingguy 7y ago

Through my work on this project, I've learned a ton about kubectl, kubeadm, the control plane, etc. that I never learned when managing EKS clusters at a previous job. It's good to know more of the 'guts' of an insanely complex ecosystem like Kubernetes, which is why I often recommend people follow Kelsey Hightower's "Kubernetes the Hard Way" guide to install Kubernetes from primitives at least once.

tyingq 7y ago

Sure. It's not necessarily skipping all those things you mention that's the motivation. Just the desired order and upfront effort to learn things about K8S.

TheOperator 7y ago

I bought into the rhetoric about the superiority of using real tech when I was studying for IT. It will make you more competent when you actually get on the job. It gets you used to encountering issues that come up in real environments far more than virtualized/simulated ones E.G. loose cables. Yet to be honest I wouldn't recommend going the real tech route because I don't think it justifies the time and money investment when you can learn the lessons it teaches you on the job. One thing I realised is that it really doesn't really help you pass certs or look good in interviews aside from your ability to say "I made an k8s cluster out of raspberry pis". I might endorse it from a strict fun standpoint.