Oportunidades e Desafios da Evolução Tecnológica no Cloud Native

Atualmente, o Cloud Native está se tornando cada vez mais popular, e a CNCF define Cloud Native como:

• Baseado em um ambiente moderno e dinâmico, também conhecido como ambiente de nuvem.
• Com a containerização como tecnologia fundamental, incluindo Service Mesh, infraestrutura imutável, API declarativa, etc.
• As principais características incluem autoescalabilidade, gerenciabilidade, observabilidade, automação, mudanças frequentes, etc.

De acordo com a pesquisa da CNCF de 2021, há um número muito significativo (mais de 62.000) de contribuidores na comunidade do Kubernetes. Com a tendência atual da tecnologia, cada vez mais empresas estão investindo mais custos no Cloud Native e entrando no caminho cedo para implantação ativa na nuvem. Por que as empresas estão adotando o Cloud Native durante o desenvolvimento, e o que o Cloud Native significa para elas?

Vantagens Técnicas do Cloud Native

A popularidade do Cloud Native vem de suas vantagens no nível técnico. Há dois aspectos principais da tecnologia Cloud Native, incluindo a containerização liderada pelo Docker e a orquestração de contêineres liderada pelo Kubernetes.

O Docker introduziu as imagens de contêiner no mundo da tecnologia, tornando as imagens de contêiner uma unidade de entrega padronizada. Na verdade, antes do Docker, a tecnologia de containerização já existia. Vamos falar sobre uma tecnologia mais recente, o LXC (Linux Containers) em 2008. Comparado ao Docker, o LXC é menos popular, pois o Docker fornece imagens de contêiner, que podem ser mais padronizadas e mais convenientes para migração. Além disso, o Docker criou o serviço público DockerHub, que se tornou o maior repositório de imagens de contêiner do mundo. Além disso, a tecnologia de containerização também pode alcançar um certo grau de isolamento de recursos, incluindo não apenas isolamento de CPU, memória e outros recursos, mas também isolamento da pilha de rede, o que facilita a implantação de várias cópias de aplicativos na mesma máquina.

Kubernetes se tornou popular devido ao crescimento do Docker. A tecnologia de orquestração de contêineres, liderada pelo Kubernetes, fornece várias capacidades importantes, como autocura de falhas, agendamento de recursos e orquestração de serviços. Kubernetes possui um mecanismo de descoberta de serviços baseado em DNS embutido e, graças à sua arquitetura de agendamento, pode ser escalado muito rapidamente para alcançar a orquestração de serviços.

Agora, cada vez mais empresas estão adotando ativamente o Kubernetes e transformando seus aplicativos para embarcar na implantação do Kubernetes. E o Cloud Native que estamos discutindo é, na verdade, baseado na premissa do Kubernetes, a pedra angular da tecnologia Cloud Native.

Vantagens da Containerização

1. Entrega Padronizada

As imagens de contêiner se tornaram uma unidade de entrega padronizada. Com a tecnologia de containerização, os usuários podem concluir a entrega diretamente por meio de uma imagem de contêiner, em vez de binários ou código-fonte. Com base no mecanismo de empacotamento da imagem de contêiner, você pode usar a mesma imagem para iniciar um serviço e produzir o mesmo comportamento em qualquer runtime de contêiner.

2. Portátil e Leve, Economizando Custos

A tecnologia de containerização alcança um certo isolamento por meio das capacidades do kernel do Linux, o que, por sua vez, facilita a migração. Além disso, a tecnologia de containerização pode executar aplicativos diretamente, o que é mais leve na implementação técnica em comparação com a tecnologia de virtualização, sem a necessidade de um sistema operacional na máquina virtual.

Todos os aplicativos podem compartilhar o kernel, o que economiza custos. E quanto maior o aplicativo, maior a economia de custos.

3. Conveniência do Gerenciamento de Recursos

Ao iniciar um contêiner, você pode definir as propriedades de CPU, memória ou IO de disco que podem ser usadas para o serviço do contêiner, o que permite um melhor planejamento e implantação de recursos ao iniciar instâncias de aplicativos por meio de contêineres.

