Dịch vụ Kubernetes phản hồi trên cổng khác với cổng được chỉ định

Dec 16 2020

Tôi đã triển khai một số dịch vụ và nhận thấy một dịch vụ hoạt động khác với những dịch vụ khác. Tôi đã định cấu hình nó để lắng nghe trên cổng 8090 (ánh xạ tới 8443 trong nội bộ), nhưng yêu cầu chỉ hoạt động nếu tôi gửi trên cổng 8080. Đây là tệp yaml của tôi cho dịch vụ (được rút xuống thành phần cần thiết) và có một triển khai đóng gói dịch vụ và thùng chứa

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

Sau khi cài đặt trình điều khiển, khi tôi chạy kubectl get svc, tôi nhận được kết quả sau

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

Tuy nhiên, khi tôi truy cập vào một trong các vùng chứa đang chạy khác và đưa ra yêu cầu cuộn vào 8090, tôi nhận được "Kết nối bị từ chối". Nếu tôi xoay thành "http: // uisvc: 8080", thì tôi đang nhận được phản hồi phù hợp. Vùng chứa đang chạy một ứng dụng khởi động mùa xuân theo mặc định sẽ lắng nghe trên 8080. Lời giải thích duy nhất mà tôi có thể đưa ra là bằng cách nào đó cổng / targetPort đang bị bỏ qua trong cấu hình này và các nhóm khác đang truy cập trực tiếp vào dịch vụ mùa xuân bên trong.

Hành vi này có đúng không? Tại sao nó không nghe trên 8090? Làm thế nào tôi nên làm cho nó hoạt động theo cách này?

Chỉnh sửa: Đầu ra cho 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>

Trả lời

1 thomas Dec 16 2020 at 20:39

Đây là hành vi mong đợi kể từ khi bạn sử dụng headless service.

Dịch vụ không đầu được sử dụng cho cơ chế khám phá dịch vụ, vì vậy thay vì trả về đơn lẻ DNS A records, DNS serversẽ trả về nhiều A recordscho dịch vụ của bạn, mỗi dịch vụ trỏ đến IP của một nhóm riêng lẻ hỗ trợ dịch vụ. Vì vậy, bạn thực hiện DNS A recordstra cứu đơn giản và lấy IP của tất cả các nhóm là một phần của dịch vụ.

Vì headless servicekhông tạo iptablesquy tắc mà dns recordsthay vào đó tạo nên bạn có thể tương tác trực tiếp với nhóm của mình thay vì proxy. Vì vậy, nếu bạn giải quyết, <servicename:port>bạn sẽ nhận được <podN_IP:port>và sau đó kết nối của bạn sẽ chuyển trực tiếp đến nhóm. Miễn là tất cả điều này nằm trong cùng một không gian tên, bạn không thể giải quyết nó bằng tên dns đầy đủ.

Với một số nhóm, DNS sẽ cung cấp cho bạn tất cả chúng và chỉ cần đặt theo thứ tự ngẫu nhiên (hoặc theo thứ tự RR). Thứ tự phụ thuộc vào cài đặt và triển khai máy chủ DNS.