IBM Cloud Private: Arquitetura Detalhada de Componentes

Lista Completa de Componentes

Kubernetes Core

• Etcd

O Kubernetes armazena dados de cluster em um armazenamento de apoio chamado etcd no master node.

• Kubelet

É um agente que é executado em cada nó no cluster, se comunica com o master e gerencia atividades e recursos no nó, como a execução de pod containers via Docker.

• Kubernets Proxy

O proxy de rede do Kubernetes é executado em cada nó e mantém regras de rede no host e executa o encaminhamento de conexão.

• Kubernets Scheduler

O Scheduler é um processo que é executado no master node e sabe o que está sendo executado, onde e quando, e determina em qual pod(s) para ser executado.

• Kubernets Control Manager

O controller é um loop de controle que observa o estado compartilhado do cluster através do apiserver e faz alterações tentando mover o estado atual para o estado desejado.

• Kubernets API Server

O apiserver é um processo executado no master node no cluster e expõe a API do Kubernetes.

Network services

DNS

• DNS (kube-dns, Cluster DNS)

O Kubernetes DNS cria um pod DNS e um serviço no cluster e configura os kubelets para informar contêineres individuais a usar o IP do serviço DNS para resolver nomes DNS.

Virtual IP Manager (VIP Manager)

• UCarp

O UCarp basicamente permite que alguns hosts compartilhem o mesmo IP virtual, ou endereços IP flutuantes, para fornecer failover automático.

Calico

O Project Calico é uma nova abordagem para redes virtuais e segurança de rede para contêineres, e foi projetado tendo a arquitetura de rede em nuvem em mente.

A ferramenta de linha de comando do calicoctl, também pode ser usada para gerenciar redes e políticas de segurança do Calico.

Detalhes na site do Project Calico.

Existem três componentes principais:

Calico Node (calico/node)

O calico/node Docker contêiner é executado no master node do Kubernetes e em cada nó do Kubernetes no cluster

calico-cni

O calico-cni plug-in integra-se diretamente ao kubelet em cada nó para descobrir quais pods foram criados e os adiciona à rede Calico

Calico Policy Controller (calico/kube-policy-controller)

O calico/kube-policy-controler contêiner é executado como um pod no topo do Kubernetes e implementa a Network Policy API.

Ingress Controller

Normalmente, serviços e pods têm IPs somente roteáveis pela rede do cluster. O tráfego que atinge o roteador de borda é descartado ou encaminhado para outro local.

O Ingress é uma coleção de regras que permite que parte desse tráfego de conexão de entrada atinja o cluster de serviços.

Você pode configurar o Ingress para:

• dar acesso externo a URLs de serviços
• load balance ou terminate SSL
• oferecer hospedagem virtual baseada em nome
• ...

O Ingress Controller é responsável por atender a todas essas requisições de entrada.

Authentication

Como funciona a autenticação? O Authentication Manager aceita credenciais de usuário do console de gerenciamento e encaminha as credenciais para o provedor OIDC de back-end.

O provedor OIDC valida as credenciais do usuário no diretório corporativo. Em seguida, ele retorna um cookie de autenticação (auth-cookie) com o conteúdo de um token da Web JSON (JWT) para o gerenciador de autenticação.

Este cookie de autenticação é então enviado de volta ao console de gerenciamento. O cookie é atualizado durante a sessão, sendo válido por 12 horas depois que você sair do console de gerenciamento ou fechar seu navegador.

Authentication Manager

O principal componente de Authentication é o Authentication Manager. Que provê:

• Fornece uma API HTTP para gerenciar usuários
• Os protocolos são implementados de maneira RESTful
• Keystone é usado para autenticação
• Pass-through para integração LDAP externa

Keystone

O serviço de identidade fornecido pelo OpenStack atualmente suportando token-based authN e autorização de serviço de usuário.

O Keystone está sendo usado para autenticação e a pass-through para integração LDAP externa.

MariaDb

Um banco de dados relacional de código aberto feito pelos desenvolvedores originais do MySQL. Nesse caso, ele é usado para fazer back-end do Keystone.

Image Management

Um cenário típico com o IBM Cloud Private ou com o Kubernetes é que um desenvolvedor baixe uma imagem de um registro público, faça testes e alterações, e em seguida fará um push dessa imagem em seu registro privado local. Nesse ponto, essa imagem fica disponível para uso nos diversos cluster da sua organização.

Interfaces para o Usuário

Cluster Management Console

O Cluster Management Console é a GUI do IBM Cloud Private que é usada para gerenciar, monitorar e solucionar problemas de seus aplicativos e cluster a partir de um console de gerenciamento único, centralizado e seguro.

