IBM Cloud Private: Arquitetura Detalhada de Componentes: Difference between revisions

From Wiki
Line 68: Line 68:


O '''Ingress Controller''' é responsável por atender a todas essas requisições de entrada.
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.


= Ver também =
= Ver também =

Revision as of 12:32, 16 January 2019

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.

Ver também