4 ms·

> kubectl scaffold mysql --generate This exists, its called helm, which in fact delivers the productivity gains the author is looking for.

ridruejo 8y ago
Correct, you can check out Kubeapps for a collection of apps packaged as Helm charts https://hub.kubeapps.com https://hub.kubeapps.com
hyperrail 8y ago
In the following paragraph, the author considers and appears to reject that solution: >Maybe the combination of operators and Helm charts covers this, but I don’t think that will cut it. Then we’re forcing developers to learn about two other things in addition to Kubernetes. Even if it’s just increasing the vocabulary and installing a new command line tool, it’s extra effort and thought. These things need to be first-class citizens and part of the Kubernetes out-of-the-box experience. They need to be accessible via kubectl.
- justinjlynn 8y ago
  So, instead of keeping cross-cutting concerns separate and permitting them to evolve separately, the author wants K8S to become more complex, because they'd rather learn one more complex thing than multiple simpler things? Seems legit. I mean, why should I install multiple libraries? Why can't glibc wash my car? Will glibc collapse under the weight of it's own complexity -- even though it can't wash my car like I want it to?
  - dominotw 8y ago
    I think more charitable interpretation is that kuberbetes should be designed in such a way that these tools are a natural part of it. Think of active record being part of rails. Sure you can use rails without ar but that doesn't make sense.
    - justinjlynn 8y ago
      Using Ruby on Rails without ActiveRecord does make sense for a number of applications. For example, an edge caching API which uses Redis on the backend. Helm is a package manager for K8S but it isn't the package manager for K8S, which is probably why it's kept separate. ActiveRecord was the ORM for Rails, before it was extracted and called "ActiveRecord" as a separate thing. Helm, however, is coming from the opposite direction -- and until it becomes something you can't use K8S without, then I'm happy to see them kept separate.
GiorgioG 8y ago
I have Kubernetes in Action on my desk and I haven’t cracked it open yet because Kubernetes seems monstrously complex. Sure helm gets you up and running. When something goes wrong in prod at 3am, what do you do?
- manigandham 8y ago
  What do you do now, without Helm or Kubernetes?
- barrkel 8y ago
  K8s is actually fairly simple and self-evident once you understand about 3 core ideas: etcd being the repository of state, in particular the spec; controllers with control loops bringing status into line with spec (the core mechanism in k8s, this is key); and a familiarity with the options on pods & deployments, for initialisation, service discovery, liveness, readiness, etc. that let the system make decisions globally while you only worry about local status (this is most of what you need to know as a dev deploying a service). Don't buy the FUD. There's a lot of it about. K8s commoditises cloud providers. It's a strategic weapon against AWS lock-in.
- core-questions 8y ago
  This is my issue as well. I'm not comfortable running magic commands that create vast realms of infrastructure that I am responsible for but do not understand. It's one thing if it's all going to run on someone else's Kube, but even still, I need to be able to troubleshoot the apps on top, which are my responsibility.
flor1s 8y ago
Also there is Draft (https://kubernetes.io/blog/2017/05/draft-kubernetes-container-development/ https://kubernetes.io/blog/2017/05/draft-kubernetes-containe...)
geerlingguy 8y ago
As someone new to Kubernetes, Helm is _really_ not appealing; it masks a _ton_ of complexity, and is akin to telling someone new to Docker to run all their applications off the 'Docker Library' official images on Docker Hub. With few exceptions, those cookie cutter examples are not ideal for running production applications; they're decent starting points for learning how they could be built, just like Helm could be (if it were a little less "here's a 1,000 line Kubernetes configuration file in a box, good luck!"-ish).

ridruejo 8y ago

Correct, you can check out Kubeapps for a collection of apps packaged as Helm charts https://hub.kubeapps.com https://hub.kubeapps.com

hyperrail 8y ago

In the following paragraph, the author considers and appears to reject that solution: >Maybe the combination of operators and Helm charts covers this, but I don’t think that will cut it. Then we’re forcing developers to learn about two other things in addition to Kubernetes. Even if it’s just increasing the vocabulary and installing a new command line tool, it’s extra effort and thought. These things need to be first-class citizens and part of the Kubernetes out-of-the-box experience. They need to be accessible via kubectl.

justinjlynn 8y ago
So, instead of keeping cross-cutting concerns separate and permitting them to evolve separately, the author wants K8S to become more complex, because they'd rather learn one more complex thing than multiple simpler things? Seems legit. I mean, why should I install multiple libraries? Why can't glibc wash my car? Will glibc collapse under the weight of it's own complexity -- even though it can't wash my car like I want it to?
- dominotw 8y ago
  I think more charitable interpretation is that kuberbetes should be designed in such a way that these tools are a natural part of it. Think of active record being part of rails. Sure you can use rails without ar but that doesn't make sense.
  - justinjlynn 8y ago
    Using Ruby on Rails without ActiveRecord does make sense for a number of applications. For example, an edge caching API which uses Redis on the backend. Helm is a package manager for K8S but it isn't the package manager for K8S, which is probably why it's kept separate. ActiveRecord was the ORM for Rails, before it was extracted and called "ActiveRecord" as a separate thing. Helm, however, is coming from the opposite direction -- and until it becomes something you can't use K8S without, then I'm happy to see them kept separate.

GiorgioG 8y ago

I have Kubernetes in Action on my desk and I haven’t cracked it open yet because Kubernetes seems monstrously complex. Sure helm gets you up and running. When something goes wrong in prod at 3am, what do you do?

manigandham 8y ago
What do you do now, without Helm or Kubernetes?
barrkel 8y ago
K8s is actually fairly simple and self-evident once you understand about 3 core ideas: etcd being the repository of state, in particular the spec; controllers with control loops bringing status into line with spec (the core mechanism in k8s, this is key); and a familiarity with the options on pods & deployments, for initialisation, service discovery, liveness, readiness, etc. that let the system make decisions globally while you only worry about local status (this is most of what you need to know as a dev deploying a service). Don't buy the FUD. There's a lot of it about. K8s commoditises cloud providers. It's a strategic weapon against AWS lock-in.
core-questions 8y ago
This is my issue as well. I'm not comfortable running magic commands that create vast realms of infrastructure that I am responsible for but do not understand. It's one thing if it's all going to run on someone else's Kube, but even still, I need to be able to troubleshoot the apps on top, which are my responsibility.

flor1s 8y ago

Also there is Draft (https://kubernetes.io/blog/2017/05/draft-kubernetes-container-development/ https://kubernetes.io/blog/2017/05/draft-kubernetes-containe...)

geerlingguy 8y ago

As someone new to Kubernetes, Helm is _really_ not appealing; it masks a _ton_ of complexity, and is akin to telling someone new to Docker to run all their applications off the 'Docker Library' official images on Docker Hub. With few exceptions, those cookie cutter examples are not ideal for running production applications; they're decent starting points for learning how they could be built, just like Helm could be (if it were a little less "here's a 1,000 line Kubernetes configuration file in a box, good luck!"-ish).