Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
The DevOps 2.4 Toolkit

You're reading from   The DevOps 2.4 Toolkit Continuous Deployment to Kubernetes: Continuously deploying applications with Jenkins to a Kubernetes cluster

Arrow left icon
Product type Paperback
Published in Nov 2019
Publisher Packt
ISBN-13 9781838643546
Length 398 pages
Edition 1st Edition
Tools
Concepts
Arrow right icon
Author (1):
Arrow left icon
Viktor Farcic Viktor Farcic
Author Profile Icon Viktor Farcic
Viktor Farcic
Arrow right icon
View More author details
Toc

Table of Contents (12) Chapters Close

1. Deploying Stateful Applications at Scale FREE CHAPTER 2. Enabling Process Communication with Kube API Through Service Accounts 3. Defining Continuous Deployment 4. Packaging Kubernetes Applications 5. Distributing Kubernetes Applications 6. Installing and Setting Up Jenkins 7. Creating a Continuous Deployment Pipeline with Jenkins 8. Continuous Delivery with Jenkins and GitOps 9. Now It Is Your Turn 10. Other Books You May Enjoy Appendix A: Installing kubectl and Creating a Cluster with minikube 1. Appendix B: Using Kubernetes Operations (kops)

Running builds in different Namespaces

One of the significant disadvantages of the script we used inside my-k8s-job is that it runs in the same Namespace as Jenkins. We should separate builds from Jenkins and thus ensure that they do not affect its stability.

We can create a system where each application has two namespaces; one for testing and the other for production. We can define quotas, limitations, and other things we are used to defining on the Namespace level. As a result, we can guarantee that testing an application will not affect the production release. With Namespaces we can separate one set of applications from another. At the same time, we'll reduce the chance that one team will accidentally mess up with the applications of the other. Our end-goal is to be secure without limiting our teams. By giving them freedom in their own Namespace, we can be secure without...

lock icon The rest of the chapter is locked
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $19.99/month. Cancel anytime
Banner background image