Kubernetes Web UI

Você pode usar também a interface da Web do Kubernetes para gerenciar o IBM Cloud Private.

kubectl

A interface de linha de comando do Kubernetes.

Application Center

O Application Center fornece um local centralizado a partir do qual você pode procurar e instalar pacotes em seu cluster. Esses pacotes são representados pelos gráficos de Helm abaixo.

Com o Helm, você pode fornecer rapidamente o acesso controlado pelo usuário para implantar mais do que aplicativos elementares baseados em pods em seu ambiente Kubernetes.

Helm Repository

O Helm Repository é um repositório para manter os Helm charts.

Tiller (Server)

O Tiller é usado dentro do cluster, gerenciando as diferentes instalações ou lançamentos de seus charts.

IBM Cloud Private Catalog

O IBM Cloud Private Catalog É uma coleção de pacotes de implantação (Helm charts ) exibidos como blocos que fornecem acesso a diversos softwares, e fornece acesso simples e de autoatendimento ao software IBM e Open Source criado para o Kubernetes.

Por padrão, 2 repositórios estão incluídos:

• IBM Charts – disponíveis publicamente no github.com/ibm/charts
• Local Charts – Instalados com o IBM Cloud Private

Logging e Monitoração

O monitoramento de uma implementação do IBM Cloud Private é ativado no momento da instalação e as principais métricas são coletadas imediatamente. O Grafana é utilizado para fornecer o dashboard das métricas coletadas pela Prometheus.

O ICP vem com Cloud Service Management and Operations (CSMO) Dashboards para ajudar uma organização a obter uma compreensão imediata da integridade de suas implantações do IBM Cloud Private.

O método de registro mais fácil e mais abrangente para aplicativos contêinerizados é escrever o standard-error e standard-out e isso é precisamente o que é feito padrão dentro do ICP. O ICP usa uma ELK Stack para tratar logs do sistema.

Você também pode ver os componentes usando a interface de linha de comando:

kubectl get configmap --namespace=kube-system | grep "alert\|monitor"

Como funciona?

• O IBM Cloud Private Dashboard mostra o status e as métricas para as workloads e o ambiente.
• Elastic Stack coleta logs de todos os nós (master and workers) e workloads.
• Prometheus coleta métricas.
• Kibana e o Grafana fornecem visibilidade dos dados coletados.
• O Prometheus pode ser configurado para enviar alertas para fontes externas. Fontes de exemplo são email e webhooks.

Coletando os logs

A abordagem mais simples, a aplicação envia logs no stderr e no stdout, que são coletados automaticamente pelo Docker e enviados para o serviço de log IBM Cloud Private por padrão. Docker armazena em um arquivo de log separado para esse contêiner (geralmente em /var/lib/docker/containers/<container_id>).

A segunda abordagem, empacotando um contêiner Filebeat como um sidecar, é mais envolvido, mas flexível o suficiente para se adaptar à maioria das cargas de trabalho que gravam seus logs em um ou mais arquivos de log. A maioria dos aplicativos armazena logs localmente em arquivos discretos. No Linux, eles geralmente são armazenados em algum lugar no diretório /var/log. A solução mais eficaz é adicionar outro contêiner ao seu pod, geralmente denominado sidecar, que tem visibilidade desses logs e executa uma ferramenta de streaming, como o Filebeat.

Persistent Storage

Tradicionalmente, os contêineres deveriam ser sem estado, onde o armazenamento existia apenas dentro desse contêiner, isto é, se o contêiner finalizar, as configurações ou dados que existiam nesse contêiner eram perdidas.

Algumas aplicações entretanto precisam armazenar algum tipo de dado ou estado, portanto, uma solução de armazenamento persistente.

Se você está acostumado com a terminologia usada na documentação do Kubernetes, a terminologia do IBM Cloud Private é um pouco diferente. Em Kubernetes a:

• PersistentVolume (PV) é uma definição de armazenamento disponível para todo o cluster
• PersistentVolumeClaim (PVC) é a reivindicação de um aplicativo específico para alguns desses armazenamentos.

No IBM Cloud Private, o equivalente a um:

• PV é "Storage", que está disponível para todo o cluster
• PVC é um “Volume” que é usado por um aplicativo para armazenar dados

O ICP está focado em fornecer suporte para o seguinte:

• HostPath
• NFS
• GlusterFS and Heketi (api server)
• vSphereVolume

Ver também

• Artigos sobre Cloud
• Mais Artigos sobre Cloud / WebDev / Tecnologias