O uso de containers tem se popularizado e trazido mais agilidade e menor custo no momento de desenvolver aplicações e entregar serviços, abstraindo a camada de infraestrutura, antes de difícil escalabilidade e portabilidade.
Apesar do Docker ter se popularizado, a gerência de muitos containers se tornou complexa, portanto surgiram os orquestradores que passaram a garantir a saúde dos muitos itens que rodavam, sem a necessidade de alguém que tomasse conta.
Temos diversas ferramentas que cumprem esse papel, entre elas o Kubernetes que ganhou força à partir da quantidade de features, robustez e quantidade de contribuidores que decidiram tornar o processo de orquestração amigável e permitiram a compatibilidade com os principais Provedores Cloud (AWS, Google e Azure), bem como os servidores de sua infra.
Muitos problemas como escalabilidade automática, balanceamento de carga, comunicação entre containers, exposição de aplicações e serviços foram resolvidos e muitas empresas adotaram a tecnologia
Uma camada acima do Kubernetes, temos as plataforma como serviços, os famosos PaaS (Plataform as a Service). O Openshift, que embora use o Kubernetes por baixo, está nessa camada, possui um “self-service” de componentes que podem ser selecionado conforme desejado, tendo soluções internas de registry, build de imagens a partir de código fonte (S2I), monitoria, segurança, logs, integração contínua, etc.
A ferramenta é mantida pela Red Hat e possui versões pagas e gratuitas. A versão free – denominada OKD (The Origin Community Distribution of Kubernetes) pode ser utilizada pela comunidade e se encontra no github, já a Enterprise é paga e incluí suporte e uma maior estabilidade.
A final o que é Docker?
Docker é um projeto OpenSource que fornece uma plataforma para desenvolvedores e administradores de sistemas permitindo que se crie containers leves e portáteis para diversas aplicações.
Sua funcionalidade é basicamente uma forma de isolamento de processo e sistemas, quase como uma virtualização, porém mais leve e integrada ao host. O Docker permite criar aplicações em Containers que isolam o SO base de toda pilha de dependências de forma leve.
Além disso, os containers oferecem maior flexibilidade para você criar, implantar, copiar e migrar um container de um ambiente para outro. Isso otimiza as aplicações na cloud.
O que é um Container Linux?
Os containers Linux são tecnologias que permitem empacotar e isolar aplicativos com todo o seu ambiente de tempo de execução, ou seja, com todos os arquivos necessários para executar os aplicativos. Dessa forma, é mais fácil migrar a aplicação em container de um ambiente para outro (desenvolvimento, teste, produção etc.) sem perder nenhum aspecto da funcionalidade.
O Container é como se fosse um chroot, um tipo de partição isolada dentro de um único sistema operacional. Os containers oferecem muito dos mesmos benefícios das maquinas virtuais, como segurança, armazenamento e isolamento de rede e ao mesmo tempo exigem menos recursos de hardware. É possível definir recursos como memória, rede, cpu, sistema, aplicação, serviços e etc.
Aplicativos de software são normalmente implantados como um único conjunto de bibliotecas e arquivos de configuração em um ambiente de tempo de execução.
Tradicionalmente , eles são implantados em um sistema operacional com um conjunto de serviços em execução, como um servidor de banco de dados ou um servidor HTTP, mas também podem ser implantados em qualquer ambiente que possa oferecer os mesmos serviços, como maquinas virtuais ou um host físico.
A maior desvantagem em usar aplicativos de software é que ele está atrelado ao ambiente em execução. Qualquer atualização ou patch aplicado o SO base pode interromper a aplicação.
Como alternativa, um administrador de sistema pode trabalhar com containers. Como mencionado anterior mete, exige menos recursos de hardware e são mais ágeis na hora de iniciar e finalizar. O uso de containers aumenta tanto e eficiência, a flexibilidade e a reusabilidade das aplicações de containers.
A imagem a seguir ilustra a diferença entre container e sistema operacional
Algumas das principais vantagens dos containers:
- Baixa área de ocupação de hadrware: Usa recursos internos do SO para criar um ambiente isolado em que os recursos são gerenciados usando funcionalidades do SO, como namespaces e cgroups. Essa abordagem minimiza a quantidade de sobrecarga de CPU e na memória em comparação a um hipervisor de máquina virtual.
- Isolamento de Ambiente: Funciona em um ambiente fechado onde as alterações feitas no SO de host ou outros aplicativos não afetam o contêiner. Como as bibliotecas necessárias para um contêiner são autocontidas, o aplicativo pode ser executado sem interrupções. Por exemplo, cada
aplicativo pode existir em seu próprio contêiner com seu próprio conjunto de bibliotecas. Uma atualização feita em um contêiner não afeta outros contêineres, que podem não funcionar com a atualização.
- Implantação rápida: Implanta qualquer contêiner rapidamente porque não há necessidade de uma instalação ou reinicialização total do SO. Normalmente, para suportar o isolamento, uma nova instalação do SO é necessária em um host físico ou VM, e qualquer atualização simples pode precisar de uma reinicialização total do SO. Um contêiner precisa somente de reinicialização sem interromper nenhum serviço no SO do host.
- Reusabilidade: Um mesmo contêiner pode ser usado por vários aplicativos sem a necessidade de configurar um SO completo.
Visão geral da arquitetura do Docker
O Docker usa uma arquitetura de servidor e cliente, descrita abaixo:
- Cliente: A ferramenta de linha de comando (docker) que é responsável pela comunicação com um servidor usando uma API RESTful para solicitar as operações.
- Servidor: Esse serviço, que é executado como um daemon em um sistema operacional, faz o trabalho de compilar, executar e baixar imagens de contêiner. O daemon pode ser executado no mesmo sistema que o cliente do docker ou remoto.
Elementos do Docker
- Registry: O registry armazena imagens para uso público ou privado. O registry público mais conhecido é o Docker Hub que armazena várias imagens desenvolvidas pela comunidade, mas registries privados podem ser criados para suportar o desenvolvimento interno de imagens de acordo com os critérios de uma empresa.
- Contêineres: Os contêineres são ambientes segregados de espaço de usuário para executar aplicativos isolados de outros aplicativos compartilhando o mesmo SO de host.
- Imagens: As imagens são modelos somente leitura que contêm um ambiente de tempo de execução que inclui bibliotecas de aplicativo e aplicativos. As imagens são usadas para criar contêineres. Imagens podem ser criadas, atualizadas ou baixadas para uso imediato.
Contêineres e o kernel do Linux
Os contêineres são ambientes segregados para executar aplicativos isolados de outros aplicativos compartilhando o mesmo SO de host.
- Namespaces: O kernel pode colocar em um namespace recursos de sistema específicos que normalmente são visíveis a todos os processos. Dentro de um namespace, somente processos que forem membros desse namespace podem ver tais recursos. Os recursos que podem ser colocados em um namespace incluem interfaces de rede, a lista de ID de processo, pontos de montagem, recursos IPC e as próprias informações de nome do host do sistema.
- Control Groups (cgroups): Os cgroups particionam conjuntos de processos e seus filhos em grupos a fim de gerenciar e limitar os recursos consumidos por eles. Os cgroups estabelecem restrições na quantidade de recursos de sistema que os processos pertencentes a um contêiner específico podem usar. Isso impede que um contêiner use recursos em excesso no host do contêiner.
- SELinux: O SELinux é um sistema de controle de acesso obrigatório que é usado para proteger contêineres uns dos outros e para proteger o host de contêiner contra seus próprios contêineres em execução. O mod de SELinux padrão enforce é usado para proteger o sistema de host contra contêineres em execução.
Terminologia do OpenShift
O Red Hat OpenShift Container Platform (OCP) é um conjunto de componentes e serviços modulares desenvolvidos com base no Red Hat Enterprise Linux e no Docker. O OCP adiciona capacidades PaaS como gerenciamento remoto, multilocação, segurança aumentada, gerenciamento de ciclo de vida de aplicativo e interfaces de autosserviço para desenvolvedores.
A figura a seguir ilustra a stack de software do OpenShift.
Na figura, da parte inferior para a parte superior e da esquerda para a direita, a
infraestrutura básica de contêiner é exibida, integrada e aperfeiçoada pela Red Hat:
• O SO de base é o Red Hat Enterprise Linux (RHEL).
• O Docker fornece a API de gerenciamento básica de contêiner e o formato de arquivo de imagem de contêiner.
• O Kubernetes gerencia um cluster de hosts (físicos ou virtuais) que executam contêineres. Ele funciona com recursos que descrevem aplicativos de vários contêineres compostos por vários recursos e de que maneira eles se interconectam. Se o Docker é o "cérebro" do OCP, o Kubernetes é o "coração" que o mantém em movimento.
• Etcd é um armazenamento de chave-valor distribuído, usado pelo Kubernetes para armazenar informações de configuração e estado dos contêiners e outros recursos dentro do cluster do Kubernetes. O OpenShift adiciona à infraestrutura de contêiner do Docker + Kubernetes as capacidades necessárias para fornecer uma plataforma PaaS de produção.
• Os OCP-KubernetesExtensions são tipos de recursos adicionais armazenados em Etcd e gerenciados pelo Kubernetes. Estes tipos adicionais de recursos formam o estado interno e a configuração do OCP.
• Containerized Services cumprem muitas funções de infraestrutura, como de rede e autorização. O OCP utiliza a infraestrutura básica de contêiner do Docker e do Kubernetes para a maioria das funções internas. Ou seja, a maioria dos serviços internos do OCP funciona como contêineres orquestrados pelo Kubernetes.
• Runtimes e xPaaS são imagens de contêiner de base prontas para serem
usadas pelos desenvolvedores, cada uma pré-configurada com um banco de dados ou linguagem de tempo de execução particular. A oferta de xPaaS é um conjunto de imagens de base para produtos JBoss middleware, como o JBoss EAP e ActiveMQ entre outros.
• DevOps Tools e User Experience: o OCP oferece ferramentas de
gerenciamento da Web e de CLI para gerenciar aplicativos de usuário e serviços do OCP. As ferramentas Web e CLI do OpenShift são desenvolvidas com base nas APIs do REST, que podem ser aproveitadas por ferramentas externas como IDEs e plataformas de CI. Um cluster do Kubernetes é um conjunto de servidores de nó que executam contêineres e são gerenciados centralmente por um conjunto de servidores masters. Um servidor pode
atuar tanto como servidor quanto como nó, mas tais funções são normalmente segregadas para obter maior estabilidade.
Tipos de recurso do Kubernetes
O Kubernetes possui cinco principais tipos de recursos que podem ser criados e configurados com um arquivo YAML ou JSON ou por meio das ferramentas de gerenciamento do OpenShift:
Pods: Representam uma coleção de contêineres que compartilham recursos, como endereços IP e volumes
Services: Definem uma combinação IP/porta única que fornece acesso a um pool de pods. Por padrão, os services conectam os clientes aos pods em round-robin.
Replication Controller: Uma estrutura para definir os pods que são destinados a serem escalonados horizontalmente. Um replication controller inclui uma definição de pod que deve ser replicada e os pods criados a partir dela podem ser agendados para diferentes nós.
Persistent Volumes (PV): Provisionam armazenamento em rede persistente para pods que podem ser montados dentro de um contêiner para armazenar dados.
Persistent Volumes Claims (PVC): Representam uma solicitação de armazenamento por um pod ao Kubernetes. Embora os pods do Kubernetes possam ser criados de forma independente, eles normalmente são criados por recursos de alto nível, como replication controllers.
Tipos de Recursos do OpenShift
A seguir, os principais tipos de recurso adicionados pelo OCP ao Kubernetes:
Deployment Configurations (DC): Representam um conjunto de pods criados a partir da mesma imagem de contêiner, gerenciando fluxos de trabalho, como atualizações sem interrupção. Um DC também oferece um fluxo de trabalho básico, porém extenso, de entrega contínua.
Build Configurations (BC): Usados pelo recurso Source-to-Image (S2I) do OpenShift para compilar uma imagem de contêiner a partir do código-fonte de aplicativo armazenado em um servidor Git. Um BC funciona junto com um DC para oferecer um fluxo de trabalho de integração contínua/entrega contínua básico, porém extenso.
Routes: Representam um nome de host DNS reconhecido pelo roteador OpenShift como um ponto de ingresso para aplicativos e microsserviços.
Embora os replication controllers do Kubernetes possam ser criados de forma
independente no OpenShift, eles normalmente são criados por recursos de alto nível, como deployment controllers.
Como funciona a comunicação de rede
Cada contêiner implantando por um daemon docker tem um endereço IP atribuído de uma rede interna que é acessível somente a partir do host executando o contêiner. Devido à natureza efêmera do contêiner, os endereços IPs são constantemente atribuídos e liberados.
O Kubernetes oferece uma rede definida por software (SDN) que gera redes internas de contêiner a partir de vários nós e permite que os contêineres acessem os pods de outros hosts a partir de qualquer pod, dentro de qualquer host. O acesso à SDN só funciona de dentro do mesmo cluster do Kubernetes.
Os contêineres dentro dos pods do Kubernetes não se conectam aos endereços IP dinâmicos uns dos outros diretamente. É recomendado que eles se conectem aos endereços IP mais estáveis atribuídos aos services e, assim, se beneficiem da escalabilidade e da tolerância a falhas.
O acesso externo a contêineres, sem OpenShift, exige o redirecionamento de uma porta em um host para o endereço IP interno do contêiner, ou de um nó para um endereço IP do serviço na SDN. Um serviço Kubernetes pode especificar um atributo NodePort que é uma porta de rede redirecionada por todos os nós do cluster à SDN. Infelizmente, nenhuma dessas abordagens apresenta um bom dimensionamento.
Ao definir os recursos de rota , o OpenShift torna o acesso aos contêineres escalável e mais simples. Os acessos HTTP e TLS a uma rota são encaminhados aos endereços de serviço dentro da SDN do Kubernetes. O único requisito é que os nomes de host DNS sejam mapeados para os endereços IP externos nos nós dos roteadores OCP.
Referencias
- https://www.redhat.com/pt-br/topics/containers/what-is-kubernetes
- https://www.redhat.com/pt-br/topics/containers/what-is-docker
- https://www.redhat.com/pt-br/topics/containers
- https://www.redhat.com/pt-br/topics/containers/whats-a-linux-container
- https://www.docker.com/
- https://docs.openshift.com/
Encerro por aqui este post. Retomando um velho projeto de escrer blog, compartilhar conteúdo, espero em breve conseguir compartilhar novo tópico.
Dúvidas, comentários, sugestões fico a inteira disposição.
Obrigado, valeu!!
