The future of Kubernetes is virtual machines - <AUTHOR> http://tech.paulcz.net/blog/future-of-kubernetes-is-virtual-machines/ <comment><USER2> An important element of Kubernetes is that it standardizes the infrastructure control plane, and allows different pieces to be plugged in (for networking, storage, etc.).

The "virtual kubelet" essentially throws that all that away and keeps Kubernetes "in API only". For example, with virtual kubelets, scheduling is meaningless and networking and storage are restricted to whatever the virtual kubelet target supports (if useable at all).

Personally, I think the value proposition is tenuous -- you can create VMs today, doing so via the Kubernetes API isn't suddenly revolutionary. Just like throwing something in a "hardware virtualized" instance doesn't suddenly make the whole system secure.

Containers and Kubernetes are compelling for a variety of reasons, improving them to handle multi-tenancy is a broad challenge but I don't think the answer is to reduce the standard to what we have today (a bunch of disparate VMs).

<comment><USER3> > _Personally, I think the value proposition is tenuous_

Multi-tenancy is a pretty compelling value proposition when you reach any kind of scale. If you're in a regulated sector, it's non-negotiable.

Relying on the cluster as the security boundary is very effective ... and very wasteful.

> _Containers and Kubernetes are compelling for a variety of reasons, > improving them to handle multi-tenancy is a broad challenge but I don 't > think the answer is to reduce the standard to what we have today (a bunch of > disparate VMs)._

I think the argument is that rather than the painful (and it will be _very_ painful) and probably incomplete quest to retrofit multi-tenancy into a single-tenancy design, we can introduce multi-tenancy where it basically actually matters: at the worker node.

At first glance it's confusing to go from "one master, many nodes" to "one node pool, many masters". But it actually works better on every front. Workload efficiency goes up. Security surface area between masters becomes close to nil.

Very cheap VMs are the means to that end.

Disclosure: I work for Pivotal and this argument fits our basic doctrine of how Kubernetes ought to be used.

<comment><USER4> I don't think multi-tenancy has been "retrofitted" onto Kubernetes. Kubernetes was designed with multi-tenancy in mind from the very early releases -- namespaces, authn/authz (initially ABAC, later RBAC), ResourceQuota, PodSecurityPolicy, etc. New features are added over time, such as NetworkPolicy (which has been in Kubernetes for a year and a half, so perhaps not "new" anymore!), EventRateLimit, and others, but always in a principled way. And the integration of container isolation technologies like gVisor and Kata are using a standard Kubernetes extension point (the Container Runtime Interface) so I do not view this work as retrofitting.

Moreover, even today there are real public PaaSes that expose the Kubernetes API served by a multi-tenant Kubernetes cluster to mutually untrusting end- users, e.g. OpenShift Online and one of the Huawei cloud products (I forget which one). Obviously Kubernetes multi-tenancy isn't going to be secure enough today for everyone, especially folks who want an additional layer of isolation on top of cgroups/namespaces/seccomp/AppArmor/etc., but there are a lot of advantages to minimizing the number of clusters. (See my other comment in this thread about the pattern we frequently see of separate clusters for dev/test vs. staging vs. prod, possibly per region, but sharing each of those among multiple users and/or applications.)

Disclosure: I work at Google on Kubernetes and GKE.

<comment><USER3> > _I don 't think multi-tenancy has been "retrofitted" onto Kubernetes. > Kubernetes was designed with multi-tenancy in mind from the very early > releases -- namespaces, authn/authz (initially ABAC, later RBAC), > ResourceQuota, PodSecurityPolicy, etc._

My complaint is that these require assembly and are in many cases opt-in (making RBAC opt-out was a massive leap forward).

Namespaces are the lynchpin, but are globally visible. In fact an enormous amount of stuff tends to wind up visible in some fashion. And I have to go through all the different mechanisms and set them up correctly, align them correctly, to create a firmer multi-tenancy than the baseline.

Put another way, I am having to construct multi-tenancy inside multiple resources at the root level, rather than having tenancy _as_ the root level under which those multiple resources fall.

> _there are a lot of advantages to minimizing the number of clusters._

The biggest is going to be utilisation. Combining workloads pools variance, meaning you can safely run at a higher baseline load. But I think that can be achieved more effectively with virtual kubelet .

<comment><USER4> > The biggest is going to be utilisation. Combining workloads pools variance, > meaning you can safely run at a higher baseline load.

Utilization is arguably the biggest benefit (fewer nodes if you can share nodes among users/workloads, fewer masters if you can share the control plane among users/workloads), but I wouldn't under-estimate the manageability benefit of having fewer clusters to run. Also, for applications (or application instances, e.g. in the case of a SaaS) that are short-lived, the amount of time it takes to spin up a new cluster to serve that application (instance) can cause a poor user experience; spinning up a new namespace and pod(s) in an existing multi-tenant cluster is much faster.

> But I think that can be achieved more effectively with virtual kubelet .

