Meine letzten Worte 2020 waren: Der Kubernetes Cluster ist nicht das Ende der Fahnenstange. Wenn man an Hohverfügbarkeit oder Standortredundanz, brauch man am wenigsten 2 Kubernetes Cluster

Es war einmal, da hatten wir ein Problem mit einem Kubernetes Cluster. Es dauerte
einige Tage, das Problem zu lösen und die Benutzer erfuhren eine Diensteeinschränkung
für eine ungewöhnlich lange Zeit. Das war der Startpunkt, um über Cluster-Redundanz und
Service Mesh nachzudenken.

Ein Service Mesh beschreibt eine Funktionalität, um Dienste in verschiedenen Versionen oder
Lokationen zu mischen. Istio ist ein solcher Service Mesh, welchen wir untersuchen möchten,
um folgende Probleme zu lösen:

• Cluster-Redundanz (jeder Kubernetes Cluster arbeitet unabhängig voneinander und liefert
  cloud-native, businesskritische Applikationen)
• Standort-Redundanz (verteile nicht ein Cluster auf mehrere Standorte, jeder Standort hat
  seinen eigenen Cluster)
• Trafik-Verteilung (liefere eine Version der Applikation zu einem bestimmten Teil der Kunden,
  basierend auf eine Region oder dem Test-Team)

Hinweis: Es gibt bislang schon technische Lösungen, um diese Probleme mit Kubernetes Werkzeugen
und ohne Service Mesh zu lösen, da man sich eine Menge technische Abhängigkeiten einlädt.

Los gehts!

Vorbedingungen

• 2 Kubernetes Downstream Cluster (1.20.12-rancher1-1) verwaltet von Rancher
• Cluster Admin Zugriff auf Rancher
• Die Möglichkeit zur Erstellung von Externen Loadbalancern, z.B. OTC ELB mit [OpenStack Cloud Controller Manager](github.com/kubernetes/cloud-provider-openstack)

