{"id":30272,"date":"2019-10-31T21:34:36","date_gmt":"2019-10-31T18:34:36","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kubernetes-1-14-obzor-osnovnyh-novshestv\/"},"modified":"2019-10-31T21:34:36","modified_gmt":"2019-10-31T18:34:36","slug":"kubernetes-1-14-obzor-osnovnyh-novshestv","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/kubernetes-1-14-obzor-osnovnyh-novshestv","title":{"rendered":"\ud83e\udd47Kubernetes 1.16: \u00dcbersicht \u00fcber die Hauptneuerungen | ProHoster","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"\ud83e\udd47Kubernetes 1.16: \u00dcbersicht \u00fcber die Hauptneuerungen | ProHoster\" src=\"\/wp-content\/uploads\/2019\/03\/8fb5be29668f55ec42d31eb47200b639.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIn dieser Nacht <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/sig-release\/tree\/master\/releases\/release-1.14#timeline\">stattfinden<\/a><\/noindex> wurde eine weitere Version von Kubernetes ver\u00f6ffentlicht \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/sig-release\/tree\/master\/releases\/release-1.14\">1.14<\/a><\/noindex>. Wie es f\u00fcr unseren Blog Tradition ist, berichten wir \u00fcber die wichtigsten \u00c4nderungen in dieser neuen Version dieses bemerkenswerten Open Source-Produkts.<\/p>\n<p>Die Informationen, die zur Vorbereitung dieses Materials verwendet wurden, stammen aus <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.google.com\/spreadsheets\/u\/1\/d\/116X6E-lmDJG5UZPlqDAFw8hN9vS6SNY4qRNZ9fKtsMU\/edit#gid=0\">der Tabelle zur Nachverfolgung von Kubernetes-Verbesserungen<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/blob\/release-1.14\/CHANGELOG-1.14.md\">CHANGELOG-1.14<\/a><\/noindex> und die entsprechenden Issues, Pull Requests, Kubernetes Enhancement Proposals (KEP).<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Wir beginnen mit einer wichtigen Einf\u00fchrung von SIG cluster-lifecycle: <b>dynamische fehlertolerante Cluster<\/b> Kubernetes (oder pr\u00e4ziser gesagt, self-hosted HA-Deployments) k\u00f6nnen jetzt <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/enhancements\/issues\/357\">erstellt werden<\/a><\/noindex> mit den gewohnten (im Kontext von Clustern mit einem Knoten) Befehlen <code>kubeadm<\/code> (<code>init<\/code> und <code>join<\/code>). Kurz gesagt, daf\u00fcr:<\/p>\n<ul>\n<li> Die vom Cluster verwendeten Zertifikate werden in Secrets verschoben;<\/li>\n<li> um die Nutzung von etcd innerhalb des K8s-Clusters zu erm\u00f6glichen (d.h. um die bisher bestehende externe Abh\u00e4ngigkeit zu beseitigen), wird der <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/coreos\/etcd-operator\">etcd-Operator<\/a><\/noindex>;<\/li>\n<li> eingesetzt, um empfohlene Einstellungen f\u00fcr einen externen Lastenausgleich zu dokumentieren, der eine fehlertolerante Konfiguration sicherstellt (es ist geplant, auch diese Abh\u00e4ngigkeit in Zukunft abzulehnen, jedoch nicht zu diesem Zeitpunkt).<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"\ud83e\udd47Kubernetes 1.16: \u00dcbersicht \u00fcber die Hauptneuerungen | ProHoster\" src=\"\/wp-content\/uploads\/2019\/03\/0e82b7e8db1ad117dc87f68fa4669431.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Die Architektur des HA-Clusters von Kubernetes, das mit kubeadm erstellt wurde,<\/i><\/p>\n<p>Die Details zur Umsetzung sind im <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.google.com\/document\/d\/1P3oUJ_kdaRSTlGONujadGBpYegjn4RjBNZLHZ4zU7lI\/edit#\">Designvorschlag<\/a><\/noindex>einzusehen. Dieses Feature war wirklich lange erwartet: Die Alpha-Version wurde bereits in K8s 1.9 erwartet, ist aber erst jetzt erschienen.<\/p>\n<h2>API<\/h2>\n<p>\nTeam <code>apply<\/code> Und generell <b>deklaratives Management von Objekten<\/b> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/enhancements\/issues\/555\">wurde ausgegliedert<\/a><\/noindex> aus <code>kubectl<\/code> in den apiserver. Die Entwickler selbst erkl\u00e4ren ihre Entscheidung damit, dass <code>kubectl apply<\/code> es eine fundamentale Komponente bei der Arbeit mit Konfigurationen in Kubernetes ist, jedoch \"voller Fehler ist und schwer zu reparieren ist\", weswegen diese Funktionalit\u00e4t in einen ordentlichen Zustand gebracht und in den Control Plane verschoben werden muss. Einfache und anschauliche Beispiele f\u00fcr die bestehenden Probleme sind:<\/p>\n<p><img decoding=\"async\" alt=\"\ud83e\udd47Kubernetes 1.16: \u00dcbersicht \u00fcber die Hauptneuerungen | ProHoster\" src=\"\/wp-content\/uploads\/2019\/03\/379b0d830491bbb0e7ac3c3ccfff71c4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDetails zur Umsetzung finden Sie im <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/enhancements\/blob\/master\/keps\/sig-api-machinery\/0006-apply.md\">KEP<\/a><\/noindex>. Der aktuelle Stand ist die Alpha-Version (die Versetzung in die Beta ist f\u00fcr die n\u00e4chste Kubernetes-Version geplant).<\/p>\n<p>In der Alpha-Version wurde die Nutzung des OpenAPI v3-Schemas f\u00fcr <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/enhancements\/issues\/692\">die M\u00f6glichkeit<\/a><\/noindex> die Erstellung und Ver\u00f6ffentlichung von OpenAPI-Dokumentationen f\u00fcr CustomResources <b>(CR), die zur Validierung (serverseitig) von K8s-Ressourcen, die vom Benutzer definiert sind (CustomResourceDefinition, CRD), verwendet werden, verf\u00fcgbar. Die Ver\u00f6ffentlichung von OpenAPI f\u00fcr CRD erm\u00f6glicht es den Clients (zum Beispiel,<\/b> ) die Validierung auf ihrer Seite (im Rahmen von <code>kubectl<\/code>) durchzuf\u00fchren und die Dokumentation zur Schema ( <code>) bereitzustellen. Details finden Sie im<\/code> und <code>kubectl apply<\/code>Die fr\u00fcheren Logs<code>, der die Spezifikationen aller Ressourcen direkt in Ihrem Terminal anzeigt.<\/code>werden jetzt ge\u00f6ffnet <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/enhancements\/blob\/master\/keps\/sig-api-machinery\/00xx-publish-crd-openapi.md\">KEP<\/a><\/noindex>.<\/p>\n<p>O_APPEND <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/74837\">(und nicht<\/a><\/noindex> mit dem Flag <code>O_TRUNC<\/code> (und nicht <code>O_TRUNC<\/code>) um den Verlust von Logdaten in bestimmten Situationen zu vermeiden und um die Truncation von Logs durch externe Tools zur Rotation zu erleichtern.<\/p>\n<p>Im Kontext der Kubernetes API kann auch erw\u00e4hnt werden, dass <code>PodSandbox<\/code> und <code>PodSandboxStatus<\/code> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/73833\">hinzugef\u00fcgt<\/a><\/noindex> Feld <code>runtime_handler<\/code> um Informationen \u00fcber <code>RuntimeClass<\/code> im Pod (lesen Sie mehr dar\u00fcber im Text \u00fcber <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/424331\/\">Kubernetes-Version 1.12<\/a><\/noindex>, wo diese Klasse als Alpha-Version eingef\u00fchrt wurde), w\u00e4hrend bei Admission Webhooks <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/74998\">wurde<\/a><\/noindex> die M\u00f6glichkeit besteht, zu bestimmen, welche Versionen <code>AdmissionReview<\/code> unterst\u00fctzt werden. Schlie\u00dflich kann in den Regeln f\u00fcr Admission Webhooks nun <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/74477\">die Anwendungskontexte<\/a><\/noindex> die Skalierung ihrer Anwendung mit Namespaces und Clustergrenzen.<\/p>\n<h2>Speicher<\/h2>\n<p>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/storage\/volumes\/#local\"><code><b>Persistente lokale Volumes<\/b><\/code><\/a><\/noindex>, die den Status einer Beta-Version seit der Ver\u00f6ffentlichung <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/353114\/\">K8s 1.10<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/74769\">erhalten hatten,<\/a><\/noindex> wurden als stabil (GA) erkl\u00e4rt: dieses Feature Gate wird nicht mehr deaktiviert und wird in Kubernetes 1.17 entfernt.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/enhancements\/issues\/559\">Die M\u00f6glichkeit<\/a><\/noindex> die Nutzung von Umgebungsvariablen des sogenannten <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/tasks\/inject-data-application\/downward-api-volume-expose-pod-information\/#capabilities-of-the-downward-api\">Downward API<\/a><\/noindex> (zum Beispiel, der Name des Pods) f\u00fcr Verzeichnisse, die als <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/storage\/volumes\/#using-subpath\"><code>subPath<\/code><\/a><\/noindex>, eingef\u00fchrt \u2014 in Form eines neuen Feldes <code>subPathExpr<\/code>, mit dessen Hilfe nun auch der ben\u00f6tigte Verzeichnisname festgelegt wird. Das Feature wurde erstmals in Kubernetes 1.11 eingef\u00fchrt, blieb aber auch f\u00fcr 1.14 im Status einer Alpha-Version.<\/p>\n<p>Wie im vorherigen Kubernetes-Release wurden viele bedeutende \u00c4nderungen f\u00fcr das aktiv entwickelte CSI (Container Storage Interface) vorgestellt:<\/p>\n<h3>CSI<\/h3>\n<p>\nwurde verf\u00fcgbar gemacht (im Rahmen der Alpha-Version) <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/enhancements\/issues\/556\">unterst\u00fctzt<\/a><\/noindex> <b>f\u00fcr die Gr\u00f6\u00dfen\u00e4nderung von CSI-Volumes.<\/b>Um es zu nutzen, muss das Feature Gate mit dem Namen <code>ExpandCSIVolumes<\/code>aktiviere werden, vorausgesetzt, der spezifische CSI-Treiber unterst\u00fctzt diese Operation.<\/p>\n<p>Ein weiteres Feature f\u00fcr CSI in der Alpha-Version \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/enhancements\/issues\/596\">die M\u00f6glichkeit<\/a><\/noindex> direkt (d.h. ohne Nutzung von PV\/PVC) auf CSI-Volumes im Rahmen der Pod-Spezifikation zu verweisen. Dies <b>behebt die Einschr\u00e4nkung, dass CSI ausschlie\u00dflich als entferntes Speichersystem genutzt wird,<\/b>und \u00f6ffnet ihnen die T\u00fcr zur Welt der <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes-csi.github.io\/docs\/ephemeral-local-volumes.html\">lokalen ephemeral volumes.<\/a><\/noindex>Zur Nutzung (<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/vladimirvivien\/kubernetes.github.io\/blob\/b78107abfdb2b5877973b84062d93cdf98ef1b9c\/content\/en\/docs\/concepts\/storage\/volumes.md#csi-ephemeral-volumes\">Beispiel aus der Dokumentation<\/a><\/noindex>) muss das <code>CSIInlineVolume<\/code> Feature Gate aktiviert werden.<\/p>\n<p>Es gab Fortschritte auch in den 'Innereien' von Kubernetes, die mit CSI verbunden sind und den Endbenutzern (Systemadministratoren) nicht so auffallen\u2026 Momentan sind die Entwickler gezwungen, zwei Versionen jedes Speicher-Plugins zu unterst\u00fctzen: eine \u2013 'auf alte Art' \u2013 innerhalb der K8s-Codebasis (in-tree), und eine zweite \u2013 im Rahmen des neuen CSI. <i>(lesen Sie mehr dar\u00fcber, z.B. in <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/424211\/\">hier<\/a><\/noindex>)<\/i>. Dies f\u00fchrt zu verst\u00e4ndlichen Unannehmlichkeiten, die behoben werden m\u00fcssen, sobald CSI als solches stabil ist. Es ist jedoch nicht m\u00f6glich, interne (in-tree) API von Plugins als veraltet (deprecated) zu erkl\u00e4ren aufgrund der <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/reference\/using-api\/deprecation-policy\/#deprecating-parts-of-the-api\">entsprechenden Kubernetes-Richtlinien.<\/a><\/noindex>.<\/p>\n<p>All dies f\u00fchrte dazu, dass die Alpha-Versionen die <b><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/enhancements\/issues\/625\">Migrationsprozesse<\/a><\/noindex> des internen Codes von Plugins<\/b>, die als in-tree implementiert werden, in CSI-Plugins umgewandelt werden, wodurch die Entwickler sich auf die Unterst\u00fctzung einer Version ihrer Plugins konzentrieren k\u00f6nnen, w\u00e4hrend die Kompatibilit\u00e4t mit alten APIs erhalten bleibt und sie im Rahmen des gewohnten Szenarios als veraltet erkl\u00e4rt werden k\u00f6nnen. Es wird erwartet, dass bis zur n\u00e4chsten Kubernetes-Version (1.15) alle Plugins der Cloud-Anbieter migriert werden, die Implementierung den Status einer Beta-Version erh\u00e4lt und standardm\u00e4\u00dfig in K8s-Installationen aktiviert wird. Details siehe <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/community\/blob\/master\/contributors\/design-proposals\/storage\/csi-migration.md\">Designvorschlag<\/a><\/noindex>. Eine Folge dieser Migration war auch <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/74544\">der Verzicht<\/a><\/noindex> die Aufhebung von Einschr\u00e4nkungen f\u00fcr Volumes, die von bestimmten Cloud-Anbietern festgelegt werden (AWS, Azure, GCE, Cinder).<\/p>\n<p>Dar\u00fcber hinaus wird die Unterst\u00fctzung f\u00fcr Blockger\u00e4te mit CSI (<code>CSIBlockVolume<\/code>) <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/74909\">wurde<\/a><\/noindex> in die Beta-Version \u00fcberf\u00fchrt.<\/p>\n<h2>Knoten \/ Kubelet<\/h2>\n<p>\nEine Alpha-Version <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/enhancements\/issues\/727\">eines neuen Endpunkts<\/a><\/noindex> wurde im Kubelet eingef\u00fchrt, der dazu dient, <b>Metriken zu den Hauptressourcen bereitzustellen.<\/b>. Im Allgemeinen erhielt Kubelet vorher Statistiken zur Nutzung von Containern von cAdvisor, jetzt stammen diese Daten aus der Container-Laufzeitumgebung \u00fcber CRI (Container Runtime Interface), wobei die Kompatibilit\u00e4t f\u00fcr die Arbeit mit alten Docker-Versionen jedoch erhalten bleibt. Fr\u00fcher wurden die in Kubelet gesammelten Statistiken \u00fcber die REST-API bereitgestellt, jetzt wird daf\u00fcr ein Endpunkt verwendet, der unter der Adresse <code>\/metrics\/resource\/v1alpha1<\/code>liegt. Die langfristige Strategie der Entwickler <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/issues\/68522\">besteht darin,<\/a><\/noindex> die Menge der von Kubelet bereitgestellten Metriken zu minimieren. <i>\u00dcbrigens werden diese Metriken <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/enhancements\/pull\/726\">jetzt als<\/a><\/noindex> nicht mehr als \u201eKernmetriken\u201c, sondern als \u201eRessourc metriken\u201c bezeichnet und beschreiben \u201eErstklassige Ressourcen wie CPU und Speicher\u201c.<\/i><\/p>\n<p>Ein interessanter Punkt: Trotz des offensichtlichen Performancevorteils des gRPC-Endpunkts im Vergleich zu verschiedenen Nutzungsf\u00e4llen des Prometheus-Formats <i>(Ergebnis eines der Benchmarks, siehe unten)<\/i>, zogen die Autoren das textbasierte Prometheus-Format aufgrund der offensichtlichen F\u00fchrungsposition dieses Monitoringsystems in der Community vor.<\/p>\n<blockquote><p><i>\u00abgRPC ist nicht mit den Haupt\u00fcberwachungs-Pipelines kompatibel. Der Endpoint wird jedoch nur f\u00fcr die Bereitstellung von Metriken an den Metrics Server oder an Monitoring-Komponenten n\u00fctzlich sein, die direkt damit integriert sind. Bei Verwendung von Caching im Metrics Server ist die Leistung des textbasierten Prometheus-Formats <b>recht gut<\/b> f\u00fcr uns, um Prometheus gegen\u00fcber gRPC zu bevorzugen, angesichts der breiten Verbreitung von Prometheus in der Gemeinschaft. Wenn das OpenMetrics-Format stabiler wird, k\u00f6nnen wir die Leistung von gRPC mit einem proto-basierten Format ann\u00e4hern.\u00bb<\/i><\/p><\/blockquote>\n<p>\n<img decoding=\"async\" alt=\"\ud83e\udd47Kubernetes 1.16: \u00dcbersicht \u00fcber die Hauptneuerungen | ProHoster\" src=\"\/wp-content\/uploads\/2019\/03\/ad7e45b61fc4676a2df3c2d33d5688b5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Einer der Leistungstests zur Verwendung der Formate gRPC und Prometheus im neuen Kubelet-Endpunkt f\u00fcr Metriken. Weitere Diagramme und andere Details finden Sie in <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/enhancements\/blob\/master\/keps\/sig-node\/kubelet-resource-metrics-endpoint.md\">KEP<\/a><\/noindex>.<\/i><\/p>\n<p>Unter den weiteren \u00c4nderungen:<\/p>\n<ul>\n<li> versucht Kubelet jetzt (einmalig) <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/73802\">die Container in unbekanntem Zustand (unknown) vor Neustart- und L\u00f6schoperationen zu stoppen.<\/a><\/noindex> PodPresets<\/li>\n<li> Bei der Nutzung eines <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/workloads\/pods\/podpreset\/\"><code>wird jetzt dem Init-Container<\/code><\/a><\/noindex> die gleichen Informationen wie dem regul\u00e4ren Container hinzugef\u00fcgt. <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/71479\">begann,<\/a><\/noindex> usageNanoCores<\/li>\n<li> Kubelet <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/73659\">vom CRI-Statistikprovider zu verwenden, und f\u00fcr Knoten und Container unter Windows<\/a><\/noindex> <code>Netzwerkstatistiken.<\/code> Informationen \u00fcber das Betriebssystem und die Architektur werden jetzt in den Labels <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/74788\">hinzugef\u00fcgt<\/a><\/noindex> kubernetes.io\/os<\/li>\n<li> kubernetes.io\/arch <code>von Node-Objekten (von Beta auf GA \u00fcbertragen).<\/code> und <code>Die M\u00f6glichkeit, eine bestimmte Benutzer-Systemgruppe f\u00fcr Container im Pod anzugeben (<\/code> RunAsGroup<\/li>\n<li> Die M\u00f6glichkeit, eine spezifische Benutzer-Gruppe f\u00fcr Container im Pod anzugeben (<code>K8s 1.11<\/code>vorangetrieben <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/415349\/\">bis zur Beta-Version (standardm\u00e4\u00dfig aktiviert).<\/a><\/noindex>) <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/73007\">du und find, die in cAdvisor verwendet wurden,<\/a><\/noindex> wurden<\/li>\n<li> durch Go-Implementierungen ersetzt. <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/74675\">In cli-runtime und kubectl<\/a><\/noindex> fand der -k-Flag f\u00fcr die Integration mit<\/li>\n<\/ul>\n<p><\/p>\n<h2>CLI<\/h2>\n<p>\n(\u00fcbrigens wird die Entwicklung jetzt in einem eigenen Repository durchgef\u00fchrt), d.h. zur Verarbeitung zus\u00e4tzlicher YAML-Dateien aus speziellen Kustomization-Verzeichnissen (weitere Einzelheiten zur Verwendung finden Sie in <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/74140\">wurde hinzugef\u00fcgt<\/a><\/noindex> Beispiel f\u00fcr die einfache Verwendung einer Datei <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes-sigs\/kustomize\"><b>kustomize<\/b><\/a><\/noindex> kustomization <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/enhancements\/blob\/master\/keps\/sig-cli\/kustomize-file-processing-integration.md\">KEP<\/a><\/noindex>):<\/p>\n<p><img decoding=\"async\" alt=\"\ud83e\udd47Kubernetes 1.16: \u00dcbersicht \u00fcber die Hauptneuerungen | ProHoster\" src=\"\/wp-content\/uploads\/2019\/03\/e38550cfb642d81237aad4d87b9b3386.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>(m\u00f6glicherweise auch komplexere Anwendungen von kustomize im Rahmen von <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes-sigs\/kustomize\/blob\/master\/docs\/glossary.md#kustomization\">overlays<\/a><\/noindex> das neue Kommando <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes-sigs\/kustomize\/blob\/master\/docs\/glossary.md#overlay\">kubectl create cronjob<\/a><\/noindex>)<\/i><\/p>\n<p>Au\u00dferdem:<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/71651\">Hinzugef\u00fcgt<\/a><\/noindex> , dessen Name f\u00fcr sich selbst spricht. <code>kubectl logs<\/code>kombiniert<\/li>\n<li> Im <code>Flags<\/code> ist jetzt m\u00f6glich <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/67573\">--follow<\/a><\/noindex> f\u00fcr das Streaming von Logs) und <code>-f<\/code> (<code>--selector<\/code> f\u00fcr die Labelabfrage). <code>-l<\/code> (<code>lernte<\/code> Dateien zu kopieren, die mit Wildcards ausgew\u00e4hlt werden.<\/li>\n<li> kubectl <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/72641\">Im Befehl<\/a><\/noindex> kubectl wait<\/li>\n<li> --all <code>zum Ausw\u00e4hlen aller Ressourcen im Namensraum eines angegebenen Ressourcentyps.<\/code> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/70599\">haben<\/a><\/noindex> Flag <code>Der stabile (GA) Status wurde f\u00fcr folgende Funktionen erreicht:<\/code> ReadinessGate<\/li>\n<\/ul>\n<p><\/p>\n<h2>Andere<\/h2>\n<p>\n, verwendet in der Pod-Spezifikation zur Bestimmung zus\u00e4tzlicher Bedingungen, die bei der Pod-Bereitschaft ber\u00fccksichtigt werden;<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/workloads\/pods\/pod-lifecycle\/#pod-readiness-gate\"><code>ReadinessGate<\/code><\/a><\/noindex>, verwendet in der Pod-Spezifikation, um zus\u00e4tzliche Bedingungen zu definieren, die bei der Bereitschaft des Pods ber\u00fccksichtigt werden;<\/li>\n<li> Unterst\u00fctzung f\u00fcr gro\u00dfe Seiten (Feature-Gate mit dem Namen <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/tasks\/manage-hugepages\/scheduling-hugepages\/\"><code>HugePages<\/code><\/a><\/noindex>);<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/services-networking\/dns-pod-service\/#pod-s-dns-config\">CustomPodDNS<\/a><\/noindex>;<\/li>\n<li> PriorityClass API, <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/configuration\/pod-priority-preemption\/\">Pod-Priorit\u00e4t &amp; Vorabenteignung<\/a><\/noindex>.<\/li>\n<\/ul>\n<p>\nWeiter \u00c4nderungen, die in Kubernetes 1.14 vorgestellt wurden:<\/p>\n<ul>\n<li> Die standardm\u00e4\u00dfige RBAC-Richtlinie gew\u00e4hrt keinen Zugriff auf die API <code>discovery<\/code> und <code>access-review<\/code> Benutzern ohne Authentifizierung <i>(unauthenticated)<\/i>.<\/li>\n<li> Offizielle Unterst\u00fctzung f\u00fcr CoreDNS <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/69940\">wird<\/a><\/noindex> nur f\u00fcr Linux bereitgestellt, daher m\u00fcssen beim Einsatz von kubeadm zur Bereitstellung von CoreDNS in einem Cluster die Knoten ausschlie\u00dflich unter Linux betrieben werden (f\u00fcr diese Einschr\u00e4nkung werden nodeSelectors verwendet).<\/li>\n<li> Die Standardkonfiguration von CoreDNS ist jetzt <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/73267\">verwendet<\/a><\/noindex> <noindex><a rel=\"nofollow\" href=\"https:\/\/coredns.io\/plugins\/forward\/\">Plugin forward<\/a><\/noindex> anstatt proxy. Zudem gibt es in CoreDNS <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/74137\">hinzugef\u00fcgt<\/a><\/noindex> readinessProbe, die verhindert, dass der Datenverkehr auf die entsprechenden (nicht betriebsbereiten) Pods geleitet wird.<\/li>\n<li> In kubeadm, in den Phasen <code>init<\/code> oder <code>upload-certs<\/code>, <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/73907\">wurde es m\u00f6glich,<\/a><\/noindex> die f\u00fcr die Verbindung eines neuen Control-Plans ben\u00f6tigten Zertifikate in das Secret kubeadm-certs hochzuladen (es wird die Option <code>--experimental-upload-certs<\/code>).<\/li>\n<li> F\u00fcr Windows-Installationen gibt es eine Alpha-Version <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/enhancements\/issues\/689\">Unterst\u00fctzung<\/a><\/noindex> gMSA (Group Managed Service Account) - spezielle Konten in Active Directory, die auch von Containern verwendet werden k\u00f6nnen.<\/li>\n<li> F\u00fcr GCE <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/70144\">wurde aktiviert<\/a><\/noindex> mTLS-Verschl\u00fcsselung zwischen etcd und kube-apiserver.<\/li>\n<li> Updates der verwendeten\/abh\u00e4ngigen Software: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, Unterst\u00fctzung von Docker 18.09 in kubeadm, und die minimal unterst\u00fctzte Version der Docker-API ist nun 1.26.<\/li>\n<\/ul>\n<p><\/p>\n<h2>P.S.<\/h2>\n<p>\nLesen Sie auch in unserem Blog:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/flant\/blog\/432208\/\">\ud83e\udd47Kubernetes 1.16: \u00dcbersicht \u00fcber die Hauptneuerungen | ProHoster<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/flant\/blog\/424331\/\">\ud83e\udd47Kubernetes 1.16: \u00dcbersicht \u00fcber die Hauptneuerungen | ProHoster<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/flant\/blog\/415349\/\">Kubernetes 1.11: \u00dcberblick \u00fcber die wichtigsten Neuerungen<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/flant\/blog\/353114\/\">Kubernetes 1.10: \u00dcberblick \u00fcber die wichtigsten Neuerungen<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Quelle: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/445196\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u042d\u0442\u043e\u0439 \u043d\u043e\u0447\u044c\u044e \u0441\u043e\u0441\u0442\u043e\u0438\u0442\u0441\u044f \u043e\u0447\u0435\u0440\u0435\u0434\u043d\u043e\u0439 \u0440\u0435\u043b\u0438\u0437 Kubernetes \u2014 1.14. \u041f\u043e \u0441\u043b\u043e\u0436\u0438\u0432\u0448\u0435\u0439\u0441\u044f \u0434\u043b\u044f \u043d\u0430\u0448\u0435\u0433\u043e \u0431\u043b\u043e\u0433\u0430 \u0442\u0440\u0430\u0434\u0438\u0446\u0438\u0438, \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u0435\u043c \u043e \u043a\u043b\u044e\u0447\u0435\u0432\u044b\u0445 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u044f\u0445 \u0432 \u043d\u043e\u0432\u043e\u0439 \u0432\u0435\u0440\u0441\u0438\u0438 \u044d\u0442\u043e\u0433\u043e \u0437\u0430\u043c\u0435\u0447\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u0433\u043e Open Source-\u043f\u0440\u043e\u0434\u0443\u043a\u0442\u0430. \u0418\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u044f, \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u043d\u0430\u044f \u0434\u043b\u044f \u043f\u043e\u0434\u0433\u043e\u0442\u043e\u0432\u043a\u0438 \u044d\u0442\u043e\u0433\u043e \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u0430, \u0432\u0437\u044f\u0442\u0430 \u0438\u0437 \u0442\u0430\u0431\u043b\u0438\u0446\u044b Kubernetes enhancements tracking, CHANGELOG-1.14 \u0438 \u0441\u043e\u043e\u0432\u0435\u0442\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445 issues, pull requests, Kubernetes Enhancement Proposals (KEP). \u041d\u0430\u0447\u043d\u0451\u043c \u0441 \u0432\u0430\u0436\u043d\u043e\u0433\u043e \u0432\u0432\u0435\u0434\u0435\u043d\u0438\u044f \u043e\u0442 SIG cluster-lifecycle: \u0434\u0438\u043d\u0430\u043c\u0438\u0447\u0435\u0441\u043a\u0438\u0435 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-30272","post","type-post","status-publish","format-standard","hentry"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u042d\u0442\u043e\u0439 \u043d\u043e\u0447\u044c\u044e\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/de\/blog\/kubernetes-1-14-obzor-osnovnyh-novshestv\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"de_DE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47Kubernetes 1.14: \u043e\u0431\u0437\u043e\u0440 \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u0445 \u043d\u043e\u0432\u0448\u0435\u0441\u0442\u0432 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u042d\u0442\u043e\u0439 \u043d\u043e\u0447\u044c\u044e\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/de\/blog\/kubernetes-1-14-obzor-osnovnyh-novshestv\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:34:36+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:34:36+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Kubernetes 1.14: \u00dcberblick \u00fcber die wichtigsten Neuerungen | ProHoster","description":"In dieser Nacht","canonical_url":"https:\/\/prohoster.info\/de\/blog\/kubernetes-1-14-obzor-osnovnyh-novshestv","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Kubernetes 1.14: \u043e\u0431\u0437\u043e\u0440 \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u0445 \u043d\u043e\u0432\u0448\u0435\u0441\u0442\u0432 | ProHoster","og:description":"\u042d\u0442\u043e\u0439 \u043d\u043e\u0447\u044c\u044e","og:url":"https:\/\/prohoster.info\/de\/blog\/kubernetes-1-14-obzor-osnovnyh-novshestv","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:34:36+00:00","article:modified_time":"2019-10-31T18:34:36+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"30272","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"Article","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 00:28:09","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 03:37:28","updated":"2026-01-21 00:28:09","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/30272","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=30272"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/30272\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=30272"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=30272"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=30272"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}