Nowadays, there are very few places where you’ll not find QR codes. In fact, QR codes have become so ubiquitous that in 2021, 45 percent of customers utilized marketing-related QR codes.

There’s no doubting the QR code’s popularity and use. But what is it, exactly?

The abbreviation QR stands for “quick response code.” It’s a black-and-white sign in the shape of a square that may be scanned with a smartphone or laser to discover more about a product or service. Content, links, discounts, event details, and other information that consumers desire to see can be stored in these encrypted squares. You can even look at the different types of QR codes and choose the one that best suits your business and purpose.

QR codes are widely used in a variety of businesses. They even helped in the fight against the Covid-19 outbreak by automating operations to limit physical touch. All you need is a smartphone with a QR code reader or an online QR code scanner to use QR codes. Another advantage of QR codes is that they are simple to make with just a few basic steps. So, if you’re interested in producing a QR code, here is how you can do it,

1. Look for a QR code generator on the internet. QR code generators abound on the internet. Examine their ratings and reviews and choose one to begin with. The best part is that the majority of them are free.

2. What kind of material are you looking to promote? Do you want to provide a link to a website or any unique information? Before moving on to the next level, you must make these decisions.

3. Fill out the information in the form that pops up on your screen. It will ask you to add the content you want to encode in your QR code. It can be a landing page, payment gateway, or any information related to your product such as PDFs and videos.

4. Once you have filled in all the information, a QR code will be generated on the screen, You’ll need to download that QR code

5. After downloading the QR code. Select a reliable QR code reader for the next step, which is to test the QR code you’ve made. There are a variety of options accessible. Your phone may also feature a QR code reader, however, it may not be able to scan QR codes that are severely broken or crumpled. As a result, choose one that works in a variety of demanding situations. You can use an online QR code scanner with versatile functionality. Try the demo here.

6. If your QR code is working properly, it’s time to share it with your audience. You can add the QR code to your collaterals such as pamphlets, menus, storefronts, product packaging, or website.

Bonus Suggestion

You can keep track of the performance of your QR code by doing an analysis that will help you in the future. For this, you must create a UTM tracking URL before encoding it with your QR code. Creating UTM URLs will help you in analyzing the performance with your analytics tool.

Simplified Steps to Create your own QR Code was originally published in DevOps and SRE Learning on Medium, where people are continuing the conversation by highlighting and responding to this story.

Just a few days before he died at the beginning of the 1990s, a wise man taught us that “the show must go on.” Freddie Mercury’s parting words have long provided the guiding light for many, if not all, ops teams.

In their eyes, the production environment should be exposed to minimum risk, even at the expense of new features and problem resolution.

About 10 years ago, Google decided to change its approach to production management. It took the company only a few years to realize that while R&D focused on creating new features and pushing them to production, the Operations group was trying to keep production as stable as possible — the two teams were pulling in opposite directions. This tension arose due to the groups’ different backgrounds, skill sets, incentives and metrics by which they were measured.

Trying to bridge this gap between the two groups, one of Google’s ops leaders, Ben Treynor, thought of an innovative solution. Instead of having an Ops team built solely from system administrators, software engineers — with an R&D background and mentality — could enrich the way the team worked with the development group, change its goals and help with automating solutions.

Site Reliability Engineering, or SRE

And so, the Site Reliability Engineering position was created. According to Google, SRE engineers are responsible for the stability of the production environment, but at the same time are committed to new features and operational improvement. Google decided its SRE teams should be composed of 50 percent software engineers and 50 percent system administrators. The engineers were driven to use software as a way of solving problems and perfecting what had historically been solved by hand. They integrated easily with the development team, and encouraged code quality improvements and automation testing.

Understanding the value of SRE, several organizations of various sizes decided to embrace its principles. Some, such as Dropbox, Netflix and Github, are well-known for being at the forefront of technology leadership.

Wait, Isn’t That DevOps?

DevOps is a more recent movement, designed to help organizations’ IT department move in agile and performant ways. It builds a healthy working relationship between the Operations staff and Dev team, allowing each to see how their work influences and affects the other. By combining knowledge and effort, DevOps should produce a more robust, reliable, agile product.

Both SRE and DevOps are methodologies addressing organizations’ needs for production operation management. But the differences between the two doctrines are quite significant: While DevOps raise problems and dispatch them to Dev to solve, the SRE approach is to find problems and solve some of them themselves.

While DevOps teams would usually choose the more conservative approach, leaving the production environment untouched unless absolutely necessary, SREs are more confident in their ability to maintain a stable production environment and push for rapid changes and software updates. Not unlike the DevOps team, SREs also thrive on a stable production environment, but one of the SRE team’s goals is to improve performance and operational efficiency.

Google tried a few approaches to implementing the SRE process before finding the one that suited them best. One of these approaches attempted to tie the number of permitted releases to the product’s stability. The principle underlying this process is that new releases are green-lighted based on current product performance.

For each service, the SRE team sets a service-level agreement (SLA) that defines how reliable the system needs to be to end users. If the team agrees on a 99.9 percent SLA, that gives them an error budget of 0.1 percent. An error budget is exactly what the name suggests: the maximum allowable threshold for errors and outages. Here’s the interesting thing: the development team can “spend” this error budget in any way they like.

If the product is currently running flawlessly, with few or no errors, they can launch whatever they want, whenever they want. Conversely, if they have met or exceeded the error budget, and are operating at or below the defined SLA, all new releases are frozen until they reduce the number of errors to a level that allows the launch to proceed. This process ensures that both the SREs and developers have a strong incentive to minimize the number of errors in production.

Another interesting approach recommended by Treynor, which is more related to SRE professionalism and efficiency, is allowing SREs to move between projects. Moreover, he suggests allowing SRE engineers to move to development, and even the other way around.

As the work done by both teams is similar, these transitions help the Ops team gain better and deeper knowledge of the product and code, and bring the Dev teams into the production space to help them understand its challenges. This strongly promotes a team atmosphere, rather than one in which an individual feels that “I’m on the SRE team for this product.”

As part of this approach, Treynor had Dev teams handle 5 percent of the operations workload. This, according to many organizations, adds to the SRE team’s motivation and effectiveness.

Riddles in the Dark

Well, SRE seems perfect. As already stated, several large-scale organizations have chosen to move some of their production operations from old Ops to SRE. However, there are still a few questions that need to be asked:

Is the position of SysAdmin (production/ops) no longer relevant for SysAdmins?

Historically, almost all system administrators have come into their roles through tech support and similar work, or even just running Linux on their desktops and then transitioning into server work. It should be pretty clear that the same path is not available into SRE.

To retain their positions, SysAdmins should now be more code-oriented, have better technological knowledge and be receptive to new methods of conducting the work they already do.

Can an SRE team prevent production incidents?

One of the strengths of a professional site reliability engineer is the ability to handle the growth of production load and traffic in-house. Monitoring and analyzing processes and logs with platforms such as the ELK Stack is part of the day-to-day workload, and the team should be able to identify problems as they occur, and even foresee risks to software stability.

The power of this position — based on the skill set it requires — lies in developing solutions for these problems and risks. As Ciara, a software engineer in Google’s cloud storage SRE team, described it in a “Life in Google” post, “We solve cooler problems in cooler ways.”

Are we doing DevOps or are we doing SRE?

This question is usually asked by people trying to position themselves in the Operations world.

According to many companies that implemented SRE in a slightly different way than Google, you don’t have to decide.

At Reddit, ops engineers work on reducing toil, improving deployment and scaling processes, but they are referred to as “DevOps.”

At Logz.io, we bridge the gap between developers and production through the use of automated monitoring and performance stress-testing. And we personally refer to it as “DevOps” rather than “SRE.”

So, is it Just a Question of Context?

In her blog, Charity Majors talks about SRE and DevOps being two different operational approaches that any organization can choose to work by, but insists on emphasizing that there is no “correct” approach. Although Google and Dropbox have decided on SRE, this does not mean the rest of the world should do so as well. What fits Google’s needs and organizational philosophy does not necessarily work for other orgs — at any scale.

Moreover, Charity believes that DevOps, having grown and evolved within a broader variety of software organizations, is the more flexible, collaborative and adaptable approach, and will work better for most software organizations at all stages of development.

On the other hand, SoundCloud senior engineer, Matthias Rampke issued a series of tweets on how SRE and DevOps were basically the same, with only one difference — high management support.

Though in contradiction to her blog, Charity lent weight to this opinion during an AskMeAnything event that revolved around DevOps and SRE. She shared a story about a friend who was hiring for a startup, which, as an experiment, posted the exact same job description twice, the only difference being that one listing was titled “DevOps engineer,” and the other “SRE.”

