29Sep

How To Create a Kubernetes Cluster Using Kubeadm on Ubuntu 18.04

September 29, 2022 admin

Kubernetes is a container orchestration system. It helps in managing the containers at scale. Alongside, it automates the installation and configuration of Kubernetes components. Kubernetes components include Controller Manager, API server, and Kube DNS. This post will guide you regarding setting up a Kubernetes cluster from the very beginning with the use of Ansible and Kubeadm. Afterward, we will be proceeding with deploying a containerized Nginx application to it.

Prerequisites for Creating Kubernetes Cluster Using Kubeadm

Before you proceed with this post, there are certain prerequisites that you need to consider:

An SSH key pair on your local Linux/macOS/BSD machine.

Three servers that run Ubuntu 18.04 having at least 2GB RAM and 2 vCPUs each. You should be able to SSH into each server and that too as the root user using your SSH key pair.

Ansible installed on your local machine.

You must be familiar with Ansible playbooks.

You must have an idea regarding the process of launching a container from a rocker image.

Steps for Creating Kubernetes Cluster on Ubuntu 18.04 Using Kubeadm

You can create a Kubernetes cluster on your Ubuntu system with ease by following the steps mentioned as follows:

Step 1: Set up the Workspace Directory and Ansible Inventory File

This step requires you to create a directory on the local machine that primarily serves as the workspace. To facilitate communication and execute demand in your remote servers, you would be required to configure Ansible locally. Afterward, you will be creating a hosts file that will be containing the inventory information like the IP addresses of your servers as well as the groups that each server belongs to.

There will be three servers, out of which one will be the master with an IP displayed as master_ip. The other two will be workers having the IPs worker_1_ip and worker_2_ip.

Then proceed towards creating a directory that will be named ~/kube-cluster in the home directory of your local machine. Then you need to navigate into this directory. Here are the commands that you need to run on the terminal:

$ mkdir ~/kube-cluster

$ cd ~/kube-cluster

This directory will serve as your workspace for this tutorial. It will also contain all the Ansible playbooks. All the local commands will be run inside this directory only.

Now, create a new file named ~/kube-cluster/hosts with the use of nano or your favorite text editor:

$ nano ~/kube-cluster/hosts

Now, you will be required to add the below-mentioned text to the file. This will aid in specifying the logical structure of the cluster.:

~/kube-cluster/hosts

[masters]

master ansible_host=master_ip ansible_user=root

[workers]

worker1 ansible_host=worker_1_ip ansible_user=root

worker2 ansible_host=worker_2_ip ansible_user=root

[all:vars]

ansible_python_interpreter=/usr/bin/python3

You must remember that inventory files in Ansible are used in specifying server information. This server information comprises IP addresses, remote users, and groupings of servers. All of these are targeted as a single unit for executing commands. Also, ~/kube-cluster/hosts act as your inventory file to which you’ve added two Ansible groups (masters and workers).

These aid in specifying your cluster’s logical structure.

Talking about the master’s group, there is a server entry that is named “master”. It helps in listing the master node’s IP (master_ip) along with specifying that Ansible should run remote commands as the root user.

Talking about the workers group, there are two separate entries for the worker servers as well (worker_1_ip and worker_2_ip). They also aid in specifying the ansible_user as root.

The bottom-most line of the file informs Ansible to utilize the remote servers’ Python 3 interpreters to facilitate its management operations.

After adding the text, simply Save and Close the file.

Once you set up the server inventory with groups, you can now install operating system level dependencies along with creating configuration settings.

Step 2: Creating a Non-Root User on All Remote Servers

In this step, you are required to create a non-root user with sudo privileges on all the servers. This allows you to SSH into them manually. You do this as an unprivileged user. During the maintenance of a cluster, these operations are performed routinely with the use of a non-root user. It aids in minimizing the risks that are present. These risks include the modification or deletion of important files. It also reduces the chances of unintentionally performing other dangerous operations.

Create a file named ~/kube-cluster/initial.yml in the workspace:

$ nano ~/kube-cluster/initial.yml

Then proceed towards adding the below-mentioned play to the file. It will create a non-root user with sudo privileges on all of the servers. A play in Ansible is a collection of steps that are required to be performed. It targets specific groups along with servers. The below-mentioned play will help in creating a non-root sudo user:

~/kube-cluster/initial.yml

– hosts: all

become: yes

tasks:

– name: create the ‘ubuntu’ user

user: name=ubuntu append=yes state=present createhome=yes shell=/bin/bash

– name: allow ‘ubuntu’ to have passwordless sudo

lineinfile:

dest: /etc/sudoers

line: ‘ubuntu ALL=(ALL) NOPASSWD: ALL’

validate: ‘visudo -cf %s’

– name: set up authorized keys for the ubuntu user

authorized_key: user=ubuntu key=”{{item}}”

with_file:

– ~/.ssh/id_rsa.pub

Now let’s have a look at the stuff which this playbook performs:

It aids in creating a non-root user in Ubuntu.

It helps in configuring the sudoers file. It further allows the Ubuntu user to run sudo commands, and that too without requiring a password prompt.

It adds the public key to your local machine (usually ~/.ssh/id_rsa.pub) to the authorized key list of remote ubuntu users. It further allows you to SSH into each server as an Ubuntu user.

Afterward, Save and close the file once you’ve added the text.

Next, you will be required to execute the playbook. You will do this by running it locally:

$ ansible-playbook -i hosts

~/kube-cluster/initial.yml

The command will be completed within two to five minutes. Once it gets completed, you will see an output that will resemble the following:

PLAY [all] ****

TASK [Gathering Facts] ****

ok: [master]

ok: [worker1]

ok: [worker2]

TASK [create the ‘ubuntu’ user] ****

changed: [master]

changed: [worker1]

changed: [worker2]

TASK [allow ‘ubuntu’ user to have passwordless sudo] ****

changed: [master]

changed: [worker1]

changed: [worker2]

TASK [set up authorized keys for the ubuntu user] ****

changed: [worker1] => (item=ssh-rsa AAAAB3…)

changed: [worker2] => (item=ssh-rsa AAAAB3…)

changed: [master] => (item=ssh-rsa AAAAB3…)

PLAY RECAP ****

master : ok=5 changed=4 unreachable=0 failed=0

worker1 : ok=5 changed=4 unreachable=0 failed=0

worker2 : ok=5 changed=4 unreachable=0 failed=0

The above-mentioned steps will complete the preliminary setup. Now, you can move towards installing the Kubernetes-specific dependencies.

Step 3: Installing Kubernetetes’ Dependencies

Following this step, you will be installing the operating-system-level packages that Kubernetes will require with Ubuntu’s package manager. These packages are:

Docker – It is a container runtime. Docker is the component that facilitates the running of the containers. When it comes to support for other runtimes such as rkt, it is under active development in Kubernetes.

kubeadm – It is a CLI tool. It allows the installation and configuration of the various components of a cluster. It does so in a standard way.

kubelet – It is a system service/program. It runs on all nodes along with handling node-level operations.

kubectl – It is a CLI tool. It facilitates issuing commands to the cluster with its API Server.

Create a file named ~/kube-cluster/kube-dependencies.yml in the workspace:

$ nano ~/kube-cluster/kube-dependencies.yml

Then, proceed to add the following plays to the file; this will aid in installing these packages to your servers:

~/kube-cluster/kube-dependencies.yml

– hosts: all

become: yes

tasks:

– name: install Docker

apt:

name: docker.io

state: present

update_cache: true

– name: install APT Transport HTTPS

apt:

name: apt-transport-https

state: present

– name: add Kubernetes apt-key

apt_key:

url: https://packages.cloud.google.com/apt/doc/apt-key.gpg

state: present

– name: add Kubernetes’ APT repository

apt_repository:

repo: deb http://apt.kubernetes.io/ kubernetes-xenial main

state: present

filename: ‘kubernetes’

– name: install kubelet

apt:

name: kubelet=1.14.0-00

state: present

update_cache: true

– name: install kubeadm

apt:

name: kubeadm=1.14.0-00

state: present

– hosts: master

become: yes

tasks:

– name: install kubectl

apt:

name: kubectl=1.14.0-00

state: present

force: yes

The first play in the playbook performs the following:

It helps in installing Docker which acts as the container runtime.

It also facilitates the installation of apt-transport-https, which allows you to add external HTTPS sources to the APT sources list.

It facilitates adding the Kubernetes APT repository’s apt-key that is required for key verification.

It also adds the Kubernetes APT repository to your remote servers’ APT sources list.

It facilitates the installation of both kubelet and kubeadm.

The second play primarily consists of a single task. It helps in installing kubectl on your master node.

Finally, Save and close the file when you are done.

Afterward, execute the playbook by running it locally:

$ ansible-playbook -i hosts ~/kube-cluster/kube-dependencies.yml

On completion, you will see an output that will resemble the following:

PLAY [all] ****

TASK [Gathering Facts] ****

ok: [worker1]

ok: [worker2]

ok: [master]

TASK [install Docker] ****

changed: [master]

changed: [worker1]

changed: [worker2]

TASK [install APT Transport HTTPS] *****

ok: [master]

ok: [worker1]

changed: [worker2]

TASK [add Kubernetes apt-key] *****

changed: [master]

changed: [worker1]

changed: [worker2]

TASK [add Kubernetes’ APT repository] *****

changed: [master]

changed: [worker1]

changed: [worker2]

TASK [install kubelet] *****

changed: [master]

changed: [worker1]

changed: [worker2]

TASK [install kubeadm] *****

changed: [master]

changed: [worker1]

changed: [worker2]

PLAY [master] *****

TASK [Gathering Facts] *****

ok: [master]

TASK [install kubectl] ******

ok: [master]

PLAY RECAP ****

master : ok=9 changed=5 unreachable=0 failed=0

worker1 : ok=7 changed=5 unreachable=0 failed=0

worker2 : ok=7 changed=5 unreachable=0 failed=0

Once the execution is completed, Docker, kubeadm, and kubelet will be installed on all of the remote servers. But, kubectl won’t be as it is needed only to execute cluster commands. Hence, installing it only on the master node is quite relevant. This is because you will run kubectl commands only from the master. However, it must be noted that kubectl commands can be run from any of the worker nodes or any machine. Those machines and nodes must be able to install and configure it to point to a cluster.

All system dependencies will be installed by now. Now you can proceed towards setting up the master node along with initializing the cluster.

Step 4: Setting Up the Master Node

Following this step, you will be setting up the master node. Before you create any playbooks, it is quite imperative to cover some concepts like Pods and Pod Network Plugins. This is because your cluster will include both of them.

A pod refers to an atomic unit that runs one or more containers. These containers help in sharing resources, including file volumes and network interfaces that are in common. Pods act as the basic unit of scheduling in Kubernetes: all containers in a pod run on the exact same node to which the pod is scheduled.

Each pod has its IP address. A pod present on one node should be able to access a pod on another node with the use of a pod’s IP. Containers on a single node can communicate easily through a local interface. However, communication between the pods is more complicated. This kind of communication requires a separate networking component. It must be capable of transparently route traffic from a pod on one node to a pod on another.

Pod network plugins provide this functionality. For this cluster, you will be using Flannel. It serves as a stable and performant option.

Create an Ansible playbook named master.yml on your local machine:

$ nano ~/kube-cluster/master.yml

Then, add the following play to the file to initialize the cluster and install Flannel:

~/kube-cluster/master.yml

– hosts: master

become: yes

tasks:

– name: initialize the cluster

shell: kubeadm init –pod-network-cidr=10.244.0.0/16 >> cluster_initialized.txt

args:

chdir: $HOME

creates: cluster_initialized.txt

– name: create .kube directory

become: yes

become_user: ubuntu

file:

path: $HOME/.kube

state: directory

mode: 0755

– name: copy admin.conf to user’s kube config

copy:

src: /etc/kubernetes/admin.conf

dest: /home/ubuntu/.kube/config

remote_src: yes

owner: ubuntu

– name: install Pod network

become: yes

become_user: ubuntu

shell: kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/a70459be0084506e4ec919aa1c114638878db11b/Documentation/kube-flannel.yml >> pod_network_setup.txt

args:

chdir: $HOME

creates: pod_network_setup.txt

Here we present before you a breakdown of this play:

The first task facilitates the initialization of the cluster by running kubeadm init. Passing the argument –pod-network-cidr=10.244.0.0/16 aids in specifying the private subnet that the pod IPs are assigned from. Flannel makes use of the above subnet by default; here we are telling kubeadm to use the exact same subnet.

The second task helps in creating a .kube directory at /home/ubuntu. This directory holds configuration information including the admin key files. These are required to connect to the cluster, and the cluster’s API address.

The third task allows copying the /etc/kubernetes/admin.conf file that was earlier generated from kubeadm init to your non-root user’s home directory. This further allows you to use kubectl which aids in accessing the newly-created cluster.

The last task that runs is kubectl apply, which intends to install Flannel.

kubectl apply -f descriptor.[yml|json] is the syntax that tells kubectl to create the objects that are described in the descriptor.[yml|json] file. The kube-flannel.yml file contains the descriptions of objects that are required for setting up Flannel in the cluster.

Once you are finished with these, Save and Close the file.

Now, you will be executing the playbook locally by using the command:

$ ansible-playbook -i hosts ~/kube-cluster/master.yml

On completion, you will see an output resembling the following:

PLAY [master] ****

TASK [Gathering Facts] ****

ok: [master]

TASK [initialize the cluster] ****

changed: [master]

TASK [create .kube directory] ****

changed: [master]

TASK [copy admin.conf to user’s kube config] *****

changed: [master]

TASK [install Pod network] *****

changed: [master]

PLAY RECAP ****

master : ok=5 changed=4 unreachable=0 failed=0

In order to check the status of the master node, just SSH into it using the following command:

$ ssh ubuntu@master_ip

Once you are inside the master node, execute the following:

$ kubectl get nodes

You will now see the following output:

NAME STATUS ROLES AGE VERSION

master Ready master 1d v1.14.0

The output states that all initialization tasks have been completed by the master node. It is now in a Ready state. From there onwards, it can start accepting worker nodes along with executing tasks that are sent to the API Server. Now, you can proceed with adding the workers from your local machine.

Step 5: Setting Up the Worker Nodes

This step involves adding workers to the cluster, which aids in executing a single command on each. It comprises the necessary cluster information, including the IP address and port of the master’s API Server and a secure token. Only the nodes that pass in the secure token are capable of joining the cluster.

Now, navigate back to your workspace. Create a playbook named workers.yml:

$ nano ~/kube-cluster/workers.yml

Then add the following text to the file. This will add the workers to the cluster:

~/kube-cluster/workers.yml

– hosts: master

become: yes

gather_facts: false

tasks:

– name: get join command

shell: kubeadm token create –print-join-command

register: join_command_raw

– name: set join command

set_fact:

join_command: “{{ join_command_raw.stdout_lines[0] }}”

– hosts: workers

become: yes

tasks:

– name: join cluster

shell: “{{ hostvars[‘master’].join_command }} >> node_joined.txt”

args:

chdir: $HOME

creates: node_joined.txt

The playbook does the following:

The first play receives the join command. It needs to be run on the worker nodes. This command will be given in the following format:

kubeadm join –token <token> <master-ip>:<master-port> –discovery-token-ca-cert-hash sha256:<hash>.

Once it gets the actual command with the proper token and hash values, the task will set it as a fact. It will aid the next play to be able to access that info.

The second play comprises a single task that runs the join command on all the worker nodes. Once this task gets completed, the two worker nodes will become a part of the cluster.

When you are finished, simply Save and Close the file.

Now, you can execute the playbook by using the following command:

$ ansible-playbook -i hosts ~/kube-cluster/workers.yml

Once it gets completed, you will see an output resembling the following:

PLAY [master] ****

TASK [get join command] ****

changed: [master]

TASK [set join command] *****

ok: [master]

PLAY [workers] *****

TASK [Gathering Facts] *****

ok: [worker1]

ok: [worker2]

TASK [join cluster] *****

changed: [worker1]

changed: [worker2]

PLAY RECAP *****

master : ok=2 changed=1 unreachable=0 failed=0

worker1 : ok=2 changed=1 unreachable=0 failed=0

worker2 : ok=2 changed=1 unreachable=0 failed=0

After adding the worker nodes, your cluster is now completely set up and functional. Your workers are now ready to run workloads. Before you start scheduling the applications, you must verify that the cluster is working in an intended manner.

Step 6: Verifying the Cluster

At times a cluster may fail while setting up. This happens either because a node is down or network connectivity between the master and worker is not working perfectly. To verify the cluster and make sure that the nodes are operating correctly, the below-mentioned protocol must be followed.

You will be checking the present state of the cluster from the master node. This will ensure that the nodes are ready. If you are disconnected from the master node, you can simply SSH back into it by using the below-mentioned command:

$ ssh ubuntu@master_ip

Then you are required to execute the following command to receive the status of the cluster:

$ kubectl get nodes

You will see an output resembling the following:

NAME STATUS ROLES AGE VERSION

master Ready master 1d v1.14.0

worker1 Ready <none> 1d v1.14.0

worker2 Ready <none> 1d v1.14.0

If all of your nodes show the value of Ready for STATUS, it means that they’re part of the cluster and are ready to run workloads.

