Deploy and Update an NGINX Microservice

Introduction

You have reached the final challenge in this beginner course. Earlier labs guided you through Pods, Deployments, Services, scaling, troubleshooting, and rollback. Now you will combine those ideas in one small release task without a command-by-command walkthrough.

The environment contains a healthy starter release named web-app. Your job is to publish its next pinned NGINX image while preserving three available replicas and the stable Service. The final cluster state and the saved manifest must agree, so the release remains reproducible after the challenge.

Release the Next NGINX Version

Environment startup: This lab starts a complete Kubernetes cluster for you. Configuring its control plane, node, and networking components usually takes 2–3 minutes. Please wait patiently for the environment to finish loading before beginning the challenge.

Current Situation

The platform team has prepared a starter release in /home/labex/project/final-release/web-app.yaml. It currently runs nginx:1.26-alpine as three replicas behind Service web-app.

Scope

• Work with the existing web-app Deployment, Service, manifest, and release-check client.
• Do not rename resources, change selectors, or replace the approved rolling update budget.
• Use the pinned target image; floating tags such as latest are outside the accepted release.

Your Goal

Publish nginx:1.27-alpine through the existing Deployment and leave the live cluster, Service access path, and saved manifest in one healthy and reproducible state.

Acceptance Criteria

• Deployment web-app uses exactly three desired replicas.
• Its nginx container uses the pinned image nginx:1.27-alpine.
• Its rolling update budget remains maxUnavailable: 0 and maxSurge: 1.
• The change-cause annotation describes the NGINX 1.27 release.
• Service web-app still selects the Deployment's Pods and has three ready backends.
• All three updated replicas are ready and available, and an in-cluster HTTP request to http://web-app succeeds.
• /home/labex/project/final-release/web-app.yaml contains the final image and rollout settings, so applying it again would preserve the accepted state.

Use Kubernetes inspection and rollout commands to decide when the release is complete. If an update is still progressing, wait for it rather than judging only the first kubectl get output.

Hints

Useful observations include the Deployment's READY, UP-TO-DATE, and AVAILABLE columns; Pod images; rollout history; and the Service's EndpointSlice addresses.

Summary

You completed the course by independently releasing a pinned NGINX image through a Kubernetes Deployment. You preserved an explicit availability budget, waited for all updated replicas, kept the Service connected to three ready backends, verified an in-cluster request, and persisted the accepted state in YAML.

Those checks form a reusable beginner workflow: declare the desired state, apply it, observe controller progress, verify the workload and its access path, and keep the manifest synchronized with the cluster.