In this blog post, I will discuss the necessary measures one should implement to ensure the security of your GitHub code and repository.

1/ ⚙️ Enable Two-Factor Authentication (2FA):

Strengthen your GitHub account security by enabling 2FA. Go to Settings > Security > Two-factor authentication. Use an authentication app for an added layer of protection.

2/ 🛑 Avoid Hardcoding Secrets:

Never hardcode sensitive information like API keys or passwords in your code. Use environment variables or secure vaults.

3/ 🚨 Private Repositories:

For sensitive projects, use private repositories. Public repositories are visible to everyone; private ones restrict access.

4/ 🚥 Branch Protection Rules:

Set up branch protection rules to prevent force pushes and ensure a clean history. This adds a layer of control and security.

5/ 🚫 Limit Access:

Grant access only to necessary collaborators. Use team permissions wisely, and regularly review and revoke access for inactive members.

6/ 🛡️ Code Scanning and Dependabot:

GitHub provides tools like Code Scanning and Dependabot to identify and fix vulnerabilities in your code and dependencies. Enable them in your repository settings.

7/ 📅 Regularly Update Dependencies:

Keep your dependencies up-to-date to patch vulnerabilities. Dependabot can automate this process for you.

8/ 📜 License Management:

Use licenses to control how others can use, modify, and distribute your code. Choose a license that aligns with your project goals.

9/ 🔄 Regular Backups:

Periodically backup your repositories. GitHub provides an “Export repository” feature in your repository settings.

10/ 🔄 Regular Security Audits:

Conduct regular security audits of your codebase. Tools like GitHub Security Advisories can help track and resolve vulnerabilities.

11/ 🚀 Use Webhooks for Monitoring:

Set up webhooks to monitor repository activities. Receive alerts for any suspicious activity.

12/ 🤖 Automated Testing:

Implement automated testing for your code. Continuous Integration (CI) tools like GitHub Actions can help ensure code quality and security.

13/ 🌐 Use HTTPS:

Clone repositories using HTTPS rather than SSH for added security. HTTPS uses your GitHub credentials, while SSH uses SSH keys.

14/ 🧑‍💻 Educate Collaborators:

Train your collaborators on security best practices. Awareness is key in maintaining a secure development environment.

15/ 🌐 Monitor Third-Party Integrations:

Review and monitor third-party applications and integrations connected to your GitHub account. Revoke access for any unnecessary or unused integrations.

16/ 🚦 Security Advisories:

Keep an eye on GitHub Security Advisories for any reported vulnerabilities in the libraries or tools you use.

Stay secure and happy coding! 🔒👩‍💻👨‍💻

Here is a step-by-step process of installing Kubernetes 1.27 via Kubeadm on RHEL.

1: Installing Kubeadm Dependencies to start —

To start, make sure you have a RHEL machine ready. Install the necessary dependencies:

$ sudo yum install -y docker kubelet kubeadm
$ sudo systemctl enable docker && sudo systemctl start docker
$ sudo systemctl enable kubelet && sudo systemctl start kubelet

2: Initializing the Master Node
On the master node, initialize Kubernetes using Kubeadm:

$ sudo kubeadm init

This command will generate a token that you’ll need to join worker nodes to the cluster.

3: Configuring the Master Node
Once the initialization completes, follow the on-screen instructions to configure the Kubernetes master node:

$ mkdir -p $HOME/.kube
$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
$ sudo chown $(id -u):$(id -g) $HOME/.kube/config

4: Deploying a Pod Network
Next, choose a pod network add-on. Popular options are Calico, Flannel, and Weave. Let’s use Calico:

$ kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml

Wait for the Calico pod network to be deployed and ready.

5: Joining Worker Nodes
On each worker node, join the cluster using the generated token from step2 :

$ sudo kubeadm join <master-node-ip>:<master-node-port> --token <token> --discovery-token-ca-cert-hash <hash>

6: Verifying Cluster Status
Back on the master node, run the following command to check the cluster’s health:

$ kubectl get nodes

You should see all the nodes in the “Ready” state.

7: Managing the Cluster as a Regular User
By default, you cannot manage the cluster as a regular user. To change that, run:

$ kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=<your-username>

8: Configuring Network Routes (Optional)
If you encounter issues with network routing, you may need to adjust the network configuration. Consult your network admin or refer to Kubernetes documentation for guidance.

9: Scaling the Cluster (Optional)
To add more worker nodes later, use the same join command from step 5 on each new node.

10: Congratulations!

You’ve successfully installed Kubernetes 1.27 via Kubeadm on RHEL. Enjoy managing your cluster and deploying applications!

Here are a few additional steps you can include after Step 10:

11: Exposing the Kubernetes API Server

By default, the Kubernetes API server is only accessible on the master node. If you want to expose it externally, you can configure a load balancer or use a tool like Nginx to proxy requests to the API server. Consult the Kubernetes documentation for detailed instructions.

12: Securing the Cluster

To enhance the security of your cluster, consider implementing RBAC (Role-Based Access Control), enabling audit logging, and enforcing network policies. These measures help protect your Kubernetes environment from unauthorized access and potential security breaches.

13: Upgrading Kubernetes

As new versions of Kubernetes are released, you might want to upgrade your cluster. Before proceeding, review the upgrade documentation provided by the Kubernetes project. Upgrading involves updating the Kubeadm tool and following a specific procedure to ensure a smooth transition to the new version.

Remember, these additional steps are optional and depend on your specific requirements.

Firewall Considerations:

Adjusting firewall rules is an important step when installing Kubernetes on RHEL. By default, RHEL has a firewall (iptables or firewalld) enabled that may block certain network traffic required for Kubernetes to function properly. Here’s what you need to consider:

1: Master Node Firewall Rules:

Allow inbound traffic on specific ports:

• API Server: TCP port 6443 (kube-apiserver)
• etcd Server: TCP port 2379 (etcd), 2380 (etcd peer communication)
• Kubelet API: TCP port 10250
• Control Plane: TCP port range 10251–10252 (kube-scheduler, kube-controller-manager)

Optionally, allow inbound traffic for any other services you want to expose externally, such as load balancers or ingress controllers.

2: Worker Node Firewall Rules:

Allow inbound traffic on specific ports:

• Node Port Services: TCP port range 30000–32767 (configured in Kubernetes service definitions)
• Kubelet API: TCP port 10250

Optionally, allow inbound traffic for any other services required by your applications.

3: Inter-Node Communication:

• Allow internal communication between nodes. This usually involves opening ports for the CNI (Container Network Interface) plugin you’re using, such as Calico, Flannel, or Weave.

4: DNS Resolution:

