Teaching Cluster Autoscaler to speak cloudscale.ch without forking the autoscaler or waiting for an upstream provider integration.

Introduction

What do you do when Kubernetes Cluster Autoscaler supports the scaling logic you need, but not the cloud provider you run on?

That was the problem behind this experiment. I wanted Cluster Autoscaler to work on cloudscale.ch. There was no upstream provider for it, and I did not want to fork the autoscaler or carry an in-tree provider forever.

The answer was externalgrpc: a cloud provider integration mode that lets Cluster Autoscaler keep its core decision logic while delegating cloud-specific actions to a separate gRPC service.

This post walks through how Cluster Autoscaler makes scaling decisions, what the provider contract looks like, how externalgrpc fits into the architecture, and the practical gotchas I ran into while building an autoscaler provider for cloudscale.ch.

The autoscaler knows when, not how

The first important mental model is this:

Cluster Autoscaler knows when the cluster should scale, but it does not inherently know how to create or delete machines.

The core autoscaler logic decides things like:

• Are there pending Pods that cannot be scheduled anywhere?
• Would those Pods fit on a node from a configured node group?
• Has a node been idle long enough that its Pods could be moved elsewhere?
• Which node group should be increased or decreased?

What it does not know is how to create a VM, which image to use, how to pass bootstrap data, how the node joins the cluster, or how to delete the machine again.

That part is delegated to a cloud provider plugin.

For large providers, there are already in-tree implementations. But if your provider is not on the list, you need another strategy.

What happens every 10 seconds

By default, Cluster Autoscaler runs a reconciliation loop roughly every 10 seconds. In each loop, it asks a set of questions:

1. Are there unschedulable Pods?
2. Would those Pods fit on a node from a configured node group?
3. If yes, call NodeGroupIncreaseSize(group, delta).
4. Are there nodes that have been idle for long enough?
5. Can their Pods be rescheduled elsewhere?
6. If yes, call NodeGroupDeleteNodes(group, nodes).

The provider does not make these decisions. The provider only receives the result of the decision, for example: “increase this node group by three nodes.”

That separation is useful. It means a provider implementation can stay relatively small. The hard Kubernetes scheduling logic remains in Cluster Autoscaler.

The simulator is the scheduler

Cluster Autoscaler does not reimplement Kubernetes scheduling from scratch. It imports the Kubernetes scheduler framework and uses the same kinds of filter logic the scheduler uses.

That includes scheduling constraints such as:

• node resource fit
• node affinity
• taints and tolerations
• topology spread constraints
• inter-pod affinity
• volume binding
• node ports
• volume limits

The autoscaler runs these checks against an in-memory snapshot of the cluster. For scale-down, it can simulate removing candidate nodes and see whether their Pods would fit elsewhere. For scale-up, it can simulate whether pending Pods would fit on a hypothetical node from a node group.

That is where one of the most important provider methods comes in: NodeGroupTemplateNodeInfo.

Node groups, flavours, and choosing what to scale

If the cloud provider supports multiple VM types, sizes, or flavours, the provider usually exposes those as separate node groups. For example, one node group might represent small general-purpose workers, another might represent larger memory-optimized workers, and another might represent nodes with different labels or taints.

Cluster Autoscaler then runs the simulation against the configured node groups. If more than one group could fit the pending Pods, the configured expander decides which group wins. Depending on configuration, that can be random, most-pods, least-waste, price, priority, or another supported strategy.

This gives you a useful amount of flexibility, but it is still not Karpenter. Cluster Autoscaler chooses from node groups that already exist as configured abstractions. Karpenter has a more dynamic provisioning model and can reason more directly about instance types, constraints, and provisioning choices.

So the mental model is:

• Cluster Autoscaler: choose between predefined node groups
• Karpenter: more dynamic node provisioning based on workload requirements and available instance types

For an externalgrpc provider, this means the provider should model each relevant cloudscale.ch flavour as a node group, return accurate template node information for each one, and let the autoscaler’s simulator and expander decide which group should grow.

Why externalgrpc?

If your cloud provider is not supported upstream, there are three realistic options:

Approach	What it means	Trade-off
Upstream in-tree provider	Add your provider to kubernetes/autoscaler	High review and maintenance burden, tied to upstream release cycles
Fork Cluster Autoscaler	Maintain your own autoscaler build	Maximum control, but you own the fork forever
externalgrpc	Run a standalone provider service over gRPC	Separate release cycle, language-agnostic, small provider surface

