IBM Cloud Private: Arquitetura Detalhada de Componentes

Ficheiro:Icp arch components.jpg

=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.

Ficheiro:Helm packages.png

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.

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.
 * 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.

=Persistent Storage=

= Ver também =


 * Artigos sobre Cloud
 * Mais Artigos sobre Cloud / WebDev / Tecnologias