Na ApacheCon América do Norte, Christopher Crosbie palestrou sobre "Mais um negociador de recursos para Big Data? Como o Google Cloud está aprimorando o processamento do Data Lake com o Kubernetes", destacando os esforços do Google para tornar o software de big data Apache "nativo na nuvem", desenvolvendo operadores Kubernetes de código aberto para fornecer planos de controle para a execução do software Apache em um cluster Kubernetes.
Crosbie, gerente de produto de Open Data and Analytics do Google, começou a palestra revisando o histórico de contribuição da empresa para a comunidade de big data de código aberto, começando com o documento de redução de mapa que inspirou o Hadoop e como o Google Cloud Platform (GCP) ofereceu recentemente versões gerenciadas de vários aplicativos Apache. Em particular, o serviço GCP Cloud Dataproc da Crosbie fornece versões gerenciadas dos clusters Apache Spark e do Hadoop. A palestra de Crosbie se concentrou nos pontos problemáticos associados à administração dos clusters e em como mudar o gerenciamento do cluster para o Kubernetes pode resolver muitos dos problemas. A equipe do Dataproc incorporou o suporte ao Kubernetes no produto, mas também forneceu muito do trabalho via código aberto, para que os usuários possam executar o Spark e o Hadoop nos próprios clusters Kubernetes.
Como o Spark e o Hadoop são sistemas distribuídos executados em um cluster, ambos exigem um sistema de gerenciamento de cluster para lidar com várias tarefas administrativas, como verificar a integridade dos vários nós, reiniciar ou substituir chamadas com falha e agendar tarefas. Ambos os sistemas suportam vários gerenciadores de cluster, incluindo YARN e Mesos. Grande parte do trabalho anterior da equipe do Dataproc se concentrou na construção de planos de controle para o YARN, integrando os controles à API do GCP.
No entanto, Crosbie diz que o uso do YARN tem vários pontos problemáticos. As dependências em outros componentes resultam em uma complicada pilha de software de código aberto, e o gerenciamento de dependências, a versão e o ajuste de tarefas são complicadas. Para reduzir a sobrecarga operacional, as organizações geralmente mantêm apenas um único cluster para executar todas as tarefas, o que significa que precisam competir por recursos e o cluster pode ter excesso de provisionamento.
Crosbie afirma que usar o Kubernetes como gerenciador de cluster pode resolver esses problemas. Como agora muitas organizações estão executando o Kubernetes como um gerenciador de cluster para os próprios aplicativos em container, o uso do Kubernetes para gerenciar o Spark elimina a necessidade de uma segunda interface de gerenciamento de recursos do YARN ou Mesos, simplificando as operações. Como os aplicativos são containers, o gerenciamento de dependência e versão é "incorporado" a cada um deles, e a execução é mais isolada. O sistema geral é mais resiliente, pois os patches de segurança e as atualizações de O/S são tratados no nível mais baixo do cluster do Kubernetes e não exigem alterações nos containers Spark e Hadoop.
A chave para usar o Kubernetes para hospedar o Spark foi estender a API do Kubernetes usando definições e operadores personalizados de recursos. Isso permite que a API do plano de controle do Kubernetes "fale na mesma língua" do aplicativo hospedado. A equipe do Crosbie possui operadores de código aberto para Spark e Apache Flink. Os usuários podem optar por executar uma solução hospedada na nuvem do Google ou baixar um helm chart e executar nos próprios clusters Kubernetes.
Crosbie concluiu a palestra listando alguns prós e contras de mudar para o Kubernetes pelo YARN. Muitos dos contras são resultado de "inércia" operacional, por exemplo, os trabalhos existentes podem ser ajustados para execução no YARN, mas precisariam ser ajustados novamente se migrados para o Kubernetes. Da mesma forma, as convenções de arquivos de log do YARN são bem compreendidas e as empresas podem ter construído auditorias e monitoramentos especificamente direcionados ao YARN. Crosbie comparou a segurança no Kubernetes a uma "boneca russa", de várias camadas:
O Kerberos no [Kubernetes] RBAC controla, na conta de serviço da VM, no IAM da nuvem, apoiado pelo Cloud Identity, muitas vezes sincronizado com outra coisa.
O operador Kubernetes para Spark foi desenvolvido em colaboração com a IBM e a Microsoft. É de código aberto e está na versão alfa desde 2018 e beta no início deste ano. O operador do Flink teve código aberto na semana passada, mas não teve um release oficial marcado.