Постановочные и производственные маршруты, конфликтующие друг с другом - PullRequest
Новая
       6

Постановочные и производственные маршруты, конфликтующие друг с другом

0 голосов
/ 10 апреля 2020

Вчера я тестировал одновременное выполнение производственного и промежуточного развертывания. Результаты, которые я получил, были ошибочными c в том, что иногда вы добавляете go к промежуточному URL, и он загружает продукт. Если вы обновите страницу, она будет переключаться между ними случайным образом.

У меня не будет времени протестировать ее до этих выходных, потому что QA продолжается, и эта проблема не позволяет ему случиться. Я убил производственное развертывание и удалил маршруты из моего ingress.yaml, чтобы QA мог продолжить работу без проблем.

Во всяком случае, моя конфигурация ingress.yaml была вероятной причиной, поэтому хотел поделиться ею, чтобы увидеть, что вызвало это поведение: 

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/add-base-url: "true"
    nginx.ingress.kubernetes.io/rewrite-target: /$1
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/proxy-body-size: "0"
    nginx.org/client-max-body-size: "500m"
    nginx.ingress.kubernetes.io/use-regex: "true"
  name: ingress-service
  namespace: default
spec:
  tls:
    - hosts:
        - domain.com
        - www.domain.com
        - staging.domain.com
      secretName: tls-domain-com
  rules:
    - host: domain.com
      http:
        paths:
          - path: /?(.*)
            backend:
              serviceName: client-cluster-ip-service-prod
              servicePort: 3000
          - path: /admin/?(.*)
            backend:
              serviceName: admin-cluster-ip-service-prod
              servicePort: 4000
          - path: /api/?(.*)
            backend:
              serviceName: api-cluster-ip-service-prod
              servicePort: 5000
    - host: www.domain.com
      http:
        paths:
          - path: /?(.*)
            backend:
              serviceName: client-cluster-ip-service-prod
              servicePort: 3000
          - path: /admin/?(.*)
            backend:
              serviceName: admin-cluster-ip-service-prod
              servicePort: 4000
          - path: /api/?(.*)
            backend:
              serviceName: api-cluster-ip-service-prod
              servicePort: 5000
    - host: staging.domain.com
      http:
        paths:
          - path: /?(.*)
            backend:
              serviceName: client-cluster-ip-service-staging
              servicePort: 3000
          - path: /admin/?(.*)
            backend:
              serviceName: admin-cluster-ip-service-staging
              servicePort: 4000
          - path: /api/?(.*)
            backend:
              serviceName: api-cluster-ip-service-staging
              servicePort: 5000

Я чувствую, что это одно из следующего:

  • Наличие domain.com перед остальными и что оно должно быть в конце
  • Теперь, когда я снова смотрю на них, они имеют один и тот же IP-адрес и используют одни и те же порты, поэтому порты необходимо изменить
  • Если я хочу оставить порты одинаковыми, я ' Потребуется развернуть другой входной контроллер, имеющий один для подготовки и один для производства, и следуйте этим инструкциям

В любом случае, кто-нибудь может подтвердить?

РЕДАКТИРОВАТЬ

Добавление .yaml: 

# client-staging.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: client-deployment-staging
spec:
  replicas: 3
  selector:
    matchLabels:
      component: client
  template:
    metadata:
      labels:
        component: client
    spec:
      containers:
        - name: client
          image: testappacr.azurecr.io/test-app-client
          ports:
            - containerPort: 3000
          env:
          - name: DOMAIN
            valueFrom:
              secretKeyRef:
                name: test-app-staging-secrets
                key: DOMAIN 
---
apiVersion: v1
kind: Service
metadata:
  name: client-cluster-ip-service-staging
spec:
  type: ClusterIP
  selector:
    component: client
  ports:
    - port: 3000
      targetPort: 3000

# client-prod.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: client-deployment-prod
spec:
  replicas: 3
  selector:
    matchLabels:
      component: client
  template:
    metadata:
      labels:
        component: client
    spec:
      containers:
        - name: client
          image: testappacr.azurecr.io/test-app-client
          ports:
            - containerPort: 3000
          env:
          - name: DOMAIN
            valueFrom:
              secretKeyRef:
                name: test-app-prod-secrets
                key: DOMAIN 

---
apiVersion: v1
kind: Service
metadata:
  name: client-cluster-ip-service-prod
spec:
  type: ClusterIP
  selector:
    component: client
  ports:
    - port: 3000
      targetPort: 3000

1 Ответ

2 голосов
/ 10 апреля 2020

Не видя дескрипторов yaml развертываний и описания проблемы, наиболее вероятной причиной является то, что оба развертывания попадают в конечные точки службы loadbalancers, поэтому необходимо изменить селекторы и добавить что-то вроде: env: prod и env: staging и добавьте их в каждое развертывание.

Чтобы проверить, является ли это проблемой, запустите kubectl describe service для каждой службы и проверьте конечные точки.

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

РЕДАКТИРОВАТЬ: Изменения в файлах после их публикации:

Производство

Служба: 

spec:
  type: ClusterIP
  selector:
    component: client
    environment: production

Развертывание: 

  replicas: 3
  selector:
    matchLabels:
      component: client
      environment: production
  template:
    metadata:
      labels:
        component: client
        environment: production

Staging

Служба: 

spec:
  type: ClusterIP
  selector:
    component: client
    environment: staging

Развертывание: 

  replicas: 3
  selector:
    matchLabels:
      component: client
      environment: staging
  template:
    metadata:
      labels:
        component: client
        environment: staging
...