8 ms·

Kubernetes 1.12

142 points by stablemap 8y ago

Logishort 8y ago
K8s 1.12 is here
brtknr 8y ago
Fast release cycle does give k8s a regular news coverage!
darren0 8y ago
It's about time for a Kubernetes to do LTS releases. 3 month release cycle and support for only 9 months is too quick for companies given that in practice companies are running lots of clusters, not just 1 or 2 big clusters.
- DasIch 8y ago
  I don’t understand your argument. If you have lots of clusters, surely you’re upgrading using some kind of CD mechanism. So it shouldn’t make a difference in time to upgrade. Zalando (disclaimer I work there, though not on K8S infrastructure. I just deploy to K8S) does upgrades this way: https://m.youtube.com/watch?v=1xHmCrd8Qn8 https://m.youtube.com/watch?v=1xHmCrd8Qn8
  - darren0 8y ago
    In practice most people do not run k8s upgrades through a CD pipeline. They are much more conservative about it. This is not a technical issue, just a cultural one mainly. People plan and roll out upgrades. Most organization treat a cluster as a large pet. They would like to avoid upgrading if they can because it's viewed as a risk. Patch releases are not typically an issue, it is minor releases that cause concern. So every 3 months is too fast for a lot of teams (again, not technical issue, this is culture of enterprise) so they may put off an upgrade. Once you do that the upgrade becomes more risky because there is obviously more change from 1 to 3 than 1 to 2. What I'm describing is not an issue specific to k8s, this is just a general enterprise infrastructure issue and one of the many reasons enterprises like LTS releases.
    - itsnotvalid 8y ago
      It's also that not all services used together may work on the latest version of k8s. For example, one of the services can only support up to 1.11 and need updates to use 1.12, then you suddenly cannot deploy 1.12 to those clusters. I think in terms of LTS it's more about having stable APIs for developing.
    - wikibob 8y ago
      I think most people would very much like to deploy cluster updates more frequently. Unfortunately this is difficult because most distributions don't keep up with the release cadence. One of (the most?) popular way to deploy Kubernetes is the Kops project. As far as I know there is nobody who is paid to work on Kops, thus the bugs and PR's don't get enough hours invested in them. Distribution and packaging is very boring and fiddly grunt work, it would be wonderful if somehow we as a community could figure out how to fund full time work on a distribution in the OSS space. Perhaps CNCF could do a better job of funding this somehow. It's a hard problem, because the organizations most suited to solving it are CoreOS/RedHat/Microsoft/Google/Amazon/etc, and they have a vested interest in putting that effort into making their hosted solutions a great experience instead. Kubeadm looks like a great step in the right direction, but as far as I'm aware, there aren't any production quality distributions for installing clusters with it yet.
    - rezeroed 8y ago
      Yes, we still have some 1.1.7s.
    - falcolas 8y ago
      And, as mentioned in a sibling comment, as complex as the K8s project is now, upgrades break things. They regularly break APIs, CLI arguments, tooling, documentation, integrations, and just about everything else. Having your entire k8s infrastructure go down due to a "oopsie" in an upgrade is a risk. And mitigating these risks takes time and effort.
      - toomuchtodo 8y ago
        As an ex-devops/infra guy, every day I'm ecstatic I don't have to wrangle k8s. These are not attributes of production infrastructure tooling. My hat is off to all of you in the trenches.
- outime 8y ago
  If your concern is about manually updating a lot of clusters, then there are many providers (GCP, AWS, DO...) offering managed solutions which most likely will handle the updates for you.