For cloudscale.ch, externalgrpc was the pragmatic option.

It avoids the need to become an upstream autoscaler maintainer. It avoids carrying a fork. And because the provider is just a gRPC service, it can be implemented in any language. In this case, I used Go.

At the time of writing, it also aligns well with where the autoscaler project appears to be heading. The ongoing SIG Autoscaling refactor proposal points toward splitting provider implementations out of the main autoscaler repository. In that future, providers would either consume the autoscaler core as a library or communicate out of process via externalgrpc.

For an independent provider implementation, that makes externalgrpc a good escape hatch.

Architecture

At a high level, the architecture looks like this:

Pending Pods
    |
    v
Cluster Autoscaler
    |
    | gRPC over mTLS
    v
autoscaler-cloudscale
    |
    | cloudscale.ch REST API
    v
cloudscale.ch VMs
    |
    v
VM boots, kubelet joins, CCM stamps providerID

The Cluster Autoscaler remains the brain. It watches the Kubernetes cluster, notices pending Pods, runs scheduling simulations, and decides whether a node group should grow or shrink.

The external provider is the hands. It receives requests from Cluster Autoscaler and performs cloud-specific actions:

• list cloudscale.ch servers
• create VMs
• tag VMs
• delete VMs
• map Kubernetes nodes back to cloudscale.ch servers

The provider also needs configuration for node groups, for example:

nodeGroups:
  - name: worker
    flavor: flex-8-2
    min: 1
    max: 5
    image: custom:talos-1.13.2
    userData: @talos
    tag: k8s-autoscaler-group

In my setup, the VM bootstrap is handled through Talos Linux machine configuration passed as user data. The VM boots, Talos configures the node, kubelet joins the cluster, and the cloud controller manager stamps the node with a provider ID.

That provider ID is critical. Without it, the autoscaler cannot reliably connect a Kubernetes Node back to the corresponding cloud VM. Scale-down depends on this mapping.

The provider contract: six important RPCs

The externalgrpc proto contains more methods, but the core provider behavior is built around a small set of RPCs:

RPC	Purpose
Refresh	Reconcile provider state with the cloud
NodeGroups	Return configured node groups
NodeGroupForNode	Map a Kubernetes node to a node group
NodeGroupTemplateNodeInfo	Describe what a new node would look like
NodeGroupIncreaseSize	Create new servers for a node group
NodeGroupDeleteNodes	Delete specific servers

The remaining methods are either bookkeeping or can be implemented as explicit Unimplemented stubs, as long as the service satisfies the proto contract.

The most important design decision is to make the cloud provider the source of truth. Do not trust only local state. VMs can be manually deleted, failed creates can leave partial state, and API calls can fail halfway through.

In practice, Refresh lists servers from the cloud provider API, filtered by tags, and rebuilds the provider’s internal view.

Conceptually:

servers, err := api.Servers.List(ctx, cloudscale.WithTagFilter(tags))
if err != nil {
    return err
}

byUUID := make(map[string]*cloudscale.Server, len(servers))
for i := range servers {
    byUUID[servers[i].UUID] = &servers[i]
}

cache.Store(byUUID)

Tags are what scope the provider to the right cluster and node group. In this implementation, group membership is represented with a tag such as:

k8s-autoscaler-group=<name>

TemplateNodeInfo: modelling future nodes

When scaling from zero, there may be no real worker node in the cluster. So how can Cluster Autoscaler know whether a pending Pod would fit on a node that does not exist yet?

The provider has to describe what a future node would look like.

NodeGroupTemplateNodeInfo returns a synthetic Kubernetes Node object. This object tells the autoscaler things like:

• CPU capacity
• memory capacity
• disk-related properties
• labels
• taints
• allocatable resources
• maximum Pod count
• special devices or constraints

This is where the provider has to “lie” to the autoscaler, but only in a very specific sense. The node is not real yet. It is a placeholder used for scheduling simulation.

As an analogy, this is conceptually similar to the idea of virtual nodes: an object that represents capacity that is not currently a normal worker node. This is only an analogy, not Virtual Kubelet and not a real virtual-node implementation. Cluster Autoscaler does not schedule Pods onto this synthetic node. It uses the template to answer the question: “If I created a node like this, would these pending Pods fit?”

In other words, the template node is not runtime capacity. It is simulated future capacity.

One easy mistake is to expose the raw VM flavor as the node capacity without accounting for kubelet reservations, system reservations, or eviction thresholds. A VM with 8 GiB of memory does not have 8 GiB of allocatable memory for workload Pods.

