PuppetConf 2016. Kubernetes para administradores de sistema. Parte 1

Eu sou um administrador de sistemas, lidando com computadores, e hoje falaremos sobre o Kubernetes. Tentarei me aprofundar no tópico, considerando os problemas que o administrador do sistema pode resolver com esse aplicativo e também abordar alguns aspectos da operação do Puppet, que pareciam se encaixar nesse mundo com a ajuda de um novo conjunto de abstrações para o aplicativo funcionar.
Há cinco ou seis anos, Luis Andre Barroso e Urs Hoesl no artigo “Data Center como um computador” sugeriram que deveríamos perceber o data center como um computador enorme. É necessário abstrair do fato de que o data center consiste em máquinas separadas e considerá-lo como uma entidade lógica. Assim que você tenta usar essa idéia na prática, pode aplicar os princípios de construção de sistemas distribuídos e computação distribuída aos data centers.



Para tratar o datacenter como um computador, você precisa de um sistema operacional. Parece muito semelhante ao que você usa em um computador separado, mas deve ter uma interface diferente, porque você não precisa de acesso a uma máquina separada e não precisa de acesso ao kernel. Então, vamos pensar no data center como um grande computador. Hoje vou lhe dizer o que fazer se você parecer privado da capacidade de controlar qualquer máquina usando SSH. Você não poderá fazer login e, embora algumas pessoas acreditem que sem isso é impossível controlar o sistema, eu vou lhe dizer o quanto pode ser feito com o Kubernetes. Primeiro, você deve pensar no Kubernetes como uma estrutura para criar plataformas distribuídas.



Isso não significa que, após o download do Kubernetes, você receberá uma interface do usuário que fornecerá tudo o que você deseja fazer com o sistema. Não, essa é apenas a base para criar as ferramentas necessárias para executar sua infraestrutura. Mostrarei como criar a integração usando a autoridade de certificação Let's Encrypt Certificate para automatizar o processo de certificação do meu aplicativo usando o Kubernetes como estrutura.



Muitas pessoas perguntam exatamente para que serve o Kubernetes. Eu trabalhei com o Puppet Labs por muitos anos e vi que essa coisa estava instalada em computadores para fornecer ao sistema uma API que não existia até o momento. Em vez de Bash, scripts YAML e coisas semelhantes, o Puppet forneceu um usuário DSL que permitiu que ele interagisse com as máquinas programaticamente sem scripts de shell. A diferença entre Kubernetes é que ele está localizado acima do nível de "ferro". Vamos nos concentrar não tanto na automação e abstração deste sistema, mas também nos relacionamentos, ou no contrato, entre nossa infraestrutura e aplicativos que vamos extrair de qualquer nó. No Kubernetes, não atribuímos aplicativos a máquinas, não existe um "manifesto de nó", o agendador considera os nós individuais simplesmente como recursos do datacenter,representando um grande computador.

Perguntas: “O Kubernetes roda no OpenStack, no VMware, no Bare Metal, na nuvem?” não faz sentido. A pergunta correta é: "Posso executar o agente Kubernetes para recuperar esses recursos?" E a resposta será "sim". Porque a operação desta aplicação é completamente independente da plataforma que você escolher.



Kubernetes é independente de plataforma. Kubernetes é declarativo da mesma maneira que Puppet. Portanto, você está relatando para qual aplicativo você o usará - neste exemplo, é nginx. Este é um contrato entre você, o desenvolvedor e o Kubernetes como um meio de criar imagens de contêiner.

Eu gosto de usar a analogia com a empresa de courier da FedEx - você não pode arrastá-los por um vagão inteiro de coisas e esperar até que eles resolvam tudo e enviem para onde deveria estar. Eles têm uma regra: coloque suas coisas em uma caixa. Quando você fizer isso, eles enviarão sua caixa e poderão saber quando ela chegará ao seu destino. "Se você não tiver uma caixa, não poderá trabalhar com nosso sistema".

Portanto, ao trabalhar com contêineres, é inútil discutir o que você tem - Python, Java e outras coisas, não importa - apenas pegue todas as suas dependências e coloque-as no contêiner. Muitas pessoas dizem sobre contêineres que parecem resolver os problemas de toda a infraestrutura. No entanto, o problema é que as pessoas não percebem os contêineres como duas coisas diferentes. A primeira coisa é a ideia de um formato de embalagem, a segunda é a idéia de um tempo de execução do contêiner. Essas são duas coisas diferentes que não necessariamente exigem as mesmas ferramentas.

