Exposing Services in Kubernetes
Es gibt verschiedene Möglichkeiten, Dienste in Kubernetes zu exponieren, damit sowohl interne Endpunkte als auch externe Endpunkte darauf zugreifen können. Diese Kubernetes-Konfiguration ist ziemlich kritisch, da der Administrator Angreifern Zugriff auf Dienste geben könnte, auf die sie keinen Zugriff haben sollten.
Automatische Enumeration
Bevor Sie damit beginnen, die Möglichkeiten zu enumerieren, die K8s bietet, um Dienste für die Öffentlichkeit zugänglich zu machen, wissen Sie, dass Sie, wenn Sie Namespaces, Dienste und Ingresses auflisten können, alles, was der Öffentlichkeit zugänglich ist, finden können mit:
ClusterIP
Ein ClusterIP-Dienst ist der Standard-Kubernetes-Dienst. Es bietet Ihnen einen Dienst innerhalb Ihres Clusters, auf den andere Apps innerhalb Ihres Clusters zugreifen können. Es gibt keinen externen Zugriff.
Es kann jedoch über den Kubernetes-Proxy zugegriffen werden:
Nun können Sie durch die Kubernetes-API navigieren, um auf Dienste zuzugreifen, die dieses Schema verwenden:
http://localhost:8080/api/v1/proxy/namespaces/<NAMESPACE>/services/<SERVICE-NAME>:<PORT-NAME>/
Zum Beispiel könnten Sie die folgende URL verwenden:
http://localhost:8080/api/v1/proxy/namespaces/default/services/my-internal-service:http/
um auf diesen Dienst zuzugreifen:
Dieser Methode erfordert, dass Sie kubectl
als authentifizierter Benutzer ausführen.
NodePort
Wenn NodePort verwendet wird, wird ein bestimmter Port auf allen Nodes (die die virtuellen Maschinen repräsentieren) verfügbar gemacht. Der Datenverkehr, der an diesen spezifischen Port gerichtet ist, wird dann systematisch zum Service geroutet. Normalerweise wird diese Methode aufgrund ihrer Nachteile nicht empfohlen.
Ein Beispiel für die NodePort-Spezifikation:
Wenn Sie den nodePort nicht in der yaml angeben (es ist der Port, der geöffnet wird), wird ein Port im Bereich 30000–32767 verwendet.
LoadBalancer
Stellt den Service extern unter Verwendung eines Load Balancers des Cloud-Anbieters bereit. Auf GKE wird dies einen Network Load Balancer starten, der Ihnen eine einzelne IP-Adresse zur Verfügung stellt, die den gesamten Datenverkehr an Ihren Service weiterleitet.
Sie müssen für jeden freigegebenen Service einen LoadBalancer bezahlen, was teuer werden kann.
ExternalName
Aus den Dokumenten: Services vom Typ ExternalName ordnen einen Service einem DNS-Namen zu, nicht einem typischen Selektor wie my-service
oder cassandra
. Sie geben diese Services mit dem Parameter spec.externalName
an.
Diese Service-Definition ordnet beispielsweise den Service my-service
im Namespace prod
zu my.database.example.com
zu:
Beim Aufrufen des Hosts my-service.prod.svc.cluster.local
gibt der Cluster-DNS-Dienst einen CNAME
-Datensatz mit dem Wert my.database.example.com
zurück. Der Zugriff auf my-service
funktioniert genauso wie bei anderen Diensten, jedoch mit dem entscheidenden Unterschied, dass die Weiterleitung auf DNS-Ebene erfolgt und nicht über Proxys oder Weiterleitungen.
Externe IPs
Datenverkehr, der in den Cluster mit der externen IP (als Ziel-IP) eintritt, wird auf den Serviceport zu einem der Service-Endpunkte geroutet. externalIPs
werden nicht von Kubernetes verwaltet und liegen in der Verantwortung des Cluster-Administrators.
In der Service-Spezifikation können externalIPs
zusammen mit einem der ServiceTypes
angegeben werden. Im folgenden Beispiel kann "my-service
" von Clients unter "80.11.12.10:80
" (externalIP:port
) erreicht werden.
Ingress
Im Gegensatz zu allen obigen Beispielen ist Ingress KEIN Typ von Service. Stattdessen sitzt es vor mehreren Services und fungiert als "intelligenter Router" oder Einstiegspunkt in Ihren Cluster.
Sie können viele verschiedene Dinge mit einem Ingress tun, und es gibt viele Arten von Ingress-Controllern, die unterschiedliche Fähigkeiten haben.
Der Standard GKE Ingress-Controller wird einen HTTP(S) Load Balancer für Sie starten. Dies ermöglicht Ihnen sowohl routing basierend auf Pfaden als auch routing basierend auf Subdomains zu Backend-Services. Zum Beispiel können Sie alles auf foo.yourdomain.com zum Foo-Service senden und alles unter dem Pfad yourdomain.com/bar/ zum Bar-Service.
Das YAML für ein Ingress-Objekt auf GKE mit einem L7 HTTP Load Balancer könnte so aussehen:
Referenzen
Last updated