[Cloud-nativ | Kubernetes von Grund auf neu lernen] 17. Kubernetes Core Technology Service

Dieser Artikel wurde in die Rubrik „ K8s von Grund auf neu lernen “ aufgenommen.
Vorheriger Artikel: Containererkennung und Startstrategie von k8spod Zum Springen klicken

Bildbeschreibung hier einfügen

Service schnell verstehen

Wir haben bereits gelernt, dass die Bereitstellung nur die Anzahl der Microservice-Pods garantiert, die Dienste unterstützen, aber nicht das Problem des Zugriffs auf diese Dienste löst. Ein Pod ist nur eine Instanz eines laufenden Dienstes, der jederzeit auf einem Knoten anhalten und einen neuen Pod mit einer neuen IP auf einem anderen Knoten starten kann, sodass er keine Dienste mit einer bestimmten IP und Portnummer bereitstellen kann.

Um Dienste stabil bereitzustellen, sind Diensterkennungs- und Lastausgleichsfunktionen erforderlich. Die Aufgabe der Diensterkennung besteht darin, die entsprechende Back-End-Dienstinstanz für den Dienst zu finden, auf den der Client zugreift. Im K8S-Cluster ist der Dienst, auf den der Client zugreifen muss, das Dienstobjekt. Jeder Dienst entspricht einer gültigen virtuellen IP innerhalb des Clusters, und auf einen Dienst wird innerhalb des Clusters über die virtuelle IP zugegriffen.

In einem K8S-Cluster wird das Load-Balancing von Microservices durch kube-proxy implementiert. kube-proxy ist ein Load Balancer innerhalb des k8s-Clusters. Es ist ein verteilter Proxy-Server, und es gibt einen auf jedem Knoten von K8S; dieses Design spiegelt seine Skalierbarkeitsvorteile wider, je mehr Knoten auf den Dienst zugreifen müssen, desto mehr Kube-Proxy bietet Lastausgleichsfunktionen, die Anzahl der hoch- Verfügbarkeitsknoten nimmt ebenfalls zu. Im Gegensatz dazu verwenden wir normalerweise einen Reverse-Proxy für den Lastausgleich auf der Serverseite, und wir müssen das Hochverfügbarkeitsproblem des Reverse-Proxys weiter lösen.

Die Bedeutung der Existenz von Service

Verhindern, dass der Pod getrennt wird [Service Discovery]

Denn jedes Mal, wenn ein Pod erstellt wird, entspricht er einer IP-Adresse, und diese IP-Adresse ist kurzlebig und ändert sich jedes Mal, wenn der Pod aktualisiert wird. Angenommen, wenn es mehrere Pods auf unserer Front-End-Seite gibt, und es gibt auch mehrere Pods am Back-End. Wenn sie aufeinander zugreifen, müssen sie die IP-Adresse des Pods über das Registrierungszentrum abrufen und dann auf den entsprechenden Pod zugreifen.
Bitte Bildbeschreibung hinzufügen

Pod-Zugriffsrichtlinie definieren [Lastausgleich]

Der Pod am vorderen Ende der Seite greift über die Dienstschicht auf den Pod am hinteren Ende zu, und der Dienst kann hier auch Lastenausgleich durchführen. Es gibt viele Implementierungsstrategien für Lastenausgleich, wie zum Beispiel:

  • zufällig
  • Umfrage
  • Antwortverhältnis
    Bitte Bildbeschreibung hinzufügen

Die Beziehung zwischen Pod und Dienst

Hier basiert die Zuordnung zwischen Pod und Dienst immer noch auf Label und Selektor [dasselbe wie Controller]

Bitte Bildbeschreibung hinzufügen
Wenn wir auf den Dienst zugreifen, brauchen wir eigentlich eine IP-Adresse, diese IP ist definitiv nicht die IP-Adresse des Pods, sondern eine virtuelle IP.vip

Gängige Arten von Diensten

Es gibt drei gängige Arten von Diensten

  • ClusterIp: Zugriff innerhalb des Clusters
  • NodePort: Wird von externen Zugriffsanwendungen verwendet
  • LoadBalancer: wird für Anwendungen mit externem Zugriff verwendet, Public Cloud

Beispiel

Wir können eine Datei exportieren, die die Konfigurationsinformationen des Dienstes enthält

