thockingoog

9 ms·

31.
by thockingoog 8y ago
This is explicitly part of the process of transferring each property. We need to be able to produce reports on spend in each area, and those reports are property of CNCF, not Google.
32.
by thockingoog 8y ago
Well, the headline is pretty awful. It's kind of personally offensive to see what is really, truly a well-intentioned act get spun in nasty ways. Besides that, 2 people does not an army make...
33.
by thockingoog 8y ago
We gave this project to CNCF years ago, and Google is still pretty heavily invested in Kubernetes. :) This is the end of the last vestige of exclusive control.
34.
by thockingoog 8y ago
Run 5000 VMs more or less continuously. Spin up/down hundreds of kube clusters every day - on every GitHub Pull Request. Serve 9-digits worth of container images per month. To name a few. The infra behind k8s is kind of staggering.
35.
by thockingoog 8y ago
That's hyperbolic. Part of the announcement is a commitment to re-evaluate the numbers as time goes on. Google is in No Way stepping back from this.
36.
by thockingoog 8y ago
Disclosure: I worked on this grant. TL;DR is that CNCF owns kubernetes, but until now I could not include non-Google people in the administration of (ostensibly) community owned stuff (google.com security policies in GCP). Now I can. Googl
37.
by thockingoog 8y ago
Kubeadm and others help install, but they don't manage clusters over time. We find that the ongoing management of GKE is what really speaks to people. The workloads will still be as portable as ever, of course.
38.
by thockingoog 8y ago
Perhaps not surprisingly, this is where Istio excels..
39.
by thockingoog 8y ago
I feel like I have to say this, even if people get it already. Walk before you run. Bare metal is a LOT harder to manage because, well, hardware fails. We hear the demand, for sure, but vSphere represents walking (and has a lot of customer
40.
by thockingoog 8y ago
The mechanism will probably support it. Whether that is "supported" or not I think is TBD. :)
41.
by thockingoog 8y ago
Deploying containers is shell-script-easy as long as nothing goes wrong. Ever. I know you know this. I'm a little confused why you'd make a claim like this.
42.
by thockingoog 8y ago
I serve a couple small websites from a very very small GKE cluster that costs well under $100/month. I don't worry about OS updates or Kubernetes upgrades. I don't worry about it going down. I don't think my needs are
43.
by thockingoog 9y ago
...and as of today there is no fee for masters on GKE. https://cloudplatform.googleblog.com/2017/11/Cutting-Cluster...
44.
by thockingoog 9y ago
First, Ingress had a purpose to serve, and it has served that purpose - it is relatively easy to handle low-complexity apps with generic Ingress. But low-complexity apps don't stay that way. What you're describing is very much the
45.
by thockingoog 9y ago
Google and GKE team member here: The AKS announcement was either poorly worded or intentionally vague. I choose to grant the benefit of the doubt. For small clusters (less than 1-5 nodes) GKE does not currently charge anything "extra&q
46.
by thockingoog 9y ago
The problem with Ingress "lagging" is that it was designed to be a lowest-common-denominator API - it only absorbs logic that exists in the majority of realistic implementations. For better or worse, cloud LBs are vastly more lim
47.
by thockingoog 9y ago
Are people happy with a built-in L7LB? I find most people are very particular about which LB they use.
48.
by thockingoog 9y ago
The link you posted highlights my exact concern with Swarm. If I use port 8080, then nobody else can use port 8080. That is a different tradeoff than Kubernetes is willing to make. Functionally, we have this in NodePort, but because i
49.
by thockingoog 9y ago
> Docker Swarm secrets have been GA for longer thank k8s I don't think that's true. Kube secrets were introduced 2015-02-17 and was considered GA in Kubernetes v1.0 > I think the pluggability of critical pieces like ingress
50.
by thockingoog 9y ago
This is an apt point. Kubernetes models Borg, and Borg has no concept of ingress. That's an entirely different problem space. Obviously that doesn't fly if there isn't an equivalent open solution, so we did what we could wi
51.
by thockingoog 9y ago
I hear what you're saying, but don't under-estimate the value of "someone else runs it and gives me an SLA", which is a large part of what public clouds are really selling. :)
52.
by thockingoog 9y ago
A great many of those (but not all, I admit) have equivalents on Google Cloud. I know I am somewhat biased (as I work there) but the technology is really great. BigQuery is untouchable. Spanner is magical. CloudML is hands-down the best
53.
by thockingoog 9y ago
I don;t think that is really what happened. :) As part of the runtime abstraction, kubernetes must necessarily decide how to handle stdout/stderr logs. Not having a decision for something at a given point in time is not exactly a bad
54.
by thockingoog 9y ago
Please remember that Kubernetes itself is literally less than 2 years GA. Stateful is hard. It wasn't the first thing we tackled. It's in progress now, and feedback so far is pretty good. That may not be enough for you yet, and
55.
by thockingoog 9y ago
Hey man, I get that you need something NOW and I am sorry about that, but I have to say this is a teeeeensy bit over the top. Yeah, StatefulSet is still beta. We're getting miles on it before we tell people that we 100% back it. But
56.
by thockingoog 10y ago
Is your jenkins code public?
57.
by thockingoog 10y ago
> come back to Kubernetes once its release cycle is a bit saner for production environments Out of curiosity, what sort of cadence would you like to see?
58.
by thockingoog 10y ago
ACK. We recognize this aspect of the docs (engineers writing docs == encyclopedia articles). We have real, honest to goodness tech writers now, and they are working on it. One piece at a time.
59.
by thockingoog 10y ago
I think Solomon has hit the nail on the head here, but I'll call it out even more starkly. Assuming containerd is successful, and that higher-order systems like Kubernetes and Mesos use containerd directly, we will see one of two thing
60.
by thockingoog 10y ago
THAT is true. Kubernetes on its own is not a product, per se. There is no one company behind it. No legally binding support contract. etc. It is the basis for many products (plural) and an ecosystem, which is really what we wanted to ac

More ›