Связь между модулем посланника и модулем внутри службы в K8

Можно ли отправить HTTP-запрос на отдых другому модулю K8, который принадлежит той же службе в Kubernetes, когда настроен Envoy?

Важно: у меня есть еще один вопрос, здесь, который побудил меня спросить с конкретными тегами Envoy.

E. G. Имя службы = UserService, 2 модуля (реплика = 2)

Pod 1 --> Pod 2 //using pod ip not load balanced hostname 
Pod 2 --> Pod 1

Соединение прервано Осталось GET 1.2.3.4:7079/user/1

Значение для хоста + порта взято из kubectl get ep

Оба IP-адреса модуля успешно работают вне модулей, но когда я делаю kubectl exec -it в модуль и делаю запрос через CURL, он возвращает 404, не найденный для конечной точки.

В Что я хотел бы знать, можно ли отправить запрос другому модулю K8, который находится в той же службе? Ответил: однозначно возможно.

В Почему я могу получить ping 1.2.3.4 успешно, но не попадаю в Rest API?

В можно ли напрямую запросить IP-адрес модуля у другого модуля при настройке Envoy?

Пожалуйста, дайте мне знать, какие конфигурационные файлы необходимы или какие выходные данные необходимы для прогресса, так как я полный новичок с K8. Спасибо.

ниже мои файлы конфигурации

 #values.yml
replicaCount: 1

 image:
  repository: "docker.hosted/app"
  tag: "0.1.0"
  pullPolicy: Always
  pullSecret: "a_secret"

service:
 name: http
 type: NodePort
 externalPort: 7079
 internalPort: 7079

ingress:
 enabled: false