kubectl expose deployment web --port=80 --target-port=80 --dry-run -o yaml > service.yaml

service.yaml sieht so aus

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  labels:
    app: web
  name: web
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: web
status:
  loadBalancer: {
    
    }

Wenn wir es nicht setzen, wird die erste Methode, ClusterIp, standardmäßig verwendet, das heißt, sie kann nur innerhalb des Clusters verwendet werden. Wir können ein Typfeld hinzufügen, um unseren Diensttyp festzulegen.

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  labels:
    app: web
  name: web
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: web
  type: NodePort
status:
  loadBalancer: {
    
    }

Nachdem wir den Befehl geändert haben, erstellen wir einen Pod mit

kubectl apply -f service.yaml

Dann können Sie sehen, dass es erfolgreich in den NodePort-Typ geändert wurde, und der letzte verbleibende Weg ist LoadBalanced: Anwendungen mit externem Zugriff, die eine öffentliche Cloud verwenden

Der Knoten wird im Allgemeinen im Intranet bereitgestellt, und das externe Netzwerk ist im Allgemeinen nicht zugänglich. Wie kann man also darauf zugreifen?

  • Suchen Sie einen Computer, auf den über das externe Netzwerk zugegriffen werden kann, installieren Sie nginx und den Reverse-Proxy
  • Zugängliche Knoten manuell zu nginx hinzufügen

Wenn wir LoadBalancer verwenden, gibt es einen Load-Balancing-Controller, ähnlich der Funktion von nginx, und wir müssen ihn nicht selbst zu nginx hinzufügen

Layer 4 Load Balancing Service: Konzept und Prinzipinterpretation

Warum Service?

In Kubernetes haben Pods einen Lebenszyklus, und wenn ein Pod neu gestartet wird, ändert sich wahrscheinlich seine IP. Wenn alle unsere Dienste die IP-Adresse des Pods zu Tode schreiben, der Pod hängt oder neu gestartet wird, können andere Dienste, die mit dem gerade neu gestarteten Pod verbunden sind, den damit verbundenen Pod nicht finden. Um dieses Problem zu lösen, definieren Sie in kubernetes Mit dem Dienstressourcenobjekt definiert Dienst einen Dienstzugriffseintrag, über den der Client auf die Anwendungsclusterinstanz hinter dem Dienst zugreifen kann. Ein Dienst ist eine logische Sammlung einer Gruppe von Pods, auf die von einem Dienst zugegriffen werden kann, normalerweise implementiert durch Tag-Selektoren.
Bitte Bildbeschreibung hinzufügen
1. Die Pod-IP ändert sich häufig. Der Dienst ist der Proxy des Pods. Wenn unser Client zugreift, müssen wir nur auf den Dienst zugreifen, und die Anfrage wird an den Pod weitergeleitet.

2. Auf die Pod-IP kann außerhalb des k8s-Clusters nicht zugegriffen werden, daher muss ein Dienst erstellt werden, auf den außerhalb des k8s-Clusters zugegriffen werden kann.

Leistungsübersicht

Der Dienst ist eine feste Zugriffsebene. Der Client kann auf den mit dem Dienst verknüpften Back-End-Pod zugreifen, indem er auf die IP-Adresse und den Port des Dienstes zugreift. Die Arbeit dieses Dienstes hängt von einem Zubehör ab, das auf dem Kubernetes-Cluster bereitgestellt wird, dem Kubernetes-DNS-Dienst (verschiedene Kubernetes-DNS-Dienste). Die standardmäßig verwendete Version von DNS ist ebenfalls unterschiedlich. Die Version vor 1.11 verwendet kubeDNS und die neuere Version verwendet coredns. Die Namensauflösung des Dienstes hängt vom DNS-Anhang ab, daher muss er bereitgestellt werden Nachdem k8s bereitgestellt wurde, muss sich kubernetes auf Netzwerk-Plug-Ins von Drittanbietern (Flanell, Calico usw.) verlassen, um Clients Netzwerkfunktionen (z. B. IP-Zuweisung) bereitzustellen. Jeder K8s-Knoten hat eine Komponente namens kube-proxy. Diese Komponente von kube-proxy überwacht immer die Änderungsinformationen zu Dienstressourcen im API-Server. Sie muss mit dem API-Server auf dem Master interagieren und sich jederzeit mit dem API-Server verbinden Abrufen eines Ressourcenänderungsstatus in Bezug auf Dienstressourcen, der durch eine in Kubernetes inhärente Anforderungsmethode Überwachung (Überwachung) realisiert wird Sobald sich der Inhalt von Dienstressourcen ändert (z. B. Erstellung, Löschung), wird die Operation in etcd gespeichert. und planen Sie dann unsere Anforderungen an die Regeln für die Backend-spezifischen Pod-Ressourcen. Diese Regel kann iptables oder ipvs sein, je nachdem, wie der Dienst implementiert ist (Sie können die Regeln selbst konfigurieren). Wenn beispielsweise ein neuer SVC erstellt wird, hat der SVC eine IP-Adresse, und das Netzwerksegment dieser IP-Adresse wird konfiguriert, wenn der Cluster erstellt wird (der Standardwert ist 10).

