In that post I mentioned in passing that I'd also be looking into doing day two stuff. And I did. It just didn't materialize in a new post :)
What I realized when testing out stuff was that while I did use my own blog post for reference it was sort of unpractical scrolling up and down the page to find the right command, and jumping between various tools and ways of solving things. I thought that "hey, wouldn't it be nice if I could just start a script and have it go through everything automatically?" Of course it would; it was just a matter of a little bit of effort getting there. (Or almost there at least.)
TL;DR - I have a repo over at https://github.com/ahelland/Cloud-Native-DevLab where I have made a collection of scripts to set you up with an AKS cluster along with a couple of features you may need/want to test on your Windows Server/Azure Stack HCI box.
Still here? I'll call out a few things to provide a backdrop and a couple of explanations.
I wanted to have a repo you could pull down and step through interactively on your client computer using .NET Interactive Notebooks. That's a great way to run code inline in a document. Turns out that doesn't work when you attempt to setup a remote PowerShell session.
I was also thinking about having the repo set up Visual Studio Code and all the UI tooling you need (locally on the host system). That sort of worked, but that would assume you're running the Desktop Experience which you're not doing if you use Azure Stack HCI. So I made it a command line experience - you probably need to copy the initial bootstrapping from your desktop to the server, but as part of the bootstrap Git is installed and the repo pulled down so you can do the rest without having a CTRL-C + CTRL-V party.
So, looking at the commit dates it seems this was done a long time ago? Yes and no. A couple of things went up early, but I needed some QA time and was also stuck on bugs with the product and the components so it wasn't that easy. I didn't want to provide a guide sending you straight into "this doesn't work". There's also other things I spent time testing that ended up being left out. And I wasn't in a hurry I guess :)
Modularizing it however was not an error; that was a deliberate choice. I have separated things into sections that should be independent of each other - you just want to test Flux and don't care about Grafana? No prob.
The repo does not go into great lengths explaining choices and the "why" of things. I wanted to keep it more to the point. That way it is easier to update and replace things as well.
Here are sections and components of the guide:
01_Bootstrap We install the necessary tooling and install a management and a workload cluster.
02_Monitoring We install Prometheus, Grafana and Jaeger. Loadbalancers for all three are also created (if you want), but not DNS names.
03_Azure_Policy We create a service principal (with a "Policy Writer" role) and use this to enable Azure Policy in our cluster.
04_ExternalAccess We install Nginx and CertManager, and configure integration with Azure DNS. This enables you to have Kubernetes take care of configuring DNS for you and enroll a certificate from Let's Encrypt when you deploy an application to the cluster.
05_MonitoringIngress This section provides configuration files for enabling ingress for Prometheus and Jaeger.
07_Dapr Explanation of Dapr plus installation commands. Links to more info and samples.
08_Flux Installation of a sample app using a GitOps approach with Flux.
Samples Samples for testing out the basic functionality of the cluster based on the installations in the sections above.
While the focus is more on the scripts than explanations I have attempted to include some instructions. Note that you also need to fill in the blanks yourself for variables unique to your environment. (Cloning the repo and just executing the PowerShell immediately will most likely throw errors at you.)
I'm not saying this is the only way, or the right way for everyone. And since the focus is on dev use it could very well be that you don't care about things like Azure Policy. Having it all in one location and tested in a cohesive manner should help though.
I'm currently working on testing workload identities. Worked fairly easy on AKS in the cloud. Not as easy in the on-prem variant so we'll see how that plays out. Point being - I try to add things to the guide, and will attempt to both optimize and re-arrange content if needed. I also intend/want to create more complex samples; but need to have the baseline working before going all in on that.
I guess the value of all of this is still limited if you don't have the hardware to run things. That has made me think of whether I should create a version for AKS running in Azure as well, but I haven't decided - there are already a ton of guides and documentation out there for that purpose.