Zero to Kubernetes on Azure | Hacker News Reader

Zero to Kubernetes on Azure

idursun.com

155 pointsonatm10 comments

This is great for the dev flow of getting up and running on Azure. When you are ready to do something in production on Azure, you should also have a look at this project https://github.com/Microsoft/bedrock, which provides a model for operationalizing a Kubernetes cluster with a GitOps workflow.

This looks like a great article and not highly specific to Azure. It is a tutorial for Azure AKS, sure, but while you do use AKS for the cluster management and Azure services for a few things like DNS, you've taken us all the way through installing nginx-ingress and are not using or even mention the ingress addon from Azure.

I don't mean this as critical feedback! I love the article and will go over it reading in a bit more detail later, but that one thing I noticed off the top of my head made me want to ask why not use the provided nginx-ingress addon?

(I can think of a few reasons why myself, but if you are OP, I thought it might be better to ask why _you_ did this rather than just throwing in my own $0.02.)

Hi, I am the author.

Thanks for pointing out the Azure's nginx-ingress add-on. The reason why I haven't mentioned it in the article is simply because I didn't know about it. I also haven't seen it used or mentioned in the articles published by Microsoft.

This article was the artefact of my personal effort of trying to understand what are the moving parts of a k8s cluster and what tools are used in what ways.

I am sure there are better/different ways of achieving the same and I am happy to hear all!

I will say that once in my whole time using AKS, the nginx-ingress addon failed me in a way that caused my cluster to stop serving traffic.

I contacted my friend at Azure (my cluster is not high-stakes production) and learned that they were aware of the issue and had engineers already on the case.

I figured it out on my own before the Azure team resolved the issue globally, there were some versions out of sync. And when I applied the fix to my own cluster, the ingress addon... put it back, breaking my traffic serving again.

The fix would have been to install nginx-ingress manually and point my DNS at the LB belonging to my manually configured ingress. I just waited for them to get it solved instead. Meanwhile my cluster was not serving ingresses.

That may (hopefully) never happen again, but the moral of the story is, one good reason to configure ingress yourself is that when it breaks, you can also fix it for yourself.

I actually wrote this for you, before you wrote your post:

Create a set of focused how-to guides for building a Kubernetes + Workflow + cert-manager + nginx-ingress cluster, that you can run your blog or anything else on. This can be a tutorial for intermediate to beginner audience, but it should cover everything that you need to harden your basic internet-facing Kubernetes+Workflow cluster, updated for 2019.

https://blog.teamhephy.info/blog/posts/announcements/season-...

+1 thank you for sharing your stuff

I prefer aks engine to aks. https://github.com/Azure/aks-engine

- Azure control nodes have problems all the time, running my own is easy - With aka engine multiple nodepool support is easy and not a “preview” - we use low priority nodes and those are not supported in stock aks, and it won’t probably for a year

I'm curious why the author used AKS. From my experience, I noticed that is the slowest to provision. I have personally experienced etcd nodes becoming unhealthy in lightweight test clusters which concern me with using AKS in production. Is AKS becoming the more popular of the three hosted k8s offerings?

AKS is certainly way better than Amazon's EKS offering - and while AKS was a bit unstable at the beginning, lately it has been very solid for me (I run a workload in production on it).

I don't know when your testing occurred, but I heard that long ago, AKS was very slow to provision and that it had gotten better. I have one AKS cluster that is pretty lightweight, does not get torn down or re-provisioned often (so I wouldn't notice that) and I've never noticed issues with etcd health faults.

Just an anecdote to counter your anecdote, I know that the plural of anecdote isn't data...

Running AKS from even late 2018 is completely different than running it now. They have been making strides in provisioning and it is more than stable enough to run AKS clusters in production. Provisioning an AKS cluster in Nov 2018 would sometimes take up to 45minutes/1hour or end up in an error'd state. By the time Kubecon rolled around (a month later, Dec 2018) AKS clusters were taking between 4~6 minutes to provision on average. Compared to EKS, it is definitely a more automated way of provisioning a K8s cluster (workers provisioned for you) and definitely takes less time to provision (EKS takes roughly 12~15min).

Reply on news.ycombinator.com