Vantagens da Orquestração de Contêineres

1. Simplifica o Fluxo de Trabalho

No Kubernetes, a implantação de aplicativos é mais fácil de gerenciar do que no Docker, pois o Kubernetes usa configuração declarativa. Por exemplo, um usuário pode simplesmente declarar em um arquivo de configuração qual imagem de contêiner o aplicativo usará e quais portas de serviço serão expostas, sem a necessidade de gerenciamento adicional. As operações correspondentes à configuração declarativa simplificam muito o fluxo de trabalho.

2. Melhora a Eficiência e Economiza Custos

Outra característica vantajosa do Kubernetes é o failover. Quando um nó no Kubernetes falha, o Kubernetes agenda automaticamente os aplicativos nele para outros nós normais e os coloca em funcionamento. Todo o processo de recuperação não requer intervenção e operação humana, portanto, não apenas melhora a eficiência operacional no nível operacional, mas também economiza tempo e custos.

Com o surgimento do Docker e do Kubernetes, você verá que o surgimento deles trouxe grande inovação e oportunidade para a entrega de aplicativos. As imagens de contêiner, como unidades de entrega padrão, encurtam o processo de entrega e facilitam a integração com sistemas CI/CD.

Considerando que a entrega de aplicativos está se tornando mais rápida, como a arquitetura de aplicativos está seguindo a tendência do Cloud Native?

Evolução da Arquitetura de Aplicativos: de Monólitos, Microsserviços para Service Mesh

O ponto de partida da evolução da arquitetura de aplicativos ainda é a arquitetura monolítica. À medida que o tamanho e os requisitos dos aplicativos aumentaram, a arquitetura monolítica não atendia mais às necessidades de desenvolvimento colaborativo em equipe, então arquiteturas distribuídas foram gradualmente introduzidas.

Entre as arquiteturas distribuídas, a mais popular é a arquitetura de microsserviços. A arquitetura de microsserviços pode dividir os serviços em vários módulos, que se comunicam entre si, completam o registro e descoberta de serviços e alcançam capacidades comuns, como limitação de fluxo e circuit breaker.

Além disso, há vários padrões incluídos em uma arquitetura de microsserviços. Por exemplo, o padrão de banco de dados por serviço, que representa cada microsserviço com um banco de dados individual, é um padrão que evita o impacto no nível do banco de dados no aplicativo, mas pode introduzir mais instâncias de banco de dados.

Outro é o padrão de API Gateway, que recebe o tráfego de entrada do cluster ou de toda a arquitetura de microsserviços por meio de um gateway e completa a distribuição de tráfego por meio de APIs. Este é um dos padrões mais usados, e produtos de gateway como Spring Cloud Gateway ou Apache APISIX podem ser aplicados.

As arquiteturas populares estão gradualmente se estendendo para arquiteturas Cloud Native. Uma arquitetura de microsserviços sob o Cloud Native pode simplesmente construir o microsserviço original como uma imagem de contêiner e migrá-lo diretamente para o Kubernetes?

Em teoria, parece possível, mas na prática há alguns desafios. Em uma arquitetura de microsserviços Cloud Native, esses componentes precisam ser executados não apenas em contêineres, mas também incluem outros aspectos, como registro de serviços, descoberta e configuração.

O processo de migração também envolve transformação e adaptação no nível de negócios, exigindo a migração de lógicas comuns, como autenticação, autorização e capacidades relacionadas à observabilidade (registro, monitoramento, etc.) para o K8s. Portanto, a migração da implantação original em máquinas físicas para a plataforma K8s é muito mais complexa do que parece.

Nesse caso, podemos usar o modelo Sidecar para abstrair e simplificar o cenário acima.

