JHipster-RFC-1:JHipster Kubernetes Operador

Summary

Os Operadores JHipster usam CRDs (Custom Resource Definitions)da Kubernetes para encapsular o conhecimento operacional sobre Aplicações JHipster.

Motivation

A integração com Kubernetes requer mais do que apenas o Manifesto Kubernetes para pôr os nossos contentores a funcionar dentro da plataforma.O Operador JHipster Kubernetes permitirá que JHipster MicroService Applications (projectos)seja gerido e compreendido pela plataforma de uma forma nativa.

Nota: É importante entender que a arquitetura atual do JHipster não será alterada. Um operador Kubernetes é algo que será executado em nossos aplicativos JHipster.

O Operador JHipster Kubernetes acrescenta às Aplicações JHipster existentes que funcionam em K8 todo o conhecimento operacional necessário para gerir e manter estas aplicações ao longo do tempo.

A ideia de ter um operador só faz sentido depois de ter um aplicativo rodando no Kubernetes por algum tempo. Em outras palavras, se você está procurando apenas implantar seu aplicativo, você deve usar os jhipster kubernetes ou jhipster kubernetes-helm .

Assim que a sua candidatura estiver a decorrer,surgirão questões que começarão a surgir,tais como

  • O que acontece se eu quiser implantar uma segunda (ou mais)aplicação JHipster MicroServices? Será que vai funcionar?
    • Se eu tiver duas (ou mais)candidaturas,posso partilhar o Registo JHipster entre os dois?
  • Como posso certificar-me de que todos os MicroServices que estão a compor a minha aplicação estão prontos? Como é que posso ser notificado se alguma coisa se avariar?
  • Como posso actualizar/versionar uma aplicação inteira (conjunto de microserviços)?

Com o Operador JHipster tentamos providenciar um local (componente)onde possamos responder iterativamente a todas estas questões.

JHipster K8s Operator

Note-se que todas as aplicações JHipster estão a funcionar como as conhecemos hoje dentro de um cluster K8s,e o Operador JHipster K8s senta-se no topo e com estas aplicações existentes.

Main objectives:

  • Compreender Aplicações JHipster (recurso raiz)
    • E Módulos (Gateway,MicroServices,Registo...)(recursos secundários/geridos)
    • Torna os K8s conscientes destes conceitos
  • Gerir uma ou mais aplicações JHipster
  • Compreender uma topologia de aplicação JHipster
    • Compreender como as coisas estão interligadas
    • Compreender e validar o Estado de Candidatura como um todo
  • Fornecer gestão avançada do ciclo de vida
    • Cablagem partilhada de infra-estruturas
    • Recolha de lixo/Serviços de órfãos
    • Versioning
    • Roteamento Dinâmico Avançado de Tráfego
    • A utilização de funções como parte das aplicações
    • Gerir a configuração centralizada
  • Fornecer um ponto de integração para outras extensões Kubernetes baseadas em CRD
    • Pode fornecer (ou configurar)encaminhamento hierárquico (Integração com Istio/Ingresso)
    • Pode compreender as funções KNative e integrar-se com elas
  • Fornecer um ponto de extensão para extensões específicas de domínio (JHipster Implementations)

Coisas que o Operador NÃO fará:

  • O Operador não fornecerá um mecanismo de implantação: a implantação do aplicativo deve ser feita por pipelines usando ferramentas como HELM, consulte o gerador jhipster kubernetes-helm
  • O Operador não fornecerá rotas:o operador pode configurar rotas em outros componentes,como no Istio Gateway,ou criar Ingress to an Ingress Controller
  • O Operador não lidará com ficheiros JDL,apenas consumirá os recursos despendidos para o Cluster Kubernetes
  • O Operador não alterará a actual arquitectura JHipster,apenas a aperfeiçoará de uma forma não intrusiva.

Guide-level explanation

jhipster kubernetes jhipster kubernetes-helm Operator para monitorar e gerenciar seus aplicativos JHipster MicroServices executados dentro do Kubernetes . K8s.

JHipster Flow to K8s

Depois de implementar as suas aplicações num ambiente Kubernetes pode implementar o Operador JHipster Kubernetes no seu cluster por (GUIA sobre como implementar aqui)

Assim que o Operador estiver a funcionar,poderá fazê-lo:

  1. Interagir com a Kubernetes API para obter recursos específicos JHipster,tais como Aplicações,MicroServiços,Gateways e Registos e ver as relações entre eles.Poderá descrever cada um dos recursos para obter mais detalhes sobre os serviços que estão relacionados com a aplicação
  2. Expor automaticamente aplicações com base na saúde de todos os serviços pertencentes a essa aplicação,se um serviço falhar a aplicação pode ser automaticamente escondida dos utilizadores finais.Isto pode ser conseguido através da criação de novas Entradas ou novas Rotas de Entrada para Istio
  3. Gerir múltiplas aplicações implantadas no mesmo grupo
  4. Controlar a topologia das aplicações e isolamento com outras Aplicações
  5. Partilha de infra-estruturas (Registo,SSO,talvez datastores)entre diferentes aplicações
  6. (futuro) gerenciar versões
  7. (futuro) definir SLAs para serviços e quais serviços são necessários para que um aplicativo (conjunto de microsserviços) seja íntegro
  8. (futuro) se o Istio estiver ativado, cria automaticamente rotas e regras de tráfego

Reference-level explanation

