Kubernetes: Die Bereitstellungs-API-Version apps / v1beta2 wird bei der Erstellung in die Erweiterungen / v1beta1 geändert
Ist dies ein BUG REPORT oder eine FEATURE REQUEST? ::
/ Art Bug
Was ist passiert :
Wenn ich ein Beispiel für eine Bereitstellung auf kubernetes / website mit der API-Version apps/v1beta2 erstelle, ist die API-Version, die ich bei der Ausführung von kubectl get deploy nginx-deployment -o yaml sehe, extensions/v1beta1 .
Was Sie erwartet hatten :
Ich erwarte, dass die API-Version apps/v1beta2 .
Wie man es reproduziert (so minimal und präzise wie möglich) :
- Verwenden Sie die Client-Version
v1.9.1und die Server-Versionv1.8.4. - Erstellen Sie die Beispiel-Nginx-Bereitstellungsdatei:
Bash kubectl create -f https://raw.githubusercontent.com/kubernetes/website/snapshot-final-v1.8/docs/tasks/run-application/deployment.yaml - Überprüfen Sie, ob die API-Version
apps/v1beta2(was nicht der Fall ist):
Bash kubectl get deploy nginx-deployment -o yaml | grep apiVersion
Was müssen wir noch wissen? ::
Nicht dass ich daran denken könnte.
Umwelt :
- Kubernetes-Version (verwenden Sie
kubectl version):
Bash
Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.1", GitCommit:"3a1c9449a956b6026f075fa3134ff92f7d55f812", GitTreeState:"clean", BuildDate:"2018-01-04T11:52:23Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.4", GitCommit:"9befc2b8928a9426501d3bf62f72849d5cbcd5a3", GitTreeState:"clean", BuildDate:"2017-11-20T05:17:43Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}
Cloud-Anbieter oder Hardwarekonfiguration:
AWS, bereitgestellt über kops v1.8.0 (git-5099bc5)
Betriebssystem (zB aus / etc / os-release): ~
Kernel (zB
uname -a): ~Tools installieren:
kops v1.8.0 (git-5099bc5)
Andere: ~
sean-krail
Alle 3 Kommentare
@ Sean-Krail: Zu diesem Thema gibt es keine Sig-Labels. Bitte fügen Sie ein Sig-Label hinzu.
Ein Sig-Label kann hinzugefügt werden durch:
Erwähnung einer Unterschrift:
@kubernetes/sig-<group-name>-<group-suffix>
Beispiel:@kubernetes/sig-contributor-experience-<group-suffix>, um die Erfahrung des Mitwirkenden zu benachrichtigenManuelles Festlegen der Bezeichnung:
/sig <group-name>
Beispiel:/sig scalability, um das Labelsig/scalabilityanzuwenden
Hinweis: Methode 1 löst eine E-Mail an die Gruppe aus. Siehe die Gruppenliste .
Das <group-suffix> in Methode 1 muss durch eines der folgenden Elemente ersetzt werden: _ Bugs, Feature-Requests, Pr-Reviews, Testfehler, Vorschläge _
Anweisungen zur Interaktion mit mir mithilfe von PR-Kommentaren finden Sie hier . Wenn Sie Fragen oder Vorschläge zu meinem Verhalten haben, reichen Sie bitte ein Problem mit dem Repository
k8s-ci-robot
am 27. Jan. 2018
kubectl get deployment ohne Qualifikation erhält die erste Version von Bereitstellungen, die der Server angibt, dass er zurückkehren kann.
Die von Ihnen erstellte Bereitstellung kann in jeder der unterstützten Versionen abgerufen werden. Um eine bestimmte Gruppe oder Version zu erhalten, qualifizieren Sie Ihre Get-Anfrage vollständig:
kubectl get deploy.apps…
kubectl get deploy.v1beta2.apps…
/schließen
liggitt
am 27. Jan. 2018
Das ist verwirrend. Ich würde denken, dass es die Version zurückgeben würde, die ich hochgeladen habe, oder die neueste Version von Bereitstellungen, die der Server zurückgeben kann.
Trotzdem danke!
sean-krail
am 27. Jan. 2018
Verwandte Themen
ttripp
·
3Kommentare
zetaab
·
3Kommentare
ddysher
·
3Kommentare
jadhavnitind
·
3Kommentare
broady
·
3Kommentare
Hilfreichster Kommentar
Das ist verwirrend. Ich würde denken, dass es die Version zurückgeben würde, die ich hochgeladen habe, oder die neueste Version von Bereitstellungen, die der Server zurückgeben kann.
Trotzdem danke!