入口在从Skaffold迁移到DevSpace和组件图表后不起作用

Question

我一直在玩弄DevSpace的Helm图表，并可能从Skaffold和Kubernetes清单迁移到它。我似乎无法让入口控制器为本地开发工作:带着404 Not Found回来。不过，我可以通过端口转发到达localhost:3000.

就像我一直做的一样，我首先为installed the ingress-nginx controller docker-desktop做了以下工作：

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.0.0/deploy/static/provider/cloud/deploy.yaml

然后，在我的devspace.yaml中，我有以下内容：

version: v1beta10

images:
  client:
    image: app/client
    dockerfile: client/Dockerfile
    context: client/

deployments:
- name: client
  helm:
    componentChart: true
    values:
      containers:
      - image: app/client
      service:
        ports:
          - port: 3000
      ingress:
        name: ingress
        rules: 
        - host: localhost
          path: /
          pathType: Prefix
          servicePort: 3000
          serviceName: client
dev:
  ports:
  - name: client
    imageSelector: app/client
    forward:
    - port: 3000
      remotePort: 3000
  sync:
  - name: client
    imageSelector: app/client
    localSubPath: ./client
    excludePaths: 
    - .git/
    - node_modules/

对于这两种配置，Dockerfile是相同的。

FROM node:14-alpine
WORKDIR /app
COPY ./package.json ./
ENV CI=true
RUN npm install
COPY . .
EXPOSE 3000
CMD ["npm", "start"]

此外，我在添加服务(例如/api、/admin等)时注意到了这一点。使用相应的ingress.rules，它为每个服务创建入口，而不是为整个应用程序创建一个入口。

作为参考，这是我以前对skaffold和清单所做的：

# ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: "nginx"
  name: ingress-dev
spec:
  rules:
    - host: localhost
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: client-cluster-ip-service-dev
                port:
                  number: 3000

# client.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: client-deployment-dev
spec:
  replicas: 1
  revisionHistoryLimit: 5
  selector:
    matchLabels:
      component: client
      environment: development
  template:
    metadata:
      labels:
        component: client
        environment: development
    spec:
      containers:
        - name: client
          image: client
          ports:
            - containerPort: 3000
---
apiVersion: v1
kind: Service
metadata:
  name: client-cluster-ip-service-dev
spec:
  type: ClusterIP
  selector:
    component: client
    environment: development
  ports:
    - port: 3000
      targetPort: 3000

# skaffold.yaml
apiVersion: skaffold/v2beta1
kind: Config
build:
  artifacts:
  - image: client
    context: client
    sync:
      manual:
      - src: 'src/**/*.js'
        dest: .
      - src: 'src/**/*.jsx'
        dest: .
      - src: 'package.json'
        dest: .
      - src: 'public/**/*.html'
        dest: .
      - src: 'src/assets/sass/**/*.scss'
        dest: .
      - src: 'src/build/**/*.js'
        dest: .
    docker:
      dockerfile: Dockerfile.dev
  local:
    push: false
deploy:
  kubectl:
    manifests:
      - k8s/ingress.yaml 
      - k8s/client.yaml

我更喜欢在开发期间使用ingress控制器，而不是端口转发。这样我就可以去localhost/，localhost/admin，localhost/api等等。我以前遇到过严重的错误，之前没有使用端口转发，而是使用入口控制器，所以我就是不信任它。

关于下列问题的任何建议：

使入口工作，使其到达service?

• Setting上的devspace.yaml，以便为每个服务创建一个入口而不是一个入口？

The devspace render

---
# Source: component-chart/templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: "client"
  labels:
    "app.kubernetes.io/name": "client"
    "app.kubernetes.io/managed-by": "Helm"
  annotations:
    "helm.sh/chart": "component-chart-0.8.2"
