Kubernetes 1.9: Apps Workloads GA and Expanded Ecosystem

What type of infrastructures do you run kubernetes on?

That's so great to hear! I love to see how it empowers small teams to deliver big stuff.

What was the trickiest part for you when it comes to real production usage?

Couldn’t have said it better myself. I am so grateful.

Great post. Could you describe further what you mean by data pipelining? Is this something that you could also use Spark, Kafka for? I'd be interested to know if Kubernetes would work for me as well.

Have you checked out Pachyderm (disclaimer: my company) for data pipelining on Kubernetes?

Our product has been available since the first Kubernetes release and is specifically designed for data analysis and pipelining tasks on Kubernetes.

github.com/pachyderm/pachyderm

pachyderm.io

As much as I like kubernetes, I find the whole ecosystem to be frustratingly immature and unreliable. I'm sure it's trending in the right direction with respect to reliability, but it just doesn't feel like it's there yet. Minikube seems especially buggy and is missing some obvious features.

FWIW, if you create a GKE cluster and create an nginx deployment:

kubectl apply -f https://k8s.io/docs/tasks/run-application/deployment.yaml

And simply create a Load Balancer:

https://kubernetes.io/docs/tasks/access-application-cluster/...

You have nginx exposed via an external IP address in about two minutes. Once you're comfortable with that, you can start working in Ingress and such to get more sophisticated.

I agree the IRC/Slack channel communication isn't the best. I prefer the Kubernetes User Group. You can usually get a great response in less than a day. I've used it a lot.

I am not a Linux expert, but I deployed clusters to 5 Raspberry Pi and Azure with custom terraform scripts. With the kubeadm things are much more straightforward now. My suggestion is to start with minikube with kubeadm bootstrapper than use more complicated solutions. https://kubernetes.io/docs/setup/pick-right-solution

You should take a look at Rancher[1]. I think it has the right mix of raw access to Kubernetes and associated tools, but also addresses some of the requirements you have.

1: https://rancher.com

Disclaimer: I've been working in the container ecosystem for a number of years, currently at Rancher.

I don't know what IRC channels you're referring to, but the Kubernetes Slack is very active. I've gotten a lot of help there. It also has channels where the devs are active.

Most of kube-users hang out on slack. I am not saying you will get definite answers but as a k8s core contributor - I can definitely say that most developers are on slack rather than IRC.

not sure if it helps, but I recently did a series of posts on my blog on installing Kubernetes from scratch on a set of CoreOS guests on Xen, with flannel, RBAC, TLS and so on and it does give you a cluster that you should be able to access from the outside no problem.

Link in my profile, I tried to make as low in magic as possible, I just ended up writing a couple of bash functions and a python script to make it easier to assemble the Ignition files for the deployment, but besides that it should all be step by step.

Watch tutorials by Kelsey Hightower, he's been helping folks understand the differences and the models. e.g. https://www.youtube.com/watch?v=HlAXp0-M6SY

Your experience is a real shame, truly. If Kubernetes could fix their horrendous documentation and onboarding story, I think you'd have a much better experience. After bruising past that battle, I found Kubernetes to be the perfect mix of sanity and opinionated architecture. I think part of it is also due to how rapidly it's evolved over the past 2 years, so hopefully you get a chance to revisit it once some of those rough edges are smoothed over!

No worries, we understand the pain, we've all been there.

The abstracted network is a constant source of headache when dealing with kubernetes and containers.

I've found one way past it: kubespray

I spent the morning listening to presentations from Kubecon last week, and a guy mentioned it in passing in one of the presentations. Went and looked at it and it's an Ansible playbook for deploying Kubernetes clusters. Respun my test nodes with a bare install and ran kubespray and I was up and running with Calico networking all set up, I'm able to get to the test pod I set up from anywhere.

So pro tip: Kubespray, especially if you are familiar with ansible!

I feel what you are going through. I wrote this last week trying to help: http://blog.cloud66.com/8-components-you-need-to-run-contain...

It's to be seen but owners of the spec represent mesos, kubernetes, docker and cloud foundry so it seems like Docker is open to the idea. source:

https://github.com/container-storage-interface/spec/blob/mas...

Mostly the answer is "if you want to do it all yourself, go for it";

Things like this, and especially Kubernetes, are about creating a common and agreed upon language for infrastructure - both patterns and specific "off the shelf" applications

It's very nice to be able to start a Proof of Concept data pipeline with `helm install incubator/kafka` (https://github.com/kubernetes/charts/tree/master/incubator/k...)

And likewise the common language/interface creates opportunities for wider coverage and easier adoption in tooling for monitoring, autoscaling, smart routing (see "service mesh"es), etc.

You may not need all of k8s functionality immediately but it's the agreed upon common core for modern distributed systems functionality

And to everyone's credit it's also being done pretty much as modularly and extensiblely as we could hope for

Well, if you took the risk of sounding snarky, I might as well take the risk of offending a number of projects as well. The following is my personal opinion only.

From touching this stack quite a bit over the past year, my lasting impression is that most people don't actually need it, but that at the same time one shouldn't decry the value of toying with a new tech stack.

(By the way, I get the same impression from many Hadoop users who carry this large infrastructural debt from building out much too early.) Many people gravitate towards these things in order to learn them better, which can be wise on a personal level should they become more popular.

