Skip to main content

Checks Required Before Starting Installation

Before starting installations, make sure to confirm from system administrators that the servers are on the same network and on the same Virtual Machine.
Before starting installations, make sure that the server’s hostname is not localhost.localdomain and that each one is unique (with hostname command). If it is, be sure to change it before starting operations.

(If Necessary) Changing Hostname

There should not be a hostname defined as 127.0.1.1 in the /etc/hosts file.There should not be an entry like "nameserver 127.0.1.1" in the /etc/resolv.conf file.
If a Proxy is required for internet access, the following codes should be executed.
Add the following codes to the files below:
When updating Ubuntu packages, it tries to pull from servers in Turkey location. However, there may be problems with tr.archive.ubuntu.com from time to time. In this case, the following change should be made.
Replace all addresses containing tr. with “Replace All”.Example:
  • Old: http://tr.archive.ubuntu.com/ubuntu
  • New: http://archive.ubuntu.com/ubuntu

1) Operating System Configurations (To be performed on all servers)

2) Kubernetes Installation

2.1) Container Installation (To be performed on all Kubernetes servers)

2.2) Kubernetes Installation (On Master and Worker servers)

Loading Kubernetes keys and repository addresses to the system:

2.2.1) Bash Auto-Completion (Optional, On any Kubernetes Master Server)

This operation can speed up writing Kubernetes commands:

2.2.2) Creating Kubernetes Master Server (On Kubernetes Master Servers)

To make Multi-Master Kubernetes, run the following command:
Use the hostname address of the Master server.
If you will not use 10.244.0.0/16 as the IP block (podCIDR value) that Kubernetes pods will receive, you need to edit the above command accordingly. To use Multi-Master structure, other nodes that will be Master should be connected with the following code
If the connection command is desired to be recreated, the output of the second of the following codes should be added to the first:
As a result, it should look like the following:
If the code is desired to be created manually, the following are used:
  • For XXX → kubeadm token list
  • For YYY → openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -hex | sed 's/^.* //'
  • For ZZZ → sudo kubeadm init phase upload-certs --upload-certs

2.2.3) Setting User Configuration of kubectl Command on Kubernetes Master Server (On Kubernetes Master Servers)

Definitions are made for the user who will run kubectl commands:

2.2.4) Install Kubernetes Network Plugin (On Kubernetes Master Servers)

We will use the Calico network plugin in this guide. You can choose other supported network plugins. Calico is a simple and easy way to configure a layer 3 network structure designed for Kubernetes.

2.2.5) If Master Server is Also Desired to be Used as Worker (Optional)

This is not a recommended method for production environments.
To add Worker task to Master:
To remove Worker task from Master:

2.2.6) Registering Kubernetes Worker Servers to Master (On Kubernetes Worker Servers)

A token information is needed to connect the Worker server to Master. This will be visible in writing on the master node during this installation phase. But if it is skipped or if you want to view it again, the following command can be used. On Master Node
On Node(s) that will be Worker

2.2.7) Installation Check (On any Kubernetes Master Server)

If the Node created in addition to Master is also visible when the following code is run from Master, the installation has been completed successfully. If it does not transition from NotReady status to Ready status after two minutes, the problem should be examined with the "kubectl describe node <NODE_NAME>" command.

2.3) DNS Test (Optional, On any Kubernetes Master Server)

For more information, please review the address at this link.