Kubernetes

Himanshu Lohiya
9 min readOct 17, 2018

--

Kubernetes in an open source container management tool hosted by Cloud Native Computing Foundation (CNCF). This is also known as the enhanced version of Borg which was developed at Google to manage both long running processes and batch jobs, which was earlier handled by separate systems.

Kubernetes comes with a capability of automating deployment, scaling of application, and operations of application containers across clusters. It is capable of creating container centric infrastructure.

Features of Kubernetes :

  • Environment consistency across development testing and production.
  • Predictable infrastructure which is going to be created.
  • Continues development, integration and deployment.
  • Auto-scalable infrastructure.
  • Higher resource utilisation.
Kubernetes — Architecture

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Kubernetes — Architecture :

Kubernetes — Master Machine Components :

etcd

It stores the configuration information. It is a high availability key value store that can be distributed among multiple nodes.

It is accessible only by Kubernetes API server as it may have some sensitive information.

API Server

Kubeconfig is a package along with the server side tools that can be used for communication. It exposes Kubernetes API.

Controller Manager

This component is responsible for most of the collectors that regulates the state of cluster and performs a task. In general, it can be considered as a daemon which runs in nonterminating loop and is responsible for collecting and sending information to API server.

The key controllers are replication controller, endpoint controller, namespace controller, and service account controller.

Scheduler

It is responsible for distributing the workload. It is responsible for tracking utilisation of working load on cluster nodes and then placing the workload on which resources are available.

Kubernetes — Node Machine Components (also known as a minion) :

Kubelet Service

This is responsible for relaying information to and from control plane service. It interacts with etcd store to read configuration details and write values.

The kubelet process then assumes responsibility for maintaining the state of work and the node server. It manages network rules, port forwarding, etc.

Kubernetes Proxy Service

This helps in making application services available to the external host. It manages pods on node, volumes, secrets, creating new containers’ health checkup, etc.

It helps in forwarding the request to correct containers and is capable of performing primitive load balancing.

Docker Engine

Docker Engine which helps in running the containers.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Kubernetes Installation :

SSH_KEYS=~/.ssh/devopsinuse

if [ ! -f "$SSH_KEYS" ]
then
echo -e "\nCreating SSH keys ..."
ssh-keygen -t rsa -N '' -f ~/.ssh/devopsinuse
else
echo -e "\nSSH keys are already in place!"
fi

echo -e "\nCreating kubernetes cluster ...\n"

kops create cluster \
--name=<NAME> \
--state=s3://<NAME> \
--authorization RBAC \
--zones=<ZONE> \
--node-count=2 \
--node-size=t2.micro \
--master-size=t2.micro \
--master-count=1 \
--dns-zone=<DNS_ZONE> \
--out=terraform_code \
--target=terraform \
--ssh-public-key=~/.ssh/devopsinuse.pub
# Start your Kubernetes cluster
cd /terraform_code
terraform apply

# Create service account && initiate tiller pod in your Kubernetes
kubectl create serviceaccount --namespace kube-system tiller
kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
# kubectl patch deploy --namespace kube-system tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'
helm init --service-account tiller --upgrade
# Delete your Kubernetes cluster
cd /terraform_code
terraform destroy # hit yes

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — ——

Namespace :

Provides an additional qualification to a resource name. Helpful when there is a potential of name collision for a resource. It can be as a virtual wall between multiple clusters. Important functionalities of a Namespace in Kubernetes −

  • Namespaces help pod-to-pod communication using the same namespace.
  • Namespaces are virtual clusters that exist in same physical cluster.

Create NameSpace

kubectl create –f namespace.yml

namespace.yml

apiVersion: v1
kind: Namespace
metadata
name: elk

Get Namespace

kubectl get namespace
kubectl get namespace <NAMESPACE_NAME>

Describe Namespace

kubectl describe namespace <NAMESPACE_NAME>

Delete Namespace

kubectl delete namespace <NAMESPACE_NAME>

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Pod :

A pod is a collection of containers.