• Ensure DNS resolution is allowed for cluster components to communicate with each other. By default, DNS uses TCP/UDP port 53.

It’s important to note that the specific firewall configuration depends on your network setup and security policies. Consult your network administrator or security team for guidance on configuring firewall rules in your environment.

By adjusting the firewall rules appropriately, you ensure that the necessary network communication between Kubernetes components and your applications can occur without any interruptions.

That’s all! Let me know if there’s anything else I can assist you with!

Thanks!

You can connect to GitHub using the Secure Shell Protocol (SSH), which provides a secure channel over an unsecured network.

This is a step by step guide to configure ssh connection with your GitHub account.

STEP 1 — Check if you already have SSH keys

Before generating a new SSH key, you should check if you have any existing SSH keys.

root@lco-linux-worker1:~# ls -la .ssh/
total 24
drwx------ 2 root root 4096 Oct  1 17:52 .
drwx------ 9 root root 4096 Oct  1 18:11 ..
-rw------- 1 root root  993 Apr 13 12:18 authorized_keys
-rw-r--r-- 1 root root 1326 Oct  1 17:58 known_hosts

Check the .ssh directory listing to see if you already have a public SSH key. By default, the filenames of the public keys are one of the following:

• id_rsa.pub
• id_ecdsa.pub
• id_ed25519.pub

As we can see above we don’t have any existing ssh keys available to connect to GitHub. So we will have to generate a new one.

STEP 2— Generating a new SSH key

Run the following command to generate the new ssh key pair.

root@lco-linux-worker1:~/.ssh# ssh-keygen

root@lco-linux-worker1:~/.ssh# ls
authorized_keys  id_rsa  id_rsa.pub

To generate RSA 4096 bit key (as it provides a reasonable increase in strength over a 2048 bit key) run the following command:

ssh-keygen -t rsa -b 4096

Now you can see see a public and private key pair listed (`id_rsa.pub` and `id_rsa`) that you would like to use to connect to GitHub.

STEP 3 — Adding your SSH key to the ssh-agent

First you need to start the ssh-agent in the background:

# eval "$(ssh-agent -s)"
Agent pid 2020

Add your SSH private key to the ssh-agent:

# ssh-add /root/.ssh/id_rsa

Verify the key fingerprint added:

# ssh-add -l -E sha256

# ssh-keygen -l -f id_rsa

STEP 4 — Add the SSH key to your account on GitHub

• First Copy the SSH public key to your clipboard
• In the upper-right corner of any page, click your profile photo, then click Settings.
• In the user settings sidebar, click SSH and GPG keys.
• Click New SSH key or Add SSH key.
• In the “Title” field, add a descriptive label for the new key for example here I’ve added the system hostname “lco-linux-worker1” and then Click Add SSH key.
• If prompted, confirm your GitHub password.

STEP 5 — Verify the SSH connectivity from the client system

Run the following command to verify the Git SSH connectivity.

# ssh -T git@github.com

You may see a warning like this:

> The authenticity of host 'github.com (IP ADDRESS)' can't be established.
> RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
> Are you sure you want to continue connecting (yes/no)?

Verify that the fingerprint in the message you see matches GitHub’s RSA public key fingerprint. If it does, then type yes and that’s all!

Now you can perform various Git operations like cloning, push, pull, commit etc.

Using SSH over the HTTPS port

Sometimes, firewalls refuse to allow SSH connections entirely. If using HTTPS cloning with credential caching is not an option, you can attempt to clone using an SSH connection made over the HTTPS port. Most firewall rules should allow this, but proxy servers may interfere.

To test if SSH over the HTTPS port is possible, run this SSH command:

# ssh -T -p 443 git@ssh.github.com

Enabling SSH connections over HTTPS

If you are able to SSH into git@ssh.github.com over port 443, you can override your SSH settings to force any connection to GitHub to run through that server and port.

To set this in your ssh config, edit the file at ~/.ssh/config, and add this section:

# touch .ssh/config
# chmod 600 .ssh/config

# cat > .ssh/config
Host github.com
Hostname ssh.github.com
Port 443
User git

# ssh -T git@github.com

You can test this by connecting once more to GitHub:

$ ssh -T git@github.com
Hi DevopsVlogger! You've successfully authenticated, but GitHub does not provide shell access

Known Errors

Error — 
Github permission denied: ssh add agent has no identities:

Reason — 
When ssh-add -l returns “The agent has no identities”, it means that keys used by ssh (stored in files such as ~/.ssh/id_rsa, ~/.ssh/id_dsa, etc.) are either missing, they are not known to ssh-agent, which is the authentication agent, or that their permissions are set incorrectly (for example, world writable).

Solution — 
If your keys are missing or if you have not generated any, use ssh-keygen -t rsa, then ssh-add to add them.
If keys exist but are not known to ssh-agent (like if they are in a non-standard folder), use ssh-add /path/to/my-non-standard-ssh-folder/id_rsa to add them.

That is all!

Hope you like the tutorial. Stay tuned and don’t forget to provide your feedback in the response section.

Happy Learning!

What is Homebrew?

homebrew is known as “The Missing Package Manager for macOS”.

It is used to install the UNIX tools Apple didn’t include with macOS in an extremely easy and flexible manner.

Prerequisites

• A 64-bit Intel CPU or Apple Silicon CPU
• macOS Mojave (10.14) (or higher)
• Command Line Tools (CLT) for Xcode: xcode-select --install, developer.apple.com/downloads or Xcode 3

How to install it on MacOSX?

Install xcode developer tools.

rakesh_jain@my-mac ~ % xcode-select --install

Now install homebrew:

rakesh_jain@my-mac ~ % /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"

You will be prompted to enter sudo password a few times during the installation process.

Verify the installation:

rakesh_jain@my-mac ~ % brew --version

Homebrew 3.2.13

Homebrew/homebrew-core (git revision 753dedc193; last commit 2021-09-22)

Homebrew Shell Completion — BASH / ZSH

Homebrew comes with completion definitions for the brew command.

zsh, bash and fish are currently supported.

If you have zsh shell ->

rakesh_jain@my-mac ~ % echo $SHELL
/bin/zsh

To make Homebrew’s completions available in zsh, you must get the Homebrew-managed zsh site-functions on your FPATH before initialising zsh’s completion facility. Add the following to your ~/.zshrc file:

rakesh_jain@my-mac ~ % cat .zshrc 
if type brew &>/dev/null
then
  FPATH="$(brew --prefix)/share/zsh/site-functions:${FPATH}"

autoload -Uz compinit
  compinit
fi

If you have bash shell ->

To make Homebrew’s completions available in bash, you must source the definitions as part of your shell’s startup. Add the following to your ~/.bash_profile (or, if it doesn’t exist, ~/.profile):

