Crossplane

Este material ainda está em desenvolvimento

Antes de começar a entender, se caiu de paraquedas, o Crossplane é uma ferramenta IaC desenvolvida para o Kubernetes. Declaramos o que queremos através de manifestos yaml para Kubernetes e o Crossplane com seus respectivos Providers irão trabalhar para transformar o estado desejado em estado real. Diferentemente do Terraform que possui um statefile para guardar o que foi provisionado, o Crossplane guarda toda informação dentro do próprio ETCD do Kubernetes, o banco de dados de objetos do Kubernetes.

Não adianta aprender Crossplane se não entender Kubernetes. Se acha que conseguirá fazer isso sinto em dizer que não será possível, talvez tenha chegado até aqui muito cedo. Volte mais tarde!

O Crossplane é uma ferramenta open-source que está crescendo rapidamente. Sua proposta é estender a API do Kubernetes para criar novos control planes para gerenciar ciclo de vida de recursos de qualquer tipo, transformando o Kubernetes em um controller universal. Permite que você gerencie qualquer coisa, em qualquer lugar, tudo por meio de APIs padrão do Kubernetes.

É o poder que falta para o seu IDP, pode ter certeza.

Os planos de controle verificam constantemente se os recursos pretendidos existem, relatam quando o estado pretendido não corresponde à realidade e agem para corrigir as diferenças. Este é um princípio fundamental da abordagem declarativa do Kubernetes que o Crossplane estende para recursos externos.

Com o Crossplane, as equipes da plataforma podem criar novas abstrações e APIs personalizadas com todo o poder das políticas, namespaces e controles de acesso baseados em função do Kubernetes. O Crossplane permite que engenheiros de plataforma criem APIs e abstrações personalizadas combinando recursos nativos do Kubernetes e recursos de nuvem sob um único plano de controle.

Estamos aproveitando que a API do Kubernetes é extensível e tornando-a universal.

Github Crossplane

Como o Crossplane atua?

Através de Custom Resources Definitions no Kubernetes, cria-se recursos externos ao Kubernetes como objetos nativos do Kubernetes. Dessa forma, é possível usar o comando kubectl create e kubectl describe para esses objetos. Para eles, o Crossplane será o controller e forçará uma imposição do estado desse recurso.

Para ter uma ideia, é uma espécie de Terraform aplicado pelo Kubernetes, mas com importantes diferenças:

Na verdade é muito mais que isso, pois podemos criar abstrações para qualquer coisa. Saindo saído de consumidor de APIs para provedores de API.

• O Crossplane é nativo do Kubernetes e utiliza sua API extensível
• A gestão do estado é feita diretamente no ETCD do cluster
• Possibilita abstrações mais avançadas através das Compositions

Os usuários somente se comunicam com o Kubernetes definindo recursos utilizando manifestos, e o Crossplane será o controller se comunicando com os recursos externos para entregar o que foi pedido. A ideia é empacotar tudo que o usuário deseja fazer criando um Custom Resource para isso e por baixo dos panos realizar todas as operações necessárias.

Com APIs personalizadas, os usuários não precisam saber detalhes sobre os recursos ou requisitos subjacentes, apenas os detalhes expostos pela plataforma.

Conceitos Iniciais

O Crossplane usa vários componentes principais para gerenciar os diversos elementos de criação e gerenciamento de recursos externos por meio do Kubernetes:

• Os pods Crossplane incluem o pod Crossplane principal e o pod gerenciador Crossplane RBAC. Juntos, esses pods gerenciam todos os componentes e recursos do Crossplane.

• Os providers conectam o Kubernetes a qualquer provedor externo, como AWS, Azure ou GCP, de forma semelhante ao que o Terraform faz. Os providers traduzem manifestos nativos do Kubernetes e chamadas de API em chamadas de API externas. Os providers são responsáveis por criar, excluir e gerenciar o ciclo de vida de seus recursos, sendo nosso ponto de ligação com sistemas externos.

• Managed resources são objetos do Kubernetes que representam recursos que o Provider criou fora do Kubernetes. Criar um recurso gerenciado no Kubernetes requer que um Provider crie um recurso correspondente no sistema externo. Excluir um recurso gerenciado requer que um Provider exclua o recurso externo associado.

• Compositions são modelos de recursos gerenciados. Compositions descrevem implantações mais complexas, combinando vários recursos gerenciados e quaisquer personalizações necessárias. Não pense nisso somente como recurso em cloud, pense maior. Às vezes, para criar uma composition, podemos utilizar vários recursos gerenciados diferentes que utilizam providers diferentes. O importante é entregar para o nosso usuário o que ele quer através de uma request simples, escondendo a complexidade.

• Composite Resource Definitions representam uma API personalizada, criada por engenheiros de plataforma e consumida por desenvolvedores ou usuários finais. Composite resource definitions usam um esquema OpenAPIv3 para estender ainda mais o Kubernetes com endpoints de API personalizados, revisões e muito mais.

  • Composite Resources representam todos os objetos criados por um usuário chamando a API personalizada. Toda vez que um usuário acessa a API personalizada, o Crossplane cria um único `Composite Resource e vincula todos os recursos gerenciados relacionados a ele.

  • Se você reparou bem, o que temos que nos concentrar mesmo para dominar o Crossplane de verdade são as composições.

• Claims são como Composite Resources, mas em nível de namespace.

• EnvironmentConfigs: são como o Kubernetes ConfigMap. São úteis para mapeamento de recursos personalizados ou para armazenar e recuperar dados em Claims e Composite Resources.

• Usages definem recursos críticos ou mapeamentos de dependência personalizados. Podem impedir que o Crossplane exclua ou podem garantir que um recurso pai espere que o Crossplane exclua todos os recursos filhos primeiro. Seria como o depends_on do Terraform.

Ainda temos os conceitos de Package e ImageConfigs que serão abordados em detalhes posteriormente.

Mantenedores

A Upbound é a empresa por trás do desenvolvimento do Crossplane. Ela tem um papel fundamental no ecossistema Crossplane de várias maneiras:

• Mantenedora Principal liderando o desenvolvimento do core do Crossplane e contribui com a maior parte do código.
• Oferece o Upbound Cloud, uma plataforma gerenciada para o Crossplane.
• Desenvolve e mantém alguns providers oficiais.
• Responsável pelo Upbound Marketplace para distribuição dos providers.
• Mantém a documentação oficial.
• coordena a comunidade de desenvolvedores.

Embora a Upbound seja a empresa principal por trás do Crossplane, o projeto é open source e faz parte da Cloud Native Computing Foundation (CNCF), permitindo contribuições da comunidade global.