Cloud Native Computing Foundation Kubernetes Community Days Bangalore 2022, 11 May 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Introduction To Hierarchical Namespaces in Kubernetes

Description

Namespaces are a great way to achieve soft multi-tenancy in Kubernetes, but fall short of many use cases from the practical world. Hierarchical Namespaces was born out of these needs and is a kubernetes-sigs project. In this talk we will look at some practical examples and how HNC(Hierarchical Namespace Controller) helps in achieving those goals with some samples and demos. Some of real world examples we will talk about:
1. How to organise smaller teams within an umbrella organisation needing similar accesses & policies
2. How to achieve governance through policies which are global, but also applicable for a set of teams etc.
3. Enable teams to create namespaces as needed without needing central admin teams to help them or without giving higher level of access.
4. How to limit the resources and exclude namespaces from HNC (which may be required in big multi-tenant clusters)

A

Hey folks welcome to kcd bengaluru. My name is rahul, and today I will be talking about hierarchical namespaces in kubernetes a bit about me. uh I work as a software engineer at infra cloud technologies, where I work mainly on go kubernetes operators and below is my twitter handle uh before we start. uh This is the agenda that we are going to talk about, we'll start with name spaces in kubernetes uh it's pros and cons. Then we will talk about hierarchical namespaces.

A

Then we will look into hierarchical, namespace controller and then finally, we will uh perform some demo. So before we start, uh we start looking into hierarchical namespaces. uh Let's first see uh the actual problem that it is trying to solve now imagine being a developer in an organization uh where you have large multi-tenant kubernetes clusters up and running you and your team are confined to work within a set of resources.

A

For example, name spaces provided to you by your cluster administrator teams, generally work best if they can operate autonomously, but since name space creation is a highly privileged task. It's unlikely that any member of development team is allowed to create a new namespace.

A

So now this means that whenever a team wants a new namespace, they must raise a ticket to the cluster administrator, and this may cause a delay in the development cycles.

A

Here I have created a new user name as dev user, and I am into dev user context.

A

This user does not have sufficient permissions us to create a new namespace.

A

So if I now try to create a new namespace say teamdb db, it throws an error, so the team or any user, is now not allowed to create a new namespace and has to go through complete administrative process to you know, uh get a new name space created by the cluster administrator.

A

uh Now, let's talk about uh namespaces in kubernetes mod, so, as you all know, modern applications are increasingly adopting the principle of micro service based architecture in their design and development phases. An application is broken down into a number of smaller modules or services and are often developed and owned by you know different teams altogether.

A

In effect, this approach introduces the need for micro modularity, where in logical and isolated units of resources are created for microservices to be deployed in a namespace in kubernetes is a natural choice to provide the needed resource isolation and hence it is widely used to deploy a micro service based architecture on kubernetes clusters, so name spaces have two key properties.

A

The first is they are used to represent ownership, so most kubernetes objects such as spots deployments, must be in a namespace. So if you use namespace to represent ownership, you can always count on there being an owner.

A

Secondly, as I previously talked about, namespaces have authorized creation menus. Only high privileged users can create namespaces and other users. Let's say developers require explicit permissions to use those namespaces. However, sometimes namespaces are not flexible enough to you know, meet some common use cases. uh For example, let's say that one team owns several micro services.

A

Ideally, ideally, they should place these micro services into different name spaces uh in order to isolate them from each other. You know, but this presents two problems. uh Firstly, these namespaces have no common concept of concept of ownership, uh even though they are, they are both owned by the same team right. This means that if the team controls multiple namespaces, not only does kubernetes not have any record of common owner, but names namespace scope policies uh cannot be applied uniformly across them.

A

For example, let's say if I want to apply a network policy to all the name spaces that a team owns. I have to apply manually one by one right and secondly, as I said, develop development teams cannot create namespaces on their own, hence with the proliferation of kubernetes as units of uh resource and identity. Isolation for micro services to be deployed in a mechanism is needed to simplify their management.

A

This is where uh hierarchical namespaces uh comes into play, so hierarchical namespaces are a new concept uh developed developed by the uh kubernetes working group, uh uh sick multi-tenancy, uh in order to solve uh the problems that I mentioned uh before uh so in its simplest form, a hierarchical namespace is a regular kubernetes namespace that contains a small custom resource that identifies a single option: parent maintenance.

A

So this now establishes the concept of ownership across namespaces, not just within them. So basically hierarchical namespaces uh allows users to you, know organize namespaces into trees uh and apply policies to an entire tree or a subtree.

A

A policy object uh applied in the root mean space or apparent namespace of a tree or a subtree is replicated and applied to the old child name species automatically.

A

uh It also introduces the concept of a sub namespace as a child of another ministries, with its life cycle bound to that of its parent. So now, instead of cluster level functions, users would only need narrow permissions in the parent nations to create sub namespaces.

A

