Please enable JavaScript.

Coggle requires JavaScript to display documents.

Operator Development (Part. 1) - Coggle Diagram

- - - - um API server para lidar com requisições recebidas
      - um armazenamento de dados para armazenar o estado desejado e real do sistema
      - um controller que observa o armazenamento de dados e reage às alterações.
- - - - Control via API server
        
        O controller de job é um exemplo de um controller integrado do Kubernetes. Os controllers integrados gerenciam o estado interagindo com o API Server do cluster.
        
        Job é um recurso do Kubernetes que executa um Pod, ou talvez vários Pods, para realizar uma tarefa e depois parar.
        
        Quando o controller de job vê uma nova tarefa, ele garante que, em algum lugar do cluster, os kubelets em um conjunto de nós estejam executando o número certo de pods para realizar o job. O controller de job não executa nenhum pod ou contêiner. Em vez disso, o controller de job informa ao API Server para criar ou remover pods. Outros componentes no plano de controle atuam nas novas informações (há novos Pods para agendar e executar) e, eventualmente, o job é concluído.
      - Direct Control
        
        Ao contrário de Job, alguns controllers precisam fazer alterações em coisas fora do cluster.
        
        Por exemplo, se você usar um loop de controle para garantir que haja nós suficientes em seu cluster, esse controller precisará de algo fora do cluster atual para configurar novos nós quando necessário.
        
        Os controllers que interagem com o estado externo encontram seu estado desejado no API Server e, em seguida, se comunicam diretamente com um sistema externo para alinhar o estado atual.
        
        Desde que os controllers do seu cluster estejam em execução e possam fazer alterações úteis, não importa se o estado geral é estável ou não.
    - - Como princípio de seu design, o Kubernetes usa muitos controllers, cada um gerenciando um aspecto específico do estado do cluster. Mais comumente, um loop de controle específico (controller) usa um tipo de recurso como seu estado desejado e possui um tipo diferente de recurso que ele gerencia para fazer esse estado desejado acontecer.
      - É útil ter controllers simples em vez de um conjunto monolítico de meshs de controle interligadas. Os controllers podem falhar, então o Kubernetes foi projetado para permitir isso.
      - Pode haver vários controllers que criam ou atualizam o mesmo tipo de objeto. Nos bastidores, os controllers do Kubernetes garantem que apenas prestem atenção aos recursos vinculados ao seu recurso de controle.
- - - - Arquivo de Structs que definem seu CRD e CR
      - A Struct Spec contém as informações que designam o estado desejado do recurso, enquanto a struct Status contém o estado observável do sistema, particularmente informações que outros recursos podem querer consumir.
      - Deve executar make generate (controller-gen) e make manifests (criação do CRD e arquivo yaml de roles)
      - Controller-Gen
        
        Kubebuilder faz uso desta ferramenta para gerar código utilitário e Kubernetes YAML. Este código e geração de configuração são controlados pela presença de “marker comments” especiais no código Go.
    - - O método Reconcile é responsável por reconciliar o estado desejado contido no status do custom resource's com o estado real em execução no sistema e é onde a maior parte da lógica do controller é implementada.
- - - - Especifica como o controller é construído para observar um CR e outros recursos pertencentes e gerenciados por esse controller.
      - NewControllerManagedBy().
        
        Fornece um construtor de controller que permite várias configurações de controller.
        
        .For(&cachev1alpha1.Memcached{}).
        
        Especifica o tipo Memcached como o principal recurso a ser observado. Qualquer evento irá iniciar o loop de reconcilicação ou o timeout de espera da reconcilçiação.
        
        .Owns(&appsv1.Deployment{})
        
        Especifica o tipo Deployments como o recurso secundário a ser observado
        
        O manipulador de eventos mapeará cada evento para uma solicitação de reconciliação para o proprietário da deployment. Que neste caso é o objeto Memcached para o qual a deployment foi criada.
    - - Esse método recebe um objeto Request que se refere ao objeto específico que está sendo reconciliado, bem como um objeto Context para acessar e modificar o estado no armazenamento etcd do Kubernetes. Resumindo Request será o estado desejado e Context o estado atual no etcd
      - A função de reconciliação é responsável por impor o estado CR desejado no estado real do sistema. Ele é executado sempre que um evento ocorre em um CR ou recurso observado e retornará algum valor dependendo se esses estados correspondem ou não.
    - - Ao iniciar a sua reconciliação, a primeira coisa a se fazer é modificar as markers para o que vc irá precisar de permissão e validar essas mudanças em config/rbac/role.yaml
      - example: //+kubebuilder:rbac:groups=cache.example.com,resources=memcacheds,verbs=get;list;watch;create;update;patch;delete