Nodelet

What is a Nodelet?

A nodelet is a software agent that is installed and run on each node as a component of the Platform9 Managed Kubernetes (PMK) stack within a cluster. The nodelet agent provides multiple functions on both the Primary/Master and the worker nodes. This includes the installation and configuration of multiple Kubernetes services including etcd, containerd, Docker, networking, webhooks, and various other components.

Nodelet Phases

Generate Certificates

Role: Master Worker

Generates prerequisites checks needed to install various certificates.

Prepare Kubeconfigs

Role: Master Worker

Customizes the kubeconfigs needed to start the Kubernetes cluster.

Docker Configure

Role: Master Worker

Installs and configures docker and containerd.

Docker Start

Role: Master Worker

Installs and verifies running docker containers.

Etcd Configure

Role: Master

Verifies, configures, and runs etcd on the primary host server's file system.

Etcd Run

Role: Master

Starts and confirms the etcd service is running on the container.

Network Configure

Role: Master

Ensures that the Classless Inter-Domain Routing (or CIDR) configuration for flannel is up-to-date (It does not target other network plugins like Calico, Canal, or Weave).

CNI Configure

Role: Master Worker

Configures the Container Network Interface (CNI).

Auth Webhook

Role: Master

Uses bouncer as a simple webhook endpoint server to validate/authenticate images created within the Kubernetes cluster (specifically, the admission controllers GenericAdmissionWebhook and the ValidatingAdmissionWebhook).

Misc Scripts

Role: Master Worker

Responsible for composing the cloud provider config on the file systems of all nodes.

Kubelet Configure/Start

Role: Master Worker

Starts and manages the proper configurations on Kubelets.

Kube Proxy Start

Role: Master Worker

Starts and configures the kube-proxy service.

Wait for K8s Services

Role: Master Worker

Starts and pauses various K8s services to ensure availability.

Label and Taint Node

Role: Master Worker

Designates “master” or “worker” nodes. Additionally, taints workloads not allowed on master.

Uncordon Node

Role: Master Worker

Marks nodes as schedulable using the kubectl uncordon node command.

Deploy App Catalog

Role: Master

Configures and deploys the Monocular and Tiller services.

Configure/Start Keepalived

Role: Master

Configures and starts the keepalived service.

Deploy Luigi Operator

Role: Master

Activates the Luigi operator

Deploy KubeVirt

Role: Master

Deploys the KubeVirt operator in addition to its other custom resources.

Enable PF9 Sentry

Role: Master

Initiates and configures the pf9-sentry service within the platform9-system namespace.

Enable PF9 Add-on Operator

Role: Master

Starts and configures the pf9-addon-operator service within the pf9-addons namespace.

Drain All Pods (Stop Only)

Role: Master Worker

If invoked, this task drains the node before implementing a stop function on other tasks. When the _pf9-kube_ service begins draining the node, it executes a priority stop function. This ensures the task is prioritized over the stop function of other tasks.

CLI

Advantages of Using the CLI

Because a CLI does not utilize a graphical user interface (or GUI), it is oftentimes overshadowed by the more user-friendly, visual-based interfaces that a mouse and keyboard affords. What is not apparent is that behind the GUI are many of the same commands which drive the functionality of a program. The strength of the CLI is speed, efficiency, and customization with decreased memory consumption. In addition, It allows for experienced users to create scripts to automate repetitive tasks as well as chain command together to achieve a greater level of customization and capabilities than when using a single mouse click.

Many new users express the steeper learning curve as the primary downside of using the CLI. Additionally, there is less room for error, and understanding the large number of command options available to utilize can be daunting. New users can be stymied when trying to remember a command, its syntax, and the available flags and options it affords. Some relief is granted via the use of quick reference guides that are widely available. Users will often find that the ongoing usage of the CLI will increase productivity over time.

Caution should be exercised when running commands as the root user. Running an errant or malformed command can cause severe issues and damage the system, up to and including needing a full system restore. The only time clients should run commands as a root user are when configuring the underlying file system.

Best practice dictates creating secondary user(s) with limited permission sets. Additionally, backup copies of files or folder should be made before editing any important system configuration files or folders.

The following section specifies the nodeletd phase related commands used to interact with the k8s stack via the CLI.

Nodelet CLI Syntax

Bash
Copy

Phases Help

The help flag defines the list of available options when running the nodelet phases command.

Bash
Copy

Phases List

This command lists the available phases by passing the list option.

Sample Output
Copy

Phases Stop

This command stops the pf9-kube stack.

Bash
Copy

Phases Start

This command starts the pf9-kube stack.

Bash
Copy

Phases Restart

This command restarts the pf9-kube stack.

Bash
Copy

Phases Status

The verbose flag provides information on the condition and state of the pf9-kube stack.

Sample Output
Copy

Note: CLI output will contain info about the various phases that run before the following table is displayed. This info is also contained in the /var/log/pf9/kube/kube.log file.

Node Health

The curl command below provides an overview of the health of the specific node. The $TOKEN refers to a temporary authentication token utilized to verify the service user, which removes the need for an interactive authentication method. The DU reference is in regard to the deployment unit that operates the platform9's server-side components. The $UUID is the universal unique identifier for an object in the cluster. A sample output of the command is shown below.

Bash
Copy
Sample Output
Copy

Note: The last_failed_status_check field is cleared 10 minutes after the status check is successful.

The pf9_kube_service_state tries to simulate the node state as reported by the hostAgent. The values this field can report on are as follows:

The following status states are described below.

StatusDescription
OKEverything is fine.
ConvergingStarting pf9-kube failed and this is the initial attempt to restart it.
RetryingStarting pf9-kube failed and Nodelet has tries less than 10 times to start pf9-kube.
FailedStarting pf9-kube failed and Nodelet has tried more than 10 times to start pf9-kube.
Type to search, ESC to discard
Type to search, ESC to discard
Type to search, ESC to discard
  Last updated