Normalmente, o modelo Sidecar vem na forma de um Sidecar Proxy, que evolui do lado esquerdo do diagrama abaixo para o lado direito, afundando algumas capacidades genéricas (como autenticação, autorização, segurança, etc.) no Sidecar. Como você pode ver no diagrama, esse modelo foi adaptado de exigir a manutenção de vários componentes para exigir apenas duas coisas (aplicativo + Sidecar) para serem mantidas. Ao mesmo tempo, o modelo Sidecar em si contém alguns componentes comuns, portanto, não precisa ser mantido pelo lado do negócio, resolvendo facilmente o problema da comunicação de microsserviços.

Para evitar as cenas complexas de configuração separada e construção repetida de rodas ao introduzir um Sidecar para cada microsserviço, o processo pode ser implementado introduzindo um plano de controle ou por injeção do plano de controle, o que gradualmente forma o atual Service Mesh.

O Service Mesh geralmente requer dois componentes, ou seja, plano de controle + plano de dados. O plano de controle completa a distribuição de configuração e a execução da lógica relacionada, como o Istio, que é atualmente o mais popular. No plano de dados, você pode escolher um gateway de API como o Apache APISIX para encaminhamento de tráfego e comunicação de serviços. Graças ao alto desempenho e escalabilidade do APISIX, também é possível realizar algumas personalizações e lógicas personalizadas. A seguir, mostra-se a arquitetura da solução de Service Mesh com Istio+APISIX.

A vantagem dessa solução é que, quando você deseja migrar da arquitetura de microsserviços anterior para uma arquitetura Cloud Native, pode evitar mudanças massivas no lado do negócio usando uma solução de Service Mesh diretamente.

Desafios Técnicos do Cloud Native

O artigo anterior mencionou algumas das vantagens da tendência atual do Cloud Native em termos técnicos. No entanto, toda moeda tem dois lados. Embora alguns elementos novos e oportunidades possam ser trazidos, desafios surgirão devido à participação de certas tecnologias.

Problemas Causados pela Containerização e K8s

Na parte inicial do artigo, mencionamos que a tecnologia de containerização usa um kernel compartilhado, e o kernel compartilhado traz leveza, mas cria uma falta de isolamento. Se ocorrer um escape de contêiner, o host correspondente pode ser atacado. Portanto, para atender a esses desafios de segurança, tecnologias como contêineres seguros foram introduzidas.

Além disso, embora as imagens de contêiner forneçam um método de entrega padronizado, elas são propensas a ataques, como ataques à cadeia de suprimentos.

Da mesma forma, a introdução do K8s também trouxe desafios na segurança dos componentes. O aumento nos componentes levou a um aumento na superfície de ataque, bem como a vulnerabilidades adicionais relacionadas aos componentes subjacentes e níveis de dependência. No nível de infraestrutura, a migração de máquinas físicas ou virtuais tradicionais para o K8s envolve custos de transformação de infraestrutura e mais custos de mão de obra para realizar backups de dados do cluster, atualizações periódicas e renovações de certificados.

Além disso, na arquitetura do Kubernetes, o apiserver é o componente central do cluster e precisa lidar com todo o tráfego interno e externo. Portanto, para evitar problemas de segurança de borda, como proteger o apiserver também se torna uma questão-chave. Por exemplo, podemos usar o Apache APISIX para protegê-lo.

Segurança

O uso de novas tecnologias requer atenção adicional no nível de segurança:

• No nível de segurança de rede, o controle granular do tráfego pode ser implementado por meio de Network Policy, ou outros métodos de criptografia de conexão, como mTLS, para formar uma rede de confiança zero.

• No nível de segurança de dados, o K8s fornece o recurso secret para lidar com dados confidenciais, mas, na verdade, ele não é seguro. O conteúdo do recurso secret é codificado em Base64, o que significa que você pode acessar o conteúdo por meio da decodificação Base64, especialmente se estiverem no etcd, que pode ser lido diretamente se você tiver acesso ao etcd.

• No nível de segurança de permissões, também há uma situação em que as configurações de RBAC não são razoáveis, o que leva a um atacante a usar o Token relevante para se comunicar com o apiserver para alcançar o objetivo do ataque. Esse tipo de configuração de permissão é mais visto em cenários de controlador e operador.