Qual dos presentes criou os contêineres? E quem usa o Puppet para construir contêineres? É isso mesmo, eu também não concordo! Você pode dizer: “como assim? Você está na conferência Puppet, precisa concordar! ” O motivo pelo qual discordo da idéia de construir contêineres no Puppet é o seguinte: não sei se precisamos disso, porque as coisas que precisamos para criar uma imagem são diferentes das que precisamos para iniciar o processo de produção.

Vamos pensar nisso como construir um pipeline de software e dar uma olhada neste Dockerfile. Feche os olhos para aqueles que nunca viram esses arquivos, pois eles podem parecer intimidadores. Este arquivo mostra como criar um aplicativo Ruby on Rails - um aplicativo Ruby com uma estrutura Rails.



Ele diz “FROM ruby ​​2.3.1”, que provavelmente inserirá todo o sistema operacional no contêiner, neste caso, a imagem básica do Ruby alpino-linux. Alguém sabe por que incorporamos imagens do Ubuntu ou Red Hat nesses contêineres? A maioria das pessoas não sabe o que são dependências e usa uma abordagem aleatória, apenas colocando todo o sistema operacional em um contêiner para garantir que elas tenham suas dependências em algum lugar dentro. Então, depois de criar isso, você precisará executá-lo apenas uma vez. É daí que vem o mal-entendido: se isso não funcionar, altere a linha do código até que funcione. Apenas verifique! Você não precisa ser muito inteligente com esses arquivos, seu objetivo é criar uma representação offline do seu aplicativo com todas as dependências. Esta é apenas uma muleta que usamos no Ubuntu como ponto de partida.

Se você apenas criou o aplicativo e o lançou, usaria algo como um link estático. Sem dependências no host, em seu contêiner você teria apenas um arquivo binário de um Docker de linha única e nenhuma imagem básica. Na verdade, é apenas uma transferência de coisas que nos são familiares. Veja como esta montagem ficará.



Eu criei esse arquivo anteriormente, mas geralmente parece uma tentativa de criar toda a Internet. Eu tenho um pouco de medo desta montagem, porque não tenho certeza de que a Internet local possa lidar com Ruby. Veja o que aconteceu.



Como você gosta deste volume de 1 Gig? Além disso, o arquivo de origem, ou seja, o próprio aplicativo, pode ocupar, digamos, apenas 100 kB. Então, como conseguimos um gigabyte inteiro? Isso ocorre porque usamos ferramentas ineficientes para criar aplicativos independentes. Todos eles foram projetados para rodar em computadores e usar bibliotecas dinâmicas carregadas do ambiente externo.

Agora, tentaremos fazer o que fazemos em um telefone móvel - versões portáteis de aplicativos para as quais existe um contrato entre você e a infraestrutura. Assim que tivermos esse contrato, poderemos dizer ao sistema exatamente o que ele deve fazer e ele não se importará com o que fazer.

Você não possui nenhum aplicativo especial criado especialmente. Me deparei com empresas que dizem: "temos uma aplicação especial!". Eu digo: "Vamos adivinhar o que faz: ele inicia, liga-se à porta, recebe tráfego, faz algo com os dados" e eles são: "Uau, como você sabe disso?" Eu sei, porque não há nada de especial aqui!

Então, pegamos a amostra que colocamos no contêiner e a enviamos ao servidor da API. Em seguida, precisamos transformar isso em algo que funcione em nossa máquina. No entanto, para coletar recursos da máquina, precisamos instalar várias coisas: um tempo de execução do contêiner para o arquivo Docker, um agente que entenda como se comunicar com o assistente para executar tudo o necessário, qual deve ser a resposta do sistema para que o aplicativo comece a funcionar. . Esse agente está simplesmente observando - não há intervalos de 30 segundos, verificações repetidas, nada disso. Ele simplesmente observa, dizendo: “se houver trabalho para mim, informe-me, e eu começarei e o informarei constantemente sobre o status do processo”, para que você saiba que funciona.



Assim que fazemos isso de carro, precisamos de um agendador. Quantas pessoas usam o agendador? Vocês todos têm que levantar as mãos! É o mesmo que a resposta à pergunta: "qual de vocês tem um laptop com mais de um processador de núcleo único?". De fato, quando faço uma pergunta sobre o planejador, a maioria não levanta as mãos.