apiVersion: v1
kind: pod
metadata:
name: Tesing_for_Image_pull
spec:
containers:
- name: containerName
image: DOCKER_IMAGE
imagePullPolicy: Always
command: ["echo", "SUCCESS"]
  • name: Tesing_for_Image_pull − This name is given to identify and check what is the name of the container that would get created after pulling the images from Docker registry.
  • name: containerName− name given to the newly created container.
  • image: DOCKER_IMAGE− image whose container need to be created.
  • imagePullPolicy
    Always — whenever we create container, it will pull the same name again.
  • command: [“echo”, “SUCCESS”] − display a message when we create the container.

To create a container :

kubectl create –f Tesing_for_Image_pull

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Deployments :

They manage the deployment of replica sets. They have the capability to update the replica set and are also capable of rolling back to the previous version. It has the capability to change the deployment midway.

apiVersion: apps/v1
kind: Deployment
metadata:
name: jupyter-k8s-udemy
labels:
app: jupyter-k8s-udemy
spec:
replicas: 1
selector:
matchLabels:
app: jupyter-k8s-udemy
template:
metadata:
labels:
app: jupyter-k8s-udemy
spec:
containers:
- name: minimal-notebook
image: jupyter/minimal-notebook:latest
ports:
- containerPort: 8888
command: ["start-notebook.sh"]
args: ["--NotebookApp.token=''"]

Create Deployment

kubectl create –f Deployment.yaml -–record

Get Deployment

kubectl get deployments

Deployment Status

kubectl rollout status deployment/Deployment

Updating Deployment

kubectl set image deployment/Deployment tomcat=tomcat:6.0

Rolling Back Deployment

kubectl rollout undo deployment/Deployment –to-revision=2

Scale Deployment

kubectl scale deployment DEPLOYEMENT_NAME –replicas=9

Changing the Deployment

Updating

The user can update the ongoing deployment before it is completed. In this, the existing deployment will be settled and new deployment will be created.

Deleting −

The user can pause/cancel the deployment by deleting it before it is completed. Recreating the same deployment will resume it.

Rollback −

We can roll back the deployment or the deployment in progress. The user can create or update the deployment by using DeploymentSpec.PodTemplateSpec = oldRC.PodTemplateSpec.

Deployment Strategies

help in defining how the new RC should replace the existing RC.

Recreate −

This feature will kill all the existing RC and then bring up the new ones. This results in quick deployment however it will result in downtime when the old pods are down and the new pods have not come up.

Rolling Update −

This feature gradually brings down the old RC and brings up the new one. This results in slow deployment, however there is no deployment. At all times, few old pods and few new pods are available in this process.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Service :

A service can be defined as a logical set of pods.

It can be defined as an abstraction on the top of the pod which provides a single IP address and DNS name by which pods can be accessed. With Service, it is very easy to manage load balancing configuration.

apiVersion: apps/v1
kind: Service
apiVersion: v1
metadata:
name: jupyter-k8s-udemy
labels:
k8s-app: appname
spec:
type: NodePort
selector:
app: jupyter-k8s-udemy
ports:
- protocol: TCP
nodePort: 30040
port: 8888
targetPort: 8888

Types of Services

ClusterIP

This helps in restricting the service within the cluster.

NodePort

It will expose the service on a static port on the deployed node. A ClusterIP service, to which NodePort service will route, is automatically created. The service can be accessed from outside the cluster using the NodeIP:nodePort.

LoadBalancer

It uses cloud providers’ load balancer. NodePort and ClusterIP services are created automatically to which the external load balancer will route.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Labels :

Labels are key-value pairs which are attached to pods, replication controller and services. They are used as identifying attributes for objects.

Selectors :

They are used by the users to select a set of objects. Supported types :

  • Equality-based selectors : allow filtering by key and value.
  • Set-based selectors : allow filtering of keys according to a set of values.
apiVersion: v1
kind: Service
metadata:
name: sp-neo4j-standalone
spec:
ports:
- port: 7474
name: neo4j
type: NodePort
selector:
app: salesplatform
component: neo4j

It will create a service with the new label selector as app and component.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Persistent Volume :

It’s a piece of network storage. Resource independent of any individual pod.

apiVersion: v1
kind: PersistentVolume
metadata:
name: pv0001
labels:
type: local
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
hostPath:
path: "/tmp/data01"
  • storage: 10Gi → we are trying to claim 10Gi space on the defined path.
  • ReadWriteOnce → access rights of the volume that we are creating.
  • path: “/tmp/data01” → path on the machine to create volume.

