Skaffold 1.4.0: «Пропуск развертывания из-за ошибки syn c: копирование файлов:» - PullRequest
Новая
       30

Skaffold 1.4.0: «Пропуск развертывания из-за ошибки syn c: копирование файлов:»

0 голосов
/ 03 марта 2020

Использование:

  • Skaffold 1.4.0

  • minikube 1.6.2

  • kubectl : клиент 1.15.5 и сервер 1.17.0

  • Django 3.0.3

  • Python 3.8.2

Я только недавно начал получать эту ошибку, поскольку я работаю над Django API. Каждый раз, когда я сохраняю после внесения изменений, я получаю: 

WARN[0234] Skipping deploy due to sync error: copying files: Running [kubectl --context minikube exec api-deployment-6946878554-n7lc2 --namespace default -c api -i -- tar xmf - -C / --no-same-owner]
 - stdout: 
 - stderr: error: unable to upgrade connection: container not found ("api")
: exit status 1

Не уверен, что изменилось, чтобы вызвать это. Я должен сделать CTRL + C, чтобы выключить Skaffold и перезапустить его, чтобы изменения отразились.

Это мой skaffold.yaml: 

apiVersion: skaffold/v1beta15
kind: Config
build:
  local:
    push: false
  artifacts:
    - image: postgres
      context: postgres
      docker:
        dockerfile: Dockerfile.dev
      sync:
        manual:
          - src: "***/*.sql"
            dest: .
    - image: testappacr.azurecr.io/test-app-api
      context: api
      docker:
        dockerfile: Dockerfile.dev
      sync:
        manual:
          - src: "***/*.py"
            dest: .
deploy:
  kubectl:
    manifests:
      - manifests/dev-ingress.yaml 
      - manifests/postgres.yaml
      - manifests/api.yaml

Также api.yaml: 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      component: api
  template:
    metadata:
      labels:
        component: api
    spec:
      containers:
        - name: api
          image: testappacr.azurecr.io/test-app-api
          ports:
            - containerPort: 5000
          env:
            - name: PGUSER
              valueFrom:
                secretKeyRef:
                  name: test-app-secrets
                  key: PGUSER
            - name: PGHOST
              value: postgres-cluster-ip-service
            - name: PGPORT
              value: "1423"
            - name: PGDATABASE
              valueFrom:
                secretKeyRef:
                  name: test-app-secrets
                  key: PGDATABASE
            - name: PGPASSWORD
              valueFrom:
                secretKeyRef:
                  name: test-app-secrets
                  key: PGPASSWORD
            - name: SECRET_KEY
              valueFrom:
                secretKeyRef:
                  name: test-app-secrets
                  key: SECRET_KEY
            - name: DEBUG
              valueFrom:
                secretKeyRef:
                  name: test-app-secrets
                  key: DEBUG
          livenessProbe:
            tcpSocket:
              port: 5000
            initialDelaySeconds: 2
            periodSeconds: 2
          readinessProbe:
            tcpSocket:
              port: 5000
            initialDelaySeconds: 2
            periodSeconds: 2
          volumeMounts:
          - mountPath: "/mnt/test-app"
            name: file-storage
      volumes:
        - name: file-storage
          persistentVolumeClaim:
            claimName: file-storage
---
apiVersion: v1
kind: Service
metadata:
  name: api-cluster-ip-service
spec:
  type: ClusterIP
  selector:
    component: api
  ports:
    - port: 5000
      targetPort: 5000

Есть предложения о том, что здесь может происходить?

1 Ответ

1 голос
/ 13 марта 2020

Понял, проблема была вызвана моими readinessProbe и livenessProbe в api.yaml. 

          livenessProbe:
            tcpSocket:
              port: 5000
            initialDelaySeconds: 2
            periodSeconds: 2
          readinessProbe:
            tcpSocket:
              port: 5000
            initialDelaySeconds: 2
            periodSeconds: 2

Теперь я не получаю эту ошибку.

Однако, причина, по которой они у меня были там, была в первую очередь потому, что skaffold иногда загружает базу данных после API , в результате чего он потерпит неудачу. Так что в моем случае это компромисс: без probes БД иногда загружается после того, как API вызывает сбой или вызывает их, и это чаще приводит к ошибке, связанной с этим вопросом.

...