Precautions for multiple environments in a single OKE cluster

Let's take a closer look at the scenario where your goal is to deploy the development (dev), test and production (prod) environments, and ensure that they are exposed through different A records in the public domain (such as myapp. org).

In this architecture overview, from the perspective of Oracle Cloud Infrastructure (OCI), each environment has its own dedicated load balancer. Development, testing and production deployment use different Kubernetes services, which leads OKE to deploy a load balancer for each declared service.

Group resources using namespaces

The next challenge to be addressed is how to group resources by environment. The answer is the Kubernetes namespace. Namespaces provide a powerful way to classify and isolate various Kubernetes objects (such as Pods, services, and replication controllers) in the same cluster.

Before continuing to deploy applications and expose them through services, we will discuss how to automatically create DNS records to publish applications in the DNS domain.

Protect your namespace

In terms of security, we focus on two aspects: RBAC and network strategy. You can use Kubernetes' RBAC policy to protect administrative access to namespaces. You can also bind these roles to users in the OCIIdentity and Access Management (IAM) service to allow Kubernetes to interact directly with the OCI service. According to our deployment example, you can have a role named "Administrator", which uses the corresponding external DNS to create namespaces, and uses three different role binding configurations to grant access to each namespace. By default, pod communication between namespaces is not allowed, which enhances isolation and security. If you need to communicate across namespaces, you can configure network policies to control.

For more information, please "click to download"