2017-06-23 1 views
2

I kubectl bin mit 1.6.4:Nach kubectl erstelle ich einen Fehler bei der Überprüfung, aber meine YAML-Datei ist gültig

$ kubectl version 
Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.4", GitCommit:"d6f433224538d4f9ca2f7ae19b252e6fcb66a3ae", GitTreeState:"clean", BuildDate:"2017-05-19T18:44:27Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"darwin/amd64"} 
Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.4", GitCommit:"d6f433224538d4f9ca2f7ae19b252e6fcb66a3ae", GitTreeState:"clean", BuildDate:"2017-05-19T18:33:17Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"} 

Ich versuche, mit Connect a Front End to a Back End Using a Service zu folgen, und bin versucht, diese Bereitstellung zu erstellen (deployment.yml):

apiVersion: apps/v1beta1 
kind: Deployment 
metadata: 
    name: frontend 
spec: 
    replicas: 1 
    template: 
    metadata: 
     labels: 
     app: hello 
     tier: frontend 
     track: stable 
    spec: 
     containers: 
     - name: nginx 
      image: "gcr.io/google-samples/hello-frontend:1.0" 
      lifecycle: 
      preStop: 
       exec: 
       command: ["/usr/sbin/nginx","-s","quit"] 

Nach kubectl create -f deployment.yml, erhalte ich folgende Fehlermeldung:

error: error validating "/path/to/deployment.yml": error validating data: unexpected end of JSON input; if you choose to ignore these errors, turn validation off with --validate=false

Diese Datei ist jedoch gültig.

Ich bemerkte in Deployments documentation, dass s vor 1.6.0 verwendet apiVersion: extensions/v1beta1 anstelle von apiVersion: app/v1beta1. Also nur für Tritte ersetzte ich apiVersion: app/v1beta1 durch apiVersion: extensions/v1beta1, obwohl ich 1.6.4 laufen lasse. Zu meiner Überraschung funktionierte es.

Was ist los? Warum muss ich die alte, vor 1.6.0 apiVersion Zeile verwenden, obwohl ich auf 1.6.4 bin?

Antwort

3

Versuchen Sie zu löschen ~/.kube/schema (Ich löschte ~/.kube/cache auch, aber ich bin mir ziemlich sicher, dass das keinen Effekt hatte). In meinem Fall hatte ~/.kube/schema mehrere Schemata:

$ l schema/ 
total 0 
drwxr-xr-x 6 dmitry staff 204B Jan 9 11:23 v1.4.7 
drwxr-xr-x 8 dmitry staff 272B Jan 11 00:13 v1.5.1 
drwxr-xr-x 5 dmitry staff 170B Jun 17 15:05 . 
drwxr-xr-x 7 dmitry staff 238B Jun 22 19:32 v1.6.4 
drwxr-xr-x 5 dmitry staff 170B Jun 22 22:47 .. 

und kubectl wurde offenbar ein altes Schema verwenden. This might be a bug.

Wenn Sie ~/.kube/schema löschen, wird das nächste Mal, wenn Sie versuchen, die YML-Datei zu erstellen, kubectl dieses Verzeichnis erneut auffüllen, jedoch nur mit dem neuesten gültigen Schema. Und es wird funktionieren.

Verwandte Themen