In the last article, we started with Pods and showed you how to create and list your first Pods...They are the basic starting point in Kubernetes and if you need to refresh yourself with what we went through, quickly jump back and have a look at the previous post:
@run.vince.run/getting-started-with-kubernetes-deploy-pods
In this article we are going to introduce to you Namespaces and Services, which are some of the first steps in segregating and defining how your pods can communicate and be isolated and organised.
Namespaces
Namespaces are used to isolate and organise your cluster. Resources in the namespace can refer to each other simply by their name. To refer to a service in another namespace, you would need to use service, then the namespace…To be more specific, it is
<service_name>.<namespace>.svc.cluster.local
“cluster.local” is the default domain name for the cluster.
The default namespace is created automatically when the cluster is created, along with the kube-node-lease, kube-public and kube-system namespaces
To view all of the namespaces in your cluster, you use the get namespace kubectl command like the following:
kubectl get namespaces
NAME STATUS AGE
default Active 6d23h
kube-node-lease Active 6d23h
kube-public Active 6d23h
kube-system Active 6d23h
When you use the kubectl command, to refer to a specific namespace, you can use the --namespace option like the following:
kubectl get pods --namespace <namespace_name>
When creating items like pods or deployments. You can create the item under a specific namespace, by including the “namespace: <namespace_name>” details as part of the metadata.
1 apiVersion: v1
2 kind: Pod
3 metadata:
4 name: nginx
5 namespace: default
6 spec:
7 containers:
8 - name: nginx-container
9 image: nginx
To create a new namespace you can do so with a definition YAML file, you only need to include the apiVersion, kind and metadata values as part of your definition, for example to create a new dev namespace, we can use the following definition file:
1 apiVersion: v1
2 kind: Namespace
3 metadata:
4 name: dev
You then create the namespace as we have previously with the create command as we did with out pod definition file "kubectl create -f namespace_yaml"
kubectl create -f dev.yaml
namespace/dev created
kubectl get namespaces
NAME STATUS AGE
default Active 6d23h
dev Active 4s
kube-node-lease Active 6d23h
kube-public Active 6d23h
kube-system Active 6d23h
You can also run the following, but you will not have any record of your changes in code when using the command like this:
kubectl create namespace <namespace_name>
So you can always use a specific namespace by default with kubectl, you can run
kubectl config set-context ${kubectl config current-context} --namespace dev
Services
Enable communication between components applications within kubernetes and outside of kubernetes. Services enable loose coupling between micro services in our application. A service is an object in our kubernetes cluster and can listen to requests on a specific port and forward those requests to a port on the pod running an application.
We can see the services in our namespace using the following command:
kubectl get services
Types of services include:
NodePort: The service will have its own ip and port and you can create it using a yaml definition like we have previously.
1 apiVersion: v1
2 kind: Service
3 metadata:
4 name: myapp-service
5
6 spec:
7 type: NodePort
8 ports:
9 - targetPort: 80
10 port: 80
11 nodePort: 300008
12 selector:
13 app: myapp
14 type: frontend
15
kubectl create -f <service_yaml>
ClusterIP: This is the default type of service which can be accessed by other applications in the cluster, without allowing external access.
1 apiVersion: v1
2 kind: Service
3 metadata:
4 name: back-end
5
6 spec:
7 type: ClusterIP
8 ports:
9 - targetPort: 80
10 port: 80
11 selector:
12 app: myapp
13 type: back-end
Loadbalancer: Only works with support cloud platforms
As you can see with both the definitions provided to create a service, we use the "selector" value to specify the app the service is forwarding communication to.
Now we have the basics for Pods, Namespaces and Services down, we can start to cover some more complicated subjects in the coming articles.
About The Author
I am a DevOps Engineer, Endurance Athlete and Author. As a DevOps Engineer I specialize in Linux and Open Source Applications. Particularly interested in Search Marketing and Analytic’s, and is currently developing my skills in devops, continuous integration, security, and development(Python).