Não simplifique este código

Controlador de volumes persistentes do Kubernetes

Visão geral

• Controlador que sincroniza PersistentVolume (PV) e PersistentVolumeClaim (PVC) do Kubernetes
• Gerencia "ponteiros" bidirecionais entre PVC e PV para evitar perda de dados
• Opera em modo de alta disponibilidade e oferece suporte quando um PVC solicita um PV específico ou quando um PV está reservado para um PVC específico

Principais funcionalidades

• Sincroniza periodicamente o estado de PVCs e PVs
• Quando o PVC não solicita um PV específico, encontra o PV mais adequado e faz o binding
• Quando o PVC solicita um PV específico, verifica se esse PV existe e atende às condições antes de fazer o binding
• Quando o PVC já está vinculado, verifica o estado e corrige se necessário

Como funciona

• Quando um PVC é criado ou atualizado, o método syncClaim é chamado
• Se o PVC não estiver vinculado, o método syncUnboundClaim é chamado
• Se o PVC estiver vinculado, o método syncBoundClaim é chamado
• Quando um PV é criado ou atualizado, o método syncVolume é chamado

Métodos principais

syncClaim

• Chama syncUnboundClaim ou syncBoundClaim de acordo com o estado do PVC

syncUnboundClaim

• Quando o PVC não solicita um PV específico, tenta encontrar o PV mais adequado e fazer o binding
• Quando o PVC solicita um PV específico, verifica se esse PV existe e atende às condições antes de fazer o binding

syncBoundClaim

• Quando o PVC já está vinculado, verifica o estado e corrige se necessário

syncVolume

• Executa a ação apropriada de acordo com o estado do PV
• Se o PV não estiver em uso, atualiza o estado para "Available"
• Se o PV estiver vinculado a um PVC específico, verifica o estado desse PVC e corrige se necessário

Resumo do GN⁺

• Este documento fornece uma explicação detalhada do controlador de volumes persistentes do Kubernetes
• Ajuda a entender a lógica de binding entre volumes persistentes e persistent volume claims
• Aborda o funcionamento em modo de alta disponibilidade e o tratamento de várias situações excepcionais
• Material útil para desenvolvedores interessados no gerenciamento de armazenamento no Kubernetes
• Outros projetos com funcionalidades semelhantes incluem OpenEBS e Rook

[GN⁺]

Comentário do Hacker News

• O software do Space Shuttle é extremamente estável e quase não tem bugs

  • As três versões mais recentes tiveram apenas um único erro cada em 420.000 linhas
  • Em comparação com programas comerciais, o número de erros é muito baixo

• O código é genérico e, por ter sido escrito em Go, é um tanto verboso

  • Isso pode ser uma sensação de quem tem muita experiência com software corporativo e percebe a diferença em relação a software de sistemas
  • Para contribuidores do projeto k8s, pode haver comentários desnecessários em excesso

• Foi prazeroso explorar o codebase da nova empresa porque ele está bem organizado

  • Há muitos comentários, e o código é bem estruturado
  • Como é uma equipe pequena, a qualidade do código é alta

• O histórico de segurança do Space Shuttle não é bom, por isso ele não está mais em operação

  • Fica a dúvida se, daqui a 10 anos, as pessoas ainda se lembrarão do Space Shuttle de forma positiva

• Usar correspondência estrutural de padrões poderia simplificar blocos if/else

  • Existem ferramentas que verificam em tempo de compilação se a correspondência está completa

• O código não é ruim e segue uma única regra

  • É muito melhor do que código com estilos variados

• Link para uma discussão de 2018

• Foi divertido escrever um driver CSI do Kubernetes

  • Os drivers CSI de EFS e EBS da Amazon são bons exemplos de codebases pequenos
  • O driver em si é simples, mas inclui lógica complexa

• Ter uma cláusula else para cada instrução if é considerado uma prática de segurança

  • Módulos de 2.000 linhas e métodos de 200 linhas são prejudiciais
  • Comentários que explicam o que o código faz não são úteis

• É mostrado como criar links para intervalos específicos de linhas em arquivos no GitHub