I think it's hard to compare virtual kubelet to something like Kata Containers, gVisor, or Firecracker. You can put almost anything at the other end of a virtual kubelet, and as others have pointed out in this thread virtual kubelet doesn't provide the full Kubelet API (and thus you can't use the full Kubernetes API against it). At a minimum I think it's important to specify what is backing the virtual kubelet, and what Kubernetes features you need, in order to compare it with isolation technologies like the others I mentioned.

Disclosure: I work at Google on Kubernetes and GKE.

<comment><USER5> One trick I used before was to create resources and leave them unused until they are allocated, at which point I create another one to top off the pool of pre-created resources. A stopped cluster takes up disk space and nothing else and this is an easy solution to the user experience issue.

Of course, hardening multi-tenant clusters is also needed. Even if the use case requires resource partitioning, there are use cases that don't and keeping one friend from stepping on another's toes is always a good idea.

</comment></comment></comment></comment></comment></comment><comment><USER6> As someone who has been a sysadmin and system programmer for 25 years and a crusty rat bastard for almost that long, I have to wonder how long it is going to be until someone realizes that a piece of hardware doing a task is more efficient than 27 layers of virtual machines and a long pair of tongs.

<comment><USER7> amen. At first i figured containers were a good way to run code with difficult dependencies and weird operating environments, but that still doesnt make sense.

\- systemd and uwsgi for example play well when run as a single user per wsgi application under a single nginx/lb.

\- php-fpm already handles a ton of overhead from php apps.

\- ansible deployments called from gitlab-ci can roll out apps just as well as deploying from the registry.

then i figured maybe they were on to something with the autoscaling thing...but that seems like a meaningless feature. Every good project already has metrics and forecasting...it would be absurd to think a final product like imgur.com or twitter does not know (down to the byte) how much storage theyll need in 4 months and the potential drivers.

auto-scaling infrastructure just betrays the fact that most developers throw resources at load problems instead of waiting for ops to figure out the actual issue.

<comment><USER8> I helped build an e-commerce marketplace, which is essentially a shopping cart system that was used by third parties. We had no idea how to predict traffic loads because we had no idea when one of our customers would run a successful campaign. Autoscaling on google appengine was a lifesaver for us. Our very small dev team focused on building features because we had zero devops and we didn't have to carry a pager.

</comment></comment></comment><comment><USER9> This is, like all good HN articles, technically correct and practically incorrect.

It is correct that containers leak, and people know this. Multi-cluster strategies are real, and they shouldn't be. It should be OK to have one big cluster[1]. Until Kubernetes fixes this, there will be some friction to adopt it, based on real use cases like untrusted code and noisy neighbors.

It is incorrect because users (e.g. non-infrastructure engineers) don't know or care about the precise definition of containers and VMs are. The point of "containers" is that I can define something that acts like an operating system from the ground up, and it builds quickly and runs quickly in production.

Kubernetes doesn't win by forcing users to think about VMs. Kubernetes wins by adopting a VM standard that can be built by Dockerfiles. Infra engineers will love it.

But besides them? Nobody will care, because Docker for Mac will look the same.

[1] Maybe 1 cluster per region? There's a whole fascinating topic that starts with the question "when building a PaaS, do you expose region placement to devs?" The answer implies a ton of stuff about what exactly it's reasonable to expect from a PaaS and how much infrastructure your average dev has to know.

<comment><USER10> > It should be OK to have one big cluster

Assuming you're deploying your Kube cluster in the cloud, the costs of having multiple clusters is really reduced. You don't have to allocate physical machines or worry about utilisation as much - you just pick a node size and autoscale.

What that enables is thinking about other concerns when deciding how many clusters and where they are is right for your team.

There are operational reasons why having multiple clusters is a good idea. At the simplest level, making a config change and only risking a portion of the infrastructure is an example.

<comment><USER4> A pattern we're seeing a lot of recently is one cluster per "stage" per region, where a "stage" is something like dev/test, canary, and prod. (In some cases only prod is replicated across multiple regions.) I think this may end up being the "sweet spot" for Kubernetes multi-tenancy architecture. The number of clusters isn't quite at the "Kubesprawl" level (I love that phrase and am absolutely going to steal it) -- you can still treat them as pets. But you get good isolation; you can limit access to the prod clusters to only the small set of folks (and perhaps the CD system) authorized to push code there, you can canary Kubernetes upgrades on the canary cluster(s), etc.

As an aside, something that's useful when thinking about Kubernetes multi- tenancy is to understand the distinction between "control plane" multi-tenancy and "data plane" multi-tenancy. Data plane multi-tenancy is about making it safe to share a node (or network) among multiple untrusting users and/or workloads. Examples of existing features for data plane multi-tenancy are gVisor/Kata, PodSecurityPolicy, and NetworkPolicy. Control plane multi-tenancy is about making it safe to share the cluster control plane among multiple untrusting users and/or workloads. Examples of existing features for control plane multi-tenancy are RBAC, ResourceQuota (particularly quota on number of objects; quota on things like cpu and memory are arguably data plane), and the EventRateLimit admission controller.

There's active work in the Kubernetes community in both of these areas; if you'd like to participate (or lurk), please join the kubernetes-wg-multi- tenancy mailing list: [http://groups.google.com/forum/#!forum/kubernetes-wg- multite...](http://groups.google.com/forum/#!forum/kubernetes-wg-multitenancy)

Also, I gave a talk at KubeCon EU earlier this year that gives a rough overview of Kubernetes multi-tenancy, that might be of interest to some folks: [https://kccnceu18.sched.com/event/Dqvb?iframe=no](https://kccnceu18.sched.com/event/Dqvb?iframe=no) (links to the slides and YouTube video are near the bottom of the page)

Disclosure: I work at Google on Kubernetes and GKE.

<comment><USER10> Your experience mirrors what I've seen.

Many teams use clusters for stages because they work on underlying cluster components and need to ensure they work together and upgrade processes work (e.g. terraform configs comes to mind). Theres no reason to separate accounts because the cluster constructs aren't there for security.

Considering it deeper (I haven't had to think about this for a while), I think multi tenancy would cover almost all of the use cases I've seen except for the platform dev where people use clusters for separation when testing cluster config-as-code changes.

</comment></comment></comment></comment><comment><USER11> "virtual machines" may be the wrong word. Containers is probably still the right word. What we probably want, is actually isolated containers.

And hell, you can nearly get that today. Combining Docker with gVisor is a potential solution to the soft tenancy problem as far as I can tell, and Kubernetes supports using it.

(And gVisor is by no stretch of the imagination a 'VM' \- it is, at best, a tiny hypervisor, and maybe less than that.)

</comment><comment><USER12> Dammit, most of you reading this do not need any of this shit! Build simple things!

<comment><USER13> You don't need them until you're hired by a client with nation-wide deployment requirements, and then you need them.

<comment><USER14> Not necessarily. Needless to say containers and kubernetes are pretty new technologies and nation wide deployment requirement existed before docker / k8s.

Most of the old big companies aren't using docker or k8s for their core services. They're all using legacy fat apps that are load balanced in baremetal or vms.

<comment><USER13> I doubt a home-made solution to load balancing will be seen as _simpler_ , which is what's being argued by the comment I replied to.

The point isn't that you need Kubernetes specifically, it's that requiring a system that scales well is not as uncommon as the OP puts it.

<comment><USER12> k8ts is not the only avenue to building scalable systems -- scaling is mostly about architecture, not how you run your software.

<comment><USER13> > k8ts is not the only avenue to building scalable systems

I had already conceded that. What's your point?

</comment></comment></comment></comment></comment></comment><comment><USER15> I really worry about cost in this future of leaning on something like ACI/Fargate to actually run the containers.

An m5.large instance (2vcpu/8gb) costs $70/mo on-demand ($44/mo with a 1 year reservation). A similar Fargate runtime costs $146/mo.

A b2ms Azure instance (2vcpu/8gb) costs $60/mo on-demand ($39/mo 1 year reservation). Azure Container Instances at a similar provisioning level costs $176/mo by my calculations.

That's not a small difference. That's, like, 3x.

Point being, I love virtual-kublet from the perspective of a scale-up just trying to get a product out the door. But for established companies, I still think the core idea of a container on a VM you control is going to rule. Fortunately Kubernetes allows amazingly easy flexibility to switch, and that's a reason why it might be the most important technology created in recent history.

<comment><USER16> Also, the instance prices are already some crazy multiple of buying a machine, racking it, and running dozens of VM's on it for 5 years.

I don't know the prices for hyperconverged or converged infrastructure off the top of my head, but doubt the amazon rates are even close to competitive unless you're at a tiny scale (or need a ton of tiny presences in different regions).

</comment></comment><comment><USER17> This feels like an infinite russian doll problem, putting k8s inside a bunch of vms I mean.. but I am glad that while everyone is still trying to learn how to properly do k8s these folks are thinking of the next thing

<comment><USER18> And running a Java services in the JVM. It's not real infrastructure unless you have at least four layers of VMs.

</comment></comment><comment> old-gregg Kubernetes has a real chance to succeed where OpenStack failed. Good people at AWS have good reasons to be worried and will push us to a proprietary form of "serverless".

<comment><USER19> OpenStack's failure is that it's an extremely complex system that looks to be nearly impossible to deploy by yourself. You have to use a Distro that does everything for you- their way.

Kubernetes is simple enough to setup yourself. They have well documented tooling, and a solid do it yourself guide. OpenStack has none of that (that I can find). You select RedHat Openstack (RDO) or Canonical OpenStack (MAAS), and you have to use their all-in-one system to have a deployment- and that requires a narrow set of variables which every environment might not have. Which is insane- and will hinder adoption.

EDIT. Not 100% correct, see below comments.

<comment><USER20> You don't have to use a distro. There are well tested puppet modules, which you could make into your own "distro", as well as openstack-ansible and kolla, and openstack-helm which uses helm to deploy openstack. There is also StarlingX. There is no kubeadm like system however, though I'm not sure how many people will really use kubeadm in prod.

Is it complex? Yes. Is it more complex than k8s? Probably. However, are there multiple open source distros outside of RDO (which is not actually a distro and is instead packaging--see tripleo for a distro like solution based on RDO). MaaS is not an OpenStack distro; it's a way to manage baremetal nodes that OpenStack is then deployed onto using other Canonical related tools. That said, selecting a way to deploy and manage openstack is complex, but the same with k8s.

<comment><USER19> True. My only experience is with VMware OpenStack, and my quick googling didn't turn up much info. I think Kubernetes will fall to the same fate as OpenStack is sliding into. Growing complexity with promises of the world. Time will tell.

You seem to know more than I do, so I got to ask. Why does openstack-helm exist? Why would anyone want to deploy OpenStack on top of kubernetes? Is it so you can have the OpenStack API run in Kubernetes that manages physical boxes?

<comment><USER21> One of the issues with Openstack is managing the services required to run it. I imagine that helm could be used to make it easier to run these services in kubernetes.

<comment><USER19> True, but that adds another layer of complexity to an already complex system. If I'm using the ansible module, that's complex enough. Throwing in management of Kubernetes and the additional cruft containers adds- it seems like it's a lot of hassle for little gain.

<comment><USER21> I see this argument relatively frequently. "Why use Kubernetes when I can accomplish X with [puppet|chef|ansible]".

The answer is that k8s offers something fundamentally different and until the person posing the question gets that distinction, the argument is relatively pointless.

I'm not just bowing behind the argument that "you just don't get it... man". Let me point out that you're right. You can manage the openstack control plane perfectly well with your configuration management tool of choice and if you have that process really dialed, then you'll have a difficult time improving upon it with something like k8s.

</comment></comment></comment></comment></comment></comment></comment><comment><USER22> It's still containers. On a cloud provider the Kubernetes workers are VM's which orchestrate containers. With Kata Containers you're just spawning containers inside micro-vm's.

<comment><USER3> > _It 's still containers._

The security profiles of containers and VMs, including kernel-based VMs, are different. VMs still have a significant edge, because the attack surface is smaller and doesn't have many competing missions.

<comment><USER23> The attack surface of a container can be massively reduced with seccomp profiles -- there was a paper a few years ago which found that the effective attack surface of a hypervisor was about the same as the attack surface of a locked-down seccomp profile of a container (and LXC/Docker/etc already have a default whitelist profile which has in practice mitigated something like 90% of kernel 0days).

And let's not forget the recent CPU exploits which found that VMs aren't very separated after all.

The fact that Kubernetes disables this (and other) security features by default should be seen as a flaw in Kubernetes. (Just as some of the flaws of Docker should be seen as Docker flaws not containers-in-general flaws.)

<comment><USER3> > _The attack surface of a container can be massively reduced with seccomp > profiles_

Yes, though as capabilities are added to the kernel, the profiles have to be updated.

That said, VM or no VM, this should be done no matter what.

> _And let 's not forget the recent CPU exploits which found that VMs aren't > very separated after all._

This is a nil-all draw in terms of the respective security postures, though.

</comment></comment></comment></comment><comment><USER24> While the use of namespaces seemed a bit discounted in the article, I think part of the problem is that it's an underutilized and poorly conveyed feature, but maybe that's just me? I'd like to see a better out-of-the-box vanilla K8S user management interface in the dashboard. Maybe the default UX on cluster creation is a user/service account that isn't cluster admin that is limited to 1 or more namespaces. There should be a better dashboard to configure and create users that is front and center when you first create a cluster. You have to work a bit to get something you can use to authenticate as cluster admin like role. This should help direct people towards creating more users and isolated namespaces.

<comment><USER21> My org is using namespaces for tenant isolation. Works quite well.

<comment><USER25> Namespaces++. Unless you're just running one app in a Kubernetes cluster (where default == that app), namespaces solve a plethora of problems.

<comment><USER21> Resource limits, network policy boundaries, etc.

<comment><USER26> That's what we designed them for :)

I do think we've not explored enough of the per namespace policy stuff though - i'd like both podpreset and a reasonably simple scheduling policy (toleration + node selector control to replace the annotation based system) to make it in, as well as a simpler namespace initialization path so you can more easily lock down the contents of a namespace without having to proxy the create namespace API call.

<comment><USER21> By podreset are you referring to something like poddisruptionbudget?

Because it'd be neat to define that on a per namespace basis.

<comment><USER26> PodPreset went alpha with service catalog but hasn't made it out to beta yet. It makes certain forms of injection / rules easier (you must use a standard log dir, you should use the provided HTTP_PROXY vars, etc). [https://kubernetes.io/docs/concepts/workloads/pods/podpreset...](https://kubernetes.io/docs/concepts/workloads/pods/podpreset/)

Being able to limit a user to only being able to edit one pod preset or scheduling policy (via rbac name access) would provide some useful flexibility for splitting control between admin and namespace user.

<comment><USER21> Okay, I get what your point.

I'm still living in the world where operating a platform for the benefit of a set of developers entails building and operating a set of services that abstracts the details of the infrastructure sufficiently that these things don't matter.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER27> I get the multi-tenancy argument, for certain use cases. I'm not sure I understand the point about greater resource utilization. Presumably they mean workloads can be scheduled more densely given a set of hardware resources, vs. containers... but I'd think that containers would score better on that metric than VMs. Can someone expound?

The best part of the piece for me was "kubesprawl," my new favorite word for the week. We've seen it ourselves to some extent, but we are at least aware of it and try to exert some pressure in the other direction. Beyond that I am not particularly bothered by the idea of running lots of clusters for different purposes.

</comment><comment><USER28> I'm picking the eyes out the article here but I had to twitch at this ...

> _Linux containers were not built to be secure isolated sandboxes (like > Solaris Zones or FreeBSD Jails). Instead they're built upon a shared kernel > model ..._

Solaris Zones and BSD Jails both use a shared kernel.

And I'd bet you they were far from perfect in security isolation.

Now it may be true that security wasn't Linux containers prime reason for being but we have an existence proof that they can be made secure enough -- anyone can get a trial Openshift container for the price of a login.

</comment><comment><USER29> _As 2018 comes to a close its time to drag out the hubris and make a bold prediction. The future of Kubernetes is Virtual Machines, not Containers._

I'd say that's less of a prediction than a matter of fact since it's already happened in 2018 for AWS and GCP.

This post is kind of irrelevant for consumers imo, in that the future of Kubernetes is still the container interface, regardless of whether your vendor decides to run it in a container or a VM.

<comment><USER21> How has it already happened? It's true that EKS and GKE nodes are virtual machines, but that's entirely beside the point of this article which seems to make the point that the workloads running inside of Kubernetes will also be virtual machines.

Interesting notion, but I don't see it. The reason for kubesprawl as it is today is a result of the fact that today Kubernetes is hard to tune for disparate workloads which leads most folks to just punt and stand up multiple clusters.

That said, people are starting to figure it out and more tools like the vertical pod autoscaler are coming. Eventually the more efficient choice will be to run disparate workloads across the same set of hardware.

</comment></comment><comment><USER30> The future of Kubernetes (for some interesting use cases), is virtual machines. For the rest of us the virtual kubelet project represents a bridge between Kubernetes and Serverless.

I'd much rather pay my cloud provider to run my k8s workloads (billed by pod requests/limits) than pay for a control plane and three nodes just to run my workloads.

</comment><comment><USER31> The nested kubernetes idea is interesting (linked to from the post). However, amazon and google aren't using nested control planes for their infrastructure. Why is a single control plane good for them, but not for a Kubernetes deployment?

</comment><comment><USER32> And people still wrangle with this... how can it be easier to struggle like this than learn how to use SmartOS and Triton? Kubernetes is a solution to severe OS virtualization deficiency in Linux, most notably orchestration. You, know, the problem which is non-existant in SmartOS with Triton and large scale configuration management with operating system packages. Every so often this hits "Hacker News" and people will rather struggle than master something new. But one cannot polish a turd.

<comment><USER33> At the risk of tarnishing my reputation amongst the hacker news docker/kubernetes hypecycle elite, have an upvote. The I.T. industry in general is funny. New technologies come and go like pop stars. Docker == ke$ha, Kubernetes == ice cube, triton is fred astaire. They all have their off moments. I personally like my platform stable, performant, secure, and boring. If I spent all of my time keeping up on the latest trends on how to spin up machines, I'd have little time to work on actual product. Something good will come out of this influx of cash, marketing, and cloud sales, eventually. Fits and starts. /me goes back to coding and deploying on triton, while patiently watching the docker/kubernetes show.

<comment><USER32> That was a big risk you took. You have guts for standing up to the hype machinery.

<comment><USER33> I'm still fighting the sneaking suspicion that putting kubernetes/etc out to the general public and having such a fast release cycle was just a genius play by the big cloud vendors to acquire customers (who will realize running this stuff on premises isn't as cheap as they thought it was after doing the math (all the math, security, training, operational expenses, personnel training/expenses, moving from docker->moby->rkt->gvisor->firecracker->now vm expenses, blah blah etc)). This current tech wave is kind of disheartening. Everybody is focused on hosting...can we not get icecube to play a show for folks that are pushing the envelope with technology as applied to the medical field, or saving the environment, yo?

Triton on-prem is a snap. Boot the headnode from usb, boot the cluster nodes from usb+pxe, and lets get to kicking ass, fighting the good fight focusing on real groundbreaking applications.

*edit: I'm still a little butt-hurt after kubernetes being rammed down my throat in a large enterprise environment. Apologies to those that are fighting the good fight with kubernetes, I know you're out there, and big high 5 :)

</comment></comment></comment></comment><comment><USER34> I'd be fine with that if they were using LKVM (from kvmtool) or that new Firecracker. But as far as I can tell most projects in this area use QEMU still, which is an outstanding piece of software, but doesn't scream micro-vm to me.

</comment><comment><USER35> I had the impression DevOps ppl would cling to containers as the final form of VMs?

But I'm mostly a high level front-end guy doing back-ends with serverless tech only.

</comment><comment><USER36> I'm convinced that Kubernetes is very good for job security, and not much else. Unless you're a managed services host, you should probably not be running it.

Please, for the love of all that is holy, use a cloud services provider if you need K8s-style service features. If you don't, then just cobble together your infrastructure in the simplest way possible that uses DevOps principles, methods and practices.

<comment><USER37> Could you elaborate a bit?

<comment><USER36> K8s is a very complex system. And the more complex the requirements, the more complex one needs to make K8s through additional software that isn't baked in. Complex systems are costly to run, but more importantly, they're costly to maintain due to the typical level of service required, the number of employees needed to maintain it, and the amount of specialized knowledge required. The system is also under constant maintenance due to its short release cycle. Basically, you need to build an entire cloud services team just to keep it running smoothly. (not for "test labs", but for real production services) And on top of all this, if you're running it on your own hardware, you don't even get the benefit of reduced infrastructure costs.

Because this is not only hard to get right, but very costly, it is much cheaper and easier to pay someone to do all this for you. It is almost guaranteed that doing it yourself will not give you any significant advantage, cost savings, or increased development velocity.

On top of this, most people don't even need k8s. K8s is a containerized microservice mesh network. If you don't need containers and you aren't running microservices, you may be trying to fit a square peg in a round hole. Even if you did need k8s, the benefit may be small if you don't have complex requirements.

Most people can get high-quality, reliable end results with simple, general- purpose solutions using DevOps principles and tools. If you're not Google or Facebook, you probably just need immutable infrastructure-as-code, monitoring, logging, continuous integration/deployment, and maybe autoscaling. You don't need an orchestration framework to deliver all that. And by going with less complex implementations, it will be easier and more cost-effective to maintain.

At the end of the day, if you need k8s, use it. But I really worry about most people who hop on the k8s bandwagon because they see a lot of HN posts about it, or because Google touts it.

</comment></comment></comment><comment><USER38> TLDR: Kubernetes is an anti-pattern.</comment>


An odd job description - <AUTHOR> http://owenge.blogspot.com/2010/04/odd-job-description.html

<comment><USER2> For a small enough company, that's not really very odd.

I've adopted a saying, "Never be too proud to sweep the floor." (if that's needed).</comment>


What happens when you rip off a site but forget to host the JS yourself - <AUTHOR> http://www.dsignio.com.ar/ Some company in Argentina ripped off a friend of mine's site, but didn't even bother to host the JS themselves. So he did this. Original site is http://www.socketstudios.com/ <comment><USER2> Back in the late 90's when Cnet was really big, they embedded a video -- which was hosted on my server -- into one of their articles.

Without asking.

I found out because my hosting company called me and said I was about to get a huge bill. Bandwidth was super expensive back then and there was no YouTube for free video hosting.

I changed the file to a short clip of hardcore porn.

I know it was mean. But it was funny and somewhat satisfying.

<comment><USER3> I assume you had the rights to the porn? :)

