Uma coisa que ouvimos dos administradores e operadores da malha de serviço que usam o Istio é que sua complexidade dificulta a adoção e a integração com o stack atual. Eu estou envolvido com o desenvolvimento do Istio desde o Istio 0.6 e vi que ele se tornou cada vez mais complexo ao longo do tempo.
Esta versão possui muitas características novas, mas esses recursos são simplificados por uma grande melhoria. A melhoria que mais me empolga está na arquitetura do Istio que consolida o painel de controle em um único binário chamado istiod. Essencialmente, o istiod simplifica dramaticamente a arquitetura do Istio, que acreditamos que melhorará a viabilidade de fazer melhorias no projeto.
Este artigo foi escrito por Steven Dake da IBM. Leia o blog de lançamento oficial da comunidade Istio para obter mais informações.
Por que o Istio começou com uma arquitetura de micro serviço
Inicialmente, o Istio usou uma arquitetura de micro serviço para dar suporte a forma em que nossas equipes no Istio estavam trabalhando. Na época, entregávamos atualizações e lançamentos de serviços em diferentes agendas, estávamos usando contratos de API entre nossas equipes e precisávamos de escalamento horizontal independente.
À medida que a equipe e a tecnologia do Istio amadureciam, as vantagens de uma arquitetura de micro serviço diminuíam. Quando concluímos o desenvolvimento do Istio 1.4, o grupo de trabalho de Ambientes de Istio recebeu uma proposta para unificar os componentes existentes num monolito. O grupo de trabalho de Ambientes liderou os debates técnicos e nasceu o conceito de istiod! Durante a reunião do Comitê de Supervisão Técnica do Istio que se seguiu, o grupo de trabalho de Ambientes propôs o uso do binário istiod.
O que exatamente é Istiod?
Simplificando, istiod é a reversão do modelo de arquitetura de micro serviço. Para entender como o binário istiod melhora o Istio, vejamos sua estrutura atual.
O plano de controle 1.4 do Istio consiste em cinco serviços e plugins para extensibilidade:
- Carregamento do proxy do paralelo. Fornecido pelo serviço sidecar-injector (não na foto).
- Extensibilidade. Fornecida pelos serviços de Mixer (istio-telemetry e istio-policy services).
- Plug-ins de extensibilidade. Fornecido pelos plugins do Mixer Adapter.
- Geração e serviço da configuração do proxy paralelo. Fornecido pelo serviço Pilot.
- Segurança. Fornecido pelo serviço Citadel.
- Validação. Fornecido pelo serviço Galley.
O Istio 1.5 reorganiza o plano de controle em um serviço e reimplementa a extensibilidade:
- Istiod. FFornece carregamento lateral de proxy, cálculo de malha, segurança e validação
- Plano de dados. Os plugins do Mixer Adapter são reimplementados dentro da malha como plugins Envoy.
Por que Istiod?
Então, por que escolhemos adotar o binário istiod? Um dos principais motivos foi que, à medida que o desenvolvimento do Istio amadureceu, começamos a trabalhar como uma única equipe, com uma única entrega, e não cumprimos mais os critérios para a necessidade de uma arquitetura de micro serviços. Outros motivos específicos incluem:
- Operação mais fácil do plano de controle. A arquitetura simplificada facilita para os administradores e operadores da malha controlar e monitorar o plano de controle do Istio. Monitorar um serviço de istiod é muito mais fácil do que seis ou sete serviços no Istio 1.4.
- Melhorar o desempenho.Em outras versões do Istio, no plano de controle havia uma grande quantidade componentes de comunicação sobre o networking no plano de controle, o que estava causando problemas de desempenho. istiod reduz o número de componentes, por isso esperamos que isso afete positivamente o desempenho.
- Menor presença de API interna. Grande parte de nossa implementação anterior de micro serviços contém código redundante. O Istio é aprimorado removendo esse código redundante usado por cada micro serviço normalmente para configuração.
Outras melhorias no Istio 1.5
O Istio 1.5 apresenta um novo modelo para estender o Istio através do runtime do WebAssembly (Wasm) no Envoy, que permite implementar extensões em vários idiomas. Esses módulos Wasm podem ser carregados dinamicamente enquanto o proxy continua atendendo o tráfego. Eles também são ótimos para reutilização, pense neles como imagens do docker para o proxy Envoy para estender facilmente a plataforma de maneiras que o Mixer simplesmente não poderia. Consulte o blog da Solo.io para saber mais sobre a extensão WebAssembly.
Outros aprimoramentos importantes incluem:
- Versão beta da CLI do Istio usando istioctl;
- Dezenas de melhorias no istioctl, incluindo melhores regras de validação e integração mais fácil com os sistemas de CI;
- Experiência de segurança aprimorada, consolidando em um único CRD (beta), adicionando novas políticas e autorizações de segurança e muito mais;
- Melhores recursos de observabilidade, incluindo o padrão de Telemetry v2.
A força de Istio é a comunidade
A arquitetura aberta e o ecossistema do Istio se combinam para tornar a tecnologia eficaz. Não há nenhum vendor lock-in que limite os tipos de serviços que você pode usar com ele. Além disso, o Istio pode ser executado em qualquer modelo de nuvem – nuvem pública, nuvem privada, local ou nuvem híbrida.
Nossa comunidade forte e vibrante torna o Istio especial. O Istio foi fundado pela IBM, Google e Lyft em 2017. O projeto Istio se beneficia de uma comunidade ativa e diversificada composta por mais de 800 desenvolvedores de mais de 459 organizações. O Istio e o ecossistema do Istio têm inúmeros colaboradores adicionais trabalhando para fazer do Istio um sucesso.
Envolva-se com o Istio
A tecnologia de malha de serviço Istio é de código aberto. O Istio conta com uma comunidade ativa de colaboradores para melhorar a tecnologia.
Aqui estão algumas maneiras de você se envolver:
- Inicie com Istio no seu cluster Kubernetes.
- Saiba como contribuir com o Istio.
- Entre no Slack de Istio, seguindo estas instruções.
Steven Dake é um líder de código aberto da IBM. Ele é um mantenedor do projeto Istio e serve como líder do grupo de trabalho de Ambientes.