My dayjob employer started a massive shift to K8S (in the form of AKS on Azure) a while back. I was pretty heavily involved in that, and can share some thoughts based on my experiences. There are a lot of variables though, so "YMMV".

By and large, your option (1) is closer to what we did, but with the caveat that most of us didn't stay on the "use Minikube" path very long, because it's somewhat limited compared to a real cluster, and can really bog down a developer laptop, etc.

Also, consider that we were coming from a situation where our deployments were to Docker Swarm, so we already had all our apps built for containerization in the general sense, and just had to port things from Docker Swarm to Kubernetes. Not quite the same as starting from scratch.

Anyway, we got automation in place for provisioning AKS clusters and made it easy for developers to quickly spin up a small (2-3 node, with auto-scaling optionally turned on) cluster on AKS and the ability to directly interact with the cluster using kubectl. Most developers quickly started doing all their initial prototyping and testing on a real cluster instead of Minikube.

Early on we hand-wrote K8S deployment yaml files and ran deployments using kubectl apply -f filename.yml. But we quickly moved to Helm and by and large I'd say that was a good move. Most deployments now are doing using Helm, run under an Azure Devops pipeline (but you can still do all this stuff on the local command line if you want, at least in non-prod).

The good news is, you can do a lot of this in something of an incremental fashion. That is, you don't have to use every feature of K8S and every fancy supporting tool right out of the gate. You can start by taking as basic Docker image and just getting it to run and configuring a NodePort for access. Over time you can start integrating Secrets, ConfigMaps, Services as External LoadBalancers, persistent Volumes, Helm, yadda, yadda, yadda.

We also adopted Istio as part of our stack early on, and that has also been a big success for us. Istio provides a lot of facilities that are very handy and/or desirable and has been very helpful for us. The biggest win is the mtls support which makes it easy for us to comply with the (internal) requirement that all "on the wire" traffic be encrypted. But beyond that, the traffic management facilities with VirtualServices have proven quite useful. We're just starting to explore integrating Istio's traffic management with Azure Active Directory using OIDC now. If it works, that's also going to be a big win for us.

Note that we did have to make some code changes, since our old model used the Netflix OSS stack along with Spring Cloud Config, and once we went to K8S we were able to throw out Eureka, Hystrix, and some of that stuff. Spring Boot does have a handy library that provides "native" interop with K8S via the API server to automatically import ConfigMaps and what-not, which is kind of handy if you're a Java/Spring shop.

Last note: me personally, I don't find the Azure Portal to be something I use very much, but I'm biased towards being a command-line guy in the general sense. Most of my interactions with Azure and AKS are through the az and kubectl command-line tools (and occasionally istioctl or helm as well).