Another easy mistake is forgetting to set ResourcePods. If the template node says it can run zero Pods, the autoscaler will correctly conclude that no workload can ever fit there.

That bug is wonderfully frustrating: everything looks wired up, the autoscaler runs, but nothing scales.

Creating nodes: target size first, VM later

When Cluster Autoscaler decides to increase a node group, it calls NodeGroupIncreaseSize with a delta.

The provider then needs to:

1. Increase the target size in its own node group state.
2. Create the requested number of VMs.
3. Tag them correctly.
4. Pass the bootstrap configuration.
5. Wait for the nodes to appear in Kubernetes.
6. Let Refresh reconcile the actual cloud state again.

It is important to distinguish three different states: desired capacity, in-flight capacity, and joined Kubernetes nodes. A VM may be requested but not yet visible, booting but not yet joined, or joined but not yet Ready. During that period, Cluster Autoscaler must not repeatedly create more and more machines every 10 seconds.

Cluster Autoscaler also has guardrails for failed provisioning. If a node does not join within the configured provisioning duration, the autoscaler can treat that scale-up as failed and move on.

Bootstrapping with Talos

In this implementation, node bootstrap is intentionally kept outside the autoscaler’s core logic.

The node group config contains the Talos machine configuration as user data. When autoscaler-cloudscale creates a VM, it passes that user data to cloudscale.ch. Talos then handles the rest:

• boot the custom image
• apply machine configuration
• use the configured certificates and join tokens
• start kubelet
• join the Kubernetes cluster

This keeps the provider focused on VM lifecycle management rather than becoming a full cluster lifecycle engine.

The one hard requirement is that the cluster has a working cloud controller manager. It must stamp Kubernetes nodes with a provider ID, because that is the bridge between Kubernetes objects and cloudscale.ch servers.

No provider ID means no reliable scale-down.

Demo: scale from zero workers

The demo shows a Kubernetes cluster on cloudscale.ch starting with only a control plane node and no workers. Workload pressure is then applied to trigger the autoscaler and the external provider.

To generate that pressure, the demo deploys 50 replicas of the Kubernetes pause container with small CPU and memory requests – a deliberately boring Deployment that exists only to create scheduling demand.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: scale-demo
spec:
  replicas: 50
  selector:
    matchLabels:
      app: scale-demo
  template:
    metadata:
      labels:
        app: scale-demo
    spec:
      containers:
        - name: pause
          image: registry.k8s.io/pause:3.9
          resources:
            requests:
              cpu: 500m
              memory: 128Mi

The Pods could not be scheduled because there were no worker nodes. Cluster Autoscaler noticed the pending Pods, simulated whether they would fit on a node from the configured worker group, and called the external provider.

The provider created three cloudscale.ch VMs. They booted the Talos image, installed to disk, rebooted, joined the cluster, and eventually became Ready. At that point, Kubernetes could schedule some of the pending Pods onto the new workers.

The important part of the demo is not the exact terminal output. It is the separation of responsibilities:

• Kubernetes produced pending Pods.
• Cluster Autoscaler simulated future capacity using TemplateNodeInfo.
• The expander selected a configured node group.
• The externalgrpc provider created the cloudscale.ch VMs.
• Talos bootstrapped the nodes into the cluster.
• The CCM stamped provider IDs so the autoscaler could map Kubernetes nodes back to cloud VMs.

That makes the demo a useful validation of the whole architecture without turning the blogpost into a screen-recording transcript.

Gotchas

1. TemplateNodeInfo is easy to get subtly wrong

The autoscaler’s decision quality depends heavily on the synthetic node returned by NodeGroupTemplateNodeInfo.

If allocatable CPU or memory is too optimistic, the autoscaler may under-scale. If it is too pessimistic, it may over-scale. If ResourcePods is missing or zero, nothing will schedule at all.

This method feeds both scale-from-zero and the internal “upcoming node” logic. Treat it as part of the scheduling model, not as a cosmetic metadata method.

2. Tags are not optional

Tags are how the provider knows which cloud VMs belong to which cluster and node group.

Without consistent tags, Refresh cannot reliably reconcile state. Scale-down becomes dangerous because the provider cannot know which machine corresponds to which Kubernetes node.

3. The cloud is the source of truth

Local state is useful, but it is not authoritative.

Manual deletes, failed creates, partial outages, quota issues, and API timeouts all happen. Refresh should reconcile against the provider API every loop and rebuild the cache from reality.

4. Lock ordering matters

