3 ms·

On the topic of "takes too long to learn" can someone recommend a good tutorial on basic Kubernetes concepts?

CSSer 6y ago
I think OP put this just as good or better than I could've in their blog post. > I think Kubernetes has fallen into the Vim/Haskell trap. People will try it for 10 minutes to an hour then get fed up. The point where you start to grok stuff just happens too late for most people to stick with it. Those become a vocal minority proclaiming it as too complex for humans to understand, and scare off people that haven’t tried it at all. I've had good luck with the tutorials and various help articles in the official docs[0]. [0]:https://kubernetes.io/docs/tutorials/kubernetes-basics/ https://kubernetes.io/docs/tutorials/kubernetes-basics/
qbasic_forever 6y ago
Kubernetes The Hard Way if you want to start from first principles and learn all about low level tools and setup. In practice you're probably going to use a cloud provider or tool to automate all of this stuff, but it's useful to understand the core infrastructure like TLS certs, etcd, etc. Otherwise the official docs are quite good and worth starting there. I'd be wary of buying books that are more than a year or two old--the k8s space moves fast and they regularly have major updates once or twice a year. Books and docs can get a bit stale or out of date with current best practices.
pas 6y ago
The trick is that to have a real chance of administering a k8s cluster you need Linux kernel knowledge (namespaces to understand docker, a bit of iptables, VXLAN or something similar to understand CNI/overlay network, how the container network namespace is connected via veth pipe, chroot/bind mounts, a very little bit of SElinux/apparmor/seccomp), systemd to see how it all starts, etcd to know about the consistency/consensus layer.. so far this is almost identical for all container orchestrator/scheduler platforms (nomad, docker swarm). Then there are the specific k8s concepts: pod (containers that share a network and PID namespace), service (a name, a TCP and/or UDP port number, and the name/selector of the target pod), ingress (HTTP routing, basically haproxy/nginx/envoy or other layer 7 stuff), LoadBalancer (the magic API that connects your cluster to the outside world, allocates IP addresses for Services/Ingresses). Then there are the background parts that take the YAML and convert it into actual running stuff: apiserver (this is the central info hub, kubectl and kubelets and controllers all talk to this basically), kubelet is the actual agent on each node, controllers have control loops and those actually calculate the necessary actions/operations to achieve what the YAML declared. Then there are the subsystems: storage (persistent volume claims and PVs), settings (secrets - see vault too - and configmaps, and various special/custom resources like a TLS certificate, these are stored in etcd, through the apiserver of course), CNI networking flavors and knobs, an endless list of kubelet and apiserver command line arguments, PCI passthrough for GPUs or HSMs or whatever. And of course there's RBAC, security, admission webhooks, see how nowadays Authz and Authn is done through a "lookaside" OpenId Connect service (some Ingress Controllers support these out of the box).

I think OP put this just as good or better than I could've in their blog post. > I think Kubernetes has fallen into the Vim/Haskell trap. People will try it for 10 minutes to an hour then get fed up. The point where you start to grok stuff just happens too late for most people to stick with it. Those become a vocal minority proclaiming it as too complex for humans to understand, and scare off people that haven’t tried it at all. I've had good luck with the tutorials and various help articles in the official docs[0]. [0]:https://kubernetes.io/docs/tutorials/kubernetes-basics/ https://kubernetes.io/docs/tutorials/kubernetes-basics/

qbasic_forever 6y ago

Kubernetes The Hard Way if you want to start from first principles and learn all about low level tools and setup. In practice you're probably going to use a cloud provider or tool to automate all of this stuff, but it's useful to understand the core infrastructure like TLS certs, etcd, etc. Otherwise the official docs are quite good and worth starting there. I'd be wary of buying books that are more than a year or two old--the k8s space moves fast and they regularly have major updates once or twice a year. Books and docs can get a bit stale or out of date with current best practices.

pas 6y ago

The trick is that to have a real chance of administering a k8s cluster you need Linux kernel knowledge (namespaces to understand docker, a bit of iptables, VXLAN or something similar to understand CNI/overlay network, how the container network namespace is connected via veth pipe, chroot/bind mounts, a very little bit of SElinux/apparmor/seccomp), systemd to see how it all starts, etcd to know about the consistency/consensus layer.. so far this is almost identical for all container orchestrator/scheduler platforms (nomad, docker swarm). Then there are the specific k8s concepts: pod (containers that share a network and PID namespace), service (a name, a TCP and/or UDP port number, and the name/selector of the target pod), ingress (HTTP routing, basically haproxy/nginx/envoy or other layer 7 stuff), LoadBalancer (the magic API that connects your cluster to the outside world, allocates IP addresses for Services/Ingresses). Then there are the background parts that take the YAML and convert it into actual running stuff: apiserver (this is the central info hub, kubectl and kubelets and controllers all talk to this basically), kubelet is the actual agent on each node, controllers have control loops and those actually calculate the necessary actions/operations to achieve what the YAML declared. Then there are the subsystems: storage (persistent volume claims and PVs), settings (secrets - see vault too - and configmaps, and various special/custom resources like a TLS certificate, these are stored in etcd, through the apiserver of course), CNI networking flavors and knobs, an endless list of kubelet and apiserver command line arguments, PCI passthrough for GPUs or HSMs or whatever. And of course there's RBAC, security, admission webhooks, see how nowadays Authz and Authn is done through a "lookaside" OpenId Connect service (some Ingress Controllers support these out of the box).