One place for hosting & domains

      Usando

      Usando uma CDN para Acelerar a Entrega de Conteúdo Estático


      Introdução

      Websites e aplicações modernas geralmente entregam uma quantidade significativa de conteúdo estático para os usuários finais. Este conteúdo inclui imagens, folhas de estilo, JavaScript, e vídeo. À medida que esses recursos estáticos aumentam em número e tamanho, o uso da largura de banda aumenta e o tempo de carregamento da página aumenta, deteriorando a experiência de navegação dos usuários e reduzindo a capacidade disponível dos servidores.

      Para reduzir drasticamente o tempo de carregamento de página, aumentar a performance e reduzir seus custos com largura de banda e infraestrutura, você pode implementar uma CDN, ou rede de entrega de conteúdo para armazenar em cache esses recursos em um conjunto de servidores distribuídos geograficamente.

      Neste tutorial, vamos fornecer uma visão geral de alto nível de CDNs e como elas funcionam, bem como os benefícios que elas podem trazer para suas aplicações web.

      O que é uma CDN?

      Content delivery network ou rede de entrega de conteúdo é um grupo de servidores geograficamente distribuídos otimizados para entregar conteúdo estático aos usuários finais. Esse conteúdo estático pode ser praticamente qualquer tipo de dados, mas as CDNs são mais comumente usadas para entregar páginas web e seus arquivos relacionados, streaming de vídeo e áudio e grandes pacotes de software.

      Uma CDN consiste em múltiplos pontos de presença (PoPs) em várias localidades, cada qual consistindo de vários servidores de borda que armazenam em cache recursos de sua origem, ou servidor de hospedagem. Quando um usuário visita seu website e solicita recursos estáticos como iamgens ou arquivos de JavaScript, suas solicitações são encaminhadas pela CDN para o servidor de borda mais próximo, a partir do qual o conteúdo é servido. Se o servidor de borda não tem os recursos em cache ou o cache de recursos expirou, a CDN irá buscar e armazenar em cache a versão mais recente de outro servidor de borda da CDN mais próximo ou de seus servidores de origem. Se a borda da CDN tiver uma entrada de cache para seus recursos (o que ocorre na maior parte do tempo se seu site receber uma quantidade moderada de tráfego), ela retornará a cópia em cache para o usuário final.

      Isso permite que usuários geograficamente dispersos minimizem o número de saltos necessários para receber o conteúdo estático, buscando o conteúdo diretamente do cache de uma borda próxima. O resultado é latência e perda de pacotes significativamente reduzidos, tempos de carregamento de página mais rápidos e uma carga drasticamente reduzida na sua infraestrutura de origem.

      Os provedores de CDN oferecem recursos adicionais como mitigação de DDoS e limitação de taxa, análise de usuários e otimizações para casos de uso móvel ou de streaming com custo adicional.

      Como uma CDN funciona?

      Quando um usuário visita seu website, ele primeiro recebe uma resposta de um servidor de DNS contendo o endereço IP do host do seu servidor web. Seu navegador então solicita o conteúdo da página web, que geralmente consite de uma variedade de arquivos estáticos, como páginas HTML, folhas de estilo CSS, código JavaScript e imagens.

      Uma vez lançada a CDN e descarregados esses recursos estáticos em sevidores da CDN, “empurrando-os” manualmente ou fazendo com que a CDN “puxe” os recursos automaticamente (ambos os mecanismos são cobertos na próxima seção), você então instrui seu webserver a reescrever os links para conteúdo estático, de modo que esses links agora apontem para arquivos hospedados pela CDN. Se você estiver usando um CMS como o WordPress, essa reescrita de link pode ser implementada usando um plugin de terceiros como o CDN Enabler.

      Muitas CDNs fornecem suporte para domínios personalizados, permitindo que você crie um registro CNAME em seu domínio apontando para um endpoint da CDN. Depois que a CDN recebe uma solicitação do usuário nesse endpoint (localizado na borda, muito mais perto do usuário do que seus servidores de back-end), ela então encaminha a solicitação para o Ponto de Presença (PoP) localizado mais próximo do usuário. Este PoP geralmente consiste de um ou mais servidores de borda da CDN colocados em um ponto de troca de Internet (IxP), essencialmente um datacenter que os Provedores de Serviço de Internet (ISPs) utilizam para interconectar suas redes. O balanceador de carga interno da CDN então encaminha a solicitação para um servidor de borda localizado neste PoP, que então serve o conteúdo para o usuário.

      Os mecanismos de cache variam entre os provedores de CDN, mas geralmente funcionam da seguinte maneira:

      1. Quando a CDN recebe uma primeira solicitação para um recurso estático, como uma imagem PNG, ele não tem o recurso em cache e deve buscar uma cópia do recurso de um servidor de borda de CDN próximo ou do próprio servidor de origem. Isso é conhecido como cache “miss” e geralmente pode ser detectado inspecionando o cabeçalho de resposta HTTP, contendo X-Cache: MISS. Essa solicitação inicial será mais lenta que as solicitações futuras porque, depois de concluir essa solicitação, o recurso terá sido armazenado em cache na borda.

      2. As solicitações futuras para esse recurso (“hits” do cache), encaminhadas para esse local de borda, agora serão atendidas a partir do cache, até a expiração (normalmente definida através de cabeçalhos HTTP). Essas respostas serão significativamente mais rápidas do que a solicitação inicial, reduzindo drasticamente as latências para os usuários e transferindo o tráfego web para a rede da CDN. Você pode verificar se a resposta foi atendida a partir de um cache CDN, inspecionando o cabeçalho de resposta HTTP, que agora deve conter X-Cache: HIT.

      Para saber mais sobre como uma CDN específica funciona e como foi implementada, consulte a documentação do seu provedor de CDN.

      Na próxima seção, vamos introduzir os dois tipos populares de CDNs: As CDNs push e pull

      Zonas Push versus Zonas Pull

      A maioria dos provedores de CDN oferecem duas maneiras de armazenar seus dados em cache: zonas pull e zonas push.

      Zonas Pull envolvem a entrada do endereço do seu servidor de origem, e deixar a CDN buscar e armazenar em cache automaticamente todos os recursos estáticos disponíveis em seu site. Zonas Pull são comumente usadas para fornecer recursos web de pequeno a médio porte frequentemente atualizados, como arquivos HTML, CSS e arquivos JavaScript. Depois de fornecer à CDN o endereço do servidor de origem, a próxima etapa é geralmente reconfigurar links para recursos estáticos, de forma que eles agora apontem para o URL fornecido pela CDN. A partir desse ponto, o CDN manipulará as solicitações de recursos de entrada dos usuários e fornecerá conteúdo de seus caches geograficamente distribuídos e sua origem, conforme apropriado.

      Para utilizar uma Zona Push, você faz o upload de seus dados para um bucket ou local de armazenamento designado, que a CDN então envia para caches em sua frota distribuída de servidores de borda. As zonas Push são normalmente usadas para arquivos maiores, atualizados com pouca frequência, como arquivamentos, pacotes de software, PDFs, vídeo e arquivos de áudio.

      Benefícios do Uso de uma CDN

      Quase qualquer site pode colher os benefícios fornecidos pela implementação de uma CDN, mas geralmente as principais razões para implementá-la são descarregar a largura de banda de seus servidores de origem nos servidores CDN e reduzir a latência para usuários distribuídos geograficamente.

      Vamos passar por estas e várias outras grandes vantagens oferecidas pelo uso de uma CDN logo abaixo.

      Descarregamento da Origem

      Se você estiver se aproximando da capacidade de largura de banda em seus servidores, o descarregamento de recursos estáticos como imagens, vídeos, arquivos CSS e JavaScript reduzirá drasticamente o uso da largura de banda dos servidores. Redes de entrega de conteúdo são projetadas e otimizadas para servir conteúdo estático, e as solicitações de clientes para esse conteúdo serão encaminhadas e servidas por servidores CDN de borda. Isso traz o benefício adicional de reduzir a carga em seus servidores de origem, pois eles servem esses dados com uma frequência muito menor.

      Latência Mais Baixa para uma Melhor Experiência do Usuário

      Se sua base de usuários estiver geograficamente dispersa e uma parte não trivial de seu tráfego vier de uma área geográfica distante, uma CDN poderá diminuir a latência ao colocar em cache os recursos estáticos em servidores de borda mais próximos dos seus usuários. Ao reduzir a distância entre os usuários e o conteúdo estático, você pode fornecer conteúdo para seus usuários com mais rapidez e melhorar a experiência aumentando as velocidades de carregamento de páginas.

      Esses benefícios são compostos para websites que atendem principalmente a conteúdo de vídeo com uso intensivo de largura de banda, em que altas latências e lentidão no tempo de carregamento afetam diretamente a experiência do usuário e o engajamento de conteúdo.

      Gerenciar Picos de Tráfego e Evitar Tempo de Inatividade

      As CDNs permitem lidar com grandes picos e rajadas de tráfego através do balanceamento da carga de solicitações em uma grande rede distribuída de servidores de borda. Ao descarregar e armazenar em cache o conteúdo estático em uma rede de entrega, você pode acomodar um número maior de usuários simultâneos com sua infraestrutura atual.

      Para sites que usam um único servidor de origem, esses grandes picos de tráfego podem sobrecarregar o sistema, causando interrupções e tempo de inatividade não planejados. A transferência do tráfego para uma infraestrutura de CDN altamente disponível e redundante, projetada para lidar com níveis variáveis de tráfego web, pode aumentar a disponibilidade de seus recursos e do seu conteúdo.

      Reduzir Custos

      Como a veiculação de conteúdo estático geralmente ocupa a maior parte do uso da largura de banda, o descarregamento desses recursos em uma rede de distribuição de conteúdo pode reduzir drasticamente os gastos mensais com infraestrutura. Além de reduzir os custos de largura de banda, uma CDN pode reduzir os custos de servidor através da redução da carga nos servidores de origem, permitindo escalar a infraestrutura existente. Por fim, alguns provedores de CDN oferecem faturamento mensal com preço fixo, permitindo que você transforme seu uso de largura de banda mensal variável em um gasto recorrente estável e previsível.

      Aumentar a Segurança

      Outro caso de uso comum para CDNs é a mitigação de ataques de DDoS. Muitos provedores de CDN incluem recursos para monitorar e filtrar solicitações para servidores de borda. Esses serviços analisam o tráfego web em busca de padrões suspeitos, bloqueando o tráfego de ataque mal-intencionado e, ao mesmo tempo, permitindo o tráfego de usuários confiáveis. Os provedores de CDN geralmente oferecem uma variedade de serviços de mitigação de DDoS, desde proteção contra ataques comuns no nível de infra-estrutura (camadas OSI 3 e 4), até serviços de mitigação mais avançados e limitação de taxa.

      Além disso, a maioria das CDNs permite configurar o SSL completo, para que você possa criptografar o tráfego entre a CDN e o usuário final, bem como o tráfego entre a CDN e seus servidores de origem, usando certificados SSL personalizados ou fornecidos pela própria CDN.

      Escolhendo a Melhor Solução

      Se o seu gargalo for a carga da CPU no servidor de origem e não a largura de banda, uma CDN pode não ser a solução mais apropriada. Nesse caso, o cache local usando caches populares, como NGINX ou Varnish, pode reduzir significativamente a carga servindo os recursos a partir da memória do sistema.

      Antes de lançar uma CDN, etapas adicionais de otimização — como minimizar e compactar arquivos JavaScript e CSS e ativar a compactação de solicitação HTTP do servidor Web — podem também ter um impacto significativo em tempos de carregamento de páginas e uso de largura de banda.

      Uma ferramenta útil para avaliar a velocidade de carregamento de página e melhorá-la é o PageSpeed Insights do Google. Outra ferramenta útil que fornece um detalhamento em cascata de solicitações e tempos de resposta, bem como otimizações sugeridas é o Pingdom.

      Conclusão

      Uma rede de entrega de conteúdo pode ser uma solução rápida e eficaz para melhorar a escalabilidade e disponibilidade de seus websites. Ao armazenar em cache os recursos estáticos em uma rede geograficamente distribuída de servidores otimizados, você pode reduzir muito os tempos de carregamento de página e as latências para os usuários finais. Além disso, as CDNs permitem que você reduza significativamente o uso de largura de banda, absorvendo as solicitações dos usuários e respondendo a partir do cache na borda, reduzindo assim seus custos de largura de banda e infra-estrutura.

      Com plugins e suporte de terceiros para os principais frameworks como WordPress, Drupal, Django e Ruby on Rails, além de recursos adicionais como mitigação de DDoS, SSL completo, monitoramento de usuários e compactação de recursos, as CDNs podem ser uma ferramenta de impacto para proteger e otimizar websites de alto tráfego.

      Por Hanif Jetha



      Source link

      Como Criar um Cluster Kubernetes 1.11 Usando Kubeadm no Ubuntu 18.04


      O autor escolheu o Free and Open Source Fund para receber uma doação como parte do programa Write for DOnations.

      Introdução

      O Kubernetes é um sistema de orquestração de container em escala. Inicialmente desenvolvido pelo Google baseado em suas experiências executando containers em produção. O Kubernetes é open source e desenvolvido ativamente por uma comunidade em todo o mundo.

      O Kubeadm atomatiza a instalação e a configuração de componentes do Kubernetes tais como o servidor de API, o Controller Manager, e o Kube DNS. Contudo, ele não cria usuários ou lida com a instalação de dependências no nível do sistema operacional e sua configuração. Para essa tarefas preliminares, é possível utilizar uma ferramenta de gerência de configuração como o Ansible ou o SaltStack. A utilização dessas ferramentas torna a criação de clusters adicionais ou a recriação de clusters existentes muito mais simples e menos propensa a erros.

      Neste guia, você vai configurar um cluster Kubernetes a partir do zero utilizando o Ansible e o Kubeadm, e a seguir fazer o deploy de uma aplicação Nginx containerizada nele.

      Objetivos

      Seu cluster irá incluir os seguintes recursos físicos:

      O node master (um node no Kubernetes refere-se a um servidor) é responsável por gerenciar o estado do cluster. Ele roda o Etcd, que armazena dados de cluster entre componentes que fazem o scheduling de cargas de trabalho para nodes worker ou nodes de trabalho.

      Nodes worker são os servidores onde suas cargas de trabalho (i.e. aplicações e serviços containerizados) irão executar. Um worker continuará a executar sua carga de trabalho uma vez que estejam atribuídos a ela, mesmo se o master for desativado quando o scheduling estiver concluído. A capacidade de um cluster pode ser aumentada adicionando workers.

      Após a conclusão desse guia, você terá um cluster pronto para executar aplicações containerizadas, desde que os servidores no cluster tenham recursos suficientes de CPU e RAM para suas aplicações consumirem. Quase todas as aplicações Unix tradicionais, incluindo aplicações web, bancos de dados, daemons, e ferramentas de linha de comando podem ser containerizadas e feitas para rodar no cluster. O cluster em si consumirá cerca de 300-500MB de memória e 10% de CPU em cada node.

      Uma vez que o cluster esteja configurado, você fará o deploy do servidor web Nginx nele para assegurar que ele está executando as cargas de trabalho corretamente.

      Pré-requisitos

      Passo 1 — Configurando o Diretório da Área de Trabalho e o Arquivo de Inventário Ansible

      Nessa seção, você vai criar um diretório em sua máquina local que irá servir como sua área de trabalho. Você configurará o Ansible localmente para que ele possa se comunicar e executar comandos em seus servidores remotos. Depois disso pronto, você irá criar um arquivo hosts contendo informações de inventário tais como os endereços IP de seus servidores e os grupos aos quais cada servidor pertence.

      Dos seus três servidores, um será o master com um IP exibido como master_ip. Os outros dois servidores serão workers e terão os IPs worker_1_ip e worker_2_ip.

      Crie um diretório chamado ~/kube-cluster no diretório home de sua máquina local e faça um cd para dentro dele:

      • mkdir ~/kube-cluster
      • cd ~/kube-cluster

      Esse diretório será sua área de trabalho para o restante desse tutorial e conterá todos os seus playbooks de Ansible. Ele também será o diretório no qual você irá executar todos os comandos locais.

      Crie um arquivo chamado ~/kube-cluster/hosts usando o nano ou o seu editor de textos favorito:

      • nano ~/kube-cluster/hosts

      Adicione o seguinte texto ao arquivo, que irá especificar informações sobre a estrutura lógica do cluster:

      ~/kube-cluster/hosts

      
      [masters]
      master ansible_host=master_ip ansible_user=root
      
      [workers]
      worker1 ansible_host=worker_1_ip ansible_user=root
      worker2 ansible_host=worker_2_ip ansible_user=root
      
      [all:vars]
      ansible_python_interpreter=/usr/bin/python3
      

      Você deve se lembrar de que arquivos de inventário no Ansible são utilizados para especificar informações de servidor tais como endereços IP, usuários remotos, e agrupamentos de servidores para tratar como uma unidade única para a execução de comandos. O ~/kube-cluster/hosts será o seu arquivo de inventário e você adicionou dois grupos Ansible a ele (masters e workers) especificando a estrutura lógica do seu cluster.

      No grupo masters, existe uma entrada de servidor chamada “master” que lista o IP do node master (master_ip) e especifica que o Ansible deve executar comandos remotos como root.

      De maneira similar, no grupo workers, existem duas entradas para os servidores workers (worker_1_ip e worker_2_ip) que também especificam o ansible_user como root.

      A última linha do arquivo diz ao Ansible para utilizar os intepretadores Python dos servidores remotos para suas operações de gerenciamento.

      Salve e feche o arquivo depois de ter adicionado o texto.

      Tendo configurado o inventário do servidor com grupos, vamos passar a instalar dependências no nível do sistema operacional e a criar definições de configuração.

      Passo 2 — Criando um Usuário Não-Root em Todos os Servidores Remotos

      Nesta seção você irá criar um usuário não-root com privilégios sudo em todos os servidores para que você possa fazer SSH manualmente neles como um usuário sem privilégios. Isso pode ser útil se, por exemplo, você gostaria de ver informações do sistema com comandos como top/htop, ver a lista de containers em execução, ou alterar arquivos de configuração de propriedade do root. Estas operações são rotineiramente executadas durante a manutenção de um cluster, e a utilização de um usuário que não seja root para tarefas desse tipo minimiza o risco de modificação ou exclusão de arquivos importantes ou a realização não intencional de operações perigosas.

      Crie um arquivo chamado ~/kube-cluster/initial.yml na área de trabalho:

      • nano ~/kube-cluster/initial.yml

      A seguir, adicione o seguinte play ao arquivo para criar um usuário não-root com privilégios sudo em todos os servidores. Um play no Ansible é uma coleção de passos a serem realizados que visam servidores e grupos específicos. O seguinte play irá criar um usuário sudo não-root:

      ~/kube-cluster/initial.yml

      
      - hosts: all
        become: yes
        tasks:
          - name: create the 'ubuntu' user
            user: name=ubuntu append=yes state=present createhome=yes shell=/bin/bash
      
          - name: allow 'ubuntu' to have passwordless sudo
            lineinfile:
              dest: /etc/sudoers
              line: 'ubuntu ALL=(ALL) NOPASSWD: ALL'
              validate: 'visudo -cf %s'
      
          - name: set up authorized keys for the ubuntu user
            authorized_key: user=ubuntu key="{{item}}"
            with_file:
              - ~/.ssh/id_rsa.pub
      

      Aqui está um detalhamento do que este playbook faz:

      • Cria um usuário não-root ubuntu.

      • Configura o arquivo sudoers para permitir o usuário ubuntu executar comandos sudo sem uma solicitação de senha.

      • Adiciona a chave pública em sua máquina local (normalmente ~/.ssh/id_rsa.pub) para a lista de chaves autorizadas do usuário remoto ubuntu. Isto o permitirá fazer SSH para dentro de cada servidor como usuário ubuntu.

      Salve e feche o arquivo depois que tiver adicionado o texto.

      Em seguida, rode o playbook localmente executando:

      • ansible-playbook -i hosts ~/kube-cluster/initial.yml

      O comando será concluído dentro de dois a cinco minutos. Na conclusão, você verá uma saída semelhante à seguinte:

      Output

      PLAY [all] **** TASK [Gathering Facts] **** ok: [master] ok: [worker1] ok: [worker2] TASK [create the 'ubuntu' user] **** changed: [master] changed: [worker1] changed: [worker2] TASK [allow 'ubuntu' user to have passwordless sudo] **** changed: [master] changed: [worker1] changed: [worker2] TASK [set up authorized keys for the ubuntu user] **** changed: [worker1] => (item=ssh-rsa AAAAB3...) changed: [worker2] => (item=ssh-rsa AAAAB3...) changed: [master] => (item=ssh-rsa AAAAB3...) PLAY RECAP **** master : ok=5 changed=4 unreachable=0 failed=0 worker1 : ok=5 changed=4 unreachable=0 failed=0 worker2 : ok=5 changed=4 unreachable=0 failed=0

      Agora que a configuração preliminar está completa, você pode passar para a instalação de dependências específicas do Kubernetes.

      Step 3 — Instalando as Dependências do Kubernetes

      Nesta seção, você irá instalar os pacotes no nível do sistema operacional necessários pelo Kubernetes com o gerenciador de pacotes do Ubuntu. Esses pacotes são:

      • Docker – um runtime de container. Este é o componente que executa seus containers. Suporte a outros runtimes como o rkt está em desenvolvimento ativo no Kubernetes.

      • kubeadm – uma ferramenta CLI que irá instalar e configurar os vários componentes de um cluster de uma maneira padrão.

      • kubelet – um serviço/programa de sistema que roda em todos os nodes e lida com operações no nível do node.

      • kubectl – uma ferramenta CLI usada para emitir comandos para o cluster através de seu servidor de API.

      Crie um arquivo chamado ~/kube-cluster/kube-dependencies.yml na área de trabalho:

      • nano ~/kube-cluster/kube-dependencies.yml

      Adicione os seguintes plays ao arquivo para instalar esses pacotes em seus servidores:

      ~/kube-cluster/kube-dependencies.yml

      
      - hosts: all
        become: yes
        tasks:
         - name: install Docker
           apt:
             name: docker.io
             state: present
             update_cache: true
      
         - name: install APT Transport HTTPS
           apt:
             name: apt-transport-https
             state: present
      
         - name: add Kubernetes apt-key
           apt_key:
             url: https://packages.cloud.google.com/apt/doc/apt-key.gpg
             state: present
      
         - name: add Kubernetes' APT repository
           apt_repository:
            repo: deb http://apt.kubernetes.io/ kubernetes-xenial main
            state: present
            filename: 'kubernetes'
      
         - name: install kubelet
           apt:
             name: kubelet
             state: present
             update_cache: true
      
         - name: install kubeadm
           apt:
             name: kubeadm
             state: present
      
      - hosts: master
        become: yes
        tasks:
         - name: install kubectl
           apt:
             name: kubectl
             state: present
      

      O primeiro play no playbook faz o seguinte:

      • Instala o Docker, o runtime de container.

      • Instala o apt-transport-https, permitindo que você adicione fontes HTTPS externas à sua lista de fontes do APT.

      • Adiciona a apt-key do repositório APT do Kubernetes para verificação de chave.

      • Adiciona o repositório APT do Kubernetes à lista de fontes do APT dos seus servidores remotos.

      • Instala kubelet e kubeadm.

      O segundo play consiste de uma única tarefa que instala o kubectl no seu node master.

      Salve e feche o arquivo quando você tiver terminado.

      A seguir, rode o playbook executando localmente:

      • ansible-playbook -i hosts ~/kube-cluster/kube-dependencies.yml

      Na conclusão, você verá uma saída semelhante à seguinte:

      Output

      PLAY [all] **** TASK [Gathering Facts] **** ok: [worker1] ok: [worker2] ok: [master] TASK [install Docker] **** changed: [master] changed: [worker1] changed: [worker2] TASK [install APT Transport HTTPS] ***** ok: [master] ok: [worker1] changed: [worker2] TASK [add Kubernetes apt-key] ***** changed: [master] changed: [worker1] changed: [worker2] TASK [add Kubernetes' APT repository] ***** changed: [master] changed: [worker1] changed: [worker2] TASK [install kubelet] ***** changed: [master] changed: [worker1] changed: [worker2] TASK [install kubeadm] ***** changed: [master] changed: [worker1] changed: [worker2] PLAY [master] ***** TASK [Gathering Facts] ***** ok: [master] TASK [install kubectl] ****** ok: [master] PLAY RECAP **** master : ok=9 changed=5 unreachable=0 failed=0 worker1 : ok=7 changed=5 unreachable=0 failed=0 worker2 : ok=7 changed=5 unreachable=0 failed=0

      Após a execução, o Docker, o kubeadm e o kubelet estarão instalados em todos os seus servidores remotos. O kubectl não é um componente obrigatório e somente é necessário para a execução de comandos de cluster. A instalação dele somente no node master faz sentido nesse contexto, uma vez que você irá executar comandos kubectl somente a partir do master. Contudo, observe que os comandos kubectl podem ser executados a partir de quaisquer nodes worker ou a partir de qualquer máquina onde ele possa ser instalado e configurado para apontar para um cluster.

      Todas as dependências de sistema agora estão instaladas. Vamos configurar o node master e inicializar o cluster.

      Passo 4 — Configurando o Node Master

      Nesta seção, você irá configurar o node master. Antes da criação de quaisquer playbooks, contudo, vale a pena cobrir alguns conceitos como Pods e Plugins de Rede do Pod, uma vez que seu cluster incluirá ambos.

      Um pod é uma unidade atômica que executa um ou mais containers. Esses containers compartilham recursos tais como volumes de arquivo e interfaces de rede em comum. Os pods são a unidade básica de scheduling no Kubernetes: todos os containers em um pod têm a garantia de serem executados no mesmo node no qual foi feito o scheduling do pod.

      Cada pod tem seu próprio endereço IP, e um pod em um node deve ser capaz de acessar um pod em outro node utilizando o IP do pod. Os containers em um único node podem se comunicar facilmente através de uma interface local. Contudo, a comunicação entre pods é mais complicada e requer um componente de rede separado que possa encaminhar o tráfego de maneira transparente de um pod em um node para um pod em outro node.

      Essa funcionalidade é fornecida pelos plugins de rede para pods. Para este cluster vamos utilizar o Flannel, uma opção estável e de bom desempenho.

      Crie um playbook Ansible chamado master.yml em sua máquina local:

      • nano ~/kube-cluster/master.yml

      Adicione o seguinte play ao arquivo para inicializar o cluster e instalar o Flannel:

      ~/kube-cluster/master.yml

      
      - hosts: master
        become: yes
        tasks:
          - name: initialize the cluster
            shell: kubeadm init --pod-network-cidr=10.244.0.0/16 >> cluster_initialized.txt
            args:
              chdir: $HOME
              creates: cluster_initialized.txt
      
          - name: create .kube directory
            become: yes
            become_user: ubuntu
            file:
              path: $HOME/.kube
              state: directory
              mode: 0755
      
          - name: copy admin.conf to user's kube config
            copy:
              src: /etc/kubernetes/admin.conf
              dest: /home/ubuntu/.kube/config
              remote_src: yes
              owner: ubuntu
      
          - name: install Pod network
            become: yes
            become_user: ubuntu
            shell: kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/v0.9.1/Documentation/kube-flannel.yml >> pod_network_setup.txt
            args:
              chdir: $HOME
              creates: pod_network_setup.txt
      

      Aqui está um detalhamento deste play:

      • A primeira tarefa inicializa o cluster executando kubeadm init. A passagem do argumento --pod-network-cidr=10.244.0.0/16 especifica a sub-rede privada que os IPs do pod serão atribuídos. O Flannel utiliza a sub-rede acima por padrão; estamos dizendo ao kubeadm para utilizar a mesma sub-rede.

      • A segunda tarefa cria um diretório .kube em /home/ubuntu. Este diretório irá manter as informações de configuração tais como os arquivos de chaves do admin, que são requeridas para conectar no cluster, e o endereço da API do cluster.

      • A terceira tarefa copia o arquivo /etc/kubernetes/admin.conf que foi gerado a partir do kubeadm init para o diretório home do seu usuário não-root. Isso irá permitir que você utilize o kubectl para acessar o cluster recém-criado.

      • A última tarefa executa kubectl apply para instalar o Flannel. kubectl apply -f descriptor.[yml|json] é a sintaxe para dizer ao kubectl para criar os objetos descritos no arquivo descriptor.[yml|json]. O arquivo kube-flannel.yml contém as descrições dos objetos requeridos para a configuração do Flannel no cluster.

      Salve e feche o arquivo quando você tiver terminado.

      Rode o playbook localmente executando:

      • ansible-playbook -i hosts ~/kube-cluster/master.yml

      Na conclusão, você verá uma saída semelhante à seguinte:

      Output

      PLAY [master] **** TASK [Gathering Facts] **** ok: [master] TASK [initialize the cluster] **** changed: [master] TASK [create .kube directory] **** changed: [master] TASK [copy admin.conf to user's kube config] ***** changed: [master] TASK [install Pod network] ***** changed: [master] PLAY RECAP **** master : ok=5 changed=4 unreachable=0 failed=0

      Para verificar o status do node master, faça SSH nele com o seguinte comando:

      Uma vez dentro do node master, execute:

      Agora você verá a seguinte saída:

      Output

      NAME STATUS ROLES AGE VERSION master Ready master 1d v1.11.1

      A saída informa que o node master concluiu todas as tarefas de inicialização e está em um estado Ready do qual pode começar a aceitar nodes worker e executar tarefas enviadas ao Servidor de API. Agora você pode adicionar os workers a partir de sua máquina local.

      Passo 5 — Configurando os Nodes Worker

      A adição de workers ao cluster envolve a execução de um único comando em cada um. Este comando inclui as informações necessárias sobre o cluster, tais como o endereço IP e a porta do Servidor de API do master, e um token seguro. Somentes os nodes que passam no token seguro estarão aptos a ingressar no cluster.

      Navegue de volta para a sua área de trabalho e crie um playbook chamado workers.yml:

      • nano ~/kube-cluster/workers.yml

      Adicione o seguinte texto ao arquivo para adicionar os workers ao cluster:

      ~/kube-cluster/workers.yml

      
      - hosts: master
        become: yes
        gather_facts: false
        tasks:
          - name: get join command
            shell: kubeadm token create --print-join-command
            register: join_command_raw
      
          - name: set join command
            set_fact:
              join_command: "{{ join_command_raw.stdout_lines[0] }}"
      
      
      - hosts: workers
        become: yes
        tasks:
          - name: join cluster
            shell: "{{ hostvars['master'].join_command }} >> node_joined.txt"
            args:
              chdir: $HOME
              creates: node_joined.txt
      

      Aqui está o que o playbook faz:

      • O primeiro play obtém o comando de junção que precisa ser executado nos nodes workers. Este comando estará no seguinte formato: kubeadm join --token <token> <master-ip>:<master-port> --discovery-token-ca-cert-hash sha256:<hash>. Assim que obtiver o comando real com os valores apropriados de token e hash, a tarefa define isso como um fact para que o próximo play possa acessar essa informação.

      • O segundo play tem uma única tarefa que executa o comando de junção em todos os nodes worker. Na conclusão desta tarefa, os dois nodes worker farão parte do cluster.

      Salve e feche o arquivo quando você tiver terminado.

      Rode o playbook localmente executando:

      • ansible-playbook -i hosts ~/kube-cluster/workers.yml

      Na conclusão, você verá uma saída semelhante à seguinte:

      Output

      PLAY [master] **** TASK [get join command] **** changed: [master] TASK [set join command] ***** ok: [master] PLAY [workers] ***** TASK [Gathering Facts] ***** ok: [worker1] ok: [worker2] TASK [join cluster] ***** changed: [worker1] changed: [worker2] PLAY RECAP ***** master : ok=2 changed=1 unreachable=0 failed=0 worker1 : ok=2 changed=1 unreachable=0 failed=0 worker2 : ok=2 changed=1 unreachable=0 failed=0

      Com a adição dos nodes worker, seu cluster está agora totalmente configurado e funcional, com os workers prontos para executar cargas de trabalho. Antes de fazer o scheduling de aplicações, vamos verificar se o cluster está funcionando conforme o esperado.

      Step 6 — Verificando o Cluster

      Às vezes, um cluster pode falhar durante a configuração porque um node está inativo ou a conectividade de rede entre o master e o worker não está funcionando corretamente. Vamos verificar o cluster e garantir que os nodes estejam operando corretamente.

      Você precisará verificar o estado atual do cluster a partir do node master para garantir que os nodes estejam prontos. Se você se desconectou do node master, pode voltar e fazer SSH com o seguinte comando:

      Em seguida, execute o seguinte comando para obter o status do cluster:

      Você verá uma saída semelhante à seguinte:

      Output

      NAME STATUS ROLES AGE VERSION master Ready master 1d v1.11.1 worker1 Ready <none> 1d v1.11.1 worker2 Ready <none> 1d v1.11.1

      Se todos os seus nodes têm o valor Ready para o STATUS, significa que eles são parte do cluster e estão prontos para executar cargas de trabalho.

      Se, contudo, alguns dos nodes têm NotReady como o STATUS, isso pode significar que os nodes worker ainda não concluíram sua configuração. Aguarde cerca de cinco a dez minutos antes de voltar a executar kubectl get nodes e fazer a inspeção da nova saída. Se alguns nodes ainda têm NotReady como status, talvez seja necessário verificar e executar novamente os comandos nas etapas anteriores.

      Agora que seu cluster foi verificado com sucesso, vamos fazer o scheduling de um exemplo de aplicativo Nginx no cluster.

      Step 7 — Executando Uma Aplicação no Cluster

      Você pode fazer o deploy de qualquer aplicação containerizada no seu cluster. Para manter as coisas familiares, vamos fazer o deploy do Nginx utilizando Deployments e Services para ver como pode ser feito o deploy dessa aplicação no cluster. Você também pode usar os comandos abaixo para outros aplicativos em container, desde que você altere o nome da imagem do Docker e quaisquer flags relevantes (tais como ports e volumes).

      Ainda no node master, execute o seguinte comando para criar um deployment chamado nginx:

      • kubectl run nginx --image=nginx --port 80

      Um deployment é um tipo de objeto do Kubernetes que garante que há sempre um número especificado de pods em execução com base em um modelo definido, mesmo se o pod falhar durante o tempo de vida do cluster. O deployment acima irá criar um pod com um container do registro do Docker Nginx Docker Image.

      A seguir, execute o seguinte comando para criar um serviço chamado nginx que irá expor o app publicamente. Ele fará isso por meio de um NodePort, um esquema que tornará o pod acessível através de uma porta arbitrária aberta em cada node do cluster:

      • kubectl expose deploy nginx --port 80 --target-port 80 --type NodePort

      Services são outro tipo de objeto do Kubernetes que expõe serviços do cluster para os clientes, tanto internos quanto externos. Eles também são capazes de fazer balanceamento de solicitações para vários pods e são um componente integral no Kubernetes, interagindo frequentemente com outros componentes.

      Execute o seguinte comando:

      Isso produzirá uma saída semelhante à seguinte:

      Output

      NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 1d nginx NodePort 10.109.228.209 <none> 80:nginx_port/TCP 40m

      A partir da terceira linha da saída acima, você pode obter a porta em que o Nginx está sendo executado. O Kubernetes atribuirá uma porta aleatória maior que 30000 automaticamente, enquanto garante que a porta já não esteja vinculada a outro serviço.

      Para testar se tudo está funcionando, visite http://worker_1_ip:nginx_port ou http://worker_2_ip:nginx_port através de um navegador na sua máquina local. Você verá a familiar página de boas-vindas do Nginx.

      Se você quiser remover o aplicativo Nginx, primeiro exclua o serviço nginx do node master:

      • kubectl delete service nginx

      Execute o seguinte para garantir que o serviço tenha sido excluído:

      Você verá a seguinte saída:

      [secondary label Output]
      NAME         TYPE        CLUSTER-IP       EXTERNAL-IP           PORT(S)        AGE
      kubernetes   ClusterIP   10.96.0.1        <none>                443/TCP        1d
      

      Para excluir o deployment:

      • kubectl delete deployment nginx

      Execute o seguinte para confirmar que isso funcionou:

      Output

      No resources found.

      Conclusão

      Neste guia, você configurou com sucesso um cluster do Kubernetes no Ubuntu 18.04 usando Kubeadm e Ansible para automação.

      Se você está se perguntando o que fazer com o cluster, agora que ele está configurado, um bom próximo passo seria sentir-se confortável para implantar suas próprias aplicações e serviços no cluster. Aqui está uma lista de links com mais informações que podem orientá-lo no processo:

      • Dockerizing applications - lista exemplos que detalham como containerizar aplicações usando o Docker.

      • Pod Overview - descreve em detalhes como os Pods funcionam e seu relacionamento com outros objetos do Kubernetes. Os pods são onipresentes no Kubernetes, então compreendê-los facilitará seu trabalho.

      • Deployments Overview - fornece uma visão geral dos deployments. É útil entender como os controladores, como os deployments, funcionam, pois eles são usados com frequência em aplicações stateless para escalonamento e na recuperação automatizada de aplicações não íntegras.

      • Services Overview - cobre os serviços ou services, outro objeto frequentemente usado em clusters do Kubernetes. Entender os tipos de serviços e as opções que eles têm é essencial para executar aplicações stateless e stateful.

      Outros conceitos importantes que você pode analisar são Volumes, Ingresses e Secrets, os quais são úteis ao realizar o deploy de aplicações em produção.

      O Kubernetes tem muitas funcionalidades e recursos a oferecer. A Documentação Oficial do Kubernetes é o melhor lugar para aprender sobre conceitos, encontrar guias específicos de tarefas e procurar referências de API para vários objetos.

      Por bsder



      Source link

      Como Criar um Cluster Kubernetes 1.10 Usando Kubeadm no CentOS 7


      O autor escolheu o Free and Open Source Fund para receber uma doação como parte do programa Write for DOnations.

      Introdução

      O Kubernetes é um sistema de orquestração de container em escala. Inicialmente desenvolvido pelo Google baseado em suas experiências executando containers em produção. O Kubernetes é open source e desenvolvido ativamente por uma comunidade em todo o mundo.

      O Kubeadm atomatiza a instalação e a configuração de componentes do Kubernetes tais como o servidor de API, o Controller Manager, e o Kube DNS. Contudo, ele não cria usuários ou lida com a instalação de dependências no nível do sistema operacional e sua configuração. Para essa tarefas preliminares, é possível utilizar uma ferramenta de gerência de configuração como o Ansible ou o SaltStack. A utilização dessas ferramentas torna a criação de clusters adicionais ou a recriação de clusters existentes muito mais simples e menos propensa a erros.

      Neste guia, você vai configurar um cluster Kubernetes a partir do zero utilizando o Ansible e o Kubeadm, e a seguir fazer o deploy de uma aplicação Nginx containerizada nele.

      Objetivos

      Seu cluster irá incluir os seguintes recursos físicos:

      O node master (um node no Kubernetes refere-se a um servidor) é responsável por gerenciar o estado do cluster. Ele roda o Etcd, que armazena dados de cluster entre componentes que fazem o scheduling de cargas de trabalho para nodes de trabalho.

      Nodes worker são os servidores onde suas cargas de trabalho (i.e. aplicações e serviços containerizados) irão executar. Um worker continuará a executar sua carga de trabalho uma vez que estejam atribuídos a ela, mesmo se o master for desativado quando o scheduling estiver concluído. A capacidade de um cluster pode ser aumentada adicionando workers.

      Após a conclusão desse guia, você terá um cluster pronto para executar aplicações containerizadas, desde que os servidores no cluster tenham recursos suficientes de CPU e RAM para suas aplicações consumirem. Quase todas as aplicações Unix tradicionais, incluindo aplicações web, bancos de dados, daemons, e ferramentas de linha de comando podem ser containerizadas e feitas para rodar no cluster. O cluster em si consumirá cerca de 300-500MB de memória e 10% de CPU em cada node.

      Uma vez que o cluster esteja configurado, você fará o deploy do servidor web Nginx nele para assegurar que ele está executando as cargas de trabalho corretamente.

      Pré-requisitos

      Passo 1 — Configurando o Diretório da Área de Trabalho e o Arquivo de Inventário Ansible

      Nessa seção, você vai criar um diretório em sua máquina local que irá servir como sua área de trabalho. Você configurará o Ansible localmente para que ele possa se comunicar e executar comandos em seus servidores remotos. Depois disso pronto, você irá criar um arquivo hosts contendo informações de inventário tais como os endereços IP de seus servidores e os grupos aos quais cada servidor pertence.

      Dos seus três servidores, um será o master com um IP exibido como master_ip. Os outros dois servidores serão workers e terão os IPs worker_1_ip e worker_2_ip.

      Crie um diretório chamado ~/kube-cluster no diretório home de sua máquina local e faça um cd para dentro dele:

      • mkdir ~/kube-cluster
      • cd ~/kube-cluster

      Esse diretório será sua área de trabalho para o restante desse tutorial e conterá todos os seus playbooks de Ansible. Ele também será o diretório no qual você irá executar todos os comandos locais.

      Crie um arquivo chamado ~/kube-cluster/hosts usando o vi ou o seu editor de textos favorito:

      Pressione i para inserir o seguinte texto ao arquivo, que irá especificar informações sobre a estrutura lógica do cluster:

      ~/kube-cluster/hosts

      
      [masters]
      master ansible_host=master_ip ansible_user=root
      
      [workers]
      worker1 ansible_host=worker_1_ip ansible_user=root
      worker2 ansible_host=worker_2_ip ansible_user=root
      

      Quando tiver terminado, pressione ESC seguido de :wq para gravar as alterações no arquvo e sair.

      Você deve se lembrar de que arquivos de inventário no Ansible são utilizados para especificar informações de servidor tais como endereços IP, usuários remotos, e agrupamentos de servidores para tratar como uma unidade única para a execução de comandos. O ~/kube-cluster/hosts será o seu arquivo de inventário e você adicionou dois grupos Ansible a ele (masters e workers) especificando a estrutura lógica do seu cluster.

      No grupo masters, existe uma entrada de servidor chamada "master" que lista o IP do node master (master_ip) e especifica que o Ansible deve executar comandos remotos como root.

      De maneira similar, no grupo workers, existem duas entradas para os servidores workers (worker_1_ip e worker_2_ip) que também especificam o ansible_user como root.

      Tendo configurado o inventário do servidor com grupos, vamos passar a instalar dependências no nível do sistema operacional e a criar definições de configuração.

      Passo 2 — Criando um Usuário Não-Root em Todos os Servidores Remotos

      Nesta seção você irá criar um usuário não-root com privilégios sudo em todos os servidores para que você possa fazer SSH manualmente neles como um usuário sem privilégios. Isso pode ser útil se, por exemplo, você gostaria de ver informações do sistema com comandos como top/htop, ver a lista de containers em execução, ou alterar arquivos de configuração de propriedade do root. Estas operações são rotineiramente executadas durante a manutenção de um cluster, e a utilização de um usuário que não seja root para tarefas desse tipo minimiza o risco de modificação ou exclusão de arquivos importantes ou a realização não intencional de operações perigosas.

      Crie um arquivo chamado ~/kube-cluster/initial.yml na área de trabalho:

      • vi ~/kube-cluster/initial.yml

      A seguir, adicione o seguinte play ao arquivo para criar um usuário não-root com privilégios sudo em todos os servidores. Um play no Ansible é uma coleção de passos a serem realizados que visam servidores e grupos específicos. O seguinte play irá criar um usuário sudo não-root:

      ~/kube-cluster/initial.yml

      
      - hosts: all
        become: yes
        tasks:
          - name: create the 'centos' user
            user: name=centos append=yes state=present createhome=yes shell=/bin/bash
      
          - name: allow 'centos' to have passwordless sudo
            lineinfile:
              dest: /etc/sudoers
              line: 'centos ALL=(ALL) NOPASSWD: ALL'
              validate: 'visudo -cf %s'
      
          - name: set up authorized keys for the centos user
            authorized_key: user=centos key="{{item}}"
            with_file:
              - ~/.ssh/id_rsa.pub
      

      Aqui está um detalhamento do que este playbook faz:

      • Cria um usuário não-root centos.

      • Configura o arquivo sudoers para permitir o usuário centos executar comandos sudo sem uma solicitação de senha.

      • Adiciona a chave pública em sua máquina local (normalmente ~/.ssh/id_rsa.pub) para a lista de chaves autorizadas do usuário remoto centos. Isto o permitirá fazer SSH para dentro de cada servidor como usuário centos.

      Salve e feche o arquivo depois que tiver adicionado o texto.

      Em seguida, rode o playbook localmente executando:

      • ansible-playbook -i hosts ~/kube-cluster/initial.yml

      O comando será concluído dentro de dois a cinco minutos. Na conclusão, você verá uma saída semelhante à seguinte:

      Output

      PLAY [all] **** TASK [Gathering Facts] **** ok: [master] ok: [worker1] ok: [worker2] TASK [create the 'centos' user] **** changed: [master] changed: [worker1] changed: [worker2] TASK [allow 'centos' user to have passwordless sudo] **** changed: [master] changed: [worker1] changed: [worker2] TASK [set up authorized keys for the centos user] **** changed: [worker1] => (item=ssh-rsa AAAAB3...) changed: [worker2] => (item=ssh-rsa AAAAB3...) changed: [master] => (item=ssh-rsa AAAAB3...) PLAY RECAP **** master : ok=5 changed=4 unreachable=0 failed=0 worker1 : ok=5 changed=4 unreachable=0 failed=0 worker2 : ok=5 changed=4 unreachable=0 failed=0

      Agora que a configuração preliminar está completa, você pode passar para a instalação de dependências específicas do Kubernetes.

      Passo 3 — Instalando as Dependências do Kubernetes

      Nesta seção, você irá instalar os pacotes no nível do sistema operacional necessários pelo Kubernetes com o gerenciador de pacotes yum do CentOS. Esses pacotes são:

      • Docker - um runtime de container. Este é o componente que executa seus containers. Suporte a outros runtimes como o rkt está em desenvolvimento ativo no Kubernetes.

      • kubeadm - uma ferramenta CLI que irá instalar e configurar os vários componentes de um cluster de uma maneira padrão.

      • kubelet - um serviço/programa de sistema que roda em todos os nodes e lida com operações no nível do node.

      • kubectl - uma ferramenta CLI usada para emitir comandos para o cluster através de seu servidor de API.

      Crie um arquivo chamado ~/kube-cluster/kube-dependencies.yml na área de trabalho:

      • vi ~/kube-cluster/kube-dependencies.yml

      Adicione os seguintes plays ao arquivo para instalar esses pacotes em seus servidores:

      ~/kube-cluster/kube-dependencies.yml

      
      - hosts: all
        become: yes
        tasks:
         - name: install Docker
           yum:
             name: docker
             state: present
             update_cache: true
      
         - name: start Docker
           service:
             name: docker
             state: started
      
         - name: disable SELinux
           command: setenforce 0
      
         - name: disable SELinux on reboot
           selinux:
             state: disabled
      
         - name: ensure net.bridge.bridge-nf-call-ip6tables is set to 1
           sysctl:
            name: net.bridge.bridge-nf-call-ip6tables
            value: 1
            state: present
      
         - name: ensure net.bridge.bridge-nf-call-iptables is set to 1
           sysctl:
            name: net.bridge.bridge-nf-call-iptables
            value: 1
            state: present
      
         - name: add Kubernetes' YUM repository
           yum_repository:
            name: Kubernetes
            description: Kubernetes YUM repository
            baseurl: https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
            gpgkey: https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
            gpgcheck: yes
      
         - name: install kubelet
           yum:
              name: kubelet
              state: present
              update_cache: true
      
         - name: install kubeadm
           yum:
              name: kubeadm
              state: present
      
         - name: start kubelet
           service:
             name: kubelet
             enabled: yes
             state: started
      
      - hosts: master
        become: yes
        tasks:
         - name: install kubectl
           yum:
              name: kubectl
              state: present
      

      O primeiro play no playbook faz o seguinte:

      • Instala o Docker, o runtime de container.

      • Inicia o serviço do Docker.

      • Desativa o SELinux, uma vez que ele ainda não é totalmente suportado pelo Kubernetes.

      • Define alguns valores sysctl relacionados ao netfilter, necessários para o trabalho em rede. Isso permitirá que o Kubernetes defina regras de iptables para receber tráfego de rede IPv4 e IPv6 em bridge nos nodes.

      • Adiciona o repositório YUM do Kubernetes às listas de repositórios de seus servidores remotos.

      • Instala kubelet e kubeadm.

      O segundo play consiste de uma única tarefa que instala o kubectl no seu node master.

      Salve e feche o arquivo quando você tiver terminado.

      A seguir, execute o playbook:

      • ansible-playbook -i hosts ~/kube-cluster/kube-dependencies.yml

      Na conclusão, você verá uma saída semelhante à seguinte:

      Output

      PLAY [all] **** TASK [Gathering Facts] **** ok: [worker1] ok: [worker2] ok: [master] TASK [install Docker] **** changed: [master] changed: [worker1] changed: [worker2] TASK [disable SELinux] **** changed: [master] changed: [worker1] changed: [worker2] TASK [disable SELinux on reboot] **** changed: [master] changed: [worker1] changed: [worker2] TASK [ensure net.bridge.bridge-nf-call-ip6tables is set to 1] **** changed: [master] changed: [worker1] changed: [worker2] TASK [ensure net.bridge.bridge-nf-call-iptables is set to 1] **** changed: [master] changed: [worker1] changed: [worker2] TASK [start Docker] **** changed: [master] changed: [worker1] changed: [worker2] TASK [add Kubernetes' YUM repository] ***** changed: [master] changed: [worker1] changed: [worker2] TASK [install kubelet] ***** changed: [master] changed: [worker1] changed: [worker2] TASK [install kubeadm] ***** changed: [master] changed: [worker1] changed: [worker2] TASK [start kubelet] **** changed: [master] changed: [worker1] changed: [worker2] PLAY [master] ***** TASK [Gathering Facts] ***** ok: [master] TASK [install kubectl] ****** ok: [master] PLAY RECAP **** master : ok=9 changed=5 unreachable=0 failed=0 worker1 : ok=7 changed=5 unreachable=0 failed=0 worker2 : ok=7 changed=5 unreachable=0 failed=0

      Após a execução, o Docker, o kubeadm e o kubelet estarão instalados em todos os seus servidores remotos. O kubectl não é um componente obrigatório e somente é necessário para a execução de comandos de cluster. A instalação dele somente no node master faz sentido nesse contexto, uma vez que você irá executar comandos kubectl somente a partir do master. Contudo, observe que os comandos kubectl podem ser executados a partir de quaisquer nodes worker ou a partir de qualquer máquina onde ele possa ser instalado e configurado para apontar para um cluster.

      Todas as dependências de sistema agora estão instaladas. Vamos configurar o node master e inicializar o cluster.

      Passo 4 — Configurando o Node Master

      Nesta seção, você irá configurar o node master. Antes da criação de quaisquer playbooks, contudo, vale a pena cobrir alguns conceitos como Pods e Plugins de Rede do Pod, uma vez que seu cluster incluirá ambos.

      Um pod é uma unidade atômica que executa um ou mais containers. Esses containers compartilham recursos tais como volumes de arquivo e interfaces de rede em comum. Os pods são a unidade básica de scheduling no Kubernetes: todos os containers em um pod têm a garantia de serem executados no mesmo node no qual foi feito o scheduling do pod.

      Cada pod tem seu próprio endereço IP, e um pod em um node deve ser capaz de acessar um pod em outro node utilizando o IP do pod. Os containers em um único node podem se comunicar facilmente através de uma interface local. Contudo, a comunicação entre pods é mais complicada e requer um componente de rede separado que possa encaminhar o tráfego de maneira transparente de um pod em um node para um pod em outro node.

      Essa funcionalidade é fornecida pelos plugins de rede para pods. Para este cluster vamos utilizar o Flannel, uma opção estável e de bom desempenho.

      Crie um playbook Ansible chamado master.yml em sua máquina local:

      • vi ~/kube-cluster/master.yml

      Adicione o seguinte play ao arquivo para inicializar o cluster e instalar o Flannel:

      ~/kube-cluster/master.yml

      
      - hosts: master
        become: yes
        tasks:
          - name: initialize the cluster
            shell: kubeadm init --pod-network-cidr=10.244.0.0/16 >> cluster_initialized.txt
            args:
              chdir: $HOME
              creates: cluster_initialized.txt
      
          - name: create .kube directory
            become: yes
            become_user: centos
            file:
              path: $HOME/.kube
              state: directory
              mode: 0755
      
          - name: copy admin.conf to user's kube config
            copy:
              src: /etc/kubernetes/admin.conf
              dest: /home/centos/.kube/config
              remote_src: yes
              owner: centos
      
          - name: install Pod network
            become: yes
            become_user: centos
            shell: kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/v0.9.1/Documentation/kube-flannel.yml >> pod_network_setup.txt
            args:
              chdir: $HOME
              creates: pod_network_setup.txt
      

      Aqui está um detalhamento deste play:

      • A primeira tarefa inicializa o cluster executando kubeadm init. A passagem do argumento --pod-network-cidr=10.244.0.0/16 especifica a sub-rede privada que os IPs do pod serão atribuídos. O Flannel utiliza a sub-rede acima por padrão; estamos dizendo ao kubeadm para utilizar a mesma sub-rede.

      • A segunda tarefa cria um diretório .kube em /home/centos. Este diretório irá manter as informações de configuração tais como os arquivos de chaves do admin, que são requeridas para conectar no cluster, e o endereço da API do cluster.

      • A terceira tarefa copia o arquivo /etc/kubernetes/admin.conf que foi gerado a partir do kubeadm init para o diretório home do seu usuário não-root centos. Isso irá permitir que você utilize o kubectl para acessar o cluster recém-criado.

      • A última tarefa executa kubectl apply para instalar o Flannel. kubectl apply -f descriptor.[yml|json] é a sintaxe para dizer ao kubectl para criar os objetos descritos no arquivo descriptor.[yml|json]. O arquivo kube-flannel.yml contém as descrições dos objetos requeridos para a configuração do Flannel no cluster.

      Salve e feche o arquivo quando você tiver terminado.

      Execute o playbook:

      • ansible-playbook -i hosts ~/kube-cluster/master.yml

      Na conclusão, você verá uma saída semelhante à seguinte:

      Output

      PLAY [master] **** TASK [Gathering Facts] **** ok: [master] TASK [initialize the cluster] **** changed: [master] TASK [create .kube directory] **** changed: [master] TASK [copy admin.conf to user's kube config] ***** changed: [master] TASK [install Pod network] ***** changed: [master] PLAY RECAP **** master : ok=5 changed=4 unreachable=0 failed=0

      Para verificar o status do node master, faça SSH nele com o seguinte comando:

      Uma vez dentro do node master, execute:

      Agora você verá a seguinte saída:

      Output

      NAME STATUS ROLES AGE VERSION master Ready master 1d v1.10.1

      A saída informa que o node master concluiu todas as tarefas de inicialização e está em um estado Ready do qual pode começar a aceitar nodes worker e executar tarefas enviadas ao Servidor de API. Agora você pode adicionar os workers a partir de sua máquina local.

      Passo 5 — Configurando os Nodes Worker

      A adição de workers ao cluster envolve a execução de um único comando em cada um. Este comando inclui as informações necessárias sobre o cluster, tais como o endereço IP e a porta do Servidor de API do master, e um token seguro. Somentes os nodes que passam no token seguro estarão aptos a ingressar no cluster.

      Navegue de volta para a sua área de trabalho e crie um playbook chamado workers.yml:

      • vi ~/kube-cluster/workers.yml

      Adicione o seguinte texto ao arquivo para adicionar os workers ao cluster:

      ~/kube-cluster/workers.yml

      
      - hosts: master
        become: yes
        gather_facts: false
        tasks:
          - name: get join command
            shell: kubeadm token create --print-join-command
            register: join_command_raw
      
          - name: set join command
            set_fact:
              join_command: "{{ join_command_raw.stdout_lines[0] }}"
      
      
      - hosts: workers
        become: yes
        tasks:
          - name: join cluster
            shell: "{{ hostvars['master'].join_command }} >> node_joined.txt"
            args:
              chdir: $HOME
              creates: node_joined.txt
      

      Aqui está o que o playbook faz:

      • O primeiro play obtém o comando de junção que precisa ser executado nos nodes workers. Este comando estará no seguinte formato: kubeadm join --token <token> <master-ip>:<master-port> --discovery-token-ca-cert-hash sha256:<hash>. Assim que obtiver o comando real com os valores apropriados de token e hash, a tarefa define isso como um fact para que o próximo play possa acessar essa informação.

      • O segundo play tem uma única tarefa que executa o comando de junção em todos os nodes worker. Na conclusão desta tarefa, os dois nodes worker farão parte do cluster.

      Salve e feche o arquivo quando você tiver terminado.

      Execute o playbook:

      • ansible-playbook -i hosts ~/kube-cluster/workers.yml

      Na conclusão, você verá uma saída semelhante à seguinte:

      Output

      PLAY [master] **** TASK [get join command] **** changed: [master] TASK [set join command] ***** ok: [master] PLAY [workers] ***** TASK [Gathering Facts] ***** ok: [worker1] ok: [worker2] TASK [join cluster] ***** changed: [worker1] changed: [worker2] PLAY RECAP ***** master : ok=2 changed=1 unreachable=0 failed=0 worker1 : ok=2 changed=1 unreachable=0 failed=0 worker2 : ok=2 changed=1 unreachable=0 failed=0

      Com a adição dos nodes worker, seu cluster está agora totalmente configurado e funcional, com os workers prontos para executar cargas de trabalho. Antes de fazer o scheduling de aplicações, vamos verificar se o cluster está funcionando conforme o esperado.

      Step 6 — Verificando o Cluster

      Às vezes, um cluster pode falhar durante a configuração porque um node está inativo ou a conectividade de rede entre o master e o worker não está funcionando corretamente. Vamos verificar o cluster e garantir que os nodes estejam operando corretamente.

      Você precisará verificar o estado atual do cluster a partir do node master para garantir que os nodes estejam prontos. Se você se desconectou do node master, pode voltar e fazer SSH com o seguinte comando:

      Em seguida, execute o seguinte comando para obter o status do cluster:

      Você verá uma saída semelhante à seguinte:

      Output

      NAME STATUS ROLES AGE VERSION master Ready master 1d v1.10.1 worker1 Ready <none> 1d v1.10.1 worker2 Ready <none> 1d v1.10.1

      Se todos os seus nodes têm o valor Ready para o STATUS, significa que eles são parte do cluster e estão prontos para executar cargas de trabalho.

      Se, contudo, alguns dos nodes têm NotReady como o STATUS, isso pode significar que os nodes worker ainda não concluíram sua configuração. Aguarde cerca de cinco a dez minutos antes de voltar a executar kubectl get nodes e fazer a inspeção da nova saída. Se alguns nodes ainda têm NotReady como status, talvez seja necessário verificar e executar novamente os comandos nas etapas anteriores.

      Agora que seu cluster foi verificado com sucesso, vamos fazer o scheduling de um exemplo de aplicativo Nginx no cluster.

      Passo 7 — Executando Uma Aplicação no Cluster

      Você pode fazer o deploy de qualquer aplicação containerizada no seu cluster. Para manter as coisas familiares, vamos fazer o deploy do Nginx utilizando Deployments e Services para ver como pode ser feito o deploy dessa aplicação no cluster. Você também pode usar os comandos abaixo para outros aplicativos em container, desde que você altere o nome da imagem do Docker e quaisquer flags relevantes (tais como ports e volumes).

      Ainda no node master, execute o seguinte comando para criar um deployment chamado nginx:

      • kubectl run nginx --image=nginx --port 80

      Um deployment é um tipo de objeto do Kubernetes que garante que há sempre um número especificado de pods em execução com base em um modelo definido, mesmo se o pod falhar durante o tempo de vida do cluster. O deployment acima irá criar um pod com um container do registro do Docker Nginx Docker Image.

      A seguir, execute o seguinte comando para criar um serviço chamado nginx que irá expor o app publicamente. Ele fará isso por meio de um NodePort, um esquema que tornará o pod acessível através de uma porta arbitrária aberta em cada node do cluster:

      • kubectl expose deploy nginx --port 80 --target-port 80<^> --type NodePort

      Services são outro tipo de objeto do Kubernetes que expõe serviços internos do cluster para os clientes, tanto internos quanto externos. Eles também são capazes de fazer balanceamento de solicitações para vários pods e são um componente integral no Kubernetes, interagindo frequentemente com outros componentes.

      Execute o seguinte comando:

      Isso produzirá uma saída semelhante à seguinte:

      Output

      NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 1d nginx NodePort 10.109.228.209 <none> 80:nginx_port/TCP 40m

      A partir da terceira linha da saída acima, você pode obter a porta em que o Nginx está sendo executado. O Kubernetes atribuirá uma porta aleatória maior que 30000 automaticamente, enquanto garante que a porta já não esteja vinculada a outro serviço.

      Para testar se tudo está funcionando, visite http://worker_1_ip:nginx_port ou http://worker_2_ip:nginx_port através de um navegador na sua máquina local. Você verá a familiar página de boas-vindas do Nginx.

      Se você quiser remover o aplicativo Nginx, primeiro exclua o serviço nginx do node master:

      • kubectl delete service nginx

      Execute o seguinte para garantir que o serviço tenha sido excluído:

      Você verá a seguinte saída:

      Output

      NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 1d

      Para excluir o deployment:

      kubectl delete deployment nginx
      

      Execute o seguinte para confirmar que isso funcionou:

      Output

      No resources found.

      Conclusão

      Neste guia, você configurou com sucesso um cluster do Kubernetes no CentOS 7 usando Kubeadm e Ansible para automação.

      Se você está se perguntando o que fazer com o cluster, agora que ele está configurado, um bom próximo passo seria sentir-se confortável para implantar suas próprias aplicações e serviços no cluster. Aqui está uma lista de links com mais informações que podem orientá-lo no processo:

      • Dockerizing applications - lista exemplos que detalham como containerizar aplicações usando o Docker.

      • Pod Overview - descreve em detalhes como os Pods funcionam e seu relacionamento com outros objetos do Kubernetes. Os pods são onipresentes no Kubernetes, então compreendê-los facilitará seu trabalho.

      • Deployments Overview - fornece uma visão geral dos deployments. É útil entender como os controladores, como os deployments, funcionam, pois eles são usados com frequência em aplicações stateless para escalonamento e na recuperação automatizada de aplicações não íntegras.

      • Services Overview - cobre os serviços ou services, outro objeto frequentemente usado em clusters do Kubernetes. Entender os tipos de serviços e as opções que eles têm é essencial para executar aplicações stateless e stateful.

      Outros conceitos importantes que você pode analisar são Volumes, Ingresses e Secrets, os quais são úteis ao realizar o deploy de aplicações em produção.

      O Kubernetes tem muitas funcionalidades e recursos a oferecer. A Documentação Oficial do Kubernetes é o melhor lugar para aprender sobre conceitos, encontrar guias específicos de tarefas e procurar referências de API para vários objetos.

      Por bsder



      Source link