Observabilidade

A maioria dos cenários Cloud Native envolve algumas operações relacionadas à observabilidade, como registro, monitoramento, etc.

No K8s, se você deseja coletar logs de várias maneiras, precisa coletá-los diretamente em cada nó do K8s por meio de agregação. Se os logs fossem coletados dessa forma, o aplicativo precisaria ser exportado para a saída padrão ou erros padrão.

No entanto, se o negócio não fizer alterações relevantes e ainda optar por escrever todos os logs do aplicativo em um arquivo no contêiner, significa que um Sidecar é necessário para a coleta de logs em cada instância, o que torna a arquitetura de implantação extremamente complexa.

Voltando ao nível de governança de arquitetura, a seleção de soluções de monitoramento no ambiente Cloud Native também apresenta alguns desafios. Uma vez que a seleção da solução está errada, o custo subsequente de uso é muito alto, e a perda pode ser enorme se a direção estiver errada.

Além disso, há questões de capacidade envolvidas no nível de monitoramento. Ao implantar um aplicativo no K8s, você pode simplesmente configurar seu limite de taxa para limitar os detalhes de recursos que o aplicativo pode usar. No entanto, em um ambiente K8s, ainda é bastante fácil vender recursos em excesso, utilizar recursos em excesso e transbordar a memória devido a essas condições.

Além disso, outra situação em um cluster K8s onde todo o cluster ou nó fica sem recursos levará à evicção de recursos, o que significa que os recursos já em execução em um nó são evictados para outros nós. Se os recursos de um cluster estiverem apertados, uma tempestade de nós pode facilmente causar a queda de todo o cluster.

Evolução de Aplicativos e Padrão de Multi-cluster

No nível da evolução da arquitetura de aplicativos, a questão central é a descoberta de serviços.

O K8s fornece um mecanismo de descoberta de serviços baseado em DNS por padrão, mas se o negócio incluir a coexistência de negócios na nuvem e negócios locais, será mais complicado usar um mecanismo de descoberta de serviços DNS para lidar com a situação.

Enquanto isso, se as empresas escolherem a tecnologia Cloud Native, com a expansão da escala de negócios, elas gradualmente considerarão a direção de processamento de múltiplos nós, o que envolverá questões de multi-cluster.

Por exemplo, queremos fornecer aos clientes um modelo de maior disponibilidade por meio de múltiplos clusters, e desta vez envolverá a orquestração de serviços entre múltiplos clusters, distribuição de carga multi-cluster e configuração de sincronização, e como lidar e implantar estratégias para clusters em cenários de multi-nuvem e nuvem híbrida. Esses são alguns dos desafios que serão enfrentados.

Como o APISIX Possibilita a Transformação Digital

O Apache APISIX é um gateway de API Cloud Native sob a Apache Software Foundation, que é dinâmico, em tempo real e de alto desempenho, fornecendo recursos ricos de gerenciamento de tráfego, como balanceamento de carga, upstream dinâmico, lançamento canário, circuit breaker, autenticação, observabilidade, etc. Você pode usar o Apache APISIX para lidar com o tráfego tradicional norte-sul, bem como o tráfego leste-oeste entre serviços.

Atualmente, com base na evolução arquitetônica e mudanças de aplicativos descritas acima, soluções baseadas em APISIX, como o controlador Ingress e Service Mesh, também foram derivadas no Apache APISIX para ajudar as empresas a realizar melhor a transformação digital.

Solução APISIX Ingress

O Apache APISIX Ingress Controller é uma implementação de Kubernetes Ingress Controller que serve principalmente como um gateway de tráfego para lidar com o tráfego norte-sul do Kubernetes.

A arquitetura do APISIX Ingress Controller é semelhante à do APISIX, pois é uma arquitetura separada para o plano de controle e o plano de dados. Nesse caso, o APISIX é usado como o plano de dados para o processamento real do tráfego.

Atualmente, o APISIX Ingress Controller suporta os três métodos de configuração a seguir e é compatível com todos os plugins do APISIX prontos para uso:

