How to: gridscale Kubernetes Cluster & PaaS verbinden

Datum: 27.04.2020

Verbindung PaaS und KubernetesWir haben vor kurzem unsere Managed-Kubernetes-Lösung veröffentlicht, die unseren Kunden ganz neue Möglichkeiten in der Orchestrierung von Container-Infrastrukturen eröffnet. Um die vollen Möglichkeiten von gridscale-Kubernetes auszuschöpfen ist eine Verbindung mit unseren PaaS sinnvoll. Wie du diese Verbindung effizient und einfach herstellst und welche Vorteile diese Vorgehensweise hat, zeigen wir dir im folgenden Beitrag.

Aber warum musst du, im vollautomatisierten gridscale-Universum, überhaupt händisch eine Verbindung herstellen. Dies hat mehrere Gründe: Zuerst ist es rein technisch so, dass unsere PaaS exklusiv über IPv6 kommunizieren, unsere Kubernetes-Lösung bisher nur über IPv4.

Zudem ist unser Kubernetes noch nicht Feature-Complete (keine Sorge wir arbeiten mit Hochdruck daran) und bis dahin brauchen wir eine Übergangslösung. Sobald dieser Workaround nicht mehr notwendig ist, werden wir dich natürlich sofort benachrichtigen.

Also Achtung! Diese Art der Verbindungserstellung ist nur so lange erforderlich bis wir die Verbindung der beiden Plattformen in unser Produkt integriert haben.

Herstellen einer Verbindung

Jetzt aber in die konkrete Umsetzung. Kleiner Tipp: Du brauchst eine Sidecar-VM! Zu diesem Zeitpunkt gehen wir davon aus, dass bereits ein GSK Cluster und ein PaaS-Service erstellt wurden.

Der Cluster enthält voreingestellt ein privates Netzwerk, der PaaS ist automatisch mit der default Security Zone verbunden. Die neu erstellte VM wird mit beiden Netzwerken verbunden und kann dann als Proxy zwischen beiden Netzwerken fungieren.

Dafür wird die Software HAProxy auf einer Ubuntu-VM installiert. Wenn ein Pod des Clusters auf einen PaaS-Service zugreifen möchte, wird die IP des Proxy als Verbindungs-IP genutzt, mit dem Standard-Port des gewünschten Services.

Erstellen der VM

Über das Public-Panel kann nun ganz einfach eine neue VM erstellt werden. Diese kann minimal konfiguriert werden, je nach Workload reichen ein CPU-Kern und 2GB RAM. Als Storage-Template wird Ubuntu 18.04 verwendet.

Ist die VM erstellt, kann ganz einfach per Drag and Drop eine Verbindung zu den beiden Netzwerken erstellt werden. Der Name des Cluster-Private-Network basiert auf dem Namen des Clusters. Es muss eine Verbindung zu den beiden Netzwerken

  • des privaten Netzwerkes des GSK Clusters und
  • der Security Zone erstellt werden.

Sind beide Netzwerke eingerichtet, kann die VM gestartet werden.

Konfiguration des Netzwerks innerhalb der VM

Im Public Panel kann die MAC-Adresse der einzelnen Interfaces ermittelt werden. So lassen sich die Interface-Namen den beiden Netzwerken zuordnen. Beispiel:


interconnect-vm ~ [255] # ip -c a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens16: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 06:5d:92:0a:c2:01 brd ff:ff:ff:ff:ff:ff
    inet 45.12.48.205/24 brd 45.12.48.255 scope global dynamic ens16
       valid_lft 2203sec preferred_lft 2203sec
    inet6 2a06:2380:2:1::6c/128 scope global dynamic noprefixroute
       valid_lft 2442sec preferred_lft 2442sec
    inet6 fe80::45d:92ff:fe0a:c201/64 scope link
       valid_lft forever preferred_lft forever
3: ens17: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 06:5d:92:0a:c2:02 brd ff:ff:ff:ff:ff:ff
    inet 10.244.31.1/19 brd 10.244.31.255 scope global ens17
       valid_lft forever preferred_lft forever
    inet6 fe80::45d:92ff:fe0a:c202/64 scope link
       valid_lft forever preferred_lft forever
