Welcome to the Linux Foundation Forum!

Lab10.1 - Error creating ingress rule: "pathType must be specified"

wodecker
wodecker Posts: 2
in LFS258 Class Forum

Hi there,
I am working through the LFS258 course and have properly gone through all the labs in sequence successfully up to Lab10.1 so far.
Now, in that Lab exercise, the step 9 (Ingest the ingress rule) fails:

student@lfs258-master:~$ kubectl create -f ingress.rule.yaml
error: error validating "ingress.rule.yaml": error validating data: [ValidationError(Ingress.spec.rules[0].http.paths[0].backend): unknown field "serviceName" in io.k8s.api.networking.v1.IngressBackend, ValidationError(Ingress.spec.rules[0].http.paths[0].backend): unknown field "servicePort" in io.k8s.api.networking.v1.IngressBackend]; if you choose to ignore these errors, turn validation off with --validate=false

When I add the mentioned --validate=false Flag, there is another error:

student@lfs258-master:~$ kubectl create -f ingress.rule.yaml --validate=false
The Ingress "ingress-test" is invalid: spec.rules[0].http.paths[0].pathType: Required value: pathType must be specified

I am running on Kubernetes 1.19.6 ... got anything deprecated here?

Thanks for help ..

Comments

  • chrispokorni
    chrispokorni Posts: 2,606

    Hi @wodecker,

    There may be several aspects to cause these errors.

    The course is asking for Kubernetes v1.19.0 - to keep it aligned with the CKA certification exam environment, and it has not been tested against v1.19.6.

    The easiest method to fix your first error and move forward would be to update the apiVersion in the ingress.rule.yaml file with apiVersion: networking.k8s.io/v1beta1, as it is presented in the YAML code on Step 8 of the lab manual. Upgrading the Ingress resource from beta (v1beta1) to stable (v1) requires some of the YAML fields to be re-formatted according to the latest documentation, but this method has not been tested and validated against the exercise.

    For the second error, inspect carefully the YAML code in Step 15, where each path: / is followed by pathType: ImplementationSpecific line. Adding the pathType should eliminate this error.

    Between Kubernetes v1.19 and 1.20 the Ingress object matured from beta to stable, it introduced changes in the YAML formatting, resulting in inconsistent behaviors between Ingress object deployments. This type of behavior is often encountered as objects mature between Kubernetes releases.

    Regards,
    -Chris

  • wodecker
    wodecker Posts: 2

    Hi @chrispokorni ,

    thanks for the quick response. Indeed I discovered that the pathType parameter has been added to the yaml in step 15, but unfortunately it was not yet there in step 8, so I didn't get aware of this on first try ..

    But also with that parameter added, there was still an error:

    student@lfs258-master:~$ kubectl create -f ingress.rule.yaml --validate=false
The Ingress "ingress-test" is invalid: spec.rules[0].http.paths[0].backend: Invalid value: "": resource or service backend is required

    I then checked kubernetes documentation here: https://kubernetes.io/docs/concepts/services-networking/ingress/#the-ingress-resource

    Based on that, I changed the backend configuration to probably newer syntax:

    spec:
  rules:
  - host: www.example.com
    http:
      paths:
      - backend:
          service:
            name: secondapp
            port:
              number: 80
        path: /
        pathType: ImplementationSpecific

    With that spec, I succeeded in creating the Ingress Rule ...

    BTW, I upgraded to 1.19.6 instead of 1.19.0 in Lab4.1 because I got some message in step 7 there asking me to upgrade to the latest 1.19 version (which was 1.19.6 then)

    Thanks and kind Regards,
    Wolfgang

  • chrispokorni
    chrispokorni Posts: 2,606

    During the upgrade you can pick any version in the process, you are not required to upgrade to the latest version.

    If the apiVersion is v1, then the new syntax needs to be followed, however, I have seen some issues when the Ingress resource would jump back and forth between the two versions. The most stable at the time was also the easiest way, with the least amount of typing, to stay on v1beta1 instead.

    Regards,
    -Chris

Categories

Upcoming Training