Kubernetes - controlando a nuvem

Quando você deseja usar o Linux para fornecer serviços a uma empresa, esses serviços precisam ser seguros, resilientes e escaláveis. Belas palavras, mas o que queremos dizer com elas?

'Seguro' significa que os usuários podem acessar os dados de que necessitam, seja acesso somente leitura ou acesso de gravação. Ao mesmo tempo, nenhum dado é exposto a nenhuma parte que não esteja autorizada a vê-lo. A segurança engana: você pode pensar que tem tudo protegido para descobrir mais tarde que há falhas. Projetar em segurança desde o início de um projeto é muito mais fácil do que tentar adaptá-lo mais tarde.

‘Resiliente’ significa que seus serviços toleram falhas na infraestrutura. Uma falha pode ser um controlador de disco do servidor que não pode mais acessar nenhum disco, tornando os dados inacessíveis. Ou a falha pode ser um switch de rede que não permite mais a comunicação de dois ou mais sistemas. Nesse contexto, um “ponto único de falha” ou SPOF é uma falha que afeta adversamente a disponibilidade do serviço. Uma infraestrutura resiliente é aquela sem SPOFs.

‘Escalável’ descreve a capacidade dos sistemas de lidar com picos de demanda com elegância. Também determina a facilidade com que as alterações podem ser feitas nos sistemas. Por exemplo, adicionar um novo usuário, aumentar a capacidade de armazenamento ou mover uma infraestrutura da Amazon Web Services para o Google Cloud - ou até mesmo movê-la internamente.

Assim que sua infraestrutura se expande para além de um servidor, existem muitas opções para aumentar a segurança, resiliência e escalabilidade. Veremos como esses problemas foram resolvidos tradicionalmente e quais novas tecnologias estão disponíveis para mudar a cara da computação de grandes aplicativos.

Obtenha mais Linux!

Está gostando do que está lendo? Quer mais Linux e código aberto? Podemos entregar, literalmente! Assine o Linux Format hoje a um preço de banana. Você pode obter edições impressas, edições digitais ou por que não ambos? Nós entregamos na sua porta em todo o mundo por uma taxa anual simples. Portanto, torne sua vida melhor e mais fácil, inscreva-se agora!

Para entender o que é possível hoje, é útil observar como os projetos de tecnologia têm sido tradicionalmente implementados. Antigamente - isto é, há mais de 10 anos - as empresas compravam ou alugavam hardware para executar todos os componentes de seus aplicativos. Mesmo aplicativos relativamente simples, como um site WordPress, têm vários componentes. No caso do WordPress, um banco de dados MySQL é necessário junto com um servidor web, como o Apache, e uma forma de lidar com o código PHP. Então, eles deveriam construir um servidor, configurar Apache, PHP e MySQL, instalar o WordPress e pronto.

Em geral, isso funcionou. Funcionou bem o suficiente para que ainda haja um grande número de servidores configurados exatamente dessa forma hoje. Mas não era perfeito, e dois dos maiores problemas eram resiliência e escalabilidade.

A falta de resiliência significava que qualquer problema significativo no servidor resultaria em perda de serviço. Claramente, uma falha catastrófica significaria a ausência do site, mas também não havia espaço para realizar a manutenção programada sem afetar o site. Mesmo a instalação e ativação de uma atualização de segurança de rotina para o Apache exigiria alguns segundos de interrupção do site.

O problema de resiliência foi amplamente resolvido com a construção de "clusters de alta disponibilidade". O princípio era ter dois servidores executando o site, configurados de forma que a falha de qualquer um deles não resultasse no inatividade do site. O serviço fornecido era resiliente, mesmo que os servidores individuais não o fossem.

Nuvens abstratas

Parte do poder do Kubernetes é a abstração que ele oferece. Do ponto de vista do desenvolvedor, eles desenvolvem o aplicativo para ser executado em um contêiner Docker. O Docker não se importa se está sendo executado no Windows, Linux ou algum outro sistema operacional. Esse mesmo contêiner do Docker pode ser obtido do MacBook do desenvolvedor e executado no Kubernetes sem nenhuma modificação.

A própria instalação do Kubernetes pode ser uma única máquina. Claro, muitos dos benefícios do Kubernetes não estarão disponíveis: não haverá escalonamento automático; há um único ponto óbvio de falha e assim por diante. Como uma prova de conceito em um ambiente de teste, porém, funciona.

