Back to 2b site

Managing GitFlow Environments Using K8s— Network Edition

Using Kubernetes to Simplify the Process

To manage an environment using Kubernetes, it is necessary to use objects which enable the mission to be part of the engine. In the example, below, we will be using the Namespace, Service, and ConfigMap (as a helper) objects.


On Kubernetes, a Service is an abstract way to expose an application running on a set of Pods as a network service. For this example, let’s say we have service A, called “my-rest” (a RESTful web service), and service B, called “some-service.” We will call “my-rest” Service’s route “/get-customer-permissions,” meaning “some-service” Pods can curl the following URL: http://my-rest/get-customer-permissions. Within a Kubernetes environment, it is possible to use an unsecured call within the namespace scope.


The Kubernetes Namespace is a logic scope that collects most of the objects. In addition, we can use the name of the namespace as part of an FQDN continuing with the Service address mentioned above, we will be able to use the following URL: http://<NAMESPACE_NAME>.my-rest/get-customer-permissions).


The ConfigMap is often used as a helper for configuration challenges. For dynamic environment management, we will create a ConfigMap containing the external DNS info, and mount it into Kubernetes Pod, as a file or an environment variable, and retrieve that info from the app layer in a more manageable way.

Putting it all Together

In the context of environment-management, we now understand that we can deploy multiple services into a namespace using their particular branch names. Also, we now know that the namespace and the service objects can be DNS-resolved. Furthermore, we can use the ConfigMap object to simplify our challenges and to obtain resource information we saved as a part of the CI/CD process.

Managing GitFlow Environments Using K8s

Managing GitFlow Environments Using K8s

Bonus: Creating a Feature-Branched Environment

Consider this situation: We’ve created and deployed the microservices mentioned above, but now we want to change one of our microservices into a separate branch/namespace. Let’s say that the microservice was deployed under the namespace “develop”. We want to change a single microservice, but we don’t want to duplicate and redeploy unchanged microservices on other namespaces — we want to reuse them transparently and efficiently, without wasting resources such as CPU, memory or storage.