{"id":4574,"date":"2023-12-11T01:01:31","date_gmt":"2023-12-11T01:01:31","guid":{"rendered":"https:\/\/www.javaadvent.com\/?p=4574"},"modified":"2023-12-09T14:07:34","modified_gmt":"2023-12-09T14:07:34","slug":"production-grade-kubernetes-for-java-developers","status":"publish","type":"post","link":"https:\/\/www.javaadvent.com\/2023\/12\/production-grade-kubernetes-for-java-developers.html","title":{"rendered":"Production-Grade Kubernetes for Java Developers"},"content":{"rendered":"

What does it mean to be a good Java Cloud Citizen? It’s definitely more than just putting an application in a container and deploying it. It is essential to consider factors such as providing real-time health status through fine-grained metrics to optimize your Java application’s performance and resilience in the cloud, . You\u2019ll also need to ensure fast startup, and avoid excessive resource consumption within the cluster.<\/span><\/p>\n

Being a good Cloud Citizen also involves streamlining configuration, deployment and upgrade processes. By integrating these tasks seamlessly, the application can facilitate smooth deployments and upgrades. This will lead to more efficiency and ease of management. This article gives a concise and opinionated overview of the Kubernetes basics from a Java developer\u2019s perspective and learn step-by-step how to get your application production ready on Kubernetes.<\/span><\/p>\n

Startup time and small footprint<\/span><\/h1>\n

Kubernetes is a highly sophisticated orchestration engine for containerized applications. Usually organizations install Kubernetes clusters across several nodes (servers). Kubernetes automatically and dynamically spreads out workloads across these different nodes for optimal usage. Typically you will want to create multiple instances\/pods of your application for high availability. When one pod gets killed, stopped, moved to a different node or what have you, your application is still up and running from your user\u2019s perspective. This is called \u201chorizontal scaling\u201d.\u00a0<\/span><\/p>\n

Because pods can stop and start relatively frequently, it is important that the applications inside those pods can start up quickly as well. The longer it takes to start up, the less flexible Kubernetes will be at scheduling its workloads and the less advantage you have of using a cloud solution. Similarly, it is important that your applications have an as small as possible footprint. This allows Kubernetes to schedule applications across nodes more flexibly. For example, if your application\u2019s resources take up 60% of your node\u2019s available capacity, Kubernetes will not be able to schedule another instance on that same node, even though 40% of its capacity goes underused. If however, your application uses 40%, it\u2019s able to spread the load to multiple instances of one or more of your applications. Only 20% of that node would go to waste. Imagine if your workloads would be even smaller. Kubernetes would have a lot more flexibility of scheduling pods, as well as increase the node\u2019s usage and efficiency.\u00a0<\/span><\/p>\n

Java<\/span><\/h3>\n

What does this mean for your Java applications? Java was (unsurprisingly) not originally built for cloud deployments. The typical deployment target for \u201ctraditional\u201d Java applications is rather large. They usually have dedicated servers with the goal to keep the applications running as long as possible. If the application needs to scale, it\u2019s usually done by adding more hardware resources to these servers (vertical scaling) instead of creating more instances (horizontal scaling). Because of this, startup time and footprint were not a top priority for Java developers. With Kubernetes however, Java has had to reinvent itself.<\/span><\/p>\n

There are several initiatives in the Java world to reduce the startup time and footprint of Java applications. There are eg. OpenJDK projects like<\/span> Leyden<\/span><\/a> and<\/span> CRaC<\/span><\/a>, or projects like<\/span> GraalVM Native Image<\/span><\/a> that compile Java applications down to very fast and compact native binaries. There are newer frameworks\/stacks like<\/span> Quarkus<\/span><\/a>,<\/span> Micronaut<\/span><\/a> and<\/span> Helidon<\/span><\/a>. These have been conceived with cloud native and kubernetes deployment targets in mind. Even the more traditional Spring (Boot) or JakartaEE have been making a lot of improvements to make applications more Kubernetes friendly.<\/span><\/p>\n

Quarkus<\/span><\/h3>\n

We\u2019ll focus in this article on Quarkus because it makes working with \u201cKube-Native\u201d Java quite a bit easier and more performant. Feel free to explore the other stacks and compare and see what makes the most sense for your project.<\/span><\/p>\n

Quarkus moves as much \u201cheavy lifting\u201d, such as classpath scanning, resolving annotations, etc to the application build time instead of during the application startup. This reduces both the startup time and the amount of memory needed. Actually, this is just the tip of the iceberg, you can read more about<\/span> Quarkus optimization for container workloads here<\/span><\/a>.<\/span><\/p>\n

Optimizing your Java application for Kubernetes is the first, but also one of the most important steps to create a production-grade, Kubernetes-native Java application. Let\u2019s now take a look at some tips and tricks to create production-grade cloud native Java workloads.<\/span><\/p>\n

Containerize your application<\/span><\/h1>\n

To deploy an application to Kubernetes, you will need to package it up as a container image first. A few years ago that meant creating or finding a Dockerfile, adding commands to copy your artifacts and dependencies, and building the container image with a docker build command. While this is still a valid way of building containers, there are now many more ways and tools to create container images, such as Podman, Jib, BuildPacks, Kaniko, Buildah, etc.<\/span><\/p>\n

While each of these tools have their advantages and challenges, you will likely use a base image which you can customize to your needs. It is important to be very conscious of where this base image comes from. There are a surprising amount of container images out in the wild. While probably not purposefully malignant, these images often contain vulnerabilities that can be exploited relatively easily. To create a production-grade container image, it is thus very important that you start from a verified\/certified base container image. Ideally one that comes from a source you trust and that you can expect to maintain the base images you\u2019re using going forward as well.<\/span> Red Hat\u2019s Universal Base Images (UBI)<\/span><\/a> are an example of base images you can use and redistribute (license free).<\/span><\/p>\n

Deploying to Kubernetes<\/span><\/h1>\n

Once you have a container image, the next step is for you (or someone else in your organization) to deploy it to Kubernetes. To build and release a production-grade application it makes sense to test your applications in an environment as similar to the production environment as possible. This will help you to get ahead of discrepancies between your local environment and production as soon as possible as well. It is however not a trivial task to learn all the ins and outs of Kubernetes and its ecosystem. Fortunately there are solutions for Java developers to be able to deploy applications to a local or remote Kubernetes instance.<\/span><\/p>\n

Quarkus for instance makes things painless through the use of a \u2018quarkus-kubernetes\u2019 extension. Adding this dependency to your project will generate Kubernetes manifests for you automatically (in an aptly named target\/kubernetes\/ folder). You can then deploy these manifests by either applying the (yaml or json) file, or calling a quarkus deploy<\/code> command. Quarkus supports remote debugging on Kubernetes out of the box as well. Even its Dev Mode can work with a Kubernetes deployment.<\/span><\/p>\n

Alternatively, projects like<\/span> JKube<\/span><\/a> are worth checking out as well to work with Kubernetes in an easy and straightforward way.\u00a0<\/span><\/p>\n

Is my application actually ready to receive requests?<\/span><\/h1>\n

A production-grade Kubernetes application needs more than just a deployment though. If you deploy a container (in a pod), a Kubernetes Service will by default start sending traffic to it as soon as the container starts. However the application inside the container might still be starting up. Even if you\u2019ve optimized your application to start up super fast, there will still be a gap of (milli)seconds where it is not available. It might for example also be establishing connections to a database or a messaging system, so requests coming are likely to fail during this startup time. Fortunately Kubernetes has a concept of \u201chealth probes\u201d that can point to an endpoint in your application where you can advertise whether your application is actually able to receive requests. There are 3 different health probes:\u00a0<\/span><\/p>\n