Shulou(Shulou.com)06/01 Report--

This article introduces the knowledge of "detailed explanation of Kubernetes Namespace". Many people will encounter such a dilemma in the operation of actual cases, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Jieshao

Kubernetes clusters can manage a large number of unrelated workloads at the same time, while organizations often choose to deploy projects created by different teams to a shared cluster. As the number increases, deployment objects often quickly become difficult to manage, slow down the response of operations, and increase the probability of dangerous errors.

Kubernetes uses the concept of namespaces to help solve the complexity of managing objects in a cluster. Namespaces allow objects to be grouped together, making it easy to filter and control them as a unit. Whether it's applying custom access control policies or separating all components for the test environment, namespaces are a powerful and flexible concept of dealing with objects as groups.

In this article, we discuss how namespaces work, introduce some common examples, and share how to use namespaces to manage Kubernetes objects. Finally, we will introduce a Rancher feature called projects (project) to see how it builds and extends the concept of namespaces.

What is a namespace and why is it important?

Namespaces (namespace) are the organizational mechanisms provided by Kubernetes to classify, filter, and manage any group of objects in a cluster. Each workload added to the Kubernetes cluster must be placed in a namespace.

Namespaces give scope to object names in the cluster. Although the name must be unique in the namespace, the same name can be used in different namespaces. This can be very helpful in some scenarios. For example, if you use namespaces to divide application lifecycle environments (such as development, staging, production), you can maintain copies of the same objects with the same name in each environment.

Namespaces also allow users to easily apply policies to specific parts of the cluster. You can control the use of resources by defining ResourceQuota objects that set limits on the use of resources on a per-namespace basis. Similarly, when using CNI (Container Network Interface) that supports network policy on the cluster, such as Calico or Canal (calico for policy, flannel for network). You can apply NetworkPolicy to namespaces, where rules define how pod communicate with each other. Different namespaces can have different strategies.

One of the biggest benefits of using namespaces is the ability to take advantage of Kubernetes RBAC (role-based access control). RBAC allows you to develop roles under a single name, thus grouping lists of permissions or features. ClusterRole objects are used to define usage patterns for cluster size, while role object types (Role object type) are applied to specific namespaces to provide better control and granularity. After the role is created, RoleBinding can grant defined functionality to specific users or groups of users in the context of a single namespace. In this way, namespaces enable cluster operators to map the same policy to an organized collection of resources.

Common namespace usage patterns

Namespaces are a very flexible feature that does not force the use of specific structures or organizational patterns. However, there are still many patterns that are commonly used within the team.

Map namespaces to a team or project

It is a convention when setting up namespaces to create a namespace for each individual project or team. This fits well with many of the namespace features we mentioned earlier.

By providing a dedicated namespace to your team, you can delegate certain functions with RBAC policies to achieve self-management and automation. For example, adding or removing members from a RoleBinding object in a namespace is an easy way to access team resources. In addition, it is also useful to set resource quotas for teams and projects. In this way, you can reasonably access resources according to your organization's business needs and priorities.

Use namespaces to partition the lifecycle environment

Namespaces are ideal for dividing development, staging, and production environments in a cluster. Typically, we are advised to deploy production workloads to a completely separate cluster to ensure maximum isolation. But for smaller teams and projects, namespaces can be a viable solution.

As with the previous use cases, network policies, RBAC policies, and quotas are important factors in implementing use cases. When managing the environment, it is necessary to control the ability to communicate with components by isolating the network. Similarly, the namespace-scoped RBAC policy allows operators to set strict permissions for production. Quotas ensure access to important resources in the most sensitive environment.

The ability to reuse object names is helpful here. When you test and publish objects, you can put them in a new environment while preserving their namespaces. In this way, the confusion caused by similar objects in the environment can be avoided and the cognitive overhead can be reduced.

Use namespaces to isolate different consumers

Another use case that namespaces can solve is to segment the workload according to the consumer. For example, if your cluster provides infrastructure for multiple customers, segmenting by namespace enables you to manage each customer while tracking the whereabouts of the bill.

In addition, the features of namespaces allow you to control the network and access policies and define different quotas for your users. In a general case, namespaces allow you to develop and deploy different instances of the same templated environment for each user. This consistency can greatly simplify the process of management and troubleshooting.

Understand preconfigured Kubernetes namespaces

Before we start creating namespaces, let's discuss how Kubernetes sets it automatically. By default, there are three namespaces on the new cluster:

Default: add an object to the cluster without providing a namespace so that it is placed in the default namespace. Until an alternative namespace is created, the namespace acts as the primary destination for the user's newly added resources and cannot be deleted.

The purpose of the kube-public:kube-public namespace is to make all users with or without authentication globally readable. This is useful for exposing the cluster information required by bootstrap components. It is mainly managed by Kubernetes itself.

The kube-system:kube-system namespace is used for Kubernetes-managed Kubernetes components, and the general rule is to avoid adding normal workloads to the namespace. It is generally managed directly by the system, so it has a relatively loose policy.