Wie Dienst funktioniert

Wenn k8s einen Dienst erstellt, sucht es den Pod gemäß dem Label-Selektor (Label-Selektor) und erstellt entsprechend ein Endpunktobjekt mit demselben Namen wie der Dienst. Wenn sich die Pod-Adresse ändert, ändert sich auch der Endpunkt und der Der Dienst empfängt die Front-End-Client-Anforderung. Wenn , findet er die Adresse des weiterzuleitenden Pods für den Zugriff über den Endpunkt. (Der Pod, der an welchen Knoten weitergeleitet wird, wird vom Load-Balancing-Kube-Proxy bestimmt.)

[root@k8smaster node]# kubectl get endpoints
NAME         ENDPOINTS             AGE
kubernetes   192.168.11.139:6443   15d
[root@k8smaster node]# kubectl get pods -n kube-system -o wide
NAME                                READY   STATUS    RESTARTS   AGE   IP               NODE     
kube-apiserver-k8smaster            1/1     Running   4          15d   192.168.11.139   k8smaster 
apiserver是绑定了宿主机的网络ip,apiserver这个pod,封装的k8sapiservice服务端口是443,这个service关联的pod是apiserver,ednpoints列表里编写的也是apiserverpod的ip和端口

Es gibt drei Arten von IP-Adressen in einem Kubernetes-Cluster

1、Node Network(节点网络):物理节点或者虚拟节点的网络,如 ens33 接口上的网路地址
[root@k8smaster node]# ip addr
ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:0c:29:94:59:0f brd ff:ff:ff:ff:ff:ff
    inet 192.168.11.139/24 brd 192.168.11.255 scope global noprefixroute dynamic ens3

2、Pod network(pod 网络),创建的 Pod 具有的 IP 地址 
[root@k8smaster node]#  kubectl get pods -o wide
NAME                        READY   STATUS    RESTARTS   AGE   IP            NODE       NOMINATED NODE  
frontend-d5tr9              1/1     Running   0          23h   10.244.2.30   k8snode    <none>          
Node Network 和 Pod network 这两种网络地址是我们实实在在配置的,其中节点网络地址是配置在节点接口之上,而 pod 网络地址是配置在 pod 资源之上的,因此这些地址都是配置在某些设备之上的,这些设备可能是硬件,也可能是软件模拟的 
 
3、Cluster Network(集群地址,也称为 service network),这个地址是虚拟的地址(virtual ip),没有配置在某个接口上,只是出现在 service 的规则当中。 
[root@xianchaomaster1 ~]# kubectl get svc 
[root@k8smaster node]# kubectl get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   15d

am Ende schreiben

Es ist nicht einfach zu erstellen, wenn Sie der Meinung sind, dass der Inhalt für Sie hilfreich ist, geben Sie mir bitte einen Drei-Link-Follow, um mich zu unterstützen! Wenn es Fehler gibt, weist sie bitte in den Kommentaren darauf hin und ich werde sie rechtzeitig ändern!
Die Serie, die gerade aktualisiert wird: k8s von Grund auf neu lernen.
Danke fürs Zuschauen. Der Artikel ist mit persönlichem Verständnis gemischt. Wenn es einen Fehler gibt, kontaktieren Sie mich bitte und weisen Sie darauf hin~
Bildbeschreibung hier einfügen

Ich denke du magst

Origin blog.csdn.net/qq_45400861/article/details/126659678
Empfohlen
Rangfolge