Na etapa de Pasadena do Kubernetes Community Days (co-localizado com o SCaLE 20x), tive a chance de conversar com cerca de 100 entusiastas , para dar minha perspectiva sobre o WebAssembly, pelas lentes de um veterano do Kubernetes. do Kubernetes Devo qualificar isso dizendo que tenho pele neste jogo em particular. Estou no Kubernetes desde o início - começando cedo com (0.6-ish) e trabalhando com Kubernetes desde 1.2 - construindo plataformas Kubernetes antes de serem uma coisa. Fui o principal mantenedor do Helm por 4 anos e co-criador do Bindle e do Krustlet - um esforço inicial para fazer o WebAssembly funcionar bem com o Kubernetes. Uma maneira longa de dizer que entendo totalmente, entendo os pontos fortes e os pontos problemáticos dos contêineres e do Kubernetes. o Docker Eu também venho do espaço WebAssembly, profundamente envolvido nos últimos 3 anos ou mais. Com os pés em ambos os campos, aqui está minha opinião sobre o que essas duas iniciativas abertas são boas e como a interseção poderia - e deveria - parecer. O Kubernetes e o Docker mudaram o jogo porque permitiram que engenheiros e desenvolvedores de plataforma dividissem o monólito em microsserviços e aplicativos, gerenciáveis isoladamente do restante da infraestrutura. O WebAssembly vai um nível mais profundo, permitindo-nos dividir aplicativos individuais em componentes combináveis que podem ser trocados, gerenciados e configurados separadamente para seus arredores. Wasm é, essencialmente, tudo o que queremos em código do lado do servidor: seguro por padrão, portátil, poliglota (particularmente no navegador), rápido, eficiente e altamente escalável. Então, como Kubernetes e Wasm se cruzam? Primeiro, vamos abordar o boato da mídia social e acabar com alguns mitos. Mito nº 1: Wasm matará contêineres. Não. Definitivamente não. Ninguém vai reescrever para funcionar no navegador quando ele funciona bem em contêineres. Existem muitos casos em que o Kubernetes é a solução certa. Existem vários aplicativos corporativos grandes (Drupal, Redis, nginx) que existem há muito tempo e que não serão transferidos para o Wasm tão cedo. o Redis Mito nº 2: devo seguir em frente e executar o Wasm em meus contêineres, certo? Não estamos dizendo que você não deveria, mas pode não ser o ponto de partida certo e você pode apenas adicionar camadas extras de complexidade. Você tem a sobrecarga de iniciar o contêiner do Docker (que não é multiplataforma), adicionada à sobrecarga de iniciar o WebAssembly. Provavelmente não vale a pena a sobrecarga de desempenho, especialmente com todas as ferramentas disponíveis que mencionarei mais tarde] Mito nº 3: Wasm não é compatível com o Kubernetes. É sim! Esta é uma história "Better Together". Tudo é evolutivo com computadores. Só porque criamos VMs não significa que não precisamos de hardware físico. E só porque Wasm apareceu, não significa que não precisamos de contêineres. Para ver isso em ação, leia como nossos amigos da Adobe . estão transformando sua arquitetura Kubernetes com Wasm Como nos primeiros dias do Kubernetes, estamos naquela fase em que as coisas estão quebrando e evoluindo muito rapidamente. A rede ainda é difícil no lado do servidor no nível bruto do Wasm. Em breve, obteremos suporte a soquetes e as coisas estão se movendo rapidamente. Cadeias de ferramentas de linguagem e código de desempenho de baixo nível também são cruciais, mas ainda não estão lá. É um momento emocionante, no entanto. Os padrões WASI (não-browser Wasm) percorreram um longo caminho, mesmo nas últimas semanas - mais sobre isso depois. Por que Wasm ? A verdade é que . Embora muito progresso tenha sido feito (grande mensagem para projetos como o K3s), há apenas um limite para as coisas. O Kubernetes deve ser executado em clusters que geralmente fazem parte da mesma região geográfica. Quando algo está sendo executado em uma torre de celular, estação de energia ou loja física, o Kubernetes não escala muito bem. Vimos isso quando conversamos com os membros da nossa comunidade. O Wasm é verdadeiramente uma arquitetura multiplataforma e é muito pequeno, tornando-o um candidato melhor para o edge. o Kubernetes tem seus limites, principalmente na borda . Conversamos com várias empresas da Fortune 100 e a utilização do servidor Kubernetes fica em torno de 25 a 35% da capacidade total, com algumas subindo para 50 a 60%. Muitos reduziram suas equipes internas do Kubernetes porque é muito caro. Wasm nos permite embalar muito mais em um espaço menor e obter uma melhor utilização dele. Custo e utilização também são fatores importantes é um grande benefício do Wasm. Os contêineres são bastante seguros, mas há muitas nuances que criam complexidade, principalmente para desenvolvedores. Por padrão, um módulo WebAssembly não pode fazer nada, a menos que você conceda a ele o privilégio de fazê-lo. A segurança também O que podemos fazer com Kubernetes e Wasm agora ? Com tudo isso dito, o que é realmente possível fazer com Wasm e Kubernetes agora? Vamos revisar três dos maiores cenários em que você pode aproveitar o Wasm imediatamente. no CNCF runwasi container Uma maneira muito legal de usar o Wasm é verificar o maravilhoso projeto que faz parte do ecossistema containerd do CNCF. Essencialmente, permite que você execute um tempo de execução do WebAssembly por meio do containerd shim dentro do Kubernetes. Essa é uma opção muito melhor do que tentar executar o Wasm dentro de um contêiner, já que ele executa o WebAssembly diretamente, exatamente como faria se você girasse um contêiner em um pod. runwasi runwasi Malhas de serviço, alguém ? O Envoy e outras malhas já têm a capacidade de escrever plug-ins usando o WebAssembly. Com eles, você pode escrever filtragem personalizada e outros modelos de plug-in usando qualquer linguagem que compila para WebAssembly. wasmCloud Sabemos que as empresas já estão vendo valor em reunir o Kubernetes com o Wasm em vários casos de uso diferentes. Mas leva isso para o próximo nível devido à sua capacidade de conectar computação diferente em uma topologia de rede plana. Minha segunda demonstração mostrou como é fácil mover o mesmo código em três nós diferentes, cada um em um local diferente. Nesse caso, meu Mac em Pasadena, um cluster Digital Ocean K8s em Nova York e wasmCloud. Sem refatoração, mesmo código, em qualquer local. Em seguida, a plataforma Cosmonic (construída em wasmCloud) trará o tipo de abordagem de serviço completo para Wasm que as empresas precisarão à medida que avançam para a produção. o wasmCloud Quer experimentar o wasmCloud em uma plataforma gerenciada? Comece a usar a Cosmonic gratuitamente hoje. Lançar agora! de componente Modelo Finalmente, e mais emocionante, as coisas estão se movendo rapidamente neste espaço. Confira a palestra de Bailey Hayes e Dan Chiarlone, que mostrou o quão longe chegamos na definição dos padrões WASI e do Modelo de Componente - foi a primeira visão de como realmente queremos que o futuro seja. Você pode acompanhar o progresso aqui e se juntar à para ouvir as últimas novidades. WASM I/O Bytecode Alliance - Por , líder de engenharia da Cosmonic Taylor Thomas Também publicado aqui. Esta história foi distribuída como um lançamento pela sob o programa Brand As An Author da HackerNoon. Saiba mais sobre o programa aqui: CosmonicDevs https://business.hackernoon.com/brand-as-author Se você estiver interessado em aprender mais, tiver dúvidas ou quiser bater um papo, conecte-se conosco no ou . Discord no Slack