If a few of the nodes have NotReady as the STATUS, it could mean that the worker nodes haven’t finished their setup till now. You must wait for around five to ten minutes before re-running kubectl get nodes, and inspect the new output in such a scenario. If a few nodes still have NotReady as their status, you might have to verify and re-run the commands that are mentioned in the previous steps.

Now that your cluster is verified successfully, we can proceed towards scheduling an example Nginx application on the cluster.

Step 7: Running an Application on the Cluster

In this step, you can deploy any containerized application to your cluster. Let’s start with deploying Nginx using Deployments and Services to see how this application can be deployed to the cluster. The commands given below can be used for other containerized applications too. All you need to do is to change the Docker image name and any relevant flags (such as volumes and ports).

Still, within the master node, you must execute the following command to create a deployment that will be named Nginx:

$ kubectl create deployment nginx –image=nginx

A deployment is basically a type of Kubernetes object that makes sure that there is a specified number of pods that run on a defined template, even if the pod crashes during the lifetime of a cluster. The above deployment aids in creating a pod that has one container from the Docker registry’s Nginx Docker Image.

Afterward, you are required to run the following command, which will create a service named Nginx. It will lead to exposing the app publicly. It will do so through a NodePort. It is basically a scheme that will make the pod accessible through an arbitrary port that is opened on each node of the cluster:

$ kubectl expose deploy nginx –port 80 –target-port 80 –type NodePort

Services are just another type of Kubernetes object. They expose cluster internal services to both internal and external clients. They are even capable of load balancing requests to multiple pods and are an integral component in Kubernetes. They frequently interact with other components too.

Run the following command:

$ kubectl get services

This will output text resembling the following:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 1d

nginx NodePort 10.109.228.209 <none> 80:nginx_port/TCP 40m

From the third line of the above output, you can have an idea about the port that Nginx is running on. Kubernetes will automatically assign a random port to it that will be greater than 30000. It will also ensure that the port is not bound by any other service.

To verify that everything is working, you can visit

http://worker_1_ip:nginx_port or http://worker_2_ip:nginx_port through a browser on your local machine. There you will see Nginx’s welcome page.

If you would like to remove the Nginx application, start with deleting the Nginx service from the master node using the command shown below:

$ kubectl delete service nginx

You must run the following to verify that the service has been deleted:

$ kubectl get services

You will see an output resembling the following:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 1d

Then, you need to delete the deployment with this command:

$ kubectl delete deployment nginx

Finally, run the following to confirm that this has worked:

$ kubectl get deployments

Output

No resources found.

Final Words

With this guide, you can successfully set up a Kubernetes cluster on your Ubuntu 18.04 system. Also, you would be using Kubeadm and Ansible for automation. Once the cluster is set up, you can proceed with deploying your applications and services into the cluster.

24Sep

How To Migrate a Docker Compose Workflow to Kubernetes

September 24, 2022 admin

If you want to deploy and scale a contemporary, stateless application on distributed platforms, you should containerize its components first. Docker Compose can help you modernize and containerize your application during its development. Plus, you can also write service definitions to explain how to run your container images.

Now, if you want to run your services on Kubernetes, you have to migrate your Docker Compose workflow to it. By doing so, you can scale your applications with ease. For such purposes, you can take the help of Kompose. It is a great tool that helps to boost the migration process and save time. In this article, we will discuss how to transfer your Docker Compose workflow to platforms like Kubernetes using Kompose.

What is Kompose?

Kompose is a tool that helps users shift from Docker Compose to Kubernetes. Its name Kompose is a blend of Kubernetes and Compose. The function of this tool is simple; it helps transform a Docker Compose file into Kubernetes resources. Its simplicity and efficiency have made it one of the most popular conversion tools among app developers.

By using Kompose, users can simplify the translation process and the deployment of their containers to a production cluster. Also, merely using a command like kompose, you can convert your Docker Compose file.

Kubernetes Overview

Kubernetes is one of the most popular open-source container orchestrators in the world. It is also known as k8s and used by several individuals as well as organizations. You might know that the process of deploying, managing, and scaling containerized apps manually takes a considerable amount of time. That’s why using a platform like Kubernetes can come in handy. By using Kubernetes, you can automate all these tasks with ease. Hence, the task of managing clusters becomes a lot easier and more convenient if you use Kubernetes.

Kubernetes was first developed by Google and soon its popularity took a hike. Currently, it is an open-source platform maintained by Cloud Native Computing Foundation (CNCF). Kubernetes offers several benefits to users that you should know and are discussed as follows:

Benefits of Kubernetes

Kubernetes helps users to orchestrate containers across numerous hosts.
The tool automates many processes that otherwise need to be performed manually during the development of an app.
Many container orchestration platforms only allow you to scale your resources vertically. But Kubernetes allows you to scale your resources not only vertically but also horizontally.
Being open-source, Kubernetes gives you greater freedom and flexibility than many other similar platforms. You can use this tool anywhere you go. No matter what the environment of your cloud is; public, on-premises, or hybrid, you can utilize Kubernetes.
One of its biggest benefits is its rollback feature which acts like an eraser. Imagine you somehow make a mistake while making a change to your app and it ends up breaking the whole app. It could make all of your efforts go down the drain. Thankfully, the rollback feature of Kubernetes can help you reverse that mistake and start anew.
Every app developer knows the importance of balancing containers. With Kubernetes, you don’t have to worry about where to place your containers anymore as it knows what’s best. It calculates the best position for your container and balances them in a pretty neat manner.
Another great advantage of Kubernetes is its self-monitoring feature. Kubernetes keeps a constant watch on the health of your nods and containers. Thus, it ensures that they are always in tip-top condition.
Besides the above benefits, Kubernetes can manage several clusters at once.

Simple Steps to Migrate a Docker Compose Workflow to Kubernetes

Before we discuss the steps that allow you to migrate your Docker Compose workflow, you need to take a look at the essential requirements that you must satisfy.

Prerequisites

An RBAC-enabled Kubernetes 1.10+ cluster.
Your local machine or development server must have the kubectl command-line tool installed on it.
You must have a Docker Hub account and the Docker software installed on your local machine or development server.

Step 1: Installing Kompose

First, go to the GitHub Releases page and copy-paste the following into the curl command to download Kompose (v1.18.0):

curl -L https://github.com/kubernetes/kompose/releases/download/v1.18.0/kompose-linux-amd64 -o kompose

Next, make the binary executable:

chmod +x compose

After that, move the binary to your path:

sudo mv ./kompose /usr/local/bin/compose

To check the version of the software by doing the following:

kompose version

If you installed the right version, you will get the following output:

1.18.0 (06a2e56)

Now that you have successfully installed kompose, you can proceed further to clone the application.

Step 2: Cloning and Packaging the Application

You have to clone your Node.js project code and package the application to run it on Kubernetes. To do that, clone the repository into the node_project directory:

git clone https://github.com/do-community/node-mongo-docker-dev.git node_project

The node_project directory stores files and directories for a shark information app that needs user inputs to function. This directory is optimized to properly work with containers. You can reach the node_project directory by copy-pasting the following:

cd node_project

There is a dockerfile in the node_project directory. You can find the instructions to build the application image in it. Build the image with the help of the docker build command. In such cases, you can tag the image with your Docker Hub Username by naming it node-kubernetes. Or, you can give it any name you like:

docker build -t your_dockerhub_username/node-kubernetes .

We are using the . in the command to specify that the build context is the current directory.

It usually takes 1-2 minutes to build an image. After you’re done building it, you can check your images with the help of the command below:

docker images

If your application image is ready, you will get this output:

REPOSITORY TAG IMAGE ID CREATED SIZE

your_dockerhub_username/node-kubernetes latest 9c6f897e1fbc 3 seconds ago 90MB

node 10-alpine 94f3c8956482 12 days ago 71MB

Now, log into your Docker Hub account:

docker login -u your_dockerhub_username

Logging into your Docker Hub account will create a ~/.docker/config.json file in your home directory.

Use the docker push command to send your application image to Docker Hub. However, you must replace your_dockerhub_username with your actual username:

docker push your_dockerhub_username/node-kubernetes

Step 3: Translating Compose Service to Kubernetes Objects with Kompose

Next, you have to translate your compose service definitions to Kubernetes Objects. The Docker Compose file namely docker-compose.yaml helps to determine the definitions to run your services with Compose. You can use Kompose to create yaml files and migrate the service definitions to Kubernetes objects. Here’s how you can do it.

First, you need to change some of your Docker Compose file definitions to make them compatible with Kubernetes. You need to modify the restart policies of both containers so that they work better with Kubernetes.

Open the Compose file with nano or any similar editor:

nano docker-compose.yaml

In its usual state, the service definition for Node.js is:

~/node_project/docker-compose.yaml

…

services:

nodejs:

build:

context: .

dockerfile: Dockerfile

image: nodejs

container_name: nodejs

restart: unless-stopped

env_file: .env

environment:

– MONGO_USERNAME=$MONGO_USERNAME

– MONGO_PASSWORD=$MONGO_PASSWORD

– MONGO_HOSTNAME=db

– MONGO_PORT=$MONGO_PORT

– MONGO_DB=$MONGO_DB

ports:

– “80:8080”

volumes:

– .:/home/node/app

– node_modules:/home/node/app/node_modules

networks:

– app-network

command: ./wait-for.sh db:27017 — /home/node/app/node_modules/.bin/nodemon app.js

…

Now, you need to do some modifications to this definition:

Replace the local dockerfile with your node-kubernetes image.
Make the restart policy always instead of unless stopped.
Get rid of the command instruction and volumes list.

After you’ve done all this, the new service definition will look like the following:

~/node_project/docker-compose.yaml

…

services:

nodejs:

image: your_dockerhub_username/node-kubernetes

container_name: nodejs

restart: always

env_file: .env

environment:

– MONGO_USERNAME=$MONGO_USERNAME

– MONGO_PASSWORD=$MONGO_PASSWORD

– MONGO_HOSTNAME=db

– MONGO_PORT=$MONGO_PORT

– MONGO_DB=$MONGO_DB

ports:

– “80:8080”

networks:

– app-network

…

Next, set the restart policy to always. Delete the .env file. Instead, use Secret and pass the values for your MONGO_INITDB_ROOT_USERNAME and MONGO_INITDB_ROOT_PASSWORD to the database container.

Here’s how the db service will look like now:

~/node_project/docker-compose.yaml

…

db:

image: mongo:4.1.8-xenial

container_name: db

restart: always

environment:

– MONGO_INITDB_ROOT_USERNAME=$MONGO_USERNAME

– MONGO_INITDB_ROOT_PASSWORD=$MONGO_PASSWORD

volumes:

– dbdata:/data/db

networks:

– app-network

…

Navigate to the bottom of the file and delete the node_modules volumes from the top-level volumes key. After doing so, it will look like this:

~/node_project/docker-compose.yaml

…

volumes:

dbdata:

Save the file and close it.

Before you can begin to migrate your service definitions, you must create the .env file. It will help Kompose create the ConfigMap with your information (non-sensitive).

Create the .env file:

nano.env

Next, add the following port and database name info to the file you’ve just created and close it after saving.

~/node_project/.env

MONGO_PORT=27017

MONGO_DB=sharkinfo

After that, convert your definitions to yaml files:

kompose convert

Running this command will give you the following output:

INFO Kubernetes file “nodejs-service.yaml” created

INFO Kubernetes file “db-deployment.yaml” created

INFO Kubernetes file “dbdata-persistentvolumeclaim.yaml” created

INFO Kubernetes file “nodejs-deployment.yaml” created

INFO Kubernetes file “nodejs-env-configmap.yaml” created

After you’re done with it all, proceed with the next step.

Step 4: Creating Kubernetes Secrets

Now, you need to make some modifications to the files created by Kompose to make your application work properly. The first thing you need to do is to create a Secret for your database username and password. There are two types of environment variables while you’re working on Kubernetes: ConfigMap and Secret. The simple, non-classified info you gave away while creating your .env file contributed to the creation of a ConfigMap. So, now you only need to create a Secret and you’re good to go.

To create a Secret, you must convert your username and password to base64. Converting your username and password to base64 will help you transfer your data in a consistent manner. Here’s the command to convert your username:

echo -n ‘your_database_username’ | base64

Write down the output value and convert your password:

echo -n ‘your_database_password’ | base64

Write down the output value here as well.

Use the command below to open a file for Secret:

nano secret.yaml

In case you want to check the formatting of your yaml files, use a linter. Or, validate your syntax using kubectl:

kubectl create -f your_yaml_file.yaml –dry-run –validate=true

Now, create a Secret to define your MONGO_USERNAME and MONGO_PASSWORD using the following code:

~/node_project/secret.yaml

apiVersion: v1

kind: Secret

metadata:

name: mongo-secret

data:

MONGO_USERNAME: your_encoded_username

MONGO_PASSWORD: your_encoded_password

Don’t forget to write your actual username and password instead of the model ones. After you’re done doing so, save and close it. Just like the .env file, add secret.yaml to your .gitignore file here too. Also, note that we have chosen mongo-secret as the name of our Secret object. You, however, can replace it with any name you want.

Next, you have to add references to the Secret to your application deployment.

Open the following file:

nano nodejs-deployment.yaml

The nodejs-deployment.yaml file’s container specs include environment variables mentioned below under the env key:

~/node_project/nodejs-deployment.yaml

apiVersion: extensions/v1beta1

kind: Deployment

…

spec:

containers:

– env:

– name: MONGO_DB

valueFrom:

configMapKeyRef:

key: MONGO_DB

name: nodejs-env

– name: MONGO_HOSTNAME

value: db

– name: MONGO_PASSWORD

– name: MONGO_PORT

valueFrom:

configMapKeyRef:

key: MONGO_PORT

name: nodejs-env

– name: MONGO_USERNAME

After that, add these Secret references to the MONGO_USERNAME and MONGO_PASSWORD variables. Without them, your application won’t have access to these values:

~/node_project/nodejs-deployment.yaml

apiVersion: extensions/v1beta1

kind: Deployment

…

spec:

containers:

– env:

– name: MONGO_DB

valueFrom:

configMapKeyRef:

key: MONGO_DB

name: nodejs-env

– name: MONGO_HOSTNAME

value: db

– name: MONGO_PASSWORD

valueFrom:

secretKeyRef:

name: mongo-secret

key: MONGO_PASSWORD

– name: MONGO_PORT

valueFrom:

configMapKeyRef:

key: MONGO_PORT

name: nodejs-env

– name: MONGO_USERNAME

valueFrom:

secretKeyRef:

name: mongo-secret

key: MONGO_USERNAME

Save and close the file.

Now, add the same values to the db-deployment.yaml file. Open the file first with this command:

nano db-deployment.yaml

After opening the file, add references to the Secret values under the variables namely MONGO_INITDB_ROOT_USERNAME and MONGO_INITDB_ROOT_PASSWORD:

~/node_project/nodejs-deployment.yaml

apiVersion: extensions/v1beta1

kind: Deployment

…

spec:

containers:

– env:

– name: MONGO_DB

valueFrom:

configMapKeyRef:

key: MONGO_DB

name: nodejs-env

– name: MONGO_HOSTNAME

value: db

– name: MONGO_PASSWORD

valueFrom:

secretKeyRef:

name: mongo-secret

key: MONGO_PASSWORD

– name: MONGO_PORT

valueFrom:

configMapKeyRef:

key: MONGO_PORT

name: nodejs-env

– name: MONGO_USERNAME

valueFrom:

secretKeyRef:

name: mongo-secret

key: MONGO_USERNAME

Save and close this file.

Now that you’re done creating your Secret, it’s time for you to create a database service and an Init Container. Focus on setting up your container in a way that makes it connect only to your database without any issues.

Step 5: Creating the Database Service and an Application Init Container

Creating your database Service and Init Container is one of the most important tasks in this entire process. You probably won’t want your Init Container attempts to connect to any database other than yours. So, be very careful here.

First, open a file:

nano db-service.yaml

Next, define the specifications for the database Service:

~/node_project/db-service.yaml

apiVersion: v1

kind: Service

metadata:

annotations:

kompose.cmd: kompose convert

kompose.version: 1.18.0 (06a2e56)

creationTimestamp: null

labels:

io.kompose.service: db

name: db

spec:

ports:

– port: 27017

targetPort: 27017

selector:

io.kompose.service: db

status:

loadBalancer: {}

The selector will match the Service object with database Pods, defined with the label io.kompose.service: db in the db-deployment.yaml.

Then, open the nodejs-deployment.yaml file with the following command:

nano nodejs-deployment.yaml

Now, add an initContainers field inside the Pod spec and next to the containers array. Navigate to the nodejs containers array and enter this code under the ports and resources field:

~/node_project/nodejs-deployment.yaml

apiVersion: extensions/v1beta1

kind: Deployment

…

spec:

containers:

…

name: nodejs

ports:

– containerPort: 8080

resources: {}

initContainers:

– name: init-db

image: busybox

command: [‘sh’, ‘-c’, ‘until nc -z db:27017; do echo waiting for db; sleep 2; done;’]

restartPolicy: Always

…

Save and close the file after editing.

Step 6: Modifying the PersistentVolumeClaim and Exposing the Application Frontend

Before running your application, you have to make two more changes to make the application work properly. Firstly, you have to navigate to the PersistentVolumeClaim and modify the storage resource. This claim helps the user dynamically provision storage to manage the state of your application.

