Here's the changelog https://github.com/kubernetes/kubernetes/blob/master/CHANGEL...

I'm confused as to whether scheduled jobs is in this release. Great work k8s team.

edit: I see it got pushed to 1.4 https://github.com/kubernetes/kubernetes/issues/28496. Too bad, I was really looking forward to that.

Yep, JUST missed it :(

Fortunately, we're on 3 month release cycles, so you won't have to wait long :)

Disclosure: I work at Google on Kubernetes.

Then it'll be just in time for my birthday!

Keep up the great work guys, Kubernetes is amazing.

Excellent. The job feature has been a godsend. We had a hacky version for one-off jobs but k8-job feature removed some of those complexities. cron-jobs will be one step closer to an ideal solution.

We have to thank the community for the amazing work in this release - Stateful application support, laptop development in one command and cross cluster service federation. Onward and upward!

Disclosure: I work at Google on Kubernetes.

Previous discussion when the release was tagged on GitHub late last week: https://news.ycombinator.com/item?id=12022215

Minikube is great for finally providing a reasonable toes-in-the-water experience.

Yep! For those that haven't seen it - https://github.com/kubernetes/minikube It's really cool - even runs a FULL UI locally (minikube dashboard), and supports xhyve, virtualbox, KVM and VMWare Fusion.

TL;DR

  # For Mac
  $ curl -Lo minikube https://storage.googleapis.com/minikube/releases/v0.4.0/minikube-darwin-amd64 && chmod +x minikube && sudo mv minikube /usr/local/bin/
  # For Linux
  curl -Lo minikube https://storage.googleapis.com/minikube/releases/v0.4.0/minikube-linux-amd64 && chmod +x minikube && sudo mv minikube /usr/local/bin/
  $ minikube start
  $ (99% of regular kubernetes commands here)

Disclosure: I work at Google on Kubernetes.

Why does minikube use a VM layer on Linux? Is it just for flexibility and not using the local docker daemon?

We mainly use the VM to provide a well-known and tested environment for Kubernetes to run in. Running inside a Docker container on Linux would have similar benefits, but there are still a few bugs with running some of the Kubernetes components inside containers.

We'll probably add a "native" option for Linux at some point. See this issue: https://github.com/kubernetes/minikube/issues/261 for a little more conversation.

Disclosure: I work at Google, on Minikube.

This is very cool, finally I don't need a datacentre to test some things :)

thanks!

I don't know if this is why, but when I work with Docker on Linux, I prefer to use docker-machine's VM layer because that way, I don't need to run docker commands as root.

My only complaint with the VM layer is it's harder to have faster iterations with local development. I know this isn't the documented way to develop with kubernetes but I often use containers with -v $PWD:/app to test things interactively

Ahh, now that makes sense. I don't usually develop inside a container, so that's why I haven't had this issue before.

That's how I usually work with my code on local development.

That's pretty cool, as some of the Kubernetes installation procedures can look a little daunting.

One question though, are there any plans to support Windows as a host OS for this (either via VMWare Workstation or Hyper-V directly, or via something like Vagrant)?

I was curious about this as well:

https://github.com/kubernetes/minikube/issues/28

Heh - this is now out of date (we move fast!)

Rather than linking to the new command, here's a list of all the releases, with instructions:

https://github.com/kubernetes/minikube/releases

you linked to the 0.4.0 version, but apparently there's a 0.5.0 version now; replacing 0.4.0 with 0.5.0 worked for me, and 0.5.0 seems to work better on osx 10.10.

Great experience using it so far. I'm using the virtualbox driver, but does anyone know if using the xhyve driver will conflict with docker for mac beta? Looks like they are using docker-machine under the hood?

They don't conflict as far as I can tell! I use Docker for Mac and the xhyve driver simultaneously.

Disclosure: I work for Google, on Minikube.

Cool deal. Great work! Any plans to streamline setting up k8s on AWS? I've run into issues with not enough vpcs etc. On GCP it couldn't be easier.

Does anyone have any experience running minikube on a NUC (or something similar)?

Has the documentation website been updated? I'm still seeing a lot of things that link directly to "release-1.2" and I can't find any information about RBAC. Kubernetes is great, but the docs have never been treated as a first-class citizen. I'd love to see the docs be considered part of the deliverable that is a release.

Two questions:

1) Does kubernetes have checkpoint/restore on its roadmap? We'd like to restore from a checkpoint instead of a fullblown docker run...

