Kubernetes
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 — 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
- etcd
- API Server
- Controller Manager
- Scheduler
Kubernetes Node Machine Components
- Kubelet Service
- Kubernetes Proxy Service
- Docker Engine
- Kubernetes Installation
- Namespace
- Create NameSpace
- Get Namespace
- Describe Namespace
- Delete Namespace
- Pod
- Deployments
- Create Deployment
- Get Deployment
- Deployment Status
- Updating Deployment
- Rolling Back Deployment
- Service
- ClusterIP
- NodePort
- LoadBalancer
- Labels and Selectors
- Persistent Volume
- Creating PV
- Checking PV
- Describing PV
- Persistent Volume Claim
- Creating PVC
- Getting Details About PVC
- Describe PVC
- Using PV and PVC with POD
- Creating Secrets
- Creating Secret from txt files.
- Creating Secret from yaml file.
- Using Secrets
- Using Secrets as Environment Variable
- Using Secrets as Volume
- Secret Configuration As Environment Variable
- Secrets As Volume Mount
- Job
- Replication Controller
- Replica Sets