Tectonic Installer creates two types of nodes when deploying a Kubernetes cluster: worker nodes (which execute containers), and master nodes (which handle cluster management tasks, and include the API server).
In large scale clusters, worker nodes may hold containers running several different types of applications. The flexibility and ease of adding drivers to Red Hat Enterprise Linux allows Kubernetes worker components to be deployed with specialized workloads and hardware.
If you have not yet created a cluster, use Tectonic Installer to deploy on bare metal (or AWS). The Installer will use Container Linux for the master nodes, and you may configure additional Container Linux worker nodes.
Once the cluster is deployed, follow this guide to configure and join additional worker nodes running Red Hat Enterprise Linux.
Deployment of Tectonic workers atop Red Hat Enterprise Linux is modeled after the traditional methods of installing software on RHEL. It is expected that users will be familiar with the Red Hat package management system, RPM, as well as its common transport mechanism, YUM/DNF.
Installation may be performed using any standard Red Hat infrastructure deployment techniques, including Kickstart/Anaconda, or other orchestration/configuration management systems like Ansible. This guide describes manual execution.
While the installation of the Tectonic worker components is designed to fit within a traditional Red Hat focused environment, the execution of the binaries are intended to mirror that of CoreOS Container Linux. As such, a utility called
kubelet-wrapper will spin up a copy of
rkt. This containerized Kubernetes binary reads its configuration from a combination of configuration files managed by both the administrator and by CoreOS. CoreOS managed files are deployed either in RPM files or via Tectonic operators. When files are deployed via RPM, local overrides are possible (but discouraged). For files deployed via the Tectonic operators, the entire lifecycle is expected to be managed by the Tectonic platform.
Deploy a Tectonic worker atop Red Hat Enterprise Linux using the process outlined below.
Deploy RHEL. Any standard deployment technique may be used, including an optical disk installation, a netbooted installation, or an image based deployment (standard for VMWare and OpenStack). Use a minimal install for the base environment. For more information, see the Red Hat Enterprise Linux Install Documentation.
Once basic installation of a host is complete, ensure that the additional Red Hat Enterprise Linux repository
extras is included. Use
subscription-manager to include the repo:
$ sudo subscription-manager repos --enable=rhel-7-server-extras-rpms
subscription-manager is not in use, ensure that the correct URL for the mirror of extras that is to be used is placed in the corresponding file in
/etc/yum.repos.d and set to
tectonic-release RPM includes the repo definition for the Tectonic software as well as relevant signing keys. The GPG signing key fingerprint for CoreOS shipped RPMs is:
3681 363D B1AA 55E0 33A2 7699 CF86 6CFE 1643 1E6A
Download the RPM from the CoreOS
$ curl -LJO https://yum.prod.coreos.systems/repo/tectonic-rhel/7Server/x86_64/Packages/tectonic-release-7-3.el7.noarch.rpm
Verify the signature:
$ sudo rpm -qip tectonic-release-7-3.el7.noarch.rpm Name : tectonic-release Version : 7 Release : 3.el7 Architecture: noarch Install Date: (not installed) Group : System Environment/Base Size : 13720 License : ASL 2.0 Signature : RSA/SHA256, Tue Oct 3 23:50:28 2017, Key ID cf866cfe16431e6a Source RPM : tectonic-release-7-3.el7.src.rpm Build Date : Tue Oct 3 22:43:08 2017 Build Host : buildhost.tectonic.coreos.systems Relocations : (not relocatable) URL : https://coreos.com/tectonic Summary : Tectonic release files and repository configuration Description : Tectonic release files including the /etc/tectonic-version file, signing keys and RPM repository files.
Confirm that the signature on the RPM matches the last 16 characters of the fingerprint ID above.
After verifying the signature, install the
$ sudo yum localinstall tectonic-release-7-3.el7.noarch.rpm
By default, YUM commands will install the latest available worker package. If the Tectonic cluster is using an update channel other than preproduction, see the different update strategies for options to restrict worker packages to versions that match the rest of the cluster.
tectonic-release RPM is installed and worker versions are optionally configured, complete the installation of the
$ sudo yum install tectonic-worker
This will download the relevant dependencies and then prompt to validate the GPG key installed by the
The Tectonic installer generates a
kubeconfig file which is used by all Tectonic workers to authenticate to the API server. Because this file is identical on all hosts, it can be retrieved from an existing worker, a node in the control plane, or from the assets bundle created by the installer.
To use the
kubeconfig from the assets bundle, extract the bundle to disk and then change to the root directory of the extracted bundle. The file will be located at the path
generated/auth/kubeconfig. Copy the file to the worker and place it in the path
A cluster-wide DNS service will be deployed as part of the Tectonic system. To allow the kubelet to discover the location of other pods and services, inform the system of the DNS service address.
The DNS service address can be manually extracted from the file
terraform.tfstate located in the installer assets directory. It is located under the key
$ grep dns_service terraform.tfstate
Once this value has been retrieved it will be placed in the user managed file
/etc/sysconfig/tectonic-worker on the host in the field
The default CNI installation for Tectonic uses VXLAN for its communications with flannel, which requires communications between hosts on UDP port 4789. The Kubernetes API also communicates with hosts on TCP port 10250. To simplify the configuration of these options, either allow all communications between cluster members, or allow 4789/udp and 10250/tcp.
Use firewalld to allow all communication between cluster members, using "trusted" zones with relevant ethernet interfaces.
Specify your ethernet adapter's name. In this example it's
$ sudo systemctl start firewalld $ sudo firewall-cmd --zone=trusted --add-interface eth0 $ sudo firewall-cmd --set-default-zone=trusted $ sudo firewall-cmd --list-all
Or, allow 4789/udp and 10250/tcp.
$ sudo firewall-cmd --add-port 10250/tcp $ sudo firewall-cmd --add-port 10250/tcp --permanent $ sudo firewall-cmd --add-port 4789/udp $ sudo firewall-cmd --add-port 4789/udp --permanent
Note: These settings may not be all inclusive and will not represent relative node ports or other communications which may need to be performed. For more information consult the Kubernetes Networking documentation.
SELinux must be run in Permissive mode. Running in Enforcing mode will block permissions for worker nodes. Execute the following commands to enable Permissive mode:
Clock synchronization is important for Tectonic, as it relies heavily on TLS certificates for communication between components. Enable and configure the NTP service with your organization's time servers.
This process is the same as with all systemd hosts. The service as installed by the
tectonic-worker RPM is called
kubelet. It can be started with the command:
$ sudo systemctl start kubelet.service
It will take a number of minutes for the worker to retrieve the relevant assets from Quay.io, bootstrap, and join the cluster. Use
journalctl to monitor progress:
$ journalctl -u kubelet.service
Note: PolicyKit requires the user to be in a relevant group with access to the journal. By default, Red Hat provides the groups
systemd-journal for this purpose. The command may also be run as the root user.
To ensure the service starts on each boot run the command:
$ sudo systemctl enable kubelet.service
Once complete, use Tectonic Console to view the new worker nodes, and confirm that they're ready to start running your containers.