Dando uma olhada nos bastidores do OpenShift e descobrindo o segredo do repositório Origin

Se você já trabalhou com OpenShift ou instalou sua distribuição gratuita OKD, certamente já se deparou com o repositório openshift/origin. Na era do OpenShift 3 e nas primeiras versões 4.x, era aqui que vivia o núcleo de toda a plataforma. Os desenvolvedores clonavam uma grande parte do código-fonte do Kubernetes aqui e construíam seus componentes sobre ele.

Mas se você acessar esse repositório hoje, não verá a estrutura antiga lá. Nenhum arquivo de controller familiar, nenhum código-fonte para o binário hyperkube. Para onde foi tudo isso, e por que a Red Hat mantém um projeto com quase nove mil estrelas?

Para onde foi o código-fonte do OpenShift

No verão de 2020, antes do lançamento do OpenShift 4.6, a equipe de desenvolvimento se reorganizou. A abordagem monolítica havia se tornado um obstáculo: sincronizar alterações com o Kubernetes upstream em um único lugar, junto com seus próprios testes, havia se tornado muito complicado.

Como resultado, a base de código foi dividida:

• Todo o trabalho com o fork do Kubernetes e a construção de binários como hyperkube foi movido para o repositório openshift/kubernetes.
• O repositório openshift/origin foi transformado em um hub de testes especializado.

Agora, o propósito principal do Origin é servir como lar para o binário openshift-tests e um conjunto de cenários e2e que verificam a conformidade do cluster com os padrões do OpenShift e do Kubernetes.

Como funciona o teste ponta a ponta no openshift-tests

Construir testes no projeto não tem nada a ver com executar go test regulares. Aqui, um binário openshift-tests completo é compilado, empacotado internamente com centenas de cenários de integração e e2e.

A equipe do OpenShift tem uma regra rígida para escrever testes e2e. Dois testes diferentes não devem duplicar a funcionalidade um do outro em mais de 10%. Esqueça a verificação meticulosa de cada erro de validação na API. O propósito desses testes é seguir uma jornada real do usuário do início ao fim: implantar uma aplicação, verificar se as políticas de rede funcionam, garantir que o roteamento está correto e coletar métricas.

Você pode compilar a ferramenta de teste com um único comando a partir da raiz do projeto:

make

O binário resultante pode executar tanto testes de conformidade padrão do Kubernetes quanto verificações específicas para componentes da Red Hat.

Seletores de ambiente em vez de anotações

No passado, para pular um teste incompatível em uma configuração específica de cluster, os engenheiros anexavam anotações diretamente no código Go. Isso criava caos durante as atualizações.

Nas branches modernas do Origin, as anotações foram eliminadas. Agora, a filtragem é controlada pelos chamados seletores de ambiente (environment selectors). O framework observa os parâmetros do cluster de destino antes da execução (como tipo de provedor de rede ou plataforma de nuvem) e filtra os testes inadequados em tempo real.

A lógica de exclusão é dividida em dois níveis:

• As exceções para testes padrão do Kubernetes estão localizadas em openshift/kubernetes nos arquivos environment_selectors.go e disabled_tests.go.
• As regras para testes específicos do OpenShift vivem diretamente no Origin no diretório pkg/test/extensions.

Se você está escrevendo seu próprio operador para o OpenShift, este esquema facilita entender por que um teste upstream específico não é executado no seu ambiente.

Sincronização de dependências e armadilhas do checksum do Go

Como origin depende de um fork de openshift/kubernetes, os desenvolvedores precisam constantemente atualizar os módulos Go. Para evitar fazer isso manualmente, um script hack/update-kube-vendor.sh foi adicionado ao projeto.

Você pode executar atualizações de vendor para uma branch específica ou commit SHA assim:

./hack/update-kube-vendor.sh master

O script pode puxar alterações mesmo de pull requests não mesclados. Para fazer isso, passe o endereço do seu fork como segundo argumento:

./hack/update-kube-vendor.sh my-feature-branch github.com/myname/kubernetes

Ao trabalhar com este script, é fácil encontrar um erro desagradável. O proxy de checksum do Go (sum.golang.org) às vezes retorna 410 Gone se um commit foi recém-criado e o banco de dados de checksum ainda não teve tempo de indexá-lo.

Ele se parece com isso:

go: k8s.io/[email protected] ... 410 Gone
        server response: not found

A solução aqui é simples — desabilitar à força a verificação do banco de dados de checksum durante as atualizações de vendor:

GOSUMDB=off hack/update-kube-vendor.sh master

Executando rapidamente exemplos externos

Além dos testes, um script útil hack/update-external-example.sh permanece no repositório. Ele baixa manifests de aplicações e quick starts atualizados de repositórios de ecossistema de terceiros e os coloca na pasta examples.

Se você precisa de exemplos testados de Deployment, Route ou StatefulSet para o OpenShift, vale a pena verificar a pasta examples/quickstarts — ela contém configurações verificadas.

Quem se beneficia do repositório Origin hoje

Se você apenas opera um cluster OpenShift, não precisará mergulhar no código do Origin todos os dias. Mas o projeto será de grande ajuda em três casos:

• Você está escrevendo seus próprios operadores ou extensões de plataforma e quer executar verificações e2e oficiais no seu pipeline de CI/CD.
• Você está contribuindo para o desenvolvimento do OKD ou depurando uma build personalizada do Kubernetes para hardware específico.
• Você quer ver como a arquitetura de testes de sistemas distribuídos em Go é implementada em projetos comerciais de grande escala.

O repositório é aberto sob a licença Apache 2.0, e uma comunidade ativa mantém branches para todas as versões atuais da plataforma.