iX 4/2018
S. 60
Review
Container-Management
Aufmacherbild

Rancher 2.0 integriert Kubernetes

Neuer Kurs

In Version 2.0 setzt Rancher stärker als zuvor auf Kubernetes. Die Software verwaltet unter anderem Container-Cluster in verschiedenen Clouds.

Zusammen mit dem Aufstieg von Docker tauchten Werkzeuge zum Orchestrieren von Container-Workloads auf: Kubernetes, Mesospheres DC/OS, Nomad und zuletzt Docker Swarm. Sie gerieten in Wettbewerb. Im vergangenen Jahr zeichnete sich schließlich klar ab: Kubernetes geht als Sieger hervor. Das sahen auch die Entwickler von Rancher Labs so. Sie kündigten im September 2017 an, mit der Release von Version 2.0 ebenfalls auf Kubernetes zu setzen. Dennoch überrascht es, dass sie sogar den kompletten Unterbau darauf ausrichten. Dafür stellen sie den eigenen Orchestrierer Cattle zurück. Gleich vorneweg eine gute Nachricht für die Nutzer von Version 1.6: Rancher stellt Funktionen für einen sauberen Übergang zu 2.0 bereit.

Bisher nutzte Rancher vor allem Docker Compose für seinen Dienst Catalog, über den Anwender Templates komplexer Anwendungen beziehen können. Das bleibt im Kern auch enthalten. Neu ist ein Transformator, der diese Templates in Kubernetes-Deployments umwandelt. Auch die bisher im Catalog hinterlegten vordefinierten Services sind in Rancher 2.0 übertragbar. Daher können Nutzer von 1.6 einfach eigene Stacks aus der alten in die neue Plattform umsiedeln. Bis zum Jahresende 2018 erhält das Unternehmen seinen Support für 1.6 aufrecht. Rancher 2.0 ist Open Source und bei GitHub verfügbar. Auf der Website steht ein Quick Start Guide (siehe ix.de/ix1804060) bereit, der bei der Installation in Docker-Containern hilft.

Neue Möglichkeiten

Auf dem Rancher-Server läuft als zentraler Dienst der API-Server, mit dem Nutzer über die Rancher-Tools kommunizieren. Dieser basiert auf dem Kubernetes-API-Server. Er benötigt eine etcd-Instanz. Kommandos leitet er weiter an den Cluster-Controller, der über Cluster-Agents die einzelnen Kubernetes-Installationen verwaltet. Direktzugriff auf diese kann über den Authentifizierungsproxy erfolgen (Abb. 1).
Rancher 2.0 erlaubt, Kubernetes-Cluster in der Cloud zu verwalten oder neue zu erstellen (Abb. 2).

Der eingebettete Kubernetes-Master erlaubt Setup und Betrieb von Kubernetes-Clustern. Das bringt Rancher einige Vorteile, die sich direkt in Form neuer Funktionen bemerkbar machen: Plug-ins für Infrastruktur wie Storage, Netzwerk und Load Balancer, feiner justierbare Role-based Access Control (RBAC) und geteilte Host-Umgebungen. Für letztere weist man Kubernetes-Namespaces bei verschiedenen Cloud-Providern Hosts zu, die so ein hybrides Cloud-Setup bilden. Über RBAC ist es dann möglich, Usern nur auf dedizierte Namespaces oder Server Zugriff zu geben. Neben RBAC führt Rancher Pod Security Policies als Security-Funktion ein. Außerdem lassen sich Ökosystemservices wie Istio, Linkerd, Prometheus oder Helm Charts leichter nutzen. Darüber hinaus sollen bald zentrales Logging und Monitoring sowie integrierte Continuous Integration / Continuous Delivery (CI/CD) kommen.

Zusätzlich präsentierten die Entwickler im November 2017 die Rancher Kubernetes Engine (RKE), einen automatischen Installer der Orchestrierungs-Engine. Die RKE ist in Rancher integriert und steht zusätzlich als eigenständiges Werkzeug im GitHub Repository bereit. Sie soll die Installation von Kubernetes vereinfachen – in der Cloud, auf Bare Metal und beliebigen virtualisierten Servern.

Bei RKE handelt es sich um ein Kommandozeilentool, das Kubernetes-Cluster automatisiert bei Cloud-Providern wie Google, Amazon Web Services (AWS), Azure oder Alibaba aufsetzt. Bisher gab es dafür verschiedene Installer wie Kops oder Kubespray, die allerdings meist nur eine Cloud ansprechen. Das war den Rancher-Entwicklern, insbesondere vor dem Hintergrund zunehmender Multi-Cloud-Szenarien, zu wenig. Mit RKE geben sie den Nutzern ein Tool an die Hand, das sich mit nahezu jedem Anbieter verwenden lässt. Die Möglichkeit, ganze Kubernetes-Cluster und nicht nur einzelne Hosts oder Pods einzurichten, wird vorerst ein Alleinstellungsmerkmal von Rancher 2.0 sein. Bisher gibt es keinen anderen Dienst mit einer solchen Funktion. Es wird aber voraussichtlich nur eine Frage der Zeit sein, bis andere Anbieter hier nachziehen.