Provider implementations often keep shared caches plus per-node-group state. If multiple mutexes are involved, lock ordering needs to be consistent.

One subtle bug here was a potential deadlock between Refresh and target-size updates. The fix was to always acquire locks in the same order.

5. No CCM, no reliable scale-down

A cloud controller manager is not just a nice addition. It is what stamps the Kubernetes node with the providerID that lets the autoscaler map a Kubernetes Node to a cloud VM.

Scale-up can appear to work without a complete mapping. Scale-down will not be safe.

Takeaways

Writing a Cluster Autoscaler provider is less about reimplementing autoscaling and more about providing the missing cloud-specific glue.

Cluster Autoscaler already knows how to:

• detect pending Pods
• simulate scheduling
• account for DaemonSets
• apply backoff
• choose node groups
• avoid duplicate scale-ups
• decide when nodes can be removed

The provider needs to know how to:

• describe a future node accurately
• create VMs
• delete VMs
• tag resources
• reconcile cloud state
• map Kubernetes nodes back to cloud resources
• bootstrap machines into the cluster

With externalgrpc, that provider can live as a standalone binary with its own release cycle. For unsupported clouds, lab environments, private infrastructure providers, or sovereign cloud platforms, that is a very practical integration model.

In this case, the result was a small Go service that taught Cluster Autoscaler how to operate on cloudscale.ch without modifying the autoscaler itself.

The autoscaler remained the brain. The external provider became the hands.

That is the real value of externalgrpc. It is not the most glamorous integration point, but it is exactly the right abstraction when you want to keep autoscaling logic upstream and put cloud-specific lifecycle logic in your own hands.

If you’d like to dive deeper, check out the blog post on my personal blog, where I explore the topic in more detail.

Kubernetes is a powerful platform for deploying and managing containerized applications at scale, and it has become increasingly popular in Switzerland in recent years.

One way to approach it is outsourcing. This can be a strategic and cost-effective option for organizations that do not have the in-house DevOps expertise, know-how, or resources to manage their infrastructure and application operations efficiently.

Not every tech company is in the business of building platforms and operating Kubernetes clusters. Thus by partnering with an experienced partner, companies can tap into a wealth of knowledge and expertise to help them run their applications.

Some companies adopt Kubernetes and look to leverage its capabilities themselves. It’s essential to consider time, effort, and possible implications while utilizing the latest developments and continually adding value to the core business.

In all cases, it will be helpful to align with fundamentals. For this reason, I have compiled a quick guide to Kubernetes in 2023 and best practices in Switzerland.

1. Understand the basics: Before diving into Kubernetes, have a solid understanding of the reasoning and concepts. This could include cloud infrastructure, networking, containers, how they liaise with each other, and how they can be managed with Kubernetes.
2. Plan your deployment carefully: When deploying applications with Kubernetes, you must plan thoroughly and consider your workloads’ specific needs and requirements. This includes but is not limited to resource requirements, network connectivity, scalability, latency, and security considerations.
3. Use appropriate resource limits: One of the critical benefits of Kubernetes is its ability to manage resources dynamically based on the needs of your applications. To take advantage of this, try to set appropriate resource limits for your application. This will help ensure that your application has the resources they need to run effectively while preventing them from consuming too many resources and impacting other applications.
4. Monitor your application: It’s essential to monitor your applications and the underlying Kubernetes cluster to ensure they are running smoothly and to identify any issues that may arise. You want to analyze the alerts and react accordingly. You can use several tools and practices to monitor your applications, including log analysis, monitoring with tools like Prometheus and Grafana, and alerting systems.
5. Use appropriate networking configurations: Networking is critical to any Kubernetes deployment, and choosing the proper network configuration is substantial. What about load balancing, service discovery, and network segmentation?
6. Secure your application: Security is a top concern for many companies and organizations in Switzerland. You cannot proceed without ensuring that your Kubernetes deployment is secure. At this stage, your team is implementing network segmentation, using secure container runtime environments, and implementing advanced authentication and authorization systems.
7. Consider using a managed Kubernetes service: For companies without the resources or needing DevOps expertise to manage their clusters, managed Kubernetes services can be a business-saving solution. With managed services, you can get a production-ready cluster, i.e., a fully-managed Kubernetes environment, allowing teams and software engineers to focus on developing new features and deploying their applications rather than managing the underlying infrastructure.
8. Stay up-to-date with the latest developments: The Kubernetes ecosystem is constantly evolving, and it’s better to stay up-to-date with the latest developments and best practices. This may involve subscribing to newsletters like VSHN, VSHN.timer, or Digests, attending conferences and CNCF meetups, and following key players in the Kubernetes community.