O Operador define 4 Definições de Recursos Personalizados:

  • applications.alpha.k8s.jhipster.tech
  • gateways.alpha.k8s.jhipster.tech
  • microservices.alpha.k8s.jhipster.tech
  • registries.alpha.k8s.jhipster.tech

Essas definições de CRDs podem ser encontradas aqui .

O JHipster Kubernetes Operator usará essas definições de recursos para entender, monitorar e gerenciar aplicativos implantados. Quando um aplicativo é implantado no Kubernetes, precisaremos decorar nossos descritores de serviços K8s existentes com esses recursos personalizados para que o operador entenda a estrutura do aplicativo. Essas instâncias de recursos personalizados, como JHipster Application, MicroService, Gateway, podem ser geradas com base na sintaxe JDL pelos jhipster kubernetes e jhipster kubernetes-helm .

Uma vez que estes recursos sejam utilizados como parte do procedimento normal de utilização de Kubernetes,o Operador poderá monitorizar o estado de toda a aplicação.

O Operador irá expor um conjunto de APIs para afinar o comportamento por defeito e também para expor informações relevantes,tais como:

  • Lista de aplicações disponíveis (mesma informação que é fornecida pela API da Kubernetes)
  • Detalhes de uma aplicação,serviços relacionados,estado de saúde,versão,etc.
  • Eliminar uma aplicação (todo um conjunto de serviços)
  • Expor/Esconder uma aplicação (integrando com um componente que possa encaminhar o tráfego)

Como estamos usando CRDs, poderemos perguntar às APIs do Kubernetes sobre nossos recursos JHipster usando, por exemplo, o comando kubectl .

Um aspecto importante do Operador é que ele não será responsável pela implantação de aplicações.A implantação deve ser feita por ferramentas padrão como o HELM,ou as APIs Kubernetes padrão que utilizamos após a geração dos Manifestos Kubernetes.A responsabilidade do Operador é de monitorizar e gerir as aplicações,e não de as implantar.

O Operador JHipster Kubernetes pode ser construído como um Arrancador de Bota de Primavera,o que significa que não precisa necessariamente de ser o seu próprio contentor independente,podendo ser ligado a um serviço existente,caso seja necessário.

O Operador fornecerá um excelente ponto de entrada para extensões e integrações específicas de domínio com outra plataforma de serviços de grande amplitude,tais como Istio,KNative,Jenkins X (Tekton Pipelines),etc.Irá fornecer o ponto de entrada para um fluxo de trabalho de Desenvolvedor sobre Kubernetes.

Drawbacks

Como o operador será executado dentro de um pod do Kubernetes, precisamos conceder à implantação do operador uma conta de serviço especial, funções e associações de funções para que ele possa interagir com as APIs do Kubernetes. Você pode encontrar esses manifestos extras aqui .

Um Operador Kubernetes só faz sentido se estiver a planear executar a sua candidatura em Kubernetes,para pessoas que ainda não estão lá,isto pode causar confusão.A Documentação e os guias do Operador devem explicar claramente o que e porquê o Operador está a tentar resolver estas preocupações da plataforma e as suas vantagens.

Justificação e alternativas

Construir Operadores Kubernetes é uma longa viagem.A fim de encontrar algumas melhores práticas,precisamos de iterar e melhorar enquanto aprendemos.Não temos todas as respostas neste momento,mas ter um projecto concreto vai ajudar-nos a melhorá-lo até que seja útil para toda a comunidade.

Prior art

Você pode ver aqui minha primeira tentativa aqui: https://github.com/salaboy/jhipster-operator/tree/jhipsterconf19 O arquivo README.md fornece um vislumbre dessa primeira iteração, mas depois de muito feedback, um conjunto de alterações será ser aplicado no branch master para tornar o Operator mais simples e mais focado.

Perguntas Mais Frequentes (F.A.Q.)

  • P: Isso definitivamente é legal, mas é realmente necessário para um aplicativo JHipster.
  • R : Se você estiver executando no Kubernetes, o JHipster K8s Operator fornecerá funcionalidades extras e permitirá que o Kubernetes entenda as preocupações específicas do JHipster.
  • P: Estamos reconstruindo quaisquer recursos fornecidos por ferramentas como o Istio (porque muitos dos recursos propostos são muito semelhantes ao que ele faz)
  • R : De forma alguma, estamos fornecendo um ponto de integração para ferramentas como Istio, KNative e ferramentas CI/CD baseadas em CRDs como Jenkins X e Spinnaker.
  • P: Embora um CRD JHipster seja legal, isso também significa mais vínculo com o JHipster em termos de arquitetura de implantação, isso é necessário?
  • R : Os CRDs são apenas arquivos yaml que precisamos implantar no Kubernetes e são gerados pelos jhipster kubernetes e jhipster kubernetes-helm , portanto, não estamos alterando nada em relação à nossa arquitetura de implantação. Estamos apenas decorando nosso manifesto existente com Recursos Específicos do JHipster, e essa decoração pode ser opcional. Os CRDs são encapsulados, gerenciados e instalados pela própria Operadora.

Unresolved questions

  • Como lidar com o versionamento?
  • Precisamos de alargar a informação incluída na linguagem JDL?
  • Queremos executar cada aplicação num espaço de nomes diferente? Se assim for,o Operador pode tratar e abstrair estes mapeamentos.

Future possibilities

  • Definir eventos da Nuvem de Operadores
  • Adicionar documentos OpenAPI
  • Istio integration
  • KNative integration
  • Integração de tubagens Jenkins X/Tekton PipelinesFuture JHipster Operator