Como o Rancher gerencia e se comunica com vários clusters Kubernetes

Este artigo se concentra na arquitetura do servidor Rancher, seus componentes e como o Rancher gerencia e se comunica com clusters Kubernetes downstream.

Arquitetura do Servidor Rancher

Gerenciando clusters Kubernetes por meio do proxy de autenticação do Rancher

A figura acima ilustra a arquitetura de alto nível do Rancher 2.x.

• O servidor Rancher pode gerenciar vários clusters Kubernetesao mesmo tempo (criados por RKE ou Amazon EKS)
• Os usuários podem gerenciar vários clusters Kubernetes por meio do Authentication Proxy.O Authentication Proxy encaminha todas as chamadas da API Kubernetes para clusters downstream.
• Para melhor desempenho e segurança, é recomendado um cluster Kubernetes dedicado para o servidor Rancher. Após implantar o Rancher, podemos criar ou importar clusters.

Comunicação com clusters de usuários downstream

O diagrama abaixo mostra como os controladores de cluster, agentes de cluster e agentes de nó permitem que o Rancher controle clusters downstream.

Comunicação com clusters de usuários downstream

 

As descrições a seguir correspondem aos números no diagrama acima:

1. O proxy de autenticação

• Um usuário chamado Bob é autenticado através do proxy de autenticação do Rancher. O proxy de autenticação encaminha todas as chamadas da API Kubernetes para clusters downstream.
• O proxy de autenticação integra-se a serviços de autenticação como autenticação local, Active Directory e GitHub.
• Em cada chamada da API do Kubernetes, o proxy de autenticação autentica o chamador e define os cabeçalhos de representação do Kubernetes adequadosantes de encaminhar a chamada para os mestres do Kubernetes.
• O Rancher se comunica com clusters Kubernetes usando uma conta de serviço, que fornece uma identidade para processos executados em um pod.

2. Controladores de Cluster e Agentes de Cluster

Há um controlador de cluster e um agente de cluster para cada cluster downstream. O agente de cluster abre um túnel para o controlador de cluster no servidor Rancher.

Cada controlador de cluster:

• Observa alterações de recursos no cluster downstream
• Traz o estado atual do cluster downstream para o estado desejado
• Configura políticas de controle de acesso para clusters e projetos
• Provisiona clusters chamando os drivers de máquina Docker e mecanismos Kubernetes necessários, como RKE e GKE

O agente de cluster, também chamado de cattle-cluster-agent, é um componente executado em um cluster de usuário downstream. Ele executa as seguintes tarefas:

• Conecta-se à API Kubernetes
• Gerencia cargas de trabalho, criação e implantação de pods em cada cluster
• Aplica as funções e vinculações definidas nas políticas globais de cada cluster
• Comunica-se entre o cluster e o servidor Rancher ( por meio de um túnel para o controlador do cluster) sobre eventos, estatísticas, informações do nó e integridade

3. Agentes de nó

• Se o agente de cluster (também chamado de cattle-cluster-agent) não estiver disponível, um dos agentes do nó cria um túnel para o controlador de cluster para se comunicar com o Rancher.
• O cattle-node-agenté implantado usando um recurso DaemonSet para garantir que seja executado em todos os nós de um cluster Kubernetes lançado pelo Rancher.
• Ele é usado para interagir com os nós ao executar operações de cluster, incluindo a atualização da versão do Kubernetes e a criação ou restauração de instantâneos do etcd.

4. Endpoint de cluster autorizado (ACE)

Os clusters Kubernetes lançados pelo Rancher contêm um serviço de autenticação chamado kube-api-auth, que permite aos usuários se comunicarem diretamente com o cluster k8s downstream sem usar o Authentication Proxy. Existem dois propósitos principais:

• Para acessar um cluster de usuário downstream enquanto o Rancher está inativo
• Para reduzir a latência quando o servidor Rancher e o cluster downstream estão separados por uma longa distância.

Aqui tem um resumo do Rancher e qualquer maiores detalhes podemos ver nas documentações do site da SUSE e o Site do Rancher.

Obrigado