smarterclayton

13 ms·

91.
by smarterclayton 8y ago
I’m not sure who at Red Hat is advocating one cluster to rule them all, but it’s just one point on the spectrum. There are lots of places where one cluster makes sense and two would be overkill - if you want to run lots of simple workloads
92.
by smarterclayton 8y ago
It’s not only about trusting containers. It’s also what data that cluster has access to (anything on a PV attached to a cluster is readable and writable by someone with privileges). The control plane can program the infra to some degree (
93.
by smarterclayton 8y ago
Any specific areas for Kubernetes to focus on?
94.
by smarterclayton 8y ago
Yeah, most Red Hatters in this space work on CRI-O, or Kubernetes, or runc, or KubeVirt, or the pieces on or around Kata from a VM side. There’s a lot of other things that need investment.
95.
by smarterclayton 8y ago
Pre 3.5.0 zookeeper reconfiguration of a running cluster was also much harder - that was a significant discussion point on Kubernetes when we had the etcd vs (anything) discussions early after open sourcing. I still think etcd total orderin
96.
by smarterclayton 8y ago
We do use it but mostly in middleware. However, the reason we don’t use that more is partially because of the viral nature of context - it came late in kube lifecycle, so we didn’t ensure it everywhere and now it’s a lot harder to wire (cli
97.
by smarterclayton 8y ago
It’s still in NEW - don’t see any chatter yet
98.
by smarterclayton 8y ago
A lot of large clusters I see in the enterprise are on big VMs or metal (48 core boxes) and so can range from 100-400 for a lot of common medium sized workloads. But at that density you also have to have a workloads with low IO requirement
99.
by smarterclayton 8y ago
Startup time is the hardest (and most valuable) piece for everyone to work together on. By improving startup time of Kube containers, we can benefit (and draw from) a lot of people who are using Kube today, not just knative. This is a gre
100.
by smarterclayton 8y ago
Thanks for that - we definitely think there are many great ideas floating around in the Kube ecosystem, and projects like knative bring together a critical mass of perspectives and people to take “good ideas” and make them “things we all ca
101.
by smarterclayton 8y ago
We definitely want to support knative, integrated well with existing concepts (like triggering deployments and builds when images change), to stitch in the new build resource so it works well with existing tools like s2i (as Jacques mention
102.
by smarterclayton 8y ago
Re: upstreaming - Kubernetes has tried really hard to make it easy to be extended, and knative also tries to use those mechanisms and be nice, clean, reusable APIs that can be used on any Kubernetes cluster. I think it's increasingly
103.
by smarterclayton 8y ago
Agree, virtual hosts are ubiquitous. But I don’t know that anyone loves their virtual machines the same way they love the smaller, faster, and simpler alternatives (unikernels included). This is a somewhat pessimistic viewpoint, but lowest
104.
by smarterclayton 8y ago
For example, OpenShift (Kubernetes + stuff also from Red Hat) exposes this pattern like both heroku and cloud foundry by A) focusing on having standard base images controlled by ops B) encouraging combining source code / built artifact
105.
by smarterclayton 8y ago
We did something simple for GCP and CI jobs, when we needed to have VMs in a certain project to launch Kubernetes single node testing - https://github.com/openshift/ci-vm-operator/ The base pattern should be prett
106.
by smarterclayton 8y ago
At the time gRPC was not part of etcd - that only arrived in etcd 3.x. The design of etcd 3.x was heavily influenced by the Kube usecase, but the original value of etcd was that A) you could actually do an reasonably cheap HA story (vs Sing
107.
by smarterclayton 8y ago
cri-o has exactly three foundational principles: * be exactly what Kubernetes needs and no more * work with OCI-standard runtimes (runc, gvisor, runv, kata, clearcontainers, etc) in order to accomplish the above * integrate well with Linux
108.
by smarterclayton 8y ago
Initially its going to be based on RHEL so we can quickly ramp up. Over time it’s very likely we get more aggressive with RH CoreOS and newer kernels, but those are all details being worked on. It’s very important for us to be able to ben
109.
by smarterclayton 8y ago
The combo is going to be ignition + ostree + evolution of Omaha (update server) + more prototyping still being done. It won’t be using chrome OS bits. Edit: as of now this is what the team is thinking, still lots of room for changes as we r
110.
by smarterclayton 8y ago
Maintained. A new offering based on RHEL will be initially targeted for the supported scenarios under openshift while we work with the communities on how they want to evolve.
111.
by smarterclayton 8y ago
I kind of agree. At this point it may just be better to write controllers that read generic policy from a different object and the base definition from the Kube object. But at that point, the extra ingress object is just a convenience.
112.
by smarterclayton 8y ago
CPU Cache contention, network overhead introduced by Kubernetes service proxy model, even the liveness checks. We haven’t yet evolved Kubernetes services to prefer specific cores and avoid app workloads quite yet (although cpu management is
113.
by smarterclayton 8y ago
And that’s why the team created a Helm-operator based on Lostromos (a tool for expanding Helm charts without running a tillers erver) that makes it easy to use a Helm chart for templating but still add additional lifecycle on top: https:&#
114.
by smarterclayton 9y ago
Image based volumes (second last to bullet) has long been blocked on the container runtime having a really clean way to enable and keep the container filesystems mounted. Definitely something I want to see fixed since otherwise you just en
115.
by smarterclayton 9y ago
It comes with restrictive PSP equivalents by default. We disable every insecure port on the cluster. End users can’t schedule onto masters or other core infrastructure. Node authorizer is now on by default so nodes are limited in what th
116.
by smarterclayton 9y ago
It’s not quite random. Every namespace gets assigned a unique block of 10k UIDs and the default container UID is the first in the block for all unprivileged users. Granting access to a higher powered PSP (actually a security context const
117.
by smarterclayton 9y ago
I’m about to cut OO 3.9 (based on 1.9) - we’ve been waiting for the subpath CVE fixes and regressions to get sorted out before we cut a release.
118.
by smarterclayton 9y ago
There is kompose with a k: https://github.com/kubernetes/kompose
119.
by smarterclayton 9y ago
I work on Kubernetes today, and you could argue it’s on it’s way to being bloated too. Successful platforms grow until they are replaced by younger, hungrier, more purpose built platforms that solve problems the old platforms couldn’t. It’
120.
by smarterclayton 9y ago
IBM typically does things “first” (social media product efforts at IBM predated Facebook, for example), and IBM research has routinely produced innovations decades earlier than their adoption. WebSphere was a platform as a service in 2004.

More ›