[Registro do ambiente de produção K8S da construção à operação e manutenção (4)] Cluster Kubernetes

[Registro do ambiente de produção K8S da construção à operação e manutenção (4)] Projeto do cluster Kubernetes

1. Introdução

O Cluster Kubernetes é, sem dúvida, o protagonista do nosso sistema, afinal, nossos serviços devem ser executados nele. Portanto, é muito importante planejar bem antes de criar um cluster do kubernetes. Desta vez, falaremos sobre o que considerar ao projetar o cluster do Kubernetes.

2. Um cluster Kubernetes simples

Primeiro, vamos primeiro examinar a composição de um cluster do Kubernetes de criação de grupos.
Insira a descrição da imagem aqui
Neste Cluster, é óbvio que existem 3 Mestres e 5 Nós, todos eles números ímpares. A razão pela qual os números ímpares são usados não é explicada aqui. Se não souber, pode pesquisar online. Você também pode ver que há muitos recursos básicos do Kubenetes em execução no mestre e no nó. Vamos analisá-lo em detalhes abaixo.

2-1. A composição de Mestre e Nó

Mestre: três
mestres são essenciais como o centro de controle de todo o cluster e devem ser agrupados no ambiente de produção. Quanto ao número de unidades, pelo menos um número ímpar de unidades com mais de 3 também.
Nó:
como a operadora para fornecermos o Pod de serviço, 5 nós não podem dar errado. Eles devem ser agrupados no ambiente de produção. Quanto aos demais, será decidido de acordo com suas reais necessidades, podendo ser 3 ou dezenas.

2-2.Recurso Kubenetes

Eu divido os recursos em execução no Master e no Node em três categorias:

Recurso de aplicativo Recurso de
aplicativo refere-se principalmente ao recurso de serviço que fornecemos, Recurso de pod de serviço e serviço de exposição. Eles são programados para serem executados em cada nó por meio de implantação, daemonset e outros controladores para fornecer nossos serviços externamente.
O Application Resource não recomenda executar no Master, porque a função do Master não é executar nossos serviços. Ele é usado para gerenciar todo o nosso Cluster Kubenetes para garantir a operação normal do Cluster Kubenetes. Normalmente a configuração do Master não é muito alta, por isso não é adequado para uso como portador do nosso serviço. Em termos leigos: o mestre está dentro, Node está fora.
A
principal função do Control Resource Control Resource é melhorar a confiabilidade dos serviços de Pod através de HPA, quota, limitaRange e outros recursos, para que nosso serviço não desligue devido à alta carga, e não use muita CPU devido a bugs em nosso programa. Recursos como memória fazem o Node travar. Além disso, as permissões podem ser gerenciadas por meio de Recursos como ServiceAccount, Role, etc., para evitar o uso indevido de permissões e erros de operação e, indiretamente, proteger nossos serviços. Além disso, esses recursos não devem ser executados no Master.
Monitor Resource
Monitor Resource é fácil de entender, que serve para monitorar e coletar informações em nosso cluster, nó e pod do Kubenetes. O monitoramento é para que possamos notificar o pessoal relevante a tempo quando houver uma falha no sistema ou no serviço. A coleta de informações é para nós analisarmos as informações, determinar a integridade do sistema e prever os problemas futuros do sistema, e também conduzir as informações de negócios A análise pode criar valor comercial.

O exemplo acima é apenas um diagrama de estrutura simples do cluster do Kubernetes, então como podemos projetar um sistema para o ambiente de produção? O que devemos considerar ao projetar o cluster do Kubenetes? A seguir, vamos falar sobre isso. .

3. Elementos de design de cluster de Kubenetes

Comece principalmente com os requisitos não funcionais, classifique todos os requisitos não funcionais, encontre uma solução para cada requisito e, em seguida, reflita-a no design.

Vamos falar sobre como projetar para cada requisito não funcional ao projetar o sistema Kubernetes.

[Confiabilidade] Facilidade de recuperação e tolerância a falhas;
um sistema robusto deve ter tolerância a falhas e resiliência. Quando uma determinada parte do sistema falha, o serviço geral do sistema não será interrompido; o ponto de falha pode ser restaurado rapidamente por meio do plano de recuperação preparado com antecedência, e o usuário do sistema não ficará ciente da ocorrência durante todo o processo. De tudo isso. Para atingir os requisitos de confiabilidade do sistema, as contramedidas usuais incluem redundância, backup e restauração, monitoramento e alarme e um sistema de resposta 24 horas.
Como implementar essas contramedidas de confiabilidade no ambiente de produção do cluster do Kubernetes, vamos analisá-las uma por uma.

