Por que uma caixa de papelão é o maior inimigo do Edge Kubernetes

É hora de uma verdade sobre como fazer computação de ponta: a única coisa que provavelmente destruirá seu projeto Kubernetes de ponta é uma caixa de papelão marrom.

“Huh?” Eu ouço você dizer. Bem, pegue sua pipoca e incline-se porque as coisas estão prestes a ficar reais.

A comunidade Cloud Native sabe o suficiente sobre logística?

Passamos mais de uma década contentorizando e migrando para a nuvem (e ainda estamos nisso).

O toque de sirene que impulsiona esta missão é a velocidade de execução: concentre-se no seu caso de negócios e no seu software, e não se preocupe com a infraestrutura. O software está devorando o mundo; é onde está o valor. É onde está a inovação. É onde você deve prestar mais atenção.

Por infraestrutura, quero dizer todos os servidores, redes e armazenamento que são abstraídos, cuidados por pessoas trabalhadoras que fazem mágica com a qual você não precisa mais se preocupar.

Todos nós temos nos concentrado tanto em lindos GitOps, cadeias de suprimentos de software, infraestrutura como código e uma série de outras coisas. Quando se trata de nossos aplicativos na nuvem, a infraestrutura é apenas algo no final de uma API. Estalamos os dedos e ele está lá.

Por outro lado, de repente temos que nos preocupar novamente com coisas não abstratas. A coisa real: hardware.

Existem grupos por aí que nunca esqueceram o quão importante é o hardware, é claro.

• Eles são os provedores de serviços de comunicação que constroem estações base em remotas ilhas escocesas e instalam cabos submarinos.
• São as empresas de IoT que se preocupam com as classificações de proteção de entrada quando aparafusam caixas de sensores reforçadas em plataformas de petróleo.
• Eles são as empresas SD-WAN (rede de área ampla definida por software) ou SASE (borda de serviço de acesso seguro) que conectam cabos entre racks em pontos de presença locais.

O Edge Kubernetes é, em certo sentido, um casamento entre nossos preciosos paradigmas nativos da nuvem e esse bom e velho ferro.

Então, o que podemos aprender com os grupos que sabem tudo sobre hardware?

O hardware é difícil e a falha é a norma, não a exceção

Qualquer pessoa envolvida na manutenção de servidores ou frotas de dispositivos na borda dirá a mesma coisa: as falhas de hardware são normais.

Tudo se resume a estatísticas. Pegue um Intel NUC (Next Unit of Computing) padrão ou um servidor compacto normalmente direcionado para uso na borda. É composto por vários componentes discretos: CPU, RAM, disco rígido ou SSD, ventiladores, fonte de alimentação e muito mais, cada um com redundância mínima, diferentemente do que estamos acostumados em um data center.

Agora imagine uma frota de 10 mil desses pequenos dispositivos. Isso significa 10.000 ou mais de cada um desses componentes, cada um com um MTBF (tempo médio entre falhas) classificado.

Aproveitando ao máximo o MTBF

O MTBF se torna uma das principais variáveis ​​na equação para determinar se a implantação do Edge K8s ganha ou perde dinheiro, em termos de tempo de inatividade e custo de hardware e mão de obra. Portanto, vale a pena você entender como aproveitar ao máximo.

Claro, você pode adquirir componentes com melhor confiabilidade, mas isso aumenta o custo e pode não ser viável para os requisitos do seu projeto. Você pode incorporar redundância, mas isso novamente aumenta os custos e pode levá-lo além do espaço, energia e refrigeração do seu local de borda.

Você pode fazer o que puder para controlar o meio ambiente. O MTBF pode ser agravado por condições operacionais abaixo do ideal em locais periféricos hostis. Talvez o gerente da loja de varejo goste de empilhar papelada em cima do miniservidor e bloquear as aberturas de ventilação. Diga-lhes para não fazerem isso, é claro, mas os humanos serão humanos.

Portanto, você também deve planejar o monitoramento de componentes de hardware comuns, mas cruciais, como ventiladores e unidades de fonte de alimentação, juntamente com os aplicativos em execução em sua pilha de borda. Eles são igualmente cruciais. As caixas esquentando devem gerar alertas e ser utilizadas para tomar medidas proativas. Essas coisas devem ser incluídas em qualquer sistema Kubernetes de ponta holístico e sair da caixa junto com regras de alerta sensatas.

