61–70 of 171 posts
I’ve got a catalog of Puppet manifests for managing the cluster that I hope to publish one day soon.
Suppose I'm an application developer who is only interested in infrastructure because there needs to be some to run my stuff. In this scenario, would I actually learn Kubernetes, or would it make more sense to go to straight to a PaaS solution? Like OpenShift (which uses k8s in the backend, I believe), or Cloud Foundry, Stackato etc. I always get the impression that k8s has a lot of good ideas, but doesn't provide ev…
> Suppose I'm an application developer who is only interested in infrastructure because there needs to be some to run my stuff. Yes, you are the perfect candidate for a PaaS solution. In general, unless you are spending thousands of dollars in infra per month, managing your own services is a waste of money.
OpenShift's value (and its open source upstream Origin) is not just that it is a PaaS. It's a PaaS that you can install and run on many different infrastructure bases: baremetal, VM, public & private cloud, and others very soon. I personally run a couple flavors on my laptop for demo and training purposes. So maybe upstream Kubernetes is not so simple. But that is why we (Red Hat) call OpenShift "Kubernetes for the Enterprise". It means we make some sensible defaults, decisions, architecture choices and make installation supportable to get you started. However, the fact that OpenShift & Kubernetes allow you to define you application architecture in reusable and portable object definitions is it's biggest benefit, IMO. And you may not need to spend thousand of dollars in infra per month to enjoy that benefit.
Right tool for the right job. Is K8s too complicated? For some use cases it is. They probably should do a better job of discouraging certain use cases, but calling their elevator pitch “bullshit” is hyperbolic. There are exceptions to every rule, but a good rule of thumb is cluster size. If you’re managing less than 25 servers than K8s is probably over kill. As you start to creep north of 40 servers K8s really starts…
Docker compose can handle simple container situations and many PoCs just fine, and part of the work will be analogous to the Kubernetes solution. If all you have is a handful of load balanced web servers and a database you can hold off on kube for a while.
Earlier quoted context omitted.
Hosted k8s. all the benefits with almost no extra maintenance.
what if you can't use hosted k8s. what if you are on vmware 3 node (no vsphere). what if you at least need consul/etcd, postgresql, haproxy + two nodes (should be as highly available as possible). how do you keep everything up to date, how do you deploy (no downtime) without a complex ansible config. for myself I use k8s either bootkubed or kubeadm, I create ignition configs via cloud-config (coreos) and create coreo…
Earlier quoted context omitted.
The problem with adding the Ingress controller via Helm (and with a lot of other Kubernetes abstractions) is that it spits out a lot of code that is then difficult or impossible to reason about. `Helm Ingress --whateversyntaxdefualt` spits out 1000+ lines of Ingress controller code that is essentially two deployments with a health check and auto spin up, but it's complicated. In production can I use this or is there…
I have read through the nginx ingress controller code in Helm before deploying it into production. What you're saying is pretty much the result of my biggest gripe with Kubernetes, though it's one I don't have a lot of ideas of how to fix; there's too much damn boilerplate. 1000 lines of YAML to store maybe 100 relevant lines. That being said, can you trust that there is not a security vulnerability when you deploy i…
No, this is not replacing the YAML under the hood, it's just more convenient for humans as a higher layer.
Earlier quoted context omitted.
You may want to update your tutorial to use cert-manager because kube-lego is in maintenance-only mode
You mean, it's stable. That sounds like a good reason to use it, not to avoid it.
Earlier quoted context omitted.
The problem with adding the Ingress controller via Helm (and with a lot of other Kubernetes abstractions) is that it spits out a lot of code that is then difficult or impossible to reason about. `Helm Ingress --whateversyntaxdefualt` spits out 1000+ lines of Ingress controller code that is essentially two deployments with a health check and auto spin up, but it's complicated. In production can I use this or is there…
I have read through the nginx ingress controller code in Helm before deploying it into production. What you're saying is pretty much the result of my biggest gripe with Kubernetes, though it's one I don't have a lot of ideas of how to fix; there's too much damn boilerplate. 1000 lines of YAML to store maybe 100 relevant lines. That being said, can you trust that there is not a security vulnerability when you deploy i…
I think that's more a helm issue than a k8s issue. I've been using helm in production for over a year and k8s for almost three years. Prior to adopting helm we rolled our own yaml templates and had scripts to update them with deploy-time values. We wanted to get on the "standard k8s package manager" train so we moved everything to helm. As a template engine it's just fine: takes values and sticks them in the right places, which is obv not rocket science. The issues come from its attempt to be a "package manager" and provide stable charts that you can just download and install and hey presto you have a thing. As a contributor to the stable chart repo I get the idea, but in practice what you end up doing is replacing a simple declarative config with tons of conditionally rendered yaml, plug-in snippets and really horrible naming, all of which is intended to provide an api to that original, fairly simple declarative config. Add to that the statefulness of tiller and having to adopt and manage a whole new abstraction in the form of "releases." At this point I'm longing to go back to a simpler system that just lets us manage our templates, and may try ksonnet at some point soon.