Quando estiver pronto para a produção, você pode executar internamente ou em um provedor de nuvem, como AWS ou Google Cloud. Os provedores de nuvem têm alguns serviços integrados que auxiliam na execução do Kubernetes, mas nenhum deles são requisitos rígidos. Se você deseja alternar entre o Google, Amazon e sua própria infraestrutura, configure o Kubernetes e siga em frente. Nenhum de seus aplicativos precisa ser alterado de forma alguma.

E onde está o Linux? O Kubernetes é executado no Linux, mas o sistema operacional é invisível para os aplicativos. Este é um passo significativo na maturidade e usabilidade das infraestruturas de TI.

O efeito Slashdot

O problema de escalabilidade é um pouco mais complicado. Digamos que seu site WordPress receba 1.000 visitantes por mês. Um dia, sua empresa é mencionada na Rádio 4 ou na TV do café da manhã. De repente, você recebe mais de um mês de visitantes em 20 minutos. Todos nós já ouvimos histórias de sites que "travaram" e, normalmente, é por isso: falta de escalabilidade.

Os dois servidores que ajudaram na resiliência conseguiram gerenciar uma carga de trabalho maior do que um servidor sozinho, mas isso ainda é limitado. Você pagaria por dois servidores 100 por cento do tempo e na maioria das vezes ambos estavam funcionando perfeitamente. É provável que um só possa administrar seu site. Em seguida, John Humphrys menciona sua empresa no Today e você precisaria de 10 servidores para lidar com a carga - mas apenas por algumas horas.

A melhor solução para o problema de resiliência e escalabilidade era a computação em nuvem. Configure uma ou duas instâncias de servidor - os pequenos servidores que executam seus aplicativos - no Amazon Web Services (AWS) ou no Google Cloud e, se uma das instâncias falhar por algum motivo, ela será reiniciada automaticamente. Configure o escalonamento automático corretamente e quando o Sr. Humphrys fizer com que a carga de trabalho em suas instâncias do servidor da web aumente rapidamente, instâncias de servidor adicionais são iniciadas automaticamente para compartilhar a carga de trabalho. Mais tarde, conforme os juros diminuem, essas instâncias adicionais são interrompidas e você paga apenas pelo que usar. Perfeito … ou é?

Embora a solução em nuvem seja muito mais flexível do que o servidor autônomo tradicional, ainda existem problemas. Atualizar todas as instâncias de nuvem em execução não é simples. O desenvolvimento para a nuvem também tem desafios: o laptop que seus desenvolvedores estão usando pode ser semelhante à instância da nuvem, mas não é o mesmo. Se você se comprometer com a AWS, migrar para o Google Cloud é uma tarefa complexa. E suponha que, por qualquer motivo, você simplesmente não queira entregar sua computação à Amazon, Google ou Microsoft?

Os contêineres surgiram como um meio de agrupar aplicativos com todas as suas dependências em um único pacote que pode ser executado em qualquer lugar. Os contêineres, como o Docker, podem ser executados nos laptops dos desenvolvedores da mesma forma que são executados nas instâncias de nuvem, mas gerenciar uma frota de contêineres se torna cada vez mais desafiador conforme o número de contêineres aumenta.

A resposta é orquestração de contêineres. Esta é uma mudança significativa de foco. Antes, garantíamos que tínhamos servidores suficientes, sejam físicos ou virtuais, para garantir que poderíamos atender à carga de trabalho. Usar o escalonamento automático dos provedores de nuvem ajudou, mas ainda estávamos lidando com instâncias. Tivemos que configurar balanceadores de carga, firewalls, armazenamento de dados e muito mais manualmente. Com a orquestração de contêineres, tudo isso (e muito mais) é cuidado. Especificamos os resultados de que necessitamos e nossas ferramentas de orquestração de contêineres atendem aos nossos requisitos. Especificamos o que queremos que seja feito, em vez de como queremos que seja feito.

A integração e implantação contínuas podem funcionar bem com o Kubernetes. Esta é uma visão geral do Jenkins sendo usado para construir e implantar um aplicativo Java

Torne-se um Kubernete

