Conceitos básicos de Kubernetes

1. Introdução: Olá e bem-vindos ao Kubernetes Warner 1. Isto vai ser bom. E então sim, nós vamos estar aprendendo algumas coisas, mas absolutamente nós vamos nos divertir fazendo isso. Agora, então, direto do bastão. Ok, vamos definir um nível neste curso para aqueles que são novos no Kubernetes. Na verdade, você nem precisa usar o Docker agora em TI ou um fundo de desenvolvedor pode ser útil, mas você sabe o que, isso não é um requisito. Portanto, nenhuma experiência prévia é necessária. Além disso, como diz o título, é um curso 1.0.1. Isso significa que quando você não fizer isso, você não vai estar indo embora como um guru Kubernetes, desculpe por isso. Mas você vai embora sabendo o que é Kubernetes e como funciona. E você terá uma idéia de algumas das coisas que ele pode fazer por você, para que você, você vai olhar para dar seus primeiros passos com o Kubernetes. Bem, quem sou eu? Sou Nigel, e se você ainda não sabe, passo minha vida ensinando o mundo, Docker e Kubernetes. Ele é como se tudo isso aqui fosse meu. E além disso, eu estou fora e sobre o circuito de alto-falantes e eu estou entregando workshops e eventos como Docker Con e o que você tem. Agora. Obviamente recomendo minhas outras coisas para dar os próximos passos. Mas, novamente, eu não faria. Quero dizer, é o meu está certo. Mas eu vou te dizer o que você é o juiz, ver como você se sente depois deste curso. E se você gosta disso, deixe-me dizer, você vai adorar isso. De qualquer forma, este sou eu no Twitter e estou ansioso para me conectar e falar sobre tecnologia. Mas eu tenho que dizer isso, certo? Estou ocupado como o resto de vocês, então não posso ser um suporte técnico gratuito. Quero dizer, fico feliz em falar sobre tecnologia, mas solução de problemas complexos. Sim, sinto muito mesmo. Só não tenho tempo. De qualquer forma. Olha, eu tenho feito esse tipo de coisa por um longo tempo agora. Estou confiante quando digo que vai gostar. E estou confiante de que você vai se afastar sentindo que aprendeu muito. Mas olha, eu estou “waffling”. É assim que fazemos as coisas. Fatia no curso praticamente no meio, a primeira metade. Então talvez uma hora mais ou menos. Vamos pregar a teoria como a arquitetura de Kubernetes aqui. Então, no segundo semestre, vai ficar com as mãos. Agora, olha, é um curso de vídeo, certo? decisão é sua se você seguir junto com as coisas práticas ou se você está apenas assistindo totalmente o seu núcleo. Mas o que eu não quero que você faça OK. E confie em mim, não pule a teoria porque é muito importante, como se eu fosse usá-lo para preparar a cena e prepará-lo para as coisas práticas. Porque você sabe o quê? Eu tenho 0 interesse em você ser capaz de acompanhar e ser brilhante ou digitar comandos se você realmente não entender o que está acontecendo, acredite em mim, certo? Eu mesmo já estive lá. Você pavimentou o curso de reciclagem. Você segue todos os exercícios. Às vezes você nem faz um único erro de digitação no final quando você não faz, você realmente não é o mais sábio. Você realmente não aprendeu nada. Então, como se alguém perguntasse o que os comandos na coisa estão mortos. Quero dizer, quem sabe, certo? Então eu não quero que você siga a teoria. Bem, falando na teoria, vamos sim, vamos descrever o que um aplicativo de microsserviços nativo na nuvem realmente é. Então descobriremos o que é Kubernetes. Vamos ver como é um cluster e, em seguida, veremos como é um orquestrador de aplicativos, h2. E eu sei, certo, isso é um monte de palavras, mas é tudo bom porque vamos explicar cada um deles enquanto vamos e também vamos contextualizar as coisas com um olhar para um fluxo de trabalho típico de como você pega a aplicação de no laptop de um desenvolvedor para realmente estar em um aplicativo em execução. De qualquer forma, quando acabarmos com a teoria, então será a prática. Vamos fazer um teste rápido. ambiente Kubernetes irá implantar um aplicativo, conectar-se a ele, testar uma falha e dizer algumas das auto-recuperações que acontecem. Estamos aumentando e diminuindo, conectando a um balanceador de carga e faremos uma atualização contínua. Agora. Eu sei que isso pode soar como um monte de coisas, mas vamos manter as coisas simples e vamos estar explicando tudo à medida que avançamos. Soa bem. Vamos fazer isso. 2. Microsserviços nativos de nuvem: Ok, então vamos falar sobre o que diabos, um microsserviços nativos de nuvem até como agora, há uma tonelada de definições lá fora, então eu vou resumir para você. Coloque as primeiras coisas em primeiro lugar. Vamos enrolar o relógio um pouco. Você diz que, antigamente, nós construímos nossos aplicativos onde nós agrupamos todos os recursos e lógica e os diferentes bits em um único programa como um único binário. Agora, estou sendo alto nível aqui. Mas tomamos podem ser os bits da interface do usuário, todas as coisas do middleware, essas coisas back-end do banco de dados e os sistemas de relatórios e tudo o que o aplicativo sempre sonhou em fazer. E nós nos reunimos em um único programa enorme e nós o instalamos e o apoiamos e executamos e todo aquele jazz, sim. E era a forma como sempre fazíamos as coisas. E foi terrível. E quando digo terrível, estou falando de perder os fins de semana inteiros de sua vida, mas não fins de semana comuns. Estes eram normalmente os longos fins de semana de férias. Então, um problema comum era atualizar a coisa. Quero dizer, era tão complexo que nenhuma pessoa ou Ting realmente novo em tudo ou foi responsável por isso. O que é um pouco de um problema ainda quando você considera que a coisa toda foi agrupada e empacotada como uma única unidade. De qualquer forma. Então, digamos que se precisávamos de patch podem ser os componentes de relatórios. Sim. Bem, sem brincadeira. Era tudo mãos no convés para aqueles fins de semana longos, você seria como fornecedores pré-aquecimento e clientes e qualquer um que usasse o sistema e dizer-lhes que seria para baixo a partir das 17h na sexta-feira e não backup até 22h no domingo. E os chefes têm o número de celular dos CIOs na discagem rápida e metade do departamento de TI estará no escritório todo o fim de semana e vivendo de pizza e café. E era muito precioso. De qualquer forma. Os problemas que forçaram isso foram arquitetônicos, certo? Tudo estava bem acoplado. Como se não pudéssemos apenas retirar os bits de relatório e corrigir aqueles independentes do resto do sistema. Agora, se quiséssemos corrigir o sistema de relatórios, tínhamos que derrubar tudo. De qualquer forma. Olha, é assim que usamos a fila. E temos palavras para aplicações como essa, certo? Nós os chamamos de monólitos. E na TI moderna, isso é como uma palavrinha, sim, como se você executar monólitos em sua organização, você está devidamente envergonhado com isso. Você definitivamente não conta para as pessoas. Sim. De qualquer forma, sorte. Estou meio brincando, certo? E agora a maioria de nós ainda tem monólitos por aí e tudo bem, certo? De qualquer forma, as coisas estão mudando e muito diferentes hoje dia, porque agora temos microsserviços nativos da nuvem. Tudo bem, vamos quebrar isso. Então o bit de microsserviços significa que pegamos toda a lógica que dissemos, sim, era como web frontend e middleware, backend e bits de relatório aqui. E nós os codificamos, e os enviamos de forma independente. Então nós temos a mesma experiência geral de aplicativo aqui ou os mesmos bits, mas a função independente, como talvez haja uma equipe dedicada especial que codifica e cuida da aposta na web e outra equipe para o armazenamento de dados e outra para o sistema de relatórios. Então eles são todos codificados e enviados de forma independente, mas eles falam uns com os outros e eles formam um útil. Agora, eu desenhei a linha em torno deles em traços propósito porque eles estão todos frouxamente acoplados desta vez. Então o que isso significa é que podemos reverter cada componente de forma independente. Como se um pouco tivesse um bug ou uma vulnerabilidade de segurança e não, digamos o relatório, mas novamente, sim. Bem, podemos tirar isso e atualizar sem tocar ou impactar qualquer uma das outras apostas. No entanto, como dissemos, tudo ainda funciona em conjunto para criar o mesmo aplicativo de negócios útil. Bem, essa é a parte dos microsserviços, certo? Lotes de diferentes pequenos ou micro serviços que conversam entre si e compõem um aplicativo maior. Bem, a parte nativa da nuvem. Isso significa que ele foi criado para demandas semelhantes à nuvem. Assim, pode escalar rapidamente para cima e para baixo. E eu estou falando que cada micro serviço aqui pode ser dimensionado de forma independente. Bem, assim como ele pode auto saudar e nós podemos fazer atualizações rollbacks e versões e todo esse tipo de coisas aqui. Mas eu conheço muitas palavras e vou explicar todas elas no devido tempo. Então não fique sobrecarregado com as palavras aqui. Agora, algo interessante que pode não ser tão intuitivo. Nuvem nativa absolutamente não significa que ele só é executado na nuvem pública. Pelo contrário, na verdade, e eu até mesmo ir tão longe a ponto de dizer um requisito de um aplicativo nativo na nuvem é que ele será executado em qualquer lugar noite seu datacenter no local. Então, isso é microsserviços nativos da nuvem. Sim, construímos pequenos componentes especializados. Nós chamamos esses microsserviços, e todos eles falam uns com os outros sobre APIs geralmente, e eles formam um aplicativo útil ou significativo. E os benefícios, cada peça individual ou micro serviço podem ser dimensionados de forma independente e atualizados de forma independente. E eles podem auto saudar e correr praticamente em qualquer lugar. Coisas boas. 3. Kubernetes de Kubernetes: Certo, hora de focar em Kubernetes. Agora, vamos pensar em Kubernetes como duas coisas. Um como um cluster e dois é um orquestrador de aplicativos. Então, na frente do cluster, você sabe o que, um cluster é. Um aglomerado, certo? É um monte de máquinas. E enquanto o Linux, você sabe o que, Kubernetes realmente não se importa. Então você poderia tê-los roubado. Quero dizer, não que eu esteja recomendando que eu seja estável, é claro, mas só para ser claro, as comunidades não se importam. Eles podem ser instâncias na nuvem, VMs em seu datacenter ou você sabe o quê? Pode até haver metais banidos em seu próprio datacenter, desde que eles executem Linux, Kubernetes é como, sim, tanto faz. Agora, eu estou dizendo Linux, mas na verdade Windows é uma coisa com Kubernetes hoje em dia. Na verdade, o suporte ao Windows no Kubernetes ficou GA, portanto, disponível ao público em geral e totalmente suportado no Kubernetes é 1.Então 14 no verão de 2019. Então sim, de qualquer maneira, bloquear um cluster Kubernetes é um cluster de nós. E como na maioria dos clusters, as mesmas regras antigas ainda se aplicam. Então podemos ver na imagem que dividimos o aglomerado em duas partes. Aqui. À esquerda temos os nós do plano de controle, e à direita temos os nós de trabalho ou supor palavras. Ok, então o plano de controle, pense nisso como onde os cérebros de Kubernetes ou a inteligência de Kubernetes existem. - Sim. Então o trabalho é aqui. Aqui é onde executamos nossos aplicativos de usuários e colunistas como o mexilhão de cluster, sim, que eu vou chegar em um minuto. Agora, quando dizemos avião de controle e Kubernetes é inteligente, estamos falando sobre as coisas que fazem Kubernetes. Kubernetes. Agora vamos cavar um pouco mais fundo em um segundo. Mas, por enquanto, vamos deixar claro que este é um tipo típico de cluster, significa que todas as regras habituais ainda se aplicam, como se não houvesse magia oculta, que significa que você não precisa mais se preocupar com coisas como desempenho e disponibilidade . Não, eles ainda se aplicam. Quero ser claro. Você está honrado pelo tempo. As regras de cluster de produção testadas pela batalha ainda se aplicam. Então, como na foto aqui, temos três notas no plano de controle. Disponibilidade, três ou cinco provavelmente é recomendado e um é melhor do que evitar Split Brains. - Sim. Agora, não deixe que a conversa techno te confunda. O ponto de levar para casa é que você precisa ter certeza de que seus nós de cluster são poderosos o suficiente. E você precisa ter certeza de que se um deles falhar, as coisas continuaram funcionando. De qualquer forma. São as partes do plano de controle. E os nós que compõem este plano de controle são geralmente chamados de nós Master ou às vezes Head. Mas é tudo apenas jargão, para os trabalhadores. Agora, a razão pela qual eu estou me referindo a eles como o músculo de cluster é aqui que nós executamos nossos aplicativos de usuário. Assim, quão rápido seus aplicativos são executados quão bem eles podem ser dimensionados. Isso depende muito da forma como providenciamos esses trabalhadores. Portanto, dependendo dos requisitos específicos de seu aplicativo, alguns desses funcionários podem ser máquinas grandes e algumas podem ser máquinas menores. Mas lembre-se, quando digo máquinas, estou falando de máquinas Linux e Windows na nuvem ou no prime, e elas podem ser VMs ou metais BAM. Agora, em seguida, mencionar janelas me lembra, máquinas Windows são suportadas apenas como nós de trabalho. Então os nós de plano de controle aqui, eles sempre têm que ser Linux, mas os nós de trabalho aqui, estes podem ser uma mistura de Linux e Windows, que eu acho que é o nível super alto. Vamos dar uma olhada mais de perto em H vai fazer mestres primeiro. 4. Mestres de Kubernetes: Tudo bem, então mestres. Então este é um explodiu o óleo como um zoom em vista de uma nota mestre. Então, na verdade, um desses aqui, sim. Tudo bem, bem, a partir do topo, um lembrete sobre terminologia. Normalmente chamamos esses nós de mestre. Mas sabes que mais, às vezes ouves outros nomes como notas de cabeça ou o que quer que seja. Tudo isso significa a mesma coisa, um nó de cluster executando os bits do plano de controle, que é o cérebro do aglomerado. - Sim. Agora, se você estiver executando um cluster altamente disponível com três ou cinco mestres, cada um executará o mesmo conjunto de serviços replicados. Dessa forma, se algum deles falhar, os outros manterão o cluster em execução. Agora, há mais serviços do que estes, mas por um custo 101, estes são os principais. Então o servidor API se acostuma com este, certo? É como a porta de entrada para o cluster. Então, sempre que quisermos consultar o cluster ou fazer uma mudança de configuração ou até mesmo implantar um aplicativo e, em seguida, atualizá-lo e todo o jazz com, fazer tudo isso através do servidor API. Então o envio de comandos para o servidor de API. Agora, sem ficar muito profundo para este curso, certo, ele expõe uma interface HTTP RESTful e cada comando recebido é autenticado ou autorizado e praticamente verificações de sanidade. Mas falando sobre a emissão de comandos, preciso dar um passo atrás por um segundo. Então dissemos que quando emitimos comandos, Kubernetes é que eles vêm aqui para o servidor de API, certo? Certo, mas como enviamos esses comandos? Bem, na maior parte, certo, certamente em um nível 101, usamos a ferramenta de linha de comando Kubernetes chamada CTL Cube. Agora, na verdadeira tradição Kubernetes em seu provavelmente se acostumar com isso. Há um milhão de maneiras de pronunciá-lo e você vai ouvir todos, como eu digo Cube CTL. Mas muitas pessoas dizem que a lei do controle do cubo, o Locke cortou o cubo, quem seria carinho eu, e como você o nomeia, certo? Qualquer coisa vale. O importante, certo, é a ferramenta de linha de comando do Kubernetes. Então é comandos como Cube CTL criar isso e Cube CTL descrevem isso. E Cube CTL deletou algo. E não vamos nos precipitar, certo? Veremos tudo em um material prático mais tarde. Eu só queria preencher uma lacuna potencial lá, certo? De qualquer forma, estávamos dizendo que sim os comandos CTL do Cube vão para o servidor de API e eles são autenticados ou autorizados e validados. Então, como exemplo, certo, talvez possamos emitir um comando para, sei lá, talvez implantar um aplicativo ou atualizar um aplicativo. Sim, bem, o que quer que o comando esteja dizendo a Kubernetes para fazer isso é gravado no armazenamento de cluster como um registro de intenção. Agora, o armazenamento de cluster é um banco de dados distribuído que geralmente é baseado no produto de código aberto chamado Etsy day. E é o único componente stateful do plano de controle, o que significa que mantém os dados de configuração localmente no disco. Agora, uma vez que a intenção do comando é persistida no armazenamento, Kubernetes pede ao programador para atribuir o trabalho fora. Então, eu acho que por uma questão de simplicidade, vamos supor que estamos implantando um aplicativo web. Sim, e digamos que queremos cinco instâncias em execução. Bem, o trabalho do agendador é ir e encontrar o melhor trabalho em notas para executar esses cinco servidores web. Agora, esta agenda está procurando por coisas como, bem, nós saudáveis é um bom começo. Sim, ele está procurando por nós com os recursos certos e suficientes desses recursos. Depois de encontrar alguns nós, ele emite as tarefas de trabalho para eles e o aplicativo é implantado. E isso é brilhante, certo? Coloque. E este é o cubo mágico que não pára por aí. Em seguida, implementa loops de controle em segundo plano que observavam constantemente o estado do cluster. E eles certificam-se de que o que pedimos é o que temos. Agora, vamos voltar a isso corretamente em um minuto, certo? Mas neste exemplo, acho que dissemos que pedimos cinco servidores web. Bem, Kubernetes implementou loop de controle. Isso garante que temos sempre cinco, certo? Acho que para nós, esse é o avião de controle. É o cérebro do aglomerado e você vai querer que ele seja altamente disponível. Enviamos nossos pedidos ou comandos para o componente de servidor de API do mesmo. Estes são gravados no armazenamento de cluster é o nosso estado desejado. Então, o que queremos, o agendador localiza os nós para executar o trabalho. E então, no fundo, há loops assistidos certificando-se de que as coisas não quebram. E se o fizerem, devo dizer que quando o fizerem, o Kubernetes conserta. Brilhante. Bem, isso vai servir para o avião de controle por enquanto. Vamos mudar para os nós de trabalho agora. 5. Kubernetes: Certo, assim como a visão explodida do mestre, isso é um zoom em vista de um trabalhador. E cada nó de trabalho no cluster executa esses mesmos três componentes principais. Agora, de uma perspectiva terminológica, você pode definitivamente chamar esses trabalhadores e as pessoas sabem o que você quer dizer. Mas, na maior parte, nós os chamamos de nós. Então, mestres para o plano de controle, sim , uh, nós para onde executamos nossas aplicações. Na verdade, às vezes chamamos as notas de cubelets. Isso é o quão importante este pedaço de cubelets aqui é. Pense nos cubelets como o principal agente do Kubernetes. Qualquer nó que você deseja como parte do cluster precisa executar um cubo. Mas agora, suponho que inicialmente os cubelets fala com o plano de controle e torna o nó CPU e RAM e os gostos disponíveis para o cluster. Então esse trabalho pode ser agendado para o nó, sim. Mas também está observando o avião de controle e está falando com ele. Assim, os cubelets observa o plano de controle para novas tarefas de trabalho que ele precisa executar, e, em seguida, ele relata de volta sobre o status desse trabalho. E curiosamente, certo, toda essa conversa com o plano de controle é através do servidor API. Quero ser muito claro sobre isso. Toda a comunicação com o plano de controle passa pelo servidor de API. É como a Grand Central Station. - Sim. Os humanos do Assad a falar via Cube, CTL ou o que for. Mas também, todos os Kubernetes, pedaços e pedaços, literalmente, tudo o que fala com qualquer coisa no plano de controle tem que passar pelo servidor de API. De qualquer forma, olha, os cubelets, é o principal agente Kubernetes. Ele é executado em cada nó que deseja ser um membro do cluster. Se ele parar como falhar ou algo assim, sim, ele vai tentar se reiniciar sozinho. Perfeito, continentes mortos na água do que o nó cai para fora do cluster e seu tempo de solução de problemas. Ok, bem, olhe no meio do diagrama, nós temos o Container Runtime. Agora, atitudes cubanas é um orquestrador de aplicativos. Sim, ele pode orquestrar coisas como VMs e cargas de trabalho sem servidor. Mas, na maior parte, em um nível um-para-um, ok, ele orquestra aplicativos em contêineres. Então, são aplicativos que são executados como contêineres, como contêineres do Docker. - Sim. Agora, então, estamos olhando para um trabalho e nota aqui, e sabemos que é aqui que os Kubernetes são aplicativos. E nós acabamos de dizer, na maior parte, aqueles corredores africanos contêineres. Então, faz sentido que cada nó precise de algum software para executar e gerenciar contêineres. Estou falando de coisas básicas como como extrair uma imagem de contêiner de um registro e, em seguida, como iniciar, parar e atualizar contêineres. Bem, esse pedaço de software é o Container Runtime aqui. Agora, no início do Kubernetes, Container Runtime foi sempre o Docker. Então, nós diríamos que, como ainda, Kubernetes joga executar nosso aplicativo. O agendador encontraria o nó que poderia executá-lo. O cubo aceso nesse nó aceitaria o trabalho e , em seguida, seria optado pelo Docker como o Container Runtime. Puxe a imagem e inicie o contêiner. Mas isso foi então, e isso é agora. E em vez de o Container Runtime ser sempre Docker, temos essa coisa chamada Container Runtime Interface ou CRI. Se você é como você é acrônimos. Cortando diretamente para a perseguição, porém, esta é uma camada de plugin. A carta diz: “Ei, talvez não queiramos o Docker neste nó, talvez precisemos de um Tempo de Execução de Contêiner diferente. Bem, o informante torna isso possível. Então agora é realmente fácil dizer, hey, neste nó, vamos correr pode ser g viseira e aqui pode ser cortador, e aqui pode ser contido um dia. Agora, sim, olha, nós somos um curso 101, então eu vou manter isso o mais simples possível neste caso, certo, entre todos esses diferentes tempos de execução de contêineres como Katherine, Container D, e qual escolha mais pesada é uma coisa boa. Cada Container Runtime oferece potencialmente características de desempenho diferentes, bem como coisas como diferentes tipos de isolamento da carga de trabalho. Assim, por exemplo, no isolamento da direita, algo como gee, visor ou cata pode oferecer um ambiente de tempo de execução mais isolado do que algo como Docker. Então, se você executar duas cargas de trabalho próximas uma da outra, certo? Às vezes, o isolamento dessas cargas de trabalho é importante. Sabemos o que? Ou seja, todo um tópico próprio e não vamos lá neste curso. Basta dizer que o Container Runtime aqui é o bit que gira contêineres e gerencia-os. Bem. Por último, mas definitivamente não menos importante, o proxy do cubo. Isso garante que a rede Kubernetes funcione. Agora um pouco de um passo para o lado aqui, certo? Quando você cria um cluster do Kubernetes, parte dessa operação é criar uma rede POD. E você sabe, bem, é muito simples, certo? A rede POD é uma rede grande e plana que abrange todos os nós. Assim como você pode ter totalmente um cluster onde todos os nós estão em diferentes redes no Likes. Mas então o Kubernetes sobrepõe essa grande rede plana em todos os nós. Agora estou dizendo sobreposição, certo? Geralmente é uma sobreposição de terra VX, mas também pode ser BGP. Nós sabemos o que, o que é importante é esta rede POD é o que todos os nossos aplicativos se encaixam. E é agradável, simples e plano, certo? Assim, todos os nossos componentes do aplicativo sentam-se sobre ele e podem conversar uns com os outros. Brilhante. De qualquer forma, olhe nos bastidores, certo? Q proxy aqui executa toda a magia para fazer essa rede POD acontecer. Coisas como tabelas IP e regras IPBES, se você estiver interessado. Mas isso são nós. Agora vamos para Kubernetes como orquestrador. Está bem. Mas rápido, antes de fazerem isso, só quero dar uma olhada em algo que é muito popular nos dias de hoje. Kubernetes hospedado. 6. K8s Hospedados: Então nós temos essa imagem, sim, nosso cluster Kubernetes e ele é cortado aqui como um plano de controle e uma espécie de plano de dados como os cérebros de Kubernetes vivem nesta parte e, em seguida, aplicações apenas um aqui. Sabe o que são coolers? Kubernetes Tech é um eu amo, certo? Eu sou realista e sei que a tecnologia só existe realmente para executar aplicativos e construir negócios, e, claro, cuidados de saúde e coisas humanitárias também. Sim. Mas meu ponto é que ninguém implanta Kubernetes só para que eles possam dizer, hey, nós temos Kubernetes é pelo menos uma esperança que ninguém faz. Você diz que implantá-lo para que seus aplicativos possam ser executados em escala e atualizar o Healon e tudo isso, certo? Então é tudo sobre o aplicativo. Mas neste mundo de foco de aplicativos, nós realmente só nos importamos com esses bits aqui. Quero dizer, todas as coisas do avião de controle tão legal quanto é, certo? Apenas meio que fica no caminho, como gastar tempo e esforço planejando e implementar todas as coisas de alta disponibilidade e talvez algumas coisas de desempenho. Sim. Quero dizer, tudo o que está fazendo é nos distrair de criar aplicativos, que é exatamente onde Kubernetes hospedado entra em jogo. Então, um serviço hospedado do Kubernetes leva os bits do plano de controle aqui, separados, desenha uma espécie de linha de demarcação e diz, vou te dizer o seguinte. Vamos gerenciar todas essas coisas de avião de controle para você. E vamos expor as partes dos trabalhadores. Então, em um nível alto, sem entrar em detalhes, você não precisa dar um único pensamento ao plano de controle. É tudo controlado por você. Assim, atualizações, disponibilidade, desempenho, tudo isso, tudo cuidado pelo seu provedor de nuvem. Falando nisso, todos os principais provedores têm um serviço Kubernetes hospedado. Os grandes reais ou o serviço Kubernetes elástico do Amazon IQ AS, o serviço Azure Kubernetes, também conhecido como S e G k0, o motor Google Kubernetes. Mas também, oceano digital, IBM Cloud, esses caras têm todos eles também. Agora tenho que dizer que é a nuvem. Então os custos se aplicam. Nada é de graça, certo? E, além dos benefícios, você pode criar um cluster gerenciado do Kubernetes em instante e não tem toda a preocupação do plano de controle. Sim. Bem, por outro lado, você desistindo do controle. Por exemplo, você está limitado às versões do Kubernetes é suportado por um provedor de nuvem. E digamos que se você precisar definir quaisquer configurações funky no plano de controle, você provavelmente está fora do bloqueio. Então é ótimo, certo? Coloque na espada de dois gumes. A simplicidade vem ao custo da configurabilidade. Agora então, e é difícil não entrar em detalhes porque eu quero dizer que você soa muito, mas eu não quero sobrecarregar você quer 101 curso. De qualquer forma, você pode estar fazendo a pergunta, especialmente se você é um desenvolvedor. Por que eu tenho que me preocupar com as apostas do nó do trabalhador? Por que não posso dar minha inscrição ao Kubernetes? E que Kubernetes é cuidar de tudo para mim. E essa é uma ótima pergunta. E o, algo chamado cubelets virtuais que está indo nessa direção. Portanto, não há nós reais em seu cluster, como coisas realmente legais e um dia potencialmente, nenhum Kubernetes ímpio é. Mas eu acho que para nós, certo, isso é potencialmente realmente mente soprar coisas. Mas se estiver interessado. Google cubelets virtuais. Bullock, estou exagerando. Kubernetes é um cluster de máquinas, principalmente Linux, e eles podem ser executados em qualquer lugar. Essas máquinas individuais operam como mestres ou mestres de trabalhadores implementam toda a inteligência Kubernetes e precisam estar altamente disponíveis e todos os custos habituais para a bondade. Mas não executamos nossos aplicativos lá nos nós de trabalho do mestre. É onde executamos nossos aplicativos. Os serviços Kubernetes bem hospedados existem na maioria das plataformas de nuvem e eles escondem principalmente o plano de controle de nós. Embora existam outras opções hospedadas. Certo? Magia. Vejamos agora como o Kubernetes é um orquestrador de aplicativos. 7. Kubernetes como orchestrator: Certo, Kubernetes como orquestrador de aplicativos. Então, primeiro, orquestrador, essa suposta palavra, então o que significa? Ok, me acompanhe por um minuto. É um pouco brega, mas eu acho que realmente leva para casa o ponto. Então esta aqui é uma orquestra sinfônica, você sabe, um monte de instrumentos diferentes que se juntam e fazem música esperançosamente incrível. Só que agora, eles estão por todo o lado e eles não têm nenhuma música para tocar. Então, sim, talvez legal, não colocar muito uso. Bem, vamos trazer o condutor. Então ela entra, coloca todos os instrumentos em seu lugar, entrega a música, e de modo geral, organiza tudo. Como quando o começo, quando tocar seu papel em particular foi um sunga, foi para ir alto ou silenciar todo aquele jazz, sim, jazz. Oh querida. Nenhum trocadilho pretendido lá. De qualquer forma. Com apenas algumas coisas, o maestro e algumas músicas como partituras. Bem, nós fomos do Chaos para todos tocando seu papel e potencialmente criando uma música comovente. E não é muito difícil dar o salto para Kubernetes, onde temos um monte de serviços de aplicação diferentes aqui, todos apenas relaxando, em Medellín e realmente não tendo a menor idéia do que fazer ou quando executar e onde correr. Então talvez o motor X em raio e alguns OAuth e alguns bits personalizados aqui, todos códigos legítimos e micro serviços, certo? Mas não faço ideia de como todos eles se reúnem e quais suas festas particulares. Então nós jogamos Kubernetes está na mistura, como a conduta do ar. E então algumas configurações de aplicativos, pense em partituras. E de repente temos esse trabalho adequado que faz algo, espero que algo útil. Agora, no caso da orquestra, precisava que os conduzidos viessem e os organizassem, diga-lhes onde dizer, quem seguir veio em como tocar todo aquele ano. E é o mesmo em Kubernetes com nosso aplicativo. Portanto, o Kubernetes é, por exemplo, programado cada componente. Então, como diz a eles quais nós executar, quais redes conectar às portas para expor toda essa bondade. E no exemplo da orquestra, todos precisavam de uma cópia da música. Bem, na aplicação aqui, cada peça precisa de sua própria configuração. Então o que é suposto fazer, e isso pode ser coisas como servir páginas web, fazer autenticação, talvez fazer pesquisas no banco de dados. Sim. O que por conta própria, esses trabalhos individuais podem não parecer muito. Mas quando estão todos a correr juntos, teríamos uma aplicação útil. Bom. Sim, espero que sim, porque foi definitivamente brega. Mas quer saber? Quando eu fiz isso, vivo em oficinas e gostos, todo mundo sempre me disse que era bom. Então, espero que tenha sido útil para você. De qualquer forma. Em seguida, vamos dar uma olhada em obter código do laptop de um desenvolvedor para rodar no Kubernetes. 8. Fluxo de desenvolvimento: Certo, então um fluxo de trabalho de aplicativo. Então esse processo de obter código do laptop de um desenvolvedor todo o caminho para rodar em um sistema live. Bem, parece algo assim. Você escreve algum código na parte de trás de um requisito ou uma idéia. Sim. Agora, Kubernetes não se importa como você escreve seu código ou em que idiomas ele está. Enquanto fosse executado em Linux ou Windows, devemos ser bons. Bem, uma vez que o código é feito, nós o empacotamos como uma imagem de contêiner pós-doc em um registro, e então estamos prontos para executá-lo, é por isso que Kubernetes entra. Agora, trancar como maneira mais simplificada. Então vamos adicionar um pouco de detalhes. Como dissemos, você escreve seu código em qualquer idioma que queira, isso não muda. Mas então este pedaço aqui, empacotando-o como uma imagem de recipiente. Sim, isso pode ser novo para você. Assim, um fluxo de trabalho típico seria um desenvolvedor com trabalho Docker em seu Mac ou laptop Windows. Eles escrevem esse código do que usam as ferramentas do Docker para construir isso em uma imagem, o que pode parecer extravagante, mas é basicamente apenas colocar seu código de aplicativo mais quaisquer dependências em uma pasta em seu laptop, executar um comando de compilação de imagem de encaixe contra isso. Felder e Docker faz o trabalho duro de construir uma imagem. Quando a construção terminar, você tem essa coisa que chamamos de imagem, certo? Como nós sugerimos que a magia da imagem é que ela tem tudo dentro dela que seu aplicativo precisa. Então, seu código operacional, claro, sim. Coloque o seu bem, ele tem todas as dependências como bibliotecas e construções de sistema de arquivos OS. O que significa que tudo o que o seu aplicativo precisa para ser executado está dentro dessa imagem. Significando, novamente, você pode praticamente executá-lo em qualquer lugar e ele vai apenas funcionar. Então você escreve seu código, usa as ferramentas do Docker para empacotá-lo como uma imagem e, em seguida, usa o push de imagem do Docker para salvá-lo em um registro em algum lugar. Agora, um registro é apenas um lugar para armazenar suas imagens de contêiner e olhar. Você pode executá-lo no prem ou em sua própria nuvem privada virtual, ou pode usar um registro baseado na Internet, como o Docker Hub. O ponto de retirada no entanto, uma vez que suas imagens em um registro, ele está pronto para ser puxado e executado em produção. Agora. Produção, sim, claro, certo. Por isso, neste processo, estamos a perder um número ridículo de passos. Diga Sim, como todas as coisas que fazemos no mundo real com uma integração contínua ou um pipeline de entrega contínua. Então isso são coisas como compilações automatizadas, testes, varreduras de vulnerabilidade, tudo isso, bondade , sim, estamos ignorando isso para manter o exemplo simples. Mas sim, suponha que todas essas coisas não fazem todas as compilações, testes e varreduras do que sua imagem vai para um repositório de produção e seu registro, e você está pronto para implantar, que é onde o Kubernetes entra. Então, neste ponto seu fluxo de trabalho de desenvolvimento é feito e é aqui que os bits de operações assumem. Agora olhe, há muito para Kubernetes e não há como fugir do fato de que é uma curva de aprendizagem bastante íngreme. Mas quero tirar um segundo só para dar uma amostra de algumas das coisas que o Kubernetes oferece para ajudar você a executar seus aplicativos. Na foto aqui estamos olhando para três recursos Kubernetes no conjunto Daymond, na implantação, e um conjunto stateful. Eu não quero que você se concentre em nenhum detalhe aqui. Apenas tire o quadro geral. Ok? Assim, um conjunto de daemon garante que uma instância de um micro serviço específico está sempre em execução em cada nó no cluster são realmente comuns exemplo seria como serviços de log ou monitoramento. Sim, você precisa dele para rodar em todos os nódulos. Bem, adivinha? Use um conjunto de daemon para conseguir isso. Então você teria seu serviço de registro ou monitoramento, certo? Você iria embrulhá-lo em um conjunto Kubernetes Damon. Dê ao Kubernetes para implantar. E o Kubernetes certificar-se-á de que uma instância seja executada em cada nó do cluster. Brilhante. Mas se você adicionar mais nós no futuro, não se preocupe. O Kubernetes vê isso e garante que os novos nós obtenham uma instância. Coisas boas. Bem, uma implantação é diferente. Estes são todos sobre ser capaz de escalar, auto-granizo e executar atualizações contínuas. E nós vamos dizer isso mais tarde na seção prática. Então, eu só vou estacionar implantações por enquanto, certo? Então o último que estamos mostrando e lembre-se há muito mais. Ok? Colocar conjuntos stateful são sobre implantar e gerenciar as partes stateful de nossos aplicativos. Então, estes nos dão coisas como nomes de pod confiáveis e startups ordenados e os gostos. Sim. Mas veja onde alto nível ou não quer se perder nos detalhes apenas apontando corretamente, o Kubernetes oferece muitas maneiras de implantar e gerenciar os diferentes bits de nossos aplicativos. Legal, vamos olhar em resumo, temos três partes principais para o fluxo de trabalho. Você codifica seu aplicativo. Você usa o Docker para empacotar tudo como uma imagem de contêiner e enviá-lo para um registro. Em seguida, você usa o Kubernetes para implantá-lo e gerenciá-lo. Simples. Bem, um deles era que eles eram lição e então vamos entrar nos exemplos. 9. Estado desejado: Certo então uma coisa que nós absolutamente precisamos saber é que a unidade atômica de implantação ou escala e Kubernetes é algo chamado um pod. E senhas podem escrever unidade atômica de agendamento. Sim, certo? Bem na tela aqui, podemos dizer que VMware completo, a unidade atômica de agendamento, é a máquina virtual do Docker, é um contêiner e para Kubernetes visita o pod. Brilhante. Bem, o que isso significa é que, se implantarmos um aplicativo no VMware vSphere, carimbamos como máquinas virtuais. Se implantarmos um aplicativo no Docker, nós o carimbamos como contêineres para adivinhar? Se implantarmos as comunidades? Nós o carimbamos como casulos. Agora, tropeçando para fora. - Sim. O que estou dizendo é que todas as diferentes partes de nossos aplicativos no Kubernetes estarão funcionando como pods. Então eu não sei se nós temos como um front-end web para nossa aplicação. Sim, precisamos escalá-lo. Nós o dimensionamos adicionando mais partes ou, se estamos diminuindo, tiramos partes. Brilhante. Agora, sim, Kubernetes é um orquestrador de aplicativos em contêineres. Quero dizer, ele também pode orquestrar máquinas virtuais e cargas de trabalho sem servidor. Mas, na maior parte, o Kubernetes orquestra aplicativos em contêineres. Portanto, os aplicativos de nós são contêineres. Somente. Você não pode realmente implantar um contêiner diretamente no Kubernetes. Sério, para que os contêineres funcionem no Kubernetes, ele precisa ser embrulhado em um pod, sim. E para o sistema operacional intensivo agora em seu curso 101, basta pensar em um pote é um invólucro leve em torno do recipiente. Tudo o que ele faz é permitir que contenham uma execução no Kubernetes. E agora vamos vê-los mais tarde em pedaços práticos e tudo ficará claro então. Mas tenho uma última teoria melhor. Implantações declarativas, estado indesejado versus estado real ou boca adequada. Bem, Kubernetes adora que descrevamos as coisas declarativamente. Bingo do Buzzword, certo? Adoraria essas palavras. - Sim. Bem, na tela, temos alguns requisitos. Isto é o que queremos. Então, dez cópias de algum serviço baseado em qualquer imagem exposta na porta 8080 com um rótulo específico. Isso é o que queremos. E o termo técnico para isso é estado desejado. Bem, nós escrevemos isso em um arquivo de configuração e damos ao Kubernetes, dez réplicas de qualquer contêiner nesta porta com esse rótulo, sim. E nós basicamente estamos dizendo, hey, Kubernetes, basta ir e fazer isso acontecer jogadas. E é isso agora. Pode parecer nada além de pensar nisso. Compare isso com o esforço e a dor de escrever algum script humungous com todos os comandos e toda a lógica para gostar, bem, decidir qual dos nós para um as dez réplicas em para iniciantes, além de todos os comandos e lógica para puxar as imagens, todos os comandos e lógica para iniciar os contêineres unidos às redes expor as portas, são os rótulos, todas essas coisas, certo? Bem, este modelo declarativo não tem nada disso. Escreva o que quiser, dê ao Kubernetes. Deixe Kubernetes lidar com as coisas difíceis. - Sim. E isso é realmente brilhante, certo? Mas quer saber? É só metade da história. Porque você vê, porque estamos declarando o que queremos para as comunidades em vez de apenas dizer, hey, executar esta longa lista de comandos. Bem, como dizemos o que queremos, Kubernetes registra esse estado desejado como um registro de intenção no armazenamento de cluster, então isso faz acontecer. Mas depois disso, ele gira. Assista loops que observam o cluster e constantemente certificando-se de que o que está realmente sendo executado no cluster corresponde ao que queremos. Agora, se isso acontecer, então se o estado real corresponde ao estado desejado, Brilhante, Certo? Se não acontecer, talvez tenhamos apenas oito réplicas em vez de dez. Kubernetes fará o que puder para consertar essa magia? Bem, olhe apenas em bolos fora snooty, certo? Digamos que um nó falhou e perdemos duas réplicas com ele. E que se lixe, certo? Acontece às três da manhã. Kubernetes sabe que precisamos de dez réplicas. Acabamos de perder três e desceu para sete. Então gira mais três e voltamos aos dez. O estado real corresponde ao problema de estado desejado corrigido, certo? E nenhum telefonema para você no meio da noite. O Lavett? Bem, este modelo é absolutamente essencial para o funcionamento do Kubernetes e é uma das coisas que o torna tão grande. E isto aqui, isto é o que realmente parece. Agora, se você não viu um arquivo YAML como este antes e parece um pouco assustador, uma promessa que você, não está bem. Como se você nunca escrevesse esses arquivos do zero. Na verdade, você sabe, eu sempre pego um velho e modifico. - Sim. Mas a coisa é, uma vez que você vê alguns, eles começam a parecer muito mais simples. De qualquer forma, estamos dizendo dez réplicas, então dez pods, executando essa imagem em particular e ouvindo essa porta ASI, pós-doc para o servidor de API, assumindo que ele passa toda a autenticação e autorização registrado no armazenamento de cluster como nosso estado desejado e é implantado no cluster. Fabuloso. Mas então, como dissemos, esses loops de reconciliação estão rodando em segundo plano e eles estão sempre observando o aglomerado o dia todo, a noite toda, mas provavelmente com um café para mantê-lo acordado ou algo assim. Coloque-o constantemente observando o cluster. E sempre que o estado observado varia do estado desejado, Kubernetes tenta corrigi-lo. Promessa brilhante, certo? Você vai adorar. E outra coisa que você ama. Terminamos com a teoria. Hora de ver alguns exemplos. 10. Como obter Kubernetes: Ok, então se você quiser acompanhar, você precisará de um cluster do Kubernetes e do aplicativo de amostra e arquivos de laboratório. Então o que vamos fazer é mostrar-lhes algumas maneiras muito fáceis de obter Kubernetes. Então vamos mostrar-lhe como obter os arquivos do laboratório. Assim, na frente do Kubernetes vai olhar para o Docker desktop, jogar com o Kubernetes e o motor Google Kubernetes. Agora, é claro, existem outras opções, e eu acho que se você já tem um cluster, talvez você possa simplesmente usar isso. Certifique-se de que não é o seu cluster de produção. De qualquer forma, procure a área de trabalho Docker. Você acabou de vir ao site do Docker. Ou melhor ainda, você pode apenas Google Docker desktop. Mas de qualquer maneira você vai acabar em algum lugar como este. E então você apenas baixar a versão para você. Agora, estou num Mac agora. Então eu vou pular eles Swan. E, em seguida, quando isso é baixado, é realmente apenas um pouco de clique clique em Avançar, Avançar, Próximo. Honestamente, não poderia ser mais fácil. De qualquer forma, quando você não fizer isso, você vai pegar essa baleia ou pêra ou ele vai estar no canto direito se você estiver no Windows. Mas ao clicar nele, você terá essa interface de usuário chique onde você vem e habilita o Kubernetes. Agora pode levar um minuto ou dois para começar, mas quando terminar, bingo, você está no negócio e está pronto para ir buscar os arquivos do laboratório e descobrir o curso. Agora, Docker desktop é apenas para fins de desenvolvimento e teste e você só obtém um cluster de nó único C-lo aqui uma única nota atuando como mestre e trabalhador. Agora, obviamente não é o que você quer para a produção, mas é definitivamente bom o suficiente para o desenvolvimento. Certo, então brinque com Kubernetes. Novamente, basta amarrar no Google e seguir o link. Ele quer que você faça login com, ou GetHub no hub Docker e, em seguida, basta seguir as instruções na tela e criar um cluster. Agora, olhe, brincar com Kubernetes é grátis e é ótimo. Honestamente, eu adoro. Mas às vezes não é super responsivo ou não pode ficar muito frustrante. Mas lembre-se, é grátis e os caras por trás dele estão realmente fazendo foi um serviço apenas colocando para fora que oh, você sabe o que bem. Se você olhar aqui para cima, este é um temporizador contagem regressiva até seu cluster ser excluído. Então, novamente, como Docker desktop, é apenas um playground. E, claro, este tem alguns problemas de desempenho às vezes. Mas a coisa é, é tempo limitado. Então, quando não contador atinge 0, ele nasce como não escolheu para o seu cluster e qualquer coisa em execução nele. Mas uma vez que você bote, honestamente, são arquivos de laboratório e você está pronto para ir. Ok, por último, mas não menos importante, para obter um cluster e lembre-se, outras opções existem. Mas o motor do Google Kubernetes é uma opção sólida para o Kubernetes hospedado na nuvem. E eu vou estar executando um monte de demos no curso sobre ele. De qualquer forma. Olha, é serviço de nuvem, então custa dinheiro. Não, sob nenhuma circunstância, crie um cluster para este curso e, em seguida, esqueça isso. Porque se o fizeres, terás um Bill de boas vindas. De qualquer forma, desde que você tenha uma conta do Google Cloud com faturamento habilitado, é apenas nuvem dot google.com login no console aqui, Kubernetes engine e, em seguida, passar pelos movimentos de criação de um cluster. Chame o que quiser, decida onde quer. Eu costumo ir para o que é mais leve quando estou fazendo um laboratório. E, em seguida, sob pool de nós aqui, cabe a você. Mas eu normalmente recomendo três nós e um caminho que vai. Agora, vai levar um minuto ou o que quer que seja para construir. Mas quando acabar, pago-te copie este comando sozinho do G-Cloud. E desde que você tenha o Google SDK instalado com o G Cloud, basta dar um Rhone rápido. E uma CTL de Cubo obtém nós, mostra você em funcionamento e pronto para rachar. Então, novamente, neste ponto, você tem um cluster Kubernetes. E uma vez que você tem os arquivos do laboratório, você está pronto para rock and roll. Mas como eu disse antes, por favor, faça o que fizer, não se esqueça de apagar o cluster quando terminar. Ok, então nós temos um aplicativo de exemplo em alguns arquivos de configuração no GitHub. E, a propósito, não se preocupe se você realmente não sabe o que é GetHub, você não precisa apenas apontar o cabelo do seu navegador. Se estiver interessado. O aplicativo está nesta pasta. E então estes são os arquivos de configuração aqui na raiz do repositório. Mas tudo o que você realmente precisa é este link aqui, pressione o botão da área de transferência, e em seguida, em uma janela de terminal digite git clone e cole no link. E é isso. Ou na verdade não, você sabe o que, você tem uma nova pasta. Frio. Kubernetes é 101 partes de habilidades ou Scotia para abreviar. De qualquer maneira, vá para lá. E esse é o aplicativo nos arquivos de configuração. Então olhe, com um conjunto nos arquivos do laboratório, você está pronto para dizer, oh, eu sou terrível nisso. E certifique-se de que todos os comandos que você executar mais tarde no curso em qualquer um dos cenários de laboratório, ok? Executá-los nesta pasta porque você precisa de acesso ao arquivo, diga sim, bem, é isso. Vamos lá. Vamos rachar. 11. Como implementar um pod: Certo, então vamos nos acalmar gentilmente. Já dissemos que a unidade atômica de implantação em Kubernetes é a cápsula. E que um pod é apenas um invólucro em torno de um contêiner que permite que ele seja executado no Kubernetes. Então, mais fotos. Pensei que tínhamos acabado com os slides a sério, certo? Se você acha que está cansado deles, eles são a maldição da minha vida. Então este vai ser muito rápido. Começamos com código, construímos como um contêiner, embrulhamos em um pod. Adorável. Então isso é o que parece ter. Agora estamos falando, este é um arquivo Kubernetes é YAML. Às vezes chamamos de arquivo de manifesto, mas este está descrevendo um pod. Começando pelo fundo, isso é o que chamamos de especificação do contêiner. Então é o contêiner, a cápsula vai funcionar. E então o material aqui em cima, este é o embrulho do POD, bem, o recipiente, mas é bem simples. Se você fez algum Docker, você dá um nome tão arbitrário, certo? Chame o que quiser. Esta é a imagem em que se baseia. Então isso é o que detém todo o seu código de aplicativo e suas dependências, Sim, e expô-lo na porta 8080, muito fácil. Os aplicativos aqui executá-lo como um contêiner, acessá-lo nesta porta e dar-lhe este nome amigável, boom, que é u recipiente. Mas para executá-lo no Kubernetes, ele precisa de tudo isso aqui. Sim, a cápsula embrulhando por falta de um termo melhor. Agora, eu acho que nós vamos percorrer este, certo, porque é semelhante em todos os objetos Kubernetes. Nós sempre começamos com a versão da API e tipo você pode tê-los em qualquer ordem, certo? Mas API versão v1 e tipo pod, quer saber? Não é ciência de foguetes, estamos dizendo que Kubernetes é faturado como um pod e construí-lo sobre o que é essencialmente uma versão um do esquema pod. Se houver um esquema v2, esperaríamos que ele tenha mais alguns sinos e assobios, como é a norma com versões posteriores das coisas. Mas sim, dê-nos um pod baseado em V1 do esquema pod ou especificação pod. Então os metadados aqui, estamos dando um nome a ele e usaremos isso em um minuto. Então nós demos alguns rótulos. Agora vai ver o poder dos rótulos um pouco mais tarde. Mas por enquanto, deixe-me dizer que eles são escandalosamente poderosos. Mas é isso, certo? Esse é o nosso estado desejado que batemos mais cedo. Então, em vez de escrever um homem que se inscreve com toneladas de comandos para fazer coisas como puxar a imagem do contêiner em comandos para iniciar o contêiner, que por sinal será diferente se você usar diferentes runtimes de contêiner, sim. Mas você também precisará de comandos para anexá-lo a uma rede expondo no 8080. Todo esse ar de complexidade, bem, não obrigado. Não queremos nada disso. Em vez disso, vamos colocar o que queremos em um arquivo aqui, enviá-lo para o Kubernetes e deixar o Kubernetes descobrir como fazê-lo. Falando nisso, vamos enviar para Kubernetes. Agora eu tenho uma cópia do arquivo aqui no meu diretório de trabalho. Se você estiver acompanhando, clone o repositório do GitHub com este comando aqui, ou copie o texto e coloque-o em um arquivo em seu diretório de trabalho chamado Pod dot yaml. E então olhe para o nome do arquivo é arbitrário, mas eu só vou estar mostrando exemplos com ele chamado Pod dot yaml. Então Cube CTL aplicar arquivo Pod dot yaml, e é isso. Agora nos bastidores Cube CTL tem um arquivo de configuração. Está em um diretório oculto no seu perfil chamado cubo. E aí tem um arquivo de configuração, convenientemente chamado config. Enquanto lá, ele tem coisas como clusters, API, endpoint e credenciais e outras coisas. Para que Cube CTL saiba para onde enviar o comando e ele pode fazer autenticação. Sim, bem, se fizermos Cube CTL pegar cápsulas, lá está 101 pod e está funcionando. Assim, o servidor de API aceitou nosso YAML como um novo armazenamento de estado desejado, a cópia e o armazenamento de cluster, e o agendador encontrou um nó íntegro para executar o Piton. Brilhante. Agora podemos executar uma CTL de Cubo, obter cápsulas com o cuidado de mosca larga para ver em qual nó ele está rodando. E um CTL Cube descreveu cápsulas 101. E isso nos dará uma visão mais detalhada que é realmente muito bem formatado. Agora, estes dois comandos, Cube CTL get e Cube CTL descrevem. Estes vão ser os teus melhores amigos, como tu eras, literalmente confiam neles o tempo todo. Agora, uma pergunta que me fazem o tempo todo em oficinas nos gostos é, como escrevemos esses arquivos YAML e lá como um número ridículo de campos e opções. Bem, para o primeiro sobre como escrevemos? A resposta é bem simples. Na maior parte. É só pegar um antigo, talvez até da web ou de algum lugar e modificá-lo como aquele super simples pod yaml que acabamos de fazer. Eu não digitei isso do zero. Então, sim, normalmente você vai copiar um antigo e ajustá-lo. Agora, a questão de saber todos os campos possíveis, opções e outras coisas. Quer saber, essa resposta simples e morta para isso também. Sim, a maioria dos objetos tem uma lista assustadora adequada de opções que você pode colocar na AML, mas você não precisa colocá-los. Basta colocar os que você precisa. Em seguida, aqueles que você deixou de fora, Kubernetes é expandi-los com valores padrão. Então você sabe o que, se nós rodarmos outro CTL Cubo obter pods aqui, mas nós mudamos esta opção aqui de wide para YAML. Confira isso. Esse é o YAML totalmente expandido do armazenamento de cluster. E quero dizer, é muito mais longo do que as dez ou 15 linhas ou o que quer que enviamos para o servidor de API. Portanto, há anotações e namespace sob a especificação do contêiner. Há bem, há um tom, certo? Então, sim, Kubernetes preenche todos os espaços em branco onde não definimos valores explicitamente. Agora, haha, sim, também, um pouco mais abaixo, há toda essa seção de status aqui que nunca especificamos nossos animais. Mas eu adoro, certo? Porque é uma ótima maneira de reforçar estado desejado contra o estado observado que descobrimos mais cedo. Então a seção de especificações é basicamente o nosso estado desejado. O que pedimos a Kubernetes são quatro. O estado é bloco aqui, porém, isso representa o estado observado atual do cluster ou o estado observado no momento em que executamos o comando, Sim. Bem, temos aqui um contentor baseado na nossa imagem. assim que lhe chamávamos. Está pronto a correr. Este é o seu Ip, literalmente uma tonelada de coisas. E sim, é uma cápsula. Nós o descrevemos declarativamente em um arquivo YAML simples. Tinha uma especificação de contentor e embrulhamo-lo como uma cápsula. Em seguida, usamos Cube CTL para enviar que YAML para o servidor de API costas. Obviamente, fomos autenticados com base no que está no arquivo de configuração do cubo. O YAML foi expandido com todos os valores padrão e coisas que não especificamos. E foi armazenado em um armazenamento de cluster. Em seguida, o pod definido nele foi agendado para o cluster e ele está em execução. Maravilhoso. Bem, na próxima lição, veremos como nos conectarmos a ela. 12. Conexão por um serviço: Então nós temos um pod rodando, e dentro dele há contêiner rodando, um aplicativo web simples, mas nunca nos conectamos diretamente a esse pod. Então nunca pegamos seu IP ou algo assim e abrimos um soquete para ele. Agora, há um monte de razões para isso e vamos cobrir algumas delas em breve. O que precisamos saber agora, porém, é que para acessar aplicativos em um pod, precisamos de outro Kubernetes é objeto chamado de serviço. E aquele simples morto, certo? Pense em um serviço como cantarolando um front-end e back-end. No front-end, cada serviço recebe um nome, um IP e uma porta. E Kubernetes dá uma garantia de ferro fundido que esses valores nunca mudarão. Em seguida, no backend, eles têm uma porta e o seletor de rótulos. O tráfego entra no front-end. Meu serviço na porta 30,001 ou o que for. E ele é empurrado para fora do backend na porta 8080 neste exemplo, e carga balanceada em todos os pods no cluster com o aplicativo, um rótulo da Web não pode ser ESEA. Então, o exemplo que vamos abrir tem como, eu não sei, dez partes podem ser, mas o serviço está apenas enviando tráfego para aqueles com o aplicativo é igual a magia da etiqueta da Web. Bem, aqui está um serviço. Começamos com a versão da API e tipo novamente, então isso quer dizer, Ei, Kubernetes, Dê-me um serviço, por favor, e baseá-lo na definição V1 de um serviço. - Sim. Mas, em seguida, a configuração do front-end primeiro, vamos dar-lhe um nome. Agora, isso é registrado no serviço interno do Kubernetes DNS. Isso significa que o nome do serviço será solucionável de dentro do cluster é SVCs A101. Este está ouvindo em duas portas. Isto ainda é o front-end, lembras-te? Então está diminuindo dentro do cluster na porta 8080 aqui e fora do cluster. Portanto, para conexões vindas de fontes externas na porta 30,001. Assim, os aplicativos dentro do cluster podem atingir fase S A101 na porta 8080 aqui e chegar ao front-end do serviço. - Também. Embora. Esta porta de nó aqui diz para também escutar na porta 30,001 em cada nó no cluster. Então, podemos entrar de fora do cluster e atingir qualquer nó no cluster usando seu nome ou seu IP na porta 30,001 e mesmo resultado, atingimos o serviço, certo? Bem, essa é a configuração do front-end, a configuração do backend como para onde o tráfego é encaminhado? Bem, sai da parte de trás na 8080. Novamente, neste exemplo, ele não precisa escrever uma cópia de uma porta diferente, mas ele irá para qualquer pod no cluster com o rótulo da Web API, que eu acho que se olharmos para o nosso pod aqui. Sim, ele está ouvindo no 8080 e é rotulado como AP é igual a Web. Então, se implantarmos esse serviço e você se acostumar com isso, certo? Eu tenho o arquivo YAML da FVC aqui. Se você está acompanhando, certifique-se de que você também tem isso localmente. Agora, você pode chamar os nomes do arquivo o que quiser, certo? Não tem que ser SBC dot yaml. Mas quando você digitar os comandos, se tiver alterado o nome do arquivo, certifique-se de que não digita apenas o que estou digitando. - Sim. Bem, olhe, novamente, ele é enviado para o servidor API, autenticado e autorizado. Obtemos uma atualização para o nosso estado desejado persistiu no armazenamento de cluster e o serviço é criado. Olhando bem. Agora, serviços e não como pods, eles realmente não executam nenhum código de aplicativo. Basicamente, há um monte de rede em coisas, certo? Assim, como tabelas IP ou regras IP VS que interceptam o uso do endereço IP de serviços e fazem qualquer magia de rede necessária para encaminhar ou carregar o tráfego balanceado para os pods corretos que estão executando nossos aplicativos. Agora como antes, e você vai se acostumar com tudo isso, certo? Mas você pode vê-los com o habitual Cubo CTL obter em Cubo CTL descrever comandos. Então lá está, SVCs A101, e eles descrevem dá-nos uma saída bem formatada com um pouco mais de detalhes. Mas não vamos esquecer por que criamos isso, certo? Dissemos que nunca falávamos diretamente com as cápsulas. Nós sempre colocamos um serviço na frente deles e falamos com o serviço. Então, se você é um aplicativo em execução no cluster ou você sabe o que, você pode até ter uma sessão exata em um pod de aplicativos em execução no cluster. Você seria capaz de chamar o nome do serviço. O nosso é o SBC 1.0.1 na porta de serviços. Agora a porta interna, lembre-se era 8080 e você chegaria ao serviço. Agora, se você estiver fora do cluster, talvez você esteja em seu laptop ou em um cliente de aplicativo externo ou algo assim, então você apenas acerta o IP público ou o DNS público, qualquer um dos nós no cluster nessa porta, 30.001, e você vai alcançá-lo também. Bem, olha, falar é barato, certo? Meu cluster do Kubernetes está no Google Cloud. Então eu procuro o IP público de um desses nós. Obrigado como sempre, Gk pelos seus nomes de nódulos horríveis que estragam as minhas colunas. E eu vou ter esse IP externo no entanto. E vamos colocar isso em uma nova sessão do navegador, 30.001. E lá estamos nós como por magia. Agora, olha, realmente não quero trabalhar o ponto, mas eu realmente, realmente quero que você se afaste deste curso entendendo os fundamentos. Então deixe-me ser claro, certo? Este serviço obtém um nome estável e um endereço IP no cluster. Quando eu digo estável, certo, Kubernetes é super mindinho promete que esses valores nunca vai mudar enquanto o serviço existe. O nome do serviço é registrado com o DNS interno de clusters, significa que qualquer parte de seu aplicativo no cluster pode enviar tráfego para o nome do IP do serviço em sua porta, e ele chegará ao serviço. Depois de chegar ao serviço, tráfego é balanceado de carga entre pods no cluster com um rótulo correspondente. Mas ainda não terminamos, certo? Porque esse serviço específico que criamos é um serviço de porta de nó. Outros existem, certo? Mas este é um serviço de porta de nó, e isso significa que ele obtém uma porta extra, 30.001 em nosso exemplo, que é exposta ao mundo externo por meio de cada nó em um cluster. Ou seja, se você tiver um cliente externo, como meu navegador que acabamos de ver, você pode atingir qualquer nó no cluster dessa porta e chegar à superfície. E, eventualmente, o aplicativo, que como dissemos, em seguida, equilibra a carga do tráfego, depositando o cluster com a API vai rótulo web, e alcança o aplicativo. Agora, finalmente, eu acho certo, nós podemos atingir qualquer nó no cluster naquela porta. Esse nó não precisa estar executando uma réplica do pod. Quem? Certo, uma última coisa. Então por que eles são Nigel, precisamos falar com um serviço em vez de diretamente para casulos? Quem sim, ótimo guia de perguntas que você fez. Então imagine esse cenário novamente. Escreva um monte de pods no grupo e quer saber, vamos perder aqueles que não combinam com a nossa gravadora. Ok, parece cinco para mim. Digamos que a hospedagem de nosso front-end web e demanda aumenta causa o que quer que seja, certo? Temos uma promoção ou algo assim, talvez seja Black Friday. - Sim. Então, adicionamos mais para lidar com a demanda. Will, como as outras partes do nosso aplicativo souberam sobre essas novas cápsulas que acabamos de adicionar? E funciona na mesma. Nós reduzimos e fazemos alguns deles irem embora. Quero dizer, nós não queremos que nossos desenvolvedores inchem seu código escrevendo lógica para rastrear coisas assim. Agora, então, em vez disso, construímos serviço. Isso fica na frente dos pods e oferece esse nome garantido, IP e porta. Assim, à medida que adicionamos e removemos pods na parte inferior aqui, o serviço mantém o controle congelado e literalmente esconde toda a escala para cima e para baixo que está acontecendo na parte inferior aqui. Certo? Então, sim, como dissemos sobre loops de observação de fundo antes, há um loop de controle para o objeto de serviço no fundo que está sentado lá dia após noite após dia após noite, mastigando pipoca, observando novos pods que correspondam aos rótulos no serviço. À medida que novos pods correspondentes são adicionados, o serviço atualiza sua lista de pontos de extremidade. E adivinha? À medida que as cápsulas desaparecem, faz o mesmo. Mantendo sempre uma lista atualizada de vagens correspondentes saudáveis. Coisas boas. E nós terminamos. - Sim. Em seguida, vamos falar sobre auto-cura. 13. Como usar implantações: Agora, então, até agora, temos implantado um pod e serviço. O pote é onde nosso aplicativo é executado e o serviço é como nos conectamos somente a ele. E isso me esmaga toda vez que tive a conversa. Nós nunca implantamos cápsulas diretamente. E aqui está o porquê de escrever isto. Aqui está uma cápsula embrulhando um recipiente e quer saber? Literalmente, a única coisa que uma dose de pod primeiro é deixar o recipiente dentro dele funcionar no Kubernetes. Você provavelmente se lembra, dissemos que os contêineres não podem ser executados diretamente no Kubernetes. Temos que embrulhá-los em uma cápsula. Will Magic, isso é ótimo. Colocar vagens nos dar agachamento. Então absolutamente 0 quando se trata de coisas como auto-recuperação, dimensionamento, execução de atualizações e reversões versionadas. Para todas essas coisas boas que precisamos implantar, que como mostra a imagem, envolve um pod. Então é um pouco como passar o pacote este ano. Temos contêineres envolvendo nosso código de aplicativo, pods, embrulhando nossos contêineres e agora uma implantação envolvendo um pod. E como a foto diz, a implantação é o que nos dá todas as coisas boas. Bem, isto é o que parece. Agora, a partir de baixo aqui, temos o mesmo contentor velho, certo? Inalterado. Por isso, já devíamos estar a habituar-nos a isso. E, em seguida, tipo de embrulho não temos um monte de coisas pod. Então, esses são os rótulos que o POD obtém para que esse serviço que criamos possa enviar tráfego para ele. Sim, o mesmo de antes, certo? E então, finalmente, temos o material de implantação bem no topo aqui que está envolvendo o POD. Bem, indo do topo desta vez temos o nosso esquema habitual de aversão e tipo de recursos. Então, dê-nos uma missão, por favor. O Kubernetes é baseado na definição do esquema V1 no subgrupo de API de aplicativos. Dê à implantação em si um nome e alguns rótulos. Agora, estes não devem ser confundidos com os rótulos POD mais abaixo. Ok? Mas então chegamos a algumas coisas interessantes. Selecione rótulos de correspondência. Isto aqui é como o rótulo selecionado que vimos no arquivo YAML serviços, certo? Então, ele está dizendo que esse objeto de implantação vai gerenciar pods no cluster com este rótulo API chama web. Então temos réplicas iguais a um. Então, quando enviarmos isso para o servidor de API, ele vai agendar exatamente um pod com base na definição abaixo. Agora, essa é a parte de escala, certo? E voltamos a ele mais tarde. Na verdade, é na verdade parte da auto-cura também. Mas antes de todo esse tipo de estratégia está rolando atualização. Então, quando chegar a hora de atualizar tudo isso aqui na definição do pod, Kubernetes vai fazer o que é chamado de Atualização Rolante. Agora, eu sei muito para digerir aqui, certo? E virá a cada bit por sua vez. Então não se preocupe, pensando que estou esperando que você troque tudo agora, você não escrever vai chegar a tudo no devido tempo. Por enquanto, estas são as implantações aqui atrás, definindo todas as coisas boas que nos dão auto-cura, atualizações, todo esse tipo de jazz, certo? Embrulhando em torno de um pod, que por sua vez está hospedando um único contêiner. Agora, uma pergunta que me fazem o tempo todo é, pode um pod ter mais de um contêiner? E a resposta é, sim, definitivamente. Mas esse é um caso de uso avançado, certo? Onde 101 curso. Então estamos apenas olhando para o modelo de um contêiner por pod. Mas deixe-me apenas dizer direito, o contêiner múltiplo por modelo pod é realmente poderoso e é alavancado fortemente por coisas como malhas de serviço. Agora, há outras coisas que o aproveitam também. Mas você sabe o que as malhas de serviço é um tópico quente agora e você sabe o quanto nós amamos um bom buzzword. De qualquer forma, olha, eu tenho o arquivo localmente. Se você está acompanhando, você vai necessitar. Então você clonou o repositório do GitHub ou copiou e colou o conteúdo do GitHub em um arquivo. E então é apenas o nosso confiável comando Cube CTL aplicar. E eu sei que estou ficando como um disco quebrado agora, certo? Mas isso vai para o servidor de API, autenticado e autorizado, armazenado no ETC, dia não programado para o cluster. Então Cube CTL só para ter certeza que está funcionando, o que é, sim. E então um CTL cubo recebe cápsulas. Boom. Lá está ele. Um novo pod sendo gerenciado pela implantação com todos os superpoderes que vêm com isso, certo? Então, como dizemos, auto-recuperação, escalabilidade, execução de atualizações, reversões, tudo isso, bondade, sim. Na verdade, o velho casulo um-a-um aqui, provavelmente está se enchendo um pouco inferior, mas como estar ao lado de Tony Stark. Sim. Enfim, por falar em superpoderes, seguir vamos ver alguma auto-cura. 14. Auto-cura: Muito bem, temos um par de cápsulas a funcionar. Este aqui está sendo gerenciado por uma implantação. Então é tudo Tony Stark WAR com superpoderes como auto-cura e tal. Sim. Mas a parte 101 aqui, é como eu, um pouco velho com superpoderes. Recentemente me aposentei de jogar futebol ou futebol dependente de onde você mora. Basicamente, porque meus joelhos têm 0 poder de cura nos dias de hoje. De qualquer forma. Um pod gerenciado por uma implantação e o outro não. Então, se fizermos isso aqui com a cápsula 101, está certo? Se colocarmos um relógio e colocarmos cápsulas aqui. Ok. Não se foi, mas vai dar alguns segundos para fazer. É justo dizer que não está voltando 0 superpoderes. Agora, então, se olharmos para nossa implantação aqui que está gerenciando nosso POD restante. O que está dizendo aqui em cima, é sempre ter certeza de que há um desse pod rodando no cluster. E pode parecer bem simples, certo? Mas acredite em mim, a maquinaria e o fundo, como todos os loops de relógio e todas as outras coisas. Quem pegou a Italia? Este é o ingrediente secreto para superpoderes. Isso dá ao nosso POD invencibilidade restante. Bem, vamos ver de qualquer maneira. Então, se tentarmos matá-lo com um destes, levem o descongelamento, Homer até ele. Vamos assistir ao live action novamente. Oh, o que é isso? Olhe dentro? Como dois contêineres. E o que é tudo isso que as autoridades de negócios terminaram tinham superpoderes. Bem, o que está acontecendo aqui é que nós acabamos de matar a cápsula descongela o martelo. Sim. E como seria de esperar com o martelo, a cápsula morreu. Mas o que as implantações fizeram em Lockerbie em alto nível um pouco de cabelo, certo? Mas criou uma nova cápsula idêntica em seu lugar. A única diferença é realmente esta parte no final do seu nome aqui. Então agora se pode escrever de uma forma que estamos trapaceando. A cápsula morreu e foi substituída por outra idêntica. Então os antigos se foram e um novo clone, se você quiser, está em seu lugar. Mas quer saber, do ponto de vista da aplicação, não é trapaça. A aplicação continua. Quero dizer, sua inscrição não se preocupa com nomes de POD ou algo assim, certo? Do ponto de vista do aplicativo, as evidências ainda estão em execução. E quer saber, certo? Isto é muito melhor quando há como várias réplicas em execução aqui e uma morre e é imediatamente substituída. Normalmente, nessa situação, o aplicativo não pula bater. Agora também, certo? Isto é o mesmo se algo quebrar no aglomerado, como se eu soubesse que acabamos de matar manualmente a parte da bala escrita à mão. Digamos que um nó morre no cluster e leva alguns pods com ele. Bem, se essas cápsulas, Raul Tony abasteceu a implantação. Agora pânico, certo? As cápsulas perdidas são substituídas e o mundo continua girando, o que é brilhante, quer saber? Podemos até atualizar nossa guia do navegador aqui sem alterar qualquer um dos URL. Porque o que aconteceu corretamente é que o objeto de serviço que está fazendo toda a rede para o Palladia está oferecendo esse endpoint super estável. Acho que podemos chamar o ponto final de Tony Stark também. Sim, isso é garantido para nunca mudar o seu invencível, certo? E sempre tem uma lista atualizada de vagens que correspondem às etiquetas que procura. E obviamente o novo público foi girado que acabamos de ver lá. Tem os mesmos rótulos. Sim, então estamos todos bem. E esse pessoal é um aspecto do ano de auto-cura. Mas a coisa legal, certo? Isso poderia ter acontecido às três da manhã. E Kubernetes consertou isso sem nos acordar de um pouco disso. Mas quer saber, estamos longe de ser feitos em seguida, escalar. 15. Escalar: Então outra coisa que as implantações nos dão é escalar essa capacidade de dizer que eu preciso de mais ou menos de um pod específico. Uma coisa que Gus disse antes, talvez seja o fim do mês e informe para fazê-lo, vamos ter mais pods que suportem a infra-estrutura de relatórios. Ou talvez tenhamos algumas ofertas ou algo assim e esperamos um aumento do tráfego. Então vamos aumentar a escala dos bits que suportam a navegação e as pesquisas em Curtidas. Bem, se olharmos para o que temos, sim, uma única implantação chamada implantação um-a-um e tem uma réplica. Então, a maneira como aumentamos para dizer cinco, para abrir o yaml de implantação aqui e olhar para o mundo real, certo? Você vai gerenciar isso da mesma forma que você gerencia seu código, esperançosamente. Então, no controle de fonte ou algo assim, sim, mas você vai verificar e todo esse jazz, sim. E então esperamos que estas réplicas contem aqui até cinco. Venha aqui e salvaremos nossas mudanças. E então nós apenas reaplicamos isso ao cluster e verificamos novamente no controle de versão, claro, sim. Mas está literalmente atualizando esse Yammer, que é nossa fonte de verdade, e depois reemiti-lo para o servidor de API que é registrado como um novo estado desejado, passando de uma réplica para cinco. O circuito de controle de fundo avisa, hey, nós queremos cinco, mas na verdade só temos um. Então ele gira para mais. E lá temos cinco cápsulas. Agora, podemos, se quisermos escalar usando o comando Cube CTL scale. Mas não acho que seja o jeito de Kubernetes. E eu digo-te porquê, certo? Fazê-lo assim é a maneira imperativa, não a maneira declarativa. Então imagine comigo, certo, que você gerencia um cluster do Kubernetes com um monte de aplicativos e há um P1 acontecendo. Sim. Então é como alerta vermelho todas as mãos para postos de batalha e você está digitando fora olhando para eventos e registros e seus chefes pairando sobre seu ombro e seus chefes constantemente no telefone em seu Bedlam, certo? Mas é ótimo. Sim. Quero dizer, você tem todo o pagamento de um. Eles são muito difíceis de vencer ação e emoção. E quer saber? Você tende a aprender uma tonelada. De qualquer forma, olha, está tudo a acontecer assim, certo? Você fazendo mudanças na mosca imperativamente. Sim. Só mudando as coisas como você vai. E digamos que o problema e eu estou inventando isso, certo, mas digamos que o problema era que a porta de rede em que seu aplicativo está operando não está funcionando. De qualquer forma, você muda a porta que você usa na hora. Então, na linha de comando sem fazer check-out do arquivo YAML, sem atualizar o arquivo do Yammer e sem reaplicar isso de volta ao cluster. De qualquer forma, então você muda a porta de rede em tempo real e são celebrações Q, certo? Você tem sido high-five os chefes por novas bebidas depois trabalho e em meio a toda a adoração e geral enlouquecendo, você esquece que você mudar o porto ao vivo para como 9 mil ou algo assim, colocá-lo à esquerda. Está 8080 em seu arquivo YAML. E a razão pela qual isso é ruim, certo? É porque o que está ativo no cluster não corresponde mais a você. Yaml e Kubernetes não tem como saber isso. Bem, vamos enrolar o relógio um pouco para frente e dizer que é uma semana ou o que quer que seja mais tarde e você está empurrando uma nova imagem para o aplicativo. Então, se tudo o que você procedimento normal, certo, porque este não é mais um P1, então isso é tudo controlado. Sim. Você verifica o YAML, atualiza a versão da imagem usada e envia o YAML para o cluster. Somente. Você não percebeu que a Yamaha ainda diz que a antiga porta 8080, que está quebrada e não funciona mais. Então, quando você reimplantá-lo, sim, você obtém uma nova imagem, mas você também tem a porta quebrada antiga de volta. Agora uma promessa aqui. O que é o ano de cinco anos ou comprar suas bebidas desta vez? Então, fazer mudanças imperativas como essa geralmente não é recomendado. Sabemos o que estou a fazer. Agora temos cinco réplicas com um observador de fundo apenas olhando para o cluster o dia todo, certificando-se de que o estado desejado corresponde ao nosso estado observado real. Agora, é claro, é o mesmo se reduzirmos o número, escrevermos, atualizarmos o YAML, enviá-lo de volta para o servidor de API. Fabuloso. Só que, quer saber, é tudo um pouco manual, não é? Quer dizer, requer que eu ou você seja um ser humano para fazer o trabalho. Felizmente, a Kubernetes tem tecnologias de dimensionamento automático. O escalador automático de pod horizontal que pode olhar para quão ocupado seus pods estão e escalar para cima e para baixo dinamicamente. E há um scaler automático de cluster que pode aumentar e reduzir o número de nós em seu cluster. Novamente, dinamicamente baseado em se há capacidade suficiente no conjunto atual do cluster para gerar novos pods em Curtidas. Infelizmente, esses tópicos estão além do escopo deste curso 101. De qualquer forma, bloqueie por enquanto neste eu uma causa que está escalando. Chegando. Em seguida, vamos integrar o aplicativo com um balanceador de carga baseado em nuvem. Traga-o. 16. load-balancers de carga na nuvem: Agora, então, eu sinto muito. Se você estiver acompanhando seu laptop com o Docker desktop, ou se estiver acompanhando o jogo com o Kubernetes, você não poderá seguir este laboratório. Este laboratório só funcionará se o seu cluster estiver em uma nuvem pública ou na Sandbox mágica, que é executado em uma nuvem pública. De qualquer forma, mentes no Google Cloud, no motor Google Kubernetes. Então eu estou pronto para ir agora, não sendo capaz de seguir adiante. Sinto muito, mas quer saber? Apenas assista. Ok. Você ainda está entendendo. Não é difícil o que estamos prestes a fazer. De qualquer forma, olha, nós temos um aplicativo simples implantado, cinco réplicas aqui de um servidor web simples. E temos um serviço Kubernetes que está fornecendo uma rede estável para as réplicas. Mas o tipo de serviço que temos é um serviço de porta de nó, que se voltarmos a pensar, nos permite acessar nosso aplicativo através de um nome ou um IP de dentro do cluster na porta 8080, que é tudo bom. Mas se quisermos acessar de fora , precisamos do nome ou do IP público de pelo menos um de nossos nós. Em seguida, com a nossa configuração, nós batemos na porta 30,001 e entraremos. Isso é bom, certo. Mas sejamos honestos, é um pouco lixo na verdade. Quero dizer, quem quer manter o controle de nomes de nós ou IPAs? Sim. Então, uma maneira muito mais elegante seria fronted todos com um balanceador de carga. E sério, fazer isso não poderia ser mais fácil. Na verdade, tenho vergonha de como é fácil. Então este YAML aqui, que vai parecer muito familiar, vai integrar aqueles com um Cloud load balancer. Então, de qualquer maneira, olhar o mesmo fora da minha antiga versão API e tipo nós sabemos tudo sobre eles. Dê um nome e um rótulo. E, em seguida, uma configuração de front-end aqui dizendo a porta 8080 no que quer que obtenhamos como nosso Cloud Load Balancer. E, em seguida, balanceamento de carga fora do backend do serviço no 8080 para qualquer pod com a API é igual a etiqueta wed. Então, já vimos tudo isso, certo? A única diferença real do último serviço que implantamos é esse tipo de balanceador de carga aqui. Então, como eu disse, se você estiver em uma plataforma de nuvem e todas as grandes aplicarem AWS Azure, Google, oceano digital, IBM Cloud, dê o nome certo definindo uma única palavra aqui. Balanceador de carga, Kubernetes vai embora, falar com sua nuvem. Provisão de hábitos, um balanceador de carga voltado para a Internet que aceita tráfego na porta 8080 e certifique-se de que ele tenha balanceamento de carga em todos os pods que executam seu aplicativo também na porta 8080. Quero dizer, quão legal é isso agora, a política, eu não tenho muito, certo? Eu acho que o ponto de levar para casa é que, com pouco esforço, temos um balanceador de carga completo e altamente disponível integrado com o nosso aplicativo. Novamente, uma aberração, adorei. De qualquer forma, olha, eu tenho o arquivo localmente. Sim. Significa que é hora do nosso velho amigo Cube CTL aplicar. Diga o arquivo e ele vai embora. Agora, se eu vigiar este comando aqui, provavelmente serão semelhantes em menos de um minuto. E eu vou editar o vídeo, certo? Então você não precisa olhar para a tela esperando, colocar em cerca de um minuto, esses valores pendentes aqui sob o IP externo vai mudar para um IP público válido adequado como esse. E podemos acertar isso na porta 8080, quem e como se por magia, certo, esse é o nosso aplicativo. Assim, todo o aplicativo web em execução em um contêiner, envolto em um pod por sua vez, envolvido em uma implantação em nosso cluster privado do Kubernetes, liderado por um serviço Kubernetes que fornece um ponto IPN estável integrado a uma nuvem nativa balanceamento de carga, certo? Quero dizer, isso é um monte de coisas boas, certo? Colocar você sabe o quê? É tão simples, estamos vendo isso aqui em uma causa um-para-um. Quero dizer, quão excelente é isso? Acho que vai concordar que é excelente. E quer saber, certo? Não vamos esquecer que o serviço está constantemente assistindo para garantir que ele tem a mais recente lista de pods para equilibrar para o. E você sabe o que, ele só balança de carga para pods saudáveis. E estamos literalmente arranhando a superfície. Vamos lá. Espero que não tenha sido muito alto se estiver ouvindo nos fones de ouvido. Mas quer saber, ainda não terminamos. Quero dizer, nós quase R, mas não completamente. Uma última coisa, uma atualização contínua. 17. Atualizações de rolagem: Certo, última lição adequada. Temos um aplicativo web simples em execução no Kubernetes, e nós vimos a si mesmo, vamos aumentar a escala e apenas vimos que ele se conecta a uma Internet voltada para o Cloud Load Balancer. Bem, vamos ver como podemos fazer uma atualização contínua. Assim como as coisas estão, se olharmos para a implantação, devemos ver nos contêineres, a versão da imagem. De qualquer forma, aqui em cima temos cinco réplicas. Então cinco pods rodando um contêiner baseado nessa imagem. Mas digamos que fizemos uma imagem atualizada e passou em todos os testes de integração e os gostos. E o último passo é distribuí-lo para o cluster. Bem, implantação, faça isso sem nem suar. E a maneira como fazemos é a maneira declarativa. Então voltamos para o YAML aqui e c aqui nas réplicas, temos uma estratégia Rolling Update. Bem, na verdade, vou colar estas linhas. Tudo bem. Então este bloco que eu estou destacando, isso nos dá algum controle sobre como a atualização rolante acontece. O que estamos dizendo é que quando atualizamos qualquer coisa no bloco de modelos mais para baixo, faça uma atualização contínua. Isso significa uma réplica de cada vez. Homens prontos segundos aqui diz, Depois de atualizar cada réplica, antes de fazer a próxima, espere dez segundos. Agora, talvez no mundo real você diria alguns minutos ou algo assim. A ideia, porém, é dar-lhe algum controle e deixar você colar o ano de lançamento. Bem, Max indisponível diz que enquanto a atualização está acontecendo, nunca vá mais do que um abaixo do que estamos pedindo. Agora. Estamos pedindo cinco. Então nunca vá mais do que um abaixo disso. Então, no entanto do que por agora com o máximo disponível era como dois, então Kubernetes seria permitido descer para três durante a atualização. E da mesma forma para o Mac Surge, nunca vá mais de um a mais do que o que estamos pedindo. Agora. Quer saber, certo? Há muitas mais opções , incluindo sondas e testes e curtidas, que garantem que depois de atualizar um pod, ele está realmente funcionando. - Sim. Mas sabes que mais? Primeiro, agora temos algumas configurações de Atualização Rolante. E eu acho que provavelmente o que vai dizer ter mais efeito é a espera de 10 segundos após cada atualização. Mas vamos descer aqui e mudar a versão da imagem de 1.So 0 para dois. Guarde isso. Agora, quando publicá-lo para o servidor API terá um novo estado desejado de sim, cinco pods. Mas desta vez, todos os cinco estarão querendo executar o 2.0. imagem, o loop de reconciliação de fundo. Notaremos que não corresponde ao que está realmente no cluster. Assim, ele irá corrigir as coisas apenas os segundos mínimos prontos e os outros valores que mencionamos exercerão controle sobre como a atualização acontece. Então vamos fazer isso, certo? E eu tenho um comando aqui que vai monitorar a atualização que está pronta para ir. E lá vamos nós. Vamos executar este. Está bem. Olha, eu sou um, vá em frente e acelere o vídeo em segundo plano porque nós temos este período de 10 segundos fresco. - Sim. E uma promessa. Não seria divertido me ouvir cantar para preencher o tempo. Então, sim, bem, olha, podemos ver que é metodicamente pisando em cada réplica. Agora. Está passando por dois de cada vez aqui porque o máximo indisponível e o pico máximo estão ambos ajustados para 11 mais um é dois. De qualquer forma, se eu começar a atualizar a guia do navegador aqui, devemos ver às vezes eu recebo a versão atualizada e às vezes a mais antiga. E, eventualmente, cinco réplicas estarão atualizadas. Um tudo vai ter é a nova versão. E que senhoras e senhores quatro filas no 101 curso. Isso vai fazer. Agora. Honestamente, há muito mais como parece nunca acabar. Kubernetes é uma plataforma vasta e ainda está em evolução. E então há coisas que nós olhamos é estável e podemos confiar em todas essas coisas. Coloque Kubernetes faz muito mais e eu não vou mentir. Pode ser assustador e a curva de aprendizagem pode ser difícil. De qualquer forma, já cobrimos muita coisa. Então fique por perto para uma rápida recapitulação dos principais pontos para casa. Além disso, vou apontar para alguns lugares que o ajudarão a levar para o próximo nível. 18. Um recolher realmente rápido: Tudo bem, então por onde começamos? Sim, definimos o que é um aplicativo de microsserviços nativo na nuvem. É apenas uma maneira moderna de construir um aplicativo útil a partir de muitas partes especializadas que nós livremente acoplamos usando APIs só porque eles são chamados nativos de nuvem não significa que eles são apenas para a nuvem. Na verdade, eu diria até mesmo que um princípio da nuvem nativa é provavelmente a capacidade de executar em qualquer lugar, incluindo seus data centers locais. Quero dizer, desde que você esteja comandando Kubernetes lá, sim. De qualquer forma, dissemos que o Kubernetes é a plataforma de fato para executar aplicativos nativos na nuvem. E que Kubernetes é duas coisas. É um cluster e é um orquestrador de aplicativos. Então, o cluster é como o substrato ou a plataforma, se preferir, em que executamos nossos aplicativos. Ele consiste em mestres que executam todos os Kubernetes é inteligente e lógica. E tem um monte de nós de trabalho onde executamos nossos aplicativos de usuário. Agora, olhe, é um aglomerado de mundo irregular no final do dia. Portanto, precisamos pensar em coisas como disponibilidade, segurança e desempenho e tudo isso. Meu Deus, sim. Agora, no aplicativo orquestrar diferentes Kubernetes podem implantar e gerenciar nossos aplicativos. Para nós, dissemos que o padrão preferido é chamado de padrão declarativo, onde definimos o que queremos qualquer arquivo YAML. E nós vamos em Kubernetes fazer o trabalho duro para nós. Então, a maneira como funciona é Kubernetes mantém um registro do que queremos como algo chamado estado desejado. E ele executa um monte de loops assistidos que os diferentes aspectos do nosso cluster e dos nossos aplicativos. E basicamente, eles estão constantemente verificando se o que está sendo executado no cluster é o que queremos. Sempre que o estado observado se afasta desse estado desejado, Kubernetes faz tudo o que está ao seu alcance para colocar tudo de volta em linha com o estado desejado. E o que mais dissemos? Sim, dissemos que escrevemos nossos aplicativos como o normal, usamos as ferramentas do Docker para criá-las como imagens de contêiner e, em seguida, usamos o Kubernetes para implantá-las e executá-las. Agora, sim, o Kubernetes orquestra aplicativos em contêineres, que é apenas um jargão techno para aplicativos que são executados dentro de contêineres. Sim, só contentores não podem correr directamente para além do Kubernetes. Primeiro, precisamos empacotá-los como Potts. Agora, podemos aumentar ainda mais as cápsulas com muitas coisas, certo? Mas o que olhamos foi o destacamento. E isso dá aos pods superpoderes, sim, como a capacidade de vender, falhar e escalar e até mesmo fazer 0 atualizações de tempo de inatividade. E isso eram aqueles. É só para isso que temos tempo. Mas meu Deus, há muito mais. Mas é um ótimo momento para aprender Kubernetes. Agora, se você gosta de livros de Deus, alguém pode gostar do Quickstart Kubernetes, a ESEA está no nível deste curso. Mas se você estiver pronto para passar para o próximo nível o livro do Kubernetes aqui é listado regularmente como um best-seller na Amazon e tem as classificações mais estrelas de qualquer livro no Kubernetes. Oh, e é atualizado anualmente, por isso está sempre atualizado. Agora, você pode obtê-lo como um eBook no Kindle e Leanpub, um livro com capa comum na Amazon. Há edições em espanhol, chinês simplificado e russo disponíveis e uma versão em áudio, mas isso é apenas um inglês. Oh, meu Deus. Você sabe o que? Há até um apego à adição de tributo. Mas sem brincadeira. A edição klingon, é apenas a capa e a introdução que estão chamando os restos em Inglês. De qualquer forma, olha, o tempo é curto e eu estou começando a waffle. Sinta-se livre para se conectar comigo. Eu não posso ser um suporte técnico gratuito, mas estou mais do que disposto a me conectar e ajudá-lo a trabalhar seus primeiros passos. Então não seja tímido. Vamos nos conectar de qualquer maneira. Olha, obrigado por passares o teu tempo comigo. Boa sorte com sua carreira. E como eu disse, mantenham-se em contacto.