rakesh_jain@my-mac ~ % cat .bash_profile

if type brew &>/dev/null
then
  HOMEBREW_PREFIX="$(brew --prefix)"
  if [[ -r "${HOMEBREW_PREFIX}/etc/profile.d/bash_completion.sh" ]]
  then
    source "${HOMEBREW_PREFIX}/etc/profile.d/bash_completion.sh"
  else
    for COMPLETION in "${HOMEBREW_PREFIX}/etc/bash_completion.d/"*
    do
      [[ -r "${COMPLETION}" ]] && source "${COMPLETION}"
    done
  fi
fi

If you install the bash-completion formula, this will automatically source the completions’ initialisation script (so you do not need to follow the instructions in the caveats).

How to install unix tools with homebrew ?

The homebrew is now installed on you system and you can use it to install various unix tools.

Syntax:

rakesh_jain@my-mac ~ % brew install <package_name>

For example here I will be installing ansible configuration management tool on my Mac Book:

rakesh_jain@my-mac ~ % brew install ansible

How to search package with homebrew?

You can search or list available packages by running following commands :

Syntax:

rakesh_jain@my-mac ~ % brew search <package_name>

Example:

rakesh_jain@my-mac ~ % brew search docker
==> Formulae
docker                              docker-credential-helper-ecr        docker-machine-driver-vmware        docker-squash
docker-clean                        docker-gen                          docker-machine-driver-vultr         docker-swarm
docker-completion                   docker-ls                           docker-machine-driver-xhyve         docker2aci
docker-compose                      docker-machine                      docker-machine-nfs                  dockerize
docker-compose-completion           docker-machine-completion           docker-machine-parallels            lazydocker
docker-credential-helper            docker-machine-driver-hyperkit      docker-slim                         mockery
==> Casks
homebrew/cask-versions/docker-edge              homebrew/cask/docker                            homebrew/cask/docker-toolbox

That’s all!

Hope you like the tutorial. Stay tuned and don’t forget to provide your feedback in the response section.

Happy Learning!

We all know the importance of highly available databases. The DB downtime can lead to unimaginable losses in revenue and reputation as well.

This guide will demonstrate the easiest way to configure database backups locally and sending alert notification after each run. Ideally we should always backup mission critical databases on to remote servers.

My setup:

OS: Ubuntu 20.04 LTS Server
DB: Postgres psql (PostgreSQL) 12.6 (Ubuntu 12.6–0ubuntu0.20.04.1)
Application: Running an open-source IPAM/DCIM application called NetBox.
DB Name: netbox

Backup Script

Following is my backup script which will take the netboxdatabase backup and save the sql dump file locally at /opt/netbox/dumps/ location.

PostgreSQL provides the pg_dump utility to back up databases.

#!/bin/bash

# You should eventually backup remotely

# Backup Folder name
backupfolder=/opt/netbox/dumps

# Notification email address
recipient_email=test_user@example.com

# MySQL user
user=postgres

sudo -u $user /usr/bin/pg_dump netbox > $backupfolder/netbox.$(date +%Y%m%d-%H%M%S).sql

if [[ $? -eq "0" ]]; then

echo -e  "NetBox Data backup is successful" | mail -s "NetBox db backup is successful" $recipient_email

else

echo "Failed to produce NetBox data backup" | mail -s "Please have a look. NetBox db backup task failed!" $recipient_email

fi

To backup all the databases you can use pg_dumpall command.

Configure Email Alerting

To send email notifications we need to configure Postfix on a null client.

A null client is a machine that can only send mail. It receives no mail from the network, and it does not deliver any mail locally. A null client typically uses POP, IMAP or NFS for mailbox access.

Steps to configure Alerting:

1. Install mailutils and postfixpackage.

apt-get install mailutils postfix

2. Configure /etc/postfix/main.cf

Configure following parameters in postfix main.cf file.

myhostname = labs-netbox.example.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = example.com
mydestination =
relayhost = smtp.example.com
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = loopback-only
inet_protocols = all

3. Restart the postfix service

systemctl restart postfix

Below is the email alert notification sample.

Schedule the backup task to run daily at midnight

root@labs-netbox:/opt/netbox# crontab -l
@daily /opt/netbox/backup.sh

The above crontab entry make sure that the backup script runs every midnight.

Delete old backups

Along with the above I have scheduled a backup retention task as well. All the database backup files older than 30 days will be deleted.

root@labs-netbox:/opt/netbox# crontab -l
@daily /opt/netbox/backup.sh

0 0 * * 0 /usr/bin/find /opt/netbox/dumps/ -type f -mtime +30 -exec rm -rf {} +

That’s all!

Hope you like the tutorial. Stay tuned and don’t forget to provide your feedback in the response section.

Happy Learning!

It’s been a long time I’ve written a story on Medium. Here I am back again.

Today we will discuss about a new cloud adoption approach (not that new by the way) I would say not much experienced.

The Multi-Cloud!

What is Multi-Cloud?

As name suggests the Multi-cloud is a strategy where we use two or more cloud computing services from any number of different cloud vendors in a single unified network architecture.

It’s different then hybrid cloud where we integrate public and private clouds in order to achieve optimal performance, security and flexibility.

Multi-cloud is when an organizations selects different cloud providers for their various infrastructure and application needs.

Why it is getting so much attention?

There are multiple reasons to this.

• Cost effectiveness / Competitive Pricing
• Eliminate the reliance on any single cloud provider (avoid lock-ins)
• Ensures high availability!
• Enhanced Risk Management (in case of an attack on one vendor we can always switch to another vendor without any disruption)
• Global compliance can be achieved
• Improved user experience
• Optimal Performance
• Lower Latency

What challenges it brings in?

Not everything is green here. This strategy comes up with a unique set of challenges which organizations have to face.

• Security
  We can have additional security concerns here as we know the traditional security tools aren’t that mature to protect you from all potential threats. Considering the type of attacks we are seeing these days are very sophisticated in nature. The multi-cloud approach increases the risk with having complex application deployed over multiple cloud vendors. It opens up a larger attack surface. To counter this one should have a multi-layered security approach and a mix set of vendor experts.
• Management Overhead
  It’s obvious that when you use services from more than one cloud vendors it will increase your management complexity.
  few such examples are like: OS patching, Application and service monitoring, Log management spread across multiple environments, backups etc..
• Competent Staffing
  Finding people having expertise in multi-cloud is very very difficult as of today. There has to be mix of people experts in development on multiple cloud platforms, the security specialists and one who can manage and operate across multiple clouds.
