How to become a gophernetes

The Go community well knows what a Cryptogopher is! Today is the way where you will learn about how a Gophernetes looks like! Kubernetes is all about extendibility. That’s why every cloud provider is able to plug their network implementation, storage layer or compute platform to it. But in order to do so, you have to write code to glue your platform or external project with Kubernetes itself. Gophers are in a unique position when it comes to writing code for Kubernetes because even if there is an API that gives you the opportunity to write integration in any language, it is written in Go, and that’s a huge benefit. This talk is for Gopher that want to become Kubernetes developers also called gopherneters. I participated in various efforts around integration at storage layers, with the container storage interface, or container runtime interface and recently with cluster-api, the abstract that drives the Kubernetes provisioning in a declarative way. It means that I wrote a good amount of Custom Resource Definitions (CRDs), Shared Informers and so on. It is a jungle and I will share what I learned in terms of best practices, testing to write solid Kubernetes integrations.

Transcript

1. How to Become a Gophernetes Gianluca Arbezzano / @gianarb
2. K8s is Hard and there’s nothing wrong with that
3. What is a Gophernetes? What does it look like?
4. What is a Gophernetes? • Develop applications running in Kubernetes • Develop Kubernetes • Develop on the Kubernetes Foundation
5. What does it look like?
6. Where are they? • Kubernetes Slack • GitHub around the kubernetes or kubernetes-sigs organization
7. https://kubernetes.io/docs/concepts/architecture/cloud-controller/ 

8. https://kubernetes.io/blog/2018/07/18/11-ways-not-to-get-hacked/ 

9. https://github.com/kubernetes/website/blob/master/content/en/blog/_posts/2017-11-00-Containerd-Container-Runtime-Options-Kubernetes.md 
 

10. Extensibility is the key Kubernetes is a blob of APIs • API Server • CRI (Container Runtime Interface: docker, containerd) • CNI (Container Networking Interface: calico, flannel) • CSI (Container Storage Interface: aws-ebs, packet-csi) This is how it abstracts your workflow from your infrastructure API Server kubelet CSI CNI CRI
11. About Me
 Gianluca Arbezzano • Gophernetes at Packet.com • www.gianarb.it / @gianarb What I like: • I make dirty hacks that look awesome • I grow my vegetables • Travel for fun and work
12. Workflow? Workflow is the reason behind why we have Kubernetes. It is the end goal for any good Gophernetes. Being able to leverage kubernetes extendibility to implement the best workflow you can even image. Examples of workflows: • Troubleshooting and debugging • Observability (data pipeline for logs, metrics, traces) • Delivery (canary release, blue green deployment, progressive delivery, your own one)
13. Workflow The Gophernetes is the limitation. It means that in theory with good code you can whatever you image
14. Extensibility is the key
15. • Event system • Share informers • Custom Resource Definitions • Kubecutl plugin • ClusterAPI (Packet implementation is under active development! Watch out!) How do you extend Kubernetes in practice?
16. Gophernetes toolchain • kubernetes/client-go • kubernetes/cli-runtime • kubernetes-sigs/kind
17. Kubectl Plugin $ cat > /usr/local/bin/kubectl-hello #!/bin/bash echo "this is a simple kubectl plugin. But gophernetes can do better, because this is bash..." ^C $ chmod +x /usr/local/bin/kubectl-hello $ kubectl hello this is a simple kubectl plugin. But gophernetes can do better, because this is bash...
18. Shared Informer https://gianarb.it/blog/kubernetes-shared-informer
19. The UX is crucial. Keep it as close as possible with the Kubernetes one...
20. Authentication
21. Flags Companies and teams invests a lot of time learning kubernetes and its cli.
 Tools developed to Gophernetes has to keep the same flavour. It should be the same as running a bike, does not matter which one you own, it always looks familiar.
22. Flags: github.com/kubernetes/cli-runtime This library is a shared dependency for clients to work with Kubernetes API infrastructure which allows to maintain kubectl compatible behavior. Its first consumer is k8s.io/kubectl.
23. Flags: kubectl-profefe uses it as well My expectations as a kubernetes user for examples are (at least): • When I have to do filtering ◦ Label Selection: -l app=dev -l runtime=1.14 (--selector) ◦ Namespace selection: -n namespace (--namespace) ◦ -a (--all-namespaces) • When it comes to authentication ◦ --kubeconfig • Output ◦ -o yaml | json (--output)
25. • kubernetes-sigs/krew-index • kubernetes-sigs/krew Krew makes plugins easy to install and discover $ kubectl krew install profefe
 $ kubectl krew install tree
 $ kubectl krew install ctx

26. The CLI runtime contains utils to print tables from cli, but I didn’t use it yet!
27. Production is a dangerous place.
 Usually hard to work with (reasonable)…

28. Kubernetes gives you for free a couple of things: • As we saw, a consistent API and a solid ecosystem to interact with it • Authentication (that you can plug with your identity management) • Authorization with RBAC • Audit logs Why?
29. • Kubernetes Assemble • https://get.oreilly.com/ind_extending-kubernetes.html • Programming Kubernetes: Developing Cloud-Native Applications • Krew kubectl plugin index • jtblin/kube2iam • https://gianarb.it THANKS LINKS
30. Thanks @gianarb / gianarb.it