2) Is it possible to get hired directly onto the kubernetes team?

1) Can you say more what you're looking for? Specifically image checkpoint/restore? Something else? 2) Yes! We're hiring :) However, you can start working on k8s wherever you are - we're 100% open source.

Disclosure: I work at Google on Kubernetes.

Suspect the parent may be talking about CRIU support? I think it's a way off, but it is definitely worth thinking about how this would work in Kube world.

I blogged about this here:

https://zwischenzugs.wordpress.com/2015/10/11/docker-migrati...

Is the open source work on Kubernetes at Google being done directly on the GitHub repo or is there an internal mirror where work is first done and internal issues tracked separately, similar to Android?

100% open (there is no mirror repo that I'm aware of). There's certainly internal discussion, particularly when some members of the team don't want to be "seen in public", but this isn't like other projects where it's sync'ed from a hidden internal repo.

Disclaimer: while I work at Google on Cloud, and know the K8s folks, I've never even committed any changes.

100% on GH and open. Some design talks might get hashed out in private, but they all end up in a GH issue or PR as a design doc.

I work at Red Hat on Kube.

It doesn't support checkpoints or container migrations right now, but it does go out of its way to hide from pods all the details about the host, in order to support them in a future release.

Can't get the hello world to run... something is amiss in the instructions. I get to here, using windows:

C:\Users\kkss\hellonode>docker build -t gcr.io/<HIDDEN>/hello-node:v1 .

An error occurred trying to connect: Post http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.23/build?buildargs=... usetmems=&cpushares=0&dockerfile=Dockerfile&labels=%7B%7D&memory=0&memswap=0&rm=1&shmsize=0&t=gcr.io%2F<HIDDEN>%2Fhello-node%3Av1&ulimits=null: open //./pipe/docker_engine: The system cannot find the file specified.

Looks like you need to set up `docker-machine`, or use the new Docker for Windows distribution [1], which abstractly includes it.

1: https://docs.docker.com/engine/installation/windows/

The instruction that I needed to run 'Docker Quickstart' (as Administrator) was not obvious.

I guess it is difficult to describe the steps when there is a major difference between platform methods (windows 7 and Docker Toolbox vs win 10 with Docker).

After that I am up and running. Thanks for the pointer.

I have a cluster that I'm looking to upgrade on AWS and was holding off for some information on upgrade procedures but I see this "Instructions coming soon" under "Known Issues and Important Steps before Upgrading".

There is some information here: http://kubernetes.io/docs/admin/cluster-management/

I've had a lot of bad experiences with the Kubernetes docs being misleading, outdated, or incomplete, so be relying on anything there.

We have a brand new repo for fixing these things - https://github.com/kubernetes/kubernetes.github.io - but that said, if you EVER run into something misleading, outdated or incomplete, please ping immediately!

Disclosure: I work at Google on Kubernetes.

Thanks! I'm aware of that repo. I think the problem is much deeper than can be fixed by creating more issues in the repo. The docs for k8s really need to be approached holistically by a technical writer or someone else who works on it full time. What's there now, and the approach the project has taken towards docs thus far, has resulted in information that is inconsistent, not well organized, and not well maintained. I think comprehensive documentation should be considered a requirement for a release—just as important as the code or the test suite. Software is only useful if people can figure out how to use it, and it's very hard to do that when it's so difficult to find high quality information.

Yeah kube-push.sh is mentioned there but it's disabled for all cluster types apparently.

How did you setup the cluster on AWS? Which instructions did you follow?

I just followed the setup procedure from the k8 docs: http://kubernetes.io/docs/getting-started-guides/aws/

what matburt said,plus be sure to setup TLS from CoreOS docs

How does Kubernetes compare with Docker? Does it compete with swarm, or which parts of the docker tools does it overlap with?

Docker Swarm (built into Docker 1.2) is in the same econiche as Kubernetes, but is not as mature. It is still catching up, and probably more on par with pre-1.0 Kubernetes feature-wise. Kubernetes is what Docker will be when it grows up.

Note: I don't work for Docker or on the Kubernetes team. I have put things into production with Docker, Docker Compose, AWS ECS, and Kubernetes 1.1 on AWS for the past two years and have built tools on top of K8S.

Kubernetes, docker swarm mode, mesos/marathon and ecs are all in the same space.

Maybe this is off topic, but how do you pronounce Kubernetes. Is the last 'es' silent?

koo-ber-net-ees [1]

[1] https://twitter.com/brendandburns/status/585479466648018944