Quando você inicia seu processo em uma máquina, algo deve escolher qual processador usar. Quem trabalha isso? É isso mesmo, o núcleo. Agora vou explicar para vocês o que é um planejador. A maneira mais rápida de fazer isso é jogar Tetris. A primeira coisa que discutiremos é a implantação automática.



Quantos de vocês usaram a implantação totalmente automática? Claramente, acho que é por isso que estamos todos aqui. Então, pressiono o botão, os blocos começam a cair de cima e agora você pode ir tomar uma cerveja. Mas observe o que acontece à esquerda e à direita: seu processador e sua memória se transformam em lixo.



Isso acontece porque a maioria das pessoas usa no máximo 5% dos recursos do computador. Você automatiza processos, mas perde muito dinheiro. Eu trabalho como um provedor de nuvem, tenho enormes reservas de recursos, mas é horrível quando as pessoas gastam dinheiro de maneira semelhante.

Quando você usa o agendador, por analogia com o Tetris, controla o campo de jogo e controla cada bloco, direcionando-o para o lugar certo, ou seja, use os recursos da máquina da melhor maneira possível. O Kubernetes usa alguns algoritmos para isso. O algoritmo principal é chamado Bin Packing - o mesmo "Tetris" ajudará a entendê-lo. O Kubernetes recebe uma carga de trabalho de várias formas e tamanhos, e nossa tarefa é embalá-lo em máquinas da melhor maneira possível.

Nosso objetivo é reutilizar todos os recursos disponíveis à medida que o trabalho avança. Nem todas as cargas de trabalho são iguais, por isso é difícil colocá-las na mesma caixa. Mas no Kubernetes, quando uma “parte” da carga de trabalho aparece (ou o bloco Tetris, se continuarmos nossa analogia), sempre existe o cluster certo onde você pode colocá-lo e executá-lo. E, como em qualquer processamento em lote, após a conclusão da tarefa, recuperamos todos os recursos anteriormente ocupados para que possamos usá-los em tarefas futuras.

Como não vivemos no jogo, mas no mundo real, você tem soluções desenvolvidas há muitos anos. Então você se torna um administrador de sistema, os empregadores mostram sua produção e você percebe que a implantação não é boa o suficiente.



Você pode instalar gerenciadores de cluster em partes de suas máquinas e deixá-los gerenciar certos recursos. Nesse caso específico, você pode usar o Kubernetes, que começará a preencher os espaços vazios do seu Tetris à medida que avançar.
Que aqueles que trabalham na indústria levantem as mãos. Sim, este é um clássico chamado salário. Suponha que você tenha vários problemas em sua empresa. A primeira é que tudo é escrito em Java ou mesmo em COBOL - normalmente ninguém está pronto para isso.

O segundo problema frequentemente encontrado nas empresas é o Oracle DBMS. Isso é algo, localizado na parte traseira do software e dizendo: "Não tente automatizar nada!". Se você automatizar o software, seu custo aumentará. Portanto, sem automação - estamos promovendo nosso ecossistema de consultoria!

Normalmente, nessas circunstâncias, as pessoas perguntam se o Kubernetes pode simplesmente ser usado para resolver esses problemas. Eu respondo: "não", porque em uma situação semelhante à perda em Tetris, nada irá ajudá-lo. Você precisa fazer outra coisa, a saber, usar o agendador.
Agora que temos um agendador que entende com êxito as cargas de trabalho, você pode simplesmente colocar tudo em caixas e o agendador começará seu trabalho.



Vamos falar sobre as principais entidades do Kubernetes. Em primeiro lugar, esses são os pods, que são uma coleção de contêineres. Na maioria dos casos, um aplicativo consiste em mais de um componente. Você pode anexar a si mesmo um aplicativo gravado sem scripts Java, mas convém usar o nginx para concluir o TLS e apenas um proxy no plano de fundo do aplicativo, e essas coisas devem ser conectadas, pois são dependências codificadas. Uma dependência fracamente acoplada é um banco de dados que você dimensiona independentemente.



A segunda coisa importante é o Replication Controller, que é um gerenciador dos processos que ocorrem no cluster Kubernetes. Permite criar várias instâncias de lareiras e monitorar suas condições.

Quando você diz que deseja iniciar algum processo, significa que ele funcionará o tempo todo em algum lugar do cluster.