- manigandham 8y ago
  Kubernetes already has many vendors that provide packaged distributions and long-term support if you want it. If you use the managed hosting/cloud providers then updates are also automatic and easy.
  - darren0 8y ago
    I happen to be one of those vendors. I don't really view it as a good thing though. It's not good if everybody has to buy different forks of Kubernetes from vendors. A point of reference, Amazon EKS only runs 1.10 which will not be supported by the community in 3 months. So not all managed services are really keeping up.
    - manigandham 8y ago
      Ah, you're from Rancher. Great product, but isn't this exactly the problem space you serve? How many of the K8S vendors are selling distributions vs support plans? Or are they always entangled? And if the community did do LTS, isn't that just shifting the work to open-source maintainers rather than focused and paid vendors?
    - raesene9 8y ago
      Yeah having forked k8s will be bad. Back-porting possible security fixes could be tricky and having multiple companies have to do it, would be painful.
  - raesene9 8y ago
    For on premises Kubernetes who do you know of who will provide committments to support k8s after the main project stops? As far as I was aware of all the on-prem options cleave to the main project support lifecycle...
    - gk1 8y ago
      https://www.gravitational.com/telekube https://www.gravitational.com/telekube ?
- technofiend 8y ago
  I mean one could argue that anything hosted on k8s should be reproducible anyway. I completely rebuild my k8s servers on a rolling two week cycle. The pain from that forces people to check in everything they need because if they don't it'll be gone very soon. And still it's a bit of a battle to get people to test new versions of things, k8s included. "But it's working" is as much of a rallying cry as it ever was, "cloud" or no.
  - jasonrm 8y ago
    Curious about the details of how you rebuild/deploy your k8s servers. Any chance you've already written about this somewhere?
    - technofiend 8y ago
      Nothing special. Just cobbler to generate the iso and kubespray to install the cluster. Between company policy on social media and internal weirdness I can't really write a GitHub or Medium contribution to HN that anyone would want to consume anyway. However I do plan to document what I've learned in a generic sort of "If you use Digital Ocean, this is how to do X, Y, Z" way.
      - jasonrm 8y ago
        Thanks! I haven't seen cobbler before, so that's certainly something I'll take a look at. Toyed with matchbox before, but didn't end up using it. Not using DigitalOcean currently, but look forward to reading that someday.
dilyevsky 8y ago
Anyone knows if in-place VPS is actually in? Doesn’t seem like it from reading gh issue. Imo this should be at the top of the release notes, not hidden in the middle
- pas 8y ago
  What is in-place VPS?
  - dilyevsky 8y ago
    Vertical pod scaling
te_chris 8y ago
People with Kube experience, at what point should someone on Heroku consider switching to Kube with something like GKE? I have a rough idea of the pros and cons, particularly cost vs. time overhead, but curious about more subtle things.
- marenkay 8y ago
  I'm migrating "legacy" applications (as in non-containerized ones) to container environments for medium to large companies, and I would suggest two things: - get a local test setup with minikube (https://github.com/kubernetes/minikube https://github.com/kubernetes/minikube) and Helm (https://www.helm.sh/ https://www.helm.sh/) and try out a few applications - convert a project of yours to a Kubernetes deployment, then a Helm chart If both steps are successful and you still feel like Kubernetes is doing a better job for you then Heroku, get a Kubernetes professional. I promise you, there will be as many problems as with any other environment. The only difference is that the Kubernetes issues are not documented.
  - te_chris 8y ago
    "The only difference is that the Kubernetes issues are not documented." Move that one to the icebox then!
- base698 8y ago
  I run a platform that is running applications multicloud, one of which is Heroku. Our devs that use heroku absolutely hate k8s. They feel it's way more complicated and cumbersome and say they don't want to write thousand line YAML files and YAML engineering isn't their job. Also, the pipelines Heroku provides and new CD is far superior. They don't want to reinvent Heroku. Personally after I got k8s I felt about it how I felt about git. I think it's game changing and everyone should learn something about it. Can understand the frustration though.
- sciurus 8y ago
  If you want to migrate in order to use some of the many services offered by Google Cloud, migrating from Heroku to App Engine is likely an easier path.
vkat 8y ago
kubelet tls bootstrap is a feature I am looking forward to. We just finished dev work and testing to get to 1.11 as we have to support various cni's and automated upgrades from 1.10, it will probably be couple of months before we get to 1.12