• Migration takes time!
• Complex Cost estimation process
  There again you need to have proper talent who can plan and strategize the costing part of your project. Though multi-cloud approach can save you money but it becomes complex at times.

What it takes to move to Multi-Cloud?

If your company has decided to adopt Multi-cloud approach for your heterogeneous infrastructure following are the things which you need to take care of.

• Bring in individual cloud experts together
• Plan the whole infrastructure in advance
• Do cost estimations in prior
• Build DevOps pipelines
• Cloud Performance Monitoring

As far I understand Multi-Cloud has a huge market scope given we together overcome the disadvantages and make most out of this approach.

That’s all for this small article.

Thank you All!

Hope you like the article. Don’t forget to like, share and follow my handle for more updates.

A DevOps aspirant who is learning about Continuous Integration and Continuous Deployment using Jenkins. There may be someone who is learning about Monitoring with Prometheus and Alert Manager.

While learning all these tools and technologies the most important thing is “how you are going to send out notifications to users regarding your jobs/builds status (failed or successful).” The recommended way is to send out an email notification to a Project/Team’s distribution list (DL) or to the maintainer of the project. In companies you might have your own SMTP servers and clients configured and can get access to the information by quickly asking your admin teams.

The problem comes when you are practicing these things at you own lab setups, you need to rely on the Public Online email providers such as Google’s Gmail, Yahoo Mail, Outlook and so on.

And you can’t go to their portals every time to read & send emails. You are going to use a local email client such as Outlook Express, Microsoft Outlook, Thunderbird etc..

To configure such a setup, your email software should be configured with the incoming and outgoing mail servers of your email provider (Gmail, Outlook, Office365, Yahoo! Mail etc.).

A Brief intro about the terms involved here

SMTP

The Simple Mail Transfer Protocol is an internet standard communication protocol for electronic mail transmission. Most of the internet systems use SMTP as a method to transfer mail from one user to another.

POP vs. IMAP

POP (Post Office Protocol) and IMAP (Internet Message Access Protocol) are two different ways to get email in your email program.

Port Numbers

Your email port is how email moves from one email server to another.

List of SMTP, IMAP, POP3 Email Ports and Servers of these popular Online email providers

Standard/Default Mail server Ports

Outlook.com

Google’s Gmail

Office365.com

Yahoo Mail

Mail.com

Hotmail

AOL.com

Comcast

Email Notification Settings in my Jenkins Server

That’s all!

Thanks for reading.

Hope you like the article. Please let me know your feedback in the response section.

What to do when the auto-completion of bash shell commands are not working. It’s something which we expect these days to happen by default.

In this short tutorial, I will demonstrate how we can enable auto-completion on Ubuntu and CentOS systems.

Enable Bash Auto Completion on CentOS Linux

Please follow the below steps one by one to enable Auto completion.

Step 1: Enable/Install EPEL repository

yum -y install epel-release

Step 2: Install bash-completion packages

yum install bash-completion bash-completion-extras -y

Step 3: Locate and Enable bash-completion

locate bash_completion.sh

updatedb

source /etc/profile.d/bash_completion.sh

logout

Now the auto-completion should be working on your server.

Step 4: Verify the working

Press starting characters of any command and press tab you will see command completions.

Enable Bash Auto Completion on Ubuntu Linux

Please follow the below steps one by one to enable Auto completion on Ubuntu.

Step 1: Install bash-completion package

apt-get install bash-completion -y

Step 2: Update .bashrc file

By now you will have `/etc/profile.d/bash_completion.sh` file in your system.

Source this file from either ~/.bashrc or ~/.bash_profile.

echo "source /etc/profile.d/bash_completion.sh" >> ~/.bashrc

Step 3: Logout and Login Back to experience it

If you want this to be enabled in the current session you can source it directly from the command line.

source /etc/profile.d/bash_completion.sh

That’s all!

Thanks for reading.

Hope you like the article. Please let me know your feedback in the response section.

👋 Join FAUN today and receive similar stories each week in your inbox! ️ Get your weekly dose of the must-read tech stories, news, and tutorials.

Follow us on Twitter 🐦 and Facebook 👥 and Instagram 📷 and join our Facebook and Linkedin Groups 💬

If this post was helpful, please click the clap 👏 button below a few times to show your support for the author! ⬇

Configure Bash Auto Completion (Tab Completion) on Linux was originally published in FAUN.dev() 🐾 on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is one thing which everyone of us might have faced difficulty with or are still struggling to get a simple and exact answer.

FYI both curl and wget support HTTP, HTTPS, and FTP protocols.

Let’s get our hands dirty.

Downloading Files and Directories from web with WGET

Our first target is to download directories and underneath files from below location

Index of /centos/7.9.2009/updates/x86_64

wget $ wget -np -P . -r -R "index.html*" --cut-dirs=4 http://mirror.myfahim.com/centos/7.9.2009/updates/x86_64/

Let us understand this command in detail.

- -no-parent or -np
Do not ever ascend to the parent directory when retrieving recursively. This is a useful option, since it guarantees that only the files below a certain hierarchy will be downloaded.

Note that, for HTTP (and HTTPS), the trailing slash is very important to “— -no-parent”. HTTP has no concept of a “directory”. Wget relies on you to indicate what’s a directory and what isn’t. In ‘http://foo/bar/’, Wget will consider ‘bar’ to be a directory, while in ‘http://foo/bar’ (no trailing slash), ‘bar’ will be considered a filename (so ‘ — -no-parent’ would be meaningless, as its parent is ‘/’).

-P prefix or - -directory-prefix=prefix
Set directory prefix to prefix. The directory prefix is the directory where all other files and subdirectories will be saved to, i.e. the top of the retrieval tree. The default is ‘.’ (the current directory).

-r or - -recursive
Turn on recursive retrieving. The default maximum depth is 5.

‘-R rejlist or - -reject rejlist’
Specify comma-separated lists of file name suffixes or patterns to accept or reject. Note that if any of the wildcard characters, ‘*’, ‘?’, ‘[’ or ‘]’, appear in an element of acclist or rejlist, it will be treated as a pattern, rather than a suffix. In this case, you have to enclose the pattern into quotes to prevent your shell from expanding it, like in ‘-A “*.mp3”’ or ‘-A ‘*.mp3’’.

Like we have done for all “index.html” files -> -R “index.html*”

cut_dirs = n
If you do not want the first few directories you can Ignore n remote directory components. Equivalent to - -cut-dirs=n.

Once run you will have the directory structure like below.

Now download files only from here

http://mirror.myfahim.com/centos/7.9.2009/updates/x86_64/repodata/

Here is the command.

