Многоуровневый конфликт в Kubernetes - PullRequest
Новая
       45

Многоуровневый конфликт в Kubernetes

0 голосов
/ 05 декабря 2018

Я новичок в Кубернетесе.Я создал кластер Kubernetes на Amazon EKS .Я пытаюсь настроить несколько служб kubernetes для запуска нескольких приложений ASP.NET в одном кластере.Но столкнулся со странной проблемой.

Все работает нормально, когда есть только 1 сервис.Но всякий раз, когда я создаю второй сервис для второго приложения, это создает конфликт.Конфликт иногда возникает из-за того, что приложение-служба загрузки URL-адресов 1 загружает приложение 2, а иногда оно загружает приложение службы 1, и то же самое происходит с URL-адресом службы 2 при простой перезагрузке страницы.

Я пробовал оба варианта Amazon Classic ELB (с LoadBalancer Service Type)и входной контроллер Nginx (с типом службы ClusterIp).Эта ошибка характерна для обоих подходов.

Службы и развертывания работают на порте 80, я даже пробовал разные порты для служб и развертываний, чтобы избежать конфликта портов, но та же проблема.

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

Пожалуйста, укажите, как я могу исправить эту ошибку.Вот файл yaml обоих сервисов для nginx ingress 

# Service 1 for deployment 1 (container port: 1120)
apiVersion: v1
kind: Service
metadata:
  creationTimestamp: 2018-12-05T14:54:21Z
  labels:
    run: load-balancer-example
  name: app1-svc
  namespace: default
  resourceVersion: "463919"
  selfLink: /api/v1/namespaces/default/services/app1-svc
  uid: a*****-****-****-****-**********c
spec:
  clusterIP: 10.100.102.224
  ports:
  - port: 1120
    protocol: TCP
    targetPort: 1120
  selector:
    run: load-balancer-example
  sessionAffinity: None
  type: ClusterIP
status:
  loadBalancer: {}

2-й сервис 

# Service 2 for deployment 2 (container port: 80)
apiVersion: v1
kind: Service
metadata:
  creationTimestamp: 2018-12-05T10:13:33Z
  labels:
    run: load-balancer-example
  name: app2-svc
  namespace: default
  resourceVersion: "437188"
  selfLink: /api/v1/namespaces/default/services/app2-svc
  uid: 6******-****-****-****-************0
spec:
  clusterIP: 10.100.65.46
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: load-balancer-example
  sessionAffinity: None
  type: ClusterIP
status:
  loadBalancer: {}

Спасибо

1 Ответ

0 голосов
/ 05 декабря 2018

Проблема с селектором в сервисах.У них обоих одинаковый селектор , и именно поэтому вы столкнулись с этой проблемой.Таким образом, они оба будут указывать на один и тот же набор модулей.

Набор модулей, на которые ориентирована служба, (обычно) определяется селектором меток

С момента развертывания 1 иРазвертывание 2 отличается (я думаю), вы должны использовать другой селектор в них.Затем выставьте развертывания.Например: 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.15.4
        ports:
        - containerPort: 80

- 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-deployment
  labels:
    app: hello
spec:
  replicas: 3
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
    spec:
      containers:
      - name: hello
        image: nightfury1204/hello_server
        args:
        - serve
        ports:
        - containerPort: 8080

Над двумя развертываниями nginx-deployment и hello-deployment имеют разные селекторы.Поэтому предоставление их службе не будет противоречить друг другу.

Когда вы используете kubectl expose deployment app1-deployment --type=ClusterIP --name=app1-svc для предоставления развертывания, служба будет иметь тот же селектор, что и развертывание.

...