1. Introdução ao Catálogo de Serviços
O diretório de serviço é um diretório que lista todos os serviços. Os usuários podem navegar no catálogo e configurar instâncias de serviço listadas no catálogo, sem precisar lidar com pods, serviços, configmaps e outros recursos necessários para a execução do serviço. Isso soa semelhante a recursos da Web personalizados.
O catálogo de serviços não adiciona recursos customizados ao servidor de API de cada tipo de serviço, mas introduz quatro recursos de API gerais nele:
- Um ClusterServiceBroker, descrevendo um sistema (externo) que pode fornecer serviços
- Um ClusterServiceClass descrevendo um tipo de serviço provisionável
- Um ServiceInstance, uma instância do serviço configurado
- Um ServiceBinding que representa a ligação entre um conjunto de clientes (pods) e um ServiceInstance
O administrador do cluster cria um recurso ClusterServiceBroker para cada intermediário de serviço que precisa fornecer seus serviços no cluster. Em seguida, o kubernetes obtém a lista de serviços que podem fornecer do proxy de serviço e cria um recurso ClusterServiceClass para cada um deles. Quando um usuário provisiona um serviço, primeiro ele precisa criar um recurso ServiceInstance e, em seguida, criar um ServiceBinding para vincular esse ServiceInstance ao seu pod. Em seguida, o pod Alisma é injetado com um segredo que contém as credenciais e outros dados necessários para se conectar ao ServiceInstance configurado.
2. Introdução do servidor API do diretório de serviços e do gerenciador do controlador
Semelhante ao kubernetes principal, o diretório de serviço também é um sistema distribuído que consiste em três componentes:
- Servidor de API do Catálogo de Serviços
- etcd como armazenamento
- Um gerenciador de controladores que executa todos os controladores
Os números de recursos relacionados aos quatro diretórios de serviço apresentados anteriormente são criados publicando a lista YAML/JSON no servidor API. O servidor da API irá armazená-los em sua própria instância do etcd ou usar o CRD no servidor da API principal como um mecanismo de armazenamento alternativo (caso em que nenhuma instância adicional do etcd é necessária)
O próprio controlador não fornece o serviço solicitado, mas o deixa para um proxy de serviço externo, que o registra criando um recurso ServiceBroker na API do catálogo de serviços.
3. Proxy de serviço e API OpenServiceBroker
Um administrador de cluster pode registrar um ou mais ServiceBrokers externos no catálogo de serviços. Ao mesmo tempo, cada corretor deve implementar a API OpenServiceBroker.
Introdução à API OpenService Broker
Por meio da API OpenServiceBroker, o diretório de serviço pode se comunicar com o intermediário por meio da API. Essa API REST simples pode fornecer as seguintes funções:
Use GET /v2/catalog para recuperar a lista de serviços
Configurar instância de serviço (PUT /v2/service_instances/:id)
atualizar instância de serviço (PATH/v2/service_instaces/:id)
Instância de serviço de ligação (PUT /v2/service_instances/:id/service_bindings/:binding_id)
Desvincular instância (DELETE /v2/service_instances/:id/service_bindings/:binding_id)
Cancelar configuração da instância de serviço (DELETE /v2/service_instances/:id)
Registre um agente no catálogo de serviços
Os administradores de cluster podem registrar agentes publicando um manifesto de recurso do ServiceBroker na API do Catálogo de Serviços
Um manifesto ClusterServiceBroker: database-broker.yaml
apiVersion：servicecatalog.k8s.io/v1alpha1
metadados:
nome: banco de dados-broker
especificação:
URL: http://database-osbapi.myorganizations.org
A listagem de código acima descreve um agente virtual que pode fornecer diferentes tipos de bancos de dados. Depois que um administrador cria um recurso ClusterServiceBroker, um controlador no Service Catalog Controller Manager se conecta à URL especificada no recurso e recupera uma lista de serviços que esse broker pode fornecer.
Depois que a lista de serviços é recuperada, um recurso ClusterServiceClass é criado para cada serviço. Cada recurso ClusterServiceClass descreve um serviço provisionável. Cada ClusterServiceClass tem um ou mais esquemas de serviço associados a ele. Os usuários podem escolher entre diferentes planos, dependendo do nível de serviço de que necessitam.
Listar serviços disponíveis no cluster
$ kubectl obter classes de serviço
4. Prestação de serviços e uso de serviços
fornecer serviços
Para pré-alocar um banco de dados, tudo o que você precisa fazer é criar um recurso ServiceInstance
ServiceInstance:database-instance.yaml
apiVersion:servicecatalog.k8s.io/v1alpha1
tipo:ServiceInstance
metadados:
nome: meu-postgres-db
especificação:
clusterServiceClassName:postgres-database
clusterServicePlanName: grátis
Parâmetros:
init-db-args:--data-checksums
Crie um ServiceInstance chamado my-postgres-db como acima, especifique o ClusterServiceClass e selecione o esquema. Também é necessário especificar um clear broker e os parâmetros requeridos pelo ClusterServiceClass.
Depois que esse recurso é criado, o catálogo de serviços pergunta ao agente a que pertence o ClusterServiceClass para provisionar o serviço, passando a ele o ClusterServiceClass de sua escolha, o nome do plano e quaisquer parâmetros especificados.
O que fazer a seguir com essas informações depende inteiramente do agente.
Verifique o status do my-postgres-db ServiceInstance criado para verificar se o serviço foi provisionado com sucesso.
$ kubectl obtém instância my-postgres-db -o yaml
Vincular instância de serviço
Se você quiser usar o ServiceInstance configurado no pod, poderá criar um recurso de vinculação, conforme mostrado na lista de códigos abaixo
ServiceBinding: my-postgres-db-binding.yaml
apiVersion:servicecatalog.k8s.io/v1alpha1
tipo: ServiceBinding
metadados:
nome: my-postgres-db-binding
especificação:
instânciaRef:
nome: meu-postgres-db
secretName:postgres-secret
O código acima define um recurso ServiceBinding chamado my-postgres-db-binding, que se refere à instância de serviço my-postgres-db criada anteriormente e também nomeia um segredo.
Ao enviar um recurso ServiceBinding da lista anterior para o servidor da API do Catálogo de Serviços, o controlador contata novamente o proxy do banco de dados e cria uma ligação para o ServiceInstance configurado anteriormente. Em resposta, neste ponto, o proxy retorna as credenciais e outros dados necessários para vincular ao banco de dados. O catálogo de serviços cria um novo segredo com o nome especificado no recurso ServiceBinding e armazena todos os dados no segredo.
Use o segredo recém-criado no pod do cliente
Os segredos criados pelo sistema de catálogo de serviços podem ser carregados em pods para que os segredos possam ler seu conteúdo e usá-los para conectar-se a instâncias de serviço configuradas.
Um segredo contendo credenciais para se conectar à instância de serviço
$ kubectl obter segredo postgres-secret -o yaml
apiVersão:v1
dados:
host:<nome do host do banco de dados codificado em base64>
nome de usuário: <nome de usuário codificado em base64>
senha: <senha codificada em base64>
tipo:Segredo
metadados:
nome: postgres-secret
namespace: padrão
...
tipo: Opaco
5. Desvincular e desconfigurar
As vinculações de serviço não são mais necessárias e podem ser removidas da mesma forma que outros recursos
$ kubectl delete servicebinding my-postgres-db-binding
Nesse ponto, o controlador do catálogo de serviços excluirá a chave e notificará o agente para desassociar, enquanto a instância do serviço ainda estará em execução. Portanto, você pode criar uma nova ligação de serviço.
Se a instância de banco de dados não for mais necessária, o recurso de instância de serviço também poderá ser excluído
$ kubectl delete serviceinstance my-postgres-db
Depois que o recurso ServiceInstance é excluído, o catálogo de serviço executa uma operação de desconfiguração no proxy de serviço. Além disso, embora as consequências da desconfiguração dependam do agente, você deve instruir o agente a desligar a instância do banco de dados postgresSQL que foi criada quando a instância do serviço foi provisionada
6. O que o catálogo de serviços nos traz
Os provedores de serviços podem expor serviços em qualquer cluster kubernetes registrando um proxy nesse cluster.