{"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\/pt\/blog\/kubernetes-1-14-obzor-osnovnyh-novshestv","title":{"rendered":"Kubernetes 1.14: vis\u00e3o geral das principais inova\u00e7\u00f5es","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Kubernetes 1.14: vis\u00e3o geral das principais inova\u00e7\u00f5es\" src=\"\/wp-content\/uploads\/2019\/03\/8fb5be29668f55ec42d31eb47200b639.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEsta noite <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/sig-release\/tree\/master\/releases\/release-1.14#timeline\">ter\u00e1<\/a><\/noindex> mais um lan\u00e7amento do Kubernetes \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/sig-release\/tree\/master\/releases\/release-1.14\">1.14<\/a><\/noindex>. De acordo com a tradi\u00e7\u00e3o do nosso blog, falamos sobre as principais mudan\u00e7as na nova vers\u00e3o deste maravilhoso produto Open Source.<\/p>\n<p>As informa\u00e7\u00f5es usadas para preparar este material foram retiradas de <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.google.com\/spreadsheets\/u\/1\/d\/116X6E-lmDJG5UZPlqDAFw8hN9vS6SNY4qRNZ9fKtsMU\/edit#gid=0\">tabela de rastreamento de melhorias do 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> e dos respectivos issues, pull requests, Propostas de Melhoria do Kubernetes (KEP).<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Comecemos com uma introdu\u00e7\u00e3o importante do SIG cluster-lifecycle: <b>clusters din\u00e2micos e tolerantes a falhas<\/b> O Kubernetes (ou, mais precisamente, implanta\u00e7\u00f5es HA autogeridas) agora <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/enhancements\/issues\/357\">podem ser criados<\/a><\/noindex> com os comandos habituais (no contexto de clusters de um \u00fanico n\u00f3) <code>kubeadm<\/code> (<code>init<\/code> e <code>join<\/code>). Em resumo, para isso:<\/p>\n<ul>\n<li> os certificados usados pelo cluster s\u00e3o transferidos para os segredos;<\/li>\n<li> para permitir o uso do etcd dentro do cluster K8s (ou seja, eliminando a depend\u00eancia externa existente), foi utilizado <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/coreos\/etcd-operator\">etcd-operator<\/a><\/noindex>;<\/li>\n<li> as configura\u00e7\u00f5es recomendadas para o balanceador de carga externo que fornece uma configura\u00e7\u00e3o tolerante a falhas s\u00e3o documentadas (futuramente est\u00e1 prevista a possibilidade de eliminar tamb\u00e9m essa depend\u00eancia, mas n\u00e3o neste est\u00e1gio).<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"Kubernetes 1.14: vis\u00e3o geral das principais inova\u00e7\u00f5es\" src=\"\/wp-content\/uploads\/2019\/03\/0e82b7e8db1ad117dc87f68fa4669431.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Arquitetura do cluster HA do Kubernetes, criado com kubeadm<\/i><\/p>\n<p>Para mais detalhes sobre a implementa\u00e7\u00e3o, voc\u00ea pode consultar <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.google.com\/document\/d\/1P3oUJ_kdaRSTlGONujadGBpYegjn4RjBNZLHZ4zU7lI\/edit#\">proposta de design<\/a><\/noindex>. Este recurso foi realmente esperado: a vers\u00e3o alfa era esperada desde o K8s 1.9, mas surgiu apenas agora.<\/p>\n<h2>API<\/h2>\n<p>\nTime <code>apply<\/code> e, de modo geral, <b>gerenciamento declarativo de objetos<\/b> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/enhancements\/issues\/555\">foram extra\u00eddos<\/a><\/noindex> do <code>kubectl<\/code> para o apiserver. Os pr\u00f3prios desenvolvedores explicam sua decis\u00e3o dizendo que <code>kubectl apply<\/code> \u00e9 uma parte fundamental do trabalho com as configura\u00e7\u00f5es no Kubernetes, no entanto, \"est\u00e1 cheia de bugs e \u00e9 dif\u00edcil de corrigir\", raz\u00e3o pela qual essa funcionalidade precisa ser aprimorada e transferida para o controle de planeamento. Exemplos simples e ilustrativos dos problemas existentes hoje:<\/p>\n<p><img decoding=\"async\" alt=\"Kubernetes 1.14: vis\u00e3o geral das principais inova\u00e7\u00f5es\" src=\"\/wp-content\/uploads\/2019\/03\/379b0d830491bbb0e7ac3c3ccfff71c4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMais detalhes sobre a implementa\u00e7\u00e3o est\u00e3o em <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/enhancements\/blob\/master\/keps\/sig-api-machinery\/0006-apply.md\">KEP<\/a><\/noindex>. A prontid\u00e3o atual \u00e9 a vers\u00e3o alfa (o avan\u00e7o para beta est\u00e1 planejado para o pr\u00f3ximo lan\u00e7amento do Kubernetes).<\/p>\n<p>A vers\u00e3o alfa agora disponibiliza <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/enhancements\/issues\/692\">a possibilidade<\/a><\/noindex> de usar o esquema OpenAPI v3 para <b>cria\u00e7\u00e3o e publica\u00e7\u00e3o da documenta\u00e7\u00e3o OpenAPI para CustomResources<\/b> (CR), usados para valida\u00e7\u00e3o (no lado do servidor) de recursos K8s definidos pelo usu\u00e1rio (CustomResourceDefinition, CRD). A publica\u00e7\u00e3o do OpenAPI para CRD permite que os clientes (por exemplo, <code>kubectl<\/code>) realizem valida\u00e7\u00e3o em seu lado (no \u00e2mbito de <code>kubectl create<\/code> e <code>kubectl apply<\/code>) e gerar documenta\u00e7\u00e3o com o esquema (<code>kubectl explain<\/code>). Detalhes \u2014 em <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>Os logs existentes anteriormente <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/74837\">agora s\u00e3o abertos<\/a><\/noindex> com a flag <code>O_APPEND<\/code> (e n\u00e3o <code>O_TRUNC<\/code>) para evitar a perda de logs em algumas situa\u00e7\u00f5es e para facilitar o truncamento de logs com utilit\u00e1rios externos para rota\u00e7\u00e3o.<\/p>\n<p>No contexto da API do Kubernetes, tamb\u00e9m se pode observar que <code>PodSandbox<\/code> e <code>PodSandboxStatus<\/code> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/73833\">adicionado<\/a><\/noindex> campo <code>runtime_handler<\/code> para levar em conta informa\u00e7\u00f5es sobre <code>RuntimeClass<\/code> no pod (saiba mais sobre isso no texto sobre <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/424331\/\">o lan\u00e7amento do Kubernetes 1.12<\/a><\/noindex>, onde essa classe surgiu como vers\u00e3o alfa), e nos Admission Webhooks <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/74998\">s\u00e3o implementadas<\/a><\/noindex> a possibilidade de definir quais vers\u00f5es <code>AdmissionReview<\/code> eles suportam. Finalmente, nas regras dos Admission Webhooks agora <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/74477\">\u00e9 poss\u00edvel limitar<\/a><\/noindex> as escalas de sua aplica\u00e7\u00e3o em namespaces e limites de cluster.<\/p>\n<h2>Armazenamentos<\/h2>\n<p>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/storage\/volumes\/#local\"><code><b>Volumes Locais Persistentes<\/b><\/code><\/a><\/noindex>, que tinham status de vers\u00e3o beta desde o lan\u00e7amento <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\">foram declarados<\/a><\/noindex> est\u00e1veis (GA): esse recurso n\u00e3o ser\u00e1 mais desativado e ser\u00e1 removido no Kubernetes 1.17.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/enhancements\/issues\/559\">Possibilidade<\/a><\/noindex> o uso de vari\u00e1veis de ambiente do chamado <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 exemplo, o nome do pod) para nomes de diret\u00f3rios montados como <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/storage\/volumes\/#using-subpath\"><code>subPath<\/code><\/a><\/noindex>, foi aprimorado \u2014 na forma de um novo campo <code>subPathExpr<\/code>, que agora determina o nome do diret\u00f3rio necess\u00e1rio. Inicialmente, esse recurso apareceu no Kubernetes 1.11, mas permaneceu na vers\u00e3o alfa para 1.14.<\/p>\n<p>Como na vers\u00e3o anterior do Kubernetes, muitas mudan\u00e7as significativas foram apresentadas para o em desenvolvimento ativo CSI (Interface de Armazenamento de Cont\u00eainer):<\/p>\n<h3>CSI<\/h3>\n<p>\nAgora est\u00e1 dispon\u00edvel (no \u00e2mbito da vers\u00e3o alfa) <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/enhancements\/issues\/556\">suporte<\/a><\/noindex> <b>para redimensionamento de volumes CSI.<\/b>Para us\u00e1-lo, ser\u00e1 necess\u00e1rio ativar o recurso conhecido como <code>ExpandCSIVolumes<\/code>, bem como o suporte a essa opera\u00e7\u00e3o no driver CSI espec\u00edfico.<\/p>\n<p>Mais uma funcionalidade para o CSI na vers\u00e3o alfa \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/enhancements\/issues\/596\">a possibilidade<\/a><\/noindex> referenciar diretamente (ou seja, sem o uso de PV\/PVC) volumes CSI dentro da especifica\u00e7\u00e3o dos pods. Isso <b>remove a limita\u00e7\u00e3o de usar o CSI exclusivamente como armazenamento de dados remotos<\/b>, abrindo para eles as portas para o mundo dos <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes-csi.github.io\/docs\/ephemeral-local-volumes.html\">volumes ef\u00eameros locais.<\/a><\/noindex>Para 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\">exemplo da documenta\u00e7\u00e3o<\/a><\/noindex>) \u00e9 necess\u00e1rio ativar <code>o recurso de volume inline CSI<\/code> .<\/p>\n<p>Houve progresso tamb\u00e9m nas 'entranhas' do Kubernetes relacionadas ao CSI, que n\u00e3o s\u00e3o t\u00e3o vis\u00edveis para os usu\u00e1rios finais (administradores de sistema)\u2026 Neste momento, os desenvolvedores s\u00e3o obrigados a manter duas vers\u00f5es de cada plugin de armazenamento: uma \u2014 'do jeito antigo', dentro do c\u00f3digo do K8s (in-tree), e a outra \u2014 no novo CSI <i>(para mais detalhes, consulte, por exemplo, o <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/424211\/\">aqui<\/a><\/noindex>)<\/i>. Isso causa inconvenientes compreens\u00edveis que precisam ser resolvidos \u00e0 medida que o CSI se estabiliza. Simplesmente declarar APIs internas (in-tree) obsoletas (deprecated) n\u00e3o \u00e9 vi\u00e1vel devido \u00e0 <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/reference\/using-api\/deprecation-policy\/#deprecating-parts-of-the-api\">pol\u00edtica correspondente do Kubernetes.<\/a><\/noindex>.<\/p>\n<p>Tudo isso levou ao fato de que as vers\u00f5es alfa alcan\u00e7aram <b><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/enhancements\/issues\/625\">o processo de migra\u00e7\u00e3o<\/a><\/noindex> do c\u00f3digo interno dos plugins<\/b>, implementados como in-tree, para plugins CSI, reduzindo assim a carga dos desenvolvedores para manter uma \u00fanica vers\u00e3o de seus plugins, enquanto a compatibilidade com APIs anteriores ser\u00e1 mantida, permitindo que sejam declaradas obsoletas de acordo com o cen\u00e1rio padr\u00e3o. Espera-se que at\u00e9 o pr\u00f3ximo lan\u00e7amento do Kubernetes (1.15) a migra\u00e7\u00e3o de todos os plugins de provedores de nuvem seja conclu\u00edda, e a implementa\u00e7\u00e3o receba status de vers\u00e3o beta e seja ativada em instala\u00e7\u00f5es K8s por padr\u00e3o. Mais detalhes podem ser encontrados em <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/community\/blob\/master\/contributors\/design-proposals\/storage\/csi-migration.md\">proposta de design<\/a><\/noindex>. Uma consequ\u00eancia dessa migra\u00e7\u00e3o tamb\u00e9m foi <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/74544\">a rejei\u00e7\u00e3o<\/a><\/noindex> das restri\u00e7\u00f5es para volumes definidos por provedores de nuvem espec\u00edficos (AWS, Azure, GCE, Cinder).<\/p>\n<p>Al\u00e9m disso, o suporte a dispositivos de bloco com CSI (<code>CSIBlockVolume<\/code>) <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/74909\">foi<\/a><\/noindex> trazido<\/p>\n<h2>\u00e0 vers\u00e3o beta.<\/h2>\n<p>\nN\u00f3s\/Kubelet <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/enhancements\/issues\/727\">Foi apresentada a vers\u00e3o alfa de<\/a><\/noindex> um novo endpoint <b>no Kubelet, destinado a<\/b>fornecer m\u00e9tricas sobre os principais recursos. <code>\/metrics\/resource\/v1alpha1<\/code>. De um modo geral, enquanto antes o Kubelet recebia estat\u00edsticas de uso de cont\u00eaineres do cAdvisor, agora esses dados s\u00e3o provenientes do ambiente de execu\u00e7\u00e3o de cont\u00eainer atrav\u00e9s do CRI (Container Runtime Interface), mantendo, no entanto, a compatibilidade com vers\u00f5es antigas do Docker. Anteriormente, as estat\u00edsticas coletadas no Kubelet eram fornecidas atrav\u00e9s da API REST, e agora isso \u00e9 feito por meio de um endpoint localizado em <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/issues\/68522\">. A estrat\u00e9gia de longo prazo dos desenvolvedores<\/a><\/noindex> \u00e9 minimizar o conjunto de m\u00e9tricas fornecidas pelo Kubelet. <i>Ali\u00e1s, essas m\u00e9tricas <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/enhancements\/pull\/726\">agora s\u00e3o chamadas<\/a><\/noindex> de 'resource metrics', em vez de 'core metrics', e descrevem como 'recursos de primeira classe, como CPU e mem\u00f3ria'.<\/i><\/p>\n<p>Uma nuance bastante interessante: apesar da clara vantagem de desempenho do endpoint gRPC em compara\u00e7\u00e3o com v\u00e1rios casos de uso do formato Prometheus <i>(resultado de um dos benchmarks, veja abaixo)<\/i>, os autores preferiram o formato de texto do Prometheus devido \u00e0 clara lideran\u00e7a deste sistema de monitoramento na comunidade.<\/p>\n<blockquote><p><i>\u00abgRPC n\u00e3o \u00e9 compat\u00edvel com os principais pipelines de monitoramento. O Endpoint ser\u00e1 \u00fatil apenas para fornecer m\u00e9tricas ao Metrics Server ou componentes de monitoramento que se integram diretamente a ele. Ao usar o cache no Metrics Server, o desempenho do formato de texto Prometheus <b>\u00e9 bastante bom<\/b> para n\u00f3s, preferirmos Prometheus em vez de gRPC, dada a ampla aceita\u00e7\u00e3o do Prometheus na comunidade. Quando o formato OpenMetrics se tornar mais est\u00e1vel, poderemos nos aproximar do desempenho do gRPC usando o formato baseado em proto\u00bb.<\/i><\/p><\/blockquote>\n<p>\n<img decoding=\"async\" alt=\"Kubernetes 1.14: vis\u00e3o geral das principais inova\u00e7\u00f5es\" src=\"\/wp-content\/uploads\/2019\/03\/ad7e45b61fc4676a2df3c2d33d5688b5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Um dos testes comparativos de desempenho utilizando os formatos gRPC e Prometheus no novo endpoint do Kubelet para m\u00e9tricas. Mais gr\u00e1ficos e outros detalhes podem ser encontrados em <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 outras mudan\u00e7as:<\/p>\n<ul>\n<li> O Kubelet agora (uma vez) <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/73802\">tenta parar<\/a><\/noindex> os cont\u00eaineres em estado desconhecido antes das opera\u00e7\u00f5es de rein\u00edcio e exclus\u00e3o.<\/li>\n<li> Ao usar <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/workloads\/pods\/podpreset\/\"><code>PodPresets<\/code><\/a><\/noindex> agora \u00e9 adicionado ao init-cont\u00eainer <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/71479\">as mesmas informa\u00e7\u00f5es que para um cont\u00eainer normal.<\/a><\/noindex> Kubelet<\/li>\n<li> come\u00e7ou a usar <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/73659\">usageNanoCores<\/a><\/noindex> <code>do provedor de estat\u00edsticas CRI, e para n\u00f3s e cont\u00eaineres no Windows<\/code> estat\u00edsticas de rede. <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/74788\">foi adicionada<\/a><\/noindex> As informa\u00e7\u00f5es sobre o sistema operacional e a arquitetura agora s\u00e3o gravadas nos r\u00f3tulos<\/li>\n<li> kubernetes.io\/os <code>kubernetes.io\/arch<\/code> e <code>dos objetos Node (transferido da beta para GA).<\/code> A capacidade de especificar um grupo de usu\u00e1rios do sistema espec\u00edfico para cont\u00eaineres no pod (<\/li>\n<li> A capacidade de especificar um grupo espec\u00edfico de usu\u00e1rios do sistema para cont\u00eaineres no pod (<code>, foi introduzida no<\/code>K8s 1.11 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/415349\/\">e evoluiu<\/a><\/noindex>) <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/73007\">para beta (ativado por padr\u00e3o).<\/a><\/noindex> du e find, usados no cAdvisor,<\/li>\n<li> foram substitu\u00eddos <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/74675\">por implementa\u00e7\u00f5es em Go.<\/a><\/noindex> No cli-runtime e kubectl<\/li>\n<\/ul>\n<p><\/p>\n<h2>CLI<\/h2>\n<p>\nfoi adicionado <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/74140\">o sinalizador -k para integra\u00e7\u00e3o com<\/a><\/noindex> kustomize <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes-sigs\/kustomize\"><b>(a prop\u00f3sito, seu desenvolvimento agora \u00e9 feito em um reposit\u00f3rio separado), ou seja, para processar arquivos YAML adicionais de diret\u00f3rios especiais de kustomization (detalhes sobre seu uso podem ser encontrados em<\/b><\/a><\/noindex> Exemplo de uso simples do arquivo <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.14: vis\u00e3o geral das principais inova\u00e7\u00f5es\" 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\">(tamb\u00e9m \u00e9 poss\u00edvel uma aplica\u00e7\u00e3o mais complexa do kustomize dentro de<\/a><\/noindex> overlays <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes-sigs\/kustomize\/blob\/master\/docs\/glossary.md#overlay\">Al\u00e9m disso:<\/a><\/noindex>)<\/i><\/p>\n<p>nova comando<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/71651\">Adicionada<\/a><\/noindex> kubectl create cronjob <code>, cujo nome fala por si.<\/code>kubectl logs<\/li>\n<li> Em <code>agora pode<\/code> ser combinado <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/67573\">com os sinalizadores<\/a><\/noindex> -f <code>--follow<\/code> (<code>para streaming de logs) e<\/code> -l <code>--selector<\/code> (<code>para query de label).<\/code> aprendemos<\/li>\n<li> kubectl <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/72641\">a copiar arquivos escolhidos por meio de wild card.<\/a><\/noindex> Na equipe<\/li>\n<li> kubectl wait <code>foi adicionado um sinalizador<\/code> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/70599\">adicionaram<\/a><\/noindex> --all <code>para selecionar todos os recursos no namespace do tipo de recurso especificado.<\/code> Outras<\/li>\n<\/ul>\n<p><\/p>\n<h2>O status est\u00e1vel (GA) foi obtido para os seguintes recursos:<\/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>ReadinessGate<\/code><\/a><\/noindex>, utilizado na especifica\u00e7\u00e3o do pod para determinar condi\u00e7\u00f5es adicionais consideradas na prontid\u00e3o do pod;<\/li>\n<li> Suporte a grandes p\u00e1ginas (feature gate chamada <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 PriorityClass, <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/configuration\/pod-priority-preemption\/\">Prioridade de Pod e Pr\u00e9-empo\u00e7amento<\/a><\/noindex>.<\/li>\n<\/ul>\n<p>\nOutras mudan\u00e7as apresentadas no Kubernetes 1.14:<\/p>\n<ul>\n<li> A pol\u00edtica RBAC padr\u00e3o n\u00e3o concede mais acesso \u00e0 API <code>discovery<\/code> e <code>access-review<\/code> para usu\u00e1rios sem autentica\u00e7\u00e3o <i>(unauthenticated)<\/i>.<\/li>\n<li> O suporte oficial ao CoreDNS <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/69940\">\u00e9 fornecido<\/a><\/noindex> apenas para Linux, portanto, ao usar kubeadm para a implanta\u00e7\u00e3o (do CoreDNS) no cluster, os n\u00f3s devem operar somente no Linux (para essa limita\u00e7\u00e3o s\u00e3o utilizados os nodeSelectors).<\/li>\n<li> A configura\u00e7\u00e3o padr\u00e3o do CoreDNS agora <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/73267\">usa<\/a><\/noindex> <noindex><a rel=\"nofollow\" href=\"https:\/\/coredns.io\/plugins\/forward\/\">o plugin forward<\/a><\/noindex> em vez de proxy. Al\u00e9m disso, no CoreDNS <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/74137\">foi adicionada<\/a><\/noindex> readinessProbe, prevenindo o balanceamento de carga em pods correspondentes (n\u00e3o prontos para atendimento).<\/li>\n<li> No kubeadm, nas fases <code>init<\/code> ou <code>upload-certs<\/code>, <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/73907\">agora \u00e9 poss\u00edvel<\/a><\/noindex> fazer upload de certificados necess\u00e1rios para conectar o novo control-plane ao segredo kubeadm-certs (o flag utilizado \u00e9 <code>--experimental-upload-certs<\/code>).<\/li>\n<li> Para instala\u00e7\u00f5es no Windows, uma vers\u00e3o alfa <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/enhancements\/issues\/689\">do suporte<\/a><\/noindex> gMSA (Group Managed Service Account) \u2014 contas de servi\u00e7o especiais no Active Directory que podem ser usadas por cont\u00eaineres.<\/li>\n<li> Para GCE <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/pull\/70144\">ativaram<\/a><\/noindex> criptografia mTLS entre etcd e kube-apiserver.<\/li>\n<li> Atualiza\u00e7\u00f5es no software utilizado\/dependente: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, suporte ao Docker 18.09 no kubeadm, e a vers\u00e3o m\u00ednima do API do Docker suportada tornou-se 1.26.<\/li>\n<\/ul>\n<p><\/p>\n<h2>P.S.<\/h2>\n<p>\nConfira tamb\u00e9m em nosso blog:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/flant\/blog\/432208\/\">Kubernetes 1.13: vis\u00e3o geral das principais novidades<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/flant\/blog\/424331\/\">Kubernetes 1.12: vis\u00e3o geral das principais novidades<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/flant\/blog\/415349\/\">Kubernetes 1.11: vis\u00e3o geral das principais novidades<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/flant\/blog\/353114\/\">Kubernetes 1.10: vis\u00e3o geral das principais novidades<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Fonte: <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.3 - 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\/pt\/blog\/kubernetes-1-14-obzor-osnovnyh-novshestv\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"pt_PT\" \/>\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\/pt\/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: vis\u00e3o geral das principais novidades | ProHoster","description":"Esta noite","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/kubernetes-1-14-obzor-osnovnyh-novshestv","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","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\/pt\/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\/pt\/wp-json\/wp\/v2\/posts\/30272","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=30272"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/30272\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=30272"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=30272"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=30272"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}