Se você espera que a implantação de seu dispositivo de borda seja “pronta e pronta”, você terá um rude despertar.

O software também pode afetar o MTBF. Coisas mundanas, como a forma como a pilha do Kubernetes lê e grava comportamentos como registro, podem matar rapidamente um SSD, e ajustar o comportamento do aplicativo não pode evitá-lo completamente.

O resultado é o seguinte: embora as probabilidades de uma única unidade falhar num determinado dia sejam muito baixas, quando há unidades suficientes, pode-se praticamente garantir que uma delas cairá… hoje, amanhã e no dia seguinte. Seria normal ter várias falhas de dispositivos todas as semanas.

Portanto, se você espera que a implantação de seu dispositivo de borda seja “pronta”, você terá um rude despertar.

Planejar falhas de hardware e como lidar com essas falhas de maneira eficiente é o nome do jogo para que seu cálculo de retorno do investimento pareça bom.

Logística e armazenamento de peças sobressalentes: mais complexo do que você imagina

Para ser bom no tratamento de falhas, é necessário pensar em logística e, especificamente, responder à pergunta: quando um nó falha, como faço para trocar um nó sobressalente e colocá-lo em funcionamento rapidamente?

Obviamente, não é econômico manter um conjunto completo de hardware sobressalente para cada dispositivo implantado e, certamente, não no local para uma troca a quente. Seu pessoal financeiro ficaria furioso se gastasse tanto dinheiro em estoque, e muitas vezes não há espaço ou segurança em locais remotos.

Portanto, em vez disso, precisamos armazenar um conjunto menor de peças sobressalentes em estoque em outro lugar — armazéns centrais ou centros de distribuição regionais — e enviá-las para o local de borda afetado quando necessário.

Não sou um especialista em modelo de Markov, mas a quantidade ideal de hardware necessária para ser armazenado centralmente/regionalmente pode ser calculada principalmente com base nas taxas de falha previstas dos dispositivos e no MTTR (tempo médio para restauração/recuperação). Um processo mais eficiente para substituição de dispositivos reduz o MTTR, o que, por sua vez, reduz o número de peças sobressalentes necessárias no armazenamento.

Não importa quantas peças sobressalentes você mantenha, elas também não podem ser enviadas diretamente do fornecedor – embora você possa estar acostumado a fazer isso para dispositivos de usuário final ou equipamentos de computação e rede de data center, que podem ser configurados por um on-line. – equipe local no destino.

Locais periféricos, como restaurantes ou turbinas eólicas, não terão um especialista em TI para instalar sistemas operacionais e configurar a pilha K8s no local, e você certamente não quer que seus ninjas K8s bem remunerados dirijam por seis horas para uma instalação remota diferente a cada dia com um chaveiro cheio de pen drives e um teclado e monitor no banco de trás.

O hardware precisa ser preparado até certo ponto em algum lugar centralizado, pré-carregado com um sistema operacional e software para que, quando ligado, possa ingressar no cluster K8s e começar a funcionar.

Ainda comigo? Tem mais

Mas mesmo aqui estamos apenas arranhando a superfície da complexidade que você precisa projetar ao construir um processo de peças sobressalentes para uma implantação de borda de produção do Kubernetes.

Diferentes destinos de implantação (por exemplo, uma pequena filial de varejo versus uma megaloja) podem ter cargas de trabalho diferentes, o que significa que são emitidos com uma variante de dispositivo diferente e uma pilha de software diferente.

Certos elementos da configuração do dispositivo serão sempre específicos do site, como segredos, endereços IP e configurações de rede.

Na verdade, independentemente dessa variação de hardware, certos elementos da configuração do dispositivo serão sempre específicos do local: segredos, endereços IP e configurações de rede, dados do usuário relacionados à localização no dispositivo, etc.

Como resultado, você simplesmente não pode preparar totalmente o dispositivo sobressalente até saber exatamente para qual local esse dispositivo está indo – e, por definição, isso acontecerá depois que um dispositivo de borda de missão crítica já tiver falhado e a pressão estiver alta.

Então, estamos construindo uma lista de requisitos:

