Perché k8s wordpress e mysql example utilizzano il servizio headless per wordpress-mysql?

Question

L'esempio è descritto qui: https://kubernetes.io/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/

L'oggetto Service per wordpress-mysql è:

apiVersion: v1
kind: Service
metadata:
  name: wordpress-mysql
  labels:
    app: wordpress
spec:
  ports:
    - port: 3306
  selector:
    app: wordpress
    tier: mysql
  clusterIP: None

I servizi headless sono documentati qui - https://kubernetes.io/docs/concepts/services-networking/service/#headless-servicesLa definizione del servizio definisce i selettori, quindi suppongo che si applichi il seguente passaggio :

Per i servizi headless che definiscono i selettori, il controller degli endpoint crea i record degli endpoint nell'API e modifica la configurazione DNS per restituire i record (indirizzi) che puntano direttamente ai pod che supportano il servizio

Ho seguito l'esempio su un cluster k8s gestito a 3 nodi in Azure:

C:\work\k8s\mysql-wp-demo> kubectl.exe get ep
NAME              ENDPOINTS          AGE
kubernetes        52.186.94.71:443   47h
wordpress         10.244.0.10:80     5h33m
wordpress-mysql   10.244.3.28:3306   5h33m
C:\work\k8s\mysql-wp-demo> kubectl.exe get pods -o wide
NAME                               READY   STATUS    RESTARTS   AGE     IP            NODE                                NOMINATED NODE   READINESS GATES
wordpress-584f8d8666-rlbf5         1/1     Running   0          5h33m   10.244.0.10   aks-nodepool1-30294001-vmss000001   <none>           <none>
wordpress-mysql-55c74969cd-4l8d4   1/1     Running   0          5h33m   10.244.3.28   aks-nodepool1-30294001-vmss000003   <none>           <none>
C:\work\k8s\mysql-wp-demo>

Per quanto ne so non c'è differenza dal punto di vista degli endpoint.

Qualcuno può spiegarmi: qual è lo scopo dei servizi senza testa in generale e in questo esempio in particolare?

Answer 1

Un servizio regolare ha un IP del servizio virtuale che esiste come regole iptables o ipvs su ogni nodo. Una nuova connessione a questo IP del servizio viene quindi instradata con DNAT a uno degli endpoint Pod, per supportare una forma di bilanciamento del carico su più pod.

Un servizio headless (che non è un ExternalName) creerà Arecord DNS per tutti gli endpoint con etichette o nomi corrispondenti. Le connessioni andranno direttamente a un singolo pod / endpoint senza attraversare le regole del servizio.

Un servizio con un tipo di ExternalNameè solo un CNAMErecord DNS nel DNS kubernetes. Questi sono headless per definizione in quanto sono nomi per un IP esterno al cluster.

L'esempio di distribuzione / servizio myql collegato porta a StatefulSet. Questa distribuzione è fondamentalmente un singolo pod statefulset. Quando ti sposti in uno StatefulSet con più pod, per lo più vorrai indirizzare i singoli membri dello StatefulSet con un nome specifico (vedi il commento di mdaniel ).

Un altro motivo per impostare clusterIP: Noneè diminuire il carico sull'elaborazione di iptables che rallenta all'aumentare del numero di servizi (cioè le regole di iptables). Le applicazioni che non richiedono più pod, non richiedono l'IP del servizio. L'impostazione di un cluster per utilizzare IPVS allevia in qualche modo il problema del rallentamento.