At the time of relating the story, DevOps was winning by 10 percent or 20 percent. However, all this means is that the job title is irrelevant, and naming an SRE team does not magically bestow qualities upon it. Rather than focusing on the title, organizations must focus on the work being done.

To summarize, we can quote Matt Simmons, a technologist with many insights into this topic, who says, “Not every infrastructure needs an SRE, but every infrastructure could use an administrator who acted more like one.”

SRE vs. DevOps — a False Distinction? was originally published in DevOps and SRE Learning on Medium, where people are continuing the conversation by highlighting and responding to this story.

What is Zabbix?

Zabbix is an open-source monitoring software tool for diverse IT components, including networks,servers, virtual machines(VMs) and cloud services.

Zabbix provides monitoring metrics, among others network utilization, CPU load and disk space consumption. Zabbix monitoring configuration can be done using XML based templates which contain elements to monitor.

Zabbix can use MySQL, MariaDB, PostgreSQL, SQLite, Oracle or IBM DB2 to store data. Its backend is written in C and the web frontend is written in PHP.

Various Zabbix Monitoring Options

Three Major Components of Zabbix

• Zabbix Server
• Zabbix Agent and
• Zabbix Web Interface

Zabbix server is the one which collects all the relevant data from the server you want to monitor.

The servers you want to monitor are called Agents.

You can have the server monitoring without the Zabbix web part. But I would suggest using it as it makes the experience better.

Let’s run through the installation steps for the Zabbix on AWS EC2 Instance:

Zabbix Installation Steps:

Initially you would be needed to spin a basic t2.micro instance on AWS EC2.

Let’s connect to the EC2 Instance using the SSH terminal on MobaXterm platform which delivers much better visualization frontend towards the Ubuntu Linux machine.

An SSH connection will be started with your Ubuntu virtual machine.

Use the following command to become the root user on the Ubuntu virtual machine.

sudo su -

You have successfully created an Ubuntu virtual Machine on Amazon AWS.

Install the MySQl database service.

apt-get update
apt-get install mysql-server mysql-client

Access the MySQL service command-line.

mysql -u root -p

Create a database named zabbix.

CREATE DATABASE zabbix CHARACTER SET UTF8 COLLATE UTF8_BIN;

Create a database user named zabbix.

CREATE USER ‘zabbix’@’%’ IDENTIFIED BY ‘admin@123’;

In our example, the password admin@123 was set to the user named zabbix.

Give the MySQL user named zabbix permission over the database named zabbix.

GRANT ALL PRIVILEGES ON zabbix.* TO ‘zabbix’@’%’;
FLUSH PRIVILEGES;
quit;

Download the Zabbix 4.4 installation package.

mkdir /downloads
cd /downloads
wget https://ufpr.dl.sourceforge.net/project/zabbix/ZABBIX%20Latest%20Stable/4.4.0/zabbix-4.4.0.tar.gz

Import Zabbix database template inside MySQL.

tar -zxvf zabbix-4.4.0.tar.gz
cd zabbix-4.4.0/database/mysql/
mysql -u zabbix -p zabbix < schema.sql
mysql -u zabbix -p zabbix < images.sql
mysql -u zabbix -p zabbix < data.sql

You have finished the Zabbix database installation.

Installing Zabbix 4.4 Web Interface

Install the Apache web server and all the required packages.

apt-get install apache2 php libapache2-mod-php php-cli php-mysql php-mbstring php-gd php-xml php-bcmath php-ldap

Find the location of the php.ini file on your system.
Edit the php.ini file.

updatedb
locate php.ini
vi /etc/php/7.2/apache2/php.ini

Keep in mind that your PHP version and the location of the file may not be the same of mine.

Set the following items on the php.ini file:

max_execution_time = 300
memory_limit = 256M
post_max_size = 32M
max_input_time = 300
date.timezone = America/New_York

Set the correct timezone to your location.

Restart the apache service.

service apache2 restart

You have finished the Apache web server installation with PHP support.

Zabbix Server 4.4 Installation on Ubuntu

Download and install the GOLANG package.

mkdir /downloads/go -p
cd /downloads/go
wget https://dl.google.com/go/go1.13.1.linux-amd64.tar.gz
tar -C /usr/local -zxvf go1.13.1.linux-amd64.tar.gz

The GOLANG software was installed under the /usr/local folder.

In order to work properly, the GO software expect the system to have a set of environment variables.

Let’s create a file to automate the required environment variables configuration.

vi /etc/profile.d/go.sh

Here is the go.sh file content:

#/bin/bash
export GOROOT=/usr/local/go
export GOPATH=$GOROOT/work
export PATH=$PATH:$GOROOT/bin:$GOPATH/bin

Reboot your computer.

reboot

Verify if the required environment variables were created automatically.

env | grep -E “(ROOT|GOPATH)”

Here is the correct output:

GOROOT=/usr/local/go
GOPATH=/usr/local/go/work

Create a Linux account to the Zabbix user and install the required packages.

groupadd zabbix
useradd -g zabbix -s /bin/bash zabbix
apt-get update
apt-get install build-essential libmysqlclient-dev libssl-dev libsnmp-dev libevent-dev
apt-get install libopenipmi-dev libcurl4-openssl-dev libxml2-dev libssh2–1-dev libpcre3-dev
apt-get install libldap2-dev libiksemel-dev libcurl4-openssl-dev libgnutls28-dev

Access the Zabbix package folder, compile and install the Zabbix server

cd /downloads/zabbix-4.4.0
 ./configure — enable-server — enable-agent — enable-agent2 — with-mysql — with-openssl — with-net-snmp — with-openipmi — with-libcurl — with-libxml2 — with-ssh2 — with-ldap
make
make install

Find the location of the zabbix_server.conf file.

updatedb
locate zabbix_server.conf
vi /usr/local/etc/zabbix_server.conf

Here is the original file, before our configuration.

LogFile=/tmp/zabbix_server.log
DBName=zabbix
DBUser=zabbix
Timeout=4
LogSlowQueries=3000
StatsAllowedIP=127.0.0.1

Here is the new file with our configuration.

LogFile=/tmp/zabbix_server.log
DBHost=localhost
DBName=zabbix
DBUser=zabbix
DBPassword=admin@123
Timeout=4
LogSlowQueries=3000
StatsAllowedIP=127.0.0.1

Start the Zabbix server.

/usr/local/sbin/zabbix_server

Now, you need to choose which version of Zabbix agent you want to use.

Use the following command to start the default Zabbix Agent.

/usr/local/sbin/zabbix_agentd

Or use the following command to start the new Zabbix Agent2.

/usr/local/sbin/zabbix_agent2 &

Zabbix agent 2 appears to run only in the foreground.

Move all the Zabbix frontend files to the root directory of your Apache installation.

Set the correct file permission on all moved files