Any namespace that isn't a sub name space is a full name space, which is nothing but traditional kubernetes, uh so creating full name. Spaces uh requires, as I previously said, it requires cluster level privileges right and that need to be closely guarded by the registered administrator to allow individual teams uh some flexibility to create their own name. Spaces uh deploy workloads in that main business. The subname space feature can be utilized, creating some name.

A

Space only requires a relatively narrow set of privileges that can be given to individual teams in an organization so uh coming to the hierarchical namespace controller, um hierarchical nps controller. uh Basically, hnc is a kubernetes controller that manages these hierarchical namespaces, uh so hnc mainly uh uh reconciles three type of uh threes. uh The first is agency configuration.

A

The second is hierarchy configuration and the third is subminister cycle, so uh this is the hnc configuration. uh This is a single. You know non-namespaced object, which is named as config.

A

You know it defines the behavior of the entire question. It should be modifiable only by the customer administrators. It basically contains information about what kubernetes objects we want to propagate down. The hierarchy by default. uh Hnc enforces roles and role. Bindings are back resources to appropriate mode by default, so this basically means that uh all the roles and role bindings that are present in the parent matrix will automatically be provided or copied to the in the child name spaces to propagate any other, kubernetes objects or resources down the hierarchy.

A

We need to update the spec of agency configuration object, so, as you see in this example, I have edited the spec of agency configuration to increa to propagate network policies uh down the hierarchy, so this means that any network policy that I now apply to the uh in the parent namespace will also be copied to each style name because of that parent namespace.

A

The second is a hierarchy configuration so uh there's either zero or one of these present in each name space. With the name hierarchy I mean, if it is, if it exists, uh this object mainly defines the child parent relationship between namespaces.

A

So, as you can see here for the namespace ipof c1, its parent is slice agency 3 and its children's are hyperc1 childhood.

A

The third is sub name space anchor. These are uh used to create the actual subname species we discussed earlier right. So, generally speaking, access to create or read these objects should be granted quite freely to users uh to have permissions to use these objects in a given namespace, since this allows them to use hierarchical namespaces to organize. uh You know their objects.

A

Note that the subname space anchor for a children in space is present in its parent line space.

A

Yes, so let's now quickly, look at some hands-on demo, so the hierarchical namespaces are provided by a kubernetes controller, which is known as a hierarchical, namespace, controller or hnc. The so basically, hnc consists of two components. uh The first is a manager that runs on your cluster. It manages sub name spaces propagate policy objects.

A

The second is the cube kernel plugin, which is known as cubecat hns, which makes it easy for users to interact with the manager, so I have already installed the both of them. So if you see.

A

An hnc system instance the manager is installed, and I've also installed the cubicle, a plug-in keypad hms.

A

So, let's now uh move to this developer context,.

A

So this eventually so this represents the uh developer. uh So if I try, if I now try to create a new namespace, let's say team db, uh I'm sorry cr.

A

As you can see, the developer user is not allowed to create a name first. So what I have done over here is: I have created a new role for this developer and I have given sufficient permission for it to interact with the hnc crds, and I also created the corresponding role binding.

A

Okay and I've already applied it. So if I now try to create a new submarine space, let's say: khms create hvc one team, a team, a under the parent name, space development.

A

So it says that svct may submit space anchor is created successfully in the paradigm. So if I do khms 3.

A

So you can see under development namespace uh the sub name, space, svc team- a is also created right, so, as I described earlier, by default, hnc provides role and role bindings under the propagate mode right. So this means that whatever rules and role bindings are present in the development instance or apparent in space, which is development namespace over here, those will be propagated to all the child namespaces. So if I do k get roles.

A

Minus in development uh demo role is present in the development namespace, which should also be now present in the svc one team, a name so.

A

Right so this is also present over here. So let's say now: uh if I want to propagate uh network policies also down there right. So let's uh move to the mini, cube context and hmc configuration.

A

To add more uh objects that you want to propagate down the hierarchy. You must edit this agency configuration, which is uh a cluster scope. I mean only present once.

A

So, as you can see here, I have already edited the uh hnc configuration uh to basically propagate network policies uh down to each child name spaces right so.

A

If I now apply network policy to the development links, so this is the network policy I'm going to apply in the development namespace, so okay apply iphone x, dev user network in development links.

A

So again, as you can see, uh it is created. uh So if I now do k get fall, minus n development namespace it is created, so this network policy now should also be present in the child image that is svc team a so. If I do this, as you can see, it is also present in the child namespace. So if I now do k describe this network policy network.

A

A

So the hnc controller also adds uh some labels over the propagated objects. So, as you can see, it has added inherited from label uh from the development namespace, which is the present namespace, which is apparently this right.

A

So you can also I mean, perform many tasks using hierarchical, namespaces.

A

Yes, so that is what all all that is what I have for the hierarchical namespaces. In the end, uh I would like to thank adrian, uh who is the team lead and who created this project known as hierarchical namespace, for helping me and reviewing the content for this presentation.

A

You can also follow the hierarchical link, space project under kubernetes 6 and maybe try to contribute it. Thank you.