Die Cluster erfüllen voll den [CIS Benchmark Check](https://rancher.com/docs/rancher/v2.6/en/cis-scans/)

• `restricted` PodSecurityPolicy ist erzwungen
• ProjectNetworkIsolation ist aktiviert

Mehr Vorbedingungen

• Istio Images sind zur MTR gespiegelt. Verfügbare Versionen auf [https://mtr.external.otc.telekomcloud.com/repository/istio/](https://mtr.external.otc.telekomcloud.com/repository/istio)
• Download kubectl (wenn erforderlich) und kube-config von Rancher

Shell

curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl

• Download und installieren von istioctl:

Shell

$ curl -L https://istio.io/downloadIstio | sh -

Istio Installationsmethoden & Projektziele

• Installation durch Rancher App Katalog (Rancher Helm Chart)
• Installation durch Istio Helm Chart
• Installation durch Istio Operator

Wir werden den Istio Operator benutzen, um jeden Schritt der Installation von Istio Version
1.12.0 (ältere Versionen haben Probleme bei der Verbindung von Multi-Clustern)

Projektziel ist die Installation des [Istio Helloworld Beispiels](https://github.com/istio/istio/tree/master/samples/helloworld)
in beiden Clustern und verteilen der Traffic. Das Zielbild sieht so aus:

• Der HelloWorld Service in beiden Clustern
• Exposed Ingress Service
• Eastwest Gateway fuer interconnect Traffic

Cluster Vorbereitungen

Annahmen:

| No | Name                | ID         | Network         | Mesh       |
|----|---------------------|------------|-----------------|------------|
| 1  | mcsps-test-k8s-01   | c-f7r9g    | mcsps-test-01   | mcsps-test |
| 2  | mcsps-test-k8s-02   | c-pzk8b    | mcsps-test-02   | mcsps-test |

Erstelle ein Projekt `istio` fuer beide Cluster im Rancher Kontext:

Shell

Erstelle einen Namespace `istio-system` fuer beide Cluster im Cluster Kontext:

EOF | kubectl apply -f -
apiVersion: v1
kind: Namespace
metadata:
  annotations:
    field.cattle.io/projectId: c-pzk8b:istio
    field.cattle.io/resourceQuota: '{"limit":{"limitsCpu":"12000m","limitsMemory":"12000Mi"}}'
    lifecycle.cattle.io/create.namespace-auth: "true"
    scheduler.alpha.kubernetes.io/node-selector: role=ingress
  labels:
    field.cattle.io/projectId: istio
    topology.istio.io/network: mcsps-test-01
  name: istio-system
EOF

• Es gibt weiter die Annahme, dass wir Worker Nodes fuer Ingress mit Rolle `ingress` haben.
  Ansonsten kann man die Annotation loeschen.
• Die richtige cluster-id und network-id muss jederzeit sichergestellt werden.

Erstelle LimitRange in `istio-system` Namespace fuer Container Default Quota:

Shell

Erstelle einen Namespace `sample` in beiden Clustern in Cluster Kontext:

reate namespace sample
$ kubectl label namespace sample  istio-injection=enabled --overwrite

Istio Operator Installation

Shell

Dadurch wird der Istio Operator im Namespace `istio-operator` erstellt

Multi-Cluster Vorbereitungen

In der [Istio Documentation](https://istio.io/latest/docs/setup/install/multicluster/before-you-begin/) sind einige Aufgaben erwaehnt wie `Configure Trust`. Dafuer gibt es auch ein [Beispiel](https://github.com/istio/istio/tree/master/samples/certs)

Im sample/certs Verzeichnis:

Shell

Auf dem Cluster anwenden (mit Kontext cluster 01):

Shell

Auf dem Cluster anwenden (mit Kontext cluster 02):

Shell

Erstellte Secrets überprüfen

Shell

Erstellen eines Rancher Token mit Skope auf cluster1 und cluster2, erstellen einer kube-config
Datei wie in diesem Beispiel und kodieren mit `base64`

Shell

Erstellen eines Remote Secret mit bas64 mit diesen Credentials und dem Namen des
anderen Clusters,

EOF | kubectl -n istio-system apply -f -
apiVersion: v1
data:
  mcsps-test-k8s-01: YXBpVmVyc2lvbjogdjEKY2x1c3RlcnM6Ci0gY2x1c3RlcjoKICAgIHNlcnZlcjogaHR0cHM6Ly9yYXNlZWQtdGVzdC5leHRlcm5hbC5vdGMudGVsZWtvbWNsb3VkLmNvbS9rOHMvY2x1c3RlcnMvYy1mN3I5ZwogIG5hbWU6IG1jc3BzLXRlc3QtazhzLTAxCmNvbnRleHRzOgotIGNvbnRleHQ6CiAgICBjbHVzdGVyOiBtY3Nwcy10ZXN0LWs4cy0wMQogICAgdXNlcjogbWNzcHMtdGVzdC1rOHMtMDEKICBuYW1lOiBtY3Nwcy10ZXN0LWs4cy0wMQpjdXJyZW50LWNvbnRleHQ6IG1jc3BzLXRlc3QtazhzLTAxCmtpbmQ6IENvbmZpZwpwcmVmZXJlbmNlczoge30KdXNlcnM6Ci0gbmFtZTogbWNzcHMtdGVzdC1rOHMtMDEKICB1c2VyOgogICAgdG9rZW46IHRva2VuLWhmanZnOnRzam4yazV2bHZqanpxaHdwYnB6d2ZrYjU0OXE1NHBkeHJrc2ZuNmh3ODJzdmJxNXZjZ3JtbAo=
kind: Secret
metadata:
  annotations:
    networking.istio.io/cluster: mcsps-test-k8s-01
  labels:
    istio/multiCluster: "true"
  name: istio-remote-secret-mcsps-test-k8s-01
  namespace: istio-system
type: Opaque
EOF

Überprüfen des Remote Secret in jedem Cluster:

Shell

Hinweis: Es gibt noch einen anderen Weg, um die Remote Secret mit
Zertifikaten zu erstellen, aber es wird hier nur erwähnt:

Shell

Installation Istio Controlplane und Istio Ingressgateway

Jetzt werden wir den Istio Controllplane in jedem Cluster installieren:

Shell

Eastwestgateway

Installation Easwestgateway in jedem Cluster:

Shell

enste

Exponieren mTLS Service in jedem Cluster:

Shell

Controllplane und Gateways

Shell

Shell

Shell

Installation Helloworld

Hinweis: Die originalen Beispiele befinden sich im [Istio Github Repo](https://github.com/istio/istio/tree/master/samples/helloworld)

cluster1:

deploy v1

Shell

cluster2:

deploy v2

Shell

## Anpassen NetworkPolicy

Istio und Rancher haben schon ein paar NetworkPolicy Regeln installiert:

Shell

Mit dieser Regel erlauben wir explizit Traffic von und zu Istio Service Ports, Kube-API und Kube-DNS:

EOF | kubectl -n istio-system apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  annotations:
  name: np-istio-ports
  namespace: istio-system
spec:
  egress:
  - ports:
    - port: 15010
      protocol: TCP
  - ports:
    - port: 15012
      protocol: TCP
  - ports:
    - port: 15014
      protocol: TCP
  - ports:
    - port: 15017
      protocol: TCP
  - ports:
    - port: 15443
      protocol: TCP
  - ports:
    - port: 6443
      protocol: TCP
  - ports:
    - port: 80
      protocol: TCP
  - ports:
    - port: 53
      protocol: TCP
  - ports:
    - port: 53
      protocol: UDP
  ingress:
  - ports:
    - port: 80
      protocol: TCP
  - ports:
    - port: 15010
      protocol: TCP
  - ports:
    - port: 15012
      protocol: TCP
  - ports:
    - port: 15014
      protocol: TCP
  - ports:
    - port: 15017
      protocol: TCP
  - ports:
    - port: 15443
      protocol: TCP
  podSelector: {}
  policyTypes:
  - Egress
  - Ingress
EOF

Am Ende erlauben wir in unserer App auch Traffic zu Istio Service, Kube-DNS und natürlich dem Service Port, auf dem Helloworld ausgeliefert wird:

Shell

stallation (Fehlersuche)

Überprüfen Eastwest Traffic

Shell

Bei funktionierendem Eastwest Gateway sollten wir als Endpunkt die Loadbalancer Ip-Adresse des Remote Cluster
auf dem mTLS port 15443 sehen. Ohne Eastwest erscheint die POD-IP jedes Helloworld POD (welche im Remote Cluster nicht erreichbar ist).

Shell

Das Istio Project sammelte Informationen in einem [Leitfaden zur Fehlersuche](https://istio.io/latest/docs/ops/common-problems/network-issues/).

## Trafficverteilung

Um etwas Ordnung im Trafficmanagement der Helloworld zu bekommen, entscheiden wir
welche Version auf welchem Endpunkt läuft:

Shell

Jetzt können wir sagen, 90% der Traffic wird von einem Service ausgeliefert
und 10% vom anderen:

EOF | kubectl -n sample apply -f -
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: helloworld
spec:
  gateways:
  - helloworld-gateway
  hosts:
  - '*'
  http:
  - match:
    - uri:
        exact: /hello
    route:
    - destination:
        host: helloworld
        port:
          number: 5000
        subset: v1
      weight: 10
    - destination:
        host: helloworld
        port:
          number: 5000
        subset: v2
      weight: 90
EOF

Nicht zu vergessen ist, dies auf beide Cluster anzuwenden, um beide
Ingress mit derselben Konfiguration zu versorgen. Jetzt sollten wir
mehr v2 Versionen in der Antwortschleife sehen:

Shell

## SSL Frontend mit Let's Encrypt Zertifikation

Um mehr produktionsreif zu sein, wir möchten SSL-Terminierung am Frontend
verwenden, eine selbstverwaltetes Let's Encrypt Zertifikat zusammen mit einem
üblichen Hostnamen.

Um mit dem Hostname Problem zu beginnen, verwenden wir schon External-DNS](https://github.com/kubernetes-sigs/external-dns)
und müssen die Quellenliste erweitern, wo external-dns auf Annotations hört:

Shell

Weiterhin gibt es beim cert-manager ein Problem mit Istio,
weswegen er nicht im User Namespace arbeiten kann, in dem
sich die Applikation befindet (`sample`).

"The Certificate should be created in the same namespace as the istio-ingressgateway"

Ref: [https://istio.io/latest/docs/ops/integrations/certmanager/](https://istio.io/latest/docs/ops/integrations/certmanager/)

Das mag die Entscheidung sein, dass der Cluster Admin verantwortlich ist für
diese Aufgabe und nicht der User ohne Berechtigung im Istio Projekt in Rancher.

Erstellen eines Gateway für SSL Terminierung

Shell

Das DNS Ziel ist die IP-Adresse des IngressGateway
Hinweis: Um mit dem external-dns Webhool zu kommunizieren, benötigen wir eine
NetworkPolicy Egress tcp/80 Regel.

Erstellen des VirtualService für Traffic Routing zur Helloworld App im
sample Namespace:

EOF | kubectl -n istio-system apply -f -
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  annotations:
  name: helloworld-ssl
spec:
  gateways:
  - helloworld-ssl-gateway
  hosts:
  - '*'
  http:
  - match:
    - uri:
        exact: /hello
    route:
    - destination:
        host: helloworld.sample.svc.cluster.local
        port:
          number: 5000
        subset: v1
      weight: 90
    - destination:
        host: helloworld.sample.svc.cluster.local
        port:
          number: 5000
        subset: v2
      weight: 10
EOF

Erstellen eines Zertifikats für Helloworld:

Shell

Da ist die Annahme, wir haben einen ClusterIssuer `letsencrypt-wild` mit
dns01-challenge und eine Designate-verwaltete Domain, da wir external-dns benutzen.

 cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-wild
spec:
  acme:
    email: cloud-operations@telekom.de
    preferredChain: ""
    privateKeySecretRef:
      name: letsencrypt-wild
    server: https://acme-v02.api.letsencrypt.org/directory
    solvers:
    - dns01:
        webhook:
          groupName: acme.syseleven.de
          solverName: designatedns

Let`s Encrypt http-01 Challenge wird nicht aus dem Hut mit Istio funktionieren,
da die Challenge eine temporaere Ingress Defintion erwartet.

Man wird sowas wie dies hier auf dem IngressGateway sehen:

Shell

Überprüfen ob das Zertifikat ausgestellt wurde:

Shell

Verbindung überprüfen:

Shell

Dieselbe Aufgabe ist auf dem zweiten Cluster erforderlich,
um wirklich autonom zu sein. Unerfreulicherweise wir können keine
[mehrfache A Records von verschiedenen Instanzen in external-dns](https://github.com/kubernetes-sigs/external-dns/issues/1441) setzen.
So müssen wir diese Automatisierungsschritt überspringen und können
2 A-Records manuell setzen:

Shell

Der Schleifentest oben sollte an beiden Endpunkten funktionieren und
sollte entsprechend der Namensauflösung folgen.

Mehr Beispiele gibt es im Istio Github Repo oder Istio Dokumentation.

Viel Spass mit Istio!