<comment><USER4> It was the late 90s. Of course pud did.

</comment></comment></comment><comment><USER5> A little backstory: They stole my site (socketstudios.com) which showed up on my analytics as they for got to remove it. They also left the contolling javascript file on my server. I modified it to load images of dogs that have no idea what they are doing.

<comment><USER6> Tangent: these kind of sites (the site that was stolen from), I'll call them "concept" sites, make me want to throatpunch a baby.

If you are seeking to demonstrate your jQuery/HTML5/CSS3 skillz then do it in a way that has some applicable context. Don't break so far from established usage conventions that users have to invest their the majority of their focus figuring out the site at the expense of examining the content.

After looking at several panels my understanding of what you do is still a guess. But I think you're a designer of some kind. If you are, the problem is that your site told me you care more about cool/flashy/pretty more than ease- of-use/user experience. As someone who engages designers on a weekly basis, that is not a positive differentiator.

<comment><USER5> Thanks for that.

It was a 'concept' site largely for my own amusement (and to teach myself a little bit of js). I do have a private portfolio site that shows more of my work and has no javascript in it at all.

<comment><USER7> Hmm, I kinda like it - and I tend to dislike sites that break conventions... its simple enough that it works really well for me.

<comment><USER8> Would be nice though if contact information and info about the company was easier to get to. It is only available on the initial page or after scrolling through the entire portfolio (at least I couldn't find it anywhere else). At least if the site were designed to draw in business, that would be the case. It definitely is not obvious.

</comment></comment></comment></comment></comment><comment><USER9> What would be interesting is to detect the IP so that whenever the owners access the site, they see it normally, but others see it with the dog images. And put their email so visitors contact them telling them of the "vandalism", but when they access it, the site looks normal.

<comment><USER10> I was thinking exactly this!

The problem with doing something like this is that the site owner will probably take it down within 24 hours.

However... if the site owner cannot see it. Well well well.. could be up for days.

Typically the first person to view the page will be the owner. They want to check everything looks alright. Would be interesting to see the results of something like this.

</comment></comment><comment><USER11> All I see is an "Index of /" page with a link to a folder called videoflow (now changed to 3333). Did the owners take it down?

Does anybody have a screenshot they can share?

<comment><USER12> Yes. There used to be a page with a picture of a dog.

<comment><USER13> Can someone dig up the page from browser cache and put up a screenshot for those who missed it?

</comment></comment></comment><comment><USER14> And what happens when you steal images from cracked - [http://www.cracked.com/blog/this-is-why-you-dont-steal- from-...](http://www.cracked.com/blog/this-is-why-you-dont-steal-from- cracked/)

<comment><USER15> From the comments of that Cracked article:

"We had a similar problem at work, but we figured out the IP of the person doing the direct linking and dished out the images they expected to that IP, but the rest of the world saw an ad for our site."

One to consider for next time?

</comment></comment><comment><USER16> I used to work for a hosting company and one of our customers (a magician of all things) copied our template into his webspace to build his own website - we spotted it and gave him a chance since he was a customer and all. We checked up on him a few months later and he had just done the same thing but to a different hosting provider (while still hosting with us).

Why would a magician need a template that looked like a hosting company?

</comment><comment><USER17> Back in 2006 some guy ripped off my entire front-end for his ticket selling site in Europe and made the same mistake. I found out when going though my analytics. I blogged about it and actually made it to the front page of Digg (a big deal at the time):

"How NOT To Steal A Design": <http://digg.com/news/story/How_NOT_To_Steal_A_Design>

Ah memories :)

<comment><USER18> I was on digg a lot back then and I remember that story!

</comment></comment><comment><USER19> Let's see how long it takes before the offender finds out about this. I'm all for changing the company's description text to tell the full story as well.

Maybe do it in Spanish(?) rather than English.

<comment><USER5> Can't do anything about the text. That's in the HTML which is on their server. I just have the JS file that controls the image loading.

<comment><USER20> But you can do stuff with the text! You can manipulate the DOM, yes? And your script displays it in the first place.

<comment><USER21> Indeed. You can basically change the site to whatever you want.

Changing the text in those boxes should be as simple as adding this to your javascript file.

$('#details .body').html("This guy ripped off my site!")

<comment><USER5> Right enough. Too late now though.

</comment></comment></comment></comment></comment><comment><USER11> I remember I had a website once where I had a little clock widget that I made in flash. I discovered that some of the traffic to my website was coming from myspace and found out that someone had used my widget on their myspace page. I changed the code in my widget to detect which url it was loaded from and if it wasn't on my website, it would simply crash and back then, flash didn't have the 30 second timeout when a script becomes unresponsive, you really had to kill the browser to exit.

<comment><USER22> I had a similar thing once. A company ripped off one of our landing page designs, even down to copyrighted material, and kept one of the little flash widgets in the footer. I showed the boss that I could take advantage of that by whiting out their page or replacing their content with whatever message we wanted.I wanted rather mean-spirited and rude messaging since it would appear to come from them. The way I remember it I was doing this by injecting javascript into the page from the SWF.

The boss never let me do it, he decided to sic the lawyers on them instead.

</comment></comment><comment><USER23> Made me wonder what would happen if some rogue Google engineer decided to replace the CDN hosted jQuery on thousands of sites with script to auto-play a rick-roll.

<comment><USER20> I've always wondered what would happen if a rogue MS employee slipped carefully-hidden malware into Windows Update. They could cause havoc.

<comment><USER24> Wouldn't that be redundant?

<comment><USER25> Thank you for the chuckle.

</comment></comment></comment></comment><comment><USER26> Once upon a time there was a dude that had the bright idea to hotlink the swf mediaplayer that I was hosting. Besides wasting my bandwidth, it also wasted my time for tracking all the referrals where he used the code. Long story short, he got a flash-based XSS in response. For the lulz.

</comment><comment><USER5> Now this guy says he has never seen my site and any similarities are coincidental.

<http://www.nerval.ch/>

I don't believe him but he wasn't stupid enough to leave any JS on my server so I can't do much about it.

<comment><USER27> Ah, I love when you can tell from someone's portfolio that they didn't design their own website. Sorry this keeps happening to you, it's so silly all these copycats come out of the woodwork after your site(s) are profiled on siteinspire/et al, and act like it was a shear coincidence.

</comment></comment><comment><USER28> Did anyone take a screenshot of it?

<comment><USER29> Anyone?

</comment></comment><comment><USER30> For what it's worth, here's all the data (JSON-formatted) about the domain, registrant, delegation, etc.:

api.nicalert.com.ar/domains/dsignio.com.ar

(shameless plug for my Nic.ar API)

</comment><comment><USER31> Reminds me of this:

[http://mike.newsvine.com/_news/2007/03/27/633799-hacking- joh...](http://mike.newsvine.com/_news/2007/03/27/633799-hacking-john-mccain)

</comment><comment><USER32> I would have used a more offensive image, but that's just me.

<comment><USER20> Think of the children.

Seriously. When I was younger I made a little social network thing for me and my schoolfriends. I didn't figure out how to properly deal with uploaded images (too much hassle), so I allowed you to simply hotlink a profile image. I hotlinked some funny picture at home, and...

At school it was pornography from the site owner intended to stop people hotlinking. I very quickly changed the image.

</comment></comment><comment><USER33> Good on them. A little backstory would be great though.

</comment><comment><USER13> All I see on the site now is Index of/ page with a folder named 3333. What did I miss? :(

</comment><comment><USER34> And it's gone. That cheered my day up hugely though, thanks.

</comment><comment><USER19> I think he/she finally figured out what's going on!

</comment><comment><USER35> How does one forget to host their own JS?

<comment><USER19> Copy & Paste any codes without understanding really burn people. Wasn't there a startup that got into trouble for doing the same thing? They later tried to play it off as "A/B" testing. Maybe this guy is A/B testing on how fast he can destroy his reputation by doing Copy & Paste of another site.

<comment><USER36> Yes, Curebit got caught stealing/hotlinking assets from 37Signals.

[http://techcrunch.com/2012/01/28/curebit-apologizes-for- copy...](http://techcrunch.com/2012/01/28/curebit-apologizes-for- copying-37signals/)

</comment></comment></comment><comment><USER37> Ha ha nice one. Justice served :)

</comment><comment><USER38> beautiful site. pretty amazing you did it only 500 lines of js.

<comment><USER5> haha, i'm not sure if that is sarcasm or not. i'm a designer that dabbles in code and that was my first attempt at JS. it works but i'm sure it is probably a disaster.

</comment></comment><comment><USER39> Served this guy right!

</comment><comment><USER40> What crap, just go to a company which does pay well. I'm a coder myself and my startup Fashiolista pays competitively. (Amsterdam though)</comment>


Microsoft launches $114 Lumia 530 with 4-inch display - <AUTHOR> http://thenextweb.com/gadgets/2014/07/23/microsoft-launches-114-lumia-530-4-inch-display-hits-europe-next-month/

<comment><USER2> Say what you will about Windows Phone, they're killing it when it comes to low end devices. Now, yes, there are some pretty awesome Android devices in that price range (looking at you ZTE) however in my view you always FEEL like you're on a cheap low end devices (not least of all because many ship with Android 2.xx still(!)).

Plus these devices are really good for less tech' savvy individuals. As much as I like Android (because of freedom, and choice) for someone like my mom these things not only don't matter but actually can add to the frustration of using the devices. Windows Phone really excels there.

I've been almost tempted just to buy a $100 Windows Phone just to develop on/just for the experience. I don't think I'd wind up migrating to it but at that price it is almost a toy-purchase.</comment>


Judge Rebukes Government, Keeps Gitmo Force-Feeding Hearing Open - <AUTHOR> https://firstlook.org/theintercept/2014/10/02/judge-knocks-government-attempt-keep-gitmo-hearing-secret/

<comment><USER2> Is there even a vaguely legitimate interest in keeping the nature of "cell extractions" and forced feedings secret? How can "the enemy" possibly use this information?

I suppose there's the tired argument used to keep most of the Abu Ghraib photos from the public eye: That even something of no strategic value can be kept secret if telling the truth about it might inflame hostilities somewhere in the world.</comment>


Ask HN: Any API's to broadcast radio?  (the old kind, not Internet radio) - <AUTHOR>

I find the quality of radio when driving around town to be very severely lacking.  I think the general trend of internet radio will continue, but lots of cars won't be equipped to get internet radio for a long time.
So I was wondering: 1. What the rough costs are to get unused air time 2. Would it be possible to create an API or some easy way for people to publish content
The idea would be to let niche radio appear (maybe HN Radio as an example).  Costs (and advertisements) could be drastically reduced by either letter people broadcast from home with a skype headset (crowd sourcing it), or even automating the content with interesting audio books, talks, podcasts, etc.
I'm not sure what the cost would be to just get the air time or where to start thinking about coding up such an API.  Has anyone thought about this? <comment><USER2> I wonder if internet radio in cars will be here sooner than you think though. I already know of MANY people who use their iPhone or Android phone (me included) to stream Pandora or other radio and just output the audio to the car speakers via an FM broadcaster or Aux input jack.

But, in regard to your idea... I wish there was that sort of API. I do listen to normal radio once in a while and would love to hear some indi stuff.

<comment><AUTHOR> Yep that's a good point. Bluetooth radios are gonna be big too. Those FM broadcaster ones an additional piece of hardware which is somewhat annoying, but you're right they work well.</comment></comment>


The Google Loophole Has Become The Facebook/Twitter Loophole - <AUTHOR> http://techcrunch.com/2011/03/17/the-social-loophole/

<comment><USER2> Hmm, how long before there's such a thing as a Hacker News Loophole?</comment>


Windows Task Manager Runs Doom (896 Cores) - <AUTHOR> https://www.youtube.com/watch?v=hSoCmAoIMOU <comment><USER2> What hardware make/model is this?

<comment><USER3> possibly this: [https://www.anandtech.com/show/13522/896-xeon-cores-in- one-p...](https://www.anandtech.com/show/13522/896-xeon-cores-in-one-pc- microsofts-new-x86-datacenter-class-machines-running-windows)</comment></comment>


Study: Some car models consuming around 50% more fuel than official results - <AUTHOR> http://www.transportenvironment.org/press/some-mercedes-bmw-and-peugeot-models-consuming-around-50-more-fuel-official-results-new-study <comment><USER2> If you read the full report, the automaker with _by far_ the largest gap between its claimed improvements in fuel economy and its actual on-the-road performance is General Motors. Much worse than VW and Mercedes (who also did very poorly), by this measure.

A reckoning is coming.

source: see page 13, here

[http://www.transportenvironment.org/sites/te/files/publicati...](http://www.transportenvironment.org/sites/te/files/publications/TE_Mind_the_Gap_2015_FINAL.pdf)

<comment><USER3> The source of the data is actually www.spritmonitor.de, which is a self- reporting mileage tracking site (like www.fuelly.com). With ~501k vehicles tracked and 8.885B kilometers tracked, the site represents ~17k kilometers per car of user-reported mileage information.

Is this the best, or a reliable source, of information to start the reckoning/witch hunt to come? I'm not sure.

<comment><USER4> I thought the same. In my anecdotal experience, drivers tend to get much lower than the manufacturer mileage because they optimize for things other than fuel economy (e.g., speed).

My dad taught me lots of tips on conserving fuel and thankfully I've exceeded the sticker numbers on every car I've owned.

<comment><USER5> No matter how careful I am, it's hard for me to get lower than 130% of the fuel consumption reported by the manufacturer. Perhaps I can do 120% of the reported consumption at 90 km/h, but I can hardly get lower than 140% on the highway (130 km/h) and in city traffic.

<comment><USER6> Are you in an area with much hilly terrain? That'll definitely increase fuel consumption significantly.

<comment><USER7> Actually, it depends. Modern cars do better in rolling hills than on perfectly flat land, since they can cut fuel entirely on the downhill, and the climbs don't require that much extra fuel over just maintaining speed.

Now, mountains are another story, of course.

Some good stuff in this SE question: [http://physics.stackexchange.com/questions/6220/can-a-car- ge...](http://physics.stackexchange.com/questions/6220/can-a-car-get-better- mileage-driving-over-hills)

<comment><USER8> > Modern cars do better in rolling hills than on perfectly flat land, since > they can cut fuel entirely on the downhill

This is physically impossible. Even if the car was perfectly efficient at overcoming the force of gravity on the uphill portions (which it is not), you cannot do better than flat terrain (unless by hilly you mean 'net downhill').

<comment><USER9> I think you should reconsider "physically impossible". Sure, in some idealized situations, the statement you're responding to would be wrong, grievously wrong.

But the actual situation has two novel features: (1) the engine uses up power just by being on; (2) you must maintain a minimum speed in order not to block traffic.

If you put these constraints in, you can see that it's possible for a pulsed- acceleration strategy to win. You put in a pulse of acceleration to get up the hill, turn the engine off, and coast down, maintaining enough speed to keep up with traffic.

Now sure, without the minimum-speed constraint, you'd probably be better off flat, and possibly using a pulsed-acceleration strategy.

I haven't done the math, but I think it would be reckless to say it's "physically impossible" for all values of static energy use and slopes.

Take a look at the stack exchange answer the commenter above linked to.

<comment><USER10> I read years ago that pulsing was the most efficient strategy. Engines have very different efficiencies at different rpms and power settings. The idea with pulsing is to try to operate it at its most efficient rpm and throttle setting, which of course rarely corresponds to the speed over flat ground you'd like to be travelling at. Hence pulsing.

<comment><USER8> I'm getting motion-sick just reading that :)

<comment><USER10> I've been known to do it when gas goes over $4 a gallon, but not when there are cars behind me.

<comment><USER7> Yep, and this is why moderate hills are better. It's essentially constant speed pulse-and-glide. Just building and releasing potential energy rather than kinetic.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> "On average, two-thirds of the claimed gains in CO2 emissions and fuel consumption since 2008 have been delivered through manipulating tests"

How deep does this rabbit hole go :( Here in Ireland the motortax for cars newer than 2008 is based on CO2 emissions, if motorists find their tax rising due to cheating by car manufacturers thats an unexpected and direct cost to their wallets.

<comment><USER12> Or maybe we abolish nonsensical, contrary requirements?

Whoever actaully believed the fuel consumption figures is a fool. You cant have a 1,5t of a car and expect it to use only 5l/100km. That's a good rate for a goddamn motorbike (450ccm,one piston, dont exceed 90 km/h and you might reach 4,5l/100km) Its one fifth of the mass...

<comment><USER13> I actually drove my Golf TDI at around the level of 5l/100km in Berlin for many years. Carefully. My girlfriend's Polo is significantly below that. Of course, these cars aren't ton and a half, but more around a ton.

<comment><USER14> Yup. Diesel cars can pull of 5l/100km quite easily (even VW Passat from 1998 can do that). My diesel Skoda Fabia consumes 4.6l/100km at 90kmh in highway. If conditions are not terrible, I hover around 5l/100km on average in mixed conditions (city and highway). Though few major traffic jams can ruin statistics pretty badly. Also in winter average is about 5.6l/100km.

Maybe /user/emp_zealoth had petrol cars in mind? I've not personally seen a petrol (non hybrid) car consuming less than 7l/100km and when I had one it was 10l/100km (8 if I was lucky) and it was small Peugeot 306.

To rant even more.. IMHO, those fuel consumption tests are a total fraud. Look at new diesel sedans, local dealer declares that huge VW Passat TDI uses 4l/100km, or Skoda Octavia TDI (GreenLine or something) uses 3.1l/100km. Maybe it's true when you're driving at 90km/h with wind blowing in your tail and slight downhill.

<comment><USER12> Yes, i was talking about gasoline ones, diesels can and do get lower fuel consumption

</comment></comment></comment></comment></comment><comment><USER15> The thing is that the cheats (throwing out unnecessary weight, taping door gaps etc, using super hard notrogen inflated tyres, etc.) would add a constant amount to the fuel consumption, say .2 liter per 10km.

If you keep pushing your engine consumption downwards to the ridiculous levels we see now (<.5 liters 10km), what happens is the "drag cheat" actually becomes a large percentage of the consumption.

Just goes to show that the cars should be designed without large door gaps or outside mirrors (cameras instead) and so on, since they seem to add significantly to the consumptions that _that_ is where the effort should be put.

As a consumer, I really don't care much, I just get consumption data from some independent source such as a magazine or website. Having manufacturers self- test and self-regulate reminds me of the financial industry in 2008. It just won't work.

<comment><USER16> The lack of good data is really frustrating. The EPA adjusted the formula for mileage a few years ago which made things slightly better but I never come close to hitting the results in my car. Observed economy is related to personal circumstances, and in my case living at 700 elevation and traveling down close to 0 on a daily basis hurts my scores (along with tire lifetimes, etc). Another thing that bothers me is that performance cars are rated by the same standards, when the people who buy them undoubtedly drive differently than the people buying Toyota Yarises.

Anecdotal reporting online is a joke. You will find endless car forums with people boasting about how they consistently get 25mpg in their V8 sedan. Gimme a break.

What I'd love to see is some service/app that was able to gather real world data from owners of the same type of car in the same area as me along with general stats about their driving style. This would have to be automated to be accurate.

<comment><USER15> Yeah I wouldn't trust some forum user either, but certainly some of the larger magazines that do long real life tests of cars.

</comment></comment></comment><comment><USER17> This is the big next step that a lot of people were expecting - where in-depth studies into all of the competitors occurs and it's gradually revealed that this defeat device game has been played by almost everyone in the industry. It'll be interesting to see the repercussions for the automakers, but inevitably this'll end with sweeping legislation changes and reform of the testing protocol and standards.

<comment><USER18> This is a very good bet. The "defeat device" turns out to be using a feature of the ECU platform provided by the ECU supplier. It would be surprising to find that VW was the only maker to cheat, when the cheating mechanism was available to everyone.

There are some markets, like voting machines, where requiring open, buildable, verifiable code is good practice. Cars might be another.

<comment><USER19> I was thinking of voting machines as well and think publicly verifiable code and hardware would be a good thing for cars (I don't think it's good enough for large scale elections, but that's another topic).

See this story about the need for open source for large publicly used systems: [http://www.nytimes.com/2015/09/23/nyregion/volkswagens- diese...](http://www.nytimes.com/2015/09/23/nyregion/volkswagens-diesel-fraud- makes-critic-of-secret-code-a-prophet.html)

<comment><USER19> ps. just reading this in a post from Bruce Schneier[1] that is currently on the frontpage as well[2] which is about cheating software as used by car manufacturers and the IoT that is coming up:

        Voting machines could appear to work perfectly --
        except during the first Tuesday of November, when it
        undetectably switches a few percent of votes from one
        party's candidates to another's.

[1] [https://www.schneier.com/blog/archives/2015/09/volkswagen_an...](https://www.schneier.com/blog/archives/2015/09/volkswagen_and_.html)

[2] [https://news.ycombinator.com/item?id=10304428](https://news.ycombinator.com/item?id=10304428)

</comment></comment></comment></comment><comment><USER20> This is not good, but it is much different from the NOx cheat because consumers can easily measure MPG themselves, and do. For that matter it's commonly noted in car magazines that U.S. EPA MPG ratings are lower the E.U. ratings for the same car & drivetrain; I'm not sure the 50% number in the OP would be so high relative to U.S. tests.

It also speaks to the responsibility of the auto press for the NOx issue. They routinely report real-world MPG ratings for cars ("in our driving, we got __ MPG"), but haven't bothered to test real-world emissions despite all the other expensive gear they use to test car performance. Manufacturers and governments should be accurate and honest, but it's also the press that should be routinely verifying their accuracy.

Example of skepticism at the "extremely optimistic European cycle":

[http://www.caranddriver.com/reviews/2017-audi-a4-prototype-d...](http://www.caranddriver.com/reviews/2017-audi-a4-prototype- drive-review#eztoc8555383_0_2)

<comment><USER21> Yeah, the European cycle has been known to be a joke for quite some time. The US results are actually quite achievable. Their highway cycle max speed is very low (I think it assumes you don't exceed 55mph), but there's so much slowing and accelerating, even on the highway cycle, that you can easily obtain US highway numbers on an open road if you keep it to say 65 or even 70.

</comment></comment><comment><USER22> _Carmakers, not drivers, are the cause of the problem as obsolete official test results are being manipulated._

Then why does this report compare NEDC numbers with user-submitted real-world consumption? Since car manufacturers have increased power output while keeping NEDC consumption relatively constant, rather than the other way around, you need to drive very carefully to get close to the official numbers. It should be obvious that the more powerful an engine is, the more fuel it _can_ burn in a period of time, _if you go full throttle_. Which is why they find that BMW and Mercedes deviate more than the average. Dear "Transport & Environment", why do you think do people buy fast cars?

This is the ICCT report TFA is based on: [http://www.theicct.org/sites/default/files/publications/ICCT...](http://www.theicct.org/sites/default/files/publications/ICCT_LaboratoryToRoad_2015_Report_English.pdf)

<comment><USER23> Thank you for the link. I was hoping it would include more detail about the cars. For example which engines and do they have start-stop. About the only thing I saw mentioned but not well accounted for was the automatic gearbox difference.

I have a car with 2.5L turbo engine and I can get from 13.5-28MPG from a tank of gas depending on a number of factors, mainly on how I drive, but also what fuel, how loaded-up the car is, and tires. I suspect that automatics with turbo or supercharged engines with start-stop have the greatest difference in real world v test performance. And yes that is because of how people drive compared to the test.

</comment></comment><comment><USER24> More fuel consumption, more CO2. Clear.

But it's not the cheating story of VW, continued - that was about nitrogen oxide pollutants which was up to 40 times above what is allowed in the US.

From the report:

> All carmakers have been exploiting ever more flexibilities in the current > official tests during 2013 and 2014, but detailed results from Spritmonitor > in Germany (Figure 4) show that cars produced by Daimler, PSA and GM exhibit > the largest realworld gaps, around 40%. However, in the past two to three > years all major carmakers (with the possible exception of Fiat) have become > more adept at using flexibilities in the tests such that all carmakers now > have an average gap of 25% or more (as against a maximum gap of only 10% in > 2001).

As I understand "Spritmonitor", as a private person, you can record your fuel data (from your receipt) and your odometer to calculate the mileage you can go with your car. No details about the driving behavior that has an impact on how much CO2 is emitted.

[http://www.spritmonitor.de/en/overview/50-Volkswagen/0-All_m...](http://www.spritmonitor.de/en/overview/50-Volkswagen/0-All_models.html)

I guess that's not the perfect, reliable source - everyone can use the portal and add his favourite car. But for sure, I'll never reach the official 5.7 l/km with my car ...

<comment><USER25> "But for sure, I'll never reach the official 5.7 l/km with my car ..." \--> are you driving a Russian tank? I drive a 10 year old not particularly efficient Vauxhall (UK) and it is doing ~17 km/l!

<comment><USER26> It's not very difficult to assume he means 5.7l / 100km

</comment></comment></comment><comment><USER27> Ok let's be real here, if we put the "pollution" taxes onto fuel and not on the design of the car, this problem, in effect, goes away.

There is still the issue that high efficiency, usually means running the engine at high temperatures which generates far more NOx gases.

We should be taxing the amount of fuel used.

<comment><USER28> That works for CO2, because there is no technology to mitigate CO2 release from combustion. But that isn't the case for particulate matter, carbon monoxide, or nitrogen oxides. You can't put a NOx tax on diesel because the amount of NOx you produce from burning a given quantity of diesel will vary by two orders of magnitude depending on the pollution controls.

<comment><USER23> Just one clarification, CO2 recapture is a thing, for example in coal power plants built after 2014 in US. But yeah for car, really impractical.

</comment></comment></comment><comment><USER29> I think we all should agree that this is the same for _every_ car manufacturer (except electric). Sure, european manufacturers are the target now, but i expect same results from all other manufacturers (including asian and american).

Lab results never represent real street results. How could they? People drive differently and the outcome is based on many aspects that you can't reproduce in lab conditions.

<comment><USER30> > except electric

Why? You have just been shown corporate cheat on tests. Why you would ever assume this has something to do with fuel type? I expect Tesla cheat as much as MB or BMW in their "range" test. And if you believe otherwise you are just someone who doesn't learn from his experience.

<comment><USER31> Tesla's range numbers for the Model S assume about 300Wh/mile average consumption. My average consumption so far over not quite 8,000 miles is 315Wh/mile.

It's hard to cheat in an electric car. Few people care about efficiency directly, but most electric car drivers care deeply about _range_ , and range is just battery capacity multiplied by efficiency. If Tesla were cheating so they could lie about efficiency, Tesla owners would notice pretty much right away that they're not achieving the range they should.

The only practical way for Tesla to cheat would be to ship a larger battery than they say they do, and then fudge the numbers from there. Given the current cost of batteries, this would be an incredibly expensive cheat, and it would be tough to hide from the tinkerers who tear down battery packs to see how they're built.

<comment><USER32> I have definitely found that electric vehicle companies advertise very sound and realistic figures for their mileage.

My personal case is a Zero motorcycle, but I've heard confirmation from owners of other kinds; the range it gets is more or less exactly what they state for the test conditions (straight level ground, no winds, etc etc). Mine did in fact improve when I adjusted the aerodynamics, but that's another topic.

</comment></comment></comment></comment><comment><USER33> I went through to the actual report ([http://www.transportenvironment.org/sites/te/files/publicati...](http://www.transportenvironment.org/sites/te/files/publications/TE_Mind_the_Gap_2015_FINAL.pdf)) and found an infographic (figure 8) that shows some of the methods manufacturers can use to defeat tests.

"Pushing the brake pads fully into the callipers reduces rolling resistance" is apparently one way. That makes me ask the question, why don't we do this already? If it reduces rolling resistance it probably also increases brake-pad life. That'd be a win-win for drivers.

<comment><USER34> In car braking systems the pedal movement from depressed to pressed corresponds to a very small (<1mm) pad movement. The pad is just touching when the brake when the pedal is not pressed, and pressing the pedal forces the pad and caliper together, increasing friction. Depressing the pedal does not withdraw the pad.

With the brake cylinder fully compressed (as they did for the test), it requires several full pumps of the pedal to bring the pad into contact with the disk. This increases braking distance, which is generally considered a bad thing.

<comment><USER35> The travel from a single pedal press is small, but its probably a solvable problem. It just needs a different design.

<comment><USER36> If you make the pedal more sensitive (increase the resulting travel per pedal press) you'll make it harder to apply a precise amount of braking power which doesn't sound like a nice feature. I suppose you could have a more clever system that would move the brake faster until it touches the disc and then behave normally but I suppose that for such a critical system constructors and regulators are very conservative.

There could also be beneficial side effects to having the pad in contact with the disc at all times, such as preventing water/fluids/dirt to coat it. I'm just guessing here.

<comment><USER34> > If you make the pedal more sensitive (increase the resulting travel per > pedal press) you'll make it harder to apply a precise amount of braking > power which doesn't sound like a nice feature.

If you've tried hopping in a car from the past few years after driving a much older car you (and you passengers) will have probably noticed this! It's very common in modern cars to have much shorter brake pedal travel, so what would bring you to a gentle stop in an older car will be somewhat more abrupt in a modern car.

This is achieved by having a shorter travel pedal, which is then heavily assisted by the brake servos so it is not horribly heavy to apply. This is nominally for safety's sake, as it reduces the time between seeing a obstacle and the brakes being fully applied. And since all recent cars have anti-lock braking and stability systems it doesn't matter so much if the driver can't control the braking pressure quite as precisely.

> I suppose you could have a more clever system that would move the brake > faster until it touches the disc and then behave normally but I suppose that > for such a critical system constructors and regulators are very > conservative.

Exactly, as I mentioned to the other commenter, it's preferable to have a simple, non powered mechanical system in place to stop the car in the event of bad things happening. Adding extra bits to this system, with the vast R+D cost involved, for marginal increases in fuel economy would be hard to justify for most car manufacturers (especially since the fuel economy saving would benefit the users pockets, not theirs).

</comment></comment></comment></comment></comment><comment><USER37> Wait a second..

When I bought my car (10 years ago) and read reviews, a lot of them say here's what the epa said you'd get for mileage, and heres what we actually got. There is always a difference (maybe 10%). But if it claims 30 mpg and you are getting 17 , I like to think more than few people might notice.

Part of the reason VW was accused of cheating on emissions was it helped mileage.

edit: as pointed out, its 50% more fuel... But still a noticeable difference..

<comment><USER38> 50% more fuel than official results would be like claims 30 mpg and actually getting 22.5 mpg.

<comment><USER31> Consuming 50% more fuel than 30MPG is 20MPG, not 22.5MPG: 30 miles divided by 1.5 gallons equals 20 miles/gallon.

<comment><USER38> True. I was thinking 100% more would be 15 MPG so 50% more would be 22.5. Thanks for the correction.

<comment><USER31> Makes sense, I was wondering where that number came from. Of course it all goes nonlinear when you take the reciprocal.

</comment></comment></comment></comment></comment><comment><USER39> So how many of these cars have turbos? I know the BMWs at least are mostly turbo 4-cylinders.

The whole reason manufacturers are moving to small displacement turbocharged engines over large displacement naturally aspirated engines is because the EPA MPG tests never run the engine in a range where the turbo is doing much. Put the car in the real world and the driver's lead foot makes the turbo kick in, killing fuel economy.

Ref: [http://autoweek.com/article/car-news/mpg-or-performance- its-...](http://autoweek.com/article/car-news/mpg-or-performance-its-trade- turbos)

<comment><USER40> Yes. Turbos are being added to everything, killing the NA engine. The reason is to create a smaller displacement motor which still has the power that drivers expect.

Turbo engines can consume vast amounts of fuel when opened up to full throttle. Modern turbo engines are also very easily remapped for extra power (and consumption) just by changing the boost control.

All the added complexity and cost just to match emissions requirements, which are all negated when the driver 'puts the boot in'.

Turbos are the ultimate cheat device.

</comment></comment><comment><USER41> Strange, I tried posting this link onto Facebook, and received the following message:

[http://imgur.com/c49k2py](http://imgur.com/c49k2py)

What's up with that?

</comment><comment><USER42> I think it is a bit unfair to just blame the manufacturers. The legislation could likely be changed to make for a more robust test approach. After all, it is engineers we are talking about here, if they are given a task to optimize an engine's emissions and fuel consumption to a specific drive cycle they will do it. But then of course you have the ethical aspects which I won't go into.

A computer science analogy to this would be if I gave you an uncompressed image and you had to develop a compression algorithm that made the image as small as possible, you could likely come up with a really good solution. But your algorithm most likely wouldn't do as well on any other image.

I think that a feasible solution to this will be to test under a wider range of conditions and add (statistically defined) noise to the testing procedures. The added cost of additional testing would be very small in comparison to the cost of a vehicle development program.

A good overview of the different drive cycles can be found here: [http://www.car-engineer.com/the-different-driving-cycles/](http://www.car- engineer.com/the-different-driving-cycles/)

<comment><USER43> "A computer science analogy to this would be if I gave you an uncompressed image and you had to develop a compression algorithm that made the image as small as possible, you could likely come up with a really good solution. But your algorithm most likely wouldn't do as well on any other image."

That analogy doesn't hold. It's more akin to developing two compression algorithms, one for the general case, and a specific algorithm which is used _only_ when your image is detected for better than the general compression performance use case.

It is entirely fair to blame the manufacturers for this. Gaming emissions results required effort to accomplish, and is completely unethical from an engineering standpoint.

<comment><USER42> I agree that the analogy doesn't hold for the recent VW debacle (where the calibration was changed during certification testing), but it holds for the industry in large and what has been going on for the past 10-20 years, which is what the paper is about.

The vehicle manufacturers optimize the engine calibration to the drive cycle they are trying to beat. That is why a US-spec BMW has a different engine tune than a Euro-spec BMW for example, the drive cycles are different.

</comment></comment></comment><comment><USER44> Dyson claim that German vacuum cleaner manufacturers are 'cheating' the energy efficiency rules similarly: [http://www.telegraph.co.uk/motoring/car- manufacturers/volksw...](http://www.telegraph.co.uk/motoring/car- manufacturers/volkswagen/11901325/My-advice-to-Germany-scrap-rules-for-real- Vorsprung-durch-Technik.html)

</comment><comment><USER45> So, does that mean that all those armchair discussions about the merits of ICE and electric cars with "official" mileage numbers thrown about are completely invalid?

A 50% increase in fuel completely changes the cost proposition.

<comment><USER46> I'm not so sure. Especially for high-end cars, lifetime fuel costs are dwarfed by the car cost. Even in low-end high-mileage cars, both numbers are smaller but the car cost is still probably double the lifetime fuel cost. So maybe across the board we can expect fuel not to be a driving variable in the cost proposition?

</comment></comment><comment><USER47> I guess "teaching for the test" applies to car manufacturing as well...

</comment><comment><USER48> This is totally anecdotal, but relevant. I installed the automatic.com car monitoring app/dongle to see how my last car (2013 ford escape ecoboost 2.0L) was performing vs the advertised rates. I drove consistently at a 95-97 score rating for efficiency, and never averaged over 16mpg despite the car being advertised as 23mpg city. Highway driving was different (i got 29.5mpg vs 31mpg advertised). I questioned ford about this and they blamed my city driving on "short trips where the car didn't heat up enough to be efficient". Either way, I was not pleased. My current car (Lexus NX200T 2015) gets 21mpg city 29 hwy within 1-2mpg of what was advertised. My driving patterns haven't changed.

</comment><comment><USER49> "Miles Per Gallon" is poor metric for reducing consumption.

"Gallons Per Year" would be much better.

Move closer to work, carpool, take public transport, ride a bike, work remotely. Benefits from these things would dwarf any incremental improvements from EPA ratings.

</comment><comment><USER50> The problem with the environmental problems (currently with VW) and the fuel consumption is, that particularly in the EU, the governments for years (if not decades) turned a totally blind eye on the car manufacturers.

The problems with the emission measuring and also fuel measuring was known for long now and in the EU, many wanted to change the measuring methods -- but for example the German government did always block such advances.

In my opinion, not only the car manufactures are guilty, but even more the politicians that made it very easy for them to cheat on us all. The additional expenses (at the gas station and with the bad air) carry the consumers.

VW is only the tip of the iceberg.

</comment><comment><USER51> So, any Japanese or American companies doing this as well? Who's next?

<comment><USER52> For now the answer is inconclusive, but let's wait and see what tricks the gasoline models are playing.

The Chevy Cruze Diesel was as clean as promised in the US version but the European version may not be as clean[1].

[http://www.thetruthaboutcars.com/2015/09/tech-dive-chevy- cru...](http://www.thetruthaboutcars.com/2015/09/tech-dive-chevy-cruze-stays- clean/)

<comment><USER18> The US Cruze diesel uses urea injection. That works. The cheats seems to be trying to do without that.

</comment></comment></comment><comment><USER53> Here is one. My Porsche has a display which tells you the MPG. However the car display is consistently between 1 and 2 mpg better than what I calculate after filling the tank and doing the math. And I repeat it's consistently worse than the display which calculates the mgp per tankful which is probably what most people rely on. I've been meaning to bring this up with the dealer but haven't so far. This is in addition to not coming anywhere near to the stated MPG and with conservative driving (non sport mode ..)

<comment><USER21> Yeah, mileage computers in cars are known for being a bit optimistic. It's not hard to beat the EPA highway number for your car. Put it on the highway, cruise at 65mph, done. The EPA test cycle doesn't even exceed 55mph, but it has quite a bit of slowing and speeding up, so you can beat it with a consistent cruise a good bit over their 55mph number.

<comment><USER54> A partial reason for this is that the speedometers have to be optimistic by law (depending on jurisdiction, but I think this is the case most everywhere.

When your speedometer shows 100 km/h, it is permitted that true speed is 90 km/h, but it is not permitted that the true speed is 101 km/h. And the same variance applies to odometer, of course.

Things like tyre wear and pressure have a noticeable impact on what both meters show, and manufactures have to stay on the safe side, by law.

<comment><USER21> This is true -- my understanding is that Germany actually requires they never read low EVEN IF FITTED WITH THE WRONG SIZE TIRES which is sort of insane.

That said, I believe the odometers are typically bang on, which would mean the mileage calculation _should_ be accurate. Or could be, if they wanted it to be.

</comment></comment></comment></comment><comment><USER55> I wonder to what degree this is due to Europe's use, as I understand it, of an absurdly optimistic testing procedure (NEDC) which does not reflect real-world driving patterns.

[https://en.wikipedia.org/wiki/New_European_Driving_Cycle](https://en.wikipedia.org/wiki/New_European_Driving_Cycle)

[http://www.car-engineer.com/the-different-driving-cycles/](http://www.car- engineer.com/the-different-driving-cycles/)

</comment><comment><USER56> I never pay attention to fuel consumption figures as they have never represented reality in my case. My current Mercedes has an official rating of 40mpg, but I never get that out of it unless I literally sit at 55mph on a flat motorway and never change speed (impossible in the UK). Some journeys I go as low as 19mpg when it's driven as it's meant to be. All the Vauxhalls I had before were the same.

<comment><USER57> As it's meant to be? How is that? 40 to 19 is a huge gap.

Do you engage the throttle and brakes more than necessary?

</comment></comment><comment><USER58> Which auto makers if any has the closest emissions to their lab results? Honda? Subaru?

</comment><comment><USER59> Reminds of the cycling world. Boundaries are pushed with doping and in order to stay competitive, after a while everyone is doping until the whole thing collapses.

The same thing goes for bodybuilding, anyone has another example?

<comment><USER60> Capitalism.

One of the Marxist critiques of capitalism is that if an employer wants to do certain good things (like treat his workers well, pay more salaries than the bare minimum, take care of the environment and so on) he can't do that because that will raise the price of whatever he is selling and he would be outcompeted by his less altruistic rivals and go bankrupt. So every business owner has to be a bit of a psychopath to survive.

<comment><USER61> Cliffbar lavishes perks on their employees and they seem to get by selling commodity food products. The problem is when the people at the top take everything for themselves and leave nothing behind. Issuing public stock induces the worst of this sort of behavior due to the need to market the company to investors on the single line item of profitability.

</comment></comment></comment><comment><USER62> I monitor my mileage by simply resetting my trip meter on a fillup and looking at how much went into the car and dividing. The largest source of error naturally is that not all pumps are gaurenteed to fill to the same hieght and some places may be on a hill etc.

Obviously this is only as good as the way I drive (or my wife) and is heavily dependent upon if I hit traffic, mostly drive in the city or go on a road trip.

It really is an interesting thing to keep track of.

</comment><comment><USER63> One problem with the report is that real-world driving styles might be linked to the type of car. So, small cars might perhaps be more likely used for short commutes, whereas larger cars could tend to have longer motorway journeys. One driving style is likely to be closer to the standard tests than the other. So, even if one car seems to perform worse, it could just be because of the average driving of that car.

<comment><USER64> That's a problem with a test, not a problem with the report.

<comment><USER63> No. The emissions test has to pick a certain kind of driving style. It can't emulate them all.

The report, on the other hand, could try to compare like-for-like. For example, they could give separate results for high-mileage drivers and low- mileage drivers. Or split the results by average speed, to try and isolate long-distance motorway drivers from short commutes.

</comment></comment></comment><comment><USER65> It's worth mentioning on the other hand that -- based on my experience -- the VW Diesels currently being recalled for cheating their NOx tests consume significantly less fuel than they are rated to.

My 2009 Jetta was rated at 29 city, 33 combined and 40 highway . Based on my fuel records, I got 33 city, 36-38 combined and 50 highway.

That means it out-performed the EPA estimates by 25% highway, 12% combined and 14% city.

</comment><comment><USER66> It's not really news though, is it ? All car magazines measure real consumption and show how it is much higher than the official figure.

<comment><USER67> well it really depends on how you drive as well. I have had only one car in the last twenty or so years where I could not consistently beat the EPA ratings. Plus throw in that most ares have ethanol formulations and that will lower your mileage.

Far too many race from light to light, keep on the gas even when going downhill and over the limit, brake late and even run with tires under inflated.

anecdotal, my current car a s28 Z4 uses a four cylinder turbo. 23/34 I think are the official ratings, I have yet to average a tank under 30 and did 40 on pure highway at speeds over 70. Granted its a manual which lets me abuse the rev range a bit more than the 8 speed auto offered but its simply down to learning to drive your car within its best performance parameters. I still have fun, run it up fast, but mostly just drive relaxed.

Does it mean that some cars are not performing to what companies claim. I am quite sure they aren't. I could not get a 2013 Mustang V6 above its EPA AVG to save my life.

</comment></comment><comment><USER68> Please change the title to

"Mercedes, BMW and Peugeot models emit 50% more CO2, new study reveals"

The report does not provide the data about fuel consumption.

</comment><comment><USER69> The conclusions in the article are bullshit. There are a number of possible explanations.

1\. offical does not reflect real world. 2\. defeat devices.

If every car manufacturer is using defeat devices it really shows how poorly EPA requirements have worked. Blame car manufacturers, sure, but they're _supposed to be_ selfish. That's how economics works.

</comment><comment><USER70> Didn't I read somewhere or maybe it was John Oliver on Last Week Tonight that corporations in the USA report their own MPG to the government on an "honor system" because congress won't fund proper testing by the government.

So much for government protecting the people from corporations and their sole quest for profit.

<comment><USER21> They do, but the EPA also spot tests cars, and the system works pretty well. They recently fined Hyundai for not matching their quoted numbers. The EPA test cycle is not particularly representative of real-world driving, but it's far better than the European tests are, which easily allow you to game the system. Seems like the system works quite well here in the US, even if you might quibble with their idea of a city and highway drive cycle.

</comment></comment><comment><USER71> It's called "real world driving". Look, this is no different from Tesla claiming a 280 miles range that nobody can achieve. Not saying it is right. What I am saying is: We need better tests.

<comment><USER31> It's not actually very hard to achieve rated range in a Tesla. You might need to refrain from flooring it at every opportunity and you might want to cut down from going 10MPH over the speed limit, but it's not a challenge.

<comment><USER71> I think you missed my point: real world driving.

No vehicle meets manufacturer specifications in this regard, electric or IC.

To be clear, I am not saying this as a negative. I am simply stating it as a fact.

<comment><USER31> You missed _my_ point, which is that it's easy to achieve rated range in a Tesla with real-world driving.

I have not taken care _at all_ to drive my Model S in an efficient manner, and I still have an average of 315Wh/mile over about 8,000 miles of driving so far, where 300Wh/mile is rated efficiency.

<comment><USER71> The bit if data you are leaving out is the nature of the terrain and traffic you experience. I am not disputing your numbers at all, I am simply saying more data is needed in order to fully evaluate it.

Beyond that, the truth is you cannot get the rated range because that would mean draining the batteries to zero. Real range anxiety, depending on where you drive, starts to come in somewhere below 50 miles from fully drained.

You also have a difference in performance between summer and winter driving. If you have a short daily commute, the combination of the "off" state drain on the battery overnight and the car warming or cooling the battery pack while parked in cold or hot weather can have an impact on available range and performance.

BTW, I am NOT saying any of this is bad. I am simply saying these are realities of the contrast between advertised specifications and performance under real life conditions.

<comment><USER31> That's fair. I think we can say there are two kinds of "do you achieve these numbers in the real world?" One being whether you can do so without completely artificial conditions, and one being whether you _always_ get the given numbers. It seems we're just talking about different ones there.

</comment></comment></comment></comment></comment></comment><comment><USER72> How is that possible with the current gas prices ? I can't even comprehend that. I would have thought gas mileage would have been a very important issue so that entire countries can save money.

</comment><comment><USER73> I have one of those cars and it actually gets more mpg than what the sticker says, not sure how it would be possible to be 50% off from that, people would figure that out pretty quickly.

</comment><comment><USER74> Why "some" was removed from the title?

</comment><comment><USER75> Remember when Toyotas (made by a Japanese company) in the US were killing people on their own and no one could replicate it?

</comment><comment><USER76> Facebook is reporting a link on that site as somehow malicious....

</comment><comment><USER77> That's a lot of bad news in a row for fuel based vehicles.

</comment><comment><USER78> i have a 2010 4runner and it was sold as 22mph, i get 16.5. i mean i knew those numbers were bad, but thats quite a bit off, if you ask me.

</comment><comment><USER79> this is bullshit. a planed smear campaign against german car manufactures. can we see some charts for american cars please!

</comment><comment><USER80> that was expected.

</comment><comment><USER81> could we expect a major recall? 10+ million cars would be disastrous.

</comment><comment><USER82> Sounds like there are plenty of worms in this particular can waiting to come out.

</comment><comment><USER83> This is Chernobyl for automotive, Elon Musk wet dream and the chance to make electric cars appealing to the general public at last. Great uncle Charles Darwin having a good laugh too, evolutionism at its best.</comment>