Host Internals

This section describes how the host internals function within the cluster. The following diagram shows how each node connects to the Platform9 Management Plane, and how communication is achieved between them. Each host machine (a node that is part of the cluster) has the following main components (Kubernetes components are discussed in the associated article)

• pf9-HostAgent: The Platform9 HostAgent handles the installation and upgrade of Nodelet itself (and with the associated p9-kube or Kubernetes version). The pf9-hostagent also acts as a supervisor for nodelet and other Platform9 services.
• pf9-Nodelet: Nodeletd, or Nodelet, is the main component that is responsible for bringing up a cluster on the host.
• pf9-kube: This is a collection of scripts that is used by Nodelet to perform cluster creation or cluster upgrades. It is an integral part of the nodelet. In future release, we anticipate those scripts to be incorporated in the nodeletd binary.
• pf9-comms: The comms service is the communication agent that helps establish an end to end secured connection with the DU. (see below for more details).

Secure Connection

Platform9 uses secure end-to-end communications between the DU and the hosts. Each host has specific pf9-comms components that are responsible for creating a secure connection to the DU. Pf9-comms only talks to the DU over the outbound HTTPS port (443). Each connection is mutually authenticated via TLS keys and certificates. In addition, the Host and the DU both have a common root certificate that the host software installs during the onboarding process (specifically during the hostagent and comms installation). This certificate stays resident but gets updated. This authentication scheme assists with a passwordless authentication system between the host and the DU, and is strong enough to be used over the public internet.

Pf9-comms also connects over NAT and proxies and does not need inbound access to make it possible to create a cluster. At the DU end, pf9-comms and haproxy maintain an end-to-end secure tunnel. Pf9-comms exposes specific ports on the localhost/loopback interface that the local processes can connect to (similar to the service meshes). Once pf9-comms makes a network connection on the local port, it also creates a corresponding network connection to the haproxy on the DDU. These connections use SSL with mutual TLS. In addition, each link may use a different SNI header to talk to other services running on the DU. Most services talk to NginX and connect to the REST APIs, but services like RabbitMQ are reached via a predetermined port on the comms.

The following example illustrates how a secure connection completes between a docker client and a registry running on the DU. Because pf9-comms exposes port "5001" on localhost, any client (like a docker client) can say:

docker pull localhost:5001/pause

when it connects and wants to fetch that docker image.

The docker client makes that connection to the pf9-comms that listens on localhost:5001. The pf9-comms will, in turn, create a secured link to haproxy on the DU and then create a tunnel over which the docker-registry traffic will traverse. This worry-free process enables individual services to use end-to-end security, essentially allowing pf9-comms and haproxy to become gatekeepers. Note the following diagram for an illustration of how this occurs.