Redundância
No diagrama de composição acima, pode ser visto intuitivamente que o Mestre e o Nó estão configurados em um modo de cluster, e o Pod em execução no Cluster também é uma configuração detalhada, mas só isso não é suficiente. Precisamos descobrir todos os lugares onde pontos únicos de falha podem ocorrer e, em seguida, perceber a redundância por meio das soluções técnicas correspondentes. O comprimento de todas as linhas de rede, o comprimento dos equipamentos de rede, como interruptores, e o comprimento dos dispositivos de distribuição de carga que geralmente são fáceis de serem ignorados. Espere, desde que seja qualquer local e equipamento relacionado ao nosso sistema, devemos considerar se precisamos atingir a verbosidade. Se for para usar serviços em nuvem, a operadora vai implementar a redundância da infraestrutura para nós, para que possamos reduzir muito trabalho. Além disso, a separação e desacoplamento de nosso negócio também pode melhorar indiretamente a confiabilidade do sistema em certa medida.

classificação	Componente longo
servidor	mestre
	Nó
a infraestrutura	Linha de rede
	Equipamento de rede (interruptores, distribuição de carga)
	Dispositivo de armazenamento
Serviço comercial	Normalmente pods no Kubernetes
de outros	Todas as partes relacionadas ao sistema

Muitas falhas de backup e restauração são causadas por nossas operações humanas, como exclusão acidental de dados, erros na publicação de conteúdo. Essas falhas geralmente são fáceis de localizar a causa. Precisamos apenas restaurar dados e reversões de versão para obter a recuperação da falha. . Mas eles se baseiam em nossa visão e preparação de longo alcance - a saber, backup e gerenciamento de versão, que desempenham um papel vital na proteção do sistema. Normalmente precisa fazer backup do sistema operacional geral, backup de dados de banco de dados, backup de arquivos de negócios importantes. No ambiente de produção do cluster do Kubernetes, você precisa fazer backup do etcd, que contém informações importantes sobre o cluster, bem como o backup do mestre e do nó. Se você usar as ferramentas de gerenciamento do Kubernetes de que falamos no capítulo Sistema de controle antes, você não precisa fazer o backup do mestre. E o próprio Node, como a ferramenta registra as informações completas do seu Cluster, ela pode restaurar todo o Cluster quando necessário. Além disso, há minha imagem Docker e gráfico do Helm, etc.

classificação	Parte de backup
Grupo	mestre
	Nó
	dados etcd
Serviço comercial	Imagem Docker
	Carta de leme
	Dados comerciais, documentos comerciais, etc.
	Registro

Alarme de monitoramento
Quando o sistema falha, é muito importante descobrir e notificar o pessoal relevante na primeira vez, para que os técnicos possam intervir a tempo de evitar que a falha se expanda. Introduzimos o sistema de monitoramento em detalhes no Capítulo 3. Não há mais explicação aqui.
Sistema de resposta 24 horas Após a
ocorrência de uma falha, o pessoal técnico deve intervir o mais rápido possível e resolver a falha o mais rápido possível, então precisamos formar uma equipe de operação e manutenção em standby 24 horas. A equipe de operação e manutenção acompanha nosso sistema em todos os momentos.

2 [Requisitos de desempenho] Tempo de resposta, rendimento, utilização de recursos;
tempo de resposta e rendimento são os principais indicadores para medir um sistema. Costuma-se dizer que "não aceite trabalho em porcelana sem o diamante", temos que fazer coisas ao projetar o sistema Para descobrir a pressão que nosso sistema enfrentará no futuro, como o requisito de tempo de resposta de um único processamento, o requisito do volume máximo de acesso por unidade de tempo, o requisito do volume máximo de processamento por unidade de tempo e assim por diante. Depois de classificar esses requisitos, ao projetar o sistema, determinamos o número de servidores, configuração do servidor, largura de banda da rede, capacidade de armazenamento, algoritmo de distribuição de carga e se devemos usar cache e outras tecnologias com base nesses requisitos ao projetar o sistema. Dessa forma, o sistema que construímos é apenas um Um sistema saudável que pode atender aos requisitos de desempenho.