By following best practices, IT leaders, stakeholders, and decision-makers can ensure that they use Kubernetes constructively and get the most out of the platform technology.

Update: here’s the Kubernetes distributions 2026 overview.

At VSHN and APPUiO.ch we rely on OpenShift as Kubernetes distribution. What a Kubernetes distribution is, why we use it and where the differences to ‘plain’ Kubernetes will be explained in this blog post.

What is Kubernetes?

The official description of Kubernetes is:

Kubernetes is a portable, extensible open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation.

The most important part of this description is the fact that Kubernetes is a platform and not a ready off-the-shelf product. This is an important piece of information for understanding this article.

What is a Kubernetes distribution?

To understand the differences between Kubernetes and OpenShift, first of all we have to clarify the term ‘Kubernetes distribution’: if Kubernetes is installed directly from the open source Kubernetes project, you ‘only’ get the core components (API server, controller manager, scheduler, Kubelet, kube-proxy). In order for Kubernetes to be really usable, you need a lot of other components like etcd, ingress controller, logging server, metrics collector (for example Prometheus), software defined network (SDN) and many more. This is very similar to Linux: the Linux kernel alone does not help much, you need a whole Linux distribution which provides a shell, package management, boot process and much more.

OpenShift is a Kubernetes distribution and makes Kubernetes a product

A ‘minimum viable Kubernetes distribution’ requires the following additional components and tools for productive operation:

• Installation and upgrade mechanism: for an automated installation of all involved components.
• SDN (software defined network): pods must be able to communicate with each other no matter where they are running. The SDN ensures that.
• Ingress controller: to allow user access to applications running on the cluster.
• Authentication: a central user and group database provides the authenticated and authorized access.
• Security: Kubernetes executes containers via Docker or CRI-O. The security on the host system must be ensured accordingly.
• Persistent storage: stateful applications such as databases require persistent storage.
• Monitoring: constant monitoring of all cluster components and applications.
• Backup: backup of cluster components and persistent data.

Optionally, further components are recommended:

• Central logging with graphics and searchability
• Application and cluster metrics including alerting

OpenShift as Kubernetes distribution

Essentially, OpenShift relies 100% on Kubernetes, but as a Kubernetes distribution, it comes with everything needed for a Kubernetes cluster. To name just the most important functions:

• Operations tools: an official and supported way via Ansible allows the entire lifecycle of OpenShift to be executed. This includes the automated installation, as well as upgrades to newer versions of OpenShift.
• Router: the OpenShift router (ingress controller) – based on HAProxy – ensures that access to applications within the cluster is made possible via HTTP(S).
• Multi-tenancy: multi-tenancy is built-in the core on OpenShift projects, RBAC and other concepts to allow the use of the platform by various stakeholders.
• Authentication: the most different authentication backends are supported, above all LDAP, Active Directory (AD) and others.
• Metrics: the bundled metrics component collects all available data (RAM, CPU, network) of the applications running on the cluster and visualizes them in the web console.
• Central logging: all lines logged by the application on stdout are automatically collected by the central logging component and are made available to the user via the web console.
• Security: the platform is designed for maximum security. For example, security measures in the kernel of Red Hat Enterprise Linux like SELinux ensure that the security of the containers is guaranteed. Further measures such as ‘security context constraints’ (SCC) and the prevention of root containers ensure further security.
• Builds and pipelines: directly in the cluster integrated build and pipeline capabilities enable a fully integrated CI / CD workflow.
• Web console: all operations on the cluster are visually displayed to the user of the platform in a web console and allow an easy and quick access to the use of Kubernetes.
• SDN: the included software defined networking provides connectivity between the pods running on the platform and for an adequate network security with network policies.
• Container registry: Docker / container images are stored in the bundled registry and used for deployment onto the worker nodes.

All these built-in functionalities can be added to any Kubernetes cluster, but only with a lot of effort. Comparable to building your own Linux distribution, as for example  Linux From Scratch demonstrates. Kubernetes has a similar guide called Kubernetes The Hard Way.

OpenShift as PaaS

The strength of Kubernetes lies in the container orchestration. In addition, OpenShift offers classic Platform-as-a-Service (PaaS) functionalities. One of these is the automatic building and deployment of application code directly from a Git repository. Nevertheless, as a user of the platform and thanks to its great flexibility, you always have the choice of whether you want to use the integrated build functions, or rather build outside the cluster. This can be chosen for each deployment, so both types can be used on one cluster.