развертывание.yml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: {{ template "app.fullname" . }}
  labels:
    app: {{ template "app.name" . }}
    chart: {{ .Chart.Name }}-{{ .Chart.Version | replace "+" "_" }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    metadata:
      labels:
        app: {{ template "app.name" . }}
        release: {{ .Release.Name }}
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          imagePullPolicy: {{ .Values.image.pullPolicy }}
          env:

            - name: MY_POD_IP
              valueFrom:
               fieldRef:
                fieldPath: status.podIP
            - name: MY_POD_PORT
              value: "{{ .Values.service.internalPort }}"
          ports:
            - containerPort: {{ .Values.service.internalPort }}
          livenessProbe:
            httpGet:
              path: /actuator/alive
              port: {{ .Values.service.internalPort }}
            initialDelaySeconds: 60
            periodSeconds: 10
            timeoutSeconds: 1
            successThreshold: 1
            failureThreshold: 3
          readinessProbe:
            httpGet:
              path: /actuator/ready
              port: {{ .Values.service.internalPort }}
          initialDelaySeconds: 60
          periodSeconds: 10
          timeoutSeconds: 1
          successThreshold: 1
          failureThreshold: 3
          resources:
{{ toYaml .Values.resources | indent 12 }}
    {{- if .Values.nodeSelector }}
      nodeSelector:
{{ toYaml .Values.nodeSelector | indent 8 }}
    {{- end }}
      imagePullSecrets:
        - name: {{ .Values.image.pullSecret }

service.yml

kind: Service
metadata:
  name: {{ template "app.fullname" . }}
  labels:
    app: {{ template "app.name" . }}
    chart: {{ .Chart.Name }}-{{ .Chart.Version | replace "+" "_" }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
spec:
  type: {{ .Values.service.type }}
  ports:
    - port: {{ .Values.service.externalPort }}
      targetPort: {{ .Values.service.internalPort }}
      protocol: TCP
      name: {{ .Values.service.name }}
  selector:
    app: {{ template "app.name" . }}
    release: {{ .Release.Name }}

выполнен от мастера

выполняется из модуля той же MicroService

ИЗМЕНИТЬ 2: вывод "kubectl get -o yaml deployment"

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "1"
  creationTimestamp: 2019-01-29T20:34:36Z
  generation: 1
  labels:
    app: msg-messaging-room
    chart: msg-messaging-room-0.0.22
    heritage: Tiller
    release: msg-messaging-room
  name: msg-messaging-room
  namespace: default
  resourceVersion: "25447023"
  selfLink: /apis/extensions/v1beta1/namespaces/default/deployments/msg-messaging-room
  uid: 4b283304-2405-11e9-abb9-000c29c7d15c
spec:
  progressDeadlineSeconds: 600
  replicas: 2
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: msg-messaging-room
      release: msg-messaging-room
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: msg-messaging-room
        release: msg-messaging-room
    spec:
      containers:
      - env:
        - name: KAFKA_HOST
          value: confluent-kafka-cp-kafka-headless
        - name: KAFKA_PORT
          value: "9092"
        - name: MY_POD_IP
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: status.podIP
        - name: MY_POD_PORT
          value: "7079"
        image: msg-messaging-room:0.0.22
        imagePullPolicy: Always
        livenessProbe:
          failureThreshold: 3
          httpGet:
            path: /actuator/alive
            port: 7079
            scheme: HTTP
          initialDelaySeconds: 60
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 1
        name: msg-messaging-room
        ports:
        - containerPort: 7079
          protocol: TCP
        readinessProbe:
          failureThreshold: 3
          httpGet:
            path: /actuator/ready
            port: 7079
            scheme: HTTP
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 1
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      imagePullSecrets:
      - name: secret
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
status:
  availableReplicas: 2
  conditions:
  - lastTransitionTime: 2019-01-29T20:35:43Z
    lastUpdateTime: 2019-01-29T20:35:43Z
    message: Deployment has minimum availability.
    reason: MinimumReplicasAvailable
    status: "True"
    type: Available
  - lastTransitionTime: 2019-01-29T20:34:36Z
    lastUpdateTime: 2019-01-29T20:36:01Z
    message: ReplicaSet "msg-messaging-room-6f49b5df59" has successfully progressed.
    reason: NewReplicaSetAvailable
    status: "True"
    type: Progressing
  observedGeneration: 1
  readyReplicas: 2
  replicas: 2
  updatedReplicas: 2

вывод из "kubectl get -o yaml svc $ the_service"

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: 2019-01-29T20:34:36Z
  labels:
    app: msg-messaging-room
    chart: msg-messaging-room-0.0.22
    heritage: Tiller
    release: msg-messaging-room
  name: msg-messaging-room
  namespace: default
  resourceVersion: "25446807"
  selfLink: /api/v1/namespaces/default/services/msg-messaging-room
  uid: 4b24bd84-2405-11e9-abb9-000c29c7d15c
spec:
  clusterIP: 1.2.3.172.201
  externalTrafficPolicy: Cluster
  ports:
  - name: http
    nodePort: 31849
    port: 7079
    protocol: TCP
    targetPort: 7079
  selector:
    app: msg-messaging-room
    release: msg-messaging-room
  sessionAffinity: None
  type: NodePort
status:
  loadBalancer: {}

M_K 30.01.2019 источник

comment

Вы, вероятно, захотите включить свою конфигурацию envoy, а предоставление шаблона helm бесполезно, поскольку имеет значение, какие фактические значения были вставлены в эти файлы; ты захочешь kubectl get -o yaml deployment $whatever и его -o yaml svc $the_service друга - mdaniel 30.01.2019

Ответы (2)

arrow_upward
1
arrow_downward

Что я опубликовал по другому вопросу, так это то, что я отключил инъекцию Istio перед установкой службы, а затем снова включил ее после установки службы, и теперь все работает нормально, поэтому команды, которые сработали для меня, были:

M_K 20.02.2019

comment

Таким образом, если модуль будет перезапущен, он снова получит свою коляску. Мне это не кажется подходящим решением, если я не упускаю здесь какую-то часть? - TheDiveO; 12.11.2019

arrow_upward
0
arrow_downward

Для части Pod to Pod:

Добавление другой службы (без головы) позволит вам получить доступ к другому модулю через curl, при этом Istio все еще включена.

Например, добавив

kind: Service
metadata:
  name: {{ template "app.fullname" . }}-headless
  labels:
  ... [same as other service]
spec:
  clusterIP: None
  ... [same as other service]

В качестве безголовой службы предоставляет Pod'ы в качестве конечных точек, а не свой собственный clusterIP.

Если вам не нужна балансировка нагрузки, вы можете просто использовать безголовый сервис, но если вам нужны оба, вы можете использовать первый сервис для внешнего трафика и безголовый для связи между модулями.

char 10.04.2020