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.
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]
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
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
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
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.