You need a StorageClass to provision storage resources to work with PersistentVolumeClaims. If you’re working with DigitalOcean Kubernetes, your default StorageClass provisioner would be dobs.csi.digitalocean.com. You can use the following command to check it:

Kubectl get storageclass

Provided that you’re using a DigitalOcean cluster, you would get the below output:

NAME PROVISIONER AGE

do-block-storage (default) dobs.csi.digitalocean.com 76m

If you’re not using a DigitalOcean cluster, you have to create a StorageClass and configure a provisioner.

You also must ensure that your storage resource meets the minimum size criteria of your provisioner. So, you need to modify the PersistentVolumeClaim to use the minimum feasible DigitalOcean Block Storage Unit of 1 GB. Therefore, use the following code to open dbdata-persistentvolumeclaim.yaml:

nano dbdata-persistentvolumeclaim.yaml

Now, you need to set the storage value to 1Gi:

~/node_project/dbdata-persistentvolumeclaim.yaml

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

creationTimestamp: null

labels:

io.kompose.service: dbdata

name: dbdata

spec:

accessModes:

– ReadWriteOnce

resources:

requests:

storage: 1Gi

status: {}

Save and close the file and proceed to the next step. That is, open the nodejs-service.yaml:

nano nodejs-service.yaml

To expose this Service externally, use a DigitalOcean Load Balancer. Navigate to the Service specification and set LoadBalancer as the Service type:

~/node_project/nodejs-service.yaml

apiVersion: v1

kind: Service

…

spec:

type: LoadBalancer

ports:

…

After you’re finished editing, save and close the file.

Step 7: Starting and Accessing the Application

Now, create your Kubernetes objects and test if the application is working as intended. The following command will create the Node application and MongoDB database Services and Deployments. It will also create your ConfigMap, Secret, and PersistentVolumeClaim:

kubectl create -f nodejs-service.yaml,nodejs-deployment.yaml,nodejs-env-configmap.yaml,db-service.yaml,db-deployment.yaml,dbdata-persistentvolumeclaim.yaml,secret.yaml

After the creation of the objects, you will get the following output:

service/nodejs created

deployment.extensions/nodejs created

configmap/nodejs-env created

service/db created

deployment.extensions/db created

persistentvolumeclaim/dbdata created

secret/mongo-secret created

Type the following to check if your Pods are running:

kubectl get pods

Now your db container will start and your Init Container will run. Meanwhile, you will get the following output:

NAME READY STATUS RESTARTS AGE

db-679d658576-kfpsl 0/1 ContainerCreating 0 10s

nodejs-6b9585dc8b-pnsws 0/1 Init:0/1 0 10s

After your database and application containers have started, you will get an output like this:

NAME READY STATUS RESTARTS AGE

db-679d658576-kfpsl 1/1 Running 0 54s

nodejs-6b9585dc8b-pnsws 1/1 Running 0 54s

In case you encounter any unanticipated phases in the STATUS column, you can fix the issue using the commands mentioned below:

kubectl describe pods your_pod

kubectl logs your_pod

Provided that all your containers are running, you can use your application now. Run the following command to get the IP for your LoadBalancer:

kubectl get svc

You will get this output:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

db ClusterIP 10.245.189.250 <none> 27017/TCP 93s

kubernetes ClusterIP 10.245.0.1 <none> 443/TCP 25m12s

nodejs LoadBalancer 10.245.15.56 your_lb_ip 80:30729/TCP 93s

When you find an IP, navigate to it by entering http://your_lb_ip in your browser’s search bar. From the landing page, go to the Get Shark Info. It will take you to another page where you can enter a name and character for your Shark. Enter a Shark Name as you like and set the Shark Character. Now, click Submit and wait a few seconds. You will be navigated to a page showing your Shark info.

And, that’s pretty much it. You will now have a single-instance setup of the Node.js application having a MongoDB database administered by a Kubernetes cluster.

Conclusion

Now that you know how to migrate your Docker Compose workflow to Kubernetes, you can proceed even further. The files you’ve created here can be used to implement many things in the later stages of app development. These include centralized logging and monitoring, backup strategies for your Kubernetes objects, and more. Good luck!

24Sep

How to Install and Use Istio with Kubernetes?

September 24, 2022 admin

Mesh is an infrastructure layer that helps to connect and manage communication with the application’s microservices. Many developers are working on microservices and the mesh services have evolved to make them even more reliable for managing tasks.

Here comes the role of service mesh like Istio, which simplifies the processes such as routing, traffic configuration, discovery, authentication, and monitoring. The main motive of Istio is to work without any changes in the existing code of service. While working with Kubernetes, one can add a service mesh to the currently running task in a cluster by creating the Istio for particular objects.

Here, you will find the accurate tutorial to install and use the Istio using the Helm package manager in Kubernetes. You can also use the Istio to showcase a demo Node.js application to create a route and virtual service resources.

Requirements

Some main requirements for installing Istio with kubernetes;

First, you need to enable the Kubernetes 1.10+ cluster. And the cluster should be (RBAC) role-based access control. Any method could be used to create the cluster with at least 8 gb of memory available.
A command-line kubectl should be installed on a development server. It should be configured for connecting to the cluster.
Further, it is important to install Hem on the development server. Triller should be installed on the cluster.
Development server must be installed with Docker. It is essential to add non-root users to the docker group.

Lastly, you need to set-up the Docker Hub account.

Step-by-Step Guide to Install and Use Istio with Kubernetes

Step 1: Packaging the Application

The primary step is to duplicate the node js-image-demo repository. The repository usually contains the codes describing on how to build a NODE.JS Application, which illustrates exactly how to create an image for a Node.js application. You can locate additional details about the treatment itself in the set from Containers to Kubernetes with NODE.JS.

Further, clone the nodejs-image-demo repository right into a directory known as istio_project

git clone https://github.com/do-community/nodejs-image-demo.git istio_project

Navigate to the istio_project folder;

cd istio_project

This director has reports and folders for a shark details application that gives customers standard details regarding sharks. Apart from the application files, the directory includes a Dockerfile and directives for making a Docker image with the application code.

For testing of the application code and Dockerfile work as anticipated. The docker build command will assist to build and tag the image, and then utilize the image to dash a demo container. Making use of the -t flag with docker build will permit you to trail the image with your Docker Hub username to ensure that you may drive it to Docker Hub after its testing.

Create the image with the help of the command mentioned as follows;

docker build -t your_dockerhub_username/node-demo

In the (.), the command states the build context as the current folder. Rename the image as NODE-DEMO. However, you can rename it with any name you want.

After the completion of the building process, create a list of the image with DOCKER IMAGES;

docker images

Then you will find the below output, confirming the image:

REPOSITORY TAG IMAGE ID CREATED SIZE

your_dockerhub_username/node-demo latest 37f1c2939dbf 5 seconds ago 77.6MB

node 10-alpine 9dfa73010b19 2 days ago

Further, use the DOCKER RUN to make a box based on the image. You can include three flags with the command;

-p: It will publish the slot on the container and map it to a slot on our bunch. Our team will use port 80 on the multitude, yet you can choose a different port if some other process is already running on port 80.

-d: This operates the container in the background.

–name: It will assist in providing the compartment an individualized label.

Now use the below command to create the container:

docker run –name node-demo -p 80:8080 -d your_dockerhub_username/node-demo

Check your running container with docker ps:

docker ps

Then you will get the confirmation that your application is running:

CONTAINER ID IMAGE COMMAND

49a67bafc325 your_dockerhub_username/node-demo “docker-entry point.s…”

Then visit your Server’s IP Address to check your setup: http://your_server_ip

After checking your application, stop the running container by using the docker ps command:

docker ps

You now have a functioning graphic that you can pull to manage your app along with Kubernetes and Istio. Next, you can easily carry on putting up Istio along with Helm.

Step 2: Installing Istio with Helm

Istio supplies different installation strategies, and the documentation encourages making use of Helm to make the most of versatility in handling configuration choices.

First, incorporate the Istio launch storehouse with this command:

helm repo add istio.io https://storage.googleapis.com/istio-release/releases/1.1.7/charts/

Then you will get the istio.io listed repo:

NAME URL

stable https://kubernetes-charts.storage.googleapis.com

local http://127.0.0.1:8879/charts

istio.io https://storage.googleapis.com/istio-release/releases/1.1.7/charts/

Further, with the assistance of istio-init chart, install the Istio’s CRDs (custom resource definitions) using the Helm install command;

helm install –name istio-init –namespace istio-system istio.io/istio-init

Output:

NAME: istio-init

LAST DEPLOYED: Fri Jun 7 17:13:32 2019

NAMESPACE: istio-system

STATUS: DEPLOYED

The following command commits 53 CRDs to the Kube-apiserver. And making it accessible for use in the Istio mesh. It also produces a namespace for the Istio objects known as istio-system and utilizes the –name choice to name the Helm release istio-init. A release of Helm pertains to a specific deployment of a chart with particular configuration choices permitted.

To examine that all of the demanded CRDs have been committed, run the following command:

kubectl get crds | grep ‘istio.io\|certmanager.k8s.io’ | wc –l

It must have an outcome of 53.

Now you can install the istio Chart successfully. To ensure that the Grafana telemetry add-on is put up with the Chart, we will use the –set grafana.enabled=true configuration alternative along with our helm install. Istio possesses various arrangement profile pages to opt for when mounting with Helm that permits you to personalize the Istio command airplane and information aircraft sidecars.

Then you have to give the command to install the Chart:

helm install –name istio –namespace istio-system –set grafana.enabled=true istio.io/istio

To verify the service object with the default account is created, run the command mentioned as follows:

kubectl get svc -n istio-system

The Pods representing these solutions ought to have a STATUS of Running, suggesting that the Pods are tied to nodules in which the compartments connected with the Pods are operating:

NAME READY STATUS RESTARTS AGE

grafana-67c69bb567-t8qrg 1/1 Running 0 4m25s

istio-citadel-fc966574d-v5rg5 1/1 Running 0 4m25s

istio-galley-cf776876f-5wc4x 1/1 Running 0 4m25s

istio-ingressgateway-7f497cc68b-c5w64 1/1 Running 0 4m25s

istio-init-crd-10-bxglc 0/1 Completed 0 9m29s

istio-init-crd-11-dv5lz 0/1 Completed 0 9m29s

istio-pilot-785694f946-m5wp2 2/2 Running 0 4m25s

istio-policy-79cff99c7c-q4z5x 2/2 Running 1 4m25s

istio-sidecar-injector-c8ddbb99c-czvwq 1/1 Running 0 4m24s

istio-telemetry-578b6f967c-zk56d 2/2 Running 1 4m25s

prometheus-d8d46c5b5-k5wmg 1/1 Running 0 4m25s

The last step in the Istio installation will permit the development of Envoy proxies, which will be set up as sidecars to solutions running in the Mesh.

Sidecars are generally made use of to incorporate an additional layer of functionality in existing container atmospheres. Istio’s mesh construction depends on communication between Envoy sidecars, which comprise the data aircraft of the net and the components of the control plane. So as for the Mesh to function, our company needs to guarantee that each Pod in the Mesh will also run an Envoy sidecar.

There are a pair of methods for accomplishing this goal: manual sidecar injection and automatic sidecar injection. You can permit automatic sidecar injection by designating the namespace through which we will generate our application objects with the label istio-injection=enabled. It will guarantee that the MutatingAdmissionWebhook controller can easily obstruct the kube-apiserver and conduct a specific activity– in this particular casing, ensuring that each of our function Pods begins along with a sidecar.

Apply the istio-injection=enables names to a namespace with the following command:

kubectl label namespace default istio-injection=enabled

Step 3: Making Application Objects

You can make an application manifest with requirements of service deployment objects, with the Istio mesh in position and configured to inject sidecar Pods. further, each object’s state is explained well in the specifications in a Kubernetes manifest.

The function Service will undoubtedly ensure that the Pods operating in containers continue to be accessible in a dynamic environment. Every pod is made and destroyed, while the Deployment will define the preferred Condition Pods.

Click on the file names node-app.yaml with nano or any other editor:

nano node-app.yaml

Further, add the given code defines the nodejs services:

`~/istio_project/node-app.yaml

apiVersion: v1

kind: Service

metadata:

name: nodejs

labels:

app: nodejs

spec:

selector:

app: nodejs

ports:

– name: http

port: 8080

The particular service definition consists of a selector. It will likewise match the pods with the corresponding app: nodejs name.

The addition of specification for the application deployment is done by the service below;. Make sure to replace the image with the containers.

apiVersion: apps/v1

kind: Deployment

metadata:

name: nodejs

labels:

version: v1

spec:

replicas: 1

selector:

matchLabels:

app: nodejs

template:

metadata:

labels:

app: nodejs

version: v1

spec:

containers:

– name: nodejs

image: your_dockerhub_username/node-demo

ports:

– containerPort: 8080

The specifications for this Deployment feature the variety of replicas and a selector that defines which Pods the Deployment will handle. It will also handle the Pods with the app: nodejs tag.

When you are finished editing and enhancing, save the report.

Placing this file at point. We can move further for the editing that consists of the definition for gateway and virtual service objects. It also controls the entrance of traffic and its path once there.

Step 4: Creating Istio Objects

To control access to a bunch and also to transmit data to Services, Kubernetes utilizes Ingress Resources Controllers. Entering Resources specify HTTP regulations and HTTPS routing to cluster Services, while Controllers balance inbound web traffic and route it to the correct Services.

Istio uses various sets of objects to achieve identical ends, though along with some essential variations. Rather than using a Controller to manage website traffic, the Istio mesh uses a Gateway, which works as a bunch balancer that handles outgoing and incoming HTTP/TCP relationships.

The minimal application coating capacities that Kubernetes Ingress Controllers and Resources make available to flock drivers certainly do not feature the performances, including sophisticated transmitting, mapping, and telemetry delivered due to the sidecars in the Istio service mesh.

To allow external visitor traffic into the Mesh and set up direct access to the Node app, we will need to make an Istio Gateway and Virtual Service. Open up a data contact node-istio.yaml for the show:

nano node-istio.yaml

Add the definition for gateway object first:

apiVersion: networking.istio.io/v1alpha3

kind: Gateway

metadata:

name: nodejs-gateway

spec:

selector:

istio: ingressgateway

servers:

– port:

number: 80

name: http

protocol: HTTP

hosts:

Aside from supplying a name for this Virtual Service, you can add feature requirements for this source that consist of:

A host area that indicates the location. Within this situation, we’re once more utilizing a wildcard value (*) to enable simple access to the treatment in the browser, given that you are not working with a domain name.
A gateways field that points out the Gateway through which external demands will be enabled. Within this situation, it’s our nodejs-gateway Gateway.

The HTTP area indicates just how HTTP visitor traffic will be routed.

Save and close the documents when you are finished editing and enhancing them.

Along with your yaml files in location, you can easily make your function Service and Deployment. The Gateway and Virtual Service items will be accessible to your function.

Step 5: Creating application resources and allowing telemetry access

After creating the application application Service and Deployment items, including the Gateway and Virtual Service. Now you can easily generate the request to the application and check the linked data in your Istio Grafana dash panels.

Further, A configure Istio is required for exposing the Grafana add-on to ensure you can access the control panels in your browser.

While working in production or sensitive settings, it is advisable to enable getting HTTPS access.

Considering that you established the –set grafana.enabled=true setup possibility when installing Istio. You possess a Grafana Service and Pod in our istio-system namespace,

Along with those resources presently in place, further you have to generate a virtual service for a Gateway to expose the Grafana add-on.

For manifest open the file:

nano node-grafana.yaml

Enter the following code to the node-grafana.yaml file to create a pathway to display and route the traffic to Grafana service:

apiVersion: networking.istio.io/v1alpha3

kind: Gateway

metadata:

name: grafana-gateway

namespace: istio-system

spec:

selector:

istio: ingressgateway

servers:

– port:

number: 15031

name: http-grafana

protocol: HTTP

hosts:

– “*”

—

apiVersion: networking.istio.io/v1alpha3

kind: VirtualService

metadata:

name: grafana-vs

namespace: istio-system

spec:

hosts:

– “*”

gateways:

– grafana-gateway

http:

– match:

– port: 15031

route:

– destination:

host: grafana

port:

number: 3000

Save and exit the file once you are done.

Now run the following command to create Grafana:

kubectl apply -f node-grafana.yaml

The command of kubectl apply will enable a specific configuration to apply to an object while making or updating it.

By entering the following command, you can check the the gateway in the Istio-system;

$ kubectl get gateway -n istio-system

You will get an input like;

Name: Age

Grafana-gateway: 47s

The below command will helps to create the application service and deployment;

kubectl apply -f node-app.yaml

Further check the applications pods after few seconds with the command;

$ kubectl get pods

To inspect the second container as Envoy sidecar, enter the command;

$ kubectl describe pod nodejs-7759fb549f-kmb7x

Then to create an application gateway and Virtual service, run the following command;

kubectl apply -f node-istio.yaml

And for virtual service, by entering the command;

kubectl get virtual service

There should only be the istio-ingressgateway with the TYPE loadbalancer.

At last, now you get the working Node.js application running in an Istio service mesh with Grafana configured and enabled for external accessibility.

Conclusion

In a nutshell, you must have learned to set up Istio using the Helm package manager and used it to reveal a Node.js use Service using Gateway and Virtual Service objects. To reveal the Grafana telemetry add-on, once can configure the Gateway, and the Virtual Service object. This can only be done to check the application’s traffic data.

13Sep

An Educational Discussion on Kubernetes Operators and Their Functions

September 13, 2022 admin

All About Kubernetes Operators and their Functions

Today, Kubernetes is sure to be among the leading orchestration platforms. The number of Kubernetes users continues to increase as time passes. Multiple factors have helped make orchestration platforms popular. Kubernetes is a strong candidate for being the most popular orchestration platform in the future due to its presence of Kubernetes operators.

Existing Kubernetes users are already familiar with the relevance of Kubernetes operators. The concept of the Kubernetes operator may seem vague and complicated for a new user. However, it’s impossible to perform specific tasks on Kubernetes without having knowledge about Kubernetes operators. This article will enlighten Kubernetes beginners about the facts and purposes of Kubernetes operators in detail.

What are Kubernetes Operators?

In order to understand Kubernetes better, you need to be clear about its purpose. As an orchestration platform, Kubernetes is best utilized for creating, managing, and monitoring applications and servers. Kubernetes operators are now responsible for creating and deploying applications on Kubernetes. The Kubernetes operator manages the entire process, from packaging the application content to managing it.

To be specific, a Kubernetes operator can be considered an application-specific controller. You are supposed to utilize different Kubernetes operators in terms of deploying or managing different applications on Kubernetes. The process of deploying and managing an application on Kubernetes becomes possible with the support of Kubernetes API and kubectl tooling. The fundamental function of a Kubernetes operator is to enhance the productivity and efficiency of a Kubernetes API. That’s how a Kubernetes operator eases up the process of configuring and deploying an application.

Deeping diving into the Kubernetes mechanism, you are supposed to know about the existence of control planes in the platform. Every Kubernetes application comes with its own control plane that consists of controllers. Throughout the process of app development, the controllers of the application’s control plane keep utilizing control loops. Now, what are the functions of the loops? Actually, they compare the present state of the entire cluster with the state required to develop the application successfully. Those control loops notify the controllers about mismatches between present states and desired states continuously. The process keeps going on until the app is deployed successfully.

Once the controllers detect that the present state of the cluster is not matching with the requirements, it troubleshoot the issues immediately. A Kubernetes operator remains liable to operate the controllers in terms of completing application developments. Such an operator utilizes custom resources for managing the application it is dedicated to. When a programmer inputs a specific configuration for an application, the configuration consists of complicated and high-level directives. A Kubernetes operator transforms those high-level directives into easy and low-level actions.

Be it upgrading the version of an application, or scaling an application, a Kubernetes operator does it all concisely. That’s what makes Kubernetes operators inseparable parts of Kubernetes.

The Working Procedure of Kubernetes Operators

As you have attained adequate information about Kubernetes operators, you may be curious about how they work. This segment will describe the functional procedure of Kubernetes operators.

When it comes to the functional procedures of Kubernetes operators, you need to know about Stateless applications and Stateful applications. Firstly, what can be considered Stateless applications? Well, web applications, API services, and mobile backends can be considered stateless applications. Why? Because these applications don’t demand additional knowledge about their functional attributes. The basic, in-built infrastructure of Kubernetes is efficient enough to handle such stateless applications.

Now, let’s focus on Stateful applications. Applications that demand domain-specific expertise are considered stateful applications. Monitoring applications or databases can be categorized under this category. The basic Kubernetes infrastructure doesn’t possess the efficiency to scale and upgrade stateful applications. That’s why Kubernetes requires Kubernetes operators to manage stateful applications.

The job of a Kubernetes Operator is to get the domain-specific knowledge encoded in a particular Kubernetes extension. That’s how the operator eases up the task of scaling a stateful application for Kubernetes. The domain-specific knowledge enforced into the Kubernetes extension helps Kubernetes automate the life-cycle of the specific application as well.

Another major function of a Kubernetes operator is to eliminate manual application management tasks from the cluster where the application is deployed. Naturally, that makes it easier for Kubernetes to scale the application and configure it accordingly.

On top of that, a developer can distribute software on Kubernetes clusters without worrying about support infrastructures with a Kubernetes operator. The operator makes that possible by addressing application-specific problems and fixing them. Alongside, you get the opportunity to write additional codes to automate applications beyond the automation features of Kubernetes. This feature, at times, comes in handy.

It can be stated with confidence that a Kubernetes operator functions identically as a human operator. The operator pattern present in a Kubernetes operator detects the probable human approach towards scaling and maintaining a service. The operator pattern prompts the operator to act similarly. That’s why Kubernetes operators are extremely friendly and easy to work with. You can utilize the Kubernetes operator software development kit to create a specialized operator according to your requirements.

What are you supposed to know about the Operator Framework?

Like every other software architecture, a Kubernetes operator comes with a framework too. Actually, the operator framework offers Kubernetes tools to the developer and the runtime as an open-source project. With those tools, you can customize your operator to build a specific application on Kubernetes.

Now, you may question the contents of the operator framework. Let’s have a glance at what gets included in the operator framework-

Firstly, you get an operator SDK tool that helps you create your customized operator even without the basic knowledge of Kubernetes APIs.
Alongside, an operator lifecycle management tool also remains present in the operator framework package. This one assists you in managing the lifecycle of an operator.
Lastly, the operator monitoring tool helps you to determine operator usage.

These are the tools that you get in an operator framework. With these tools and your expertise, you can build a Kubernetes operator as you want.

Wrapping up

There’s no alternative to a Kubernetes operator in terms of building an application on Kubernetes that demands domain-specific knowledge. This article has offered complete knowledge about Kubernetes operators. Also, we have described the functional procedures of Kubernetes operators in depth.
Kubernetes operators are the best options to scale and monitor complicated applications with special features. As a developer, you can’t turn down the utility and necessity of Kubernetes operators. If you’ve started developing applications with Kubernetes recently, we strongly recommend you utilize Kubernetes developers to enhance your productivity. Now it’s your turn to use your knowledge of Kubernetes operators and generate outstanding results.

12Sep

How to Manage Your Kubernetes Configurations with Kustomize?

September 12, 2022 admin

How to Manage Your Kubernetes Configurations with Kustomize?

Kustomize is among the most valuable technologies inside Kubernetes, used for easing installation. Yes, it allows you to build a full Kubernetes service out of separate parts without altering their YAML configuration settings.

Here, you’ll get to know about kustomize and see how it functions with a basic WordPress installation. Moreover, you will explore how to use kustomize with kubectl, and the advantages of kutomize for large-scale operations. What is or isn’t correct is no longer relevant, as kustomize capability is now a standard component of the kubectl binary.

The Purpose behind kustomize

Kustomize is inspired by Helms in many ways, including the need to give application setup but with the opportunity to adapt the configuration to fit a specific purpose or environment. It aims to offer this for both bespoke and commercial off-the-shelf (COTS) applications.

The approach varies from Helm’s in that it insists on using YAML for customization settings instead of an obscure templating dialect. It’s safe to assume that DevOps professionals who deal with Kubernetes are already aware of the API service and YAML syntax demanded to define them. At least in principle, familiarity facilities painless adoption.

Kutomize may add a common field to a variety of resources, such as a label or annotation, change the setting of the current field, for instance, a Deployment’s amount of copies, and partly patch resources supplied as a “base” configuration. It also constructs configMap and secret resource settings from their canonical resource definitions.

What does Kustomize function?

Kustomize Is indeed a Kubernetes item configuration controller with the command-line interface. From version 1.14, it has been linked with kubectl, allowing you to perform declarative modifications to your setups without having to alter the templates. You can, for illustration, mix elements for several sources, preserving your adaptations or customizations., even as the matter could be – in version control systems, and develop overlays for certain scenarios.

Kutomize makes this possible by allowing you to create a document that binds it all together, or by including “overwhelms” for particular settings.

Following the below given steps to explore more;

Step 1: Deploy apps without kustomize

You would first launch your application in a much conventional fashion before using kustomize. Inside this Scenario, you will use NgnixI to serve a development edition of Sammy-app, a dynamic web service. Your site contents will be stored as information in a ConfigMap that will be mounted on a Pod in a deployment. All of them will necessitate the creation of a distinct YAML file, which you will do immediately.

Create a folder for your program and each of the configuration files initially;

mkdir ~/sammy-app && cd ~/sammy-app

All of the instructions in the guide will run from here.

In the home directory, create a new folder. You have given it the name sammy-app plus saved some HTML website content in information. Your file should be saved and closed.

Now make a new file named deployment.yml and enter it.

nano deployment.yml

Add the following;

apiVersion: apps/v1

kind: Deployment

metadata:

name: sammy-app

namespace: default

labels:

app: sammy-app

spec:

replicas: 1

selector:

matchLabels:

app: sammy-app

template:

metadata:

labels:

app: sammy-app

spec:

containers:

– name: server

image: nginx:1.17

volumeMounts:

– name: sammy-app

mountPath: /usr/share/nginx/html

ports:

– containerPort: 80

protocol: TCP

resources:

requests:

cpu: 100m

memory: “128M”

limits:

cpu: 100m

memory: “256M”

env:

– name: LOG_LEVEL

value: “DEBUG”

volumes:

– name: sammy-app

configMap:

name: sammy-app

items:

– key: body

path: index.html

This standard adds a new deploy item to the system. The title and label of sammy-app are added, the quantity of replicas is set at 1, and also the object is set to utilize the Ngnix edition 1.17 docker container.

Output

NAME READY STATUS RESTARTS AGE

sammy-app-56bbd86cc9-chs75 1/1 Running 0 8s

You are also changing the container’s address to 80, establishing CPU and memory demands and limits, and turning on DEBUG logging.

Even when your pods are up and operating, and are supported by a deployment, you are still unable to access the application. You should first make a service.

Make a 3rd YAML file named service.yml, then open it. Now you may start using the service on your Kubernetes cluster.

Take a few seconds before checking the status of the application using kubectl. Your external IP would be replaced by a unique IP address.

Cut/paste the IP address that depicts into your internet browser. You will notice your app’s DEVELOPMENT edition. Stop viewing your service, USe CTRL+C from the desktop.

Step 2: Use Kustomize for application deployment

You will install the same application inside the stage, although in the format kutomize anticipates rather than the normal kubernetes way.

You just have to add one file, customization.yml, to get this application deployable using kutomize.

nano kustomization.yml

That file will give the information to kubectl what service to handle when using the -k option, which tells kubectl to analyze thge kustomization file. Your file shoukd be saved and closed.

Now add the below command;

Resource:

– Configmap.yml

– Deployment.yml

– Service.yml

Save and exit it.

Next, when you re-deploy, remove the kubernetes service you created in step 1.

kubectl delete deployment/sammy-app service/sammy-app configmap/sammy-app

And then re-deploy them, this time using Kustomize.

kubectl apply -k .

The ConfigMap, Deploy, and Service are all created as a result of this. Verify your deployment with the get pods function.

kubectl get pods -l app=sammy-app

In the READY column, you will find a one pod containing your program executing and 1/1 containers. Restart the get process command immediately. Your service would additionally have a publicly available EXTERNAL-IP.

kubectl get services -l app=sammy-app

Step 3: Kustomize for monitoring application variability

While engaging with many resource types, particularly if there are minor changes across environments, application servers for Kubernetes resources can quickly become bloated just as the development versus production. Instead of having a deployment.yml, you may have deployment-development.yml plus deployment-production.yml.

The Scenario may be the same for each of your additional services. Consider what would happen if the latest version of the Nginx Docker image was published and you wanted to use it right away. Perhaps you want to proceed after testing the new edition in deployment-development.yml, but you neglect to update deployment-production.yml also with the new edition. Suddenly, the edition of Nginx you are using in development differs from the edition used in output. Small setup issues like these might cause your application to crash often.

Their administrative challenges can be substantially simplified using kustomize. Keep in mind that you currently possess a filesystem containing your Kubernetes configuration settings and customization.yml file.

sammy-app/

── configmap.yml

── deployment.yml

── kustomization.yml

── service.yml

The file would define the overlay’s basis, and the patching technique kubernetes will employ. To refresh the CongiMap and deploy resources, you can use a strategic-merge-stype fix in this case.

The file should be saved and closed.

At last, under the overlays.production.directory, create a new deployment.yml and configmap.yml files.

Now you are ready to use your base setup to deploy. Uninstall the current resource immediately. Deploy the kubernetes basic setup. Make sure that deployment is in proper condition.

Just one EXTERNAL-IP of the service, you will find the anticipated base setup, with the development versions showing. Now, you have to put the production setup into action. Examine your deployment once again. Just EXTERNAL-IP of the service, you will get the expected production setup, with the production model displayed.

In the production arrangement, you will see three Pods rather than one. Tool, you can check the deployment resources to see if the less visible modifications have gone into effect.

To see the production edition of your website, go to your external-ip in a browser. Kustomize is increasingly being used to control application variance. Returning to one of your initial issues, if you now wish to update the Nginx image edition, all you have to do is alter deployment.yml in the foundation, and all your layers that utilize that foundation will also receive the update via Kustomize. This streamlines your development process, enhances readability, and lowers the risk of mistakes.

What are the advantages of adopting kustomize?

Now you must have ensured about every detail of kustomize’s main advantages, that incorporates;

1. Declarative template

Kubernetes and Kustomize both employ a declarative method to system configuration.

2. Consolidation of codebases which is easy to follow

Monitoring and administration are simplified by applying chosen patches via a centralized file that may be stored under version controls.

3. Using kubectl for integration

There have been no new dependencies or prerequisites to bother about because Kustomize is already included in the basic Kubernetes toolset.

Conclusion

In a nutshell, with the above given steps, you must have created a web app or deployed that to kubernetes. Afterward, you utilize kustomize to make managing your application’s setup for various contexts a lot easier. You have created a layer model out of a collection of identical YAML files.

It will definitely assist you to avoid mistakes in manual setups. And will make your work more precise and manageable. Meanwhile, This is only a small part of what kustomize has to offer in Kubernetes.

08Sep

How to Set Up an Nginx Ingress with Cert-Manager on DigitalOcean Kubernetes

September 8, 2022 admin

With Kubernetes Ingresses, you can flexibly route traffic from outside your Kubernetes cluster to Services that are present inside of your cluster. This task is performed with the use of Ingress Resources and Ingress Controllers. Ingress Resources aid in defining the rules which facilitate routing of HTTP and HTTPS traffic to Kubernetes Services. Ingress Controllers, on the other hand, aid in implementing the rules by load balancing traffic. These controllers also route it to the proper backend services.

Some of the most popular Ingress Controllers are Nginx, HAProxy, Traefik, and Contour. Ingresses help in providing an alternative of setting up multiple LoadBalancer services. All of these services have their own LoadBalancer.

This post will guide you with setting up the Kubernetes-maintained Nginx Ingress Controller. To support routing of traffic to many dummy backend services, it also creates some Ingress Resources. Once you have set up the Ingress, you will be installing the cert-manager into your cluster. This will help in managing and provisioning TLS certificates. Also, it will help you in encrypting HTTP traffic to the Ingress.

Before you proceed with the steps for setting up an Nginx Ingress with a cert-manager on DigitalOcean Kubernetes, there are certain prerequisites that you need to check out in the next section.

Prerequisites

A Kubernetes 1.15+ cluster with role-based access control (RBAC) enabled. This setup will utilize a DigitalOcean Kubernetes cluster. However, you can also create a cluster with the use of another kubernetes service.

The kubectl command-line tool must be installed on your local machine. It must be configured in a way that it gets connected to your cluster.

A domain name and DNS A records that allow you to point to the DigitalOcean Load Balancer used by the Ingress.

The wget command-line utility is installed on your local machine. You can also get wget installed with the use of the package manager that is built into your operating system.

How to Set Up an Nginx Ingress with Cert-Manager on DigitalOcean Kubernetes?

Here are the steps that will help you to set up an Nginx Ingress with cert-manager on DigitalOcean Kubernetes with ease:

1. Setting up dummy backend services

Before you start deploying the Ingress Controller, you would be required to create and roll out two dummy echo services. This will aid in routing external traffic with the use of Ingress. The echo Services will run the hashicorp/http-echo web server container. It will return to a page that will be containing a text string passed in when the web server is launched.

Now you will be creating and editing a file called echo1.yaml using nano or your favorite editor on your local machine:-

$ nano echo1.yaml

Paste in the following Service and Deployment manifest:

echo1.yaml

apiVersion: v1

kind: Service

metadata:

name: echo1

spec:

ports:

– port: 80

targetPort: 5678

selector:

app: echo1

—

apiVersion: apps/v1

kind: Deployment

metadata:

name: echo1

spec:

selector:

matchLabels:

app: echo1

replicas: 2

template:

metadata:

labels:

app: echo1

spec:

containers:

– name: echo1

image: hashicorp/http-echo

args:

– “-text=echo1”

ports:

– containerPort: 5678

In this file, you will be defining a Service called echo1. It will be routing traffic to Pods with the app: echo1 label selector. It also accepts TCP traffic on port 80 and further aids in routing it to port 5678, http-echo’s default port.

Then you will be defining a Deployment which is named echo1; it helps in managing the Pods with the app: echo1 Label Selector. You are required to specify that the Deployment should be having 2 Pod replicas and that the Pods should be starting a container named echo1 running the hashicorp/http-echo image. Then you pass in the text parameter and further set it to echo1 so that the http-echo web server will return to echo1. Finally, you will be opening up port 5678 on the Pod container.

Once you get satiated with your dummy Service and Deployment manifest, you can save and close the file.

Then, you will be creating the Kubernetes resources with the use of kubectl apply with the -f flag. It specifies the file that has been just saved as a parameter:

$ kubectl apply -f echo1.yaml

Output:

service/echo1 created

Deployment.apps/echo1 created

Now you need to reevaluate that the Service has been started correctly. You can do so by confirming that it has a ClusterIP. ClusterIP is the internal IP on which the Service gets exposed:

$ kubectl get svc echo1

Output:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

echo1 ClusterIP 10.245.222.129 <none> 80/TCP 60s

This points towards the fact that the echo1 Service is now available internally at 10.245.222.129 on port 80. It will further facilitate the forwarding of traffic to containerPort 5678 on the Pods that it selects.

Since the echo1 Service is up and running smoothly, you can repeat the same process for the echo2 Service as well.

Follow these steps to do that:-

You will be creating and opening a file named echo2.yaml:

echo2.yaml

apiVersion: v1

kind: Service

metadata:

name: echo2

spec:

ports:

– port: 80

targetPort: 5678

selector:

app: echo2

—

apiVersion: apps/v1

kind: Deployment

metadata:

name: echo2

spec:

selector:

matchLabels:

app: echo2

replicas: 1

template:

metadata:

labels:

app: echo2

spec:

containers:

– name: echo2

image: hashicorp/http-echo

args:

– “-text=echo2”

ports:

– containerPort: 5678

Here, you will utilize the same Service and Deployment manifest as above. But this time, you will be naming and relabelling the Service and Deployment echo2. Along with that, you will be creating only 1 Pod replica. You also need to make sure that you set the text parameter to echo2 so that the webserver gets returned to the text echo2.

Save and close the file. Finally, proceed with creating the Kubernetes resources using kubectl:

$ kubectl apply -f echo2.yaml

Output:

service/echo2 created

Deployment.apps/echo2 created

Once again, you need to reevaluate that the Service is up and running:

$ kubectl get svc

You should also be seeing that both the echo1 and echo2 Services are with their respective assigned ClusterIPs.

Output:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

echo1 ClusterIP 10.245.222.129 <none> 80/TCP 6m6s

echo2 ClusterIP 10.245.128.224 <none> 80/TCP 6m3s

kubernetes ClusterIP 10.245.0.1 <none> 443/TCP 4d21h

Now since your dummy echo web services are up and running, you can proceed on to rolling out the Nginx Ingress Controller.

2. Setting up the Kubernetes Nginx Ingress Controller

Here, you will be rolling out v0.34.1 of the Kubernetes-maintained Nginx Ingress Controller. The instructions provided in this post are based on those from the official Kubernetes Nginx Ingress Controller installation guide.

The Nginx Ingress Controller comprises a pod. This pod aids in running the Nginx web server. It also watches the Kubernetes Control Plane for new and updated Ingress Resource objects. An Ingress resource can be defined as a list of traffic routing rules for backend Services. The use of Ingress Resources allows you to perform host-based routing: for instance, routing requests that hit web1.your_domain.com to the backend Kubernetes Service web1.

In this particular scenario, since you are deploying the Ingress Controller to a DigitalOcean Kubernetes cluster, the Controller will thereby be creating a LoadBalancer Service that aids in provisioning a DigitalOcean Load Balancer. All external traffic will be directed to it. This Load Balancer will facilitate routing of external traffic to the Ingress Controller Pod running Nginx. Further, it aids in forwarding traffic to the appropriate backend Services.

You will start this process by creating the Nginx Ingress Controller Kubernetes resources. These comprise of ConfigMaps, which contain the Controller’s configuration, Role-based Access Control (RBAC) Roles to grant the Controller access to the Kubernetes API, and the actual Ingress Controller Deployment, which utilizes v0.34.1 of the Nginx Ingress Controller image. To have a look at the full list of these required resources, you can choose to consult the manifest from the Kubernetes Nginx Ingress Controller’s GitHub repo.

In order to create the resources, you can use kubectl apply and the -f flag. It will help you in specifying the manifest file that is hosted on GitHub:

$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v0.34.1/deploy/static/provider/do/deploy.yaml

You make the use of ‘applying’ command here so that in the future, you can incrementally apply changes to the Ingress Controller objects in place of completely overwriting them.

You would see an output resembling the following:

Output:

namespace/ingress-nginx created

serviceaccount/ingress-nginx created

configmap/ingress-nginx-controller created

clusterrole.rbac.authorization.k8s.io/ingress-nginx created

clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx created

role.rbac.authorization.k8s.io/ingress-nginx created

rolebinding.rbac.authorization.k8s.io/ingress-nginx created

service/ingress-nginx-controller-admission created

service/ingress-nginx-controller created

Deployment.apps/ingress-nginx-controller created

validatingwebhookconfiguration.admissionregistration.k8s.io/ingress-nginx-admission created

clusterrole.rbac.authorization.k8s.io/ingress-nginx-admission created

clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx-admission created

job.batch/ingress-nginx-admission-create created

job.batch/ingress-nginx-admission-patch created

role.rbac.authorization.k8s.io/ingress-nginx-admission created

rolebinding.rbac.authorization.k8s.io/ingress-nginx-admission created

serviceaccount/ingress-nginx-admission created

This output also serves as a convenient summary of all the Ingress Controller objects that you have created from the deploy.yaml manifest.

Now, you need to confirm that the Ingress Controller Pods have started:

$ kubectl get pods -n ingress-nginx \

$ -l app.kubernetes.io/name=ingress-nginx –watch

Output:

NAME READY STATUS RESTARTS AGE

ingress-nginx-admission-create-l2jhk 0/1 Completed 0 13m

ingress-nginx-admission-patch-hsrzf 0/1 Completed 0 13m

ingress-nginx-controller-c96557986-m47rq 1/1 Running 0 13m

To return to your prompt you can press Ctrl+C.

Now, you need to confirm that the DigitalOcean Load Balancer has been successfully created. You can do so by fetching the Service details with kubectl:

$ kubectl get svc –namespace=ingress-nginx

After several minutes, you would be seeing an external IP address. It will be corresponding to the IP address of the DigitalOcean Load Balancer.

Output:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

ingress-nginx-controller LoadBalancer 10.245.201.120 203.0.113.0 80:31818/TCP,443:31146/TCP 14m

ingress-nginx-controller-admission ClusterIP 10.245.239.119 <none> 443/TCP 14m

You must note down the Load Balancer’s external IP address. You will be requiring it in a later step.

This load balancer will be receiving traffic on HTTP and HTTPS ports 80 and 443. It also forwards it to the Ingress Controller Pod. The Ingress Controller finally promotes routing the traffic to the appropriate backend Service.

3. Creating the Ingress Resource

We will start this step by creating a minimal Ingress Resource. It will help in routing traffic directed at a given subdomain to a corresponding backend Service.

In this step, you will be making use of the test domain example.com. You can replace this with your own domain name.

Start with creating a simple rule which will route traffic directed at echo1.example.com to the echo1 backend service and traffic directed at echo2.example.com to the echo2 backend service.

Start by opening up a file named echo_ingress.yaml in your favourite editor:

$ nano echo_ingress.yaml

Then, paste in the following ingress definition:

echo_ingress.yaml

apiVersion: networking.k8s.io/v1beta1

kind: Ingress

metadata:

name: echo-ingress

spec:

rules:

– host: echo1.example.com

http:

paths:

– backend:

serviceName: echo1

servicePort: 80

– host: echo2.example.com

http:

paths:

– backend:

serviceName: echo2

servicePort: 80

Once you are finished editing the Ingress rules, you can save and close the file.

Here, you will be creating an Ingress Resource called echo-ingress, and route traffic based on the Host header. An HTTP request Host header helps in specifying the domain name of the target server. Requests with host echo1.example.com will be directed to the echo1 backend set up in Step 1, and requests with host echo2.example.com will be directed to the echo2 backend.

You can now proceed with creating the Ingress using kubectl:

$ kubectl apply -f echo_ingress.yaml

Output:

ingress.networking.k8s.io/echo-ingress created

In order to test the Ingress, you can navigate to your DNS management service and create A records for echo1.example.com and echo2.example.com pointing to the DigitalOcean Load Balancer’s external IP. The Load Balancer’s external IP is the external IP address for the ingress-nginx Service. It is the same external IP address that we fetched in the previous step.

Once the echo1.example.com and echo2.example.com DNS records have been created, you can test the Ingress Controller and Resource that you have created using the curl command-line utility.

From your local machine, curl the echo1 Service:

$ curl echo1.example.com

Output:

echo1

This confirms that your request to echo1.example.com is being correctly routed through the Nginx ingress to the echo1 backend Service.

Now, you are required to perform the same test for the echo2 Service:

$ curl echo2.example.com

Output:

echo2

This helps in verifying that your request to echo2.example.com is correctly routed through the Nginx ingress to the echo2 backend Service.

By this time, you would have successfully set up a minimal Nginx Ingress. It will perform virtual host-based routing.

4. Installing and Continuing Cert-Manager

This step will guide you to install v0.16.1 of cert-manager into your cluster. Cert-Manager is primarily a Kubernetes add-on. It helps in provisioning TLS certificates from Let’s Encrypt and other certificate authorities (CAs). It also helps in managing their life cycles.

Certificates can be automatically requested and configured. This can be done by annotating Ingress Resources, appending a tls section to the Ingress spec, and configuring one or more Issuers or ClusterIssuers to specify your preferred certificate authority. To learn more about Issuer and ClusterIssuer objects, you can go through the official cert-manager documentation on Issuers.

Start by installing the cert-manager and its Custom Resource Definitions (CRDs) like Issuers and ClusterIssuers. You can do so by following the official installation instructions. You must keep in mind that a namespace called cert-manager will be created into which the cert-manager objects will be created:

$ kubectl apply –validate=false -f https://github.com/jetstack/cert-manager/releases/download/v0.16.1/cert-manager.yaml

Output:

customresourcedefinition.apiextensions.k8s.io/certificaterequests.cert-manager.io created

customresourcedefinition.apiextensions.k8s.io/certificates.cert-manager.io created

customresourcedefinition.apiextensions.k8s.io/challenges.acme.cert-manager.io created

customresourcedefinition.apiextensions.k8s.io/clusterissuers.cert-manager.io created

. . .

deployment.apps/cert-manager-webhook created

mutatingwebhookconfiguration.admissionregistration.k8s.io/cert-manager-webhook created

validatingwebhookconfiguration.admissionregistration.k8s.io/cert-manager-webhook created

To reevaluate the installation, you can check the cert-manager Namespace for running pods:

$ kubectl get pods –namespace cert-manager

Output:

NAME READY STATUS RESTARTS AGE

cert-manager-578cd6d964-hr5v2 1/1 Running 0 99s

cert-manager-cainjector-5ffff9dd7c-f46gf 1/1 Running 0 100s

cert-manager-webhook-556b9d7dfd-wd5l6 1/1 Running 0 99s

This points out towards successful installation of the cert-manager.

Now before you get started with issuing certificates for our echo1.example.com and echo2.example.com domains, you will be creating an Issuer. It will help in specifying the certificate authority from which you can get the signed x509 certificates. In this guide, you will be using the Let’s Encrypt certificate authority. It helps in providing free TLS certificates. It also offers both a staging server for testing your certificate configuration and a production server that rolls out verifiable TLS certificates.

Proceed with creating a test ClusterIssuer to ensure that the certificate provisioning mechanism is functioning properly. A ClusterIssuer is not namespace-scoped. Certificate resources can even use it in any namespace.

Start with opening a file named staging_issuer.yaml in your favorite text editor:

nano staging_issuer.yaml

Then, paste in the following ClusterIssuer manifest:

staging_issuer.yaml

apiVersion: cert-manager.io/v1alpha2

kind: ClusterIssuer

metadata:

name: letsencrypt-staging

namespace: cert-manager

spec:

acme:

# The ACME server URL

server: https://acme-staging-v02.api.letsencrypt.org/directory

# Email address used for ACME registration

email: your_email_address_here

# Name of a secret used to store the ACME account private key

privateKeySecretRef:

name: letsencrypt-staging

# Enable the HTTP-01 challenge provider

solvers:

– http01:

ingress:

class: Nginx

Here you will specify that you need to create a ClusterIssuer called letsencrypt-staging. You will then be using the Let’s Encrypt staging server. You will later utilize the production server to roll out certificates. But the downside is that the production server rate-limits requests made against it. Hence, for testing purposes, you should use the staging URL.

Then you will be specifying an email address to register the certificate and will create a Kubernetes Secret called letsencrypt-staging. It will store the ACME account’s private key. You also need to use the HTTP-01 challenge mechanism.

Now, you are required to roll out the ClusterIssuer by using the following command:

$ kubectl create -f staging_issuer.yaml

Output:

clusterissuer.cert-manager.io/letsencrypt-staging created

You are then required to repeat this process. It will help in creating the production ClusterIssuer. You must keep in mind that the certificates will only be created after annotating and updating the Ingress resource that has been provisioned in the previous step.

Now, Open a file called prod_issuer.yaml in your favourite editor:

nano prod_issuer.yaml

Then, paste in the following manifest:

prod_issuer.yaml

apiVersion: cert-manager.io/v1alpha2

kind: ClusterIssuer

metadata:

name: letsencrypt-prod

namespace: cert-manager

spec:

acme:

# The ACME server URL

server: https://acme-v02.api.letsencrypt.org/directory

# Email address used for ACME registration

email: your_email_address_here

# Name of a secret used to store the ACME account private key

privateKeySecretRef:

name: letsencrypt-prod

# Enable the HTTP-01 challenge provider

solvers:

– http01:

ingress:

class: Nginx

Note the different ACME server URLs and the letsencrypt-prod secret key name.

When you have finished editing, you can save and close the file.

Then roll out this Issuer using kubectl command like this:

$ kubectl create -f prod_issuer.yaml

Output:

clusterissuer.cert-manager.io/letsencrypt-prod created

Now that you have created your Let’s Encrypt staging and prod ClusterIssuers, you can modify the Ingress Resource that has been created above. You can even enable TLS encryption for the echo1.example.com and echo2.example.com paths.

If you are using DigitalOcean Kubernetes, you are required to start with implementing a workaround. This allows the Pods to communicate with other Pods using the Ingress. If you’re not using DigitalOcean Kubernetes, you can simply jump to Step 6.

5. Enabling Pod Communication through the Load Balancer (optional step)

Before the provisioning of certificates from Let’s Encrypt gets started, the cert-manager will first perform a self-check. It will do so to make sure that Let’s Encrypt is able to reach the cert-manager Pod that validates your domain. You will need to enable Pod-Pod communication through the Nginx Ingress load balancer, for this check to pass on DigitalOcean Kubernetes.

To do this, you will be creating a DNS A record that points to the external IP of the cloud load balancer. It must also annotate the Nginx Ingress Service manifest with this subdomain.

You will start by navigating to your DNS management service. Then you will create an A record for workaround.example.com that will point to the DigitalOcean Load Balancer’s external IP. The Load Balancer’s external IP refers to the external IP address for the ingress-nginx Service, which you fetched in Step 2. Here we use the subdomain workaround but you’re free to use whichever subdomain you prefer.

Once you have created a DNS record that points to the Ingress load balancer, proceed with annotating the Ingress LoadBalancer Service with the do-loadbalancer-hostname annotation. Then open a file named ingress_nginx_svc.yaml in your favorite editor and simply paste in the following LoadBalancer manifest:

ingress_nginx_svc.yaml

apiVersion: v1

kind: Service

metadata:

annotations:

service.beta.kubernetes.io/do-loadbalancer-enable-proxy-protocol: ‘true’

service.beta.kubernetes.io/do-loadbalancer-hostname: “workaround.example.com”

labels:

helm.sh/chart: ingress-nginx-2.11.1

app.kubernetes.io/name: ingress-nginx

app.kubernetes.io/instance: ingress-nginx

app.kubernetes.io/version: 0.34.1

app.kubernetes.io/managed-by: Helm

app.kubernetes.io/component: controller

name: ingress-nginx-controller

namespace: ingress-nginx

spec:

type: LoadBalancer

externalTrafficPolicy: Local

ports:

– name: http

port: 80

protocol: TCP

targetPort: http

– name: https

port: 443

protocol: TCP

targetPort: https

selector:

app.kubernetes.io/name: ingress-nginx

app.kubernetes.io/instance: ingress-nginx

app.kubernetes.io/component: controller

This Service manifest was extracted from the complete Nginx Ingress manifest file that you had installed in Step 2. Keep in mind to copy the Service manifest, which is corresponding to the Nginx Ingress version that you had installed. In this tutorial, the Nginx Ingress version is 0.34.1. Just make sure to set the do-loadbalancer-hostname annotation to the workaround.example.com domain.

When you are finished, you can save and close the file.

Now, modify the running ingress-nginx-controller Service using the kubectl apply command shown below:

kubectl apply -f ingress_nginx_svc.yaml

Output:

service/ingress-nginx-controller configured

This verifies that you’ve annotated the ingress-nginx-controller Service. This also points out that the Pods in your cluster are now able to communicate with one another utilizing this ingress-nginx-controller Load Balancer.

6. Issuing Staging and Production Let’s Encrypt Certificates

To issue a staging TLS certificate for your domains, you will be annotating echo_ingress.yaml with the ClusterIssuer that you created in Step 4. This will further utilize the ingress-shim to automatically create and issue certificates for those domains that are specified in the Ingress manifest.

Now, open up echo_ingress.yaml in your favorite editor:

$ nano echo_ingress.yaml

Proceed with adding the following to the Ingress resource manifest:

echo_ingress.yaml

apiVersion: networking.k8s.io/v1beta1

kind: Ingress

metadata:

name: echo-ingress

annotations:

cert-manager.io/cluster-issuer: “letsencrypt-staging”

spec:

tls:

– hosts:

– echo1.example.com

– echo2.example.com

secretName: echo-tls

rules:

– host: echo1.example.com

http:

paths:

– backend:

serviceName: echo1

servicePort: 80

– host: echo2.example.com

http:

paths:

– backend:

serviceName: echo2

servicePort: 80

Here you will be adding an annotation that will set the cert-manager ClusterIssuer to letsencrypt-staging. This is the same test certificate ClusterIssuer that you created while following Step 4.

You would also be adding a tls block that will specify the hosts you want to acquire the certificates and specify a secretName. This secret will comprise the TLS private key and issued certificate. You just need to ensure that you swap out example.com with the domain for which you have created DNS records.

Now once you have made the changes, you can save and close the file.

Now you will be pushing this update to the existing Ingress object utilizing kubectl apply:

$ kubectl apply -f echo_ingress.yaml

Output:

ingress.networking.k8s.io/echo-ingress configured

You can utilize kubectl describe to trail the state of the Ingress changes you’ve made:

$ kubectl describe Ingress

Output:

Events:

Type Reason Age From Message

—- —— —- —- ——-

Normal UPDATE 6s (x3 over 80m) nginx-ingress-controller Ingress default/echo-ingress

Normal CreateCertificate 6s cert-manager Successfully created Certificate “echo-tls”

Once you have successfully created the certificate, you may run a description on it, which will ascertain its successful creation:

$ kubectl describe certificate

Output:

Events:

Type Reason Age From Message

—- —— —- —- ——-

Normal Requested 64s cert-manager Created new CertificateRequest resource “echo-tls-vscfw”

Normal Issuing 40s cert-manager The certificate has been successfully issued

This ascertains that the TLS certificate has been successfully issued and HTTPS encryption is now effective for the two domains that are configured.

You can now send a request to a backend echo server. It will assess that HTTPS is working correctly.

You need to run the following wget command to send a request to echo1.example.com and print the response headers to STDOUT:

wget –save-headers -O- echo1.example.com

Output:

. . .

HTTP request sent, awaiting response… 308 Permanent Redirect

. . .

ERROR: cannot verify echo1.example.com’s certificate, issued by ‘CN=Fake LE Intermediate X1’:

Unable to locally verify the issuer’s authority.

To connect to echo1.example.com insecurely, use `–no-check-certificate’.