Creating PV

kubectl create –f local-01.yaml

Checking PV

kubectl get pv

Describing PV

kubectl describe pv <PV_NAME>

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Persistent Volume Claim

The storage requested by Kubernetes for its pods is known as PVC. The user does not need to know the underlying provisioning. The claims must be created in the same namespace where the pod is created.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: myclaim-1
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 3Gi

Creating PVC

kubectl create –f myclaim-1

Getting Details About PVC

kubectl get pvc

Describe PVC

kubectl describe pvc <PVC_NAME>

Using PV and PVC with POD

apiVersion: v1
kind: Pod
metadata:
name: mypod
labels:
name: frontendhttp
spec:
containers:
- name: myfrontend
image: nginx
ports:
- containerPort: 80
name: "http-server"
volumeMounts:
- mountPath: "/usr/share/tomcat/html"
name: mypd
volumes:
- name: mypd
persistentVolumeClaim:
claimName: myclaim-1
  • volumeMounts: → path in the container to mount the volume.
  • Volumes: → volume definition that we are going to claim.
  • persistentVolumeClaim: → define the volume name to use in the pod.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Secrets

Used to store sensitive data with encryption. Ways of creating secrets :

Creating from txt files.

kubectl create secret generic tomcat-passwd –-from-file= ./username.txt –fromfile = ./password.txt

Creating from yaml file.

apiVersion: v1
kind: Secret
metadata:
name: helloworld-secrets
type: Opaque
data:
username: <USER_NAME>
password: <USER_PASSWORD>

Using Secrets in Pod :

As Environment Variable

To use as environment variable, use env under the spec section of pod.yaml.

env:
- name: MYSQL_USER
valueFrom:
secretKeyRef:
name: helloworld-secrets
key: username
- name: MYSQL_PASSWORD
valueFrom:
secretKeyRef:
name: helloworld-secrets
key: password

As Volume

spec:
volumes:
- name: "secretstest"
secret:
secretName: tomcat-pass
containers:
- image: tomcat:7.0
name: awebserver
volumeMounts:
- mountPath: "/tmp/mysec"
name: "secretstest"

Secret Configuration As Environment Variable

apiVersion: v1
kind: ReplicationController
metadata:
name: appname
spec:
replicas: replica_count
template:
metadata:
name: appname
spec:
nodeSelector:
resource-group:
containers:
- name: appname
image:
imagePullPolicy: Always
ports:
- containerPort: 3000
env:
- name: ENV
valueFrom:
configMapKeyRef:
name: appname
key: tomcat-secrets

Secrets As Volume Mount

apiVersion: v1
kind: pod
metadata:
name: appname
spec:
metadata:
name: appname
spec:
volumes:
- name: "secretstest"
secret:
secretName: tomcat-pass
containers:
- image: tomcat: 8.0
name: awebserver
volumeMounts:
- mountPath: "/tmp/mysec"
name: "secretstest"

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Glossary

  • Features of Kubernetes
  • Architecture :

Kubernetes Master Machine Components

  1. etcd
  2. API Server
  3. Controller Manager
  4. Scheduler

Kubernetes Node Machine Components

  1. Kubelet Service
  2. Kubernetes Proxy Service
  3. Docker Engine
  • Kubernetes Installation
  • Namespace
  1. Create NameSpace
  2. Get Namespace
  3. Describe Namespace
  4. Delete Namespace
  • Pod
  • Deployments
  1. Create Deployment
  2. Get Deployment
  3. Deployment Status
  4. Updating Deployment
  5. Rolling Back Deployment
  • Service
  1. ClusterIP
  2. NodePort
  3. LoadBalancer
  • Labels and Selectors
  • Persistent Volume
  1. Creating PV
  2. Checking PV
  3. Describing PV
  • Persistent Volume Claim
  1. Creating PVC
  2. Getting Details About PVC
  3. Describe PVC
  4. Using PV and PVC with POD
  • Creating Secrets
  1. Creating Secret from txt files.
  2. Creating Secret from yaml file.
  • Using Secrets
  1. Using Secrets as Environment Variable
  2. Using Secrets as Volume
  3. Secret Configuration As Environment Variable
  4. Secrets As Volume Mount
  • Job
  • Replication Controller
  • Replica Sets

--

--

No responses yet