Although these namespaces effectively isolate user workloads from system-managed workloads, they do not force the use of any additional structures to classify and manage applications. More amicably, it is easy to create and use additional namespaces

Use namespaces

Using kubectl to manage namespaces and the resources they contain is fairly simple. In this section, we will demonstrate some of the most common namespace operations so that you can start dividing resources effectively.

View existing namespaces

To display all the namespaces available in the cluster, use the kubectl get namespaces command:

This command shows all available namespaces, whether they are active or not. There is also the duration of the resource (age).

For more detailed information, use the kubectl describe command:

Name: default Labels: field.cattle.io/projectId=p-cmn9g Annotations: cattle.io/status= {"Conditions": [{"Type": "ResourceQuotaInit", "Status": "True", "Message": "", "LastUpdateTime": "2018-12-17T23:17:48Z"}, {"Type": "InitialRolesPopulated", "Status": "True", "Message": "", "LastUpda..." Field.cattle.io/projectId=c-7tf7d:p-cmn9g lifecycle.cattle.io/create.namespace-auth=trueStatus: ActiveNo resource quota.No resource limits.

This command displays the labels and comments associated with the namespace, as well as any quotas or resource restrictions that have been applied.

Create a namespace

We use the kubectl create namespace command to create namespaces. Use the name of the namespace as the argument to the command.

You can also use manifest to create namespaces through files. For example, the following file defines our exact namespace as above.

Assume that the above specification is saved in the demo-namespace.yml file. You can enter instructions to use it:

No matter which method we use to create namespaces, when we examine the available namespaces again, we should be able to list the new namespaces (we use the abbreviation for ns-- namespaces and query for the second time):

Our newly created namespace has become available.

Filter and perform actions based on namespace

If we deploy a workload object to the cluster without specifying a namespace, it will be added to the default namespace:

We can use kubectl to verify that the deployment is created in the default namespace:

If we try to create the deployment with the same name again, we will get a namespace conflict error.

To apply the operation to different namespaces, we must include the option-namespace= in the command. Let's create a deployment with the same name on the demo-namespace namespace:

This deployment was successful, although we still used the same deployment name. Namespaces provide different scopes for resource names, avoiding the naming conflicts experienced earlier.

If you want to see the details of the new deployment, we use the-namespace= option again to specify the namespace:

This means that we have created another deployment called demo-nginx in the demo-namespace namespace.

Select a namespace by setting Context

If you want to avoid providing the same namespace for each command, you can change the default namespace of the command by configuring kubectl's context. This modifies the namespace to which the operation is applied when the context is active.

To list the details of context configuration, enter:

The figure above shows that we use a context,context named Default that does not specify a namespace, so the default namespace is used.

To change the namespace used by the context to demo-context, we type:

We can view the context configuration here to verify that demo-namespace is currently selected:

Verify that our kubectl describe command now defaults to demo-namespace, which requests our demo-nginx deployment without specifying a namespace:

Delete namespaces and clean up

If we don't need a namespace, we can delete it.

Deleting a namespace is very powerful because it not only deletes the namespace, but also cleans up all resources deployed in it. This function is very convenient, but at the same time, if you are not careful, it can be very dangerous.

Before deleting, it is best to list the resources related to the namespace and determine the objects you want to delete:

Once you have determined the scope of the action, you can delete the demo-namespace namespace and all resources in it by entering the following command:

Namespaces and their resources will be deleted from the cluster

If you previously changed the selected namespace in the kubectl context, type the following command to clear the selected namespace:

When cleaning up demo resources, remember to delete the original demo-nginx deployment that we originally provided to the default namespace:

Your cluster should be in its initial state by now.

Use Rancher's Project to extend the namespace

If you use Rancher to manage Kubernetes clusters, you can use the extensions provided by the projects feature. Project in Rancher is an additional organization layer that binds multiple namespaces together.

Rancher's project overrides a control structure on the namespace, allowing you to divide the namespace into logical units and apply policies to it. Project reflects namespaces in most cases, but it serves as a container for namespaces rather than as a separate workload resource. Each namespace in the Rancher exists in only one project, and the namespace inherits all the policies applied to the project.

By default, the Rancher cluster defines two project:

Default: this project contains the default namespace

System: this project contains all other preconfigured namespaces, including kube-public, kube-system, and all namespaces provided by the system

After selecting a cluster, you can view the items available in the cluster by visiting the Projects/Namespaces tab:

Here, click the Add Project button to add the project. When you create a new project, you can configure project members and their access rights, as well as security policies and resource quotas.

You can also click project's Add Namespace button to add namespaces to existing projects. If you want to move the namespace to a different project, select the namespace first and click the Move button. The switch that moves the namespace to the new project immediately modifies the permissions and policies applied to that namespace.

Instead of introducing a new organizational model, Rancher's project simply applies the same abstraction to namespaces, which act on workload objects. If you like to use namespaces, but need additional control layers, then they can fill this gap.

That's all for the detailed introduction of Kubernetes Namespace. Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.