Deploy Django Application using Kubernetes and AWS EC2 Instance
By: Ashutosh K
Tags: Git, Kubernetes, Django, Ec2, Github

🔥💥🔥💥🔥💥🔥💥🔥💥🔥💥🔥💥🔥💥🔥💥🔥💥🔥💥🔥💥🔥

image from internet

Here is the steps

1.launch ubuntu AMI one of t2.medium(Master Node) and t2.micro(slave node)

2.login to aws console of the instance

3.Install following dependencies on both master and slave.

Kubernetes supports many runtime engines here am going to select docker as runtime engine

-Install docker using following commands

# (Install Docker CE)

## Set up the repository:

### Install packages to allow apt to use a repository over HTTPS

apt-get update && apt-get install -y \

apt-transport-https ca-certificates curl software-properties-common gnupg2

# Add Docker’s official GPG key:

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -

# Add the Docker apt repository:

add-apt-repository \

"deb [arch=amd64] https://download.docker.com/linux/ubuntu \

$(lsb_release -cs) \

stable"

# Install Docker CE

apt-get update && apt-get install -y \

containerd.io=1.2.13-2 \

docker-ce=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) \

docker-ce-cli=5:19.03.11~3-0~ubuntu-$(lsb_release -cs)

# Set up the Docker daemon

cat > /etc/docker/daemon.json <<EOF

{

"exec-opts": ["native.cgroupdriver=systemd"],

"log-driver": "json-file",

"log-opts": {

"max-size": "100m"

},

"storage-driver": "overlay2"

}

EOF

mkdir -p /etc/systemd/system/docker.service.d

# Restart Docker

systemctl daemon-reload

systemctl restart docker

# Now check the status of docker by

systemctl status docker

Ok docker is in active state. lets move on

Kubeadm is a tool built to provide kubeadm init and kubeadm join as best-practice “fast paths” for creating Kubernetes clusters.

kubeadm performs the actions necessary to get a minimum viable cluster up and running.

Installing kubeadm, kubelet and kubectl

You will install these packages on all of your machines:

kubeadm: the command to bootstrap the cluster.

kubelet: the component that runs on all of the machines in your cluster and does things like starting pods and containers.

kubectl: the command line util to talk to cluster.

sudo apt-get update && sudo apt-get install -y apt-transport-https curl

curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -

cat <<EOF | sudo tee /etc/apt/sources.list.d/kubernetes.list

deb https://apt.kubernetes.io/ kubernetes-xenial main

EOF

sudo apt-get update

sudo apt-get install -y kubelet kubeadm kubectl

sudo apt-mark hold kubelet kubeadm kubectl

Once you install all these on both master and slave,to distinguish between master and slave we need to execute following command on master node.

kubeadm init -pod-network-cidr

This command initializes a Kubernetes control-plane node

On execution this command you will get join token which is used to join multiple slaves to the cluster

Execute kubeadm join [token generated] on slave node

kubeadm join bootstraps a Kubernetes worker node or a control-plane node and adds it to the cluster. This action consists of the following steps for worker nodes:

kubeadm downloads necessary cluster information from the API server. By default, it uses the bootstrap token and the CA key hash to verify the authenticity of that data. The root CA can also be discovered directly via a file or URL. Once the cluster information is known, kubelet can start the TLS bootstrapping process. The TLS bootstrap uses the shared token to temporarily authenticate with the Kubernetes API server to submit a certificate signing request (CSR); by default the control plane signs this CSR request automatically. Finally, kubeadm configures the local kubelet to connect to the API server with the definitive identity assigned to the node.

you can see still master is not in ready state and cant able communicate with slave so we need to establish networking among master and slave.

download cni plugin using the following one of the command



kubectl create -f kubectl create -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/k8s-manifests/kube-flannel-rbac.ymlkubectl create -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

now we can see master and slave is ready to communicate

Managing storage is a distinct problem from managing compute instances. The PersistentVolume subsystem provides an API for users and administrators that abstracts details of how storage is provided from how it is consumed. To do this, we need two API resources: PersistentVolume and PersistentVolumeClaim.

A PersistentVolume (PV) is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using Storage Classes. It is a resource in the cluster just like a node is a cluster resource. PVs are volume plugins like Volumes, but have a lifecycle independent of any individual Pod that uses the PV. This API object captures the details of the implementation of the storage, be that NFS, iSCSI, or a cloud-provider-specific storage system.

A PersistentVolumeClaim (PVC) is a request for storage by a user. It is similar to a Pod. Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory). Claims can request specific size and access modes.

Now move on to creation of pv ,pvc , deployment yaml files