0

When I try to create an nfs-based persistent volume in our local kubernetes cluster, I get the following error:

# kubectl create -f nfs.yaml
error: error validating "nfs.yaml": error validating data: the server could not find the requested resource; if you choose to ignore these errors, turn validation off with --validate=false

The nfs.yaml has the following content:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-nfs-pv1
  labels:
    type: nfs
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteMany
  nfs:
    server: 192.168.1.3
    path: "/srv/kubedata/"

The kubernetes cluster runs on three virtual machines created in our local openstack cloud (installed with kubespray). The nfs share is on the first node, and could be mounted manually on all nodes.

How can I fix this problem? Is the problem in the yaml file? How can I diagnose the problem? It would be very helpful to know where exactly the error is: is there a debug mode for kubectl?

Update: The original yaml I posted was corrupt, but that was because the stack overflow quote algorithm ate some newlines. I fixed that, now the posted yaml seems to validate on https://kubeyaml.com/, so the yaml seems to be okay (syntax-wise, at least).

Update2: 

# kubectl version
Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.0", GitCommit:"fff5156092b56e6bd60fff75aad4dc9de6b6ef37", GitTreeState:"clean", BuildDate:"2017-03-28T16:36:33Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.3", GitCommit:"2d3c76f9091b6bec110a5e63777c332469e0cba2", GitTreeState:"clean", BuildDate:"2019-08-19T11:05:50Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}
P.Péter
  • 499
  • 2
  • 6
  • 17

1 Answers1

2

This error means that your yaml file has an error. The easiest way to find it would be to just use one of the online validation tools. In your example there is an error at line 1. Your file should look like that:

apiVersion: v1
kind: PersistentVolume
metadata: 
  labels: 
    type: nfs
  name: pv-nfs-pv1
spec: 
  accessModes: 
    - ReadWriteMany
  capacity: 
    storage: 1Gi
  nfs: 
    path: /srv/kubedata
    server: 192.168.1.3

Please let me know if that helped.

EDIT:

However, a valid yaml does not mean that it has a valid input for Kubernetes. In order to further investigate you need to upgrade your kubectl version.

After upgrading to version 1.15 you will be able to get a detailed error message showing you the exact line(s) with the validation problem instead of just: the server could not find the requested resource;

In short:

  • upgrade kubectl to 1.15
  • run the command again
  • see which lines cause the problem
  • correct the lines and run the command again
Wytrzymały Wiktor
  • 731
  • 3
  • 10
  • Sorry, during the copy-paste-format, the posted file contents got corrupted. I fixed the post, so the yaml is identical to the real one (which is the same as yours, except the leading ---). Unfortunately, your version still produces the same error as mine. – P.Péter Jan 14 '20 at 14:16
  • `yaml` might be valid structurally but the input might still be wrong. Please try with the edited one and if that would still result with an error than we will dig deeper. – Wytrzymały Wiktor Jan 14 '20 at 14:44
  • I did try with the edited one, and the error message seems still the same: `error: error validating "proba.yaml": error validating data: the server could not find the requested resource; if you choose to ignore these errors, turn validation off with --validate=false` – P.Péter Jan 14 '20 at 14:49
  • Which version of `kubectl` do you have? – Wytrzymały Wiktor Jan 14 '20 at 14:57
  • added kubectl version output to question – P.Péter Jan 14 '20 at 15:11
  • Thanks for your input. I have edited the answer with more info in order to fix your problem. Please let me know if that worked for you. – Wytrzymały Wiktor Jan 15 '20 at 08:38
  • Yes, the version of my local kubectl was outdated. It seems that the kubernetes debian stretch repository is outdated (and there is no buster repo). However, the xenial repo is up-to-date, and so far seems to be compatible with debian buster. There is a new error of pod has unbound immediate PersistentVolumeClaims so it seems that even though the pv and pvc are created now, they still cannot be used, but I will ask about that in a different question, if I cannot figure it out. – P.Péter Jan 16 '20 at 16:29