3 [Segurança] Confidencialidade, anti-vazamento, controle de acesso e anti-ataque; a
segurança exige que o sistema tenha uma solução de defesa de segurança eficaz e estratégia de controle de acesso para evitar o vazamento de informações confidenciais do sistema e acesso impróprio. Ao projetar, geralmente estou disposto a dividi-lo em considerações externas e internas. Ambas as contramedidas internas e externas são basicamente semelhantes. A tabela a seguir apresenta as contramedidas de segurança usuais.

classificação	Contramedida	Descrição
Externo	Ferramenta de segurança de vírus	Impedir vírus e ataques externos
	Certificação	Impedir o acesso não autorizado de fora
	Isolamento de rede	Esconda a parte sensível
interno	Ferramenta de segurança de vírus	Impedir vírus de dentro
	Controle de acesso	Nível de autoridade para evitar vazamento de informações ou operação indevida devido a autoridade excessiva
	Servidor de entrada único	Uma forma de isolamento interno, outros servidores no sistema que só podem ser acessados através do servidor de entrada, para facilitar o monitoramento da operação e gerenciamento de autoridade

4 [Escalabilidade] A expansão horizontal e a expansão vertical
são geralmente fáceis de entender, incluindo a expansão do número de servidores, a expansão da CPU, memória, armazenamento, expansão de serviços, etc., mas a diferença no cluster do Kubernetes é que tudo Os requisitos de expansão devem ser concluídos automaticamente, sem intervenção manual. Somente assim as vantagens do Kubenetes podem ser refletidas. Ao projetar o cluster do Kubernetes, devemos pelo menos considerar os requisitos de expansão na tabela a seguir.

classificação	Conteúdo expandido	Automático / não automático
Autoescalador de cluster	Expansão horizontal do cluster	Automático (requer suporte de terceiros, como serviços em nuvem)
	Expansão de cluster vertical	Automático (requer suporte de terceiros, como serviços em nuvem)
no autoescalador	Expansão horizontal	HPA automático
	Expansão vertical	VPA automático (mas não recomendado)

5 [Manutenibilidade] Modularidade, reutilização e fácil análise;
após o lançamento oficial do sistema, entrará na fase de operação e manutenção, que será sempre acompanhada por todo o ciclo de vida do sistema, para que um sistema de fácil manutenção possa ser Reduzir a carga de trabalho do pessoal de operação e manutenção e a probabilidade de operação incorreta é equivalente a melhorar indiretamente a confiabilidade do sistema. Como a composição do sistema Kubenetes é basicamente fixa, tanto na forma de mestre quanto de nó, para a conveniência de manter o sistema Kubernetes no futuro, as principais considerações são a capacidade de reutilização e a fácil análise. A tabela a seguir visa obter contra-medidas reutilizáveis e fáceis de analisar.

classificação	Projetar contramedidas	Descrição
Reutilizável	Configure um ambiente de teste	O mesmo ambiente que o ambiente de produção equivale a reutilizar o ambiente de produção, o que é uma garantia importante para a redução de falhas no ambiente de produção
	Use ferramentas de gerenciamento de terceiros	Ferramentas como o Pivotal, que mencionamos nos capítulos anteriores, podem nos ajudar a concluir tarefas repetitivas de gerenciamento do KubernetesCluster.
	Rico manual	Problemas e falhas repetidos ou semelhantes, escreva-os no manual e você poderá usá-los diretamente no futuro
Fácil de analisar	Informações de projeto detalhadas e fáceis de entender	Os diagramas da estrutura do sistema e outros materiais de design são materiais de referência importantes para operação e manutenção futuras
	Colete informações de registro válidas	Colete informações de log eficazes e completas para nós por meio do sistema de coleta de informações de log para análise

4. Resumo

Não importa que tipo de sistema você está projetando, você precisa classificar e analisar os requisitos não funcionais antes de projetar, encontrar soluções correspondentes para cada requisito não funcional e, em seguida, refletir essas soluções em seu projeto, para que o sistema projetado seja seguro É um sistema saudável. Claro, não é fácil classificar e analisar os requisitos não funcionais e encontrar as soluções correspondentes. Os designers precisam ter conhecimento técnico e experiência em design suficiente. Somente através de experiência em projetos de longo prazo e acúmulo de conhecimento técnico é possível Alcance um designer de estrutura de sistema real.

Autor: rm *
Data do Grupo : 12 de setembro de 2020