Kubernetes (ku-ber-net-eez) é a principal ferramenta de orquestração de contêineres hoje, e veio do Google. Se alguém sabe como operar infraestruturas de TI em grande escala, é o Google. A origem do Kubernetes é o Borg, um projeto interno do Google que ainda é usado para executar a maioria dos aplicativos do Google, incluindo seu mecanismo de pesquisa, Gmail, Google Maps e muito mais. Borg era um segredo até que o Google publicou um artigo sobre isso em 2015, mas o artigo deixou bem claro que o Borg foi a principal inspiração por trás do Kubernetes.

Borg é um sistema que gerencia os recursos computacionais nos data centers do Google e mantém os aplicativos do Google, tanto em produção quanto em outros lugares, em execução, apesar de falha de hardware, esgotamento de recursos ou outros problemas que poderiam ter causado uma interrupção. Ele faz isso monitorando cuidadosamente os milhares de nós que constituem uma “célula” Borg e os contêineres em execução neles, e inicia ou interrompe os contêineres conforme necessário em resposta a problemas ou flutuações na carga.

O próprio Kubernetes nasceu da iniciativa GIFEE ("Infraestrutura do Google para todos os outros") do Google e foi projetado para ser uma versão mais amigável do Borg que poderia ser útil fora do Google. Foi doado à Linux Foundation em 2015 por meio da formação da Cloud Native Computing Foundation (CNCF).

O Kubernetes fornece um sistema por meio do qual você "declara" seus aplicativos e serviços em contêineres e garante que seus aplicativos sejam executados de acordo com essas declarações. Se seus programas exigem recursos externos, como armazenamento ou balanceadores de carga, o Kubernetes pode provisioná-los automaticamente. Ele pode aumentar ou diminuir seus aplicativos para acompanhar as mudanças na carga e pode até mesmo dimensionar todo o cluster quando necessário. Os componentes do seu programa nem precisam saber onde estão sendo executados: o Kubernetes fornece serviços de nomenclatura internos para aplicativos para que eles possam se conectar a “wp_mysql” e se conectar automaticamente ao recurso correto. '

O resultado final é uma plataforma que pode ser usada para executar seus aplicativos em qualquer infraestrutura, desde uma única máquina por meio de um rack de sistemas no local até frotas de máquinas virtuais baseadas em nuvem em execução em qualquer provedor de nuvem importante, todos usando os mesmos contêineres e configuração. O Kubernetes é independente do provedor: execute-o onde quiser.

O Kubernetes é uma ferramenta poderosa e necessariamente complexa. Antes de entrarmos em uma visão geral, precisamos apresentar alguns termos usados no Kubernetes. Os contêineres executam aplicativos únicos, conforme discutido acima, e são agrupados em pods. Um pod é um grupo de contêineres intimamente vinculados que são implantados juntos no mesmo host e compartilham alguns recursos. Os contêineres em um pod funcionam como uma equipe: eles realizarão funções relacionadas, como um contêiner de aplicativo e um contêiner de registro com configurações específicas para o aplicativo.

Uma visão geral do Kubernetes mostrando o mestre executando os principais componentes e dois nós. Observe que, na prática, os componentes principais podem ser divididos em vários sistemas

Quatro componentes principais do Kubernetes são o API Server, o Scheduler, o Controller Manager e um banco de dados de configuração distribuído chamado etcd. O servidor de API está no centro do Kubernetes e atua como o endpoint primário para todas as solicitações de gerenciamento. Eles podem ser gerados por uma variedade de fontes, incluindo outros componentes do Kubernetes, como o programador, administradores via linha de comando ou painéis baseados na web e os próprios aplicativos em contêiner. Ele valida solicitações e atualiza dados armazenados no etcd.

O Scheduler determina em quais nós os vários pods serão executados, levando em consideração as restrições, como requisitos de recursos, quaisquer restrições de hardware ou software, carga de trabalho, prazos e muito mais.

O Controller Manager monitora o estado do cluster e tentará iniciar ou parar os pods conforme necessário, por meio do API Server, para trazer o cluster ao estado desejado. Ele também gerencia algumas conexões internas e recursos de segurança.

Cada nó executa um processo Kubelet, que se comunica com o servidor API e gerencia contêineres - geralmente usando Docker - e Kube-Proxy, que lida com proxy de rede e balanceamento de carga dentro do cluster.

O sistema de banco de dados distribuído etcd deriva seu nome do / etc pasta em sistemas Linux, que é usada para conter informações de configuração do sistema, além do sufixo 'd', frequentemente usado para denotar um processo daemon. Os objetivos do etcd são armazenar dados de valor-chave de maneira distribuída, consistente e tolerante a falhas.

