{"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\/es\/blog\/kubernetes-1-14-obzor-osnovnyh-novshestv","title":{"rendered":"Kubernetes 1.13: revisi\u00f3n de las principales novedades","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Kubernetes 1.13: revisi\u00f3n de las principales novedades\" src=\"\/wp-content\/uploads\/2019\/03\/8fb5be29668f55ec42d31eb47200b639.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEsta noche <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/sig-release\/tree\/master\/releases\/release-1.14#timeline\">se llevar\u00e1 a cabo<\/a><\/noindex> se lanza otra versi\u00f3n de Kubernetes \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/sig-release\/tree\/master\/releases\/release-1.14\">1.14<\/a><\/noindex>. Seg\u00fan la tradici\u00f3n de nuestro blog, hablamos sobre los cambios clave en la nueva versi\u00f3n de este maravilloso producto de c\u00f3digo abierto.<\/p>\n<p>La informaci\u00f3n utilizada para la preparaci\u00f3n de este material se tom\u00f3 de <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.google.com\/spreadsheets\/u\/1\/d\/116X6E-lmDJG5UZPlqDAFw8hN9vS6SNY4qRNZ9fKtsMU\/edit#gid=0\">la tabla de seguimiento de mejoras de Kubernetes<\/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> y los issues, pull requests, Propuestas de Mejora de Kubernetes (KEP) correspondientes.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Comencemos con una importante introducci\u00f3n de SIG cluster-lifecycle: <b>cl\u00fasteres din\u00e1micos y tolerantes a fallos<\/b> Kubernetes (o, para ser m\u00e1s precisos, despliegues HA autoalojados) ahora <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/enhancements\/issues\/357\">se pueden crear<\/a><\/noindex> utilizando los comandos familiares (en el contexto de cl\u00fasteres de un solo nodo) <code>kubeadm<\/code> (<code>init<\/code> y <code>join<\/code>). En resumen, para esto:<\/p>\n<ul>\n<li> los certificados utilizados por el cl\u00faster se transfieren a secretos;<\/li>\n<li> para permitir el uso de etcd dentro del cl\u00faster de K8s (es decir, eliminar la dependencia externa que exist\u00eda anteriormente) se ha implementado <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/coreos\/etcd-operator\">etcd-operator<\/a><\/noindex>;<\/li>\n<li> se documentan las configuraciones recomendadas para el balanceador de carga externo que proporciona una configuraci\u00f3n tolerante a fallos (en el futuro se planea la posibilidad de renunciar a esta dependencia tambi\u00e9n, pero no en esta etapa).<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"Kubernetes 1.13: revisi\u00f3n de las principales novedades\" src=\"\/wp-content\/uploads\/2019\/03\/0e82b7e8db1ad117dc87f68fa4669431.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Arquitectura del cl\u00faster HA de Kubernetes creado con kubeadm<\/i><\/p>\n<p>Los detalles de la implementaci\u00f3n se pueden encontrar en <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.google.com\/document\/d\/1P3oUJ_kdaRSTlGONujadGBpYegjn4RjBNZLHZ4zU7lI\/edit#\">propuesta de dise\u00f1o<\/a><\/noindex>. Esta funci\u00f3n ha sido realmente esperada: la versi\u00f3n alfa se esperaba desde K8s 1.9, pero solo ha llegado ahora.<\/p>\n<h2>API<\/h2>\n<p>\nComando <code>aplicar<\/code> y en general <b>gesti\u00f3n declarativa de objetos<\/b> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/enhancements\/issues\/555\">se han extra\u00eddo<\/a><\/noindex> de <code>kubectl<\/code> en apiserver. Los propios desarrolladores explican brevemente su decisi\u00f3n se\u00f1alando que <code>kubectl apply<\/code> \u2014 una parte fundamental del trabajo con configuraciones en Kubernetes, sin embargo, \u00abest\u00e1 llena de errores y es dif\u00edcil de corregir\u00bb, por lo que esta funcionalidad necesita ser puesta en condiciones normales y trasladada al control plane. Ejemplos simples y claros de los problemas existentes hoy son:<\/p>\n<p><img decoding=\"async\" alt=\"Kubernetes 1.13: revisi\u00f3n de las principales novedades\" src=\"\/wp-content\/uploads\/2019\/03\/379b0d830491bbb0e7ac3c3ccfff71c4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLos detalles de la implementaci\u00f3n \u2014 en <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/enhancements\/blob\/master\/keps\/sig-api-machinery\/0006-apply.md\">KEP<\/a><\/noindex>. La preparaci\u00f3n actual \u2014 versi\u00f3n alfa (se planea avanzar a beta en el pr\u00f3ximo lanzamiento de Kubernetes).<\/p>\n<p>En la versi\u00f3n alfa se ha hecho disponible <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/enhancements\/issues\/692\">la posibilidad<\/a><\/noindex> el uso del esquema OpenAPI v3 para <b>crear y publicar documentaci\u00f3n OpenAPI para CustomResources<\/b> (CR), utilizados para la validaci\u00f3n (del lado del servidor) de los recursos de K8s definidos por el usuario (CustomResourceDefinition, CRD). La publicaci\u00f3n de OpenAPI para CRD permite a los clientes (por ejemplo, <code>kubectl<\/code>) realizar la validaci\u00f3n del lado del cliente (dentro de <code>kubectl create<\/code> y <code>kubectl apply<\/code>) y producir documentaci\u00f3n del esquema (<code>kubectl explain<\/code>). M\u00e1s detalles \u2014 en <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>Los registros existentes anteriormente <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/74837\">ahora se abren<\/a><\/noindex> con la bandera <code>O_APPEND<\/code> (y no <code>O_TRUNC<\/code>) para evitar la p\u00e9rdida de registros en algunas situaciones y para facilitar el truncamiento de registros mediante utilidades externas para la rotaci\u00f3n.<\/p>\n<p>Tambi\u00e9n en el contexto de la API de Kubernetes, se puede se\u00f1alar que en <code>PodSandbox<\/code> y <code>PodSandboxStatus<\/code> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/73833\">a\u00f1adido<\/a><\/noindex> el campo <code>runtime_handler<\/code> para tener en cuenta la informaci\u00f3n sobre <code>RuntimeClass<\/code> en el pod (lea m\u00e1s sobre \u00e9l en el texto sobre <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/424331\/\">la versi\u00f3n 1.12 de Kubernetes<\/a><\/noindex>, donde esta clase se introdujo como versi\u00f3n alfa), y en Admission Webhooks <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/74998\">se ha implementado<\/a><\/noindex> la capacidad de definir qu\u00e9 versiones <code>AdmissionReview<\/code> son compatibles. Finalmente, en las reglas de Admission Webhooks ahora <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/74477\">se puede limitar<\/a><\/noindex> los alcances de su aplicaci\u00f3n en los namespaces y l\u00edmites del cl\u00faster.<\/p>\n<h2>Almacenamientos<\/h2>\n<p>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/storage\/volumes\/#local\"><code><b>Vol\u00famenesLocalPersistentes<\/b><\/code><\/a><\/noindex>, que ten\u00edan estatus de versi\u00f3n beta desde el lanzamiento <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\">se han declarado<\/a><\/noindex> estables (GA): este feature gate ya no se desactiva y se eliminar\u00e1 en Kubernetes 1.17.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/enhancements\/issues\/559\">Posibilidad<\/a><\/noindex> el uso de variables de entorno llamadas <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> (por ejemplo, el nombre del pod) para los nombres de directorios montados como <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/storage\/volumes\/#using-subpath\"><code>subPath<\/code><\/a><\/noindex>, ha evolucionado \u2014 en forma de un nuevo campo <code>subPathExpr<\/code>, mediante el cual ahora se determina el nombre de directorio necesario. Esta funci\u00f3n apareci\u00f3 inicialmente en Kubernetes 1.11, pero tambi\u00e9n permaneci\u00f3 en estado alfa para 1.14.<\/p>\n<p>Al igual que en la versi\u00f3n anterior de Kubernetes, se presentan muchos cambios significativos para el en desarrollo CSI (Container Storage Interface):<\/p>\n<h3>CSI<\/h3>\n<p>\nSe ha hecho disponible (en versi\u00f3n alfa) <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/enhancements\/issues\/556\">soporte<\/a><\/noindex> <b>cambio de tama\u00f1o para vol\u00famenes CSI.<\/b>Para utilizarlo, ser\u00e1 necesario activar el feature gate llamado <code>ExpandCSIVolumes<\/code>, as\u00ed como contar con el soporte para esta operaci\u00f3n en el controlador CSI espec\u00edfico.<\/p>\n<p>Otra caracter\u00edstica de CSI en versi\u00f3n alfa \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/enhancements\/issues\/596\">la posibilidad<\/a><\/noindex> referirse directamente (es decir, sin usar PV\/PVC) a vol\u00famenes CSI dentro de la especificaci\u00f3n de los pods. Esto <b>elimina la restricci\u00f3n de utilizar CSI exclusivamente como almacenamiento de datos remoto<\/b>, abriendo puertas a <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes-csi.github.io\/docs\/ephemeral-local-volumes.html\">vol\u00famenes ef\u00edmeros locales.<\/a><\/noindex>Para su uso (<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/vladimirvivien\/kubernetes.github.io\/blob\/b78107abfdb2b5877973b84062d93cdf98ef1b9c\/content\/en\/docs\/concepts\/storage\/volumes.md#csi-ephemeral-volumes\">ejemplo de la documentaci\u00f3n<\/a><\/noindex>) es necesario activar <code>el feature gate CSIInlineVolume.<\/code> Ha habido avances tambi\u00e9n en las 'entra\u00f1as' de Kubernetes relacionados con CSI, que no son tan evidentes para los usuarios finales (administradores del sistema)... En este momento, los desarrolladores se ven obligados a mantener dos versiones de cada plugin de almacenamiento: una 'a la antigua', dentro de la base de c\u00f3digo de K8s (in-tree), y la segunda \u2014 dentro del nuevo CSI<\/p>\n<p>(para m\u00e1s detalles, consulte, por ejemplo, en <i>(lea m\u00e1s sobre \u00e9l, por ejemplo, en <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/424211\/\">aqu\u00ed<\/a><\/noindex>)<\/i>. Esto provoca incomodidades comprensibles que deben ser solucionadas a medida que se estabiliza CSI como tal. Simplemente declarar obsoletos (deprecated) a los APIs internos (in-tree) de los plugins no es posible debido a <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/reference\/using-api\/deprecation-policy\/#deprecating-parts-of-the-api\">la pol\u00edtica correspondiente de Kubernetes<\/a><\/noindex>.<\/p>\n<p>Todo esto ha llevado a que las versiones alfa hayan alcanzado <b><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/enhancements\/issues\/625\">el proceso de migraci\u00f3n<\/a><\/noindex> del c\u00f3digo interno de los plugins<\/b>, implementados como in-tree, a plugins CSI, lo que permitir\u00e1 a los desarrolladores preocuparse por mantener una sola versi\u00f3n de sus plugins, asegurando la compatibilidad con los APIs antiguos y permitiendo que sean declarados obsoletos de la manera habitual. Se espera que para la pr\u00f3xima versi\u00f3n de Kubernetes (1.15) se complete la migraci\u00f3n de todos los plugins de proveedores de la nube, que la implementaci\u00f3n alcance el estado beta y se active en las instalaciones de K8s por defecto. Para m\u00e1s detalles, consulte <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/community\/blob\/master\/contributors\/design-proposals\/storage\/csi-migration.md\">propuesta de dise\u00f1o<\/a><\/noindex>. Como consecuencia de esta migraci\u00f3n tambi\u00e9n surgi\u00f3 <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/74544\">la eliminaci\u00f3n<\/a><\/noindex> de las restricciones para vol\u00famenes definidos por proveedores de nube espec\u00edficos (AWS, Azure, GCE, Cinder).<\/p>\n<p>Adem\u00e1s, se ha a\u00f1adido soporte para dispositivos de bloque con CSI (<code>CSIBlockVolume<\/code>) <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/74909\">se ha trasladado<\/a><\/noindex> a versi\u00f3n beta.<\/p>\n<h2>Nodos \/ Kubelet<\/h2>\n<p>\nSe ha presentado la versi\u00f3n alfa <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/enhancements\/issues\/727\">de un nuevo endpoint<\/a><\/noindex> en Kubelet, destinado a <b>proporcionar m\u00e9tricas sobre recursos clave<\/b>. En t\u00e9rminos generales, si antes Kubelet obten\u00eda estad\u00edsticas de uso de contenedores de cAdvisor, ahora estos datos provienen del entorno de ejecuci\u00f3n del contenedor a trav\u00e9s de CRI (Container Runtime Interface), aunque se ha mantenido la compatibilidad para trabajar con versiones antiguas de Docker. Antes, las estad\u00edsticas recolectadas en Kubelet se entregaban a trav\u00e9s de REST API, y ahora se utiliza un endpoint ubicado en <code>\/metrics\/resource\/v1alpha1<\/code>. La estrategia a largo plazo de los desarrolladores <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/issues\/68522\">es<\/a><\/noindex> minimizar el conjunto de m\u00e9tricas proporcionadas por Kubelet. <i>Por cierto, estas m\u00e9tricas <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/enhancements\/pull\/726\">ahora se llaman<\/a><\/noindex> no \u00abcore metrics\u00bb, sino \u00abresource metrics\u00bb, y se describen como \u00abfirst-class resources, como CPU y memoria\u00bb.<\/i><\/p>\n<p>Un matiz interesante: a pesar de la clara ventaja de rendimiento del endpoint gRPC en comparaci\u00f3n con varios casos de uso del formato Prometheus <i>(resultado de uno de los benchmarks, ver m\u00e1s abajo)<\/i>, los autores prefirieron el formato de texto de Prometheus debido al claro liderazgo de este sistema de monitoreo en la comunidad.<\/p>\n<blockquote><p><i>\u00abgRPC no es compatible con los principales pipelines de monitoreo. El endpoint solo ser\u00e1 \u00fatil para entregar m\u00e9tricas al Metrics Server o a componentes de monitoreo que se integren directamente con \u00e9l. Al utilizar el almacenamiento en cach\u00e9 en el Metrics Server, el rendimiento del formato de texto de Prometheus <b>es suficientemente bueno<\/b> para nosotros como para preferir Prometheus en lugar de gRPC, dado que Prometheus es ampliamente utilizado en la comunidad. Cuando el formato OpenMetrics sea m\u00e1s estable, podremos acercarnos al rendimiento de gRPC con un formato basado en proto\u00bb.<\/i><\/p><\/blockquote>\n<p>\n<img decoding=\"async\" alt=\"Kubernetes 1.13: revisi\u00f3n de las principales novedades\" src=\"\/wp-content\/uploads\/2019\/03\/ad7e45b61fc4676a2df3c2d33d5688b5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Una de las pruebas comparativas de rendimiento del uso de los formatos gRPC y Prometheus en el nuevo endpoint de Kubelet para m\u00e9tricas. M\u00e1s gr\u00e1ficos y otros detalles se pueden encontrar en <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>Entre otros cambios:<\/p>\n<ul>\n<li> Kubelet ahora (una vez) <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/73802\">intenta detener<\/a><\/noindex> los contenedores en estado desconocido (unknown) antes de las operaciones de reinicio y eliminaci\u00f3n.<\/li>\n<li> Al usar <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/workloads\/pods\/podpreset\/\"><code>PodPresets<\/code><\/a><\/noindex> ahora se agrega la misma informaci\u00f3n al contenedor init <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/71479\">que al contenedor normal.<\/a><\/noindex> Kubelet<\/li>\n<li> ha comenzado a utilizar <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/73659\">usageNanoCores<\/a><\/noindex> <code>del proveedor de estad\u00edsticas CRI, y para nodos y contenedores en Windows<\/code> estad\u00edsticas de red. <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/74788\">se ha a\u00f1adido<\/a><\/noindex> La informaci\u00f3n sobre el sistema operativo y la arquitectura ahora se registra en las etiquetas<\/li>\n<li> kubernetes.io\/os <code>kubernetes.io\/arch<\/code> y <code>de los objetos Node (migrado de beta a GA).<\/code> La capacidad de especificar un grupo de usuario del sistema espec\u00edfico para contenedores en un pod (<\/li>\n<li> La posibilidad de especificar un grupo de usuarios del sistema espec\u00edfico para contenedores en el pod (<code>, fue introducida en<\/code>K8s 1.11 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/415349\/\">se avanz\u00f3<\/a><\/noindex>) <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/73007\">a la versi\u00f3n beta (activada por defecto).<\/a><\/noindex> du y find, utilizados en cAdvisor,<\/li>\n<li> fueron reemplazados <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/74675\">por implementaciones en Go.<\/a><\/noindex> CLI<\/li>\n<\/ul>\n<p><\/p>\n<h2>en cli-runtime y kubectl<\/h2>\n<p>\nel flag -k para integraci\u00f3n con <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/74140\">se ha agregado<\/a><\/noindex> (por cierto, su desarrollo ahora se lleva a cabo en un repositorio separado), es decir, para procesar archivos YAML adicionales de directorios especiales de kustomization (detalles sobre su uso se pueden encontrar en <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes-sigs\/kustomize\"><b>kustomize<\/b><\/a><\/noindex> Ejemplo de uso simple del archivo <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=\"Kubernetes 1.13: revisi\u00f3n de las principales novedades\" src=\"\/wp-content\/uploads\/2019\/03\/e38550cfb642d81237aad4d87b9b3386.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>kustomization <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes-sigs\/kustomize\/blob\/master\/docs\/glossary.md#kustomization\">(tambi\u00e9n se puede aplicar kustomize de manera m\u00e1s compleja dentro de<\/a><\/noindex> overlays <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes-sigs\/kustomize\/blob\/master\/docs\/glossary.md#overlay\">Adem\u00e1s:<\/a><\/noindex>)<\/i><\/p>\n<p>nueva comando<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/71651\">Se ha a\u00f1adido<\/a><\/noindex> kubectl create cronjob <code>, cuyo nombre lo dice todo.<\/code>kubectl logs<\/li>\n<li> En <code>combina<\/code> ahora es posible <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/67573\">--follow<\/a><\/noindex> flags <code>-f<\/code> (<code>para la transmisi\u00f3n de logs) y<\/code> --selector <code>-l<\/code> (<code>para la consulta por etiquetas).<\/code> se aprendi\u00f3<\/li>\n<li> kubectl <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/72641\">a copiar archivos seleccionados con comodines.<\/a><\/noindex> El comando<\/li>\n<li> kubectl wait <code>--all<\/code> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/70599\">se ha a\u00f1adido<\/a><\/noindex> bandera <code>para seleccionar todos los recursos en el espacio de nombres del tipo de recursos especificado.<\/code> Las siguientes caracter\u00edsticas recibieron estado estable (GA):<\/li>\n<\/ul>\n<p><\/p>\n<h2>Otros<\/h2>\n<p>\nReadinessGate<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/workloads\/pods\/pod-lifecycle\/#pod-readiness-gate\"><code>, utilizado en la especificaci\u00f3n del pod para definir condiciones adicionales que se consideran para la disponibilidad del pod;<\/code><\/a><\/noindex>, utilizado en la especificaci\u00f3n del pod para definir condiciones adicionales consideradas en la disponibilidad del pod;<\/li>\n<li> Soporte para p\u00e1ginas grandes (feature gate llamada <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> API de PriorityClass, <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/configuration\/pod-priority-preemption\/\">Prioridad de Pod y Preemption<\/a><\/noindex>.<\/li>\n<\/ul>\n<p>\nOtros cambios introducidos en Kubernetes 1.14:<\/p>\n<ul>\n<li> La pol\u00edtica RBAC por defecto ya no permite el acceso al API <code>discovery<\/code> y <code>access-review<\/code> a usuarios sin autenticaci\u00f3n <i>(unauthenticated)<\/i>.<\/li>\n<li> El soporte oficial de CoreDNS <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/69940\">est\u00e1 disponible<\/a><\/noindex> solo para Linux, por lo que al usar kubeadm para su (CoreDNS) implementaci\u00f3n en el cl\u00faster, los nodos deben funcionar solo en Linux (para esta limitaci\u00f3n se utilizan nodeSelectors).<\/li>\n<li> La configuraci\u00f3n por defecto de CoreDNS ahora <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/73267\">utiliza<\/a><\/noindex> <noindex><a rel=\"nofollow\" href=\"https:\/\/coredns.io\/plugins\/forward\/\">plugin forward<\/a><\/noindex> en lugar de proxy. Adem\u00e1s, en CoreDNS <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/74137\">se ha a\u00f1adido<\/a><\/noindex> readinessProbe, que previene el balanceo de carga en los pods correspondientes (no listos para ser atendidos).<\/li>\n<li> En kubeadm, en las fases <code>init<\/code> o <code>upload-certs<\/code>, <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/73907\">se ha hecho posible<\/a><\/noindex> cargar los certificados necesarios para conectar un nuevo control-plane al secreto kubeadm-certs (se usa el flag <code>--experimental-upload-certs<\/code>).<\/li>\n<li> Para instalaciones de Windows, hay una versi\u00f3n alfa <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/enhancements\/issues\/689\">de soporte<\/a><\/noindex> gMSA (Cuenta de Servicio Administrado por Grupo) \u2014 cuentas especiales en Active Directory que pueden ser utilizadas tambi\u00e9n por contenedores.<\/li>\n<li> Para GCE <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/70144\">se activ\u00f3<\/a><\/noindex> la encriptaci\u00f3n mTLS entre etcd y kube-apiserver.<\/li>\n<li> Actualizaciones en el software utilizado\/dependiente: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, soporte de Docker 18.09 en kubeadm, y la versi\u00f3n m\u00ednima soportada de la API de Docker es 1.26.<\/li>\n<\/ul>\n<p><\/p>\n<h2>P.D.<\/h2>\n<p>\nTambi\u00e9n puedes leer en nuestro blog:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/flant\/blog\/432208\/\">Kubernetes 1.12: revisi\u00f3n de las principales novedades<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/flant\/blog\/424331\/\">\ud83e\udd47Kubernetes 1.16: revisi\u00f3n de las principales novedades | ProHoster<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/flant\/blog\/415349\/\">Kubernetes 1.11: resumen de las novedades principales<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/flant\/blog\/353114\/\">Kubernetes 1.10: resumen de las novedades principales<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Fuente: <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.2 - 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\/es\/blog\/kubernetes-1-14-obzor-osnovnyh-novshestv\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"es_ES\" \/>\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\/es\/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: resumen de las novedades principales | ProHoster","description":"Esta noche","canonical_url":"https:\/\/prohoster.info\/es\/blog\/kubernetes-1-14-obzor-osnovnyh-novshestv","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","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\/es\/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\/es\/wp-json\/wp\/v2\/posts\/30272","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=30272"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/30272\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=30272"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=30272"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=30272"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}