Learn Kubernetes with Google | Hacker News Reader

Learn Kubernetes with Google

learnkubernetes.withgoogle.com

111 pointsGigacore37 comments

This seems to gives you no starting point.

Right? The first link on the page is "Installing Istio on Kubernetes".

What is Istio? Why would I want to install it? Can you teach me what Kubernetes is first, and how to install that?

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.

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.

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.

[1]: https://learnkubernetes.withgoogle.com/kubernetes-essentials....

Yes, it looks like a library of K8S tutorials without any overall walkthrough.

After a search, I guess this one would be the best starting point:

https://learnkubernetes.withgoogle.com/kubernetes-essentials...

To me, Kubernetes looks like a thing a person learns on a team.

It is bigger than what one person can typically learn on their own.

Which makes sense since it is based on a tool for teams at Google.

Most organizations don't have Google like teams.

And most organizations don't have Google sized problems...and Kubernetes is based on solutions to Google sized problems.

K8s certification courses (CKA for example) have good intros usually. I did the one on kodekloud, but I think there are plenty of other good ones too.

I think you are right.

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.

it's the usual problem with kubernetes.

and it's always mostly poorly documented, particularly regarding how to set it up (api server parameters etc).

my guess is that google pushes kubernetes as a "runtime" but meant to be used via its proprietary implementation on google cloud.

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.

https://kubernetes.io/docs/concepts/services-networking/ingr...

Just FYI: MetalLB can be used without BGP, in L2 mode. It was actually one of the few things that "just worked" for me (with k3s).

VMware has a similar offering called KubeAcademy at https://kube.academy

i quite like "kubernetes the hard way" by Kelsey Hightower https://github.com/kelseyhightower/kubernetes-the-hard-way

not sure how up-to-date it is, but it really helped me understand how k8s works.

While the above resource is really good, it is more about setup than using Kubernetes.

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'd qualify that with "if you need to know how to use it as quickly as possible" then it probably goes into more depth than you need.

On the other hand, having at least some idea of how the thing you're using works under the hood is never a bad idea.

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.

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.

I'm a big fan of Julia Evans' zines. They're short and to-the-point and are often excellent jumping off points.

This one seems highly relevant: https://wizardzines.com/zines/containers/

This was also posted on HN a couple weeks ago: https://earthly.dev/blog/chroot/

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.

https://devopswithdocker.com/

Is withgoogle.com an official Google website, or are they about to get hit with a takedown notice for trademark infringement?

It does look official: https://who.is/whois/withgoogle.com

It's good. The certificate is also valid for .apps.google and .appspot.com, and is issued by Google Trust Services LLC.

> Google Trust Services LLC

Which confusingly, is under the TLD .goog instead of .google, for god knows what reason...

> god knows what reason...

Likely for privilege separation.

Doesn't Google/Alphabet have their very own TLD that could use instead? Then it'd be very obvious what is/isn't official.

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.

It seems to be the domain they use for conferences and other things that they host. Like https://opensourcelive.withgoogle.com/

It's official.

No thanks.

Reply on news.ycombinator.com