Тайм-аут в восходящем направлении (110: Тайм-аут соединения) на Kunbernetes Ingress - PullRequest
Новая
       12

Тайм-аут в восходящем направлении (110: Тайм-аут соединения) на Kunbernetes Ingress

0 голосов
/ 28 января 2019

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

---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: alpha-ingress
  annotations:
    kubernetes.io/ingress.class: nginx
    certmanager.k8s.io/cluster-issuer: letsencrypt-prod
spec:
  tls:
    - hosts:
        - alpha.example.com
      secretName: letsencrypt-prod
  rules:
    - host: alpha.example.com
      http:
        paths:
          - backend:
              serviceName: web
              servicePort: 80

В конечном итоге время ожидания браузера составляет 504ошибка и в журнале входа я вижу

2019/01/27 23:45:38 [ошибка] 41 # 41: * 4943 тайм-аут восходящего потока (110: тайм-аут соединения) при чтении заголовка ответаиз апстрима, клиент: 10.131.24.163, сервер: alpha.example.com, запрос: «GET / HTTP / 2.0», апстрим: «http://10.244.93.12:80/", хост:« alpha.example.com »

У меня нет никаких служб на этом IP-адресе ... 

╰─$ kgs --all-namespaces                                                                                                                                                                                                                                                  130 ↵
NAMESPACE       NAME                            TYPE           CLUSTER-IP       EXTERNAL-IP      PORT(S)                      AGE
default         database                        ClusterIP      10.245.181.187   <none>           5432/TCP                     4d8h
default         kubernetes                      ClusterIP      10.245.0.1       <none>           443/TCP                      9d
default         user-api                        ClusterIP      10.245.41.8      <none>           9000/TCP                     4d8h
default         web                             ClusterIP      10.245.145.213   <none>           80/TCP,443/TCP               34h
ingress-nginx   ingress-nginx                   LoadBalancer   10.245.25.107    <external-ip>   80:31680/TCP,443:32324/TCP   50m
kube-system     grafana                         ClusterIP      10.245.81.91     <none>           80/TCP                       6d1h
kube-system     kube-dns                        ClusterIP      10.245.0.10      <none>           53/UDP,53/TCP,9153/TCP       9d
kube-system     prometheus-alertmanager         ClusterIP      10.245.228.165   <none>           80/TCP                       6d2h
kube-system     prometheus-kube-state-metrics   ClusterIP      None             <none>           80/TCP                       6d2h
kube-system     prometheus-node-exporter        ClusterIP      None             <none>           9100/TCP                     6d2h
kube-system     prometheus-pushgateway          ClusterIP      10.245.147.195   <none>           9091/TCP                     6d2h
kube-system     prometheus-server               ClusterIP      10.245.202.186   <none>           80/TCP                       6d2h
kube-system     tiller-deploy                   ClusterIP      10.245.11.85     <none>           44134/TCP                    9d

Если я просматриваю файл resolv.conf на входном модуле, он возвращает то, что должен ... 

╰─$ keti -n ingress-nginx nginx-ingress-controller-c595c6896-klw25 -- cat /etc/resolv.conf                                                                                                                                                                                130 ↵
nameserver 10.245.0.10
search ingress-nginx.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

dig / nslookup / host не доступны в этом контейнере, но если я создаю простой экземпляр busybox, он получает правильный IP с той же конфигурацией: 

╰─$ keti busybox -- nslookup web
Server:    10.245.0.10
Address 1: 10.245.0.10 kube-dns.kube-system.svc.cluster.local

Name:      web
Address 1: 10.245.145.213 web.default.svc.cluster.local

Может кто-нибудь датьУ меня есть какие-либо идеи, что попробовать дальше?

Обновление # 1

Вот конфиг для web, как и было запрошено вКомментарии.Я также исследую, почему я не могу напрямую wget что-либо из web, используя busybox внутри кластера. 

apiVersion: v1
kind: Service
metadata:
  labels:
    io.kompose.service: web
    app: web
  name: web
spec:
  ports:
  - name: "80"
    port: 80
    targetPort: 80
  - name: "443"
    port: 443
    targetPort: 443
  selector:
    io.kompose.service: web
status:
  loadBalancer: {}
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    app: web
  name: web
spec:
  replicas: 1
  strategy:
    type: RollingUpdate
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        io.kompose.service: web
        app: web
    spec:
      containers:
      - image: <private docker repo>
        imagePullPolicy: IfNotPresent
        name: web
        resources: {}
      imagePullSecrets:
      - name: gcr
status: {}

Обновление 2

Asсогласно приведенному ниже комментарию Михаила, IP-адрес, разрешенный для web, является одной из конечных точек: 

╰─$ k get endpoints web                                                                                                                                                                                                                                                   130 ↵
NAME      ENDPOINTS                          AGE
web       10.244.93.12:443,10.244.93.12:80   2d

1 Ответ

0 голосов
/ 29 января 2019

Итак, все это сводится к тому, что у службы php-fpm нет конечных точек, потому что я неправильно настроил селектор служб!

Некоторые из более читателей с орлиными глазами могли заметить, что мой конфиг начал свою жизнькак преобразование из конфигурационного файла docker-compose (моя среда разработки), и я основывался на нем оттуда.

Проблема возникла из-за того, что я изменил метки и селектор для развертывания, а не службысам. 

apiVersion: v1
kind: Service
metadata:
  name: user-api
  labels:
    io.kompose.service: user-api
    app: user-api
spec:
  ports:
    - name: "9000"
      port: 9000
      targetPort: 9000
  selector:
    io.kompose.service: user-api
status:
  loadBalancer: {}
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    app: user-api
  name: user-api
spec:
  replicas: 1
  selector:
    matchLabels:
      app: user-api
  template:
    metadata:
      labels:
        app: user-api
    spec:
... etc

Вы видите, что я все еще использовал старый селектор, созданный для меня kompose, io.kompose.service: user-api вместо более нового app: user-api

Я последовал совету @coderangerв то время как служба nginx отвечала, php-fpm - нет.

Быстрый просмотр документации для Соединение приложений со службами говорит:

Как уже упоминалось ранее, Сервис поддерживается группой Стручков.Эти стручки выставляются через конечные точки.Селектор службы будет оцениваться непрерывно, а результаты будут помещены в объект конечных точек, также называемый my-nginx.

Когда я проверял селектор шаблона службы и шаблона развертывания, я увидел, что они разные.теперь они совпадают, и все работает, как ожидалось.

...