For me personally, I think the value with Kubernetes is if it becomes a provider independent cloud platform. Bascially what Openstack couldn't deliver, Kubernetes takes the core of and delivers an orchestration platform on that is actually useful. So while you shouldn't invest resources in it solely because it's a new stack, the design is sane and the community is there.

Maybe you don't. I wouldn't recommend anyone to use something extremely complex for mission critical architecture, unless unavoidable. If you feel the same, it's probably a perfectly sound reason to avoid Kubernetes if there's no necessity.

When I wrote "extremely complex" I did't mean all that models and concepts from user documentation - they're the easy part (although I haven't used K8s much and probably missing a lot about its user-facing parts). I mean the internals. Because when things break and cluster goes down it's the internals that matter.

I use Docker instead of plain LXC because it adds convenience of layers and versioning while not introducing any significant complexity. I had some issues with libnetwork (which sometimes behaved oddly when containers crash under high load or docker-proxy gets somehow stuck) but I can live with it.

I also prefer Swarm to manual networking. It's trivial to set up and just works under normal circumstances. And I feel confident that I can fix issues reasonably fast. I had experimented with it under some odd scenarios (like a heterogeneous cluster with a mix of x86_64 and armv7h nodes) and when it had (obviously) failed, I was able to quickly find the relevant source code, read it, understand the details and correct the problem (which was trivial but not documented). And if I wouldn't be able to, I'm absolutely certain I would be able to scrap the cluster and script reprovisioning with standalone nodes, Compose and ad-hoc VPNs - I did this when Rancher (old version) had failed me badly.

Now, maybe I'm just too stupid but I can't say this for Kubernetes. I've tried to experiment with it - also under explicitly unsupported conditions - and tried to dig into its documentation and code when it had failed (obviously it did, I was asking for it). However, I was literally overwhelmed by how much there is. What I've learned is a little tiny bit about CNI internals but the primary result was a conclusion "sorry but nope, that's not something I feel comfortable dealing with if I'm to support it". And I don't mean that it fail-prone or anything - just that every software project has its bugs, and sometimes they manifest themselves at really inconvenient times.

On the other hand, Kubernetes is very nice when it's not you who's responsible for its operation but you're just an user. Spin a cluster on GKE and you know Google would take care of it - you'd just have to write some YAML to describe your project and enjoy. In this scenario, I think I can recommend it - even though I haven't ran anything serious on K8s but some toy projects worked without issues and were easy to deploy and maintain. And Kubernetes feels more mature than other options, having lots of nice functionality, supposedly covering a lot of different use cases and scenarios. E.g. Swarm feels like it lacks a lot of stuff - I've subscribed to a lot of tickets for features that I wanted but that aren't yet there.

Just a personal opinion.

I agree with the "because it's fun to learn" answers.

But I'd also add the reliability factor of keeping a quorum of containers running. It's a tool for dealing with the unreliability of cloud infrastructure, and unexpected process death.

In general, I tend to think that any tooling I can avoid writing (and documenting, and debugging, and maintaining...) is an advantage. As someone who has done the whole "running my own containers from bash scripts and cronjobs", Kubernetes (and in particular the hosted Kubernetes clusters provided by Google Cloud, Azure and AWS) does a great job of managing a lot of crap I don't want to deal with, such as:

- Networking setup and service discovery - Managing container failure - Secret storage - Deployments (in particular, sensibly-managed Rolling Deployments) - Container-cluster size management - Ingress management (load balancers are a pain in the ass to manage from bash scripts) - Resource monitoring (Kubernetes comes with a nice interface to watch the cluster and modify it dynamically)

There's nothing stopping you from building all of that from scratch, but why bother?

Kubernetes is not supposed to be run on a single node, but on dozens or hundreds of machines. Scheduling, networking, and authorizing heterogeneous highly available workloads by possibly different teams + managing ingress + managing networked storage is what Kubernetes is built for.

I wouldn't know how to do this with LXC

Why would you write scripts or learn LXC commands when you can just write a k8 deployment? Even if you don't consider all the more advanced features, it's just easier and declarative and supported natively by several cloud providers.

I've been in your shoes using LXC way back but moved to Docker fairly quickly when it came out, so I kinda get your position.

Now, Kubernetes/Docker provide better tooling with added benefits. Docker provides a Dockerfile based declarative approach of building the setup and storing it in an image and then running it as a container with greater flexibility and more features than a typical LXC based script. Kubernetes takes the running of multiple containers to another level capable of managing 100s or even 1000s of them for scalable operations.

RTFM for the details :-)

HTH!

Kuberenetes is meant to be a self-healing always up infrastructure, if your minikube goes down, it cannot heal fast enough, and your services will go down. It is recommended to have at least 3 nodes.

Minikube runs in a virtual machine because its meant to be a cross platform development environment, and linux containers aren't natively supported on macOS or windows.

Minikube does have a --none driver, which run on bare metal and can be used to provision a cluster on virtualized hardware, such as a CI system or a GCE instance.

Why not minikube in production? Upgrades, downgrades, clean-up and maintenance. We don't offer any real guarantees on these lifecycle operations unlike a more robust setup like GKE.

Disclaimer: I work on minikube

Huh, I've been wrapping my ML models into a flask app and deploying it as well. If you don't mind me asking, what are you using the ML model for, and what are the current suck-ass parts of deploying it?

You can get what you want with capistrano and a something like unicorn taht supports no downtime deploys