Using Namespaces

Namespaces
Organizing Kubernetes

Kubernetes Namespaces are designed to assist the administration of Kubernetes clusters by organizing resources. By providing a scope for names, Namespaces make it possible for you as administrator of the fabric to divide resources amongst users.

Step 1 - Remove mylabapp

As the first step we are going to remove what we have done already. Using the command kubectl delete we can remove the service and pods we have created. This is a great place to start seeing the power of the declarative model. With a single command you can create the deployment. With the same simplicity you can remove it. Since these don't have a need for persistency in storage, then creating and deleting them is simple. You are thinking, what happens if I need the container to save data? The answer is the same. You don't keep persistent data in containers, you keep them elsewhere. And when you delete deployments in kubernetes clusters, you can restore them to the exact same state because they would look for the data in their persistent volume claims.


kubectl delete deployment mylabapp
kubectl delete service mylabapp

You can validate that we have removed the service and pods with the command:


kubectl get svc,pods -o wide

That will output the single fabric wide service.

NAME             TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE       SELECTOR
svc/kubernetes   ClusterIP   10.96.0.1    [none]        443/TCP   5d        [none]

Step 2 - Create Namespace


kubectl create namespace mylabapp

To list all the namespaces in the cluster you can use the command kubectl get namespaces. That will have a set of default namespaces, one that we have been using already; default.

    
        kubectl get namespaces
    
    
NAME                    STATUS   AGE
aci-containers-system   Active   18h
default                 Active   18h
kube-node-lease         Active   18h
kube-public             Active   18h
kube-system             Active   18h
mylabapp                Active   4s

Step 3 - Deployments in a Namespace

You can now deploy the same application deployment we have done in the previous exercise inside the Namespace. You can specify any deployment file inside of a YAML definition file or you can from the CLI. The kubectl command can take the --namespace attribute. For this lab we will overwrite the previous deployment file with the namespace defined.


kubectl create -f ~/mylabapp-deployment.yaml --namespace mylabapp
kubectl create -f ~/mylabapp-service.yaml --namespace mylabapp

Now the deployment is operating inside of the namespace we have defined. To view kubectl related output for this deployment you now have to specific the --namespace.


kubectl get deployment -o wide --namespace mylabapp 

NAME       DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE       CONTAINERS   IMAGES                                            SELECTOR
mylabapp   1         1         1            1           2m        mylabapp     svs-rtp-dmz-registry.ciscolive.com/myplayapp:v1   app=mylabapp,tier=frontend

kubectl get svc,pods -o wide --namespace mylabapp 

NAME                        READY     STATUS    RESTARTS   AGE       IP           NODE
mylabapp-6ddb9bfd5f-wcq24   1/1       Running   0          2m        10.X.X.X   pod09-nodeX.ecatsrtpdmz.cisco.com

Step 4 - Increase deployment size in namespace

Just as you did before, but now inside the namespace you will increase the deployment size to four.


kubectl scale --replicas=4 deployment mylabapp --namespace mylabapp

And you can verify the increase with:


    kubectl get svc,pods -o wide --namespace mylabapp

[root@pod09-master ~]# ~]# kubectl get svc,pods -o wide --namespace mylabapp

NAME          TYPE          CLUSTER-IP  EXTERNAL-IP   PORT(S)       AGE SELECTOR
svc/mylabapp  LoadBalancer  10.96.X.X   10.0.146.67  80:30563/TCP  1m  app=mylabapp

NAME                          READY STATUS  RESTARTS AGE  IP           NODE
po/mylabapp-587458cc8f-hx22f  1/1   Running 0        9s   10.209.X.X   pod09-nodeX.ecatsrtpdmz.cisco.com
po/mylabapp-587458cc8f-s5fdd  1/1   Running 0        9s   10.209.X.X   pod09-nodeX.ecatsrtpdmz.cisco.com
po/mylabapp-587458cc8f-t8ncp  1/1   Running 0        1m   10.209.X.X   pod09-nodeX.ecatsrtpdmz.cisco.com
po/mylabapp-587458cc8f-vwz7s  1/1   Running 0        9s   10.209.X.X   pod09-nodeX.ecatsrtpdmz.cisco.com

Step 5 - Check ACI Fabric

Now that the application is deployed in a separate namespace, we can go ahead and see how the ACI fabric provides you visibility in the VMM domain for containers giving you more management flexibility of Kubernetes with ACI.

Head over to the ACI fabric ( link/credentials in the top left on this browser window ).

As you can see the ACI fabric administrator has visibility to every Namespace created in the the Kubernetes environment. Giving you an easy way to track down where POD's have been deployed. This visibility becomes very useful in a large Kubernetes cluster.

With the Namespace created, we can assign namespaces into fabric policies easily.