Keynote: KubeCon Opening Keynote - Kelsey Hightower, Google
CNCF [Cloud Native Computing Foundation]0 HN recommenders · 2018–2018
27K views · talk · dated · Uploaded 2017-12-15
Kelsey Hightower's opening keynote at KubeCon, delivered as a live-demo style talk about Kubernetes and cloud-native tooling.
HN mentions it mainly as an example of Hightower's live-demo keynotes and a demo of pull-request-driven promotion and deployment.
19:10Velocity NY 2013: Richard Cook, "Resilience In Complex Adaptive Systems"
O'Reilly
52:35Debugging Under Fire: Keep your Head when Systems have Lost their Mind • Bryan Cantrill • GOTO 2017
GOTO Conferences
59:56AWS re:Invent 2018: Amazon DynamoDB Deep Dive: Advanced Design Patterns for DynamoDB (DAT401)
Amazon Web Services
28:36Literate Devops with Emacs
Howard Abrams
42:54Containers From Scratch • Liz Rice • GOTO 2018
GOTO Conferences
20:29Over 200,000 Servers in One Place! Visiting Hetzner in Falkenstein (Germany)
der8auer EN
1:31:05Bryan Cantrill from Joyent on Manta: internet-facing object storage facility that features compute
AI Council
46:37Zebras All the Way Down - Bryan Cantrill, Uptime 2017
Code & Supply
3 comments from Hacker News
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. [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 - [VIDEO] And a better writeup on weave's site - [LINK]
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] [VIDEO]