Получение 403 Forbidden от envoy при попытке скручивания между модулями с включенной коляской

Я использую установку Kubernetes / Istio, и мой список подов и сервисов приведен ниже:

NAME                                                READY     STATUS    RESTARTS   AGE
hr--debug-deployment-86575cffb6-wl6rx               2/2       Running   0          33m
hr--hr-deployment-596946948d-jrd7g                  2/2       Running   0          33m

NAME                             TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)             AGE
hr--debug-service                ClusterIP   10.104.160.61    <none>        80/TCP              33m
hr--hr-service                   ClusterIP   10.102.117.177   <none>        80/TCP              33m

Пытаюсь свернуться в hr--hr-service из hr--debug-deployment-86575cffb6-wl6rx

pasan@ubuntu:~/product-vick$ kubectl exec -it hr--debug-deployment-86575cffb6-wl6rx /bin/bash
Defaulting container name to debug.
Use 'kubectl describe pod/hr--debug-deployment-86575cffb6-wl6rx -n default' to see all of the containers in this pod.
root@hr--debug-deployment-86575cffb6-wl6rx:/# curl hr--hr-service -v
* Rebuilt URL to: hr--hr-service/
*   Trying 10.102.117.177...
* Connected to hr--hr-service (10.102.117.177) port 80 (#0)
> GET / HTTP/1.1
> Host: hr--hr-service
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 403 Forbidden
< date: Thu, 03 Jan 2019 04:06:17 GMT
< server: envoy
< content-length: 0
<
* Connection #0 to host hr--hr-service left intact

Не могли бы вы объяснить, почему я получаю сообщение 403, запрещенное посланником, и как я могу устранить его?

kubernetes http-status-code-403 istio envoyproxy

03.01.2019 05:17

Развертывание модели машинного обучения с помощью Flask - Angular в Kubernetes

Kubernetes - это портативная, расширяемая платформа с открытым исходным кодом для управления контейнерными рабочими нагрузками и сервисами, которая...

1 510

Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

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

Вы также можете попробовать отключить аутентификацию между вашими службами для отладки. Примерно так (если ваша политика определена так):

apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
  name: "hr--hr-service"
spec:
  targets:
  - name: hr--hr-service
  peers:
  - mTLS:
      mode: PERMISSIVE

В моем сценарии 403 был выпущен самой службой, и посланник просто повторил это. Поэтому я хотел бы добавить это как еще один возможный сценарий ошибки 403.

— 03.01.2019 17:23

03.01.2019 06:34