Desculpa pela mega demora, Bruno e obrigado pelo comentário. É maneiro saber que veio de lá :)
Primeira coisa que eu recomendaria fazer é não utilizar a versão 2.5 ou superior do Rancher uma vez que ela teve algumas modificações; caso já esteja em uma versão anterior, eu recomendaria olhar as opções de quando criar um novo cluster -- aquela parte que gera um 'docker run' gigantesco --, nesta tela tem três opções de valores e caso você esteja rodando o sistema em um ambiente único, seja ele virutalizado ou não, você terá que selecionar as três opções: control plane, etcd e service worker.
O que acontece é que isso é um pouco mais de Kubernetes (K8s) em si do do que do Rancher por si só. As três opções citadas são o "core" para o funcionamento de um cluster; elas ficam responsáveis pelas as tarefas dele e a organização do mesmo. Você pode ver isso da seguinte maneira: uma cozinha de um boteco tem os mesmos principios de uma cozinha de um restaurante chique, ambas elas tem que ter alguém que limpe a cozinha, selecione os ingredientes e pré-prepare eles e outro que cozinhe eles mesmo; a diferença é que em uma cozinha de restaurante geralmente você tem pelo menos mais de uma pessoa para cada tarefa, enquanto na do boteco uma pessoa geralmente faz tudo.
Essa abordagem ajuda bastante para casos de alta performance e escalamento de tarefas muito pontuais ou até mesmo que a demanda são altas como, por exemplo, um dia de Black Friday em um e-comerce a empresa que roda todo o sistema dela pode precisar de um "nó" -- as unidades de um cluster, que seriam as pessoas neste exemplo da cozinha -- de armazenamento de dados maior, que seria o etcd em um cluster.
No final de contas um cluster K8s é uma cozinha, é algo "único" mesmo que você tenha várias unidades de medida que formem ele.
No seu caso você vai ter que partir pra opção da cozinha de boteco, a sua Rasp vai fazer tudo para todos os seus "clientes" -- os serviços -- que vai rodar nela :)