4: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 06:5d:92:0a:c2:03 brd ff:ff:ff:ff:ff:ff
    inet6 fcfc::1:45d:92ff:fe0a:c203/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 86399sec preferred_lft 14399sec
    inet6 fe80::45d:92ff:fe0a:c203/64 scope link
       valid_lft forever preferred_lft forever
interconnect-vm ~ #

Hier gibt es neben lo noch das Interface ens16, welches mit dem Internet verbunden ist. ens17 und ens18 sind die die Verbindungen zum Cluster-Private-Network (IPv4 only) und der Security Zone (IPv6 only).

Die MAC-Adresse findet sich jeweils direkt hinter link/ether; Diese wird mit der Info im Public Panel abgeglichen, um zu ermitteln, welches Interface via IPv4 in das GSK Cluster Private Network gebracht wird. In diesem Beispiel ist es ens17. Im Anschluss ist klar, dass ens18 auf der PaaS-Seite für die Security Zone konfiguriert wird.

IPv4 einrichten

Die IPv4-Verbindung kann nun wie folgt eingerichtet werden. Wir konfigurieren zuerst die statische IP-Adresse für das Interface: 10.244.31.1/19. Dazu füllen wir die Datei /etc/netplan/99_config.yaml mit folgendem Inhalt:


network:
  version: 2
  renderer: networkd
  ethernets:
    ens17:
      addresses:
        - 10.244.31.1/19

Anschließend wird die Konfiguration mit netplan apply angewendet. Mit einem ping 10.244.0.1
stellen wir sicher, dass die Verbindung hergestellt ist.

IPv6 einrichten

IPv6 wird dank SLAAC automatisch für die Security Zone konfiguriert, sodass ein Ping gegen den PaaS-Service ohne Weiteres funktioniert. Die IP des Services entnehmen wir den Details des PaaS-Services.

Installation und Konfiguration von HAProxy

HAProxy wird mittels apt update && apt -y install haproxy installiert. Nach der Installation kopieren wir die Standardkonfiguration von HAProxy und ersetzen sie durch eine spezielle Version, die auf diesen Zweck angepasst ist:


cd /etc/haproxy/
mv haproxy.cfg haproxy.cfg.backup
cat >> /etc/haproxy/haproxy.cfg << CONFIGEND
global
    log /dev/log    local0
    log /dev/log    local1 notice
    user    haproxy
    group   haproxy
    daemon

listen ipv6redis
    bind    10.244.31.1:
    mode    tcp
    timeout connect     4000
    timeout client      180000
    timeout server      180000
    server  paasredis   :
CONFIGEND
systemctl restart haproxy

Das war es! Wenn nun ein Pod des GSK Clusters auf einen PaaS-Service (über die IP 10.244.31.1 des Proxy-Servers) zugreift, wird HAProxy diese Anfrage an den PaaS-Service weiterleiten und die Antwort zurück an den Pod schicken.

Wenn weitere Services verbunden werden sollen, kann einfach der listen-Block kopiert werden. Bspw. wird mit der folgenden Config…


cat >> /etc/haproxy/haproxy.cfg << CONFIGEND

listen ipv6pgsql
        bind    10.244.31.1:5432
        mode    tcp
        timeout connect         4000
        timeout client          180000
        timeout server          180000
        server  paaspgsql       :5432
CONFIGEND

… ein PostgreSQL-PaaS an den Cluster angebunden.

Fazit

Du hast nun eine funktionierende Verbindung zwischen unserem gridscale Kubernetes Cluster und einem PaaS hergestellt. Die hier im Beispiel gezeigte Systematik lässt sich natürlich nicht nur bei PostgreSQL anwenden, sondern auch bei allen anderen gridscale Services.

Aber nochmal zur Erinnerung: dieser Vorgang ist ein Workaround und nur solange notwendig bis unser Managed-Kubernetes Feature-Complete ist. Hierüber werden wir dich zeitnah informieren!

Zurück zur Übersicht