This points out that HTTPS has been successfully enabled, but at the same time the certificate cannot be verified. This is because it’s a fake temporary certificate that has been issued by the Let’s Encrypt staging server.

Now that you have tested that everything works using this temporary fake certificate, you can progress with rolling out production certificates for the two hosts echo1.example.com and echo2.example.com. To do this, you will be using the letsencrypt-prod ClusterIssuer.

You need to update echo_ingress.yaml to use letsencrypt-prod:

$ nano echo_ingress.yaml

Then, make the following changes to the file:

echo_ingress.yaml

apiVersion: networking.k8s.io/v1beta1

kind: Ingress

metadata:

name: echo-ingress

annotations:

cert-manager.io/cluster-issuer: “letsencrypt-prod”

spec:

tls:

– hosts:

– echo1.example.com

– echo2.example.com

secretName: echo-tls

rules:

– host: echo1.example.com

http:

paths:

– backend:

serviceName: echo1

servicePort: 80

– host: echo2.example.com

http:

paths:

– backend:

serviceName: echo2

servicePort: 80

Here, you will be updating the ClusterIssuer name to letsencrypt-prod.

Once you are satiated with the changes that you have made, proceed with saving and closing the file.

Roll out the changes using the kubectl apply command as shown below:

$ kubectl apply -f echo_ingress.yaml