wget $ wget -nd -np -P . -r -R "index.html*" http://mirror.myfahim.com/centos/7.9.2009/updates/x86_64/repodata/

Here we have used one additional parameter — -nd.

-nd or - -no-directories

Do not create a hierarchy of directories when retrieving recursively. With this option turned on, all files will get saved to the current directory, without clobbering (if a name shows up more than once, the filenames will get extensions ‘.n’).

This command will download the files on the same directory.

wget is the go to solution for us as it only supports a small number of protocols. Its very effective for downloading files and can also be used to download directory structures recursively.
For more information on various other arguments please go here.

Downloading Files from web with CURL

curl does not provide recursive download. So we can only use it for downloading files.

Download a single file with curl

curl $ curl -O http://mirror.myfahim.com/centos/7.9.2009/updates/x86_64/repodata/repomd.xml

Download multiple files with curl

To download multiple files at the same time, use –O followed by the URL to the file that you wish to download.

Use the following syntax for this purpose:

curl -O [url1] -O [url2]

You can also make use of double quoting the URL to avoid copying it multiple times:

curl -O "http://domain/path/to/{file1,file2}"

curl $ curl -O “http://mirror.myfahim.com/centos/7.9.2009/updates/x86_64/repodata/{http://mirror.myfahim.com/centos/7.9.2009/updates/x86_64/repodata/repomd.xml, http://mirror.myfahim.com/centos/7.9.2009/updates/x86_64/repodata/repomd.xml.asc}"

