TABLE OF CONTENT
- Kubernetes deployment components
- kubernetes Pod
- kubernetes Service
- kubernetes Ingress
- kubernetes ConfigMap
- kubernetes Secrets
- kubernetes Volumes
- kubernetes Deployment
- Basics Kubernetes command
- Kubernetes Objects and their Specifications
Kubernetes Cluster Objects and their Specifications
A Kubernetes object is a type of record from which you create the object, the Kubernetes system will constantly work to ensure that object exists. Kubernetes objects allows you to represent the state of your cluster like how many container are running inside the Pod, how many Pods are running , what all resources are available, If there are any policies on applications.
These Objects are declared in
.YAML format’s and are used while deployments. This YAML file is used by kubectl command and parse it and converts into JSON while taking to kube-apiserver which further takes care of API’s in kubernetes.
For objects that have a
spec, you have to set this when you create the object, providing a description of the characteristics you want the resource to have its desired state.
status describes the current state of the object, supplied and updated by the Kubernetes system and its components.
Labels are key/value pairs that are attached to objects, such as pods. Labels are intended to be used to specify identifying attributes of objects that are relevant to users
- Lets checkout an example here! In below
.yamlfile you will see the required fields and object spec for a Kubernetes Deployment:
apiVersion: apps/v1 # Which Version your kubernetes API server uses kind: Deployment # What kind of Object you would like to have metadata: tomcat deployment # To Identify the Object specs: # What would you like to achieve using this template replicas: 2 # Run 2 pods matching the template template: metadata: # Data that identify object like name, UID and namespace labels: app : my_tomcat_app spec: containers: - name: my_tomcat_container image: tomcat ports: - containerPort : 8080
- Now create a Deployment using a
.yamlfile with kubectl command as shown below.
kubectl apply -f my.yaml
Kubernetes commands line tools
kubectl is a command line tool that supports various ways to create and manage kubernetes objects.
- To create a deployment named nginx-deployment using kubectl command.
kubectl create deployment nginx-deployment --image=nginx
- To edit the deployment
kubectl edit deployment nginx-deployment
- To check the running pods in the kubernetes cluster.
kubectl get pod
- To check the running services in the kubernetes cluster.
kubectl get services
- To check the the nodes in the kubernetes cluster.
kubectl get nodes
- To describe the pod
kubectl describe Pod_name
- To check the logs of the Pod.
kubectl logs Pod_name
- kind: It lets you run kubernetes on your local machine , install docker before.
- minkube: Similar to kind and it runs on single node.
- kubeadm: Create and Manage kubernetes.
Kubernetes deployment Components
kubernetes deployment contains various components that you need to have a for complete application deployments. You deploy pods and services using kubectl command on kubernetes cluster.
Pod contains single or group of containers which work with shared storage and network and a specification for how to run the containers. Pods are created using workload resources such as deployment or Job. To create a highly available application you should consider deploying on different Pods which is also known as Replication. Healing of Pods is done by controller-manager as it keeps monitoring the health of each pod and later asks scheduler to replace a new Pod. All the Pods are assigned unique IP address and communicate with each other.
- Lets see a template file that creates pod after running it.
apiVersion: batch/v1 kind: Job metadata: name: hello_Tomcat spec: template: # This is the pod template spec: containers: - name: Tomcat_container image: Tomcat command: ['sh', '-c', 'echo "Hello, Tomcat!" && sleep 3600'] restartPolicy: OnFailure # The pod template ends here
Service provides you a way to expose your application running on a set of Pods as a network service. Kubernetes provide unique IP address to each Pods and a single DNS name. Sometimes, Kubernetes Pods are created and destroyed to match the state of your cluster. Pods are nonpermanent resources. If you use a Deployment to run your app, it can create and destroy Pods dynamically.
Each Pod gets its own IP address, however in a Deployment, the set of Pods running in one moment in time could be different from the set of Pods running that application a moment later which leads to a problem. To solve this kubernetes service was introduced which aligns static Permanent IP address on a set of Pods as a network service .
- To provide a service definition to the API server, lets create a
service.yamlfile. In the below YAML code , you have sets of set of Pods where each listens on TCP port 9376 and contains a label
app=MyApp. This specification creates a new Service object named “my-service”, which targets TCP port 9376 on any Pod with the
apiVersion: v1 kind: Service metadata: name: my-service spec: selector: app: MyApp ports: - protocol: TCP port: 80 targetPort: 9376
API Object that helps in managing the external access of services in the cluster. It provides Load Balancing , SSL termination and name based hosting. Exposes HTTP/HTTPS routes from outside world to services in your cluster but does not expose arbitrary ports or protocols.
To deploy Ingress you also need ingress controller which is responsible for fulfilling the Ingress, usually with a load balancer. Unlike other types of controllers which run as part of the
kube-controller-manager binary, Ingress controllers are not started automatically with a cluster. Example of AWS Ingress controller: AWS Load Balancer Controller is a controller to help manage Elastic Load Balancers for a Kubernetes cluster.
Here is a simple diagram where an Ingress sends all its traffic to one Service.
Below, lets see how to create a minimum ingress resource.
metadata fields are required for details. The name of an Ingress object must be a valid DNS subdomain name and annotations configures Ingress controller. The Ingress spec has all the information needed to configure a load balancer or proxy server. In case of rules inside the spec, if no host is configured that means so the rule applies to all inbound HTTP traffic through the IP address specified. /testpath is the path which has an associated backend defined with a
service name and a
service port name. A backend is a combination of Service and port names.
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: minimal-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target: / spec: rules: - http: paths: - path: /testpath pathType: Prefix backend: service: name: test port: number: 80
- ConfigMap helps you to store key-value pairs
- Pod can consume them as environmental values or command line argument in config file .
- These contains information about DBS subdomain names.
- There are 4 ways in which you can use configMap to configure containers
- use command on container
- environmental variable on container
- Attach in volume
- write a code or script which Kubernetes API can use to read configMap
apiVersion: v1 kind: ConfigMap metadata: name: Example data:
apiVersion: v1 kind: Pod metadata: name: configmap spec: containers: - name: container_1 image: alpine env: valueFrom: configMapKeyRef: name: Example
- These store sensitive information such as password, OAuth tokens, SSH keys.
- It is important to enable encryption at REST using base64 encoded
- This is also used as environmental variable and can be consumed by POD.
- There are 3 ways in which you can use secrets with POD.
- environmental variable on container
- Attach as a file in volume
- It can be used by kubelet when you pull image
apiVersion: v1 kind: Secret metadata: name: secret_Example annotations:
- This is used to store data for containers in POD
- We can have local storage which containers use but that’s really a risky thing if POD dies volume is also gone.
- We should volume which should be persistent and should be backed up easily.
- There are different persistent volumes which kubernetes supports such as
apiVersion: v1 kind: Pod metadata: name: test spec: containers: - image: name: mycontainer volumeMounts: - mountPath: /myapp name: myvol
This is a layer which helps to define how your POD and containers should be created it using YAML files. This are also known as blueprint for PODS. Using Deployment You can define how many replicas you can have and other features.
apiVersion: v1 kind: Deployment metadata: name: test
kubectl create deployment nginx-deploymnet --image=nginx kubectl get pod kubectl get replicaset kubectl edit deployment nginx-deploymnet
- It manages stateful applications such as MySQL, Databases , MongoDB.
- It is used for those apps which needs persistant storage
- For example when a DB POD dies and new POD is generated then we need to make sure that our new DB POD which connects to Shared DB shouldn’t gets inconsistent as other PODS might be writing or reading the data.
apiVersion: apps/v1 kind: StatefulSet metadata: name: web spec: