A deployment based on this solution must be as close to a kubeadm-managed deployment as possible (though with some changes, e.g. non-root services). This should, over time, allow to actually integrate kubeadm and its ‘business-logic’ in the solution.
It should be possible to install the solution in a fully offline environment, starting from a set of ‘packages’ (format to be defined), which can be brought into the environment using e.g. a DVD image. It must be possible to validate the provenance and integrity of such image.
After deployment of a specific version of the solution in a specific configuration / environment, it shall be possible to re-run this deployment, which should cause no changes to the system(s) involved.
It must be possible to deploy the solution on a single server (without any expectations w.r.t. availability, of course).
Scale-Up from Single-Server Deployment¶
Given a single-server deployment, it must be possible to scale up to multiple nodes, including control plane as well as workload plane.
Installation == Upgrade¶
There shall be no difference between ‘installation’ of the solution vs. upgrading a deployment, from a logical point of view. Of course, where required, particular steps in the implementation may cause other actions to be performed, or specific steps to be skipped.
When upgrading an environment, this shall happen in ‘rolling’ fashion, always cordoning, draining, upgrading and uncordoning nodes.
Handle CentOS Kernel Memory Accounting¶
The solution must provide versions of runc and kubelet which are built to include the fixes for the kmem leak issues found on CentOS/RHEL systems.
Data stored by Kubernetes must be encrypted at-rest (TBD which kind of objects).
Nodes in the cluster can be properly labeled, e.g. including availability zone information.
For evaluation purposes, it should be possible to set up a cluster in a Vagrant environment, in a fully automated fashion.
All services, including those managed by kubelet, must run as a non-root user, if possible. This user must be provisioned as a system user/group. E.g., for the etcd service, despite being managed by kubelet using a static Pod manifest, a suitable etcd user and group should be created on the system, /var/lib/etcd (or similar) must be owned by this user/group, and the Pod manifest shall specify the etcd process must run as said UID/GID.
The solution may not require SELinux to be disabled or put in permissive mode.
It must, however, be possible to configure workload-plane nodes to be put in SELinux disabled or permissive mode, if applications running in the cluster can’t support SELinux.
All containers as deployed by the solution must be fully immutable, i.e. read-only, with EmptyDir volumes as temporary directories where required.
The solution must support CentOS 7.6.
The solution shall not depend on Docker to be available on the systems, and instead rely on either containerd or cri-o. TBD which one.
For ‘human’ authentication, the solution must integrate with external systems like Active Directory. This may be achieved using OIDC.
For environments in which an external directory service is not available, static users can be configured.
No Random Binaries¶
Any binary installed on a host system must be installed by a system package (e.g. RPM) through the system package manager (e.g. yum).
Tagged Generated Files¶
Any file generated during deployment (e.g. configuration files) which are not required to be part of a system package (i.e. they are installation-specific) should, if possible, contain a line (as a comment, a preamble, …) describing the file was generated by this project, including project version (TBD, given idempotency) and timestamp (TBD, given idempotency).
All container (OCI) images must be built from a well-known base image (e.g. upstream CentOS images), which shall be based on a digest and parametrized during build (which allows for easy upgrades of all images when required).
During build, only ‘system’ packages (e.g. RPM) can be installed in the container, using the system package manager (e.g. CentOS), to ensure the ability to validate provenance and integrity of all files part of said image.
All containers should be properly labeled (TODO), and define suitable PORT and ENTRYPOINT directives.
Zero-Trust Networking: Transport¶
All over-the-wire communication must be encrypted using TLS.
Zero-Trust Networking: Identity¶
All over-the-wire communication must be validated by checking server identity and, where sensible, validating client/peer identity.
Zero-Trust Networking: Certificate Scope¶
Certificates for different ‘realms’ must come from different CA chains, and can’t be shared across multiple hosts.
Zero-Trust Networking: Certificate TTL¶
All issued certificates must have a reasonably short time-to-live and, where required, be automatically rotated.
Zero-Trust Networking: Offline Root CAs¶
All root CAs must be kept offline, or be password-protected. For automatic certificate creation, intermediate CAs (online, short/medium-lived, without password protection) can be used. These need to be rotated on a regular basis.
Zero-Trust Networking: Host Firewall¶
The solution shall deploy a host firewall (e.g., using firewalld) and configure it accordingly (i.e., open service ports where applicable).
Furthermore, if possible, access to services including etcd and kubelet should be limited, e.g. to etcd peers or control-plane nodes in the case of kubelet.
Zero-Trust Networking: No Insecure Ports¶
Several Kubernetes services can be configured to expose an unauthenticated endpoint (sometimes for read-only purposes only). These should always be disabled.
Zero-Trust Networking: Overlay VPN (Optional)¶
Encryption and mutual identity validation across nodes for the CNI overlay, bringing over-the-wire encryption for workloads running inside Kubernetes without requiring a service mesh or per-application TLS or similar, if required.
Network addressing must, primarily, be based on DNS instead of IP addresses. As such, certificate SANs should not contain IP addresses.
Server Address Changes¶
When a server receives a different IP address after a reboot (but can still be discovered through an updated DNS entry), it must be possible to reconfigure the deployment accordingly, with as little impact as possible (i.e., requiring as little changes as possible). This related to the DNS section above.
For some services, e.g. keepalived configuration, IP addresses are mandatory, so these are permitted.
A deployment can specify subnet CIDRs for various purposes, e.g. control-plane, workload-plane, etcd, … A service part of a specific ‘plane’ must be bound to an address in said ‘plane’ only.
Availability of kube-apiserver¶
kube-apiserver must be highly-available, potentially using failover, and (optionally) made load-balanced. I.e., in a deployment we either run a service like keepalived (with VRRP and a VIP for HA, and IPVS for LB), or there’s a site-local HA/LB solution available which can be configured out-of-band.
E.g. for kube-apiserver, its /healthz endpoint can be used to validate liveness and readiness.
Provide LoadBalancer Services¶
The solution brings an optional controller for LoadBalancer services, e.g. MetalLB. This can be used to e.g. front the built-in Ingress controller.
In environments where an external load-balancer is available, this can be omitted and the external load-balancer can be integrated in the Kubernetes infrastructure (if supported), or configured out-of-band.
Network Configuration: MTU¶
Care shall be taken to set networking configuration, e.g. MTU sizes, properly across the cluster and the services relying on it (e.g. the CNI).
Network Configuration: IPIP¶
Unless required, ‘plain’ networking must be used instead of tunnels, i.e., when using Calico, IPIP should only be used in cross-subnet networking.
Network Configuration: BGP¶
In environments where routing configuration using BGP can be achieved, this should be feasible for MetalLB-managed services, as well as Calico routing, in turn removing the need for IPIP usage.
Similar to MetalK8s 1.x, the solution comes ‘batteries included’. Some aspects of this, including optional HA/LB for kube-apiserver and LoadBalancer Services using MetalLB have been discussed before.
Metrics and Alerting: Prometheus¶
The solution comes with prometheus-operator, including ServiceMonitor objects for provisioned services, using exporters where required.
Node Monitoring: node_exporter¶
The solution comes with node_exporter running on the hosts (or a DaemonSet, if the volume usage restriction can be fixed).
Node Monitoring: Platform¶
The solution integrates with specific platforms, e.g. it deploys an HPE iLO exporter to capture these metrics.
Node Monitoring: Dashboards¶
Dashboards for collected metrics must be deployed, ideally using some grafana-operator for extensibility sake.
The solution comes with log aggregation services, e.g. fluent-bit and fluentd. Either a storage system for said logs is deployed as part of the cluster (e.g. ElasticSearch with Kibana, Curator, Cerebro), or the aggregation system is configured to ingest into an environment-specific aggregation solution, e.g. Splunk.
To support fully-offline environments, this is required.
System Package Repository¶
Tracing Infrastructure (Optional)¶
The solution can deploy an OpenTracing-compatible aggregation and inspection service.
The solution ensures backups of core data (e.g. etcd) are made, at regular intervals as well as before a cluster upgrade. These can be stored on the cluster node(s), or on a remote storage system (e.g. NFS volume).