spec:
  externalIPs:
  ports:
    - name: "port-0"
      port: 3000
      targetPort: 3000
      protocol: "TCP"
  selector:
    "app.kubernetes.io/name": "devspace-app"
    "app.kubernetes.io/component": "client"
  type: "ClusterIP"
---
# Source: component-chart/templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: "client"
  labels:
    "app.kubernetes.io/name": "devspace-app"
    "app.kubernetes.io/component": "client"
    "app.kubernetes.io/managed-by": "Helm"
  annotations:
    "helm.sh/chart": "component-chart-0.8.2"
spec:
  replicas: 1
  strategy:
    type: Recreate
  selector:
    matchLabels:
      "app.kubernetes.io/name": "devspace-app"
      "app.kubernetes.io/component": "client"
      "app.kubernetes.io/managed-by": "Helm"
  template:
    metadata:
      labels:
        "app.kubernetes.io/name": "devspace-app"
        "app.kubernetes.io/component": "client"
        "app.kubernetes.io/managed-by": "Helm"
      annotations:
        "helm.sh/chart": "component-chart-0.8.2"
    spec:
      imagePullSecrets:
      nodeSelector:
        null
      nodeName:
        null
      affinity:
        null
      tolerations:
        null
      dnsConfig:
        null
      hostAliases:
        null
      overhead:
        null
      readinessGates:
        null
      securityContext:
        null
      topologySpreadConstraints:
        null
      terminationGracePeriodSeconds: 5
      ephemeralContainers:
        null
      containers:
        - image: "croner-app/client:AtrvTRR"
          name: "container-0"
          command:
          args:
          env:
            null
          envFrom:
            null
          securityContext:
            null
          lifecycle:
            null
          livenessProbe:
            null
          readinessProbe:
            null
          startupProbe:
            null
          volumeDevices:
            null
          volumeMounts:
      initContainers:
      volumes:
  volumeClaimTemplates:
---
# Source: component-chart/templates/ingress.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: "ingress"
  labels:
    "app.kubernetes.io/name": "client"
    "app.kubernetes.io/managed-by": "Helm"
  annotations:
    "helm.sh/chart": "component-chart-0.8.2"
spec:
  rules:
  - host: "localhost"
    http:
      paths:
      - backend:
          serviceName: client
          servicePort: 3000
        path: "/"
        pathType: "Prefix"
---

我能看到的最大区别是我过去使用的是apiVersion: networking.k8s.io/v1，而devspace使用的是apiVersion: extensions/v1beta1。也许我申请的入口控制器controller-v1.0.0不兼容？不确定..。

Answer 1

在这种特殊情况下，解决方案是使用与ingress-nginx使用的版本兼容的旧版本的DevSpace控制器。在我的例子中，我使用的是devspace v5.16.0-alpha.0，下面的控制器与它一起工作：

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v0.49.0/deploy/static/provider/cloud/deploy.yaml

由于此解决方案将随较新版本的devspace和ingress-nginx而改变，通常如下：

compatible.

• Check

• 确保ingress-nginx控制器版本和devspace版本是devspace render，以查看如何生成ingress配置，以及apiVersion是否与您kubectl apply.的入口控制器版本兼容。

Answer 2

要调试这一点，您可能需要运行devspace render，它显示了DevSpace在将它们部署到集群之前从Helm图表生成的普通清单。这样你就可以看到什么与你的骷髅有什么不同。或者，您可以使用以下命令在集群内进行检查：

kubectl get service --all -o yaml   # to see all services
kubectl get ingress --all -o yaml   # to see all ingresses

我对实际问题的猜测是:由于您使用的是componentChart: true，所以不应该为入口指定serviceName: client。我假设此serviceName与组件图表根据舵机部署的发布名生成的服务名称不匹配。因此，只需将serviceName: client从devspace.yaml中删除。或者，您可以为服务指定name: client以确保其匹配。

有关完整的组件图表规范，请参见文档：https://devspace.sh/component-chart/docs/configuration/reference