cd /downloads/zabbix-4.4.0/frontends
mkdir /var/www/html/zabbix
mv php/* /var/www/html/zabbix
chown www-data.www-data /var/www/html/zabbix/* -R

Restart the Apache service.

service apache2 restart

Zabbix 4.4 Web Installer

Open your browser and enter the IP address of your web server plus /zabbix.

Make sure the security group for the EC2 instance allows the traffic on the default port for the Zabbix server, else just modify the SecurityGroup for the EC2 instance by adding the Inbound rules as follows:

In our example, the following URL was entered in the Browser:

http://54.203.0.220/zabbix

The Zabbix web installation interface should be presented.

Click on the Next button.

On the next screen, you will have to check if all the requirements were achieved.

Click on the Next button.

Enter the Database information required to connect to the Zabbix database.

Host: localhost

Database Username: zabbix

Database Password: admin@123

On the next screen, you just have to click on the Next button.

Now, take a look on the configuration summary.

Click on the Next button.

On the next screen, you will have to click on the Finish button.

Finally, you will be presented with the Zabbix login screen.

Zabbix default username: Admin

Zabbix default Password: zabbix

After a successful login, you will be sent to the new Zabbix Dashboard.

Voila !!

You have successfully installed the Zabbix Server Configuration and Monitoring tool, an open-source monitoring software tool for diverse IT components, including networks,servers, virtual machines(VMs) and cloud services.

It can be used for monitoring metrics, among others network utilization, CPU load and disk space consumption.

References:

• Zabbix: The enterprise-class open source observability solution
• How To Install and Configure Zabbix to Securely Monitor Remote Servers on Ubuntu 16.04 | DigitalOcean

Zabbix Monitoring Configuration Installation on AWS EC2 was originally published in DevOps and SRE Learning on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

Docker Overview:

What is Docker?

Docker is a tool which is used by developer and operation teams to create and automate the deployment of applications in lightweight containers so that applications can work efficiently in different environments

Note: Container is a software package that consists of all the dependencies required to run an application

How are Docker containers created?

• Docker File creates a Docker Image using the build command
• A Docker Image contains all the project’s code
• Using Docker Image, any user can run the code in order to create Docker Containers
• Once a Docker Image is built, it’s uploaded in a registry or a Docker Hub
• From the Docker Hub, users can get the Docker Image and build new containers

What is Docker Compose?

• Docker Compose is used for running multiple containers as a single service
• Here, containers run in isolation but can interact with each other
• All Docker Compose files are YAML files
• In Docker Compose, a user can start all the services (containers) using a single command

For example:

If you have an application which requires NGINX server and Redis database, you can create a Docker Compose file which can run both the containers as a service without the need to start each one separately

ELK Stack Overview:

• Elasticsearch is an open-source, full-text search, and analysis engine, based on the Apache Lucene search engine.
• Logstash is a log aggregator that collects data from various input sources, executes different transformations and enhancements, and then ships the data to various supported output destinations.
• Kibana is a visualization layer that works on top of Elasticsearch, providing users with the ability to analyze and visualize the data.
• And last but not least — Beats are lightweight agents that are installed on edge hosts to collect different types of data for forwarding into the stack.

Together, these different components are most commonly used for monitoring, troubleshooting, and securing IT environments (though there are many more use cases for the ELK Stack such as business intelligence and web analytics).

Beats and Logstash take care of data collection and processing, Elasticsearch indexes and stores the data, and Kibana provides a user interface for querying the data and visualizing it.

Why is ELK So Popular?

• The ELK Stack is popular because it fulfills a need in the log management and analytics space.
• Monitoring modern applications and the IT infrastructure they are deployed on requires a log management and analytics solution that enables engineers to overcome the challenge of monitoring what is highly distributed dynamic and noisy environments.
• ELK Stack helps by providing users with a powerful platform that collects and processes data from multiple data sources, stores that data in one centralized data store that can scale as data grows, and that provides a set of tools to analyze the data.

• Of course, the ELK Stack is open-source.
• With IT organizations favoring open-source products, this alone could explain the popularity of the stack.
• Using open source means organizations can avoid vendor lock-in and onboard new talent much more easily.
• Everyone knows how to use Kibana, right? Open source also means a vibrant community is constantly driving new features and innovation and helping out in case of need.

We will use docker-compose to deploy our ELK stack. Docker-compose offers us a solution to deploy multiple containers at the same time.

Prerequisites:

• Docker
• Docker-Compose

The full template is available on my GitHub. Clone the repository and start the containers by using Docker-compose.

$ git clone https://github.com/jainhemant163/ELK-Docker-Containerization.git
$ cd docker-elk
$ docker-compose up -d

The first resource which is deployed is Elasticsearch. Elasticsearch is a system for quickly analyzing and analyzing different types of data.

We’re able to use a single instance and disable xpack (paying feature) using environment variables. It is deployed in the logging-network which is a Docker bridge network.

Now we will deploy Logstash. Logstash is an open-source, server-side data processing pipeline that simultaneously ingests data from a multitude of sources, transforms it, and then sends it to tools like Elasticsearch.

Logstash depends on Elasticsearch, which needs to be deployed first. Port 12201 is exposed and mapped on the server. Other Docker containers will send their logs to Logstash by connecting to this UDP port. As volume, we will mount the logstash.conf inside the container.

We will now expect Gelf input. Gelf is the Graylog Extended Log Format and is a great choice for logging from within applications,which we can then send our logs to our ElasticSearch container. They can communicate with each other using their service name because they are deployed in the same Docker Bridge network.

The file /usr/share/logstash/config/pipelines.yml contains the available pipelines which Logstash runs. Here we can define specific files (pipelines), but we are using only one pipeline now.

The default file describes the directory where our logstash.conf is available, so we don’t need to update our pipeline configuration. If you want to run multiple pipelines, you can add additional id’s and point to specific .conf files instead of pointing to a directory like it is now (by default). For more info, take a look here.

If you configure multiple pipelines, it can be useful to debug your Logstash container. You can use docker exec to debug your Logstash container and check configuration files. This is out of scope for our current basic setup.

$ docker exec -it docker-elk_logstash_1 bash
bash-4.2$ cat /usr/share/logstash/pipeline/logstash.conf
input {
  gelf {}
}output {
  elasticsearch {
    hosts => "elasticsearch:9200"
  }
}

The last ELK stack related service in our template is the setup of Kibana. Kibana lets us visualize our Elasticsearch data.

Kibana depends on Logstash and will expose and map port 5601. Like all other ELK stack related resources, Logstash is deployed inside the logging-network. This allows the containers to communicate with each other by using service names.

Now we can test our setup. One Apache (httpd) container is already started by using Docker-compose. Users of Docker Desktop for Mac should edit the gelf-address in the docker-compose.yml to udp://host.docker.internal:12201. Check here for more information. Don’t forget to update your environment by running docker-compose up -d again.

We will start an additional Nginx container using the Docker CLI.

Users of Docker Desktop for Mac should update the gelf-address to udp://host.docker.internal:12201. Check here for more information.

$ docker run -d -p 8080:80 --log-driver gelf --log-opt gelf-address=udp://localhost:12201 nginx:latest

Let’s visit both applications in the browser.

Now Access Kibana on http://localhost:5601. Click on the left on ‘Discover’ and on ‘Create Index Pattern’. Create a pattern using ‘*’ and ‘@timestamp’,also create a pattern using ‘.kibana_1’.

Now click on discover and verify the logs.

Conclusion

In this article, I tried to containerize the complete ELK stack using Docker and Docker-Compose, making it easy to Docker containers on Kibana visualization dashboards.

The main concern of this article was to help the developers in set up the complete Elasticsearch, Logstash, Kibana stack over Docker container in the same network making it easy to communicate with other containers in the same network.

Dockerizing ELK stack into containers using Docker was originally published in DevOps and SRE Learning on Medium, where people are continuing the conversation by highlighting and responding to this story.

Grafana is multi-platform open source analytics and interactive visualization software available since 2014. It provides charts, graphs, and alerts for the web when connected to supported data sources. It is expandable through a plug-in system. End users can create complex monitoring dashboards using interactive query builders.

As a visualization tool, Grafana is a popular component in monitoring stacks,often used in combination with time series databases such as Prometheus and Graphite.

In this post, you will learn how to install the Grafana, by using shell script AWS EC2 Ubuntu Instance Server.

Step1: Spin up an EC2 Instance on AWS by logging in your dev/prod account

Step2: Once the EC2 Instance is up and running,we would be using the Public DNS (IPv4) or IPv4 Public IP to login into server using credentials, and switch the user to root.

Step3: Open any text editor and create the grafanainstallation.sh shell script file.And paste the below code and save using ESC+wq Command on text editor.

#!/bin/bash
echo ‘deb https://packages.grafana.com/oss/deb stable main’ >> /etc/apt/sources.list
curl https://packages.grafana.com/gpg.key | sudo apt-key add -
sudo apt-get update
sudo apt-get -y install grafana
systemctl daemon-reload
systemctl start grafana-server
systemctl enable grafana-server.service

Step4: Change the permission of file by using the command.

chmod +x grafanainstallation.sh

Step5: execute the shell script by using command

./grafanainstallation.sh

Step6: Verify whether Grafana is running or not by using following command

service grafana-server status

If the Grafana Server is not running run the below command to start it.

service grafana-server start

Step7: Perfect, our Grafana server is in active state and is up and running for the Metrics and Performance Visualization.

Step8: Here, you won’t be able to the grafana dashboard now as the AWS Security Group for the EC2 Instance is not enabled to accept the load for port 3000.Therefore,you must allow the 3000 port in security groups in AWS.

Step9: Take the IP address or DNS of your server and place it on address bar of the any browser along with Grafana port 3000. (we can change the port number)

Step10: By default, Grafana username and password are admin and admin. From the next screen you can get the option to change your password. that is depend on your choice either you can change or not.

Step11: Below is the Grafana Home screen.

Grafana Installation Steps on AWS EC2 Instance was originally published in DevOps and SRE Learning on Medium, where people are continuing the conversation by highlighting and responding to this story.

If this all questions intricates you and you would like to know more about it then this article would be right platform to learn and get aware about Kubernetes, so without wasting time let’s dive deep and understand Kubernetes,its extra-ordinary features and the complete setup on AWS platform.

What is Kubernetes?

Kubernetes is an open-source Container Management (orchestration) tool which automates container deployment, container (de) scaling & container load balancing.

It’s container management responsibilities includes:

1.Scheduling

Deploy containers across a cluster of servers, using the available resources (data centers, servers, CPU, memory, ports, etc.) as efficiently as possible.

2.Deployments

Roll out updates to containers using a variety of deployment strategies, such as rolling deployment, blue-green deployment, and canary deployment, and automatically roll back if there’s an error.

3.Auto healing

Monitor the health of your containers and servers and automatically replace unhealthy ones.

4.Auto scaling

Scale the number of containers and servers up or down in response to load.

5.Load balancing

Make your containers accessible to the outside world and distribute traffic across your containers.

6.Service discovery

Allow containers to find and communicate with each other over the network, automatically routing requests to the proper destination.

7.Configuration and secrets

Provide containers with environment-specific configuration data and secrets.

NOTE: Kubernetes is not a containerization platform. It is a multi-container management solution.

Why Kubernetes?

Kubernetes has become the de facto choice for container orchestration. Here’s why:

Massive feature set

Kubernetes offers a huge range of functionality for managing containers, including auto scaling, auto healing, rolling deployments, service discovery, secrets management, configuration management, bin packing, storage orchestration, batch execution, access controls, log aggregation, SSH access, batch processing, and much more.

Massive community

Kubernetes has the biggest community of any orchestration tool, with more than 50,000 stars and 2,500 contributors on GitHub, thousands of blog posts, numerous books, hundreds of meetup groups, several dedicated conferences, and a huge ecosystem of frameworks, tools, plugins, integrations, and service providers.

Run anywhere

You can run Kubernetes on-premise, in the cloud (with 1st class support from the cloud provider, e.g.,: AWS offers EKS, Google Cloud offers GKE, Azure offers AKS), and on your own computer (it’s built directly into the Docker desktop app). This reduces lock-in and makes multi-cloud and hybrid-cloud more manageable, as both the containers themselves and the way you manage them are portable.

Proven technology

Kubernetes was originally designed by Google, based on years of experience with their internal container management systems (Borg and Omega), and is now maintained by the Cloud Native Computing Foundation. It’s designed for massive scale and resiliency (Google runs billions of containers per week) and with a huge community behind it, it’s continuously getting better.

What are the main Kubernetes design principles?

The design of a Kubernetes cluster is based on 3 principles, as explained in the Kubernetes implementation details.

A Kubernetes cluster should be:

• Secure. It should follow the latest security best-practices.
• Easy to use. It should be operable using a few simple commands.
• Extendable. It shouldn’t favor one provider and should be customizable from a configuration file.

Key Feature Offering from Kubernetes Platform

1. Service Discovery & Load Balancing

With Kubernetes, there is no need to worry about networking and communication because Kubernetes will automatically assign IP addresses to containers and a single DNS name for a set of containers, that can load-balance traffic inside the cluster.

2. Storage Orchestration

With Kubernetes, you can mount the storage system of your choice. You can either opt for local storage, or choose a public cloud provider such as GCP or AWS, or perhaps use a shared network storage system such as NFS, iSCSI, etc.

3. Self-Healing

Personally, this is my favorite feature. Kubernetes can automatically restart containers that fail during execution and kills those containers that don’t respond to user-defined health checks. But if nodes itself die, then it replaces and reschedules those failed containers on other available nodes.

4. Automatic Rollbacks & Rollouts

Kubernetes progressively rolls out changes and updates to your application or its configuration, by ensuring that not all instances are worked at the same instance. Even if something goes wrong, Kubernetes will rollback the change for you.

5. Secret & Configuration Management

Kubernetes can help you deploy and update secrets and application configuration without rebuilding your image and without exposing secrets in your stack configuration.

6. Automatic Binpacking

Kubernetes automatically packages your application and schedules the containers based on their requirements and available resources while not sacrificing availability. To ensure complete utilization and save unused resources, Kubernetes balances between critical and best-effort workloads.

7. Batch Execution

In addition to managing services, Kubernetes can also manage your batch and CI workloads, thus replacing containers that fail, if desired.

8. Horizontal Scaling

Kubernetes needs only 1 command to scale up the containers, or to scale them down when using the CLI. Else, scaling can also be done via the Dashboard (kubernetes UI).

9. Service Topology

Kubernetes,based on the cluster topology it has the ability to route the service traffic to various nodes configured.

Service Topology enables a service to route traffic based upon the Node topology of the cluster. For example, a service can specify that traffic be preferentially routed to endpoints that are on the same Node as the client, or in the same availability zone.

10. IPv4/IPv6 dual-stack

IPv4/IPv6 dual-stack enables the allocation of both IPv4 and IPv6 addresses to Pods and Services.

If you enable IPv4/IPv6 dual-stack networking for your Kubernetes cluster, the cluster will support the simultaneous assignment of both IPv4 and IPv6 addresses.

These were some of the notable features of Kubernetes,which makes Kubernetes multi-container management solution with auto-healing,load balancing like features.

In the next article we would be discussing more about the Kubernetes architecture and the Master-Slave (Worker) Configuration for the Load Balancing and Distribution along with various algorithms used behind those methodologies.

Reference Links to read more about Kubernetes and its Applications:

• Production-Grade Container Orchestration
• Kubernetes on AWS | Amazon Web Services

Quick Learning Guide for Kubernetes-Part I was originally published in DevOps and SRE Learning on Medium, where people are continuing the conversation by highlighting and responding to this story.

Next, in this article we would be learning more about the Kubernetes Architecture, Master-Slave (Worker) Node Configuration with detailed overview about the submodules in each section and many more…

Kubernetes Architecture/Kubernetes Components

Kubernetes Architecture has the following main components:

• Master nodes
• Worker/Slave nodes
• Distributed key-value store(etcd.)

What is Master Node in Kubernetes Architecture?

The Kubernetes Master (Master Node) receives input from a CLI (Command-Line Interface) or UI (User Interface) via an API. These are the commands you provide to Kubernetes.

It is the entry point for all administrative tasks which is responsible for managing the Kubernetes cluster. There can be more than one master node in the cluster to check for fault tolerance. More than one master node puts the system in a High Availability mode, in which one of them will be the main node which we perform all the tasks.

For managing the cluster state, it uses etcd in which all the master nodes connect to it.

Let us discuss the components of a master node. As you can see in the diagram it consists of 4 components:

1. API Server

• The API Server is the front-end of the control plane and the only component in the control plane that we interact with directly.
• Performs all the administrative tasks through the API server within the master node.
• In this REST commands are sent to the API server which validates and processes the requests.
• After requesting, the resulting state of the cluster is stored in the distributed key-value store.

2. Scheduler

• A Scheduler watches for new requests coming from the API Server and assigns them to healthy nodes.
• The Scheduler schedules the tasks to slave nodes. It stores the resource usage information for each slave node.
• It schedules the work in the form of Pods and Services.
• Before scheduling the task, the scheduler also takes into account the quality of the service requirements, data locality, affinity, anti-affinity, etc.

3. Controller Manager

• Also known as controllers.
• It is a daemon which regulates the Kubernetes cluster which manages the different non-terminating control loops.
• It also performs lifecycle functions such as namespace creation and lifecycle, event garbage collection, terminated-pod garbage collection, cascading-deletion garbage collection, node garbage collection, etc.
• The role of the Controller is to obtain the desired state from the API Server. It checks the current state of the nodes it is tasked to control, and determines if there are any differences, and resolves them, if any.

4. Key-Value Store (etcd)

• The Key-Value Store, also called etcd, is a database Kubernetes uses to back-up all cluster data.
• It stores the entire configuration and state of the cluster.
• The Master node queries etcd to retrieve parameters for the state of the nodes, pods, and containers.
• It can be part of the Kubernetes Master, or, it can be configured externally.
• etcd is written in the Go programming language. In Kubernetes, besides storing the cluster state (based on the Raft Consensus Algorithm) it is also used to store configuration details such as subnets, ConfigMaps, Secrets, etc.

Now you have understood the functioning of Master node. Let’s see what is the Worker/Minions node and its components.

What is Worker Node in Kubernetes Architecture?

Worker Node (formerly minions)

It is a physical server or you can say a VM which runs the applications using Pods (a pod scheduling unit) which is controlled by the master node. On a physical server (worker/slave node), pods are scheduled. For accessing the applications from the external world, we connect to nodes.

Worker nodes listen to the API Server for new work assignments; they execute the work assignments and then report the results back to the Kubernetes Master node.

Let’s see what are the following components:

1. Kubelet

• The kubelet runs on every node in the cluster.
• It is the principal Kubernetes agent.
• By installing kubelet, the node’s CPU, RAM, and storage become part of the broader cluster.
• It watches for tasks sent from the API Server, executes the task, and reports back to the Master.
• It gets the Pod specifications through the API server and executes the containers associated with the Pod and ensures that the containers described in those Pod are running and healthy.
• Based on that information, the Master can then decide how to allocate tasks and resources to reach the desired state.

2. Kube-proxy

• Kube-proxy runs on each node to deal with individual host sub-netting and ensure that the services are available to external parties.
• The kube-proxy makes sure that each node gets its IP address, implements local iptables and rules to handle routing and traffic load-balancing.
• It serves as a network proxy and a load balancer for a service on a single worker node and manages the network routing for TCP and UDP packets.
• It is the network proxy which runs on each worker node and listens to the API server for each Service endpoint creation/deletion.
• For each Service endpoint, kube-proxy sets up the routes so that it can reach to it.

3. Container Runtime

• To run and manage a container’s lifecycle, we need a container runtime on the worker node.
• The container runtime pulls images from a container image registry and starts and stops containers.
• Sometimes, Docker is also referred to as a container runtime, but to be precise, Docker is a platform which uses containers as a container runtime.

4. Pod

• A Pod is the smallest element of scheduling in Kubernetes. Without it, a container cannot be part of a cluster. If you need to scale your app, you can only do so by adding or removing pods.
• The Pod serves as a ‘wrapper’ for a single container with the application code. A Pod is one or more containers that logically go together.
• Based on the availability of resources, the Master schedules the pod on a specific node and coordinates with the container runtime to launch the container.

• Pods run on nodes. Pods run together as a logical unit. So they have the same shared content.
• They all share the same IP address but can reach other Pods via localhost, as well as shared storage.
• Pods don’t need to all run on the same machine as containers can span more than one machine. One node can run multiple pods.
• In instances where pods unexpectedly fail to perform their tasks, Kubernetes does not attempt to fix them. Instead, it creates and starts a new pod in its place.
• This new pod is a replica, except for the DNS and IP address. This feature has had a profound impact on how developers design applications.
• Due to the flexible nature of Kubernetes architecture, applications no longer need to be tied to a particular instance of a pod.
• Pods can be connected to persistent storage in order to run stateful applications.
• Instead, applications need to be designed so that an entirely new pod, created anywhere within the cluster, can seamlessly take its place. To assist with this process, Kubernetes uses services.

To quickly summarize this learning chapter about the Kubernetes architecture the Master Worker Architecture flow:

Reference Links to read more about Kubernetes and its Applications:

Production-Grade Container Orchestration

Quick Learning Guide for Kubernetes-Part II was originally published in DevOps and SRE Learning on Medium, where people are continuing the conversation by highlighting and responding to this story.

Kubernetes Services

• Like a pod, a Kubernetes service is a REST object. A service is both an abstraction that defines a logical set of pods and a policy for accessing the pod set.
• Pods are not constant. One of the best features Kubernetes offers is that non-functioning pods get replaced by new ones automatically.
• However, these new pods have a different set of IPs. It can lead to processing issues, and IP churn as the IPs no longer match. If left unattended, this property would make pods highly unreliable.
• Services are introduced to provide reliable networking by bringing stable IP addresses and DNS names to the unstable world of pods.
• By controlling traffic coming and going to the pod, a Kubernetes service provides a stable networking endpoint — a fixed IP, DNS, and port. Through a service, any pod can be added or removed without the fear that basic network information would change in any way.

General Attributes of a Kubernetes service:

1. A label selector can find pods that are targeted by a service.

• For K8S-native applications, the endpoints API will be updated whenever there are changes to a set of pods in a service.
• For non-native applications, a virtual-IP-based bridge to services redirects to backend pods.

2. A service is assigned an IP address (“cluster IP”), which the service proxies use.

3. A service can map an incoming port to any targetPort. (The targetPort is set, by default, to the port field’s same value. The targetPort can be defined as a string.)

4. The port number assigned to each name can vary in each backend pod.

• For example, you can change the port number that pods expose in the next version of your backend software, without breaking clients.

5. Services support TCP (default), UDP and SCTP for protocols.

6. Services can be defined with or without a selector.

7. Services support a variety of port definitions.

Types of Kubernetes services

There are four types of Kubernetes services:

1. ClusterIP. This default type exposes the service on a cluster-internal IP. You can reach the service only from within the cluster.
2. NodePort. This type of service exposes the service on each node’s IP at a static port. A ClusterIP service is created automatically, and the NodePort service will route to it. From outside the cluster, you can contact the NodePort service by using “<NodeIP>:<NodePort>”.
3. LoadBalancer. This service type exposes the service externally using the load balancer of your cloud provider. The external load balancer routes to your NodePort and ClusterIP services, which are created automatically.
4. ExternalName. This type maps the service to the contents of the externalName field (e.g., foo.bar.example.com). It does this by returning a value for the CNAME record.

Before moving forward, let’s go over the role of kube-proxy. Kube-proxy implements a form of virtual IP for services for all types other than ExternalName. To achieve this, you can set three possible modes:

• Proxy-mode: userspace. In this mode, kube-proxy keeps an eye on the Kubernetes master, watching for services and endpoints objects that get added or removed. For each service, the mode opens a random port on your local node. Any connections to this “proxy port” are proxied to a service’s backend pods and reported in the endpoints.
• Proxy-mode: iptables. When this mode is on, kube-proxy continues to watch the Kubernetes master for added or removed services and endpoint objects.

For each service, unlike in userspace, this mode installs iptables rules in order to capture traffic to the service’s clusterIP (virtual) and port, and then redirects that traffic to a service backend set.

For each endpoints object, the mode installs iptables rules to select a random (by default) backend pod.

• Proxy-mode: ipvs. In this mode, kube-proxy watches the services and endpoints and calls netlink interface in order to create appropriate ipvs rules. Then, to ensure ipvs status is consistent with its expectations, the mode periodically syncs ipvs rules with services and endpoints. When a service is accessed, traffic gets redirected to a backend pod.

How to discover a Kubernetes service

In Kubernetes, there are two ways to discover a service:

1. DNS: In this recommended method, the DNS server is added to the cluster in order to watch the Kubernetes API create DNS record sets for each new service. When DNS is enabled throughout the cluster, all pods should be able to automatically perform name resolution of services.
2. ENV Var: In this discovery method, a pod runs on a node, so the kubelet adds environment variables for each active service.

Headless services

When you neither need nor want load-balancing and a single service IP, create a headless service by specifying “none” for the cluster IP (.spec.clusterIP). There are two options:

• Headless service with selectors. With a headless service that defines selectors, the endpoints controller creates endpoint records in the API, modifying the DNS configuration to return A records (addresses) that point to the pods that back the service.
• Headless service without selectors. Headless services don’t define selectors, so the endpoints controller does not create endpoint records. However, the DNS system configures one of the following:

For service type ExternalName, CNAME records

For the other service types, a record for any endpoints that share names with the service

How Do Kubernetes Services Work?

1. Pods are associated with services through key-value pairs called labels and selectors. A service automatically discovers a new pod with labels that match the selector.
2. This process seamlessly adds new pods to the service, and at the same time, removes terminated pods from the cluster.
3. For example, if the desired state includes three replicas of a pod and a node running one replica fails, the current state is reduced to two pods. Kubernetes observers that the desired state is three pods.
4. It then schedules one new replica to take the place of the failed pod and assigns it to another node in the cluster.
5. The same would apply when updating or scaling the application by adding or removing pods.
6. Once we update the desired state, Kubernetes notices the discrepancy and adds or removes pods to match the manifest file.
7. The Kubernetes control panel records, implements, and runs background reconciliation loops that continuously check to see if the environment matches user-defined requirements.

Now we have learnt about what Kubernetes is,what all features it offers, learning about the k8s architecture and now in the above section learning in details about the Kubernetes Services

Let’s have some practical demo of creating the Kubernetes Services in our Linux/Ubuntu.

How to create a service

Creating a service is better understood when we use a simple example. We’ll run a “Hello World” application and use a deployment kind to create the app. Once deployment is up and running, we can create a service, using type ClusterIP, for our app.

First, let’s create a deployment running

$ kubectl run hello-world --replicas=2 --labels=load-balancer-example --image=gcr.io/google-samples/node-hello:1.0 --port=8080

Without going into too much detail, this command creates a deployment with two replicas of our application.

Next, run the below command to see the deployment is running. Now we can check the replicaset and pods that the deployment created.

$ kubectl get deployment hello-world
NAME          DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
hello-world   2         2         2            2           56s

With the applications running, we want to access one. So, let’s create a ClusterIP type of service. We can:

• Create a yaml manifest for the service and apply it, or
• Use the “kubectl expose” command, which is the easier option. This expose command creates a service without creating a yaml file.

$ kubectl expose deployment hello-world --type=ClusterIP --name=example-service
service "example-service" exposed

Here, we’ll create a service called example-service with type ClusterIP.

To access our application, run “kubectl get service example-service” to get our port number. Then, run a special command called port-forward. Because our service type is Cluster IP, which can only be accessed from within the cluster, we must access our app by forwarding the port to a local port.

We can use other types, like “LoadBalancer”, which will create a LB in AWS or GCP, then we can access the app using the DNS address given to the LB with our port number.

$ kubectl get service example-service
NAME              TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
example-service   ClusterIP   100.20.149.98   <none>        8080/TCP   1h

$ kubectl port-forward service/example-service 8080:8080
Forwarding from 127.0.0.1:8080 -> 8080

Now we can browse http://localhost:8080 from our workstation and we should see:

Hello Kubernetes!

• #1 Learn-by-Doing Online Cloud Training Platform - Linux Academy
• Production-Grade Container Orchestration
• Kubernetes Terminology: Glossary - Documentation | Bytemark

Quick Learning Guide for Kubernetes-Part III was originally published in DevOps and SRE Learning on Medium, where people are continuing the conversation by highlighting and responding to this story.

For starting up with this complete tutorial from scratch you would be needing a Linux Machine to run all the scripts which you can make it easily available from AWS EC2 Instances or running the VMWare Workstation Pro or Oracle Virtualbox with Ubuntu based iso file.

Introduction

What is Terraform ?

Terraform is a tool for building, changing, and versioning infrastructure safely and efficiently. Terraform can manage existing and popular service providers as well as custom in-house solutions.

Configuration files describe to Terraform the components needed to run a single application or your entire datacenter. Terraform generates an execution plan describing what it will do to reach the desired state, and then executes it to build the described infrastructure. As the configuration changes, Terraform is able to determine what changed and create incremental execution plans which can be applied.

The key features of Terraform are:

1. Infrastructure as Code

Infrastructure is described using a high-level configuration syntax. This allows a blueprint of your datacenter to be versioned and treated as you would any other code. Additionally, infrastructure can be shared and re-used.

2. Execution Plans

Terraform has a “planning” step where it generates an execution plan. The execution plan shows what Terraform will do when you call apply. This lets you avoid any surprises when Terraform manipulates infrastructure.

3. Resource Graph

Terraform builds a graph of all your resources, and parallelizes the creation and modification of any non-dependent resources. Because of this, Terraform builds infrastructure as efficiently as possible, and operators get insight into dependencies in their infrastructure.

4. Change Automation

Complex changesets can be applied to your infrastructure with minimal human interaction. With the previously mentioned execution plan and resource graph, you know exactly what Terraform will change and in what order, avoiding many possible human errors.

What is Kubernetes?

Kubernetes is a powerful open-source system, initially developed by Google, for managing containerized applications in a clustered environment. It aims to provide better ways of managing related, distributed components and services across varied infrastructure.

Kubernetes, at its basic level, is a system for running and coordinating containerized applications across a cluster of machines. It is a platform designed to completely manage the life cycle of containerized applications and services using methods that provide predictability, scalability, and high availability.

As a Kubernetes user, you can define how your applications should run and the ways they should be able to interact with other applications or the outside world. You can scale your services up or down, perform graceful rolling updates, and switch traffic between different versions of your applications to test features or rollback problematic deployments. Kubernetes provides interfaces and composable platform primitives that allow you to define and manage your applications with high degrees of flexibility, power, and reliability.

Installing Terraform

Terraform is very easy to install. You can download Terraform from the Terraform download page. Select the appropriate package for your operating system and architecture, unzip the archive and move the binary to a directory included in your PATH variable.

First, create ~/bin directory:

mkdir ~/bin

On Ubuntu, if you create this directory it will automatically be added to your PATH.

Next, download the zip archive. Visit the Terraform download page for the latest version to download.

wget https://releases.hashicorp.com/terraform/0.12.26/terraform_0.12.26_linux_amd64.zip

Unzip the archive. The archive will extract a single binary called terraform.

unzip terraform_0.12.26_linux_amd64.zip

Move the terraform binary to a directory included in your system's PATH in our case that's ~/bin directory.

mv terraform ~/bin

To check whether Terraform is installed, run:

terraform version
# Terraform v0.12.26

Install kubectl on Linux

Install kubectl binary with curl on Linux

1. Download the latest release with the command:

curl -LO https://storage.googleapis.com/kubernetes-release/release/`curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt`/bin/linux/amd64/kubectl

2. Make the kubectl binary executable.

chmod +x ./kubectl

3. Move the binary in to your PATH.

sudo mv ./kubectl /usr/local/bin/kubectl

4. Test to ensure the version you installed is up-to-date:

kubectl version --client

Configure AWS credentials

First of all, you need an AWS account.

Since the Terraform kubeadm module will create AWS resources on your behalf, it needs to have access to the Access Key ID and Secret Access Key of an IAM User in your AWS account.

If you’re already using the AWS CLI and have an ~/.aws/credentials file on your machine, then you should be good to go.

In all other cases, you can set the following environment variables:

export AWS_ACCESS_KEY_ID=<AccessKeyID>
export AWS_SECRET_ACCESS_KEY=<SecretAccessKey>

You can find out the Access Key ID and Secret Access Key of all the IAM users in your AWS account in the AWS IAM Console

Ensure default OpenSSH keys

The Terraform kubeadm module will set up SSH access to the nodes of the cluster by using the default key pair of OpenSSH:

• ~/.ssh/id_rsa (private key)
• ~/.ssh/id_rsa.pub (public key)

If you currently don’t have these files on your local machine, you can generate them with the following command:

$ ssh-keygen

You’re now ready to use the Terraform kubeadm module!

Various Methods for Kubernetes Cluster

There are many ways to create Kubernetes cluster s — from simple cluster installation tools like kubeadm to full-blown managed Kubernetes services like GKE, EKS, or AKS.

Generally, the available options pose a trade-off between automation and flexibility:

• Managed Kubernetes services make creating a cluster very easy, but they usually apply many default settings that you can’t configure.
• On the other extreme, installing Kubernetes manually without any scripts and tools allows you to configure every setting you want, but it requires many manual and error-prone steps.

Often, what you want is a middle ground between these two extremes.

Such as creating an un-opinionated cluster in a simple way — preferably with a single command.

This is especially true if you want to experiment with certain low-level Kubernetes features, such as CNI plugins — if a given cluster installation method installs a CNI plugin by default, you can’t use it for this purpose, since you need to be in control about which CNI plugin to install and how to configure it.

This article presents an approach that attempts to combine both automation and flexibility.

The created clusters are “minimum viable clusters”, as they are produced by kubeadm, with no CNI plugin installed and no opinionated settings applied.

The goal of this is to provide a base on which you can run controlled Kubernetes experiments (such as testing CNI plugins or experimenting with other Kubernetes features).

Managed Kubernetes services

There are two categories for creating a Kubernetes cluster: managed services and installation tools.

Managed Kubernetes services create and operate a cluster for you and give you access to it.

They allow you to use Kubernetes in a Software as a Service (SaaS) manner.

Managed Kubernetes services provide the highest degree of automation (creation and operation are entirely done for you), but the least amount of flexibility (you can configure only those settings that the service provider exposes through its API).

The most popular managed Kubernetes services are provided by the major cloud providers:

• Google Kubernetes Engine (GKE) by GCP
• Amazon Elastic Kubernetes Service (EKS) by AWS
• Azure Kubernetes Service (AKS) by Azure

Kubernetes installation tools

Kubernetes installation tools allow you to install and manage Kubernetes on your own (both on-premises or in the cloud).

They allow you to use Kubernetes like a traditional self-managed piece of software.

Installation tools provide varying degrees of automation and flexibility depending on the extent to which the tool wants to “get it right for you”.

At the time of writing, the most popular (and officially supported) Kubernetes installation tools are:

• kops
• kubespray
• kubeadm

The flip side of creating a cluster with kubeadm is being not a single-command operation (as it’s the case for kops and kubespray).

Rather, it requires a whole series of manual steps:

• Provision the infrastructure on which you want to create the cluster
• Log in to every node and install kubeadm and Docker on it
• Run the kubeadm init command on one of the nodes
• Run the kubeadm join command on all the other nodes

Furthermore, these steps depend on each other — for example, the kubeadm join commands must include a token and other identifiers that are generated by the initial kubeadm init command.

In summary, creating a Kubernetes cluster with kubeadm is a time-consuming tedious process when done manually.

This is where the Terraform kubeadm module comes in.

The Terraform kubeadm module

The Terraform kubeadm module automates the operation of kubeadm with the goal of providing both automation and flexibility.

However, the module does not only run kubeadm, but it also provisions the infrastructure for the cluster.

Currently, only AWS is supported as an infrastructure provider, but support for GCP and Azure is planned.

That means, with the Terraform kubeadm module, you can go from zero to a running cluster on AWS with a single command in a few minutes.

This brings you the convenience of kops without having to deal with opinionated features that you might not need.

With the Terraform kubeadm module, you get the exact same “minimum viable” cluster that you also get when running kubeadm manually.

More Details can be found at :

https://registry.terraform.io/modules/weibeld/kubeadm/aws/0.2.0

The power and versatility of Terraform comes from the Terraform providers.

Terraform providers are plugin-style components that encapsulate the interaction with the API of a specific service (e.g. AWS, GCP, Cloudflare) and expose the resources that can be managed through this service as Terraform resources.

Terraform resources are the basic building blocks of a Terraform configuration.

For example, there exists a Terraform provider for AWS, and this provider defines a Terraform resource named aws_instance which corresponds to an Amazon EC2 instance.

When you define an aws_instance Terraform resource in your Terraform configuration, Terraform will create an EC2 instance for you.

Furthermore, when you change the definition of the aws_instance resource in your configuration, Terraform will apply the corresponding changes to the real EC2 instance in your AWS account.

A Terraform configuration can be organised as a Terraform module.

A Terraform module encapsulates a piece of Terraform configuration so that it can be reused and shared.

The Terraform Registry is the primary place where Terraform modules are hosted and shared — you can browse hundreds of freely available Terraform modules there.

The Terraform kubeadm module is also freely available on the Terraform Registry, and the following sections explain how to use it.

Creating a single cluster

In the following, you will create a minimal cluster consisting of a single master node and two worker nodes on AWS.

Start by creating a new directory:

$ mkdir terraform-kubeadm
$ cd terraform-kubeadm

And in this directory, create a file named main.tf with the following content:

provider "aws" {
  region = "us-east-1"
}module "cluster" {
  source  = "weibeld/kubeadm/aws"
  version = "~> 0.2"
}

The above is a Terraform configuration that invokes the Terraform kubeadm module.

That’s all the code you have to write to create a minimal Kubernetes cluster.

But before you can do so, you have to initialise Terraform in your current working directory as follows:

$ terraform init

The terraform init downloads both the AWS provider and the Terraform kubeadm module to a subdirectory named .terraform in your current working directory.

Now you can start the process of turning your configuration into reality:$

$ terraform apply

The terraform apply command first shows you a so-called execution plan which is a summary of resources that Terraform will create, modify, or delete.

In your case, since you’re starting from zero, there should be only resources to create.

The command prompts you if you want to proceed, which you can confirm by typing yes.

Terraform now turns the execution plan into reality by creating the necessary AWS resources in your AWS account.

You can lean back and wait for Terraform to create your cluster!

It shouldn’t take longer than 3–4 minutes.

When the command completes, your cluster should be up and running!

In your current working directory, you should now have a file with a random name (such as modern-amoeba) and a .conf extension:

$ ls *.conf
 modern-amoeba.conf

This is the kubeconfig file for connecting to your newly created cluster.

You can use it to access your cluster with kubectl as follows:

$ kubectl --kubeconfig modern-amoeba.conf get pods --all-namespaces

Please replace modern-amoeba.conf with the name of your kubeconfig file.

You should see the system Pods of your cluster.

Congratulations, you just created your first cluster!

You can see the EC2 instances (and other resources) that Terraform created in your AWS account in the AWS EC2 Console.

So, looks like you have a running cluster now.

However, if you inspect the above output a bit closer, you should see that the coredns Pods are Pending:

And if the nodes of the cluster should be NotReady:

Don’t worry!

This doesn’t mean there’s something wrong — it’s the expected behaviour!

The reason is that your cluster doesn’t yet have a CNI plugin installed — this keeps the nodes in the NotReady state and prevents any Pods in the Pod network from being scheduled.

In case you wonder why the other Pods are all Running: that's because these Pods run in the host network (i.e. they have .spec.hostNetwork set to true) rather than in the Pod network, which doesn't depend on a CNI plugin.

The reason that your cluster has no CNI plugin installed is that kubeadm doesn’t install a CNI plugin by default — rather it leaves this choice to the user.

The article will show how to install a CNI plugin in your cluster later.

For now, let’s first explore the cluster a bit more.

Connecting to a node

In the following, you will SSH into one of the nodes of your cluster.

To do so, you need to know the public IP address of this node.

You could do so by going to the AWS EC2 Console and looking up the public IP address of the EC2 instance that corresponds to the node.

However, the Terraform kubeadm module provides an easier way to get this information.

The module features a collection of output values that convey internal information about the cluster to the user.

One of these outputs is called cluster_nodes and it contains information about the individual nodes of the cluster, including their public IP addresses.

You can include this output in your Terraform configuration as follows (added lines are highlighted):

provider "aws" {
  region = "us-east-1"
}module "cluster" {
  source  = "weibeld/kubeadm/aws"
  version = "~> 0.2"
}output "nodes" {
  value = module.cluster.cluster_nodes
}

To display this output, you have to run terraform apply again:

$ terraform apply --auto-approve

The --auto-approve flag automatically approves the execution plan so that you don't need to type yes.

When the command completes, you should see an output looking something like this:

As you can see, this contains some information about each node of the cluster, including its public IP address.

With this information, you can now SSH into any node of the cluster as follows:

$ ssh -i ~/.ssh/id_rsa ubuntu@<NODE-PUBLIC-IP>

Note that ~/.ssh/id_rsa is the default OpenSSH private key that is used by default by the Terraform kubeadm module to set up SSH access to the cluster nodes. It's the credential that allows you to connect to all the nodes of the cluster.

You should now be logged into the node, where you can do all kind of interesting things, such as listing the running containers:

$ sudo docker ps

But for now, just return to your local machine:

$ exit

There’s a way you can improve your cluster infrastructure!

Using a dedicated VPC instead of default

By default, the kubeadm module creates the cluster in the default VPC of the specified AWS region.

That means, the cluster coexists with other AWS resources in this VPC.

In some cases, this is not a problem, but in general, it’s a good idea to separate unrelated applications into separate VPCs.

The Terraform kubeadm module allows you to create a dedicated VPC for your cluster on-the-fly.

To do so, edit your Terraform configuration as follows (added lines are highlighted):

provider "aws" {
  region = "us-east-1"
}
module "network" {
  source  = "weibeld/kubeadm/aws//modules/network"
  version = "~> 0.2"
}
module "cluster" {
  source    = "weibeld/kubeadm/aws"
  version   = "~> 0.2"
  vpc_id    = module.network.vpc_id
  subnet_id = module.network.subnet_id
}
output "nodes" {
  value = module.cluster.cluster_nodes
}

The above configuration adds an invocation of the network submodule.

Since you added a new module invocation, you first need to run terraform init before you can apply the configuration:

$ terraform init

This downloads the network submodule to your local directory.

Now you can apply your new configuration:

$ terraform apply

Terraform now figures out how to get from the current state to the new specification and shows you the execution plan.

If you pay close attention to the execution plan, you can see that the aws_instance resources get destroyed and recreated — this means that Terraform will effectively destroy the existing cluster and create a new one in the new VPC.

To confirm the execution plan, type yes.

When the command completes, you should have both a new VPC and a new cluster running in it.

You can see the VPC that Terraform created in the AWS VPC Console.

Let’s test if you can still access this new cluster:

$ kubectl --kubeconfig real-hedgehog.conf get pods --all-namespaces

Voila…!!

You should see the list of system Pods just like before.

But now your cluster is running in its own VPC isolated from any other AWS resources!

Creating multiple clusters

So far, you created only a single cluster, but what if you want multiple ones?

For example, if you wanted to run a series of experiments on multiple clusters in parallel?

In the following, you will extend your fleet of clusters to three clusters in total.

To do so, edit your configuration as follows (changed lines are highlighted):

provider "aws" {
  region = "us-east-1"
}
module "network" {
  source  = "weibeld/kubeadm/aws//modules/network"
  version = "~> 0.2"
}
module "cluster" {
  source    = "weibeld/kubeadm/aws"
  version   = "~> 0.2"
  vpc_id    = module.network.vpc_id
  subnet_id = module.network.subnet_id
}
module "cluster_2" {
  source    = "weibeld/kubeadm/aws"
  version   = "~> 0.2"
  vpc_id    = module.network.vpc_id
  subnet_id = module.network.subnet_id
}
module "cluster_3" {
  source    = "weibeld/kubeadm/aws"
  version   = "~> 0.2"
  vpc_id    = module.network.vpc_id
  subnet_id = module.network.subnet_id
}
output "nodes" {
  value = {
    (module.cluster.cluster_name)   = module.cluster.cluster_nodes
    (module.cluster_2.cluster_name) = module.cluster_2.cluster_nodes
    (module.cluster_3.cluster_name) = module.cluster_3.cluster_nodes
  }
}

The main change of the above configuration consists in the addition of two invocations of the kubeadm module.

The configuration now includes three invocations of the kubeadm module, which results in Terraform creating three clusters.

In the present configuration, all clusters use the same settings, but you could configure each cluster separately by specifying different input variables for the individual invocations of the kubeadm module.

You could also create a dedicated VPC for each cluster by adding additional invocations of the network submodule.

If this configuration works, then, after applying it, you should have three running clusters.

Since you added additional module invocations, you first need to run terraform init:

$ terraform init

Now, you can apply the configuration with terraform apply:

$ terraform apply

If you pay attention to the execution plan that Terraform presents to you, you should see that it includes the creation of the resources belonging to two new clusters.

This means, that Terraform will create two new clusters while leaving the existing cluster unchanged — that’s because you just added two new cluster specifications in your configuration, but didn’t modify the existing one.

After you confirm the prompt with yes and the command completes, there should now be three running clusters!

You should now also have three kubeconfig files in your current working directory, one for each cluster:

Let’s test if you can access each of the clusters:

All the commands should succeed!

Which means that all three clusters are running.

Congratulations, you just created a fleet of three Kubernetes clusters!

Installing CNI plugins

You have three clusters now, but something might still slightly bother you about them.

They have no CNI plugin installed which causes the nodes to be NotReady and prevents any Pods from being scheduled.

Let’s fix that!

Having three freshly bootstrapped clusters is actually a great opportunity to compare different CNI plugins in a controlled environment.

Three of the most popular CNI plugins are:

• Calico
• Weave Net
• Cilium

So let’s install one of them on each cluster.

Install Calico on the first cluster:

$ kubectl apply \
  -f https://docs.projectcalico.org/manifests/calico.yaml \
  --kubeconfig careful-thrush.conf

Install Weave Net on the second cluster:

# Identify Kubernetes version
$ K8S_VERSION=$(kubectl version --kubeconfig large-walleye.conf | base64 | tr -d '\n')
# Install CNI plugin
$ kubectl apply \
  -f "https://cloud.weave.works/k8s/net?k8s-version=$K8S_VERSION" \
  --kubeconfig large-walleye.conf

And install Cilium on the third cluster:

$ kubectl apply \
  -f https://raw.githubusercontent.com/cilium/cilium/1.7.0/\
install/kubernetes/quick-install.yaml \
  --kubeconfig modern-amoeba.conf

Now, give the CNI plugins some time to initialise.

Then query the nodes of your clusters again:

Voila …!!

All the nodes should be Ready now!

If you list the Pods, they should now also all be Running.

The CNI plugins indeed completed the setup of your clusters and rendered them fully functional.

At this point, you can launch further Pods in your clusters and do more experiments.

Destroying the clusters

When you’re done experimenting with the clusters, you should delete them because, unfortunately, running clusters on AWS costs money.

Fortunately, Terraform makes this very easy.

All you have to is to issue the following command:

$ terraform destroy

The terraform destroy deletes all the resources from your configuration that are currently running.

This means that all the AWS resources corresponding to your clusters will be deleted.

The command also shows you an execution plan, specifying the exact set of resources that will be deleted, which you can confirm with yes.

When the command completes, your AWS account will be in exactly the same state as it was before your ran terraform apply for the first time!

Conclusion

This article presented the Terraform kubeadm module which allows to automatically spin-up a Kubernetes multi-clusters on AWS using the kubeadm functionality with terraform simplicity and consistency.

References:

• Terraform Registry
• Terraform | HashiCorp Developer
• What is Amazon EKS?

Setting up Multi-Cluster Kubernetes on AWS Using the Terraform as IaC was originally published in DevOps and SRE Learning on Medium, where people are continuing the conversation by highlighting and responding to this story.

We developers often have access tokens and other sensitive information flowing through our applications. Access tokens are needed so that we can consume APIs on behalf of our users, and the tokens have to be stored somewhere.

With single-page applications, it’s tempting to store access tokens directly in the browser. Doing so is convenient because it makes it easy to intercept API hits and add the token to an Authorization header.

But here’s the problem: major identity providers explicitly warn against keeping access tokens in the browser, as does OWASP, and the authors of the OAuth 2.0 Best Current Practices specification.

“It’s recommended not to store any sensitive information in local storage.” -OWASP Cheat Sheet

“Don’t store tokens in local storage.” -Auth0: Where to Store Tokens

“You are safe from CSRF, but you have opened yourself up to a much greater attack vector… XSS.” -Okta: JWTs Suck

What is Vault?

Vault is a tool for securely accessing secrets. A secret is anything that you want to tightly control access to, such as API keys, passwords, or certificates. Vault provides a unified interface to any secret, while providing tight access control and recording a detailed audit log.

A modern system requires access to a multitude of secrets: database credentials, API keys for external services, credentials for service-oriented architecture communication, etc.

Understanding who is accessing what secrets is already very difficult and platform-specific. Adding on key rolling, secure storage, and detailed audit logs is almost impossible without a custom solution. This is where Vault steps in.

Key Features of Vault

1. Dynamic Secrets

Vault can generate secrets on-demand for some systems, such as AWS or SQL databases. For example, when an application needs to access an S3 bucket, it asks Vault for credentials, and Vault will generate an AWS keypair with valid permissions on demand. After creating these dynamic secrets, Vault will also automatically revoke them after the lease is up.

2. Secure Secret Storage

Arbitrary key/value secrets can be stored in Vault. Vault encrypts these secrets prior to writing them to persistent storage, so gaining access to the raw storage isn’t enough to access your secrets. Vault can write to disk, Consul, and more.

3. Data Encryption

Vault can encrypt and decrypt data without storing it. This allows security teams to define encryption parameters and developers to store encrypted data in a location such as SQL without having to design their own encryption methods.

4. Leasing and Renewal

All secrets in Vault have a lease associated with them. At the end of the lease, Vault will automatically revoke that secret. Clients are able to renew leases via built-in renew APIs.

5. Revocation

Vault has built-in support for secret revocation. Vault can revoke not only single secrets, but a tree of secrets, for example all secrets read by a specific user, or all secrets of a particular type. Revocation assists in key rolling as well as locking down systems in the case of an intrusion.

What are the Vault Goals?

1. Single Source of Secrets
2. Programmatic Application Access(Automated)
3. Operator Access(Manual)
4. Practical Security
5. Modern Data Center Friendly

Installation Steps for HashiCorp Vault

$ wget https://releases.hashicorp.com/vault/1.0.3/vault_1.0.3_linux_amd64.zip
$ unzip vault_1.0.3_linux_amd64.zip -d .
$ sudo cp vault /usr/bin/
$ sudo mkdir /etc/vault
$ sudo mkdir /opt/vault-data
$ sudo mkdir -p /logs/vault/

Configuration File for the Vault:

$ sudo vi /etc/vault/config.json

Configuring the Vault Service on the Virtual Machine

$ sudo vi /etc/systemd/system/vault.service

Now,starting the HashiCorp Vault Service on the Private IP Address provided in the Configuration File by running the command shown below:

$ sudo systemctl start vault.service
$ sudo systemctl status vault.service

Now, it ask for the Number of Key Share you want to split your Master Key into;and shown below I am inputting 5 value and it is asking how many keys are required to re-create the master key — threshold key (3).

Now you would be needing minimum of 3 threshold keys to unseal your master vault.

It asks the Root Token or the Root Password to login into Vault to configure the User, Policies, Secrets in Vault Directory.

After successfully inputting minimum 3 threshold keys correctly and passing the correct Token Value,we are logged-in inside the Vault Account.

In the next article,we will learn how to create users, policies, secret on Vault to store our authentication server credentials for future purpose.

Securing Access Token/Credentials using HashiCorp Vault was originally published in DevOps and SRE Learning on Medium, where people are continuing the conversation by highlighting and responding to this story.