TrueCharts News

Deprecating Old Operators

Jul 3, 2023

As part of limiting our promise not to introduce breaking changes to the charts within our Enterprise train, we’ve ensured both the new and old way of dealing with “operators” were both supported.

Starting August 1, 2023, we will completely drop support for the old (pre-July installs only, internal not user controlled) way of handling operators.

After August 1, 2023, additional checks for operators will be enabled, preventing users from making the mistake of installing charts without the right operator from the operator train present. This means that charts will prevent themselves from being updated when you’re still using the old operators at that time.

If you have already installed the metallb, prometheus-operator, and cloudnative-pg operators then no further action is required.

Prerequisites

Add the operator train to TrueCharts [as outlined here](/

MetalLB

The MetalLB operator is only required for users of MetalLB, anyone who does not use or plan to use MetalLB can skip this section.

Uninstall current metallb from Enterprise train.
Run this in the system shell as root: k3s kubectl delete --grace-period 30 --v=4 -k https://github.com/truecharts/manifests/delete
Complete MetalLB installation as outlined here

Prometheus

The Prometheus operator is required for the use of app metrics. Its installation is recommended.

Run this in the system shell as root: k3s kubectl delete --grace-period 30 --v=4 -k https://github.com/truecharts/manifests/delete3
Install prometheus-operator from the operators train. (Deprecated 2025)

CNPG

The cloudnative-pg operator is required for any applications that utilize postgres. Its installation is recommended.

Follow the [CNPG Operator Migration Guide](/ to migrate to the new CNPG operator. Ensure you follow the guide carefully as data loss can occur with this migration if proper steps are not followed.

If you run into additional issues, please file a ticket with our dedicated support staff via the #support channel of our discord as normal.

New CloudNative-PG (CNPG) operator chart.

Jun 4, 2023

Kjeld Schouten

Ops and R&D Lead

After building our own MetalLB operator chart, we’ve also now finished the work on building our own CloudNative-PG Chart. As of today this chart will be a requirement for new users if they want to run applications featuring a postgresql database.

Updating to the new Cloudnative-PG helm chart for existing users

We want to point out though, that users should update the new CloudNative-PG Helm chart as soon as possible. To update an existing install with applications using postgresql databases to the new system, the following procedure can be used:

We want to explicitly highlight that this procedure will COMPLETELY DESTROY all your databases. It’s absolutely crucial to export your databases manually beforehand.

export all your databases manually, on SCALE using the [following guide](/ (do not rely on heavyscript backups for this!)
run this in a root shell: k3s kubectl delete --grace-period 30 --v=4 -k https://github.com/truecharts/manifests/delete2
install the new cloudnative-pg chart from the operators train
wait a few minutes
Hit edit and save without changes on all applications using postgresql databases.
wait a few minutes
Restore all your databases manually, on SCALE using the [following guide](/ (do not rely on heavyscript backups for this!)

If you run into additional issues, please file a ticket with our dedicated support staff via the #support channel of our discord as normal.

New MetalLB chart and our own operator charts.

Jun 1, 2023

Kjeld Schouten

Ops and R&D Lead

Introdocution: Our own Operator Charts

The last few months, we’ve experimented with injecting so-called “operators” into the cluster directly when using our charts. Manifests for things like: MetalLB, Cert-Manager and CNPG where always loaded. While this system guaranteed users where always running the latest operator versions, we’ve also encountered some downsides. Primarily:

Loading manifests from the web is a security issue
Loading manifests required a pre-install job, with full-cluster permissions. Which is also a security issue.
Mistakes in the manifests, directly affect all users regardless of version
It requires creating namespaces outside of the ix-something style, while not an issue that’s something somehow iX developers voiced annoyance with.
It lacks any configurability for users that need a customization
It prevents users from using these operators outside of the TrueCharts scope on non-scale systems

To fix all of these issues, we’ve had quite the challenge. First off we needed to figure out a way of preventing users from installing multiple instances of the same operator. But we also needed to ensure ourselves that users always had the correct operators installed for the charts they want to install.

We’ve by now designed an industry leading helm logic, that scans your cluster for references of installed operators and compares those to the required operators.

Besides this logic, we also need to write the Helm Charts ourselves. This is a lot of work, as operators are often notoriosly complex to write helm charts for. Luckily we’ve enough experienced Kubernetes developers that we’re certain to pull this off!

First chart: MetalLB

As a first example of our new logic, we’re super happy to introduce our first self-build operator helm chart: MetalLB. It will be completely self-contained within it’s own namespace, not load dynamic manifests from the web and doesn’t contain risky security practices.

Obviously this chart, in the operators train, has a naming conflict with the old metallb chart in the enterprise train, so the later has been renamed to metallb-config requiring a reinstall. We want to point out that only the new metallb-config chart is compatible with the new self-build metallb operator.

We are very happy to also announce that the metallb-config chart, is fully compatible with our old and new ways of installing/managing metallb. However, new installs of the old way of handling metallb (without the chart from the operators train), will be actively disabled from now on.

To use MetalLB on new installs, one needs to install both metallb and metallb-config, in that order.

Updating to the new MetalLB helm chart

We want to point out though, that users should update the new MetalLB Helm chart as soon as possible. To update a current install using MetalLB to the new system, the following procedure can be used:

remove the old metallb chart coming from the enterprise train
run this in a root shell: k3s kubectl delete --grace-period 30 --v=4 -k https://github.com/truecharts/manifests/delete
install the new metallb chart from the operators train
wait a few minutes
install or update metallb-config to the latest version
wait a few minutes
Hit edit on metallb-config and save without changes if you where already on the latest version or it isn’t working yet
wait a few minutes

If you run into additional issues, please file a ticket with our dedicated support staff via the #support channel of our discord as normal.

Traefik Changes

May 24, 2023

Kjeld Schouten

Ops and R&D Lead

BLUF: Traefik (Stable) is Deprecated. Users need to add the Enterprise channel and install Traefik. [See how to get started](/

The use of TrueNAS Scale Certificates is also deprecated and you must migrate to Clusterissuer. (note: Clusterissuer replaced Cert-Manager)

As some of you might’ve noticed, Traefik has been a bit outdated the last few weeks. The reason behind this, was a multitude of potentially breaking todo’s where left and we don’t want to bother users with continues manual intervention on breaking changes. By now we’ve fixed the remaining issues and will soon release a breaking-change release for traefik and a patch for all the charts.

In short we’ve ensured that we only use our signature “tc-system” namespace for storing configuration and middlewares for traefik. This ensures consistent behavior for users using ingressClasses and allowed us to, cleanly, fix the known bug where a port got appended to the TrueNAS SCALE “portal” button.

This also means that charts that do not get patches because they are not ported to new common, most notably: Nextcloud Will inherently not work anymore. Though, users would’ve been ill-advised using it at all currently… due to the big ongoing nextcloud rework.

Unrelated new issue

We also got the request from iX-systems staff a while ago to limit our use of non-ix-prefixed namespaces on kubernetes. While the other work to do so, requires a lot of work building our own operator helm-charts, these Traefik changes are the initial step to comply to those wishes. The “low hanging fruit”.

As we’re working hard on building separate operator helm-charts, instead of handling it in the background.This work leads to a unrelated temporary issue, which has been created on purpose: CNPG will currently only be installed on new systems, if one of our “enterprise” charts is being installed. More news about this will be released later.

For any help, please file a ticket with our dedicated support staff via the #support channel of our discord as normal.

Introducing: TrueCharts Stop-All

May 16, 2023

Kjeld Schouten

Ops and R&D Lead

Previously we’ve warned users against using the stop-button on TrueNAS SCALE. At the same time we also understand, that users expect platform uniformity between Helm and SCALE. That’s why we’re happy to announce our own solution stop our Charts: TrueCharts Stop-All!

About that stop button

First off, we would like to go into a bit more depth about the design issues of the TrueNAS SCALE “Stop” Button. We’ve hinted at it previously, but it’s always good to explain why we need to step in ourselves.

The idea with Kubernetes, is that one tool should be managing deployment of objects at a time. Often indicated by a managed-by annotation on said objects. With TrueNAS SCALE, the middleware, triggers a management tool called “Helm” to deploy objects. So far so good, a GUI isn’t magically able to trigger other software, after all.

However, with the stop button, iX decided to also start editing some of those objects themselves. Specifically “Deployments” and “StatefulSets”, setting them to 0 “replica’s” meaning “run nothing”. That sounds completely fine, however: In these cases “Helm” is the actual management tool for those objects, so everything a helm action is triggered, those modifications are instantly removed.

That’s where the problems start to become bigger and bigger, because helm actions are triggered more often than people realize. For example: A reboot also triggers helm, requiring the same “hacks” to put things “back to sleep” again.

iX also decided to not even include all default objects that are technically “running”, like: Daemonsets, Jobs and Cronjobs. Which leads to issues with breaking jobs or daemonsets/jobs locking access to PVC’s. There it becomes more complicated, as kubernetes does not only exists of those “default” objects. There are also “Custom Resources”, objects that are defined by other charts and there is also the ability of other management tools, like Operators, to add objects.

When making such changes through Helm, it would be relatively easy for Chart/App developers to mitigate this. However, iX decided not to and does not even expose the “stop” button state to the Chart/App developers, leaving us completely without tools to mitigate these design flaws.

In the end, that leave out how the stop button can get into a near endless state of limbo, if not all running objects are stopped correctly… Putting the cherry on top.

Looking for a better way forward

With that all concluded, we decided to look into “what needs to be done”, to get all our Charts to have “stop” button functionality back again. It’s clear that the stop button, even with little fixes, isn’t going to be a future proof design. It completely needs to be redesigned, including all it’s backend logic. Sadly enough, refactors of said scale (pun not even intended), are currently not the priority of iXsystems, so not something we can rely on for our users.

We concluded that the only way to do so reliably, is through Helm itself. We know which objects we have, how they need to be stopped and can do so reliably through Helm. Which means: Do it ourselves!

The solution: TrueCharts Stop-All

With the most recent updates, we’ve introduced a new option: TrueCharts Stop-All This option will cause all your running objects to slowly shut themselves down or, in the case of our postgresql backend (CNPG), “hibernate”.

It’s designed to feature support for all default kubernetes objects deployed using our common chart: Daemonsets, Deployments, StatefulSets, Jobs and Cronjobs. On top we can easily expand that to cover any operator based objects, like cnpg, that needs to be shut down as-well in the future!

How To Use Stop-All

On SCALE

On SCALE this is a little checkbox on editing the App. Check it and its done

NOTE: Do not forget to uncheck the “Stop-All” checkbox to start the App again.

Using Helm

On native Helm, the same functionality is also available: Simply set the following in your values.yaml file:

global:
  stopAll: true