In diesem Blog-Post zeigen wir, wie der CIC im Kubernetes Cluster deployed werden kann und wie die Bereitstellung einer Sample-Webapp inkl. Ingress-Konfiguration und SSL-Offloading durch den ADC funktioniert.
Folgende Inhalte erwarten euch im Beitrag:
Was ist der Citrix Ingress Controller?
Das Thema Kubernetes ist aus der modernen Anwendungsbereitstellung seit Jahren nicht mehr weg zu denken. Immer mehr Hersteller bieten deswegen Third-Party-Lösungen an.
Auch Citrix setzt auf Kubernetes auf und bietet u.a. eine Integration des Citrix ADC (ehm. NetScaler) als Ingress Device, um über Kubernetes bereitgestellte Anwendungen außerhalb des Clusters verfügbar zu machen. Hierbei bietet der ADC seine bekannten Vorteile wie z.B. sehr hohe Performance, mächtige Layer 7 Funktionalitäten (HTTP Rewrite, Content Switching, Web Application Firewall (WAF), etc.) sowie erweiterte Monitoring- und Logging-Möglichkeiten.
Die Konfiguration des ADC wird dabei nicht händisch, sondern vollautomatisiert durch den Citrix Ingress Controller (CIC) übernommen. Dieser wird als Container innerhalb des Kubernetes Clusters betrieben und konvertiert die Ingress-Definitionen einer Anwendung in Konfigurationen für den Citrix ADC.
Voraussetzungen
- Kubernetes Cluster (v1.10+) mit Zugriff auf kubectl
- Citrix ADC (11.1-61.7+) VPX / MPX
Neben self-hosted Kubernetes Clustern werden auch managed Lösungen wie z.B. AKS, EKS und GKE unterstützt.
Weitere Informationen hierzu können den Developer-Docs entnommen werden.
Citrix Ingress Controller Deployment
Citrix bietet mehrere Deployment-Topologien für verschiedene Einsatzzwecke an. Wir verwenden in diesem Fall die Single-Tier Topologie bei der eine VPX oder MPX Appliance als Ingress-Device für den Northd-South-Traffic verwendet wird. Der für die Konfiguration zuständige CIC wird als Standalone Pod deployed.
1.
ADC System-User-Credentials als Secret anlegen
kubectl create secret generic nslogin --from-literal=username='nsroot' --from-literal=password='<pwd>'
In diesem Beispiel wird der nsroot User verwendet. Außerhalb von Laborumgebungen sollte unbedingt ein eingeschränkter Systemuser angelegt werden.
2.
CIC-Config als YAML-File speichern und NSIP oder SNIP für Management-Zugriff setzen
3.
CIC auf Kubernetes Cluster deployen
kubectl apply -f <cic-config-file.yaml>
4.
CIC Pod prüfen
kubectl get pods --all-namespaces -l app=cic-k8s-ingress-controller
Der Status sollte nach Abschluss des Deployments auf „Running“ stehen.
5.
Sollte der Status nach einigen Minuten weiterhin nicht auf „Running“ stehen, können folgende Commands beim Troubleshooting helfen.
kubectl describe pods --all-namespaces -l app=cic-k8s-ingress-controller
kubectl logs <cic-pod-name>
Stelle dabei vor allem sicher, dass der CIC sich erfolgreich zum mit ADC verbinden kann.
Beispiel: Webapp-Deployment
Nachdem wir erfolgreich den CIC als Standalone Pod deployed haben, wollen wir eine erste Webapp in unserem Kubernetes Cluster bereitstellen und diese über den Citrix ADC als Ingress Device nach außen veröffentlichen.
Als Beispiel nutzten wir die Guestbook-Anwendung von Google. Diese besteht aus einem einfachen Frontend sowie einer Redis Datenbank als Backend mit einem Master und mehreren Slaves.
Im ersten Schritt werden wir die Anwendung im Cluster bereitstellen und mit einer ersten Ingress-Konfiguration nach außen veröffentlichen.
1.
Guestbook-Config als YAML-File speichern
2.
Annotation für Frontend-VIP definieren
3.
Hostname der Anwendung definieren
Der Hostname sollte im DNS auf die Frontend-IP zeigen.
4.
Die komplette Ingress-Definition
5.
Abschließend kann unsere Beispielanwendung nun deployed werden.
kubectl apply -f <guestbook-config.yaml>
6.
Webapp Pods prüfen
kubectl get pods --all-namespaces -l app=guestbook
7.
Ingress prüfen
kubectl get ingress guestbook-ingress
kubectl describe ingress guestbook-ingress
kubectl logs <cic-pod-name>
8.
ADC Config prüfen
Auf dem ADC sollte ein neuer CS VServer mit der definierten Frontend-IP konfiguriert sein.
Die neu angelegte Servicegroup zeigt auf eine der Node-IPs des Kubernetes Clusters
Die Konfiguration des Routings zwischen ADC und Kubernetes Cluster Nodes geschieht ebenfalls automatisiert. Dies wird durch das Node-Watch-Feature des CICs gesteuert, dass für jede Node des Clusters statische Routen anlegt.
9.
Aufruf der Anwendung im Browser
10.
Sollte es Anpassungen an der Anwendung oder auch dem Ingress geben, muss lediglich der kubectl apply Command erneut ausgeführt werden. Die Konfiguration wird automatisch angepasst.
Ingress-Konfiguration mit SSL-Offloading
Um für unsere Anwendung SSL-Offloading zu konfigurieren, benötigt es nur wenige Anpassungen an der Ingress-Definition. Voraussetzung hierfür ist ein bereits auf dem ADC angelegtes Server-Zertifikat.
1.
Annotations konfigurieren
ingress.citrix.com/preconfigured-certkey: '{"certs": [ {"name": "<server-cert>", "type": "default"} ] }' # predefined server certificate
ingress.citrix.com/insecure-termination: redirect # allow = HTTP allowed, redirect = HTTP 2 HTTPS redirect, disallow = HTTPS only
ingress.citrix.com/frontend-sslprofile: "ns_default_ssl_profile_secure_frontend" # predefined frontend SSL profile
Die letzte Annotation für die Konfiguration des SSL-Profils ist optional. Dies muss ebenfalls bereits auf dem ADC angelegt sein.
2.
TLS in der Ingress-Definition aktivieren
3.
Konfiguration aktivieren
kubectl apply -f <guestbook-config.yaml>
4.
ADC Config prüfen
Auf dem ADC sollten nun zwei CS VServer konfiguriert sein. Der VServer für Port 80 führt lediglich einen Redirect HTTPS durch.
Am SSL-VServer sind das definierte Server-Zertifikat und SSL-Profile gebunden.
Schlusswort
Damit haben wir den Citrix Ingress Controller im Kubernetes Cluster deployed und unsere erste Webapp in nur wenigen Schritten über einen Citrix ADC als Ingress Device sicher nach außen veröffentlicht.
Der CIC bietet noch viele weitere Anwendungsfälle und Funktionen, die wir Euch gerne in künftigen Blogbeiträgen zeigen.
