Sergiy Markin
d305f18450
Two separate rsyslog problems prevent maas-syslog.service from starting in MAAS region and rack controller containers on Noble hosts. Problem 1 — imklog/chown capability restrictions: rsyslogd fails because imklog requires CAP_SYSLOG to read /proc/kmsg and $FileOwner/$FileGroup require CAP_CHOWN. Noble host kernels enforce these restrictions more strictly than Jammy. Fixed by patching /etc/rsyslog.conf at image build time to comment out these directives. The same patch is applied in db-sync, which restarts rsyslog before running region DB migrations. Problem 2 — AppArmor blocks /var/lib/maas/rsyslog.conf: On Noble the rsyslogd AppArmor profile was renamed from /etc/apparmor.d/usr.sbin.rsyslogd to /etc/apparmor.d/rsyslogd. maas-common.postinst only checks the old path, so it never reloads the profile and the MAAS-specific rules in /etc/apparmor.d/rsyslog.d/maas (which allow rsyslogd to read /var/lib/maas/rsyslog.conf) are never loaded into the host kernel. Fixed by two complementary measures: - start.sh now loads the rsyslogd AppArmor profile via apparmor_parser before exec-ing systemd init. The container's SYS_ADMIN capability allows apparmor_parser to push the updated profile (including the MAAS rules) into the host kernel via the shared AppArmor securityfs. - values.yaml sets AppArmor to unconfined for maas-region and maas-rack pods via pod.mandatory_access_control, providing a belt-and-suspenders guarantee that rsyslogd is never blocked regardless of the host profile state. Also fixes a typo volueMounts -> volumeMounts in the maas-syslog sidecar container definition in statefulset-region.yaml (the sidecar is disabled by default but the typo would prevent volume mounts from applying if manifests.maas_syslog were enabled). Change-Id: Ieea22c3f75d9cd23844dc11e9a49f70a8ccb5a20 Signed-off-by: Sergiy Markin <smarkin@mirantis.com>
MaaS Helm Artifacts
This repository holds artifacts supporting the deployment of Canonical MaaS in a Kubernetes cluster.
Images
The MaaS install is made up of two required imags and one optional image. The Dockerfiles in this repo can be used to build all three. These images are intended to be deployed via a Kubernetes Helm chart.
MaaS Region Controller
The regiond Dockerfile builds a systemD-based Docker image to run the MaaS Region API server and metadata server.
MaaS Rack Controller
The rackd Dockerfile builds a systemD-based Docker image to run the MaaS Rack controller and dependent services (DHCPd, TFTPd, etc...). This image needs to be run in privileged host networking mode to function.
MaaS Image Cache
The cache image Dockerfile simply provides a point-in-time mirror of the maas.io image repository so that if you are deploying MaaS somewhere without network connectivity, you have a local copy of Ubuntu. Currently this only mirrors Ubuntu 18.04 Bionic and does not update the mirror after image creation.
Charts
Also provided is a Kubernetes Helm chart to deploy the MaaS pieces and integrates them. This chart depends on a previous deployment of Postgres. The recommended avenue for this is the Openstack Helm Postgres chart but any Postgres instance should work.
Overrides
Chart overrides are likely required to deploy MaaS into your environment
- values.labels.rack.node_selector_key - This is the Kubernetes label key for selecting nodes to deploy the rack controller
- values.labels.rack.node_selector_value - This is the Kubernetges label value for selecting nodes to deploy the rack controller
- values.labels.region.node_selector_key - this is the Kubernetes label key for selecting nodes to deploy the region controller
- values.labels.region.node_selector_value - This is the Kubernetes label value for selecting nodes to deploy the region controller
- values.conf.cache.enabled - Boolean on whether to use the repo cache image in the deployment
- values.conf.maas.url.maas_url - The URL rack controllers and nodes should use for accessing the region API (e.g. http://10.10.10.10:8080/MAAS)
Deployment Flow
During deployment, the chart executes the below steps:
- Initializes the Postgres DB for MaaS
- Starts a Pod with the region controller and optionally the image cache sidecar container
- Once the region controller is running, deploy a Pod with the rack controller and join it to the region controller.
- Initialize the configuration of MaaS and start the image sync
- Export an API key into a Kubernetes secret so other Pods can access the API if needed