Auf einen Blick: Kubernetes Ingress ist ein API-Objekt, das Routing-Regeln für den Zugriff auf Dienste in einem Kubernetes-Cluster verwaltet und so Sicherheit und Lastverteilung verbessert. Es vereinfacht die Service-Exposition, indem es als einziger Eintrittspunkt fungiert.
- Ingress besteht aus einem API-Objekt und einem Ingress Controller für das Verkehrsrouting.
- Es unterstützt mehrere Protokolle, Authentifizierung und inhaltsbasiertes Routing.
In jedem Kubernetes-Cluster müssen Anwendungen in der Lage sein, sich mit der Außenwelt zu verbinden, um Endnutzern Zugriff auf die Anwendung zu ermöglichen. Kubernetes Ingress ist eine verfügbare Option – schauen wir uns das mal an.
Was ist Kubernetes Ingress?
Kubernetes Ingress ist ein API-Objekt, das Routing-Regeln bereitstellt, um den Zugriff auf die Dienste innerhalb eines Kubernetes-Clusters zu verwalten. Dies verwendet typischerweise HTTPS- und HTTP-Protokolle, um das Routing zu erleichtern.
Ingress ist die ideale Wahl für eine Produktionsumgebung. Nutzer können Dienste innerhalb des Kubernetes-Clusters bereitstellen, ohne mehrere Load Balancer erstellen oder Dienste manuell offenlegen zu müssen.
Darüber hinaus bietet K8s Ingress einen einzigen Einstiegspunkt für den Cluster, der es Administratoren ermöglicht, die Anwendungen einfach zu verwalten und Routing-Probleme zu diagnostizieren. Dies verringert die Angriffsfläche des Clusters und erhöht automatisch die Gesamtsicherheit.
Einige Anwendungsfälle von Kubernetes Ingress sind:
- Bereitstellung extern erreichbarer URLs für Dienste
- Lastverteilungsverkehr
- Angebot von namensbasiertem virtuellem Hosting
- SSL (Secure Sockets Layer) oder TLS (Transport Layer Security) beenden
Kubernetes Ingress unterstützt mehrere Protokolle, Authentifizierung, inhaltsbasiertes Routing usw. und ermöglicht es Nutzern, diese in Kubernetes-Clustern einfach zu verwalten und zu konfigurieren.
Kubernetes Ingress besteht aus zwei Kernkomponenten:
- Ingress-API-Objekt. Das API-Objekt gibt die Dienste an, die außerhalb des Clusters bereitgestellt werden müssen. Es besteht aus den Routing-Regeln.
- Ingress Controller. Ingress Controller ist die eigentliche Implementierung von Ingress. Er ist üblicherweise ein Load Balancer, der den Datenverkehr von der API zu den gewünschten Diensten im Kubernetes-Cluster leitet.
Was ist ein Ingress-Controller?
Bei der eigentlichen Implementierung von Kubernetes Ingress ist der Ingress-Controller für die Verkehrsleitung von externen Quellen zu den entsprechenden Diensten im Kubernetes-Cluster verantwortlich. Ingress-Controller unterstützen das Routing sowohl über die Transportschicht (OSI – Schicht 4) als auch über die Anwendungsschicht (OSI – Schicht 7) im OSI-Modell.
Das Routing auf Anwendungsebene wird dem einfachen Transportschicht-Routing vorgezogen, da es eine größere Kontrolle bietet, wie zum Beispiel das Lastenausgleich des externen Verkehrs basierend auf Anfragen. Die Ingress-Controller werden weder automatisch mit einem Kubernetes-Cluster gestartet noch Teil des Standard-"kube-controller-manager"-Binärsystems.
Kubernetes bietet integrierte Unterstützung für AWS-, GCE- und nginx-Ingress-Controller und unterstützt außerdem die Integration mit Drittanbieter-Ingress-Controllern. Die Wahl des Ingress-Controllers hängt von folgenden ab:
- Ihre Bewerbungsanforderungen
- Die Wirtumgebung
Einfach ausgedrückt ist der Ingress-Controller eine Anwendung, die innerhalb des Kubernetes-Clusters läuft und entsprechend den Anforderungen von Ingress einen Load Balancer bereitstellt. (Der Load Balancer kann ein Software-Load Balancer, externer Hardware-Load Balancer oder Cloud-Load Balancer sein, wobei jeder Typ unterschiedliche Controller-Implementierungen erfordert.)
Ingress vs. Alternativen zur Offenlegung von Diensten
Die Nutzung von Ingress ist nicht die einzige Möglichkeit, Dienste bereitzustellen.
Eine Kubernetes-Service-Ressource bietet eine abstrakte Möglichkeit, eine Reihe gezielter Anwendungspods als Netzwerkdienst bereitzustellen. Gleichzeitig verwendet Kubernetes ClusterIP-, NodePort- und Load Balancer-Methoden , um Dienste sowohl intern innerhalb der Knoten als auch extern außerhalb des Clusters bereitzustellen.
- ClusterIP ist der Standarddiensttyp, der Dienste über eine interne Cluster-IP freistellt. Diese Methode stellt nur den Dienst innerhalb des Clusters frei und ist extern nicht erreichbar.
- NodePort stellt den Dienst über einen statischen Port frei, der dem gewünschten Knoten zugeordnet ist. Die NodePort-Konfiguration erstellt automatisch die ClusterIP, um den Datenverkehr intern zu routen. Benutzer können extern auf den Dienst zugreifen, indem sie die IP-Adresse des Knotens und den freiliegenden Port verwenden.
- LoadBalancer stellt den Service über den Load Balancer des Cloud-Anbieters frei und erstellt automatisch die notwendigen NodePorts und ClusterIPs, um den gewünschten Datenverkehr zu routen.
(Erfahren Sie mehr über NodePort, Port und TargetPort.)
Das individuelle Offenstellen und Verwalten von Diensten ist ineffizient und in großen Kubernetes-Clustern nicht skalierbar. So wird Ingress zur idealen Lösung – indem es als Einstiegspunkt für den gesamten Kubernetes-Cluster dient. Dies ermöglicht es den Nutzern:
- Verwalte alle Routing-Regeln von einer zentralen Ressource aus
- Mehrere Dienste unter einer einzigen IP-Adresse bereitstellen
Erstellung einer Ingress-Ressource
Schauen wir uns nun an, wie man eine Ingress-Ressource erstellt.
Wie bei jeder anderen Ressource in Kubernetes besteht die Ingress-Ressource auch aus apiVersion-, Kind- und Metadatenfeldern mit den gewünschten Regeln und Konfigurationen im Spec-Abschnitt.
Einfache Ingress-Konfiguration
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/app-root: /test_app
name: testapproot
namespace: default
spec:
rules:
- host: testapproot.mycluster.com
http:
paths:
- backend:
serviceName: http-svc
servicePort: 80
path: /
Bei der Definition einer Ingress-Ressource muss der Name des Ingress-Objekts den gültigen DNS-Namenskonventionen der Subdomain entsprechen. Darüber hinaus können Annotationen verwendet werden, um Ingress-Ressourcen mit spezifischen Optionen zu konfigurieren. In der obigen YAML-Datei verwenden wir die Option "nginx.ingress.kubernetes.io/app-root", um die Anwendungswurzel zu definieren, die der Ingress-Controller umleiten muss, wenn der Root-Pfad aufgerufen wird (Pfad: /).
Verschiedene Arten von Ingress-Steuerungen bieten unterschiedliche Annotationsunterstützung, und der Benutzer muss die Annotationen an den gewünschten Controller anpassen.
Eintrittsregeln
Ingress-Regeln sind der Kern von Kubernetes Ingress. Sie definieren, was mit dem eingehenden Datenverkehr passiert und an welche Dienste dieser Datenverkehr geleitet werden soll. Jede HTTP-Regel besteht aus mehreren Feldern, um die Regel korrekt zu definieren.
- Host ist ein optionaler Parameter, der definiert, auf welchen Host die Regel angewendet wird. Wenn der Host-Parameter nicht definiert ist, wird die Regel auf den gesamten eingehenden HTTP-Verkehr angewendet.
- Pfade beziehen sich auf die Liste der Pfade, die mit einem Backend verbunden sind. Sowohl der Host als auch der Pfad sollten übereinstimmen, um den Datenverkehr korrekt zum gewünschten Dienst zu routen.
- Backend ist dasZiel, zu dem der eingehende Datenverkehr letztlich geleitet werden sollte. Dies kann ein Kubernetes-Dienst oder ein benutzerdefiniertes Ressourcen-Backend sein, um eine weitere Ressource im gleichen Namensraum (z. B. Storage Bucket) anzuzeigen.
Jede Anfrage, die keiner der definierten Regeln entspricht, wird an das Standard-Backend weitergeleitet. Dieses Standard-Backend ist Teil des Ingress-Controllers selbst und nicht in der Ingress-Ressource spezifiziert.
Definition mehrerer Ingress-Regeln
Da wir nun ein besseres Verständnis der Ingress-Ressource haben, können wir sehen, wie man mehrere Ingress-Regeln mit verschiedenen Hosts und Backends definiert.
Arten von Eintritt
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: myapp
spec:
rules:
- host: "app.mycluster.com"
http:
paths:
- pathType: Prefix
path: "/home"
backend:
serviceName: http-app
servicePort: 80
- pathType: Prefix
path: "/admin"
backend:
serviceName: http-app
servicePort: 8080
- host: "data.mycluster.com"
http:
paths:
- pathType: Prefix
path: "/charts"
backend:
serviceName: http-charts
servicePort: 81
In der obigen Konfiguration haben wir drei Routing-Regeln für zwei verschiedene Hosts konfiguriert, die unterschiedliche Dienste nutzen.
Moderator: "app.mycluster.com"
Dieser Abschnitt besteht aus zwei Regeln, die nur für den Datenverkehr gelten, der an app.mycluster.com gerichtet ist. Wenn der URL-Pfad mit /home oder /admin übereinstimmt, wird der Datenverkehr an verschiedene Ports desselben Dienstes weitergeleitet.
Moderator: "data.mycluster.com"
Die einzelne Regel, die konfiguriert ist, gilt für Datenverkehr, der an data.mycluster.com Host gerichtet ist, und wenn der URL-Pfad mit /charts übereinstimmt, wird der Verkehr auf Port 81 des "http-charts"-Dienstes geleitet.
Kubernetes Ingress-Pfadtypen
Bei der Definition von Regeln muss der Pfad einen entsprechenden Pfadtyp enthalten, um die Regeln korrekt zu validieren. Kubernetes hat drei Pfadtypen:
- Dies entspricht den Konfigurationen einer IngressClass , die in einem Ingress Controller definiert ist. Sie wird je nach Implementierung der Klasse als separater Pfadtyp behandelt oder gleich wie Prefix- oder Exakte-Typen.
- Wir können diesen Typ verwenden, wenn der Benutzer einen URL-Pfad exakt mit der Groß- und Kleinschreibsensitivität abgleichen möchte.
- Diese passt die URL basierend auf dem Pfadpräfix ab, das durch den Vorwärtsschrägstrich (/) geteilt wird. Dies ist ebenfalls groß- und kleinschreibungssensitiv, und der Matching-Prozess erfolgt von Element zu Element in der URL.
Schauen wir uns nun einige Pfad-Matching-Szenarien an.
| Pfadtyp | Verlauf | Beispielanfrage | Spiel |
| Genau | /Test | www.example.com/test | Ja |
| Genau | /Test | www.example.com/test/ | Nein |
| Präfix | /Test | www.example.com/test www.example.com/test/ | Ja (beide URLs) |
| Präfix | /test/user | www.example.com/test/us | Nein |
In Fällen, in denen mehrere Übereinstimmungen für eine Anfrage verfügbar sind, erhält die Anfrage mit dem längsten passenden Pfad Präferenz. Wenn beide Pfade exakt übereinstimmen, wählt der Ingress-Controller den exakten Pfadtyp über das Präfix, um die notwendige Ingress-Regel anzuwenden.
(Tauchen Sie tiefer in alle passenden Szenarien in der offiziellen Kubernetes-Dokumentation ein.)
Es gibt drei Arten von Ingress in Kubernetes;
- Ein einzelner Service. Dies ist ein Ingress, der von einem einzelnen Service unterstützt wird, bei dem ein einzelner Service offengelegt wird. Um dies zu definieren, geben Sie ein Standard-Backend ohne Regeln an.
- Einfacher Fanout. Der Fanout-Typ ist ein einziger Einstiegspunkt (eine IP-Adresse), der mehrere Dienste bereitstellt. Dort wird der URL-Verkehr je nach Anfrage zum gewünschten Ziel weitergeleitet. Diese Methode ermöglicht es den Nutzern, die Anzahl der Load Balancer zu reduzieren und das Routing innerhalb des Clusters einfach zu verwalten.
- Namensbasiertes virtuelles Hosting. Diese Methode kann verwendet werden, um den Datenverkehr von einem einzigen Eintrag (IP-Adresse) zu verschiedenen Hosts innerhalb des Clusters zu leiten. Hier wird der Datenverkehr zunächst auf einen bestimmten Host ausgerichtet, bevor ein weiteres Routing durchgeführt wird.
Benutzer können einen Eingang sichern, indem sie ein Geheimnis mit einem unterstützten TLS-Schlüssel und einem Zertifikat angeben. Die Eintrittsressource unterstützt einen einzigen TLS-Port (443) und geht davon aus, dass TLS am Eintrittspunkt terminiert wird. Anschließend erfolgt die interne Kommunikation über Klartext.
Dienste besser verwalten, mit verbesserter Sicherheit
Kubernetes Ingress bietet eine einheitliche Ressource, um den Datenverkehr zu Ihren Anwendungen in einem Kubernetes-Cluster zu verwalten und weiterzuleiten, ohne Dienste und Lastverteilungen manuell verwalten zu müssen.
Verwandte Literatur
- BMC DevOps Blog
- Kubernetes Best Practices für verbesserte Cluster-Effizienz
- Wie Container und Kubernetes zusammenarbeiten
- Kubernetes vs. Docker Swarm: Vergleich von Container-Orchestrierungstools
- Docker-Sicherheit: 14 Best Practices zur Sicherung von Docker-Containern
- Der Zustand der Container heute: Eine Berichtszusammenfassung
Kubernetes-Leitfaden
- Was ist Kubernetes (K8s)? Ein Tutorial zu den Grundlagen von Kubernetes
- Kubernetes Best Practices für verbesserte Cluster-Effizienz
- Best Practices: Wie man Anwendungen für Kubernetes architekt
- Kubernetes Pods: Eine Einführung
- Kubernetes ReplicaSets: Eine kurze Einführung
- Kubernetes-Deployments vollständig erklärt
- Wie man Kubernetes DaemonSets verwendet und verwaltet
- Wie Kubernetes-Dienste funktionieren
- Verwendung von Kubernetes Port, TargetPort und NodePort
- Erstellen und verwenden von ConfigMaps in Kubernetes
- Einführung in Kubernetes-Geheimnisse
- Kubernetes-Netzwerkgrundlagen
- Kubernetes-Ingress erklärt
- Einführung in Kubernetes Helm Charts
- Was ist das Kubernetes-Operator-Muster?
- Bereitstellung von PostgreSQL als StatefulSet in Kubernetes
- Kubernetes Custom Resource Definition (CRDs) erklärt
- 3 Kubernetes-Muster für Cloud-native Anwendungen
- Kubernetes Compute-Ressourcen erklärt
- Kubernetes-Sicherheit für DevOps-Pipelines
- Verwendung von Spinnaker mit Kubernetes für Continuous Delivery
- Kubernetes-Multi-Cluster: Wie und warum man sie verwendet.
- Kubernetes-Überwachung: Ein umfassender Leitfaden
- Kubernetes vs. Docker: Ein kurzer Vergleich
- Kubernetes vs. Docker Swarm: Vergleich von Container-Orchestrierungstools
- Kubernetes vs. OpenShift: Was ist der Unterschied?
- Kubernetes-Zertifizierungen: Wie und warum man zertifiziert wird
Diese Beiträge sind meine eigenen und spiegeln nicht unbedingt die Position, Strategien oder Meinung von BMC wider.