O servidor API mantém todos os seus dados de estado no etcd e pode executar várias instâncias simultaneamente. O planejador e o gerenciador de controlador podem ter apenas uma instância ativa, mas usa um sistema de lease para determinar qual instância em execução é a mestre. Tudo isso significa que o Kubernetes pode ser executado como um sistema altamente disponível, sem pontos únicos de falha.

Juntando tudo

Então, como usamos esses componentes na prática? A seguir, um exemplo de configuração de um site WordPress usando Kubernetes. Se você quisesse fazer isso de verdade, provavelmente usaria uma receita predefinida chamada gráfico de leme. Eles estão disponíveis para vários aplicativos comuns, mas aqui veremos algumas das etapas necessárias para colocar um site WordPress em funcionamento no Kubernetes.

A primeira tarefa é definir uma senha para o MySQL:

 kubectl criar segredo mysql-pass genérico --from-literal = senha = YOUR_PASSWORD

kubectl falará com o servidor da API, que validará o comando e armazenará a senha no etcd. Nossos serviços são definidos em arquivos YAML e agora precisamos de algum armazenamento persistente para o banco de dados MySQL.

 apiVersion: v1 kind: PersistentVolumeClaim metadata: name: mysql-pv-Claim labels: app: wordpress spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi

A especificação deve ser autoexplicativa. Os campos de nome e rótulos são usados para se referir a esse armazenamento de outras partes do Kubernetes, neste caso, nosso contêiner WordPress.

Depois de definir o armazenamento, podemos definir uma instância do MySQL, apontando-o para o armazenamento predefinido. Isso é seguido pela definição do próprio banco de dados. Damos a esse banco de dados um nome e um rótulo para fácil referência no Kubernetes.

Agora precisamos de outro contêiner para executar o WordPress. Parte da especificação de implantação do contêiner é:

 kind: Metadados de implantação: nome: wordpress rótulos: app: wordpress spec: estratégia: tipo: recriar

O tipo de estratégia “Recriar” significa que, se qualquer parte do código que compõe o aplicativo for alterado, as instâncias em execução serão excluídas e recriadas. Outras opções incluem a capacidade de reiniciar e remover as instâncias existentes, uma por uma, permitindo que o serviço continue em execução durante a implantação de uma atualização. Por fim, declaramos um serviço para o próprio WordPress, compreendendo o código PHP e o Apache. Parte do arquivo YAML que declara isso é:

 metadados: nome: wordpress labels: app: wordpress spec: ports: - port: 80 selector: app: wordpress tier: frontend type: LoadBalancer

Observe a última linha, definindo o tipo de serviço como LoadBalancer. Isso instrui o Kubernetes a disponibilizar o serviço fora do Kubernetes. Sem essa linha, isso seria apenas um serviço interno "apenas do Kubernetes". E é isso. O Kubernetes agora usará esses arquivos YAML como uma declaração do que é necessário e configurará pods, conexões, armazenamento e assim por diante, conforme necessário para colocar o cluster no estado "desejado".

Use a visualização do painel para obter um resumo rápido do Kubernetes em ação

Esta foi necessariamente apenas uma visão geral de alto nível do Kubernetes, e muitos detalhes e recursos do sistema foram omitidos. Analisamos o escalonamento automático (pods e nós que compõem um cluster), cron jobs (iniciando contêineres de acordo com uma programação), Ingress (balanceamento de carga HTTP, regravação e descarregamento SSL), RBAC (controles de acesso baseados em papéis) , políticas de rede (firewall) e muito mais. O Kubernetes é extremamente flexível e poderoso: para qualquer nova infraestrutura de TI, ele deve ser um candidato sério.

Recursos

Se você não está familiarizado com o Docker, comece aqui: https://docs.docker.com/get-started.

Há um tutorial interativo sobre como implantar e dimensionar um aplicativo aqui: https://kubernetes.io/docs/tutorials/kubernetes-basics.

E veja https://kubernetes.io/docs/setup/scratch para saber como construir um cluster.

Você pode brincar com um cluster Kubernetes gratuito em https://tryk8s.com.

Por fim, você pode ler um longo artigo técnico com uma excelente visão geral do uso do Borg pelo Google e como isso influenciou o design do Kubernetes aqui: https://storage.googleapis.com/pub-tools-public-publication-data/ pdf / 43438.pdf.

Descubra mais sobre Tiger Computing.