smarterclayton

11 ms·

61.
by smarterclayton 6y ago
Kubernetes had a non-public prototype in Java. None of the code in the main tree even resembles the code from that prototype (I was one of the first non-googlers to contribute). It’s just ugly because that’s how it evolved after a community
62.
by smarterclayton 6y ago
Kubernetes has lots of workarounds - I’m not sure generics are the ones I’ve worried about the most. If I had to write a list of “tools I would have preferred to have”: 1. Perfect serialization libraries - Serde is the gold standard here, a
63.
by smarterclayton 6y ago
The difference is that Kubernetes isn’t a data store - we’d have to implement the full functionality of etcd. Kafka is a full featured data store that doesn’t need 80% of what zookeeper does. This was actually an early complaint leveled ag
64.
by smarterclayton 7y ago
A lot of extensions ask for “read all secrets” which is effectively root on the cluster - especially ingress controllers - because service account tokens for controllers are in secrets. Once we turn off service account tokens (they will he
65.
by smarterclayton 7y ago
Airgapped is now available in 4.3 (although it has some rough edges that will be addressed in 4.4).
66.
by smarterclayton 7y ago
Still trying to land the remaining changes to 4.4. It’s working, just a lot of workarounds still waiting to be replaced with real changes. It has definitely taken longer than anticipated to line up all of the impact from Fedora CoreOS clea
67.
by smarterclayton 7y ago
Kubernetes was never publicly available (open source) in any other language than Go. Early internal prototypes may have been in Java, but those bear no more resemblance to current Kubernetes than Borg does.
68.
by smarterclayton 7y ago
Good question. I certainly use the “name” and “name.namespace.svc” forms extensively for both “apps in a single namespace” and “apps generic to a cluster”. I know a small percentage of clusters makes their service networks public with dns r
69.
by smarterclayton 7y ago
Coming very soon - hopefully ready for KubeCon
70.
by smarterclayton 7y ago
We needed fedora coreos. OpenShift used RHEL CoreOS. It took longer for fedora coreos because we also wanted fedora coreos to be a sufficient replacement for ContainerLinux. That integration started passing CI with openshift today. Readm
71.
by smarterclayton 7y ago
Yeah, Tim Hockin and I still regret not designing the DNS name search process in Kube better. If we had, we would have avoided the need for 5 and could have kept 90% of the usability win of “name.namespace.svc” and “name” being resolvable
72.
by smarterclayton 7y ago
A lot of early web apps heavily abused this pattern - I worked on a web framework that used iframes to manage widget state, and of course at that time everyone had to support IE5 and 6. But those browsers by default had this charming noise
73.
by smarterclayton 7y ago
Although an ingress operator could be even higher level and ensure one or more ingress controllers were actually deployed (if you had an IngressController resource that made it easy to deploy them)
74.
by smarterclayton 7y ago
Controller is usually reserved as the implementation that satisfies an API, regardless of what it does. Operators hide operational complexity via judicious use of APIs - if using it in the broadest sense the ingress API + a particular contr
75.
by smarterclayton 7y ago
Fedora CoreOS is intended to eventually provide a suitable replacement for ContainerLinux. Red Hat ships a variant of RHEL called RHEL CoreOS, but the only way to run it is as part of OpenShift (for instance via https://try.opens
76.
by smarterclayton 7y ago
For Kubernetes in general this has been my experience over the last 5 years (and the year preceding on Docker and other "learning Go" projects). For web style apps with moderate to heavy client complexity (Kube APIs, client librar
77.
by smarterclayton 7y ago
My experience in the Golang side of this is limited to profiling and optimizing Kubernetes, which doesn't have extensive use of interfaces in general, but over the last 5 years I would say 90% of the wins we have have been: 1. optimizi
78.
by smarterclayton 7y ago
This is a joke talk (hyperbolic) Most of the codebase problems in Kube are: 1. we depended on half the Go ecosystem at one point (docker, grpc, etcd, a few others) which is hard to do with dependencies in go (few standardized libraries) 2.
79.
by smarterclayton 7y ago
Kubernetes (from open sourcing to about 1.3 or 1.4) is a second system mostly written by senior engineers (from several companies) with deep experience in the problem domain and strong architectural guidance, and a willingness to stop at “j
80.
by smarterclayton 7y ago
As some of the other comments have mentioned, kubernetes is “multitenant capable”, but the questions come down to: 1. Do you understand all the primitives and how they interact 2. Do your use cases require some or all of these primitives be
81.
by smarterclayton 7y ago
As someone who works on Kubernetes in the enterprise I would agree - there’s lots of go, but it’s newer and organized around the teams who were early adopters. And even the early adopters have massive Java, .NET, and increasingly Node foot
82.
by smarterclayton 8y ago
Yeah, OpenShift did this from the very first version. It worked pretty well. Memory use was very reasonable from etcd 3.0 on.
83.
by smarterclayton 8y ago
For kubernetes unless you’re past a couple of million keys it’s unlikely etcd is the issue, and other things would fall over first. However, if you’re at those levels it might be worth it to use something else. I’m not sure foundation woul
84.
by smarterclayton 8y ago
Because we prioritized stabilizing the core and having something shipped. Pod safety guarantees were part of 1.0 and ensure “at-most-one” pod with a given name at a given time on any node, which allows us to build a compute model that can b
85.
by smarterclayton 8y ago
StatefulSets are PetSets. We renamed them. The core API designed hasn’t materially changed since the alpha.
86.
by smarterclayton 8y ago
As someone who designed kubernetes, I completely disagree. We designed it to run stateful workloads. From V1 we set very strong safety guarantees around how pods work and are scheduled. However, like any software infrastructure, you are
87.
by smarterclayton 8y ago
Arguably all kube is just a pattern library, and the patterns fit reasonably well together. But patterns are situational - you’re always going to have to fill the 20% oc uncovered space with something unique to your use case. Operators are
88.
by smarterclayton 8y ago
What are some of the design by committee cracks that you think should be addressed?
89.
by smarterclayton 8y ago
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://
90.
by smarterclayton 8y ago
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 annotat

More ›