Kubernetes hizmeti, atanan bağlantı noktasından farklı bağlantı noktasında yanıt veriyor

Dec 16 2020

Birkaç hizmet dağıttım ve bir hizmetin diğerlerinden farklı davrandığını gördüm. Onu 8090 bağlantı noktasını dinleyecek şekilde yapılandırdım (dahili olarak 8443 ile eşleşir), ancak istek yalnızca 8080 bağlantı noktasından gönderirsem çalışır. İşte hizmet için yaml dosyam (esaslara indirgenmiştir) ve hizmeti kapsayan bir dağıtım var ve konteyner

apiVersion: v1
kind: Service
metadata:
  name: uisvc
  namespace: default
  labels:
    helm.sh/chart: foo-1
    app.kubernetes.io/name: foo
    app.kubernetes.io/instance: rb-foo
spec:
  clusterIP: None
  ports:
    - name: http
      port: 8090
      targetPort: 8080
  selector:
    app.kubernetes.io/component: uisvc

Dümeni kurduktan sonra çalıştırdığımda kubectl get svcaşağıdaki çıktıyı alıyorum

fooaccess       ClusterIP   None         <none>        8888/TCP   119m
fooset          ClusterIP   None         <none>        8080/TCP   119m
foobus          ClusterIP   None         <none>        6379/TCP   119m
uisvc           ClusterIP   None         <none>        8090/TCP   119m

Ancak, çalışan diğer konteynerlerden birine ssh attığımda ve 8090'da bir curl isteği yaptığımda, "Bağlantı reddedildi" mesajı alıyorum. "Http: // uisvc: 8080" ile kıvrılırsam, doğru yanıtı alıyorum. Konteyner, varsayılan olarak 8080'i dinleyen bir yaylı önyükleme uygulaması çalıştırıyor. Bulabildiğim tek açıklama, bağlantı noktası / targetPort'un bir şekilde bu yapılandırmada göz ardı edilmesi ve diğer bölmelerin içerideki yay hizmetine doğrudan ulaşması.

Bu davranış doğru mu? Neden 8090'da dinlemiyor? Nasıl bu şekilde çalıştırmalıyım?

Düzenleme: Çıktı kubectl describe svc uisvc

Name:              uisvc
Namespace:         default
Labels:            app.kubernetes.io/instance=foo-rba
                   app.kubernetes.io/managed-by=Helm
                   app.kubernetes.io/name=rba
                   helm.sh/chart=rba-1
Annotations:       meta.helm.sh/release-name: foo
                   meta.helm.sh/release-namespace: default
Selector:          app.kubernetes.io/component=uisvc
Type:              ClusterIP
IP:                None
Port:              http  8090/TCP
TargetPort:        8080/TCP
Endpoints:         172.17.0.8:8080
Session Affinity:  None
Events:            <none>

Yanıtlar

1 thomas Dec 16 2020 at 20:39

Bu, kullandığınızdan beri beklenen bir davranıştır headless service.

Başsız Hizmetleri servis keşif mekanizması böylece yerine tek döndürmek için kullanılacak DNS A records, DNS serverçoklu dönecektir A recordsbireysel bölmelerin IP o sırtları hizmet için hizmet için her işaret. Böylece, basit bir DNS A recordsarama yapar ve hizmetin parçası olan tüm bölmelerin IP'sini alırsınız.

Yana headless serviceyaratmaz iptableskuralları ancak yaratır dns recordsyerine, kendi pod yerine bir proxy ile doğrudan etkileşime girebilir. Yani eğer çözerseniz <servicename:port>, alacaksınız <podN_IP:port>ve ardından bağlantınız doğrudan bölmeye gidecek. Tüm bunlar aynı ad alanında olduğu sürece, tam DNS adıyla çözemezsiniz.

Birkaç bölmeyle, DNS size hepsini verir ve yalnızca rastgele sıraya (veya RR sırasına göre) yerleştirir. Sıra, DNS sunucusu uygulamasına ve ayarlarına bağlıdır.