Kubernetes 1.12

142 points by stablemap 8y ago

Logishort 8y ago

K8s 1.12 is here

brtknr 8y ago

Fast release cycle does give k8s a regular news coverage!

darren0 8y ago

It's about time for a Kubernetes to do LTS releases. 3 month release cycle and support for only 9 months is too quick for companies given that in practice companies are running lots of clusters, not just 1 or 2 big clusters.

DasIch 8y ago
I don’t understand your argument. If you have lots of clusters, surely you’re upgrading using some kind of CD mechanism. So it shouldn’t make a difference in time to upgrade. Zalando (disclaimer I work there, though not on K8S infrastructure. I just deploy to K8S) does upgrades this way: https://m.youtube.com/watch?v=1xHmCrd8Qn8 https://m.youtube.com/watch?v=1xHmCrd8Qn8
- darren0 8y ago
  In practice most people do not run k8s upgrades through a CD pipeline. They are much more conservative about it. This is not a technical issue, just a cultural one mainly. People plan and roll out upgrades. Most organization treat a cluster as a large pet. They would like to avoid upgrading if they can because it's viewed as a risk. Patch releases are not typically an issue, it is minor releases that cause concern. So every 3 months is too fast for a lot of teams (again, not technical issue, this is culture of enterprise) so they may put off an upgrade. Once you do that the upgrade becomes more risky because there is obviously more change from 1 to 3 than 1 to 2. What I'm describing is not an issue specific to k8s, this is just a general enterprise infrastructure issue and one of the many reasons enterprises like LTS releases.
  - itsnotvalid 8y ago
    It's also that not all services used together may work on the latest version of k8s. For example, one of the services can only support up to 1.11 and need updates to use 1.12, then you suddenly cannot deploy 1.12 to those clusters. I think in terms of LTS it's more about having stable APIs for developing.
  - wikibob 8y ago
    I think most people would very much like to deploy cluster updates more frequently. Unfortunately this is difficult because most distributions don't keep up with the release cadence. One of (the most?) popular way to deploy Kubernetes is the Kops project. As far as I know there is nobody who is paid to work on Kops, thus the bugs and PR's don't get enough hours invested in them. Distribution and packaging is very boring and fiddly grunt work, it would be wonderful if somehow we as a community could figure out how to fund full time work on a distribution in the OSS space. Perhaps CNCF could do a better job of funding this somehow. It's a hard problem, because the organizations most suited to solving it are CoreOS/RedHat/Microsoft/Google/Amazon/etc, and they have a vested interest in putting that effort into making their hosted solutions a great experience instead. Kubeadm looks like a great step in the right direction, but as far as I'm aware, there aren't any production quality distributions for installing clusters with it yet.
  - rezeroed 8y ago
    Yes, we still have some 1.1.7s.
  - falcolas 8y ago
    And, as mentioned in a sibling comment, as complex as the K8s project is now, upgrades break things. They regularly break APIs, CLI arguments, tooling, documentation, integrations, and just about everything else. Having your entire k8s infrastructure go down due to a "oopsie" in an upgrade is a risk. And mitigating these risks takes time and effort.
    - toomuchtodo 8y ago
      As an ex-devops/infra guy, every day I'm ecstatic I don't have to wrangle k8s. These are not attributes of production infrastructure tooling. My hat is off to all of you in the trenches.
outime 8y ago
If your concern is about manually updating a lot of clusters, then there are many providers (GCP, AWS, DO...) offering managed solutions which most likely will handle the updates for you.
manigandham 8y ago
Kubernetes already has many vendors that provide packaged distributions and long-term support if you want it. If you use the managed hosting/cloud providers then updates are also automatic and easy.
- darren0 8y ago
  I happen to be one of those vendors. I don't really view it as a good thing though. It's not good if everybody has to buy different forks of Kubernetes from vendors. A point of reference, Amazon EKS only runs 1.10 which will not be supported by the community in 3 months. So not all managed services are really keeping up.
  - manigandham 8y ago
    Ah, you're from Rancher. Great product, but isn't this exactly the problem space you serve? How many of the K8S vendors are selling distributions vs support plans? Or are they always entangled? And if the community did do LTS, isn't that just shifting the work to open-source maintainers rather than focused and paid vendors?
  - raesene9 8y ago
    Yeah having forked k8s will be bad. Back-porting possible security fixes could be tricky and having multiple companies have to do it, would be painful.