O terceiro elemento importante é o Serviço, um conjunto de lares colaborativos. Sua implantação é baseada na determinação dinâmica do estado desejado - onde os aplicativos devem funcionar, com qual endereço IP etc., para que você precise de algum tipo de serviço.

O quarto elemento são os repositórios Volumes, que podem ser visualizados como diretórios disponíveis para contêineres na lareira. O Kubernetes possui diferentes tipos de volumes que determinam como essa loja é criada e o que ela contém. O conceito de Volume também estava presente no Docker, mas o problema era que o armazenamento era limitado a uma lareira específica. Tão logo deixou de existir, o Volume desapareceu com ele.

O armazenamento que o Kubernetes cria não se limita a nenhum contêiner. Ele suporta todos ou alguns contêineres implantados dentro da lareira. Uma das principais vantagens do Kubernetes Volume é o suporte a vários tipos de armazenamento que o Pod pode usar simultaneamente.

Vamos ver o que é um contêiner. Este é o formato da imagem em que nosso aplicativo com todas as dependências é compactado e a principal configuração do ambiente de tempo de execução, mostrando como esse aplicativo deve funcionar. Esses são dois elementos diferentes, embora você possa incluir o que quiser, especialmente o Root Filesystem como um arquivo tar Tarball compactado que contém muitos arquivos de configuração para um sistema específico.



Em seguida, podemos executar a distribuição, um processo que é familiar a todos - o RPM ou outro sistema de repositório é usado aqui. Você pega todas essas coisas e as coloca no repositório. Esse processo é muito semelhante ao que fazemos com pacotes de SO, apenas para contêineres criados a partir de imagens.



O Pod permite compor tudo o que nosso aplicativo lógico precisa. Um aplicativo lógico é uma ferramenta para gerenciar vários aplicativos no mesmo perfil do sistema. Um sub é um pacote de recursos que inclui um ou mais contêineres e armazenamentos, um espaço para nome comum e um endereço IP por sub. Os cofres podem ser distribuídos entre contêineres.



Em geral, o design da lareira se assemelha a uma máquina virtual. Ele garante que o aplicativo inicie e pare como uma unidade atômica. O próximo slide mostra como é o controlador de replicação. Se eu enviar esta declaração para o servidor e disser: "Ei, eu quero que uma réplica do aplicativo" Foo "funcione!", O controlador a criará a partir do modelo e a enviará ao agendador, que colocará o aplicativo no Nó 1. Não especificamos em qual máquina ela deve funcionar, embora possamos fazê-lo. Agora aumente o número de réplicas para 3.



Que ações você espera do sistema se uma das máquinas falhar? Nesse caso, o controlador de replicação levará o estado atual do sistema ao estado desejado, movendo-o sob o contêiner da terceira máquina que não está funcionando para a segunda.



Você não precisa se aprofundar nesse processo e direcioná-lo - confiando o trabalho ao controlador, pode ter certeza de que o aplicativo será assegurado adequadamente, monitorando constantemente as mudanças no estado atual da infraestrutura e tomando decisões que garantam que o sistema esteja funcionando.

Essas coisas estão à frente do tempo delas - você apenas diz ao sistema: “Quero que essas três máquinas funcionem!”, E é aí que o seu controle termina. Essa abordagem é muito diferente de scripts e automação pura, quando você realmente precisa gerenciar o que está acontecendo agora para influenciar a decisão futura. Você não pode codificar tudo isso sem a capacidade de receber informações de entrada para responder adequadamente à situação. A abordagem descrita acima fornece essa oportunidade.
Como você imagina a configuração - o conceito de arquivos de configuração para serviços? Muitas pessoas ficam caladas sobre esse problema quando se trata de contêineres, mas ainda precisamos de configuração, ele não desaparece em lugar nenhum!

O Kubernetes também usa o conceito Secrets, que é usado para armazenar e transferir dados criptografados entre gerentes e nós do Nods.

Nunca executamos o Puppet em um contêiner porque não há razão para fazer isso. Você pode usar o Puppet para gerar um arquivo de configuração, mas ainda deseja armazená-lo no Kubernetis, pois permite distribuí-lo usando o tempo de execução. Vamos ver como fica.



Neste exemplo, criamos um segredo a partir de um arquivo e o salvamos no servidor da API Kubernetes. Você pode imaginar que substituiu esta parte por algo como Puppet, que usa o modelo eRB e dados ocultos para preencher o conteúdo do segredo - não importa quem o faça, mas você pode fazê-lo de qualquer maneira.

