‫Jetzt, da Ihre Pods ausgeführt werden, müssen Sie sie wahrscheinlich irgendwann externen
‫Diensten aussetzen.
‫Dies bedeutet, dass sie Verbindungen in Ihrem Cluster oder von außerhalb Ihres Clusters
‫akzeptieren können.
‫In kubanischen Wirbeln verwenden wir den Befehl cube control exposed als eine Möglichkeit, einen Service zu erstellen.
‫Und wir haben den Service bereits einige Male erwähnt, aber stellen wir sicher, dass klar ist, was ein Service
‫ist.
‫Ein Endpunkt, der konsistent ist, damit andere Dinge innerhalb oder außerhalb des Clusters möglicherweise darauf zugreifen
‫können.
‫Wenn Sie also Pods und kubanische Entitäten erstellen, erhalten diese nicht automatisch einen DNS-Namen für die externe Konnektivität
‫mit einer IP-Adresse.
‫Richtig.
‫Sie möchten dies tun, indem Sie einen Service auf dem vorhandenen Pod erstellen.
‫Neben diesem offengelegten Befehl gibt es jetzt verschiedene Möglichkeiten, einen Dienst zu erstellen.
‫Aber konzentrieren wir uns darauf, was hier gemeinsam ist: Wenn Sie sich erinnern, dass wir bereits
‫erwähnt haben, dass dies eines der Hauptmerkmale Ihrer Steuerebene ist.
‫Dieser Dienst wird Ihr DNS-Server sein, der die Namen für all diese Dinge auflöst.
‫Und obendrein ist es Aufgabe einer von vier verschiedenen Diensttypen, die IP-Adresse im Port auszuwählen und
‫zu bestimmen, wie der Datenverkehr im Wesentlichen zu Ihrem Dienst geleitet wird.
‫Lassen Sie uns diese ab und zu durchgehen und einige Beispiele durchgehen.
‫Beginnen wir mit der Standard-Cluster-IP des Diensttyps.
‫In diesem Fall ist der wichtigste Aspekt, dass er nur im Cluster verfügbar ist.
‫Hier geht es also wirklich um eine Reihe von kubanischen Wirbeln, die mit einer anderen Reihe von Hülsen sprechen.
‫Und das bekommt sein eigenes DNS-Kleid richtig.
‫Das wird also die DNS-Adresse in der DNS-Kernsteuerebene sein und es wird eine IP-Adresse
‫in diesem virtuellen IP-Adressraum innerhalb des Clusters abgerufen.
‫Auf diese Weise können Ihre anderen Pods, die im Cluster ausgeführt werden, über den Port des Dienstes mit diesem Dienst
‫kommunizieren.
‫Wenn Sie also eine verletzte X-App ausführen und diese auf Port 80 ausgeführt wurde, als Sie diesen Dienst erstellt haben, kann
‫sich diese Dienst-IP auch auf Port 80 befinden.
‫Das sorgt also für eine gewisse Konsistenz.
‫Wenn Sie darüber nachdenken, ist dies sehr ähnlich zu der Art und Weise, wie Sie einen Service und einen Schwarm erstellen, da die
‫Services im Schwarm etwas anders sind. Sie haben eine andere Idee, sind aber zumindest dann konsistent, wenn Sie einen
‫Service erstellen, den sie bereitstellen Sie diese interne IP auf dem Load Balancer, wenn Sie sich erinnern, und es
‫läuft auf dem Port, auf dem die App ist.
‫In diesem Fall machen wir eine sehr ähnliche Sache, aber wir müssen diese mit einem offengelegten Befehl oder anderen Optionen erstellen,
‫über die wir später sprechen werden, und als nächstes ist hier oben der Knoten-Port, der plötzlich anders ist.
‫Es ist ein bisschen verwirrend.
‫Daher ist die Cluster-IP eine Standardeinstellung und funktioniert immer innerhalb des Clusters.
‫Es sind keine speziellen Firewall-Regeln außerhalb des Clusters erforderlich, damit der Datenverkehr dorthin
‫gelangt. Die Cluster-IP-Adresse ist jedoch nur im Cluster gültig.
‫Denken Sie also daran, dass die Cluster-IP-Adresse im Cluster als Knoten-Port für etwas außerhalb des Clusters ausgelegt ist, um
‫über die IP-Adressen auf den Knoten selbst mit Ihrem Dienst zu kommunizieren.
‫Wenn Sie also einen Knotenport erstellen, erhalten Sie auf jedem Knoten, der diesem Service zugewiesen ist,
‫einen High-Port.
‫Und sobald Sie das bekommen, können Sie andere Dinge aktualisieren, die über diesen Port wissen müssen.
‫Dieser Hafen wird also ein hoher Hafen sein.
‫Wenn Sie diesen Typ verwenden, wird beispielsweise Port 80 nicht verwendet.
‫Und der Schlüssel zu diesen beiden ist, dass sie in jedem Schrank immer verfügbar sind, ist Cluster.
‫Ganz gleich, ob Sie eine Cloud-Anbieterlösung verwenden oder Ihre eigenen kubanischen Wirbel rollen oder ein Paket
‫wie Dock, Enterprise oder Rancher bereitstellen.
‫Dies sind diejenigen, die immer sofort funktionieren.
‫Als Nächstes folgt der Typ des Lastenausgleichs.
‫Jetzt wird dies hauptsächlich in der Cloud verwendet.
‫Die Idee dabei ist, dass Sie einen externen Load Balancer über die kubanische 80er-Befehlszeile steuern, was
‫ziemlich cool ist.
‫Und im Grunde ist dies ein Haufen Automatisierung.
‫Was Sie hier tun, ist im Hintergrund, wenn Sie diesen Load Balancer erstellen, wird automatisch die Cluster-IP
‫im Node-Port erstellt, damit diese verfügbar sind, und dann wird mit dem externen System gesprochen.
‫Vielleicht sind es acht von uns, Load Balancer oder ein anderer Cloud-Anbieter.
‫Grundsätzlich werden diese von Ihren Infrastrukturanbietern bereitgestellt und ermöglichen es Cuba Days, über eine Remote-API
‫mit ihnen zu kommunizieren und sie für Sie zu konfigurieren.
‫Im Fall von vielleicht acht von uns, wenn Sie dies erstellen, befindet sich das Erstellen dieser
‫Knotenports in der Cluster-IP nicht nur im Back-End, sondern es weist auch den ADA-Lastausgleicher an, mit den
‫Knotenports zu sprechen.
‫Und das ist im Wesentlichen nur Automatisierung.
‫Richtig.
‫Dies erspart Ihnen den Schritt, Ada über die Befehlszeile oder das Webinterface ausführen zu müssen, um diesen
‫Load Bouncer automatisch für Sie einzurichten.
‫Bei den beiden möglichen Vorgehensweisen handelt es sich also um Überlegungen, da dies nur für den Datenverkehr gilt, der
‫von einer externen Quelle in Ihren Cluster eingeht, und ein Infrastrukturanbieter erforderlich ist, der kubanischen Entitäten die
‫Möglichkeit gibt, über Fernzugriff mit ihm zu kommunizieren.
‫Der letzte der Forest Service-Typen ist der externe Name.
‫Jetzt wird dies seltener verwendet und hat nichts mehr mit der Steuerung des eingehenden Datenverkehrs zu Ihren
‫Diensten zu tun.
‫Hier geht es mehr um Dinge in Ihrem Cluster, die mit externen Diensten gesprochen werden
‫müssen, und Sie möchten DNS-Namen im Kern-DNS-System erstellen, damit Ihr Cluster externe Namen auflösen kann, die Sie möglicherweise
‫nicht extern steuern können.
‫Einer der Gründe, warum Sie möglicherweise einen externen Namen verwenden, ist, dass Sie bei der Migration von
‫Dingen überlegen, ob bei einer Remoteanwendung außerhalb Ihres Sicherheitsclusters wahrscheinlich bereits ein
‫DNS-Name vorhanden ist.
‫Richtig.
‫Wenn Sie jedoch von diesen externen Diensten zu internen Diensten wechseln möchten, sollten Sie sich
‫überlegen, wie Sie den externen Namen als Ersatz für die Steuerung des DNS in Ihrem Büro verwenden können.
‫Sie könnten also im Grunde genommen eine einzige Befehlszeile für das kubanische Netz haben, anstatt zu sagen: Oh, ich
‫muss den externen DNS für etwas ändern, damit ich ein anderes Dienstprogramm für diesen DNS-Dienst ausführen kann, oder vielleicht
‫sogar für etwas, das nicht einmal eine API hat dahinter.
‫Vielleicht können Sie dies wie einen Unternehmens-DNS oder so etwas in Ihren Clustern verwenden, damit
‫Dienste in Ihren Clustern einen anderen Endpunkt auflösen als den, den sie zuvor hatten, der
‫extern war.
‫Ich stelle also fest, dass ich es wirklich nur verwende, wenn ich ändern muss, wie meine Daten aus meinem Cluster in einen
‫externen Dienst umgewandelt werden, aber ich habe keine Möglichkeit, das DNS von diesen anderen Dingen aus der Ferne zu steuern, also möchte
‫ich lieber nur Mach es in kubanischen Entitäten und erstelle ein paar externe Namen für meine Sachen.
‫Wenn ich dann dynamisch in kubanischen Einstellungen für meine Inhalte in meinem Cluster ändern möchte, kann ich das ziemlich
‫einfach tun, ohne mit irgendetwas anderem sprechen zu müssen.
‫Gut, wir werden diese für Service-Typen einpacken, aber es gibt eine andere Möglichkeit, wie der Datenverkehr in
‫Ihren Cluster gelangen kann, und zwar durch Ingress, und wir werden später darüber sprechen.
‫Das ist speziell für ACG-Verkehr ausgelegt.
‫Wenn wir zu dieser Vorlesung kommen, werden Sie verstehen, warum dies ein bisschen anders ist als diese
‫Servicetypen.