3 ms·

If complexity isn't the reason for the steep learning curve what is?

JMTQp8lwXL 8y ago
The documentation around it isn't that great. Once you know the key actors -- which are a dozen or so key types of resources, and how they play together, you understand how to create the configuration for your environment. The YAML files are quite intimidating at first, if you look at examples out there. I'm probably not a great teacher, but I think I could boil it down to a slide deck of no more than 25, and an hour's worth of time, and clearly teach how to interface with Kubernetes for a basic web app w/ horizontal scaling, Let's Encrypt SSL certificates, etc.
- NicoJuicy 8y ago
  I'd be interested
ecnahc515 8y ago
My personal take is that it's because Kubernetes has a lot of compositional features and abstractions, rather than a bunch of one off ones that don't play well with other features. A good example is label selectors with Services, Pods, and Deployments. You create a deployment, which is basically a scaling group for pods, and pods are the unit of deployment running containers. A service exposes your pods ports to other components through a cluster local virtual IP, or a load balancer. You cannot simply say "this service is for this app". You must instead say, this service will map it's service port, to the following pod port, for all pods that match the following label selector. There are 5 different concepts (pods, deployments, services, labels and selectors) you need to learn before you can actually make your app accessible. But what's nice is that these concepts are used elsewhere in Kubernetes. Labels and selectors are used to query over any group of objects, and allow grouping different things in arbitrary ways. Pods are concepts that get reused by anything that deploys a container. There's Deployments, Statefulsets, Daemonsets, Jobs, CronJobs, these all create pods. So it's nice that pods are their own decoupled concept, but now you gotta understand how they're used, and relate to the other Resource types. Part of what's great about this all is also that now that people are building custom operators/controllers, you can understand how to use them fairly easily because they build on all these existing concepts.
- jacques_chester 8y ago
  I find that in Kubernetes I do a great deal of tedious boilerplate work. Sometimes I just want to run some damn software and let the platform do the boring stuff. Disclosure: I work for Pivotal, we have a hand in a few such things.
  - JMTQp8lwXL 8y ago
    I've tried that, but then been burned by PaaS switching things up in unexpected ways. Best to make the investment and just own it. I absolutely share the sentiment, though. Good news is, it only took me a week to really pick up k8s.
    - jacques_chester 8y ago
      Kubernetes switches things up a bit too. But before it existed I could type `cf push` and get a running app with automatic routing, logging and service injection. Whereas nowadays I have to type `cf push` and get a running app with automatic routing, logging and service injection.

The documentation around it isn't that great. Once you know the key actors -- which are a dozen or so key types of resources, and how they play together, you understand how to create the configuration for your environment. The YAML files are quite intimidating at first, if you look at examples out there. I'm probably not a great teacher, but I think I could boil it down to a slide deck of no more than 25, and an hour's worth of time, and clearly teach how to interface with Kubernetes for a basic web app w/ horizontal scaling, Let's Encrypt SSL certificates, etc.

NicoJuicy 8y ago
I'd be interested

ecnahc515 8y ago

My personal take is that it's because Kubernetes has a lot of compositional features and abstractions, rather than a bunch of one off ones that don't play well with other features. A good example is label selectors with Services, Pods, and Deployments. You create a deployment, which is basically a scaling group for pods, and pods are the unit of deployment running containers. A service exposes your pods ports to other components through a cluster local virtual IP, or a load balancer. You cannot simply say "this service is for this app". You must instead say, this service will map it's service port, to the following pod port, for all pods that match the following label selector. There are 5 different concepts (pods, deployments, services, labels and selectors) you need to learn before you can actually make your app accessible. But what's nice is that these concepts are used elsewhere in Kubernetes. Labels and selectors are used to query over any group of objects, and allow grouping different things in arbitrary ways. Pods are concepts that get reused by anything that deploys a container. There's Deployments, Statefulsets, Daemonsets, Jobs, CronJobs, these all create pods. So it's nice that pods are their own decoupled concept, but now you gotta understand how they're used, and relate to the other Resource types. Part of what's great about this all is also that now that people are building custom operators/controllers, you can understand how to use them fairly easily because they build on all these existing concepts.

jacques_chester 8y ago
I find that in Kubernetes I do a great deal of tedious boilerplate work. Sometimes I just want to run some damn software and let the platform do the boring stuff. Disclosure: I work for Pivotal, we have a hand in a few such things.
- JMTQp8lwXL 8y ago
  I've tried that, but then been burned by PaaS switching things up in unexpected ways. Best to make the investment and just own it. I absolutely share the sentiment, though. Good news is, it only took me a week to really pick up k8s.
  - jacques_chester 8y ago
    Kubernetes switches things up a bit too. But before it existed I could type `cf push` and get a running app with automatic routing, logging and service injection. Whereas nowadays I have to type `cf push` and get a running app with automatic routing, logging and service injection.