Arquitetura
SUSE® Rancher Prime Continuous Delivery tem dois componentes principais. O controlador SUSE® Rancher Prime Continuous Delivery e os agentes de cluster. Esses componentes funcionam em um modelo de pull em duas etapas. O controlador SUSE® Rancher Prime Continuous Delivery fará pull do git e os agentes de cluster farão pull do controlador SUSE® Rancher Prime Continuous Delivery.
SUSE® Rancher Prime Continuous Delivery Controlador
O SUSE® Rancher Prime Continuous Delivery controlador é um conjunto de controladores Kubernetes executando em qualquer cluster Kubernetes padrão. A única API exposta pelo SUSE® Rancher Prime Continuous Delivery controlador é a API Kubernetes, não há API personalizada para o controlador Fleet.
Agentes de Cluster
Um agente de cluster é executado em cada cluster e é responsável por se comunicar com o SUSE® Rancher Prime Continuous Delivery controlador. A única comunicação do cluster para o SUSE® Rancher Prime Continuous Delivery controlador é por meio deste agente e toda a comunicação vai do cluster gerenciado para o SUSE® Rancher Prime Continuous Delivery controlador. O controlador Fleet não inicia conexões com clusters downstream. Isso significa que clusters gerenciados podem operar em redes privadas e atrás de NATs. A única exigência é que o agente de cluster precisa ser capaz de se comunicar com a API Kubernetes do cluster que executa o SUSE® Rancher Prime Continuous Delivery controlador. A única exceção a isso é se você usar o fluxo de registro do cluster iniciado pelo manager-initiated registration. Isso não é obrigatório, mas é um padrão opcional.
Os agentes de cluster não são considerados como tendo uma conexão "sempre ativada". Eles retomarão a operação assim que puderem se conectar. Melhorias futuras provavelmente adicionarão a capacidade de agendar horários em que o agente se conecta; no momento, ele sempre tentará se conectar.
Segurança
O SUSE® Rancher Prime Continuous Delivery controlador cria dinamicamente contas de serviço, gerencia seu RBAC e, em seguida, fornece os tokens para os clusters downstream. Os clusters são registrados por meio de tokens de registro de cluster que podem expirar opcionalmente. O token de registro do cluster é usado apenas durante o processo de registro para gerar uma credencial específica para aquele cluster. Depois que a credencial do cluster é estabelecida, o cluster "esquece" o token de registro do cluster.
As contas de serviço atribuídas aos clusters têm privilégios apenas para listar BundleDeployment no namespace criado especificamente para aquele cluster. Ele também pode atualizar o status sub-recurso de BundleDeployment e o status sub-recurso de seu Cluster recurso.