OpenShift as upstream to Kubernetes

Many developments in Kubernetes originally came from OpenShift. The best example is RBAC (role based access control). This feature has been part of OpenShift since the first release and has been gradually integrated into Kubernetes. RBAC has been an integral part of Kubernetes since Kubernetes version 1.6. The OpenShift ‘Route’ or the ‘DeploymentConfiguration’ object also played a key role in the current objects ‘Ingress’ and ‘Deployment’ in Kubernetes.
Since OpenShift is 100% based on Kubernetes, all Kubernetes native workloads are also supported, such as the ‘Deployment’ or the ‘Ingress’ object.
If you look more closely at the contributor statistics, you’ll find that Red Hat is one of the top 3 contributor companies, so Red Hat is crucial in the development of Kubernetes. With the purchase of the company CoreOS, Red Hat has acquired formidable Kubernetes know-how. The merger of OpenShift and Tectonic will be the next milestone of the Kubernetes distribution OpenShift.

Alternatives to OpenShift

OpenShift is not the only Kubernetes distribution on the market. A quick comparison shows the differences:

• Cloud vendor Kubernetes: the big clouds offer their own Kubernetes distributions as a service. These are tailored to the respective cloud and are maintained by the providers. Installation on your own private cloud or on other public clouds is not possible.
  • Amazon Elastic Container Service for Kubernetes (Amazon EKS)
  • Google Kubernetes Engine
  • Azure Kubernetes Service (AKS)
  • IBM Cloud Kubernetes Service
  • Alibaba Cloud Container Service for Kubernetes
• Rancher: since version 2.0, Rancher focuses 100% on Kubernetes and offers a multi-cluster management function as a major strength. With Rancher, Kubernetes clusters in the cloud (for example, on Amazon or Google) can be managed centrally, as well as Kubernetes clusters with the ‘Rancher Kubernetes Engine’ on your own VMs. With the web interface, setting up a new cluster is very easy and application deployments using Helm are also directly available.
• Tectonic: this distribution lies great importance on cloud-native automation. Through Red Hat’s acquisition of CoreOS, Tectonic will be merged with OpenShift and many of its features will inserted into OpenShift.
• Canonical / Ubuntu Kubernetes: platform based on Ubuntu, which uses Juju as installation tool. In partnership with Google and Rancher, a hybrid cloud solution will be offered in the future.
• SUSE CaaS platform: a very new platform based on SUSE MicroOS. Salt is used to ensure configuration management. Under the following link you can participate in the beta program: SUSE CaaS Platform Beta.

Further Kubernetes distributions include:

• Kontena Pharos
• Cisco Container Platform
• And even more from the Kubernetes documentation: Picking the Right Solution

One very important aspect to consider is the cloud and / or vendor lock-in. Many of the Kubernetes distributions have their own characteristics, which may not be compatible with each other. Using the example of ‘cloud vendor’ distributions: these can only be used in the corresponding cloud. However, if you want to pursue a hybrid cloud approach, this is not possible due to the lock-in. In contrary, a self-installable distribution like OpenShift makes this option possible.
Pure open source distributions without manufacturer support are not recommended for productive environments, as this is of great advantage for a complex platform like Kubernetes.

APPUiO – Swiss Container Platform

The attentive reader may have noticed that there are some discrepancies between the ‘minimum viable Kubernetes distribution’ and OpenShift. This is exactly where APPUiO comes in: we refine OpenShift into a comprehensive, production-ready Kubernetes distribution by offering managed services. We automatically monitor and secure the cluster status, take care of regular updates, fix bugs, provide persistent storage and help with our know-how to make the most out of the platform.

More information about Kubernetes and OpenShift

At the Cloud Native Meetup on August 28, 2018 in Zurich, we also talked about Kubernetes distributions: you can find the slides on Speaker Deck. You can also find more about OpenShift, Docker and Kubernetes here. Another recommendable blog post on this topic by Tomasz Cholewa: 10 most important differences between OpenShift and Kubernetes (English, technical).

How can we help?

Through our experience in operating OpenShift clusters around the world, we offer managed OpenShift clusters on almost any public, private or on-premise cloud. Or are you interested in another Kubernetes distribution than OpenShift? We gladly help you with the evaluation, integration and operation and support with our many years of Kubernetes experience.
Contact us, follow us on Twitter or take a look on our services.
We are looking forward to your feedback!