Kubernetes Inclusive Naming

The software industry has historically used words and terms which evoke unintended meanings that they weren’t intended to have to have. Canonical and the Charmed Kubernetes team are proud to be part of an industry-wide initiative which aims to remove problematic language from our code and docs.

Generally, inclusive language means using precise technical terms that do not leave out marginalised groups or carry needless emotional or historical baggage.

In practice, this means reviewing terms that’re commonly used in tech, and deciding whether it could be improved with less harmful, more welcoming, and ultimately clearer wording. It doesn’t mean that these words should be banned from our language entirely, or that they should never be used in any context. Rather, it’s simply admitting that these words are counterproductive for our goal and that we are all better off if we do things differently moving forward.

Canonical Kubernetes strives to improve the language used in its products to better reflect its components, relations, status messages, and source code repositories. We also realise that software is built on a trust that renaming some component doesn’t break existing working deployments. We will document all inclusive-naming changes, and take care to make non-breaking adjustments.

Kubernetes Control Plane charm

Ending with the charms release 1.23, Charmed Kubernetes is replacing the charm kubernetes-master with kubernetes-control-plane. This charm has always hosted applications such as the api-server, controller-manager, proxy, and scheduler. Aside from etcd, which is provided by a separate charm, these services are considered the central kubernetes control plane services and are better represented under this charm name.

See Upgrading for more details about how to switch to this charm.

Repository default branch names

Charmed Kubernetes charms have a legacy position of working from a default branch which doesn’t accurately reflect that it is the main branch of code. Many charms build also on charm layers and interfaces which are reusable source components for these charms. As a part of this progress, the project will transition the names of the default branches to main.

We appreciate your feedback on the documentation. You can edit this page or file a bug here.

See the guide to contributing or discuss these docs in our public Mattermost channel.