- raesene9 8y ago
  For on premises Kubernetes who do you know of who will provide committments to support k8s after the main project stops? As far as I was aware of all the on-prem options cleave to the main project support lifecycle...
  - gk1 8y ago
    https://www.gravitational.com/telekube https://www.gravitational.com/telekube ?
technofiend 8y ago
I mean one could argue that anything hosted on k8s should be reproducible anyway. I completely rebuild my k8s servers on a rolling two week cycle. The pain from that forces people to check in everything they need because if they don't it'll be gone very soon. And still it's a bit of a battle to get people to test new versions of things, k8s included. "But it's working" is as much of a rallying cry as it ever was, "cloud" or no.
- jasonrm 8y ago
  Curious about the details of how you rebuild/deploy your k8s servers. Any chance you've already written about this somewhere?
  - technofiend 8y ago
    Nothing special. Just cobbler to generate the iso and kubespray to install the cluster. Between company policy on social media and internal weirdness I can't really write a GitHub or Medium contribution to HN that anyone would want to consume anyway. However I do plan to document what I've learned in a generic sort of "If you use Digital Ocean, this is how to do X, Y, Z" way.
    - jasonrm 8y ago
      Thanks! I haven't seen cobbler before, so that's certainly something I'll take a look at. Toyed with matchbox before, but didn't end up using it. Not using DigitalOcean currently, but look forward to reading that someday.

dilyevsky 8y ago

Anyone knows if in-place VPS is actually in? Doesn’t seem like it from reading gh issue. Imo this should be at the top of the release notes, not hidden in the middle

pas 8y ago
What is in-place VPS?
- dilyevsky 8y ago
  Vertical pod scaling

te_chris 8y ago

People with Kube experience, at what point should someone on Heroku consider switching to Kube with something like GKE? I have a rough idea of the pros and cons, particularly cost vs. time overhead, but curious about more subtle things.

marenkay 8y ago
I'm migrating "legacy" applications (as in non-containerized ones) to container environments for medium to large companies, and I would suggest two things: - get a local test setup with minikube (https://github.com/kubernetes/minikube https://github.com/kubernetes/minikube) and Helm (https://www.helm.sh/ https://www.helm.sh/) and try out a few applications - convert a project of yours to a Kubernetes deployment, then a Helm chart If both steps are successful and you still feel like Kubernetes is doing a better job for you then Heroku, get a Kubernetes professional. I promise you, there will be as many problems as with any other environment. The only difference is that the Kubernetes issues are not documented.
- te_chris 8y ago
  "The only difference is that the Kubernetes issues are not documented." Move that one to the icebox then!
base698 8y ago
I run a platform that is running applications multicloud, one of which is Heroku. Our devs that use heroku absolutely hate k8s. They feel it's way more complicated and cumbersome and say they don't want to write thousand line YAML files and YAML engineering isn't their job. Also, the pipelines Heroku provides and new CD is far superior. They don't want to reinvent Heroku. Personally after I got k8s I felt about it how I felt about git. I think it's game changing and everyone should learn something about it. Can understand the frustration though.
sciurus 8y ago
If you want to migrate in order to use some of the many services offered by Google Cloud, migrating from Heroku to App Engine is likely an easier path.

vkat 8y ago

kubelet tls bootstrap is a feature I am looking forward to. We just finished dev work and testing to get to 1.11 as we have to support various cni's and automated upgrades from 1.10, it will probably be couple of months before we get to 1.12