Listing: cluster.yaml

---
auth:
  strategy: x509

network:
  plugin: flannel

ssh_key_path: /home/user/.ssh/id_rsa

nodes:
  - address: server1
    user: ubuntu
    role: [controlplane, etcd]
  - address: server2
    user: ubuntu
    role: [worker]

services:
  etcd:
    image: quay.io/coreos/etcd:latest
  kube-api:
    image: rancher/k8s:v1.8.3-rancher2
    service_cluster_ip_range: 10.233.0.0/18
    extra_args:
      v: 4
  kube-controller:
    image: rancher/k8s:v1.8.3-rancher2
    cluster_cidr: 10.233.64.0/18
    service_cluster_ip_range: 10.233.0.0/18
  scheduler:
    image: rancher/k8s:v1.8.3-rancher2
  kubelet:
    image: rancher/k8s:v1.8.3-rancher2
    cluster_domain: cluster.local
    cluster_dns_server: 10.233.0.3
    infra_container_image: gcr.io/google_ ⤦
 containers/pause-amd64:3.0
  kubeproxy:
    image: rancher/k8s:v1.8.3-rancher2

addons: |-
    ---
    apiVersion: v1
    kind: Pod
    metadata:
      name: my-nginx
      namespace: default
    spec:
      containers:
      - name: my-nginx
        image: nginx
        ports:
        - containerPort: 80

Ein Beispiel, wie RKE funktioniert, stellt Rancher Labs auf seiner Website zur Verfügung. Der Hauptteil der Cluster-Konfiguration besteht aus den drei Bereichen Nodes, Services und Add-ons. Nutzer nehmen alle Einstellungen in YAML-Dateien vor (siehe Listing).

Cluster über mehrere Clouds verteilen

Der Betrieb von Multi-Cloud-Setups ist in Rancher direkt vorgesehen (Abb. 3).

In Version 2.0 können Anwender auch wieder Federation verwenden. Sie sind damit in der Lage, mehrere Kubernetes-Cluster über ein Rancher-Setup zu steuern. Laufen diese bereits in unterschiedlichen Clouds, ist es leicht, sie über die API von Rancher zentral zu verwalten oder zu einem großen Cluster zusammenzuschließen.

Dank Kubernetes lässt sich zudem Vendor-Lock-in umgehen. Im Endeffekt sind es die in Kubernetes vorhandenen Plug-ins, die sich an Ressourcen wie Storage bedienen: etwa Amazon Elastic Block Store (EBS), Azure File Storage, CephFS oder GCE Persistent Disk. Auf diese Weise ist es möglich, je nach Cloud vorhandene Varianten via Code einzubinden. Dadurch sind Anwender wesentlich flexibler in der Wahl ihrer Cloud-Provider.

Über Node Drivers spricht Rancher verschiedene Cloud-Provider an – oder über die OpenStack- und VMware-Treiber lokale Infrastruktur (Abb. 4).

Über Rancher erfolgt das Andocken an bestehende oder der Aufbau neuer Cluster. Nutzer erhalten mehr Freiheit, etwa kostensensitive Strategien zu verfolgen: Ist die Infrastruktur bei einem Provider zu teuer, ist es einfach, einen Cluster bei einem anderen zu verwenden und die Ressourcen dorthin zu verlagern. Dahinter steckt die Funktion, eingebaute Docker Machine Driver zu nutzen. Diese wiederum sind in der Lage, bei jedem registrierten Provider (siehe Abbildung 4) virtuelle Maschinen (VM) als Rancher Agents zu starten. Dafür greifen die integrierten Docker Machine Driver auf die jeweilige API des Cloud-Providers oder der Cloud-Software zu. Dies funktioniert sowohl für Public Clouds von Amazon oder DigitalOcean als auch für Bare Metal, OpenStack oder VMware vSphere.

Rancher provisioniert die VM und stellt den Agent-Container bereit, der sich automatisch in das IPsec-Netzwerk integriert. Bisher funktioniert das unter anderem mit Googles Kubernetes Engine (GKE), Azure, Amazon EC2 und DigitalOcean. Auch vSphere und der vCloud Director von VMware, die oft in Private Clouds zum Einsatz kommen, sind nutzbar. Anwender können damit einen Rancher-Cluster über mehrere Clouds verteilen.