4 ms·

K8S is not that complicated. Once you know the big ideas behind it, and how to reason with it, it becomes a very versatile platform substrate. Probably the bi

by hosh 3y ago

K8S is not that complicated. Once you know the big ideas behind it, and how to reason with it, it becomes a very versatile platform substrate. Probably the biggest one is understanding you don’t ever do anything directly with Kubernetes.

el_benhameen 3y ago
Do you have any favorite learning resources?
- doctoboggan 3y ago
  I've learned K8S over the past few months and what was absolutely instrumental to my understanding was: 1. use Helm, and 2. daily chat sessions with gpt-4. I use gpt-4 through the API where you can set your own system prompt. I developed one that basically instructed it to give me kubectl commands to solve my problems and then wait for me to give it the result before continuing. Through this I learned the practical techniques and which kubectl commands you use on a daily basis, which is so much more helpful than reading the documentation which just gives all commands equal weight. EDIT: Oh, and definitely watch a few "TechWorld with Nana" videos on YouTube. She does a great job of explaining the architecture, terminology, and philosophy of k8s which I think it very helpful to know.
- hosh 3y ago
  I learned k8s the hard way so I am not sure I can point those out. That mindset of not doing anything directly comes from understanding that you are not setting up pods up, but rather, you are setting automated processes up. These processes knows what the desired state is, and if there is something that changes things, it takes actions to get back to that desired state. So you don’t create pods. You create deployments that maintain a set of pods. You don’t assign pods to nodes. You define pod affinities, and use node selectors on nodegroups. You use pod priority. You make graceful startups and shutdowns work correctly. And so forth.
saurik 3y ago
Then what are you using, if not kubernetes, when you are using kubernetes?
- hosh 3y ago
  You don’t use kubernetes. You’re defining desired states for various processes that are collectively called “Kubernetes”. These automated processes maintain things at the desired state, and take action to move things back to the desired state when that happens. These processes are distinct, and are not usually aware of each other (example: horizontal pod autoscaling and cluster autoscaler). If you understand that, you then know you can add processes (such as operators or the cluster autoscaler). It’s a mindset shift. Thinking of it as “using” kubernetes, as if it is a monolithic thing that you directly control, will greatly increase the difficulty in understanding and reasoning through what’s going on within a Kubernetes cluster.
ithkuil 3y ago
A lot of people conflate the pains of installing and managing the kubernetes "infrastructure", with the pains of deploying and managing an application running on kubernetes. The complaints are real, because in practice a company needs both aspects and when a small company struggles to setup and manage the kubernetes infrastructure correctly, the application operators are suffering the consequences (e.g. log collection infrastructure doesn't work, it's hard to provision nodes with the right capacity, things like that). They see the infrastructure operation team struggle and they partake in that struggle because what is advertised to be easy, it's not. That said, K8s is a very good way to build an "API" between infrastructure and application "teams". It can work very well if the people involved set things and processes up correctly. It can be a nightmare if botched up
- hosh 3y ago
  > That said, K8s is a very good way to build an "API" between infrastructure and application "teams". It can work very well if the people involved set things and processes up correctly. It can be a nightmare if botched up Agreed. Someone has to actually build it with a product mindset — including product-market fit. I’m one of those oddballs that have set up and scaled up infra, and have put together and delivered applications before. In one gig, I had people joke about naming what I had setup after Heroku. I didn’t realize its significance until I came to a place where it was not done this way. Many on the application team have expressed dissatisfaction… but it’s like the infra team is oblivious to that.

by hosh 3y ago

el_benhameen 3y ago

Do you have any favorite learning resources?

doctoboggan 3y ago
I've learned K8S over the past few months and what was absolutely instrumental to my understanding was: 1. use Helm, and 2. daily chat sessions with gpt-4. I use gpt-4 through the API where you can set your own system prompt. I developed one that basically instructed it to give me kubectl commands to solve my problems and then wait for me to give it the result before continuing. Through this I learned the practical techniques and which kubectl commands you use on a daily basis, which is so much more helpful than reading the documentation which just gives all commands equal weight. EDIT: Oh, and definitely watch a few "TechWorld with Nana" videos on YouTube. She does a great job of explaining the architecture, terminology, and philosophy of k8s which I think it very helpful to know.
hosh 3y ago
I learned k8s the hard way so I am not sure I can point those out. That mindset of not doing anything directly comes from understanding that you are not setting up pods up, but rather, you are setting automated processes up. These processes knows what the desired state is, and if there is something that changes things, it takes actions to get back to that desired state. So you don’t create pods. You create deployments that maintain a set of pods. You don’t assign pods to nodes. You define pod affinities, and use node selectors on nodegroups. You use pod priority. You make graceful startups and shutdowns work correctly. And so forth.

saurik 3y ago

Then what are you using, if not kubernetes, when you are using kubernetes?

hosh 3y ago
You don’t use kubernetes. You’re defining desired states for various processes that are collectively called “Kubernetes”. These automated processes maintain things at the desired state, and take action to move things back to the desired state when that happens. These processes are distinct, and are not usually aware of each other (example: horizontal pod autoscaling and cluster autoscaler). If you understand that, you then know you can add processes (such as operators or the cluster autoscaler). It’s a mindset shift. Thinking of it as “using” kubernetes, as if it is a monolithic thing that you directly control, will greatly increase the difficulty in understanding and reasoning through what’s going on within a Kubernetes cluster.

ithkuil 3y ago

A lot of people conflate the pains of installing and managing the kubernetes "infrastructure", with the pains of deploying and managing an application running on kubernetes. The complaints are real, because in practice a company needs both aspects and when a small company struggles to setup and manage the kubernetes infrastructure correctly, the application operators are suffering the consequences (e.g. log collection infrastructure doesn't work, it's hard to provision nodes with the right capacity, things like that). They see the infrastructure operation team struggle and they partake in that struggle because what is advertised to be easy, it's not. That said, K8s is a very good way to build an "API" between infrastructure and application "teams". It can work very well if the people involved set things and processes up correctly. It can be a nightmare if botched up

hosh 3y ago
> That said, K8s is a very good way to build an "API" between infrastructure and application "teams". It can work very well if the people involved set things and processes up correctly. It can be a nightmare if botched up Agreed. Someone has to actually build it with a product mindset — including product-market fit. I’m one of those oddballs that have set up and scaled up infra, and have put together and delivered applications before. In one gig, I had people joke about naming what I had setup after Heroku. I didn’t realize its significance until I came to a place where it was not done this way. Many on the application team have expressed dissatisfaction… but it’s like the infra team is oblivious to that.