O Kubernetes abstrai tudo dentro de seus limites como recursos. A parte principal é o controlador de carga de trabalho representado por Deployment e StatefulSet, e outros vários recursos funcionam em torno desses recursos principais. Combinados, esses recursos podem apresentar um modelo centrado na carga de trabalho para os técnicos de TI. Todos os recursos no Kubernetes são editados e descritos por meio de arquivos de configuração declarativa, e as definições de campo do Yaml são definidas uma a uma, o que não apenas dá aos técnicos de TI o maior grau de liberdade, mas também apresenta requisitos extremamente altos sobre a capacidade dos técnicos.
Simplifique o gerenciamento do Kubernetes com modelos de aplicativos
Quando sua equipe estiver usando o Kubernetes nativo por um tempo, você provavelmente descobrirá que nem todo técnico de TI é bom em escrever arquivos de configuração declarativa (YAML) complexos do Kubernetes. Especialmente para desenvolvedores cuja principal responsabilidade é o desenvolvimento de negócios, aprender e escrever YAML pode aumentar sua carga e até resistir a usá-lo.
O projeto de código aberto Rainbond é uma plataforma de gerenciamento de aplicativos nativa da nuvem que usa um padrão de design centrado em aplicativos. Com base nesse padrão de design, um modelo de aplicativo de nível superior à carga de trabalho é re-abstraído. Não há necessidade de aprender e escrever YAML a partir da experiência de uso e realizar o gerenciamento completo do ciclo de vida dos aplicativos de negócios. O aplicativo corresponde a um sistema de negócios completo, que consiste em vários componentes de serviço que podem ser gerenciados de forma independente.Ao implantar componentes de negócios, você pode editar o relacionamento de invocação de serviço "arrastar e soltar" do código-fonte e das imagens do contêiner. Cada componente de serviço pode definir e usar alguns recursos comuns de operação e manutenção com base na interface gráfica. Com base nisso, os usuários também podem usar o conceito central do modelo de aplicativo para realizar operações mais avançadas, como publicar todo o sistema de negócios na forma de um modelo de aplicativo, e o sistema de negócios pode ser instalado/atualizado com um clique com base em o modelo. No campo da entrega de software, esta capacidade é muito útil, seja o ambiente de entrega final on-line ou off-line, ele pode ser entregue rapidamente com base em modelos de aplicativos e até entrega personalizada.
O modelo de aplicativo usado pelo Rainbond torna mais fácil para os desenvolvedores se concentrarem no aplicativo e no próprio negócio. Os recursos de operação e manutenção retidos após o corte são exibidos e interagidos por meio de uma interface gráfica, o que reduz bastante a dificuldade de uso.Aplicando modelos, a maioria dos desenvolvedores pode usar o Kubernetes sem problemas, sem editar arquivos de configuração declarativos complexos.
Converter YAML do Kubernetes em modelo de aplicativo
Todo o processo de conversão pode ser resumido em três etapas:
- Para as cargas de trabalho mais usadas pelos desenvolvedores, elas podem ser geradas automaticamente a partir de código-fonte e imagens de contêiner de maneira semelhante a um assistente ou importando YAML existente e aplicativos em execução. O processo de importação identifica automaticamente todos os recursos do tipo de carga de trabalho conversíveis, incluindo implantação, Tipos StatefulSet, Job e CronJob. Esses recursos serão transformados em modelos de aplicativos, que serão executados como componentes de serviço.
- Depois de importar os componentes de serviço gerados, as propriedades básicas da carga de trabalho podem ser visualizadas e editadas por meio da interface, como variáveis de ambiente, endereços de espelho e assim por diante. Durante o processo de conversão, as propriedades avançadas de carga de trabalho identificadas serão adicionadas aos componentes de serviço, que podem ser visualizados e gerenciados na forma de chave/valor ou Yaml.
- Os tipos de recursos que não são de carga de trabalho, como Secret, ServiceAccount, Role e outros recursos, serão classificados, identificados e carregados na
k8s资源página para o operador editar em uma experiência interativa.
As propriedades avançadas de carga de trabalho que podem ser gerenciadas e transformadas incluem:
| nome da propriedade | efeito |
|---|---|
| seletor de nó | Seletor de nós: usado ao especificar um determinado tipo de agendamento de nós. |
| rótulos | Rótulos: Usados para personalizar rótulos para componentes de serviço a serem usados por seletores. |
| volumes | Volumes de armazenamento: montagens usadas para definir tipos de volumes que não são gerenciados pelo Rainbond. |
| volumeMounts | Volumes de montagem: Usado em conjunto com volumes para montar volumes em contêineres. |
| afinidade | Afinidade: métodos de agendamento mais avançados, incluindo afinidade de nó e afinidade de pod. |
| tolerâncias | Tolerância: Usado em conjunto com a mancha de nó, os pods com tolerância especificada podem ser agendados para nós especificados. |
| serviceAccountName | Nome da conta de serviço: especifique uma SA existente para o componente de serviço, para que o pod correspondente tenha determinadas permissões. |
| privilegiado | Modo privilegiado: Uma verdadeira configuração, não ativada a menos que seja necessário. |
| env | Variáveis de ambiente: usadas para definir variáveis de ambiente que não são gerenciadas pelo Rainbond e suportam operações de referência. |
Vale a pena notar que o modelo de RAM expandida ainda pode ser publicado como um modelo de aplicativo para instalação/atualização/entrega subsequente com um clique de todo o sistema de negócios.
Teste e prática de importação de aplicativos Kubernetes existentes
O teste a seguir é baseado no Rainbond v 5.8. Para testar a importação de aplicativos existentes no Kubernetes, pretendo wpusar o Wordpresssistema de construção de estações que foi implantado no namespace para realizar um teste de importação. O sistema é composto pelos seguintes recursos:
[root@localhost ~]# kubectl get secret,service,deployment,statefulset,pod -n wp
NAME TYPE DATA AGE
secret/default-token-nq5rs kubernetes.io/service-account-token 3 27m
secret/mysql-secret Opaque 2 27m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/wordpress NodePort 10.43.157.40 <none> 8080:30001/TCP 5m19s
service/wp-mysql ClusterIP 10.43.132.223 <none> 3306/TCP 27m
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/wordpress 1/1 1 1 5m19s
NAME READY AGE
statefulset.apps/wp-mysql 1/1 27m
NAME READY STATUS RESTARTS AGE
pod/wordpress-66bc999449-qv97v 1/1 Running 0 5m19s
pod/wp-mysql-0 1/1 Running 0 27m
Visite Rainbond e selecione Importar no cluster Nesta página, você pode selecionar o namespace para importar recursos wp. A plataforma agrupará os recursos de acordo com os rótulos:
O Rainbond divide os aplicativos de acordo labelcom . Por exemplo, recursos que correspondem ouapp.kubernetes.io/name:wp-mysql serão distribuídos para dois aplicativos diferentes na figura. Se os recursos acima não estiverem disponíveis, eles serão divididos uniformemente em um aplicativo desagrupado. A divisão de aplicativos é muito crítica, pois a aplicação avançada do modelo de aplicativo é para um aplicativo como um todo, portanto, você deve planejar cuidadosamente antes de importar e adicionar outros razoáveis .app:wordpresslabellabel
Durante o processo de importação, Rainbond atribui diferentes propriedades ao modelo estendido para gerenciamento.A maioria das operações de operação e manutenção se tornou muito fácil de usar, enquanto a outra parte é gerenciada pela página de propriedades do Kubernetes.
Uma vez importado, ambos oswordpress aplicativos podem ser gerenciados usando o Rainbond.wp-mysql
- gestão portuária
wordpressAntes de importar, confie no NodePorttipo de Serviceexposição externa, mas depois de importar o gerenciamento do Rainbond, você pode usar o gateway para expor sua própria porta 80 ao mundo exterior. Observe que você deve reiniciar o componente de wordpressserviço para que a política de acesso entre em vigor.
Para alguns serviços, a entrada de acesso não oferece suporte à designação dinâmica, o que requer algumas alterações no lado comercial para se adaptar à nova entrada de acesso. WordpressPara , o endereço do site nas opções gerais precisa ser redefinido.
- Gerenciamento de armazenamento
O wordpresssistema usa o hostpathmodo de armazenamento para todos os componentes. Embora essa configuração seja simples, ela não é adequada para ambientes Kubernetes de grande escala Podque podem derivar. Depois que o Rainbond for implantado, ele fornecerá armazenamento compartilhado fácil de usar, que oferece suporte ao compartilhamento de dados entre vários Pods e migração de Pods entre hosts. O armazenamento original do hostpath pode ser redefinido. O caminho de armazenamento redefinido ficará vazio, portanto, lembre-se de localizar os caminhos novos e antigos e realizar uma migração de dados.
significado prático
Por meio do modelo de aplicativo, os técnicos de TI podem prestar mais atenção ao negócio em si, em vez do uso das ferramentas complexas subjacentes. O efeito final é simplificar o custo de operação e a dificuldade de compreensão e tornar o Kubernetes mais fácil de implementar.