• Se falhas ocorrerem diariamente, o processo de preparação e as ferramentas para preparação do dispositivo precisam ser simples, leves e capazes de serem automatizados.
• Se o provisionamento sobressalente for acionado apenas por uma falha de missão crítica, todo o processo deverá acontecer de forma rápida e consistente, com poucas etapas manuais.
• Se não pudermos enviar engenheiros para cada local, precisaremos da capacidade de propagar dispositivos de forma segura com as informações necessárias para que eles se juntem a um cluster – e para solucionar problemas remotamente e observar o status dos dispositivos depois que eles forem ligados em um local, antes e durante a tentativa de ingressar ou formar um cluster.
• Se mantivermos uma proporção de 1:x peças sobressalentes por local ativo, precisaremos da capacidade de fornecer informações específicas do local o mais tarde possível na cadeia logística, para permitir que todos os dispositivos armazenados sejam homogêneos em termos de configuração de software.
• Se não podemos contar com hardware totalmente intercambiável (porque temos variantes), não deveríamos exigir o pré-provisionamento de diferentes funções, como um nó mestre ou um nó de trabalho, rótulos para GPUs, etc. Isso deve ser detectado automaticamente e atribuído dinamicamente quando um dispositivo chega a um local e está pronto para formar ou ingressar em um cluster. Sem isso, é necessário envolvimento humano adicional durante a preparação ou durante a integração e introduz mais espaço para erros.

Protegendo suas caixas de papelão marrom

Na Spectro Cloud, falamos muito sobre segurança do Kubernetes e, em particular, segurança de dispositivos de ponta. Imaginamos a adulteração deliberada e o ataque de dispositivos de ponta in situ, por agressores mascarados.

Mas, como qualquer pessoa que encomendou um presente caro para um ente querido sabe, o maior risco é o “encolhimento” da cadeia de abastecimento: quando uma caixa castanha desaparece misteriosamente do radar algures depois de ser despachada.

Você precisa levar isso em conta, e não apenas escolhendo um parceiro logístico confiável para operar seu armazém e entregar suas encomendas.

Seus dispositivos de borda — especialmente porque foram pré-configurados com dados! — precisam ser criptografados, com o uso de Trusted Platform Modules para inicialização segura, recursos de limpeza remota e todos os outros recursos de proteção que você puder encontrar.

Um dispositivo perdido ou roubado deve ser sinalizado em vermelho para que não possa ingressar no cluster corporativo, e um agressor certamente não deve ser capaz de apenas carregar seus dados debaixo do braço.

Chamada de despertar oficialmente encerrada

Se ao menos o meatspace fosse tão fácil de orquestrar quanto nossas abstrações nativas da nuvem, não é? Mas a realidade é que essa vantagem é muito física. Trata-se de caixas zumbindo instaladas em armários, embaixo de mesas, em milhares de locais esquecidos que apenas um motorista de entrega assobiando ou um cara com colete de alta visibilidade poderá ver.

Se o seu projeto de ponta quiser passar com sucesso de um piloto para uma produção de missão crítica em escala, você precisa pensar em ventiladores com defeito, pilhas de caixas em armazéns e tudo o que precisa acontecer para levá-los de A a B quando cada segundo conta .

Precisa de alguma ajuda?

Estamos criando recursos em nossa plataforma de gerenciamento Palette Edge Kubernetes para lidar com esses tipos de cenários.

Por exemplo, o Palette oferece criptografia de dados persistente e sistemas operacionais imutáveis ​​para resolver questões de segurança, como adulteração e roubo.

O mais interessante é que fizemos grandes avanços na preparação e no provisionamento de dispositivos de borda em locais de borda remotos por meio de recursos como registro automático para implantação sem cabeça, integração de código QR com baixo toque e monitoramento remoto estilo centro de operações de rede (NOC). Para uma rápida visão geral de como tudo isso funciona, assista meu colega Justin Barksdale explicar tudo neste vídeo de 25 minutos. É muito legal.

Se você quiser falar sobre o que aprendemos e seus próprios projetos de ponta, entre em contato conosco. Ou para ler mais sobre Edge Kubernetes, confira nosso hub de recursos Edge.

A postagem Por que uma caixa de papelão é o maior inimigo do Edge Kubernetes apareceu pela primeira vez no The New Stack.