• Suporte para recursos Ingress nativos do K8s. Essa abordagem permite que o APISIX Ingress Controller tenha um nível mais alto de adaptabilidade. Até o momento, o APISIX Ingress Controller é a versão mais suportada de qualquer produto de controlador Ingress de código aberto e influente.

• Suporte para o uso de recursos personalizados. Os recursos personalizados atuais do APISIX Ingress Controller são um conjunto de especificações CRD projetadas de acordo com a semântica do APISIX. O uso de recursos personalizados facilita a integração com o APISIX e é mais nativo.

• Suporte para Gateway API. Como a próxima geração do padrão Ingress, o APISIX Ingress Controller começou a suportar a Gateway API (estágio Beta). À medida que a Gateway API evolui, é provável que se torne um recurso embutido diretamente no K8s.

O APISIX Ingress Controller tem as seguintes vantagens sobre o Ingress NGINX:

• Separação arquitetônica. No APISIX Ingress, a arquitetura do plano de dados e do plano de controle é separada. Quando a pressão do processamento de tráfego é alta e você deseja expandir a capacidade, pode simplesmente fazer a expansão do plano de dados, o que permite que mais planos de dados sejam servidos externamente sem a necessidade de fazer ajustes no plano de controle.

• Alta escalabilidade e suporte para plugins personalizados.

• Como a escolha do plano de dados, com alto desempenho e recursos totalmente dinâmicos. Graças ao recurso totalmente dinâmico do APISIX, é possível proteger o tráfego de negócios o máximo possível com o uso do APISIX Ingress.

Atualmente, o APISIX Ingress Controller é usado por muitas empresas em todo o mundo, como a China Mobile Cloud Open Platform (um produto de API aberta e IDE em nuvem), Upyun e Copernicus (parte do Europe's Eyes on Earth).

O APISIX Ingress Controller ainda está em iteração contínua, e planejamos melhorar mais funções das seguintes maneiras:

1. Completar o suporte para a Gateway API para permitir mais configurações de cenários.
2. Suporte para proxy de serviço externo.
3. Suporte nativo para múltiplos registros para tornar o APISIX Ingress Controller mais versátil.
4. Atualizações arquitetônicas para criar um novo modelo arquitetônico;
5. Integração com Argo CD/Flux e outras ferramentas GitOps para criar um ecossistema rico.

Se você estiver interessado na solução APISIX Ingress, sinta-se à vontade para seguir as atualizações da comunidade para iterações de produtos e tendências da comunidade.

Solução APISIX Service Mesh

Atualmente, além do gateway de API e da solução Ingress, a solução Service Mesh baseada no APISIX também está em iteração ativa.

A solução Service Mesh baseada no APISIX consiste em dois componentes principais, ou seja, o plano de controle e o plano de dados. O Istio foi escolhido para o plano de controle, pois é um líder do setor com uma comunidade ativa e é suportado por vários fornecedores. O APISIX foi escolhido para substituir o Envoy no lado dos dados, permitindo que o alto desempenho e escalabilidade do APISIX entrem em ação.

O Service Mesh do APISIX ainda está sendo perseguido ativamente, com iterações subsequentes planejadas nas seguintes direções:

• Realizar aceleração eBPF para melhorar a eficácia geral.

• Realizar integração de capacidades de plugins para permitir um melhor uso das capacidades do APISIX Ingress dentro da arquitetura do Service Mesh.

• Criar uma ferramenta de migração contínua para fornecer ferramentas mais fáceis e simplificar o processo para os usuários.

Em geral, a evolução da arquitetura e da tecnologia na era do Cloud Native nos traz tanto oportunidades quanto desafios. O Apache APISIX, como um gateway Cloud Native, tem se comprometido com mais adaptações e integrações técnicas para a tendência do Cloud Native. Várias soluções baseadas no APISIX também começaram a ajudar os usuários empresariais a realizar a transformação digital e ajudar as empresas a fazer a transição para o caminho do Cloud Native de forma mais suave.