Keynote: KubeCon Opening Keynote - Kelsey Hightower, Google

Kubernetes projects leads would argue that any time a user has to SSH into one of their K8s workers, they should file a bug against Kubernetes. At KubeCon CPH, when I asked Tim Hockin about the long-awaited debug containers feature, aka 'kubectl debug', he said that "I really do feel that every time someone has to SSH into a node a ferry loses its wings." :) Dropping out of or below the cluster layer inherently means there is something in K8s that is missing. But no matter what is added to its APIs, Kubernetes will experience a long tail of weird corner cases that just can’t be covered. Reportedly the same is true with Borg jobs internally within Google. Teleport's K8s protocol implementation mates its certificate-based SSH auth with Kubernetes certificate signing request API, plus Teleport acts as a full recording MITM for all K8s apiserver requests. How exactly end-users will leverage this remains to be seen, but we're super excited to see where the community takes this (and related tricky K8s vs provider IAM issues) as it continues to expand. Full disclosure -- I work at Gravitational, worked closely with Sasha on this feature[1], and am a fan of Kelsey Hightower's live demo keynotes[2] where he frequently quips about the inherent struggle between procedural Dev+Ops encountering declarative APIs such as K8s. [1] link [2] ▶ this video

Please don't. I am using gitlab, though we quickly grew beyond auto devops. Your definition of auto devops is different than gitops. Gitops is the practice of using commits and pull requests to execute change and do releases. Weave uses it to mean git as the source of truth. link Kelsey Hightower talked about it and and has demoed the workflow of using pull requests to initiate promotion and deployments. Gitlab's auto devops does not seem to tackle promotion via environment repos, so in my understanding does not fit gitops and would be confusing to call it such. Edit: Kelsey Hightower's kubeconf talk - ▶ this video And a better writeup on weave's site - link

well the problem with openshift on redhat/centos/atomic/whatever is that you still need to regulary update your cluster os's. however when you setup a bootkubed/self-hosted kubeadm cluster you can basically run on coreos and only need to update your self-hosted control plane and kubelet/(etcd, if not self hosted, too) this makes it way, way easier to have an up-to-date os + kube than any other solution (kubelet and etcd can be updated via etcd-wrapper and kubelet-wrapper, so this is even more insane). BUT i think that red hat pushes for an easier upgrade path anyway, that's why they basically bought coreos. for CoreUpdate + Tectonic + MatchBox, so I think that in the end Redhat will have a similar simplier upgrade mechanism, but only time will tell. What would in fact be awesome if CoreUpdate could also update Kubernetes Kubelet's and Etcd and than it would be a no-ops os if something broke you just boot a new system and delete the broken node. And yes kubectl is the ssh/ftp of k8s. ▶ this video