Output:

ingress.networking.k8s.io/echo-ingress configured

Then, wait for a couple of minutes for the Let’s Encrypt production server to issue the certificate. You can also trail its progress by using kubectl describe on the certificate object:

$ kubectl describe certificate echo-tls

Once you see the following output, you may assure that the certificate has been issued successfully:

Normal Issuing 28s cert-manager Issuing certificate as secret was previously issued by ClusterIssuer.cert-manager.io/letsencrypt-staging

Normal Reused 28s cert-manager Reusing private key stored in existing Secret resource “echo-tls”

Normal Requested 28s cert-manager Created new CertificateRequest resource “echo-tls-49gmn”

Normal Issuing 2s (x2 over 4m52s) cert-manager The certificate has been successfully issued.

You will then be performing a test using curl to verify that HTTPS is working correctly:

$ curl echo1.example.com

Output:

<html>

<head><title>308 Permanent Redirect</title></head>

<body>

<center><h1>308 Permanent Redirect</h1></center>

<hr><center>nginx/1.15.9</center>

</body>

</html>

This will point out that HTTP requests are being redirected to use HTTPS.

Run curl on https://echo1.example.com:

$ curl https://echo1.example.com

Output:

echo1

You can also run the previous command with the verbose -v flag. It allows you to dig deeper into the certificate handshake. It also verifies the certificate information.

By the time you reach this point, you would have successfully configured HTTPS utilizing a Let’s Encrypt certificate for your Nginx Ingress.

Final Words

We expect that this post would have guided you well in setting up an Nginx Ingress. This allows you to load balance and route external requests to backend services inside of your Kubernetes Cluster. Also, it facilitates securing the Ingress with the installation of cert-manager certificate provisions and setting up a Let’s Encrypt Certificate for two host paths.

08Sep

How to Generate a Self-Signed Certificate for Kubernetes

September 8, 2022 admin

Technology has evolved across ages, still creating a self-signed certificate for Kubernetes is nevertheless hard. We will show you how to create a self-signed Kubernetes certificate with the help of just a few commands. But in case you can’t create the self-signed one, you can definitely go for the TLS certificate. The certificate will be signed by the Certificate Authority (CA) so that it can prove the authenticity of the copy.

Generally, people use these CA certificates to authorize any work process. We will shortly come into the part where you are able to learn how to create a self-signed certification for Kubernetes. But before that, let’s have a look at the things you require to create a self-signed certificate.

Prerequisites for Creating a Self-Signed Certificate for Kubernetes

If you have a Kubernetes cluster on your computer, it will help you with the process. But if not, you can create one. But make sure that there is the kubectl command-line tool on your system and it is configured properly. You can check out this guide where you will find how to properly set up and configure the kubectl command-line tool. The kubectl command-line tool will help your computer to interact with the cluster. Also, make sure that you are following this guide and running the commands on a cluster that has at least two cluster nodes. Apart from the cluster nodes that have the role of control plane hosts, you will need two separate ones.

However, if there is no Kubernetes cluster, you can construct one by using minikube. Apart from that, you can use one of these Kubernetes playgrounds as an alternative to minikube:

Alternatively, you can create a Kind Kubernetes in a docker cluster using the commands given below.

kind create cluster

export KUBECONFIG=”$(kind get kubeconfig-path –name=”kind”)”

To test if the cluster is set up properly, use the command below:

kubectl cluster-info

You can also check the version of your cluster with the following command:

kubectl version

After making sure that your PC is running a proper Kubernetes cluster, it’s time to move on to the next section. Here we can create a self-signed certificate using different methods.

Create a Self-Signed Certificate with Cert-Manager

Generally, you can create a self-generated certificate with the cert-manager, but for that, you will have to install the cert-manager first. Use the following command to install cert-manager:

kubectl create namespace cert-manager

kubectl apply –validate=false -f https://github.com/jetstack/cert-manager/releases/download/v0.13.1/cert-manager.yaml

If there is a validation error in the x-Kubernetes-preserve-unknown-fields, you can add the –validate command to the above command and then run the whole command again. After that, create a namespace where you could work to create a certificate. Creating the namespace will require the following command:

kubectl create namespace sandbox

If you want to request a certificate from any namespace, you can create a cluster issuer in Kubernetes. Here is the command to create a cluster issuer:

kubectl apply -n sandbox -f <(echo “

apiVersion: cert-manager.io/v1alpha2

kind: Issuer

metadata:

name: selfsigned-issuer

spec:

selfSigned: {}

“)

Then create a self signed certificate that is usable for the services in the sandbox namespace:

kubectl apply -n sandbox -f <(echo ‘

apiVersion: cert-manager.io/v1alpha2

kind: Certificate

metadata:

name: first-tls

spec:

secretName: first-tls

dnsNames:

– “*.sandbox.svc.cluster.local”

– “*.sandbox”

issuerRef:

name: selfsigned-issuer

‘)

After creating the certificate, check out its resource:

$ kubectl -n sandbox get certificate

NAME READY SECRET AGE

first-tls True first-tls 9s

And its subsequent secret:

$ kubectl -n sandbox get secret first-tls

NAME TYPE DATA AGE

first-tls kubernetes.io/tls 3 73s

To check whether or not the certificate is valid, use the following command:

openssl x509 -in <(kubectl -n sandbox get secret \

first-tls -o jsonpath='{.data.tls\.crt}’ | base64 -d) \

-text -noout

However, this method will only allow you to create a self-signed certificate in Kubernetes. But if you want to find TLS certificates that are signed by the CA, you can do that too. A TLS certificate will help you perform client or server authentication in Kubernetes more easily and you can generate the certificate using the cert-manager as well.

Create Multiple TLS Certificates with Cert-Manager

Again, you need to install the cert-manager. You can check out the command required to install the cert-manager in the previous section. Also, create a namespace and cluster issuer here with the same commands discussed previously. Now, create a CA certificate using the commands below:

kubectl apply -n sandbox2 -f <(echo ‘

apiVersion: cert-manager.io/v1alpha2

kind: Certificate

metadata:

name: sandbox2-ca

spec:

secretName: sandbox2-ca-tls

commonName: sandbox2.svc.cluster.local

usages:

– server auth

– client auth

isCA: true

issuerRef:

name: selfsigned-issuer

‘)

Check if the certificate and secret were created well:

$ kubectl -n sandbox2 get certificate sandbox2-ca

NAME READY SECRET AGE

sandbox2-ca True sandbox2-ca-tls 15s

$ kubectl -n sandbox2 get secret sandbox2-ca-tls

NAME TYPE DATA AGE

sandbox2-ca-tls kubernetes.io/tls 3 22s

However, this time, you will have to create a second cluster issuer. You will have to produce an Issuer resource from the CA secret you have made in the previous command:

kubectl apply -n sandbox2 -f <(echo ‘

apiVersion: cert-manager.io/v1alpha2

kind: Issuer

metadata:

name: sandbox2-ca-issuer

spec:

ca:

secretName: sandbox2-ca-tls’)

Now, create a TLS certificate from the second cluster issuer:

kubectl apply -n sandbox2 -f <(echo ‘

apiVersion: cert-manager.io/v1alpha2

kind: Certificate

metadata:

name: sandbox2-server

spec:

secretName: sandbox2-server-tls

isCA: false

usages:

– server auth

– client auth

dnsNames:

– “server.sandbox2.svc.cluster.local”

– “server”

issuerRef:

name: sandbox2-ca-issuer

‘)

Create another CA certificate from the same issuer:

kubectl apply -n sandbox2 -f <(echo ‘

apiVersion: cert-manager.io/v1alpha2

kind: Certificate

metadata:

name: sandbox2-client

spec:

secretName: sandbox2-client-tls

isCA: false

usages:

– server auth

– client auth

dnsNames:

– “client.sandbox2.svc.cluster.local”

– “client”

issuerRef:

name: sandbox2-ca-issuer

Now check if all the certificates are created:

$ kubectl -n sandbox2 get certificate

NAME READY SECRET AGE

sandbox2-ca True sandbox2-ca-tls 7m34s

sandbox2-client True sandbox2-client-tls 7s

sandbox2-server True sandbox2-server-tls 16s

$ kubectl -n sandbox2 get secret

NAME TYPE DATA AGE

sandbox2-ca-tls kubernetes.io/tls 3 8m14s

sandbox2-client-tls kubernetes.io/tls 3 48s

sandbox2-server-tls kubernetes.io/tls

Now, validate the certificate against the CA:

$ openssl verify -CAfile \

<(kubectl -n sandbox2 get secret sandbox2-ca-tls \

-o jsonpath='{.data.ca\.crt}’ | base64 -d) \

<(kubectl -n sandbox2 get secret sandbox2-server-tls \

-o jsonpath='{.data.tls\.crt}’ | base64 -d)

/proc/self/fd/18: OK

$ openssl verify -CAfile \

<(kubectl -n sandbox2 get secret sandbox2-ca-tls \

-o jsonpath='{.data.ca\.crt}’ | base64 -d) \

<(kubectl -n sandbox2 get secret sandbox2-client-tls \

-o jsonpath='{.data.tls\.crt}’ | base64 -d)

/proc/self/fd/18: OK

Here, now validate the client-server authentication and manage an openssl server as the environment method:

touch test.txt

openssl s_server \

-cert <(kubectl -n sandbox2 get secret sandbox2-server-tls -o jsonpath='{.data.tls\.crt}’ | base64 -d) \

-key <(kubectl -n sandbox2 get secret sandbox2-server-tls -o jsonpath='{.data.tls\.key}’ | base64 -d) \

-CAfile <(kubectl -n sandbox2 get secret sandbox2-ca-tls -o jsonpath='{.data.ca\.crt}’ | base64 -d) \

-WWW -port 12345 \

-verify_return_error -Verify 1 &

And run an openssl client test and search for the HTTP/1.0 200 ok in the client output:

echo -e ‘GET /test.txt HTTP/1.1\r\n\r\n’ | \

openssl s_client \

-cert <(kubectl -n sandbox2 get secret sandbox2-client-tls -o jsonpath='{.data.tls\.crt}’ | base64 -d) \

-key <(kubectl -n sandbox2 get secret sandbox2-client-tls -o jsonpath='{.data.tls\.key}’ | base64 -d) \

-CAfile <(kubectl -n sandbox2 get secret sandbox2-client-tls -o jsonpath='{.data.ca\.crt}’ | base64 -d) \

-connect localhost:12345 -quiet

To stop the background process, use this simple one-line command:

kill %1

Create Certificates via CFSSL

You can also generate certificates with CFSSL. CFSSL is a command-line tool for CFSSL container administration and consists of the following programs:

Multirootca – It is a certificate authority server
Mkbundle – It is a certificate pool bundle builder
Cfssljson – It is a certificate generator that uses json outputs from the cfssl and multirootca for the CFSSL tool.

In the following steps, we are going to talk about how to create a self-signed certificate with CFSSL. But firstly, download and install the CFSSL tool from https://github.com/cloudflare/cfssl/releases. Alternatively, you can use the following steps to install CFSSL using GO language pancakes with the following command:

sudo apt install golang

Then apply the syntax given below to download cfssl:

go get -u github.com/cloudflare/cfssl/cmd/cfssl

Copy the file from ~/go/bin to the appropriate folder:

sudo cp ~/go/bin/cfssl /usr/local/bin/cfssl

And lastly, repeat the process with cfssljson:

go get -u github.com/cloudflare/cfssl/cmd/cfssljson

sudo cp ~/go/bin/cfssljson /usr/local/bin/cfssljson

After you install the tool, you will have to create a self-signed certificate authority. However, you will also have to create a file named ca.json. Have a look at the following section to do so.

Create a Certificate Authority

The example below creates a file that we will call ca.json and the file defines the following terms:

CN refers to the common name for the authority
algo is the algorithm that has been used for the certificate
size is the algorithm size in bits
C refers to the country
L refers to locality or city
ST is State or province
O is Organization
OU is Organizational Unit

This example file is for the organization and its unit is “Example Company Root CA”. The organization is based on the United States territory, New York. So, the C of the file will be the USA, L will be New York, and so on.

{

“CN”: “Example Company Root CA”,

“key”: {

“algo”: “rsa”,

“size”: 2048

“names”: [

{

“C”: “US”,

“L”: “New York”,

“ST”: “New York”,

“O”: “Example Company”,

“OU”: “Example Company Root CA”

}

]

}

Once created, save the json file in a text editor and later use it to create ca.pem and ca-key.pem files with the following cfssl command:

cfssl gencert -initca ca.json | cfssljson -bare ca

Perform the cfssl.json Configuration File

The cfssl.json configuration file will have details about the certificate such as its expedition date and usage for peer, server, and client. Now the json file will look like this:

{

“signing”: {

“default”: {

“expiry”: “8760h”

“profiles”: {

“intermediate_ca”: {

“usages”: [

“signing”,

“digital signature”,

“key encipherment”,

“cert sign”,

“crl sign”,

“server auth”,

“client auth”

“expiry”: “8760h”,

“ca_constraint”: {

“is_ca”: true,

“max_path_len”: 0,

“max_path_len_zero”: true

}

“peer”: {

“usages”: [

“signing”,

“digital signature”,

“key encipherment”,

“client auth”,

“server auth”

“expiry”: “8760h”

“server”: {

“usages”: [

“signing”,

“digital signing”,

“key encipherment”,

“server auth”

“expiry”: “8760h”

“client”: {

“usages”: [

“signing”,

“digital signature”,

“key encipherment”,

“client auth”

“expiry”: “8760h”

}

Save the file and exit. The next section will be about creating an Intermediate Certificate Authority. So, check it out and apply the next steps.

Generate an Intermediate Certificate Authority

After creating the json file in the previous section, there is another file that you need to create that will be called intermediate-ca.json. The intermediate-ca.json file defines the intermediate certificate authority and almost looks like the previously created ca.json file. Here is what the content of this file will be:

“CN”: ” Example Company Intermediate CA”,

“key”: {

“algo”: “rsa”,

“size”: 2048

“names”: [

{

“C”: “US”,

“L”: “New York”,

“ST”: “New York”,

“O”: “Example Company”,

“OU”: “Example Company Intermediate CA”

}

“ca”: {

“expiry”: “42720h”

}

This is not the end of this file. You will have to sign the certificate and create a host certificate, which is discussed in the next section.

Sign the Certificate and Create a Host Certificate

Create the intermediate_ca.pem, intermediate_ca.csr and intermediate_ca-key.pem files after creating the previous ones and sign the intermediate CA by following the commands below:

cfssl gencert -initca intermediate-ca.json | cfssljson -bare intermediate_ca

Finally, sign the certificate using the CA and the cfssl.json configuration file:

cfssl sign -ca ca.pem -ca-key ca-key.pem -config cfssl.json -profile intermediate_ca intermediate_ca.csr | cfssljson -bare intermediate_ca

If you have not created the host certificate for peer, server, and client profiles, then create the host1.json file with the important host information:

{

“CN”: “host.example-company.com”,

“key”: {

“algo”: “rsa”,

“size”: 2048

“names”: [

{

“C”: “US”,

“L”: “New York”,

“O”: “Example Company”,

“OU”: “Example Company Intermediate CA”,

“ST”: “New York”

}

“hosts”: [

“host1.example-company.com”,

“localhost”

]

}

You can create a host certificate using the configuration file. Type cfssl gencert -ca intermediate_ca.pem -ca-key intermediate_ca-key.pem -config cfssl.json -profile=peer host1.json | cfssljson -bare host-1-peer to create the peer certificate that performs communication between the server.

cfssl gencert -ca intermediate_ca.pem -ca-key intermediate_ca-key.pem -config cfssl.json -profile=peer host1.json | cfssljson -bare host-1-peer

Type cfssl gencert -ca intermediate_ca.pem -ca-key intermediate_ca-key.pem -config cfssl.json -profile=server host1.json | cfssljson -bare host-1-server that will allow you to create a server certificate.

There are several additional options that let you generate a self-signed certificate for Kubernetes. But using the cert-management tool and CFSSL are the best ways. The simplest way to get the license is by using the kubectl get csr my-svc.my-namespace -o jsonpath='{.status.certificate}’ \

| base64 –decode > server.crt command. Although greatest time users are unsure of the ways to get the certificate signing requests approved. In that case, follow the section below.

How to Approve Certificate Signing Requests?

The Kubernetes administrator that has the appropriate permissions for changing the cluster files can manually approve or deny the certificate signing requests. You will have to use the kubectl certificate approval and kubectl certificate to deny commands for that. But you should also write an automated certificate controller in case you want to overuse this command. The approver of the certificate verifies if the Kubernetes self-signed certificate meets the following requirements:

The subject of the certificate signing request needs the same private key that you use to sign in to the CSR. So, if a third party tries to get the certificate, the authority can recognize it. This also helps the authority to verify if the pod controls the private key that is required to generate the CSR.
The subject of the CSR will be authorized, which will make sure that the CSR contains the right subject and not an invalid one. Also, the subject of the CSR will verify if the pod can participate in the requested service.

If your CSR meets these requirements, the approver of the Kubernetes certificate will approve your CSR otherwise, your request will be denied. So, before generating the certificate, try to take certain conditions into account. There are some drawbacks of self-signed certificates as well and before you try to get one, you need to consider them as well.

Know More About the Request Signing Process in Kubernetes

The type of CertificateSigningRequest resource helps the client to generate an X.509 certificate according to the signing request. In the spec.request field, there will be a PEM-encoded PKCS#10 signing request, and the request is situated in the CertificateSigningRequest object. It is an important signing request key that you need to have besides the API version. The signing request needs to be approved before it is signed and the signer will be the recipient of the certificate only (one who has made the signing request). The certificate signer request is often approved or declined automatically by the controller. Or else, you will have to manually approve it using the REST API.

Once the certificate has been approved, you will have to confirm the certificate. The controller will verify the signing conditions before creating the certificate. Once the controller updates the status of the certificate—whether or not it was approved, you will find the status in the status.certificate field of the requested certificate. The field will be empty or will contain an X.509 certificate. But once the request is approved, it will be deleted within 1 hour. The case is the same for the two other scenarios—denied and pending requests.

What are the Disadvantages of Self-Signed Certificates on Kubernetes?

Have a look at the possible disadvantages of self-signed certificates on Kubernetes:

1. Browser Warnings

Sometimes when you are trying to connect to an HTTPS website through your browser, it shows untrusted connections. So, while creating a website, self-certificates may not be the best option for you.

2. Authentication Issue

A self-signed certificate is not signed by any authority hence, it faces authentication issues. Whenever intruders want, they can displace the self-signed record with the attacker’s own hazardous definitions. And when the browser is connecting to the website with the self-signed certificate, it won’t be able to understand the subject of the certificate and communicate with it.

3. Warranty

While the third-party CA offers warranties against certain losses when there is an issue with the certificate, self-signed certificates don’t come with such warrants.

4. Customers trusts

A signed certificate such as HTTPS ensures a website’s visitors that it is safe to shop online from the website. If your website is running a self-signed certificate, it creates an untrusted environment as it conveys that your site is not authenticated. That’s why customers are not likely to trust your website.

The drawbacks mentioned above cannot be eliminated as it is a part of the self-signed certificate. But if you ignore these disadvantages and focus on other things such as the ease of generating a self-signed certificate on Kubernetes, it won’t be a problem. Also, it is suggested to place a service in front of the Kubernetes deployment that manages pods. Have a look at the section below to know how to do it.

How to Manage TSL Between Microservices in Kubernetes?

First, we want you to put service before the deployment that manages the pods in a Kubernetes cluster. The service then will generate a stable DNS and IP endpoint that will help the pods that have been deleted. By doing so, you can assign a new IP address to the pods when the pods are newly constructed again. You can enable the DNS service recovery using the ClusterIP type service. The format of the ClusterIP type service will be <service name>.<kubernetes namespace>.svc.<cluster domain>. And the cluster domain will be cluster.local as usual.

Therefore, you can use the assigned ClusterIP and the newly created DNS as the names of your self-created certificate. But what about the Kubernetes internal CA? What to do when you are generating a third-party approved certificate?

1. Kubernetes Internal CA

Kubernetes comes with internal CA and API methods to generate CSR and sign them up by the CA that would secure the microservices we talked about in the previous section. The internal CA in Kubernetes is managed by the kubelet and other internal cluster processes for the Kubernetes API server authentication purposes. However, there is no auto-renewal process for the signed certificate but the cert has a 30 days time period within which it will stay signed.

2. Certificate Management for Kubernetes

We have talked about the usage of cert-manager earlier in this article. The cert-manager helps your cluster to automatically create and manage certificates using the custom resources. If you apply the CA Issuer Type and obtain certificate sources, that will generate a certificate for Kubernetes Secret. You will find more info about this on the Kubernetes official website but you can also have a fair idea from the previous sections of this article.

Final Verdict

If your Kubernetes cluster has the requirements specified in the previous section, then you could easily generate a certificate. However, this tutorial indicates that the signer of the Kubernetes certificate should be able to complete the documents API. Kubernetes controller manager already implements the default execution pre-set by a signer. You can simply pass the –cluster-signing-cert-file parameters to the controller manager with your Certificate Authority’s keypair paths.

Generally, generating a self-signed certificate for Kubernetes takes a lot of procedures than the CA-signed certificates. If you want, you can choose to create multiple TLS certificates with cert-manager; but still, it has some complications. However, if you carefully follow the steps mentioned in this article, you can easily generate a self-signed certificate on Kubernetes. Whenever you are creating a certificate and following the commands to create one, make sure you are following the right commands in the right order.

06Sep

How To Set Up WordPress with MySQL on Kubernetes Using Helm

September 6, 2022 admin

In the realm of distributed environments, platforms like Kubernetes are undoubtedly setting up a standard. This is applicable across dynamic builds and also production environments. Complex application ecosystems and the most sought-after Kubernetes have made services like MySQL quite important in the field of distributed environments.

The open-source Helm package manager for Kubernetes makes the process of deploying and upgrades on a Kubernetes cluster quite easy and also offers information on applications like Kubernetes Charts.

Here in this article, we will discuss how to use Helm to install WordPress on Kubernetes. From the point of scalability and accessibility aspects, Helm makes WordPress secure and offers simplified upgrade and rollback via it.

For the database component, the external MySQL server database component is used that enables Helm to be a part of a separate cluster. So, at the end of this article, you will learn how to install WordPress with MySQL on Kubernetes.

Requirements

To ensure a seamless installation, you need to meet the following requirements:

You need a Kubernetes 1.10+ cluster with RBAC. This is role-based access control.
Configure the kubectl for cluster connectivity. You can also go through Kubernetes resources for instructions.
You also need to deploy Helm and Tiller.
For the database, you need a MySQL server with SSH access. It also should have the root MySQL password. You can log into your MySQL server and check Kubernetes cluster connectivity. If there is more than one cluster on the kubectl config file, you need to check if you are connected to the correct cluster.

kubectl config get-contexts

Output:

Output

CURRENT NAME CLUSTER AUTHINFO NAMESPACE

* do-sfo2-wordpress-cluster do-sfo2-wordpress-cluster do-sfo2-wordpress-cluster-admin

minikube minikube minikube

This (*) sign is for the default cluster selection. Check the current context, by executing this command:

kubectl config use-context context-name

Step 1: Configuring MySQL

There should be a MySQL user and an associated database for WordPress. External hosts should be able to connect here. Once the WordPress installation is complete this will be on a server as a part of the Kubernetes cluster. This is not required for a single and dedicated MySQL server.

On the MySQL server, you can log into MySQL using:

mysql -u root -p

Enter the password you set up for the root MySQL account. This is during the installation. Log in to MySQL and you can create the database and the user details for WordPress.

database name: wordpress

User name: wordpress_user

password: password

To create the database, you can use the following command:

CREATE DATABASE wordpress;

Create MySQL user for this database:

CREATE USER wordpress_user IDENTIFIED BY ‘password’;

Add admin access for wordpress_user for both internal and external networks:

GRANT ALL PRIVILEGES ON wordpress.* TO wordpress_user@’%’;

To manage access to internal MySQL tables you can use the below command

FLUSH PRIVILEGES;

To exit MySQL client:

exit;

Check MySQL command-line client using wordpress_user :

mysql -u wordpress_user -p

Check database access:

show databases;

Output:

Output

+——————–+

| Database |

+——————–+

| information_schema |

| wordpress |

+——————–+

2 rows in set (0.03 sec)

You can exit once completed:

exit;

So, now the WordPress installation is deployed on a separate server, you can modify the MySQL configuration for external connections.

Select to open the file /etc/mysql/mysql.conf.d/mysqld.cnf

sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

Configure the bind-address setting within this file. MySQL by default accepts 127.0.0.1 (localhost). Modify this to 0.0.0.0 so that it looks like below-

/etc/mysql/mysql.conf.d/mysqld.cnf

# Instead of skip-networking the default is now to listen only on

# localhost which is more compatible and is not less secure.

bind-address = 0.0.0.0

Save the changes and restart MySQL:

sudo systemctl restart mysql

Check the remote connectivity:

mysql -h mysql_server_ip -u wordpress_user -p

Edit mysql_server_ip to your MySQL server IP address and move to the next step.

Step 2: Install WordPress

We can now use Helm to install WordPress.

It starts with the installation of MariaDB on a separate pod as the database. But for installation purposes, it needs to use a MySQL database. You can make this and other configuration edits like the default user credentials during this time via command-line parameters or YAML configuration.

In the following steps, we will use a configuration file.

Create a new directory and select the followings:

mkdir myblog-settings

cd myblog-settings

Create values.yaml, using your text editor:

nano values.yaml

Enter custom variables to help WordPress connect to the database and add some basic information and admin credentials after the WordPress installation is complete.

These are stored as default on values.yaml file from the WordPress Helm chart. Blog/Site Info has all the general features for the WordPress blog. It contains the name and the login details. The Database Settings helps to connect to the remote MySQL server. MariaDB is inactivated at the final phase.

Add the following to values.yaml file, and edit the highlighted values with the new values:

values.yaml

## Blog/Site Info

wordpressUsername: sammy

wordpressPassword: password

wordpressEmail: sammy@example.com

wordpressFirstName: Sammy

wordpressLastName: the Shark

wordpressBlogName: Sammy’s Blog!

## Database Settings

externalDatabase:

host: mysql_server_ip

user: wordpress_user

password: password

database: wordpress

## Disabling MariaDB

mariadb:

enabled: false

The following options are configured:

wordpressUsername: WordPress user’s login

wordpressPassword: WordPress user’s password

wordpressEmail: WordPress user’s email

wordpressFirstName: WordPress user’s first name

wordpressLastName: WordPress user’s last name

wordpressBlogName: Name of the Site or Blog

host: MySQL server IP address or hostname

user: MySQL user

password: MySQL password

database: MySQL database name

Exit from the editor once this task is finished.

Now you can use helm to install WordPress. Initiate helm for the latest WordPress chart with the name myblog, using values.yaml as the setup file:

helm install –name myblog -f values.yaml stable/wordpress

Output:

Output

NAME: myblog

LAST DEPLOYED: Fri Jan 25 20:24:10 2019

NAMESPACE: default

STATUS: DEPLOYED

RESOURCES:

==> v1/Deployment

NAME READY UP-TO-DATE AVAILABLE AGE

myblog-wordpress 0/1 1 0 1s

==> v1/PersistentVolumeClaim

NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE

myblog-wordpress Pending do-block-storage 1s

==> v1/Pod(related)

NAME READY STATUS RESTARTS AGE

myblog-wordpress-5965f49485-8zfl7 0/1 Pending 0 1s

==> v1/Secret

NAME TYPE DATA AGE

myblog-externaldb Opaque 1 1s

myblog-wordpress Opaque 1 1s

==> v1/Service

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

myblog-wordpress LoadBalancer 10.245.144.79 <pending> 80:31403/TCP,443:30879/TCP 1s

(…)

Now, myblog-wordpress is created on Kubernetes. It will take some time before the container and the External-IP information are accessible. For the service status and external IP address execute the following command:

kubectl get services

Output

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

kubernetes ClusterIP 10.245.0.1 <none> 443/TCP 20h

myblog-wordpress LoadBalancer 10.245.144.79 203.0.113.110 80:31403/TCP,443:30879/TCP 3m40s

This gives you information about the services running on your cluster. It also shows that IP addresses like myblog-wordpress are available on the external IP address 203.0.113.110.

Note: If during the installation you have used the minikube, you have to execute a minikube service myblog-wordpress to check the container web server

WordPress installation is now active. You can use kubectl get services, followed by /wp-admin in your web browser:

http://203.0.113.110/wp-admin

Use the custom values from values.yaml file to enter and set up the WordPress site.

Step 3: Upgrading

WordPress needs to be constantly upgraded for smooth functioning. The helm upgrade ensures Helm upgrades.

Execute the following command to see the list of releases:

helm list

Output

NAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE

myblog 1 Fri Jan 25 20:24:10 2019 DEPLOYED wordpress-5.1.2 5.0.3 default

If you want to upgrade to the latest version of a chart, you need to upgrade Helm repositories with the following command:

helm repo update

Output

Hang tight while we grab the latest from your chart repositories…

…Skip local chart repository

…Successfully got an update from the “stable” chart repository

Update Complete. ⎈ Happy Helming!⎈

The newer version of the WordPress chart is available with:

helm inspect chart stable/wordpress

Output

apiVersion: v1

appVersion: 5.1.1

description: Web publishing platform for building blogs and websites.

engine: gotpl

home: http://www.wordpress.com/

icon: https://bitnami.com/assets/stacks/wordpress/img/wordpress-stack-220×234.png

keywords:

– wordpress

– cms

– blog

– http

– web

– application

– php

maintainers:

– email: containers@bitnami.com

name: Bitnami

name: wordpress

sources:

– https://github.com/bitnami/bitnami-docker-wordpress

version: 5.9.0

The chart version also gets upgraded from version 5.9.0 with WordPress 5.1.1 . Execute the following command for the latest charts:

helm upgrade -f values.yaml myblog stable/wordpress

This command will give you results similar to the helm install. Use the same configuration file as you had used the first time while installing the WordPress for the custom database settings.

Execute helm list to get more updates on the release:

Output

NAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE

myblog 2 Fri May 3 14:51:20 2019 DEPLOYED wordpress-5.9.0 5.1.1 default

WordPress is upgraded to WordPress chart.

RollBack

Every upgrade creates a new revision of release by Helm. This is a version history detail that you can revisit to know about the changes. To rollback you can always use the helm rollback command:

helm rollback release-name revision-number

If there are any edits or changes which you want to not go ahead with then you go back to the initial version by using

helm rollback myblog 1

If this rollback goes through, then the output will be:

Output

Rollback was a success! Happy Helming!

Execute the helm list to check if it was downgraded

Output

NAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE

myblog 3 Mon Jan 28 22:02:42 2019 DEPLOYED wordpress-5.1.2 5.0.3 default

Notice that rolling back a release will create a new revision, based on the target revision of the roll-back. This makes myblog version 3 the latest file. So, we can see there is a change in the revision number.

Conclusion

In this article, we explored how to install WordPress on a Kubernetes cluster with an external MySQL server using Helm. The list of steps with code snippets and examples should help you to perform the complete process. If you face any issue while following the above-mentioned steps, drop us a comment through the below box.

31Aug

What is Kubernetes CrashLoopBackOff Events?

August 31, 2022 admin

Kubernetes has gained much popularity in recent years and is currently one of the most widely used container orchestration engines. If you are using Kubernetes, you might come across various errors and failures while running containers. One of the commonly occurring errors is the dreaded CrashLoopBackOff error and it may occur because of the incorrect Kubernetes configurations. Such misconfigurations include unavailable volumes, init-container misconfiguration, and more.

In this article, we will majorly focus on the CrashLoopBackOff problem, why it occurs, and how you can debug it.

What is Kubernetes?

Before moving towards the CrashLoopBackOff problem, we will first give you an overview of Kubernetes. In 2014, Google launched Kubernetes as a container orchestration tool and it is also known as k8s. This container orchestration engine is well-suited for cloud-native computing services. Google launched it as its Container as a Service (CaaS) offering and later it is known as Google Container Engine.

It is an open-source system that helps in deploying, scaling, and managing containerized applications. It has extended support from other platforms like OpenShift and Azure. It has a simple and modular API core that makes it a powerful tool for container orchestration. Kubernetes works on pods and a pod is a collection of two or more containers running together.

What is the CrashLoopBackOff Error?

This is a common Kubernetes error that occurs during the deployment of various applications using Kubernetes. If a pod is stuck in the CrashLoopBackOff state, then the pod will keep on crashing at a single point after you deploy and run it on any host. It may occur due to the improper starting of the pod.

Each pod in Kubernetes comes with a specification field that has an associated RestartPolicy field for such errors. There are various values that can be assigned to the RestartPolicy that are namely Always, OnFailure, and Never. These values are applicable for all the containers present within a single pod. The RestartPolicy specifies the restarting of the container by the kubelet within the Kubernetes.

If the RestartPolicy status is “Always or OnFailure”, the kubelet will restart the failed pod every time but with an exponential back-off delay. This delay value is mostly capped at 5 minutes. But, if the pod runs successfully for 10 minutes, this delay value will get resettled to the initial value.

How to Find a CrashLoopBackOff Error?

You can spot this error by running a single command on Kubernetes, which is as follows:

kubectl get pods -n <namespace>

The output of the above command will display the details regarding the pods and you can check the status section for CrashLoopBackOff state.

You can apply the filter for checking the status of the pods and examine if any of them are in CrashLoopBackOff status. If you want to check the status of the pods, you can run the following command:

kubectl describe po <pod name> -n <namespace>

You can use the output of the above-mentioned command to:

Check the events section for the probes’ status (like liveness, readiness, startup), if they are failing.
Look for the events section for the particular event mentioned as the OOM Killed.
Look in the pod status section for any ‘error’ displayed along with the error code.

You will get the output as shown below:

Why Does CrashLoopBackOff Occur?

There can be many reasons for the occurrence of this error. Here are some of the most common reasons:

1. Probe failure

For checking the containers, Kubernetes uses some probes like liveness, readiness, and startup. If the probe with liveness or the startup status fails, the container will get restarted at the same point without delay.

For solving this problem, you need to re-check the configuration settings of the probes, if they are configured properly. Check for the specifications like (endpoint, port, SSL config, timeout, command) and make sure they are mentioned correctly. If you are not able to find any error there, you can look for the logs for more clarification. If the error is not clear yet, then you can use the ephemeral containers and run the curl or other relevant commands to check if the application is running perfectly.

2. Out of memory failure (OOM)

Each pod has an associated memory space. If any pod consumes more memory than the allocated one, the pod tends to be crashing. It may be the case if you have allocated less memory than it requires to run seamlessly. The consumption of memory may increase due to an error in the pod and consumes more memory in its running phase.

On checking the event logs, you will encounter the “OOM killed event” error. It will indicate that the pod has been crashed as it takes up all the RAM that is allocated to it.

For solving this error, you need to allocate more RAM to the pods for successful running. It may work sometimes, but if the pod is consuming way more memory then you need to look at the application for the actual cause of the crash. If you are using Java then you should check the heap configurations.

3. Application failure

As we know, containers store applications and their dependencies together to run as an independent application. The CrashLoopBackOff may occur if that application within the container fails due to some error resulting in a Pod crash.

If you want to check the code of the application for debugging, you can run the following command.

Kubectl logs -n <namespace> <podName> -c <containerName> –previous

You can consider checking the last line of the logs. It will usually help in narrowing down the error source within the application.

How to Alert on Kubernetes CrashLoopBackOff?

If you want to set an alert on the Kubernetes for any failed pods, then you can use the metric Kubernetes.pod.restart.rate. It allows you to do some analysis on the pod’s trend of restarting over time. It will instantly notify the respective team if there’s any type of pod anomaly.

To manage the delay in the environment, you need to change the time settings accordingly. The alert is configured and will trigger if any of the pods has been restarted more than 3 times in the last 4 minutes. Such a situation is the CrashLoopBackOff error and is the default alert for the Kubernetes environment.

You can even enable the Sysdig capture for debugging and troubleshooting the CrashLoopBackOff error. It allows complete recording of every small event that happened on the system when you get the alert. You can look at these captures using Sysdig Inspect for deep insights and troubleshooting the situation for better analysis. This will help the development team to respond quickly and recover from the error.

You can even set the CrashLoopBackOff alert based on the captures generated.

Conclusion

Kubernetes is the most reliable tool for running your containers or pods. However, any application tends to fail due to many reasons running within a container. Such a situation can cause the complete pod to fail. To resolve an issue like CrashLoopBackOff, you need to debug logs and event status for clarity.

In this article, we have mentioned what the CrashLoopBackOff error is and what is the reason for its occurrence. Also, we discussed how you can set up an alert for this error using the Kubernetes UI.

02Aug

Kubernetes Persistent Volumes

August 2, 2022 admin

Kubernetes Persistent Storage provides Kubernetes apps with a simple way to request and use storage. A volume is an essential part of Kubernetes’ storage architecture. Kubernetes persistent volumes are volumes that reside within a Kubernetes cluster and may outlast other Kubernetes pods to save data and information for longer periods of time.

Persistent Volume Claims or PVCs, are the requests for storage resources by Kubernetes nodes, and Storage Classes, which specify the storage type and allow Kubernetes resources to use them without addressing the underlying implementation. There are two more key Kubernetes storage concepts. Let’s scroll down the blog to learn about them in detail, along with knowing their features, lifecycles, use cases, and setup process.

What are Kubernetes Persistent Volumes?

PVs or Persistent Volumes in Kubernetes are storage units given by the administrators as components of Kubernetes clusters. A node is a computing resource that is utilized by a cluster. The data contained in persistent volumes is not lost when the pod goes down since persistent volumes are independent of the lifespan of the pod that uses them.

They’re specified by an API object that encapsulates the operational characteristics of storage systems like NFS files or specialized cloud storage services. Admin-provided Volumes are persistent volumes in Kubernetes. File system, size, and identifiers like volume ID and name are all established characteristics. To begin using these volumes, a Pod has to first request by sending a persistent volume claim (PVC).

PVCs describe the storage capacity and characteristics a pod needs, and the cluster tries to match that request and provide the appropriate persistent volume. Kubernetes persistent volumes have the following attributes:

It may be deployed either dynamically or manually
Built using a specific filesystem
Comes with a certain size
Has attributes like volume IDs and a name for identification

To dig deeper into Kubernetes persistent volumes, one must be aware of the following two concepts:

1. Persistent Volume Claim (PVC)

It is a storage request issued by a Kubernetes node. Applications can specify specific storage attributes, such as how much storage is needed, or the kind of access, such as read/write, read-only, write-only, etc., in Persistent Volume Claims.

Kubernetes searches for a PV which fits the user’s PVC’s requirements, and if one exists, it connects the claim to that PV. This is referred to as binding. You may also set up the cluster to provide a PV for a claim on the fly.

2. StorageClass

Persistent Volumes can be defined with varied features, including performance, size, and access parameters, using the StorageClass object. It allows you to offer persistent storage to users while abstracting implementation details. Kubernetes offers a variety of pre configured StorageClasses or you can construct one yourself.

Users can create several Storage Classes to provide users a variety of performance alternatives. There may be one on a quick SSD memory with limited capacity, and the other on a slower data storage with a large capacity.

Features of Kubernetes Persistent Volumes

1. Capacity

Individuals are allowed to set the PV’s maximum storage capacity using the “capacity” feature. To guarantee consistency across all storage services and devices, amounts are defined in bytes.

2. Volume Mode

By default, Kubernetes creates a file system on the PV, but you can also use a bare block device without a layer if you wish.

3. Access Modes

The access modes for a PV are as follows:

ReadWriteOnce: Allows a specific node to read and write the data
ReadOnlyMany: Allows read-only access and can be installed on several nodes
ReadWriteMany: Specific node would be able to perform both reading and writing operations

It’s worth noting that certain storage plugins may only offer a subset of these access options.

4. Reclaim Policy

The reclaim policy determines what happens after a node no longer requires persistent storage. A PV can be retained until it is destroyed in this way: Delete, which permanently eradicates the data, or Recycle, which can be retrieved later; or Preserve, which keeps the PV in the active state until it has been deleted explicitly. It’s worth noting that certain storage plugins may not support a subset of these recovery rules.

Lifecycle of Persistent Volumes

Persistent Volumes are the cluster’s resources. In contrast, persistent volume claims are requests for certain resources, as well as claims checks. How PVs and PVCs interact during their lifecycle can be summarized as follows:

1. Provisioning

Persistent Volumes can be provisioned in one of the following two ways:

2. Static

PVs are created by a cluster administration. They include information about the actual storage that cluster users may access. They are accessible for usage through the Kubernetes API.

3. Dynamic

If all the administrator’s static PVs fail to match the user’s Persistent Volume Claim, the clusters may attempt to dynamically provide a volume, particularly for the PVC. For dynamic provisioning to take place, the PVC should demand a storage class, and the administrator must have built and specified that class.

The cluster administration must activate the DefaultStorageClass admission controller on the API server to activate dynamic storage provisioning depending on the storage class.

4. Binding

Here’s how the binding process works in a nutshell:

Administrators must submit a PVC request, indicating the amount of storage needed and the access modes necessary. Further, a master-level control loop searches for new PVCs and then:

Static – The control loop searches and binds a matched PV to a particular PVC.
Dynamic – The control loop ties them collectively if a PV was previously dynamically supplied to the PVC.

After a PVC and a PV have been connected, they are no longer mutually exclusive because one-to-one mapping exists between PVC and PV. A ClaimRef is used in this procedure to build a bi-directional binding among PV and the PVC.

5. Using

Pods use claims as volumes. Cluster inspects the claim to find the bound volume, and mounts that volume for a pod. A user specifies which access mode they desire when using their claim as a volume inside a pod for volumes that support multiple access modes.

Once a user has a claim and that claim is bound, the bound PV belongs to the user for as long as they need it. Users schedule Pods and access their claimed PVs by including a persistentvolumeclaim section in a Pod’s volumes block.

6. Storage Object in Use Protection

Claims are used as volumes in pods. The cluster examines the claim to identify the bound volume and mount it for Pod’s use. When utilising claims as a volume Pods, the user defines which access mode is wanted for volumes that allow various access modes.

Right after the user claims it as the bound, the user owns the bound PV for as long as required. By adding a persistentvolumeclaim section in a Pod’s volumes block, users may schedule Pods and access their claimed PVs.

Whenever the PVC’s status is displayed as “Terminating” and kubernetes.io/pvc-protection is included in the Finalizers list, it clearly means that PV is secured. Simply run the command mentioned below:

kubectl describe pvc hostpath

Similar to PVC, your PV is secured if the PV’s status is Terminating and the Finalizers list includes kubernetes.io/pv-protection. Just execute the command mentioned below:

kubectl describe pv task-pv-volume

7. Reclaiming

When an individual is finished utilising their volume, they may want to remove the PVC objects from the API, allowing the resources to be reclaimed. A PersistentVolume’s reclaim policy instructs Kubernetes clusters to define what to do with the volume once it has been freed from its claim. Volume can either be Retained, Recycled, or Deleted.

8. Retain

The Retain reclaim policy enables manual resource recovery. It keeps the PersistentVolume even after the PersistentVolumeClaim is removed, and the volume is deemed “released.” However, because the prior claimant’s data is still on the disc, it does not get accessible for another claim.

9. Delete

It removes both the PersistentVolume object within Kubernetes and the corresponding storage asset in the external infrastructure, such as an AWS EBS, GCE PD, Azure Disk, or Cinder volume.

10. Recycle

If the underlying volume plugin supports it, the Recycle reclaim policy scrubs the volumes (rm -rf /thevolume/*) and makes it accessible for new claims.

Why do we use persistent volumes?

There were some best practises in the early days of containerization. One of them was for containers to be neutral. There’s no reason to exclude stateless applications now because Kubernetes has developed and container-native storage solutions such as Portworx. Similarly, for running applications in containers, Kubernetes have provided features for storing, retaining, and backing up data generated or utilized by that application.

Databases are the most popular use case for Persistent volumes in Kubernetes. It is because a database must have constant access to its data, and utilizing databases like MySQL, Cassandra, CockroachDB, and even MS SQL isn’t a good idea for applications. Therefore, PVs are used for putting complicated workloads inside containers, not merely stateless that assures the consistency of our data.

Individuals can make the deployment of distributed, stateful apps easier by using persistent volumes. But before installing any PV, make sure the following things are performed:

Every pod is made from scratch (with proper config and environment variables)
The pod has a persistent volume linked to it (with the help of persistent volume claim)
The claimed storage should be installed inside the pod

These high-level stages will be repeated for each pod in the application set. In this manner, we can be sure that the original pod will deploy and have enough storage, and that each successive copy will have the same storage attachments and mounts (required for any clustered application). This stateful collection of pods can readily scale, allowing us to add many more replicas to the distributed application. If any of the pods fail, they can be replaced, and the storage can be reconnected.

How to use Kubernetes Persistent Volumes

After learning about persistent volumes, how they differ from regular volumes, as well as how they are used, we are now ready to go over how to use them. The following steps will help you create Kubernetes persistent volumes defined sizes. Before that, ensure you have a well-functioning Kubernetes environment in place:

For building a persistent volume, create a file with the name pv-demo.yaml in your preferred editor
Edit the created file by pasting the below-mentioned spec into the same

apiVersion: v1

kind: PersistentVolume

metadata:

name: <pv_name>

spec:

capacity:

storage: 10Gi

accessModes:

– ReadWriteOnce

persistentVolumeReclaimPolicy: Retain

portworxVolume:

volumeID: “<volume_id>”

Replace <pv_name> with the PersistentVolume’s name. For instance, pv0001.

Adjust the storage capacity to the quantity you want. The aforementioned configuration will generate a volume of 10 GB.

Substitute <volume_id> with the volume’s appropriate ID. For example, “pv0001” might be used.

Save the file and run the command below for creating the Persistent Volume

kubectl create –f pv-demo.yaml

The following must be displayed on your screen as a confirmation that Persistent Volume is created

persistentvolume “pv0001” created

For seeing the created PV, execute the below-mentioned command

kubectl get pv

Conclusion

In Kubernetes, Persistent Volumes are storage units given by administrators as components of clusters. The operational characteristics of storage systems, such as NFS files or specialized cloud storage services, are specified by an API object. To begin using these volumes, a Pod has to first request by sending a persistent volume claim (PVC). Persistent Volumes can be defined with varied features, including performance, size, and access parameters, using the StorageClass object.

It interacts with Persistent Volume Claims on lots of stages of its lifecycle such as provisioning, binding, reclaiming, etc. Databases are the most popular use case for Persistent volumes in Kubernetes. Therefore, PVs are used for putting complicated workloads inside containers. For setting up Kubernetes Persistent Volume in your infrastructure, go through the steps mentioned in the last section of the blog.