Quando o segredo está no lugar, ele pode servir como um link para criar uma implantação que diz: "Quero usar esse segredo!" Nesse caso, o Kubernetes faz o seguinte.



Ele cria um pod, pega os dados em segredo, os coloca em um sistema de arquivos temporário e os apresenta como um contêiner, assim como o Puppet cria uma cópia em uma máquina. Isso segue o ciclo de vida do aplicativo e, quando o aplicativo morre, a configuração desaparece com ele. Se você precisar de 10.000 instâncias de aplicativos, precisará criar e injetar em menos de 10.000 sistemas de arquivos temporários.

Serviços permite executar todos esses elementos em um cluster e sincronizá-los com outro ponto de extremidade. De fato, um serviço é um grupo de lareiras que funcionam como uma única lareira. Ele contém um endereço IP e uma porta permanentes, fornece integração ao DNS, usa balanceamento de carga e é atualizado quando o firmware é alterado.



Agora, vejamos a colaboração dos componentes conceituais do Kubernetes. Temos peças e configurações de Lego que precisam interagir entre si. Se você deseja executar um banco de dados em um cluster, pode realmente fazê-lo no Kubernetes. Muitos dizem que você não poderá executar aplicativos com estado em contêineres, mas isso está completamente errado.

Se você pensar em como os hipervisores funcionam, poderá entender que eles fazem quase a mesma coisa que você: crie uma máquina virtual, o planejador a move para o hipervisor e anexa o armazenamento. Às vezes, você trabalha com armazenamento local proveniente do hipervisor e não há motivos para que os contêineres não possam fazer o mesmo.

No entanto, o problema com os contêineres é que a maioria das pessoas não está acostumada a ter uma lista explícita de caminhos de arquivos que eles devem fornecer ao aplicativo. A maioria das pessoas não poderá informar exatamente os dispositivos e arquivos que o data warehouse precisa. Eles empacotam tudo em contêineres e, como resultado, nada de bom vem disso. Portanto, não acredite que os contêineres não sejam capazes de executar aplicativos de economia de estado - você pode muito bem fazer isso.



No slide, você vê um exemplo de Ruby-on-Rails e, antes de podermos usar nosso aplicativo, precisamos migrar o banco de dados. Vamos à demonstração ao vivo do programa. Para realizar a implantação, eu uso MY_SQL e você vê muitos dados na tela.



Estou mostrando tudo isso porque, como administrador do sistema, você precisa entender muitas coisas. Nesta implantação, refino alguns dos metadados do meu aplicativo, mas a principal coisa que destacarei em cinza: quero iniciar 1 cópia do aplicativo mysql e usar o contêiner mysql versão 5.6.32.



Observe que aqui eu seleciono algum segredo do Kubernetes como links, que neste caso vou injetar como variáveis ​​de ambiente. Mais tarde, mostrarei outro caso quando os inserirmos no sistema de arquivos. Portanto, não preciso “guardar” segredos em minha configuração. A próxima linha importante é o bloco de recursos.



Você não pode jogar Tetris até saber o tamanho dos blocos. Muitas pessoas começam a implantar sem usar limites de recursos para esse processo. Como resultado, a RAM está completamente entupida e você "empilha" o servidor inteiro.

22:09 min

Para continuar em breve ...

Um pouco de publicidade :)

Obrigado por ficar com a gente. Você gosta dos nossos artigos? Deseja ver materiais mais interessantes? Ajude-nos fazendo um pedido ou recomendando aos seus amigos o VPS baseado em nuvem para desenvolvedores a partir de US $ 4,99 , um analógico exclusivo de servidores básicos que foi inventado por nós para você: Toda a verdade sobre o VPS (KVM) E5-2697 v3 (6 núcleos) 10 GB DDR4 480 GB SSD 1 Gbps de US $ 19 ou como dividir o servidor? (as opções estão disponíveis com RAID1 e RAID10, até 24 núcleos e até 40GB DDR4).

Dell R730xd 2 vezes mais barato no data center Equinix Tier IV em Amsterdã? Somente nós temos 2 TVs Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV a partir de US $ 199 na Holanda!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - a partir de US $ 99! Leia sobre Como criar um prédio de infraestrutura. classe c usando servidores Dell R730xd E5-2650 v4 que custam 9.000 euros por um centavo?