‫Deixe-me falar sobre pistas secas e diferenças, que
‫são novidades.
‫As últimas versões do Kubernetes, começando com 1. 13 têm
‫essa nova opção que nos permite ver
‫o que vamos mudar antes de mudar.
‫Já vimos isso antes.
‫Eu mostrei alguns exemplos anteriormente no curso.
‫Mas, esse método de usá-lo com
‫o comando apply é novo
‫e melhor. O que tínhamos no
‫passado era uma corrida a seco, mas era apenas
‫para o cliente. O cliente não falou
‫com o servidor para dizer: ei, esses recursos já estão lá?
‫Preciso recriá-los, ou eles serão atualizados ou o que vai
‫acontecer? Direito.
‫Isso não aconteceu antes.
‫Agora há uma opção de execução a seco
‫do servidor que enviará o YAML ao servidor e comparará,
‫descubra o que realmente precisa acontecer e, em seguida,
‫relate novamente à linha de comando o
‫que vai mudar. Vamos ver isso em ação.
‫Estou no diretório YAML do K8s, como discuti anteriormente em uma
‫palestra, se você estiver no repositório do Docker Mastery e não tiver
‫esse diretório, precisará executar um
‫git-pull para obter as atualizações mais recentes.
‫Este é um arquivo que vimos em
‫uma palestra anterior, aplicativo. yml. Este é um serviço,
‫além de uma implantação, em um arquivo.
‫Tecnicamente, dois recursos são criados com um
‫comando apply e estão relacionados.
‫O serviço usa um seletor, sobre o
‫qual ainda não falamos. Os seletores são como um
‫objeto encontra os recursos com os quais deseja conversar ou
‫fazer alguma coisa.
‫Um serviço precisa conversar com os pods, portanto, precisa encontrar
‫uma maneira de acessá-los.
‫Ele usa seletores como essencialmente correspondência de
‫padrões para corresponder aos rótulos das chaves
‫e valores existentes. Se eu fizesse o tradicional
‫dry dry aqui, tudo o que faria seria que o cliente olhasse para a
‫aplicação e dissesse: sim, eu vou criar esses objetos.
‫Tudo certo. Sempre vai voltar e dizer criado.
‫Isso ocorre porque a aplicação não é
‫muito específica. Se você estava usando uma
‫atualização, um comando create ou delete, que novamente não
‫me parece um fluxo de trabalho baseado em DevOps.
‫Esses comandos apenas executariam a seco e você sabe
‫que a atualização diria sim,
‫ambos serão atualizados. Mas, ele realmente não sabe no
‫seu cluster, certo. Ele não conversou com o servidor para descobrir isso.
‫Queremos tentar a execução a seco do servidor, que é ativada
‫por padrão em qualquer coisa 1. 13 e mais recente.
‫Quando eu fizer isso, ele irá conversar com o servidor e me
‫dará uma resposta adequada.
‫Vamos em frente e criar isso.
‫Vou tirar a corrida a seco do servidor.
‫Isso criará os dois recursos, a implantação e
‫o serviço.
‫Agora, se eu pressionar a seta para cima e voltar à execução a
‫seco do servidor, verá que ele diz inalterado para os dois.
‫Não está me dizendo o que mudou ou se
‫havia algo que iria mudar
‫o que seria. Está apenas me dizendo que
‫um recurso será alterado ou não. É uma espécie de alternância, sim ou não.
‫Que tal obter a diferença real entre o que
‫queremos fornecer ao servidor e qual o
‫status atual de nossos recursos.
‫Esse é o comando kubectl diff.
‫Se eu simplesmente der um diff em vez
‫de aplicar, ele comparará o YAML que
‫eu tenho com as especificações que estão nos servidores
‫atualmente em execução. esse status volta e fará uma
‫diferença nisso. Vamos fazer isso.
‫Não vai dizer nada, porque não há diferença.
‫Mas e se formos mudar o YAML?
‫E se eu mudar as réplicas para duas?
‫Depois adiciono um rótulo nos metadados e darei algo
‫como ... algo como.
‫Servidores dmz.
‫Eu inventei. Realmente não importa.
‫Então nós temos as réplicas de dois.
‫Se eu fizer o mesmo diff, ele volta com os
‫prós e contras.
‫Se você está acostumado a ler as diferenças, isso faz
‫todo o sentido para você. Se você não está acostumado com as diferenças,
‫o sinal de menos significa que a linha desaparecerá.
‫Então essas linhas serão adicionadas.
‫Então, aqui embaixo, ele mostra qual linha
‫e qual caractere está sendo
‫removido.
‫Isso está sendo adicionado.
‫Está mantendo a formatação YAML, o que é legal.
‫Está nos informando que várias mudanças estão acontecendo.
‫Ótimo. Claro, isso não está realmente fazendo algo
‫como um canário, ou teste de implantação ou algo assim.
‫Não está tentando fazer a coisa e depois ver qual
‫é o resultado. É realmente apenas olhando para
‫a especificação que ela registra e a especificação que temos em
‫nosso disco. Verifique
‫mais informações nos links de recursos.
‫É um artigo de blog da equipe Kubernetes sobre
‫o futuro deles e como eles serão apresentados ao
‫sair da versão beta. Lembre-se, esses recursos agora são beta,
‫pelo menos em 1. 15 eles são.
‫Felizmente, você pode criar seu próprio fluxo de
‫trabalho para criar YAMLs do
‫zero, gerenciar as especificações nessas YAMLs e usar o
‫comando apply repetidamente para fazer suas alterações.
‫Essa é uma infraestrutura muito mais amigável ao DevOps como
‫tipo de código para fazê-lo.
‫Tudo o que você faz é documentado, espero que no Git.
‫Portanto, esperamos que você faça um git-commit para cada alteração feita
‫em seu YAML antes de implantá-lo no servidor.
‫Então você tem essa boa documentação no Git, bem como a
‫documentação quando você faz algo como um diff para ver o que
‫você tem versus o que está realmente em execução.