Sorry if I'm late, I'll try to give an answer for future readers, or maybe still for you!

First of all, docker build and deploy on kubernetes cluster are two totally different phases of your software supply chain, let's keep them as separate discourses

1. The build process should be already automated: if you need to run manually mvn clean install it means that you are loosing one of the advantages of Docker: build repeatable, immutable software packages that can be delivered everywhere. Just add RUN mvn clean install to your Dockerfile (yes, you need to put maven in your image before, but there are some base images around that does the job for you). Now you should just set up a CI server that builds and pushes images at every repository check-in (I am intentionally skipping any quality gate and pipeline workflow , they're up to you to automate). Also deploy can be managed by CI servers, there are two main approaches

a) create a config repository with all the k8s manifests and run kubectl apply from you CI server at every push

b) put config along with the interested microservice, tag the fresh built image with the commit hash and at the end of the pipeline kubectl apply env.yaml && kubectl set image myregistry.com/myimage:${commitHash} (just be sure to tag also as "latest" and include the latest tag in you deployment spec, it helps to reconstruct the current situation after a remove-and-apply configuration)

c) deploy with helm charts. It's similar to the previous but you can leverage all the advantages of the dependency management and deployment templateization

2. Hot reloads are nice when you do your tdd development but useless when the code is about to be delivered, neither with node/python microservices you will use it because once your code is containerized, you should shoot with an AK47 every developer that tries to touch it. The real big thing here is to automate your integration/delivery/deployment. In my team we just need to open and accept a PR, and the magic happens

3. You need to do some debugging/integration between microservices on your laptop. I would not discourage this practice, but is something that has to be done at a frequency for which speed is not so important for productivity. But if you want to do it, you can do it building a "laptop" or "dev" environment with docker compose, pulling your dependencies from the registry (to reproduce the current "online" situation) and then build your microservice with its own configuration. Another way is to use port forwarding a k8s capability to pretend that a pod is connected with your local machine exposing a well-known port, but is an headache if there are many dependencies. A third way is to use tools like https://www.telepresence.io/ that promises to run a pod locally and connect to the cluster with a pair of proxies in both directions

You can build a docker image directly from maven with docker-maven-plugin. Add to your pom.xml:

<build>
  <plugins>
    ...
    <plugin>
      <groupId>com.spotify</groupId>
      <artifactId>docker-maven-plugin</artifactId>
      <version>VERSION GOES HERE</version>
      <configuration>
        <imageName>example</imageName>
        <dockerDirectory>docker</dockerDirectory>
        <resources>
           <resource>
             <targetPath>/</targetPath>
             <directory>${project.build.directory}</directory>
             <include>${project.build.finalName}.jar</include>
           </resource>
        </resources>
      </configuration>
    </plugin>
    ...
  </plugins>
</build>

I don't know precisely your use case, but deploying a k8's cluster in your dev machine is maybe overkill. You can test your docker images with Docker compose