Not to mention that beside its insane complexity most people these days probably just need linkerd instead. Google pushes Istio because they built it but it’s so overkill for so many people’s use cases.
Yeah you really need to understand what K8s does before even thinking about a service mesh like Istio, weird that it’s the first link on the page.
I love Kubernetes for the most part and it’s awesome, but yeah, starting with Istio is like going from 0 to 60 MPH in a few seconds in a sports car when that person has been riding an e-bike as their primary transportation for 3 years.
Yea, the front page seems to be optimized for recency -- Istio is on top because its the newest module, as the heading "Latest release" states.
If you scroll down to "View all series" they have one listed as "KUBERNETES FOR COMPLETE BEGINNERS"[1]. The content is 1-2 years old which can be quite a ways back in our field.
Kubernetes can be a fairly exotic solution to fairly mundane problems.
There is however, perhaps, an inherent elegance in API design and separation of concerns which could result in a transformation in the control of storage and compute at all scales.
A lot of these learning resources either tie you down a vendor Cloud specific Kubernetes like this one or run they risk of getting outdated. My journey to Learn Kubernetes using Vagrant , VirtualBoxe VMs, Ansible and Kubeadmin has run into a lot of those.
First , there is the issue of Docker and Kubernetes compatibility that I ran into. I could not get Docker shim to work and pivoted to Containerd. Once I sorted this out , I was able to get my Kubernete cluster deployed. Or So I thought.
I ran into an issue of my nodes not using the correct IP address to join the cluster. Apparently, there is a flag you need to enable in the nodes like KUBELET_EXTRA_ARGS="--node-ip=<your node ip address>". Once I got this sorted out by modifying /etc/systemd/system/kubelet.service.d/10-kubeadm.conf , my nodes were able to join the cluster properly and I was ready to do actual development. Or so I thought.
There is this issue of Loadbalancer. I had no idea that the only way to get Kubernetes to work and expose deployed services require a cloud vendor specific load balancer. If you deploy Kubernetes using Kubeadmin and VMs, you do not get a load balancer. So now I have to deploy something called MetalLB or create services of type NodePort so that they can be accessed using node ip addresses. MetalLB requires knowledge of BGP which I don't have. So I will stick to NodePort.
So now I have to deploy a vm with Haproxy as the Loadbalancer that could forward the calls to Nodeports of my services on my Kubernetes cluster on my laptop.
I have been told it is roses all the way once the cluster is working with the load balancer. Or so I think.
Have you looked into using an ingress controller[1]? Still not quite as easy as a managed LoadBalancer but at least you wouldn't have to configure every single service manually.
edit: of course, not very useful if your services aren't using HTTP.
I did it as well and I wouldn't recommend it to people who want to know how to use K8s. If you are going to administer (i.e., setup from scratch) K8s clusters, then yes it's a good resource.
I know that K8s isn't Docker, but discussing learning the former, does anyone have a suggestion for learning the latter? I know what Docker is and have even used it for a production service, but I definitely don't feel like I've learned it "properly". I vaguely recall reading some of the Docker documentation and was underwhelmed with its ability to onboard newbies.
Docker's recent licensing changes seem to make it not as popular anymore (>10M revenue every developer needs a license for docker desktop). Kubernetes even deprecated docker as a container runtime (https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-...).
That deprecation was because the Docker shim (compatibility layer) was expensive to maintain. You can still use containerd, which is Docker’s runtime, as a Kubernetes runtime.
This framing (Docker is losing popularity, even k8s is deprecating it) is misleading. The article you linked to clears that up immediately out of the gate (emphasis added):
> You do not need to panic. It’s not as dramatic as it sounds.
> TL;DR Docker as an underlying runtime is being deprecated in favor of runtimes that use the Container Runtime Interface (CRI) created for Kubernetes. Docker-produced images will continue to work in your cluster with all runtimes, as they always have.
> If you’re an end-user of Kubernetes, not a whole lot will be changing for you. This doesn’t mean the death of Docker, and it doesn’t mean you can’t, or shouldn’t, use Docker as a development tool anymore. Docker is still a useful tool for building containers, and the images that result from running docker build can still run in your Kubernetes cluster.
I learned it by first building a homelab cluster and spinning up simple services with DNS on it. Then I did the same on a cloud provider. Digital Ocean has some great guides and starter kits for how to do it on their platform.
I suggest reframing the question to, “how do I learn how to build container images?” Docker as a container runtime is dying fast and being replaced, so no need to learn the runtime.
The lasting contribution of Docker is the Dockerfile, learning that and the alternative ways to build an image is sufficient in 2022.
Learning Dockerfile is most of the work of learning Docker, and the docs and tutorials for Docker are far more thorough and useful at this stage than the docs for podman or whatever else.
There's no harm in learning Docker even if it gets replaced completely in the next 10 years, because there's enough industry inertia behind it that any replacement will be highly backwards compatible.
Given that that domain was registered in 2008, they probably have just been using this one for so long that it's not worth the hassle to switch now that they have the TLD.
