An application generally goes through the development, joint debugging, and testing stages before it is launched. In this process, the workloads deployed in each environment (stage) are the same, but are logically defined. There are two ways to define them:
Resources cannot be shared among different clusters. In addition, services in different environments can access each other only through load balancing.
Workloads in the same namespace can be mutually accessed by using the Service name. Cross-namespace access can be implemented by using the Service name or namespace name.
The following figure shows namespaces created for the development, joint debugging, and testing environments, respectively.
You are advised to use this method if a large number of workloads are deployed in the same environment. For example, in the following figure, different namespaces (APP1 and APP2) are created to logically manage workloads as different groups. Workloads in the same namespace access each other using the Service name, and workloads in different namespaces access each other using the Service name or namespace name.
For example, the key is project and the value is cicd, indicating that the namespace is used to deploy CICD.
After node affinity is enabled in a namespace, the workloads newly created in the namespace can be scheduled only to nodes with specific labels. For details, see PodNodeSelector.
After node affinity is enabled, new workloads in the current namespace will be scheduled only to nodes with specified labels. For example, in namespace test, the workloads in the namespace can be scheduled only to the node whose label key is kubelet.kubernetes.io/namespace and label value is test.
If a namespace is deleted, all resources (such as workloads, jobs, and ConfigMaps) in this namespace will also be deleted. Exercise caution when deleting a namespace.
Follow the prompts to delete the namespace. The default namespaces cannot be deleted.