In this lab, you learn how to set up a continuous delivery pipeline with Jenkins on Kubernetes engine. Jenkins is the go-to automation server used by developers who frequently integrate their code in a shared repository. The solution you build in this lab is similar to the following diagram:
In the Cloud Architecture Center, see Jenkins on Kubernetes Engine to learn more about running Jenkins on Kubernetes.
What you'll learn
In this lab, you complete the following tasks to learn about running Jenkins on Kubernetes:
Provision a Jenkins application into a Kubernetes Engine cluster
Set up your Jenkins application using Helm Package Manager
Explore the features of a Jenkins application
Create and exercise a Jenkins pipeline
Prerequisites
This is an advanced level lab. Before taking it, you should be comfortable with at least the basics of shell programming, Kubernetes, and Jenkins. Here are some labs that can get you up to speed:
Once you are prepared, scroll down to learn more about Kubernetes, Jenkins, and Continuous Delivery.
What is Kubernetes Engine?
Kubernetes Engine is Google Cloud's hosted version of Kubernetes - a powerful cluster manager and orchestration system for containers. Kubernetes is an open source project that can run on many different environments—from laptops to high-availability multi-node clusters; from virtual machines to bare metal. As mentioned before, Kubernetes apps are built on containers - these are lightweight applications bundled with all the necessary dependencies and libraries to run them. This underlying structure makes Kubernetes applications highly available, secure, and quick to deploy—an ideal framework for cloud developers.
What is Jenkins?
Jenkins is an open-source automation server that lets you flexibly orchestrate your build, test, and deployment pipelines. Jenkins allows developers to iterate quickly on projects without worrying about overhead issues that can stem from continuous delivery.
What is Continuous Delivery / Continuous Deployment?
When you need to set up a continuous delivery (CD) pipeline, deploying Jenkins on Kubernetes Engine provides important benefits over a standard VM-based deployment.
When your build process uses containers, one virtual host can run jobs on multiple operating systems. Kubernetes Engine provides ephemeral build executors—these are only utilized when builds are actively running, which leaves resources for other cluster tasks such as batch processing jobs. Another benefit of ephemeral build executors is speed—they launch in a matter of seconds.
Kubernetes Engine also comes pre-equipped with Google's global load balancer, which you can use to automate web traffic routing to your instance(s). The load balancer handles SSL termination and utilizes a global IP address that's configured with Google's backbone network—coupled with your web front, this load balancer always sets your users on the fastest possible path to an application instance.
Now that you've learned a little bit about Kubernetes, Jenkins, and how the two interact in a CD pipeline, it's time to go build one.
Setup and requirements
Before you click the Start Lab button
Read these instructions. Labs are timed and you cannot pause them. The timer, which starts when you click Start Lab, shows how long Google Cloud resources are made available to you.
This hands-on lab lets you do the lab activities in a real cloud environment, not in a simulation or demo environment. It does so by giving you new, temporary credentials you use to sign in and access Google Cloud for the duration of the lab.
To complete this lab, you need:
Access to a standard internet browser (Chrome browser recommended).
Note: Use an Incognito (recommended) or private browser window to run this lab. This prevents conflicts between your personal account and the student account, which may cause extra charges incurred to your personal account.
Time to complete the lab—remember, once you start, you cannot pause a lab.
Note: Use only the student account for this lab. If you use a different Google Cloud account, you may incur charges to that account.
How to start your lab and sign in to the Google Cloud console
Click the Start Lab button. If you need to pay for the lab, a dialog opens for you to select your payment method.
On the left is the Lab Details pane with the following:
The Open Google Cloud console button
Time remaining
The temporary credentials that you must use for this lab
Other information, if needed, to step through this lab
Click Open Google Cloud console (or right-click and select Open Link in Incognito Window if you are running the Chrome browser).
The lab spins up resources, and then opens another tab that shows the Sign in page.
Tip: Arrange the tabs in separate windows, side-by-side.
Note: If you see the Choose an account dialog, click Use Another Account.
If necessary, copy the Username below and paste it into the Sign in dialog.
{{{user_0.username | "Username"}}}
You can also find the Username in the Lab Details pane.
Click Next.
Copy the Password below and paste it into the Welcome dialog.
{{{user_0.password | "Password"}}}
You can also find the Password in the Lab Details pane.
Click Next.
Important: You must use the credentials the lab provides you. Do not use your Google Cloud account credentials.
Note: Using your own Google Cloud account for this lab may incur extra charges.
Click through the subsequent pages:
Accept the terms and conditions.
Do not add recovery options or two-factor authentication (because this is a temporary account).
Do not sign up for free trials.
After a few moments, the Google Cloud console opens in this tab.
Note: To access Google Cloud products and services, click the Navigation menu or type the service or product name in the Search field.
Activate Cloud Shell
Cloud Shell is a virtual machine that is loaded with development tools. It offers a persistent 5GB home directory and runs on the Google Cloud. Cloud Shell provides command-line access to your Google Cloud resources.
Click Activate Cloud Shell at the top of the Google Cloud console.
Click through the following windows:
Continue through the Cloud Shell information window.
Authorize Cloud Shell to use your credentials to make Google Cloud API calls.
When you are connected, you are already authenticated, and the project is set to your Project_ID, . The output contains a line that declares the Project_ID for this session:
Your Cloud Platform project in this session is set to {{{project_0.project_id | "PROJECT_ID"}}}
gcloud is the command-line tool for Google Cloud. It comes pre-installed on Cloud Shell and supports tab-completion.
(Optional) You can list the active account name with this command:
gcloud auth list
Click Authorize.
Output:
ACTIVE: *
ACCOUNT: {{{user_0.username | "ACCOUNT"}}}
To set the active account, run:
$ gcloud config set account `ACCOUNT`
(Optional) You can list the project ID with this command:
gcloud config list project
Output:
[core]
project = {{{project_0.project_id | "PROJECT_ID"}}}
Note: For full documentation of gcloud, in Google Cloud, refer to the gcloud CLI overview guide.
Task 1. Download the source code
In this task, you download the source code for this lab.
To get set up, open a new session in Cloud Shell and run the following command to set your zone :
gcloud config set compute/zone {{{project_0.default_zone}}}
Kubernetes Engine uses these credentials to access your newly provisioned cluster—confirm that you can connect to it by running the following command:
kubectl cluster-info
Task 3. Set up Helm
Helm is a package manager that makes it easy to configure and deploy Kubernetes applications. Once you install Jenkins, you can set up your CI/CD pipeline.
In this task, you use Helm to install Jenkins from the Charts repository.
Add Helm's stable chart repo:
helm repo add jenkins https://charts.jenkins.io
Ensure the repo is up to date:
helm repo update
Task 4. Install and configure Jenkins
When installing Jenkins, a values file can be used as a template to provide values that are necessary for setup.
You use a custom values file to automatically configure your Kubernetes Cloud and add the following necessary plugins:
Kubernetes:latest
Workflow-multibranch:latest
Git:latest
Configuration-as-code:latest
Google-oauth-plugin:latest
Google-source-plugin:latest
Google-storage-plugin:latest
This allows Jenkins to connect to your cluster and your Google Cloud project.
Use the Helm CLI to deploy the chart with your configuration settings:
helm install cd jenkins/jenkins -f jenkins/values.yaml --wait
This command may take a couple minutes to complete.
Click Check my progress to verify your performed task. If you have successfully configured a Jenkins chart you see an assessment score.
Configure and install Jenkins
Once that command completes ensure the Jenkins pod goes to the Running state and the container is in the READY state:
kubectl get pods
Example Output:
NAME READY STATUS RESTARTS AGE
cd-jenkins-7c786475dd-vbhg4 2/2 Running 0 1m
Configure the Jenkins service account to be able to deploy to the cluster:
Now, check that the Jenkins Service was created properly:
kubectl get svc
Example Output:
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
cd-jenkins 10.35.249.67 8080/TCP 3h
cd-jenkins-agent 10.35.248.1 50000/TCP 3h
kubernetes 10.35.240.1 443/TCP 9h
You are using the Kubernetes Plugin so that the builder nodes are automatically launched as necessary when the Jenkins master requests them. Upon completion of their work, builder nodes automatically turn down and their resources are added back to the cluster's resource pool.
Notice that this service exposes ports 8080 and 50000 for any pods that match the selector. This exposes the Jenkins web UI and builder/agent registration ports within the Kubernetes cluster. Additionally, the jenkins-ui service is exposed using a ClusterIP so that it is not accessible from outside the cluster.
Task 5. Connect to Jenkins
Retrieve the admin password and log into the Jenkins interface.
The Jenkins chart automatically creates an admin password for you. To retrieve it, run:
printf $(kubectl get secret cd-jenkins -o jsonpath="{.data.jenkins-admin-password}" | base64 --decode);echo
To get to the Jenkins user interface, in the Cloud Shell action bar, click Web Preview () Preview on port 8080:
If asked, log in with username admin and your auto-generated password.
You now have Jenkins set up in your Kubernetes cluster! Jenkins drives your automated CI/CD pipelines in the next sections.
Task 6. Understand the application
In this task, you deploy the sample application, gceme, in your continuous deployment pipeline. The application is written in the Go language and is located in the repo's sample-app directory. When you run the gceme binary on a Compute Engine instance, the app displays the instance's metadata in an info card.
The application mimics a microservice by supporting two operation modes.
In backend mode: gceme listens on port 8080 and returns Compute Engine instance metadata in JSON format.
In frontend mode: gceme queries the backend gceme service and renders the resulting JSON in the user interface.
Task 7. Deploy the application
Deploy the application into two different environments:
Production: The live site that your users access.
Canary: A smaller-capacity site that receives only a percentage of your user traffic. Use this environment to validate your software with live traffic before it's released to all your users.
In Google Cloud Shell, navigate to the sample application directory:
cd sample-app
Create the Kubernetes namespace to logically isolate the deployment:
kubectl create ns production
Create the production and canary deployments, and the services using the kubectl apply commands:
kubectl apply -f k8s/production -n production
kubectl apply -f k8s/canary -n production
kubectl apply -f k8s/services -n production
Click Check my progress to verify your performed task. If you have successfully created deployments you see an assessment score.
Create the production and canary deployments
By default, only one replica of the frontend is deployed. Use the kubectl scale command to ensure that there are at least 4 replicas running at all times.
Scale up the production environment front ends by running the following command:
kubectl scale deployment gceme-frontend-production -n production --replicas 4
Now confirm that you have 5 pods running for the frontend, 4 for production traffic and 1 for canary releases (changes to the canary release affects only 1 out of 5 (20%) of users):
kubectl get pods -n production -l app=gceme -l role=frontend
Also confirm that you have 2 pods for the backend, 1 for production and 1 for canary:
kubectl get pods -n production -l app=gceme -l role=backend
Retrieve the external IP for the production services:
kubectl get service gceme-frontend -n production
Note: It can take several minutes before you see the load balancer external IP address.
Example Output:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
gceme-frontend LoadBalancer 10.79.241.131 104.196.110.46 80/TCP 5h
Paste External IP into a browser to see the info card displayed on a card—you should get a similar page:
Now, store the frontend service load balancer IP in an environment variable for use later:
export FRONTEND_SERVICE_IP=$(kubectl get -o jsonpath="{.status.loadBalancer.ingress[0].ip}" --namespace=production services gceme-frontend)
Confirm that both services are working by opening the frontend external IP address in your browser.
Check the version output of the service by running the following command (it should read 1.0.0):
curl http://$FRONTEND_SERVICE_IP/version
You have successfully deployed the sample application! Next, you set up a pipeline to deploy your changes continuously and reliably.
Task 8. Create the Jenkins pipeline
In this task, you create the Jenkins pipeline as follows:
Create a repository to host the source code
Add credentials to give Jenkins access to the code repository
Configure Jenkins Cloud for Kubernetes
Authenticate Jenkins with the GitHub private repo
Create the Jenkins job
Create a repository to host the sample app source code
Create a copy of the gceme sample app and push it to a GitHub Repository:
In Cloud Shell, run the following commands to configure Git and GitHub:
curl -sS https://webi.sh/gh | sh
gh auth login
gh api user -q ".login"
GITHUB_USERNAME=$(gh api user -q ".login")
git config --global user.name "${GITHUB_USERNAME}"
git config --global user.email "${USER_EMAIL}"
echo ${GITHUB_USERNAME}
echo ${USER_EMAIL}
Press ENTER to accept the default options.
Read the instructions in the command output to log in to GitHub with a web browser.
When you have successfully logged in, your GitHub username appears in the output in Cloud Shell.
gh repo create default --private
You can ignore the warning as you are not billed for this repository.
git init
Initialize the sample-app directory as its own Git repository:
Configure your credentials to allow Jenkins to access the code repository. Jenkins uses your cluster's service account credentials to download code from the GitHub repository.
In the Jenkins user interface, click Manage Jenkins in the left navigation then click Security > Credentials.
Click System.
Click Global credentials (unrestricted).
Click Add Credentials in the top right corner.
Select Google Service Account from metadata from the Kind drop-down.
Under the ID field enter the Project ID and click Create.
Note: `Project ID` found in the `CONNECTION DETAILS` section of the lab.
The global credentials have been added.
Configure Jenkins Cloud for Kubernetes
In the Jenkins user interface, select Manage Jenkins > Nodes.
Click Clouds in the left navigation pane.
Click New cloud.
Type any name under Cloud name and then select Kubernetes for Type.
Click Create.
In the Jenkins URL field, enter the following value: http://cd-jenkins:8080
In the Jenkins tunnel field, enter the following value: cd-jenkins-agent:50000
Click Save.
Authenticate Jenkins with a GitHub private repo using an SSH key
To authenticate Jenkins with a GitHub private repository using an SSH key follow below steps:
a. Generate the SSH Key
Create a new GitHub SSH key, where github-email is your GitHub email address:
To download the private key(id_github) and public key(id_github.pub) from your local machine, in the Cloud Shell action bar, click More () and select the folder continuous-deployment-on-kubernetes/sample-app.
b. Add the public key to GitHub
After generating the SSH key, you need to add the public key to GitHub so Jenkins can access your repositories.
Go to your GitHub account. Click your github profile and navigate to Settings.
From the side menu, select SSH and GPG keys.
Click New SSH key.
Enter the title SSH_KEY_LAB.
Paste the contents of your public key (id_github.pub) downloaded from path (~/continuous-deployment-on-kubernetes/sample-app/id_github.pub) into the Key field. You can also add a descriptive name in the Title field.
Click Add SSH key.
c. Configure the Jenkins to use the SSH key
Go to Jenkins and select Manage Jenkins from the main dashboard.
Select the Credentials option.
Under Stores scoped to Jenkins. click System.
Click Global credentials (unrestricted).
Click Add Credentials.
In the Kind dropdown, select SSH Username with private key.
For ID enter _ssh_key.
For Username, type [your GitHub username]
Choose Enter directly for the private key and click Add. Paste the content of the id_github file (downloaded from ~/continuous-deployment-on-kubernetes/sample-app/id_github).
Click Create.
d. Add the public SSH key to known hosts
In Cloud Shell create a file named known_hosts.github and add the public SSH key to this file.
ssh-keyscan -t rsa github.com > known_hosts.github
chmod +x known_hosts.github
cat known_hosts.github
Note: If you are seeing any errors in Cloud Shell press CTRL+C and then execute the above command.
e. Configure known host key
Click Dashboard > Manage Jenkins in the left panel.
Under Security. Click Security.
Under Git Host Key Verification Configuration for Host Key Verification Strategy select Manually provided keys from drop down.
Paste the known hosts.github file content in Approved Host Keys.
Click Save.
Create the Jenkins job
Navigate to your Jenkins user interface and follow these steps to configure a Pipeline job.
Click Dashboard > New Item in the left panel.
Name the project sample-app, then choose the Multibranch Pipeline option and click OK.
On the next page, in the Branch Sources section, select Git from Add Source dropdown.
Paste the HTTPS clone URL of your sample-app repo under the Project Repository field. Replace ${GITHUB_USERNAME} with your Github username:
git@github.com:${GITHUB_USERNAME}/default.git
From the Credentials menu options, select the github credentials name.
Under the Scan Multibranch Pipeline Triggers section, check the Periodically if not otherwise run box and set the Interval value to 1 minute.
Leave all other options at their defaults and click Save.
After you complete these steps, a job named Branch indexing runs. This meta-job identifies the branches in your repository and ensures changes haven't occurred in existing branches. If you click sample-app in the top left, the master job should be seen.
Note: The first run of the master job might fail until you make a few code changes in the next step.
You have successfully created a Jenkins pipeline! Next, you create the development environment for continuous integration.
Task 9. Create the development environment
Development branches are a set of environments your developers use to test their code changes before submitting them for integration into the live site. These environments are scaled-down versions of your application, but need to be deployed using the same mechanisms as the live environment.
Create a development branch
To create a development environment from a feature branch, you can push the branch to the Git server and let Jenkins deploy your environment.
Note: If you are seeing errors in Cloud Shell, press CTRL+C and then execute the below command.
Create a development branch and push it to the Git server:
git checkout -b new-feature
Modify the pipeline definition
The Jenkinsfile that defines that pipeline is written using the Jenkins Pipeline Groovy syntax. Using a Jenkinsfile allows an entire build pipeline to be expressed in a single file that lives alongside your source code. Pipelines support powerful features like parallelization and require manual user approval.
For the pipeline to work as expected, you need to modify the Jenkinsfile to set your project ID.
Open the Jenkinsfile in your terminal editor, for example vi:
vi Jenkinsfile
Start the editor:
i
Add your PROJECT_ID to the REPLACE_WITH_YOUR_PROJECT_ID value. (Your PROJECT_ID is your Project ID found in the CONNECTION DETAILS section of the lab. You can also run gcloud config get-value project to find it.
Change the value of CLUSTER_ZONE to . You can get this value by running gcloud config get compute/zone.
This starts a build of your development environment.
After the change is pushed to the Git repository, navigate to the Jenkins user interface where you can see that your build started for the new-feature branch. It can take up to a minute for the changes to be picked up.
After the build is running, click the down arrow next to the build in the left navigation and select Console output:
Track the output of the build for a few minutes and watch for the kubectl --namespace=new-feature apply... messages to begin. Your new-feature branch is now deployed to your cluster.
Note: In a development scenario, you wouldn't use a public-facing load balancer. To help secure your application, you can use kubectl proxy. The proxy authenticates itself with the Kubernetes API and proxies requests from your local machine to the service in the cluster without exposing your service to the Internet.
If you didn't see anything in Build Executor, don't worry. Just go to the Jenkins homepage > sample app. Verify that the new-feature pipeline has been created.
Once that's all taken care of, start the proxy in the background:
kubectl proxy &
If it stalls, press CTRL+C to exit. Verify that your application is accessible by sending a request to localhost and letting kubectl proxy forward it to your service:
You should see it respond with 2.0.0, which is the version that is now running.
If you receive a similar error:
{
"kind": "Status",
"apiVersion": "v1",
"metadata": {
},
"status": "Failure",
"message": "no endpoints available for service \"gceme-frontend:80\"",
"reason": "ServiceUnavailable",
"code": 503
It means your frontend endpoint hasn't propagated yet—wait a little bit and try the curl command again. Move on when you get the following output:
2.0.0
You have set up the development environment! Next, build on what you learned in the previous module by deploying a canary release to test out a new feature.
Click Check my progress to verify your performed task. If you have successfully started the build for the new-feature branch, you see an assessment score.
Build for the new-feature branch
Task 11. Deploy a canary release
You have verified that your app is running the latest code in the development environment, so now deploy that code to the canary environment.
Create a canary branch and push it to the Git server:
git checkout -b canary
git push origin canary
In Jenkins, you should see the canary pipeline has kicked off. Once complete, you can check the service URL to ensure your new version is serving some some of the traffic. You should see about 1 in 5 requests (in no particular order) returning version 2.0.0:
export FRONTEND_SERVICE_IP=$(kubectl get -o \
jsonpath="{.status.loadBalancer.ingress[0].ip}" --namespace=production services gceme-frontend)
while true; do curl http://$FRONTEND_SERVICE_IP/version; sleep 1; done
If you keep seeing 1.0.0, try running the above commands again. Once you've verified that the above works, end the command with CTRL+C.
That's it! You have deployed a canary release. Next you deploy the new version to production.
Click Check my progress to verify your performed task. If you have successfully deployed the canary release, you see an assessment score.
Deploying a canary release
Task 12. Deploy to production
Now that our canary release was successful and we haven't heard any customer complaints, deploy to the rest of your production fleet.
Create a canary branch and push it to the Git server:
In Jenkins, you should see the master pipeline has kicked off.
Click Check my progress to verify your performed task. If you have successfully started the master pipeline, you see an assessment score.
Deploying to production
Once complete (which may take a few minutes), you can check the service URL to ensure your new version, 2.0.0 is serving all of the traffic.
export FRONTEND_SERVICE_IP=$(kubectl get -o \
jsonpath="{.status.loadBalancer.ingress[0].ip}" --namespace=production services gceme-frontend)
while true; do curl http://$FRONTEND_SERVICE_IP/version; sleep 1; done
Once again, if you see instances of 1.0.0 try running the above commands again. To stop this command press CTRL+C.
Example output:
gcpstaging9854_student@qwiklabs-gcp-df93aba9e6ea114a:~/continuous-deployment-on-kubernetes/sample-app$ while true; do curl http://$FRONTEND_SERVICE_IP/version; sleep 1; done
2.0.0
2.0.0
2.0.0
2.0.0
2.0.0
2.0.0
^C
You can also navigate to site on which the gceme application displays the info cards. The card color changed from blue to orange.
Here's the command again to get the external IP address. Paste the External IP into a new tab to see the info card displayed:
kubectl get service gceme-frontend -n production
Example output:
Task 13. Test your understanding
Below are multiple-choice questions to reinforce your understanding of this lab's concepts. Answer them to the best of your abilities.
You're done!
Awesome job, you have successfully deployed your application to production!
Congratulations!
This concludes this hands-on lab deploying and working with Jenkins in Kubernetes Engine to enable a Continuous Delivery / Continuous Deployment pipeline. You've had the opportunity to deploy a significant DevOps tool in Kubernetes Engine and configure it for production use. You've worked with the kubectl command-line tool and deployment configurations in YAML files, and have learned a bit about setting up Jenkins pipelines for a development / deployment process. With this practical hands-on experience you should feel comfortable applying these tools in your own DevOps shop.
...helps you make the most of Google Cloud technologies. Our classes include technical skills and best practices to help you get up to speed quickly and continue your learning journey. We offer fundamental to advanced level training, with on-demand, live, and virtual options to suit your busy schedule. Certifications help you validate and prove your skill and expertise in Google Cloud technologies.
Manual Last Updated June 10, 2025
Lab Last Tested June 10, 2025
Copyright 2025 Google LLC. All rights reserved. Google and the Google logo are trademarks of Google LLC. All other company and product names may be trademarks of the respective companies with which they are associated.
Moduły tworzą projekt Google Cloud i zasoby na określony czas.
Moduły mają ograniczenie czasowe i nie mają funkcji wstrzymywania. Jeśli zakończysz moduł, musisz go zacząć od początku.
Aby rozpocząć, w lewym górnym rogu ekranu kliknij Rozpocznij moduł.
Użyj przeglądania prywatnego
Skopiuj podaną nazwę użytkownika i hasło do modułu.
Kliknij Otwórz konsolę w trybie prywatnym.
Zaloguj się w konsoli
Zaloguj się z użyciem danych logowania do modułu. Użycie innych danych logowania może spowodować błędy lub naliczanie opłat.
Zaakceptuj warunki i pomiń stronę zasobów przywracania.
Nie klikaj Zakończ moduł, chyba że właśnie został przez Ciebie zakończony lub chcesz go uruchomić ponownie, ponieważ spowoduje to usunięcie wyników i projektu.
Ta treść jest obecnie niedostępna
Kiedy dostępność się zmieni, wyślemy Ci e-maila z powiadomieniem
Świetnie
Kiedy dostępność się zmieni, skontaktujemy się z Tobą e-mailem
Jeden moduł, a potem drugi
Potwierdź, aby zakończyć wszystkie istniejące moduły i rozpocząć ten
Aby uruchomić moduł, użyj przeglądania prywatnego
Uruchom ten moduł w oknie incognito lub przeglądania prywatnego. Dzięki temu unikniesz konfliktu między swoim kontem osobistym a kontem do nauki, co mogłoby spowodować naliczanie dodatkowych opłat na koncie osobistym.
In this lab you will deploy and completely configure a continuous delivery pipeline using Jenkins running on Kubernetes Engine and go through the dev - deploy process.
Czas trwania:
Konfiguracja: 0 min
·
Dostęp na 75 min
·
Ukończono w 75 min