If you curl without any options except for the URL, the content of the URL (whether it's a webpage, or a binary file, such as an image or a zip file) will be printed out to screen. So better you either save it with -o option or download with the original with -O option.

Downloading and Uploading files over FTP using CURL and WGET

curl and wget can be used to download files using the FTP protocol:

wget --user=ftpuser --password='ftpuserpassword' ftp://mywebsite.com/testdoc.pdf
curl -u ftpuser:ftpuserpassword 'ftp://mywebsite.com/testdoc.pdf' -o testdoc.pdf

CURL vs WGET — few differences

The main differences are:

• wgetcan download files recursively whereas curl can not.
• wget is a CLI utility and no libraries associated with it whereas curl is part of feature rich library libcurl.
• curl supports FTP, FTPS, HTTP, HTTPS, SCP, SFTP, TFTP, TELNET, DICT, LDAP, LDAPS, FILE, POP3, IMAP, SMTP, RTMP and RTSP. wget supports HTTP, HTTPS and FTP.
• curl offers upload and sending capabilities. wget only offers plain HTTP POST support.

That’s all!

Thanks for reading.

Hope you like the article. Please let me know your feedback in the response section.

Kubernetes 1.20 was released on Dec 8, 2020! They call it “The Raddest Release”.

Kubernetes as a Technology as a Platform and as a Business Model growing by leaps and bounds. Kubernetes team is continuing to work on improving user experience by enhancing the feature sets.

This was a much-awaited release this year.

What this release brings to you?

As per their official announcement “This release consists of 42 enhancements: 11 enhancements have graduated to stable, 15 enhancements are moving to beta, and 16 enhancements are entering alpha.”

For those who are not aware of these Development Stages:
Pre Alpha: all activities performed during the software project before formal testing. These activities can include requirements analysis, software design, software development, and unit testing.

Alpha: The alpha phase of the release life cycle is the first phase of software testing. Can be described as an early version (typically unstable) of a program or application.

Beta: A Beta phase generally begins when the software is feature complete but likely to contain a number of known or unknown bugs. It further has few stages like Perpetual beta, Open and closed beta etc.

Release candidate: A release candidate (RC), also known as “going silver”, is a beta version with potential to be a stable product, which is ready to release unless significant bugs emerge.

Stable release: Also called production release, the stable release is the last release candidate (RC) which has passed all verifications / tests.

Major Highlights from v1.20

A heads up towards Docker Deprecation

Dockershim, the container runtime interface (CRI) shim for Docker is being deprecated. Support for Docker is deprecated and will be removed in a future release (planned for version 1.22 next year).

It doesn’t affect the Kubernetes environments running on different cloud platforms such as EKS on AWS, AKS on Azure, RedHat Open shift, and so on as they have already moved to default to other container runtimes such as containerd and CRI-O, respectively.

Please note that the Docker-produced images will continue to work in your clusters with all CRI compliant runtimes as Docker images follow the Open Container Initiative (OCI) image specification.

For more details on this go through my article- Kubernetes deprecated docker! or Kubernetes community Blog.

Exec Probe Timeout Handling

A longstanding bug regarding exec probe timeouts that may impact existing pod definitions has been fixed. Prior to this fix, the field timeoutSeconds was not respected for exec probes. Instead, probes would run indefinitely, even past their configured deadline, until a result was returned. With this change, the default value of 1 second will be applied if a value is not specified and existing pod definitions may no longer be sufficient if a probe takes longer than one second.

If you just want to continue with previous behavior set the newly added feature gateExecProbeTimeout to false.

More details can be found here.

Volume Snapshot Operations are now stable

This feature provides a standard way to trigger volume snapshot operations and allows users to incorporate snapshot operations in a portable manner on any Kubernetes environment and supported storage providers.

Kubectl Debug Graduates to Beta

From now on you can use kubectl debug command for common debugging.
You should now use kubectl debug instead of kubectl alpha debug`

For more information on this go here.

GA: Process PID Limiting for Stability

This feature now adds support for configuring the kubelet to limit the number of PIDs a pod can utilize. This limits their potential impact on other pods on a node.

For more details go here.

Alpha: Graceful node shutdown

Currently, when a node shuts down, pods do not follow the expected pod termination lifecycle and are not terminated gracefully which can cause issues for some workloads. The GracefulNodeShutdown feature is now in Alpha. GracefulNodeShutdown makes the kubelet aware of node system shutdowns, enabling graceful termination of pods during a system shutdown.

Alpha with updates: IPV4/IPV6

This allows both IPv4 and IPv6 service cluster IP addresses to be assigned to a single service and also enables a service to be transitioned from single to dual IP stack and vice versa.

Beta: API Priority and Fairness

Kubernetes 1.20 now enables API Priority and Fairness (APF) by default. This allows kube-apiserver to categorize incoming requests by priority levels.

CronJobs (previously ScheduledJobs)

CronJobs (previously ScheduledJobs) are meant for performing all time-related actions, namely backups, report generation, and the like. Each of these tasks should be allowed to run repeatedly (once a day/month, etc.) or once at a given point in time.

To try this feature out you will need to enable the CronJobControllerV2 feature flag.

How to upgrade your Kubernetes cluster to v1.20?

Now let’s start the demonstration of upgrading your Kubernetes cluster from 1.19.x version to 1.20.x.

Prerequisites

A working Kubernetes cluster with at least one master and one worker node.

My Environment

Kubernetes Master Node ->
172.42.42.200 kmaster-rj.example.com/kmaster-rj, Ubuntu 18.04 LTS

Kubernetes Worker Nodes ->
172.42.42.201 kworker-rj1.example.com/kworker-rj1, Ubuntu 18.04 LTS
172.42.42.202 kworker-rj2.example.com/kworker-rj2, Ubuntu 18.04 LTS

Check the newest version available (On Master/Control plane node)

Update the package cache first.

root@kmaster-rj:~# apt update
Hit:2 http://ppa.launchpad.net/bashtop-monitor/bashtop/ubuntu bionic InRelease
Hit:3 http://security.ubuntu.com/ubuntu bionic-security InRelease
Hit:4 http://archive.ubuntu.com/ubuntu bionic InRelease
Hit:5 http://archive.ubuntu.com/ubuntu bionic-updates InRelease
Hit:1 https://packages.cloud.google.com/apt kubernetes-xenial InRelease
Hit:6 http://archive.ubuntu.com/ubuntu bionic-backports InRelease
Reading package lists... Done
Building dependency tree
Reading state information... Done
142 packages can be upgraded. Run 'apt list --upgradable' to see them.

You will find the latest version 1.20 in the list, it should look like 1.20.x-00.

root@kmaster-rj:~# apt-cache madison kubeadm
   kubeadm |  1.20.1-00 | http://apt.kubernetes.io kubernetes-xenial/main amd64 Packages
   kubeadm |  1.20.0-00 | http://apt.kubernetes.io kubernetes-xenial/main amd64 Packages
   kubeadm |  1.19.6-00 | http://apt.kubernetes.io kubernetes-xenial/main amd64 Packages
   kubeadm |  1.19.5-00 | http://apt.kubernetes.io kubernetes-xenial/main amd64 Packages
   kubeadm |  1.19.4-00 | http://apt.kubernetes.io kubernetes-xenial/main amd64 Packages
   kubeadm |  1.19.3-00 | http://apt.kubernetes.io kubernetes-xenial/main amd64 Packages
   kubeadm |  1.19.2-00 | http://apt.kubernetes.io kubernetes-xenial/main amd64 Packages
   kubeadm |  1.19.1-00 | http://apt.kubernetes.io kubernetes-xenial/main amd64 Packages
   kubeadm |  1.19.0-00 | http://apt.kubernetes.io kubernetes-xenial/main amd64 Packages

Upgrading control plane nodes

The upgrade procedure on control plane nodes should be executed one node at a time.

Step 1: upgrade kubeadm (On Master/Control plane node)

root@kmaster-rj:~# apt-get update && apt-get install -y --allow-change-held-packages kubeadm=1.20.1-00
Hit:2 http://archive.ubuntu.com/ubuntu bionic InRelease
Hit:3 http://ppa.launchpad.net/bashtop-monitor/bashtop/ubuntu bionic InRelease
Hit:4 http://archive.ubuntu.com/ubuntu bionic-updates InRelease
Hit:5 http://security.ubuntu.com/ubuntu bionic-security InRelease
Hit:6 http://archive.ubuntu.com/ubuntu bionic-backports InRelease
Hit:1 https://packages.cloud.google.com/apt kubernetes-xenial InRelease
Reading package lists... Done
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following held packages will be changed:
  kubeadm
The following packages will be upgraded:
  kubeadm
1 upgraded, 0 newly installed, 0 to remove and 141 not upgraded.
Need to get 7,708 kB of archives.
After this operation, 160 kB of additional disk space will be used.
Get:1 https://packages.cloud.google.com/apt kubernetes-xenial/main amd64 kubeadm amd64 1.20.1-00 [7,708 kB]
Fetched 7,708 kB in 1s (5,350 kB/s)
(Reading database ... 75793 files and directories currently installed.)
Preparing to unpack .../kubeadm_1.20.1-00_amd64.deb ...
Unpacking kubeadm (1.20.1-00) over (1.19.6-00) ...
Setting up kubeadm (1.20.1-00) ...

Step 2: Verify the kubeadm version (On Master/Control plane node)

root@kmaster-rj:~# kubeadm version
kubeadm version: &version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.1", GitCommit:"c4d752765b3bbac2237bf87cf0b1c2e307844666", GitTreeState:"clean", BuildDate:"2020-12-18T12:07:13Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"linux/amd64"}

Step 3: Verify the upgrade plan (On Master/Control plane node)

root@kmaster-rj:~# kubeadm upgrade plan
[upgrade/config] Making sure the configuration is correct:
[upgrade/config] Reading configuration from the cluster...
[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
[preflight] Running pre-flight checks.
[upgrade] Running cluster health checks
[upgrade] Fetching available versions to upgrade to
[upgrade/versions] Cluster version: v1.19.6
[upgrade/versions] kubeadm version: v1.20.1
[upgrade/versions] Latest stable version: v1.20.1
[upgrade/versions] Latest stable version: v1.20.1
[upgrade/versions] Latest version in the v1.19 series: v1.19.6
[upgrade/versions] Latest version in the v1.19 series: v1.19.6

Components that must be upgraded manually after you have upgraded the control plane with 'kubeadm upgrade apply':
COMPONENT   CURRENT       AVAILABLE
kubelet     3 x v1.19.6   v1.20.1

Upgrade to the latest stable version:

COMPONENT                 CURRENT    AVAILABLE
kube-apiserver            v1.19.6    v1.20.1
kube-controller-manager   v1.19.6    v1.20.1
kube-scheduler            v1.19.6    v1.20.1
kube-proxy                v1.19.6    v1.20.1
CoreDNS                   1.7.0      1.7.0
etcd                      3.4.13-0   3.4.13-0

You can now apply the upgrade by executing the following command:

kubeadm upgrade apply v1.20.1

_____________________________________________________________________

The table below shows the current state of component configs as understood by this version of kubeadm.
Configs that have a "yes" mark in the "MANUAL UPGRADE REQUIRED" column require manual config upgrade or
resetting to kubeadm defaults before a successful upgrade can be performed. The version to manually
upgrade to is denoted in the "PREFERRED VERSION" column.

API GROUP                 CURRENT VERSION   PREFERRED VERSION   MANUAL UPGRADE REQUIRED
kubeproxy.config.k8s.io   v1alpha1          v1alpha1            no
kubelet.config.k8s.io     v1beta1           v1beta1             no
____________________________________________________________________

Above command checks that your cluster can be upgraded, and fetches the versions you can upgrade to. It also shows a table with the component config version states.

Step 4: Choose a version to upgrade to (On Master/Control plane node)

root@kmaster-rj:~# kubeadm upgrade apply v1.20.1
[upgrade/config] Making sure the configuration is correct:
[upgrade/config] Reading configuration from the cluster...
[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
[preflight] Running pre-flight checks.
[upgrade] Running cluster health checks
[upgrade/version] You have chosen to change the cluster version to "v1.20.1"
[upgrade/versions] Cluster version: v1.19.6
[upgrade/versions] kubeadm version: v1.20.1
[upgrade/confirm] Are you sure you want to proceed with the upgrade? [y/N]: y
[upgrade/prepull] Pulling images required for setting up a Kubernetes cluster
[upgrade/prepull] This might take a minute or two, depending on the speed of your internet connection
[upgrade/prepull] You can also perform this action in beforehand using 'kubeadm config images pull'
[upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.20.1"...
Static pod: kube-apiserver-kmaster-rj hash: ca19d1a3c534805e8f47381caf3063f4
Static pod: kube-controller-manager-kmaster-rj hash: b5e37ec64802ad1ee865a41314ccd01f
Static pod: kube-scheduler-kmaster-rj hash: 092bf93ace9b8cbbba45a9126334ea19
[upgrade/etcd] Upgrading to TLS for etcd
Static pod: etcd-kmaster-rj hash: 4a2056f053f1ca1909b86404eb65cd11
[upgrade/staticpods] Preparing for "etcd" upgrade
[upgrade/staticpods] Renewing etcd-server certificate
[upgrade/staticpods] Renewing etcd-peer certificate
[upgrade/staticpods] Renewing etcd-healthcheck-client certificate
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/etcd.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2021-01-13-09-58-27/etcd.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
Static pod: etcd-kmaster-rj hash: 4a2056f053f1ca1909b86404eb65cd11
Static pod: etcd-kmaster-rj hash: 4a2056f053f1ca1909b86404eb65cd11
Static pod: etcd-kmaster-rj hash: 4a2056f053f1ca1909b86404eb65cd11
Static pod: etcd-kmaster-rj hash: 94417d36c0e48fdf5c03655da9543034
[apiclient] Found 1 Pods for label selector component=etcd
[upgrade/staticpods] Component "etcd" upgraded successfully!
[upgrade/etcd] Waiting for etcd to become available
[upgrade/staticpods] Writing new Static Pod manifests to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests629701940"
[upgrade/staticpods] Preparing for "kube-apiserver" upgrade
[upgrade/staticpods] Renewing apiserver certificate
[upgrade/staticpods] Renewing apiserver-kubelet-client certificate
[upgrade/staticpods] Renewing front-proxy-client certificate
[upgrade/staticpods] Renewing apiserver-etcd-client certificate
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-apiserver.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2021-01-13-09-58-27/kube-apiserver.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
Static pod: kube-apiserver-kmaster-rj hash: ca19d1a3c534805e8f47381caf3063f4
Static pod: kube-apiserver-kmaster-rj hash: e1eb6ececa489105263c8f38b2ad3d85
[apiclient] Found 1 Pods for label selector component=kube-apiserver
[upgrade/staticpods] Component "kube-apiserver" upgraded successfully!
[upgrade/staticpods] Preparing for "kube-controller-manager" upgrade
[upgrade/staticpods] Renewing controller-manager.conf certificate
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-controller-manager.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2021-01-13-09-58-27/kube-controller-manager.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
Static pod: kube-controller-manager-kmaster-rj hash: b5e37ec64802ad1ee865a41314ccd01f
Static pod: kube-controller-manager-kmaster-rj hash: 68d79396812e09a48466beaec532705f
[apiclient] Found 1 Pods for label selector component=kube-controller-manager
[upgrade/staticpods] Component "kube-controller-manager" upgraded successfully!
[upgrade/staticpods] Preparing for "kube-scheduler" upgrade
[upgrade/staticpods] Renewing scheduler.conf certificate
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-scheduler.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2021-01-13-09-58-27/kube-scheduler.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
Static pod: kube-scheduler-kmaster-rj hash: 092bf93ace9b8cbbba45a9126334ea19
Static pod: kube-scheduler-kmaster-rj hash: 9be8cb4627e7e5ad4c3f8acabd4b49b3
[apiclient] Found 1 Pods for label selector component=kube-scheduler
[upgrade/staticpods] Component "kube-scheduler" upgraded successfully!
[upgrade/postupgrade] Applying label node-role.kubernetes.io/control-plane='' to Nodes with label node-role.kubernetes.io/master='' (deprecated)
[upload-config] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config-1.20" in namespace kube-system with the configuration for the kubelets in the cluster
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to get nodes
[bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstrap-token] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstrap-token] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy

[upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.20.1". Enjoy!

To upgrade the other control plane nodes you need to follow the same steps we followed above.

Step 5: Drain the node (On Master/Control plane node)

Prepare the node for maintenance by marking it unable to schedule and evicting the workloads:

root@kmaster-rj:~# kubectl drain kmaster-rj --ignore-daemonsets
node/kmaster-rj cordoned
WARNING: ignoring DaemonSet-managed Pods: kube-system/calico-node-2vs9l, kube-system/kube-proxy-kmj6b
evicting pod kube-system/coredns-f9fd979d6-fr4fr
pod/coredns-f9fd979d6-fr4fr evicted
node/kmaster-rj evicted

Step 6: Upgrade kubelet and kubectl (On Master/Control plane node)

root@kmaster-rj:~# apt-get update && apt-get install -y --allow-change-held-packages kubelet=1.20.1-00 kubectl=1.20.1-00
Hit:2 http://ppa.launchpad.net/bashtop-monitor/bashtop/ubuntu bionic InRelease
Hit:3 http://archive.ubuntu.com/ubuntu bionic InRelease
Hit:4 http://archive.ubuntu.com/ubuntu bionic-updates InRelease
Hit:5 http://security.ubuntu.com/ubuntu bionic-security InRelease
Hit:6 http://archive.ubuntu.com/ubuntu bionic-backports InRelease
Hit:1 https://packages.cloud.google.com/apt kubernetes-xenial InRelease
Reading package lists... Done
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following held packages will be changed:
  kubectl kubelet
The following packages will be upgraded:
  kubectl kubelet
2 upgraded, 0 newly installed, 0 to remove and 139 not upgraded.
Need to get 26.8 MB of archives.
After this operation, 1,353 kB of additional disk space will be used.
Get:1 https://packages.cloud.google.com/apt kubernetes-xenial/main amd64 kubectl amd64 1.20.1-00 [7,948 kB]
Get:2 https://packages.cloud.google.com/apt kubernetes-xenial/main amd64 kubelet amd64 1.20.1-00 [18.9 MB]
Fetched 26.8 MB in 4s (6,837 kB/s)
(Reading database ... 75793 files and directories currently installed.)
Preparing to unpack .../kubectl_1.20.1-00_amd64.deb ...
Unpacking kubectl (1.20.1-00) over (1.19.6-00) ...
Preparing to unpack .../kubelet_1.20.1-00_amd64.deb ...
Unpacking kubelet (1.20.1-00) over (1.19.6-00) ...
Setting up kubelet (1.20.1-00) ...
Setting up kubectl (1.20.1-00) ...

Step 7: Restart the kubelet (On Master/Control plane node)

root@kmaster-rj:~# systemctl daemon-reload
root@kmaster-rj:~# systemctl restart kubelet

Step 8: Uncordon the node (On Master/Control plane node)

root@kmaster-rj:~# kubectl uncordon kmaster-rj
node/kmaster-rj uncordoned

Step 9: Verify the version (On Master/Control plane node)

root@kmaster-rj:~# kubectl get nodes
NAME          STATUS   ROLES                  AGE    VERSION
kmaster-rj    Ready    control-plane,master   163d   v1.20.1
kworker-rj1   Ready    <none>                 163d   v1.19.6
kworker-rj2   Ready    <none>                 163d   v1.19.6

Upgrade worker nodes

Step 1: Upgrade kubeadm: (On worker node)

root@kworker-rj2:~# apt-get update && \
> apt-get install -y --allow-change-held-packages kubeadm=1.20.1-00
Get:2 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB]
Hit:3 http://archive.ubuntu.com/ubuntu bionic InRelease
Hit:4 http://archive.ubuntu.com/ubuntu bionic-updates InRelease
Hit:5 http://archive.ubuntu.com/ubuntu bionic-backports InRelease
Hit:1 https://packages.cloud.google.com/apt kubernetes-xenial InRelease
Fetched 88.7 kB in 1s (114 kB/s)
Reading package lists... Done
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be upgraded:
  kubeadm
1 upgraded, 0 newly installed, 0 to remove and 140 not upgraded.
Need to get 7,708 kB of archives.
After this operation, 602 kB disk space will be freed.
Get:1 https://packages.cloud.google.com/apt kubernetes-xenial/main amd64 kubeadm amd64 1.20.1-00 [7,708 kB]
Fetched 7,708 kB in 2s (4,422 kB/s)
(Reading database ... 74981 files and directories currently installed.)
Preparing to unpack .../kubeadm_1.20.1-00_amd64.deb ...
Unpacking kubeadm (1.20.1-00) over (1.18.8-00) ...
Setting up kubeadm (1.20.1-00) ...

Step 2: upgrades the local kubelet configuration (On worker node)

root@kworker-rj2:~# kubeadm upgrade node
[upgrade] Reading configuration from the cluster...
[upgrade] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
[preflight] Running pre-flight checks
[preflight] Skipping prepull. Not a control plane node.
[upgrade] Skipping phase. Not a control plane node.
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[upgrade] The configuration for this node was successfully updated!
[upgrade] Now you should go ahead and upgrade the kubelet package using your package manager.

Step 3: Drain the node (On Master/Control plane node)

root@kmaster-rj:~# kubectl drain kworker-rj2  --ignore-daemonsets
node/kworker-rj2 cordoned

Step 4: Upgrade kubelet and kubectl (On worker node)

root@kworker-rj2:~# apt-get update && apt-get install -y --allow-change-held-packages kubelet=1.20.1-00 kubectl=1.20.1-00
Hit:2 http://archive.ubuntu.com/ubuntu bionic InRelease
Get:3 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB]
Hit:4 http://archive.ubuntu.com/ubuntu bionic-updates InRelease
Hit:1 https://packages.cloud.google.com/apt kubernetes-xenial InRelease
Hit:5 http://archive.ubuntu.com/ubuntu bionic-backports InRelease
Fetched 88.7 kB in 1s (125 kB/s)
Reading package lists... Done
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be upgraded:
  kubectl kubelet
2 upgraded, 0 newly installed, 0 to remove and 138 not upgraded.
Need to get 26.8 MB of archives.
After this operation, 1,353 kB of additional disk space will be used.
Get:1 https://packages.cloud.google.com/apt kubernetes-xenial/main amd64 kubectl amd64 1.20.1-00 [7,948 kB]
Get:2 https://packages.cloud.google.com/apt kubernetes-xenial/main amd64 kubelet amd64 1.20.1-00 [18.9 MB]
Fetched 26.8 MB in 4s (6,575 kB/s)
(Reading database ... 74981 files and directories currently installed.)
Preparing to unpack .../kubectl_1.20.1-00_amd64.deb ...
Unpacking kubectl (1.20.1-00) over (1.19.6-00) ...
Preparing to unpack .../kubelet_1.20.1-00_amd64.deb ...
Unpacking kubelet (1.20.1-00) over (1.19.6-00) ...
Setting up kubelet (1.20.1-00) ...
Setting up kubectl (1.20.1-00) ...

Step 5: Restart the kubelet (On worker node)

root@kworker-rj2:~# systemctl daemon-reload
root@kworker-rj2:~# systemctl restart kubelet

Step 6: Uncordon the node (On Master/Control plane node)

root@kmaster-rj:~# kubectl uncordon kworker-rj2
node/kworker-rj2 uncordoned

Step 7: Verify the status of the cluster (On Master/Control plane node)

After the kubelet is upgraded on all nodes verify that all nodes are available again by running the following command from anywhere kubectl can access the cluster:

root@kmaster-rj:~# kubectl get nodes
NAME          STATUS   ROLES                  AGE    VERSION
kmaster-rj    Ready    control-plane,master   163d   v1.20.1
kworker-rj1   Ready    <none>                 163d   v1.20.1
kworker-rj2   Ready    <none>                 163d   v1.20.1

Great! Our cluster has been upgraded to the newer version v1.20.1.

That’s all!

Hope you like the article. Please let me know your feedback in the response section.

👋 Join FAUN today and receive similar stories each week in your inbox! ️ Get your weekly dose of the must-read tech stories, news, and tutorials.

Follow us on Twitter 🐦 and Facebook 👥 and Instagram 📷 and join our Facebook and Linkedin Groups 💬

If this post was helpful, please click the clap 👏 button below a few times to show your support for the author! ⬇

What’s new in Kubernetes Version 1.20 and How to upgrade to 1.20.x? was originally published in FAUN.dev() 🐾 on Medium, where people are continuing the conversation by highlighting and responding to this story.