Kubernetes objects are different types of entities provided by Kubernetes for deploying, maintaining, and scaling applications either on cloud or on-premise infrastructure. In this post we will go through different kubernetes objects that we'll use in our applcation deployment.
A pod is the most basic object that you can create in an Kubernetes cluster. It usually contains one or more running containers. Containers in a pod share the same network, storage, and lifecycle. What this means is that they can communicate with each other directly, and will both be stopped and started at the same time.
apiVersion: v1 kind: Pod metadata: name: my-first-pod labels: name: my-first-pod app: nginx-app spec: containers: - image: nginx name: nginx-app ports: - containerPort: 80
Let’s break down the yaml definition we've just used, as we will be using similar definition in other objects definitions as well. And also try to understand this definition file will do.
apiVersion: This definies which version of the Kubernetes API you're using to create this object. There are several versions, and several objects are introduced with each version. Some common ones are v1, apps/v1, and extensions/v1beta1.
Kind: This is the type of Kubernetes object. In this example we’re creating a pod. (so Pod)
Metadata: The metadata is the information about the object. The metadata usually contains the name you want to give the object , the labels etc. For the labels, you can define as many labels as you want like name, app, owner, group, tier etc,
Spec: The spec section is where you define the specifications of your object (the desired state of the object). In the case of a pod, it’s where you describe the state of your container. Some options you can specify in the spec section are:
Container: Here you specify:
- The image that you want to run in your pod
- The name of the container that you’ll run in your pod.
- The ports
Let's create the Pod with our pod-definition.yaml file:
Now go to your terminal, make sure you’re in the directory where you created your file.
kubectl apply -f pod-definition.yaml
The above command will create the pod with nginx image as defined in the pod-definition file. and you can view the Pods by using
kubectl get pods.
The ReplicaSet is used to create multiple copies of the same pod in a Kubernetes cluster. It helps ensure that at any given time, the desired number of pods specified are in the running state.
ReplicaSet helps bring up a new instance of a Pod when the existing one fails, scale it up when the running instances are not up to the specified number, and scale down or delete Pods if another instance with the same label is created. A ReplicaSet ensures that a specified number of Pod replicas are running continuously and helps with load-balancing in case of an increase in resource usage.
apiVersion: apps/v1 kind: ReplicaSet metadata: name: myapp-replicaset labels: app: myapp tier: frontend spec: replicas: 2 selector: matchLabels: tier: frontend template: metadata: labels: tier: frontend spec: containers: - name: nginx-app image: nginx
To create ReplicaSet, go to your terminal and run the following command with your YAML Definition file.
kubectl apply -f ReplicaSet-definition.yaml
Once the ReplicatSet is running, you can check its status using
kubectl get replicaset <your-replicaset-name>
Deployments are Kubernetes objects that are used for managing pods. The first thing a Deployment does when it’s created is to create a replicaset. The replicaset creates pods according to the number specified in the replica option. If you look at the YAML definition for the Deployment below, you’ll notice that the spec section of the deployment looks just like the definition for a replicaset.
apiVersion: apps/v1 kind: Deployment metadata: name: myapp-deployment labels: app: mongo spec: replicas: 2 selector: matchLabels: app: mongo template: metadata: labels: app: mongo spec: containers: - name: mongo image: mongo
So when you create a Deployment, it will create a Replicaset with the pods mentioned in definition.
Deployments can be used to scale your application by increasing the number of running pods, or update the running application.
kubectl apply -f Deployment-definition.yaml
You can view the Deployments with
kubectl get deployments
Namespaces are used to organize objects in a Kubernetes cluster. They enable you to group resources together and perform actions on those resources.
To see all the namespaces in you environment , use
kubectl get namespaces
Creating a Namespace can be done with a single command. If you wanted to create a Namespace called ‘testing’ you would run:
kubectl create namespace testing
Or you can create a namespace using YAML Definition, as follows:
apiVersion: v1 kind: Namespace metadata: name: testing
Now that we have created a namespace, but how do we create the objects in the newly created namespace. For that you need to reference the namespace in the definition file/command.
apiVersion: v1 kind: Pod metadata: name: myPod namespace: testing labels: name: namespaced-pod spec: containers: - image: hello-world name: firstpod
Kubernetes Service is used to expose an application deployed on a set of pods using a single endpoint. Service enables network access to a set of Pods in Kubernetes.
A service in Kubernetes can be created via an API request by passing in a service definition such as:
apiVersion: v1 kind: Service metadata: name: my-service spec: selector: app: myApp ports: - protocol: TCP port: 80 targetPort: 9376
In this example the service is named my-service and will target TCP port 9376 on any pod with the metadata label "app=MyApp" . Kubernetes constantly evaluates the service’s label selector to determine at any given moment which pods are included in the service. This means that a new service can include existing pods that already match the label selector.
The default and simplest service type is
ClusterIP . It exposes the service’s ClusterIP address internally to the Kubernetes cluster.
NodePort – exposes the service on the specified port number, on all nodes in the Kubernetes cluster. Meaning that an incoming request to a node’s IP on the specified port will get routed to the service’s ClusterIP .
LoadBalancer – service is exposed like in NodePort but creates a load balancer in the cloud where Kubernetes is running (if supported by the cloud provider) that receives external requests to the service. It then distributes them among the cluster nodes using NodePort. To specify this type add this line to the spec: